Obfuscated Malware Analysis with Responder Pro 2.0.5

Responder 2.0.5 was recently released, and for me, as a daily-user of the product, it contains new features that (much like the invention of the DVR,) I can't imagine living without from here on. Today, I will demonstrate a process that used to be painstaking, which is now done completely automatically.
I recently observed an interesting piece of malware in a customer's network. The process host was spoolsv.exe, and the offending module was inetpp.dll. In a nutshell, the malware would crash the inetpp.dll process, rename it to something else, drop its own malicious replacement inetpp.dll and restart the process. It acted as a printer handler as well, calling InitializePrintProvidor and pointing it to the now-renamed, original inetpp.dll for all incoming print jobs as to not alert the user to suspect activity. Intially, what caught my eye about this module was that it was lacking references to the standard static links required by the real inetpp.dll:

advapi32.dll
crypt32.dll
kernel32.dll
msvcrt.dll
ntdll.dll
spoolss.dll
user32.dll
winspool.drv
ws2_32.dll

Here is the suspicious version:

There was no obvious domain that this malware contained as a binary string, but I knew it had to be connecting to something, since it had hijacked the internet print dll. I hadn't seen this particular binary or exploit before, so I loaded up Responder Pro. Within a few minutes of just scrolling through the disassembled code, I saw hand-written, byte-by-byte strings being created, the command strings the binary was listening for and at last, the command and control domain.

Below is the main loop of the malware, looking for input commands:

Malware has a long history of evading typical antivirus software and incident responders by obfuscating API calls, command and control domains and other non-standard strings in an attempt to mask its own malicious intent. One such technique is to build these strings byte-by-byte during runtime. Digital DNA has several traits to flag and detect this behavior, but sometimes the context is difficult for new users of the product to understand. In previous versions of Responder, to decode this information required either a memorization of hex values as they relate to ascii characters, or by using the built in value calculator.

This was an invaluable tool, but with the introduction of Responder 2.0.5, this information is now automatically represented and doesn't require manually checking each and every byte ptr in the disassembled binary. Below is an example of how easy it is to spot manually constructed strings within a disassembled binary. (NOTE: The actual domain in the malware has been censored due to the directed nature of the domain name.)

Manually looking up the hex values for ascii characters in assembly used to be a process of "guess and check", but with the new auto-labeling, even someone with limited or no assembly skill can have obfuscated calls and manually created strings represented in a visually impactful way.

Ghost in the (Infected) Machine

Without a doubt, it is standard practice to look for debug artifacts in malicious binaries. Often times entire directory strings can be extracted providing clues to the identity of the actual malware author. An example would be a discovered string named:

"c:\documents and settings\superhacker9001
\projects\malware\targeted\company_1\exploit.pdb"

that contains the username of the person who's system the malware was compiled on, in this case "superhacker9001". That information can be used to search in a number of ways to potentially uncover identities or motives of a specific attacker.

But other types of metadata can be just as valuable.

Recently I observed a phishing attempt that used an embedded flash exploit where the exploit itself was contained within a Microsoft Word document. The exploit-riddled .doc file was stripped of all metadata, but as part of the payload, it created, then opened a new .doc file as to not arise additional suspicion. This new .doc's metadata however was not sanitized and contained not only an "Author" field, but also a "Company" field.

This information in hand, it became incredibly easy to track the author of the malware. A simple Google search using the two fields in tandem gave way to the malware author's personal website. After translating the contents of this foreign language page, it became obvious this was the source. That personal page contained flash exploit code unique binary packers and other compiler obfuscation tools.

Of course this time we had gotten lucky that this phisherman had not taken the time to sanitize both .doc files. Sometimes it takes a great deal of time to be able to properly attribute malware attacks. Another network was constantly bombarded with malware. Each time a new binary was dropped, the command and control server would change ports and change locations. Using WHOIS lookups on the hostnames gave way to interesting results. The registrar name would always change, but the registrar fax number would always remain the same. Using HBGary's network monitoring tool Razor, we were able to create a policy to blackhole even future traffic coming from (or going to) this attacker's command and control servers. That's because Razor does a WHOIS lookup on every new domain it comes in contact with. We can blacklist by registrar name, phone number, email address or any other standard WHOIS field.