|
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 |
|