Recently we investigated a malware encountered in the wild. It turned out to be a recently released variant of the Banker/InfoStealer/Bancos/Zbot family (identified as PWS-Banker.gen.bw by McAfee, as Infostealer.Banker.C by Symantec, as Trojan-Spy.Win32.Bancos.aam by Kaspersky and as Mal/Zbot-A by Sophos). Initial analysis indicated that this is a descendent of the malware analyzed by SecureScience and Michael Ligh (http://ip.securescience.net/advisories/pubMalwareCaseStudy.pdf) – in fact, quite possibly a variant of the new strand identified in section 18 of that paper. The paper proved to be very useful, especially the description of how to decrypt the malware collected data.
The malware we analyzed displayed two interesting techniques for credential collection, which are not common among malwares:
- WinInet interception
- In-process key-logging
WinInet interception – as explained in the above mentioned paper, the malware makes sure it is injected into practically all user space processes. When the malware copy detects that it is injected into an Internet Explorer process, the malware appears to modify IAT entries for the HttpSendRequest family of functions within that process. As such, each time Internet Explorer requests a URL, it eventually calls HttpSendRequest, and control is transferred to the malware code. The malware collects POST request data (the POST request body, which contains credentials in case of a login submission) and periodically sends it (encrypted) via its own HTTP request to a drop site. This is in contrast to many flavors of malware which install themselves as an Internet Explorer add-on (BHO), and intercept credential submission by subscribing to the submit/navigate event.
In-process keylogging – (this is not explicitly mentioned in the paper, and may possibly indicate that it is a later addition) it appears that the malware code inside an Internet Explorer process also patches the GetMessage/PeekMessage family of functions. This enables the malware to monitor all incoming messages into Internet Explorer. Particularly, it seems that the malware code logs keystrokes in this manner. The keystrokes are added to a 100 byte buffer. Each periodic transmission to the drop site contains the current contents of this buffer. This is in contrast to “traditional” key-logging using the GetAsyncKeyState and similar functions, and the Windows hooks methods.
The obvious question is why does this malware employ non-standard techniques? We suggest two answers:
- Enhanced stealth: by not using a BHO (which is visible through Internet Explorer’s Tools->Manage Add Ons GUI), the malware is less detectable by the user. Using a BHO also incurs having a malware DLL permanently on disk, which makes the malware more vulnerable to anti-malware products. Likewise, by using non-standard keylogging techniques, the malware can avoid detection by anti-spyware/malware products that monitor attempts to use the traditional keylogging techniques. And just like a BHO, traditional anti-keylogging techniques require a DLL (or a process) to be permanently available.
- Enhanced usability: unlike traditional key-logging techniques, an in-process (or more precisely, an in-Internet Explorer) key-logger can easily and accurately determine which keystrokes belong to the browser. It is not impossible to obtain this information in traditional key-logging methods, yet it is more complicated and less reliable than the in-process technique.