0x10 First Place
by gNick
Poor Molly – To have her box violated on her 0x10 birthday must be very
distressing. But, we'll see what we can do to restore her purity.
1. Based on the output of the strings command, what capabilities might
be built into the malicious code?
Based on the output of her 'strings' test, Molly can conclude that she
has contracted something nasty. Let's tackle the strings in the order
they were detected to see what we can learn:
"This program must be run under Win32"
"FTWARE\Borland\Delphi\RTL"
This simply tells us that the malicious hacker used the Borland Delphi
compiler and took advantage of the Run Time Libraries available to
programmers. Although I am not personally a Delphi fan, it has become a
favorite of many virus writers and new Delphi-based viruses are being
generated regularly.
"EliRT 1.00"
This is bad news. EliRT is used to insert code (often Remote
Administration Tools) into other processes so that they will run in
conjunction with whatever application they've infected. EliRT was used
in the prolific Beagle virus among several others. Most often,
malicious code is inserted into Explorer.exe. This means that no
suspicious processes need to be running on the target box, the code will
be run whenever the computer is up, killing the infected process makes
further work more difficult, and clean-up can be messy. Be afraid… Be
very afraid…
"Hook.Patch"
This may imply that the code has been modified to 'hook' system API
calls. This is a popular technique when debugging or documenting
compiled code, but also has some obvious uses for malicious hackers.
For example, a hacker could intercept all process termination commands
and intercept or modify all process memory reads and writes. Basically,
a talented hacker can make a 'hooked' process do just about anything
he'd like. 'Hookers' are dangerous and letting one access your box can
easily lead to infection.
"Stealth2j"
Stealth2 is a Trojan that likes to steal passwords. The presence of
this string likely means that some variant of Stealth2 is sniffing
around and sharing private passwords with the attacker. The 'j' is
probably garbage. Also, Stealth2 is not one of the preferred password
stealers – There are alternatives that are more popular among virus
writers. Anyone with the good taste and couth to include the two
strings following this one in his virus would use something cooler –
"Stealth2j" could be a red herring.
"Please remember to buy"
"The Malware book by Ed and Lenny!!!"
These strings are an indication that we're dealing with a hacker of
obvious sophistication and knowledge of powerful literature dealing with
malware. Be careful, Molly!
"GetProcAddress"
This is used to obtain pointers to functions within dll's. This can be
used by an attacker to make sophisticated internal calls to processes.
"iexplore.exe"
This could indicate that that Internet Explorer is the process that the
attacker wants to sink his hook into. It could also indicate that he's
spawning his own IE window behind the scenes to use for his own purposes
– This might explain all the traffic on TCP 443 (the traditional https
port). If he does spawn his own IE client, Molly may be able to see it
in the process list, even though it would probably be hidden from the
screen and taskbar. This is likely considering that it showed up under
Active Ports. Techniques exist to prevent processes from showing up
even in the process explorer, so checking for 'iexplore.exe' there could
verify its presence, but not its absence.
"\VMware Tools"
This tells us that the attacker is making use of some of VMware's
capabilities. This is one of the Remote Administration Tools I
mentioned earlier and could explain the mysterious moving mouse. These
tools are powerful (if not subtle) ways for the attacker to run code,
change settings, and basically abuse Molly's box in whatever way suits him.
"Cmd Line:"
This is a weird thing to see. It doesn't appear to be trying to spawn
a command line and it would be a poor choice of characters if the
attacker was trying to spoof the cmd utility with a clone. Maybe it's
just a prompt being passed through his connection to help him to pass
commands to Molly's OS.
"ersion\Run/;
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" and
"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" are
two popular registry locations to place links to software somebody wants
to run when the OS starts. The string we see could imply either of
these locations, but the first is more likely since it affects all
users. The attacker just wants to make sure his code gets run when
Molly's system is up. Using the program 'Autoruns' (by Mark Russinovich
and Bryce Cogswell and available at www.sysinternals.com), Molly could
check to see if there are new entries in those locations or others
designed to run code at start-up.
2. What simple and popular method could the attacker have used to thwart
strings analysis (as well as making binary disassembly more difficult)
on note.exe? What tools could the attacker use to accomplish this goal?
The easiest way to tackle these goals would be to use an executable
packer or crypter. Basically these just either compress (packer) or
obfuscate (crypter) the executable and tack on a small header so that it
will still run. This has the advantages of obscuring strings and making
it very difficult to decipher the executable in its packed form. Some
examples of free packer tools are: CExe, exe32pack, EZIP, FSG, Mew, PE
Dimisher, PE-PaCK, and UPX. A few free crypters include: ARM
Protector, CodeCrypt, ELFCrypt, NFO, PECRYPT32, PELOCK, PEncrypt,
PE-PROTECTOR, PESpin, PeX, and tElock.
There are many more free and commercial alternatives to these tools.
3. How could a malicious code researcher overcome the strings-obscuring
and anti-disassembly technique(s) you described in your answer to
question 2? What tools could a researcher use to accomplish this goal?
Crypters have developed very sophisticated methods for obfuscating
code, but their weakness lies in the fact that the OS must still be able
to interpret the code in order to be able to run it. Several tools have
been put together to exploit this weakness and try to return the code to
a more user-readable form. Some, like ProcDump, run the program and
then dump the running process to disk. Others, like Generic Unpacker
Win32 and Win32 Intro try to distinguish between the packer/crypter code
and the original code and run only what is necessary to convert the
program to normal form and return the result. Still others, like
UN-PACK, try to identify the packing routine using a library of known
headers and applying any that match. Finally, there exist a huge array
of packer-specific unpackers that can be used if there is a strong
suspicion about which packer/crypter has been used. The internet is
full of resources elaborating on the function and alternatives for
bypassing these packers and crypters due in large part to pirates trying
to bypass various software and copyright protections.
4. What should Molly do next to eradicate the malware and win Jake's heart?
Unfortunately, I think Molly's box has been pretty well defiled. There
are many schools of thought on what Molly should do now. If she's truly
paranoid, she should immediately power-off the box and remove the disk
for data recovery and forensics (Power-Off NOT Shut-Down). If I was
Molly, I would probably just cross my fingers, pull the network
connection out, kill any visible 'iexplore.exe' processes that may be
running, and hope for the best as I began backing up important data.
It's a little risky, but less trouble than pulling the disk. I live
dangerously when there's nothing absolutely crucial on the line. In
either case, she should assume that the OS has been completely
compromised. She needs to back up her data (including note.exe in case
she needs it for evidence later), and re-install the OS. If she's
curious or knows a good forensics person, ghosting the drive for
analysis before doing repairs might be interesting – She might learn
something more about the virus and maybe pick up a couple of leads to
help her prove the identity of her attacker. I wish for Molly's sake
that there was a simpler solution than a full re-install, but the
infection just looks too deep – A re-install would probably be less
trouble than relentlessly hunting for any infected resources and
attempting repair. Good luck, Molly – Happy Birthday – I hope you saved
your install disks!
-gNick
distressing. But, we'll see what we can do to restore her purity.
1. Based on the output of the strings command, what capabilities might
be built into the malicious code?
Based on the output of her 'strings' test, Molly can conclude that she
has contracted something nasty. Let's tackle the strings in the order
they were detected to see what we can learn:
"This program must be run under Win32"
"FTWARE\Borland\Delphi\RTL"
This simply tells us that the malicious hacker used the Borland Delphi
compiler and took advantage of the Run Time Libraries available to
programmers. Although I am not personally a Delphi fan, it has become a
favorite of many virus writers and new Delphi-based viruses are being
generated regularly.
"EliRT 1.00"
This is bad news. EliRT is used to insert code (often Remote
Administration Tools) into other processes so that they will run in
conjunction with whatever application they've infected. EliRT was used
in the prolific Beagle virus among several others. Most often,
malicious code is inserted into Explorer.exe. This means that no
suspicious processes need to be running on the target box, the code will
be run whenever the computer is up, killing the infected process makes
further work more difficult, and clean-up can be messy. Be afraid… Be
very afraid…
"Hook.Patch"
This may imply that the code has been modified to 'hook' system API
calls. This is a popular technique when debugging or documenting
compiled code, but also has some obvious uses for malicious hackers.
For example, a hacker could intercept all process termination commands
and intercept or modify all process memory reads and writes. Basically,
a talented hacker can make a 'hooked' process do just about anything
he'd like. 'Hookers' are dangerous and letting one access your box can
easily lead to infection.
"Stealth2j"
Stealth2 is a Trojan that likes to steal passwords. The presence of
this string likely means that some variant of Stealth2 is sniffing
around and sharing private passwords with the attacker. The 'j' is
probably garbage. Also, Stealth2 is not one of the preferred password
stealers – There are alternatives that are more popular among virus
writers. Anyone with the good taste and couth to include the two
strings following this one in his virus would use something cooler –
"Stealth2j" could be a red herring.
"Please remember to buy"
"The Malware book by Ed and Lenny!!!"
These strings are an indication that we're dealing with a hacker of
obvious sophistication and knowledge of powerful literature dealing with
malware. Be careful, Molly!
"GetProcAddress"
This is used to obtain pointers to functions within dll's. This can be
used by an attacker to make sophisticated internal calls to processes.
"iexplore.exe"
This could indicate that that Internet Explorer is the process that the
attacker wants to sink his hook into. It could also indicate that he's
spawning his own IE window behind the scenes to use for his own purposes
– This might explain all the traffic on TCP 443 (the traditional https
port). If he does spawn his own IE client, Molly may be able to see it
in the process list, even though it would probably be hidden from the
screen and taskbar. This is likely considering that it showed up under
Active Ports. Techniques exist to prevent processes from showing up
even in the process explorer, so checking for 'iexplore.exe' there could
verify its presence, but not its absence.
"\VMware Tools"
This tells us that the attacker is making use of some of VMware's
capabilities. This is one of the Remote Administration Tools I
mentioned earlier and could explain the mysterious moving mouse. These
tools are powerful (if not subtle) ways for the attacker to run code,
change settings, and basically abuse Molly's box in whatever way suits him.
"Cmd Line:"
This is a weird thing to see. It doesn't appear to be trying to spawn
a command line and it would be a poor choice of characters if the
attacker was trying to spoof the cmd utility with a clone. Maybe it's
just a prompt being passed through his connection to help him to pass
commands to Molly's OS.
"ersion\Run/;
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" and
"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" are
two popular registry locations to place links to software somebody wants
to run when the OS starts. The string we see could imply either of
these locations, but the first is more likely since it affects all
users. The attacker just wants to make sure his code gets run when
Molly's system is up. Using the program 'Autoruns' (by Mark Russinovich
and Bryce Cogswell and available at www.sysinternals.com), Molly could
check to see if there are new entries in those locations or others
designed to run code at start-up.
2. What simple and popular method could the attacker have used to thwart
strings analysis (as well as making binary disassembly more difficult)
on note.exe? What tools could the attacker use to accomplish this goal?
The easiest way to tackle these goals would be to use an executable
packer or crypter. Basically these just either compress (packer) or
obfuscate (crypter) the executable and tack on a small header so that it
will still run. This has the advantages of obscuring strings and making
it very difficult to decipher the executable in its packed form. Some
examples of free packer tools are: CExe, exe32pack, EZIP, FSG, Mew, PE
Dimisher, PE-PaCK, and UPX. A few free crypters include: ARM
Protector, CodeCrypt, ELFCrypt, NFO, PECRYPT32, PELOCK, PEncrypt,
PE-PROTECTOR, PESpin, PeX, and tElock.
There are many more free and commercial alternatives to these tools.
3. How could a malicious code researcher overcome the strings-obscuring
and anti-disassembly technique(s) you described in your answer to
question 2? What tools could a researcher use to accomplish this goal?
Crypters have developed very sophisticated methods for obfuscating
code, but their weakness lies in the fact that the OS must still be able
to interpret the code in order to be able to run it. Several tools have
been put together to exploit this weakness and try to return the code to
a more user-readable form. Some, like ProcDump, run the program and
then dump the running process to disk. Others, like Generic Unpacker
Win32 and Win32 Intro try to distinguish between the packer/crypter code
and the original code and run only what is necessary to convert the
program to normal form and return the result. Still others, like
UN-PACK, try to identify the packing routine using a library of known
headers and applying any that match. Finally, there exist a huge array
of packer-specific unpackers that can be used if there is a strong
suspicion about which packer/crypter has been used. The internet is
full of resources elaborating on the function and alternatives for
bypassing these packers and crypters due in large part to pirates trying
to bypass various software and copyright protections.
4. What should Molly do next to eradicate the malware and win Jake's heart?
Unfortunately, I think Molly's box has been pretty well defiled. There
are many schools of thought on what Molly should do now. If she's truly
paranoid, she should immediately power-off the box and remove the disk
for data recovery and forensics (Power-Off NOT Shut-Down). If I was
Molly, I would probably just cross my fingers, pull the network
connection out, kill any visible 'iexplore.exe' processes that may be
running, and hope for the best as I began backing up important data.
It's a little risky, but less trouble than pulling the disk. I live
dangerously when there's nothing absolutely crucial on the line. In
either case, she should assume that the OS has been completely
compromised. She needs to back up her data (including note.exe in case
she needs it for evidence later), and re-install the OS. If she's
curious or knows a good forensics person, ghosting the drive for
analysis before doing repairs might be interesting – She might learn
something more about the virus and maybe pick up a couple of leads to
help her prove the identity of her attacker. I wish for Molly's sake
that there was a simpler solution than a full re-install, but the
infection just looks too deep – A re-install would probably be less
trouble than relentlessly hunting for any infected resources and
attempting repair. Good luck, Molly – Happy Birthday – I hope you saved
your install disks!
-gNick
