In a post earlier this month, I presented steps for unpacking and restoring the IT/IAT of a suspicious BHO for analysis purposes. In that case, it was packed with a tool called “Upack”, otherwise known as the “Ultimate PE Packer” by its author Dwing. Upack often is used on executable files around 40kb in size. It compresses the file’s contents with the LZMA algorithm and adds an unpacking stub to the target file for self-decompressing at runtime.
In other words, to make a file smaller for download and delivery without requiring a decompression utility like WinZip or WinRar to already be installed on another system at runtime, an author can compress their executable creation with this tool.
This posting will work with the PE file that was recreated from that previous work.

Here are some of the steps we used to work on this file, leaving off at the last step to identify some behaviors of this malicious file:
Change PE file to .exe in PE header, rename dll to exe extension
Load into Ollydbg
Find OEP (original entry point) — pretty easy with Upack
Break at oep and dump file from memory to disk
Fixup IAT with ImpRec and write to dumped file
Rename fixed file and modify PE header back to dll
Load into IDA Pro 5.1 with the IDA Python plugin installed…

When we load this file into IDA Pro, the disassembler now can provide a listing that can be used to reverse engineer the component’s functionality. Without properly unpacking the file and fixing up the imports, the disassembler cannot analyze the code.
However, the listing doesn’t seem to immediately reveal much about the component’s activity. But knowing that this component is a BHO helps identify key areas for reversing progress. We do see fundamental Win32 API calls like “AtlInternalQueryInterface” and “AtlComPtrAssign”, leaving clues about COM programming within the component. The location of these calls can lead us further down the control flow to locations where COM calls can be further analyzed and easily understood. Joe Stewart published information about reversing OLE, but this code is more complex than a common SubmitHook trojan.
Frank Boldewin’s Python scripts come in handy for walking through these COM calls — the listing now reveals a section where the code obtains the “document” interface within the web browser and enumerates its connection points. We can set memory breakpoints on these sections for further analysis, and when we visit various banking web sites, we can see that the BHO is building an event sink:

Once the event sink is set, GetKeyState is then called on “KEY_DOWN” events. The component can check on each individual keystroke as they are hit. And it appears that the only keystrokes being checked are the ones emanating from the userid and pass input fields.

So, we’ve got a dll that identifies Urls of banks and other financial institutions and, after parsing and identifying an “interesting” Url, then constructs an event sink attached to very specific fields within the browser’s web page — namely, userid and password input fields. This ActiveX component will log these keystrokes and send them off the system. The component calls “HttpSendRequestA” to send off the banking usernames and passwords it just collected from these fields. I think that we’ve found an interesting piece of malware, quite possibly a password stealer for banking websites. We’ll add more technical detail to this post as time permits.
It helps to be able to dump this file and modify it for static analysis.