In association with heise online


Finally, I would like to take a closer look at the memory area the hooks point to. To do so, I use the Volatility function volshell. It displays select content from the memory dump either disassembled or as a hex/ASCII dump. I use cc to set the "current context" to process ID 1372 for Explorer.exe and then have dis display the code for the function offset of TranslateMessage.


As apihooks already found, there is a JMP command there to the address 0xEA85879. The disassembly here shows the typical function prologue

	Push EBP,

For the time being, I'm not going to bother with a closer analysis of what is happening here; instead, I want to check the surrounding area. That's where all of the JMPs are headed. The command db shows me the memory content at the address 0xEA80000 in the Hex/ASCII view. I quickly find a typical PE file header, including the characteristic "This program cannot be run in DOS mode." This is the smoking gun; it proves that a complete program image has indeed been injected into the Explorer process.

It seems pretty clear now that malicious code has been introduced into the system, but while I am at it I'd like to find out a bit more about the unwelcome guest. To do so, I use yet another plug-in function called malfind, which sifts through a process's entire memory range on the lookout for embedded code.

Basically, malfind works its way along the data structures for memory management, the Virtual Address Descriptors (VADs) for a process, and analyses their properties. Regular libraries in the address space for a process are labelled _MMVAD or _MMVAD_LONG, whereas the VADs for memory injected via VirtualAllocEx/WriteProcessMemory has the label _MMVAD_SHORT. And if part of the memory is labelled as executable with PAGE_EXECUTE_READWRITE, you have found a good starting point for further analysis.

This is where we start using the open source YARA project, which identifies malicious software based on characteristic strings and byte sequences. malfind can switch on YARA directly; specifically for this purpose, a number of malware analysts (myself included) use malware.yara, which I applied to the hijacked Explorer process via:

malfind -D \dump-files -Y malware.yara

And YARA comes up with the goods:


Some of the code fragments kept in \dump-files are immediately identified as an online banking spy, specifically as a version of the widespread SpyEye trojan.

Zoom These Yara rules identify SpyEye.

Now, the cat is out of the bag. But, I would still like to complete the puzzle. To find the source of the problem, I use Mark Russinovich's command-line tool strings to look for the string "cleansweep" in the dump-files directory. In addition to the aforementioned "cleansweep.exe," I also find a reference to "config.bin," which is probably where specific details can be found about which bank servers are sniffed from which form fields.

A string search for "http://" reveals a couple of URLs pointing to PHP sites. These could be the C&C servers.


nslookup rounds off the picture and confirms my suspicion that the server names and actually belong to the IP addresses that Volatility showed me at the beginning of my investigation. Wolfgang has been looking over my shoulder the whole time. He initially doubted that all of this was really related to his case of online banking fraud, but when I also show him that the malware tracking sites and agree that his PC has been in close contact the entire time with C&C servers for the popular online banking trojan SpyEye, he is finally convinced.

Normally, I recommend that infected systems be completely reinstalled; after all, you never know what a trojan has brought along. But after this quite comprehensive analysis, I am fairly certain that I would have noticed if it had caused any other damage. So in this exceptional case, I let Wolfgang talk me into disinfecting his Windows. I boot his PC from a special Windows boot CD and first delete the RUN key from the registry. Then, I remove the two files cleansweep.exe and config.bin.

Now that SpyEye has been removed, I boot the system and check it with The H's Update-Check to make sure that Windows and the most common applications are up to date. The operating system patches and browsers are, but both the Java runtime environment (GRE) and Adobe Reader are completely outdated. That's probably how SpyEye got in to begin with. After all, security holes in these applications are regularly exploited in order to infect systems. So I update these two programs.

Finally, I tell Wolfgang he should stop using the relatively unsafe iTAN lists and switch instead to one of the basically safe chip card methods that almost all banks now offer. I also tell him he should do his online banking with a special boot CD; many are available from AV software authors. We say goodbye, and I switch off my cell phone right away just to be safe: the weekend!

About CSI:Internet


In our "Crime Scene Investigation:Internet" series, experts examine suspicious files using every trick in the book. Watch over their shoulders as they track down malware – because all this really could have happened. All the malware samples shown in CSI:Internet have been used in real attacks and have been analysed using methods including those described. The accompanying narratives are inspired by real incidents, and only the names of those involved have been invented.

The expert for this series two episode three is Frank Boldewin; he is an IT security architect at GAD eG in Münster, Germany. In his scarce spare time, he analyses new rootkit and trojan techniques and publishes tools and white papers on these issues on his website

The second series of "CSI:Internet" was originally published in c't magazine starting with issue 15/2011. For links to articles in the first series please refer to our CSI:Internet HQ page.

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit