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.