After this round of foreplay, things start to get interesting. For the further analysis of the memory dump, I use the powerful open source Volatility tool. Written entirely in Python, this framework extracts useful information from memory dumps, which are not readable by people.
First, Volatility analyses the Kernel Processor Control Region (KPCR), which is always at the address
0xffdff000 on Windows XP and serves the useful purpose of pointing to the Windows kernel's other data structures. From there, the tool swings over to the structures that are actually interesting, such as the list of active processes, which Windows has to permanently store in the RAM.
Unlike classic forensics, the wonderful thing about this approach is that you are looking at a truly live system and can study volatile information, such as current network connections. And unlike other ways of investigating live systems, you do not have to rely on a system that may be compromised and is only showing you what it wants you to see. By analysing memory with Volatility, I have taken down quite a number of rootkits. Let's see what we find on Wolfgang's computer.
To get a rough overview, I first use the Volatility command
pslist to display a list of all processes that were active when the snapshot was taken.
That seems to look pretty normal; at first glance, at least, there are no conspicuous process names. But that would also have been too easy. Let's keep going with the program. The list of open network connections via
connscan2 looks a lot more promising.
Two active connections are listed, one to the IP address 18.104.22.168 on port 80, and the other to 22.214.171.124 on port 8853. According to the process list, the process IDs 1372 and 616 do not belong to a browser process, such as
Firefox.exe, but rather to
Winlogon.exe. What are these system processes doing on the internet?
It looks as though I may have found something. It wouldn't be the first time that these processes get infected so that their rights can be exploited in order to have a chat with a command and control (C&C) server online without being noticed by the firewall.
Let's see what the registry says. Simple userland trojans normally leave fingerprints here as autorun keys. Windows always keeps an updated copy of the registry in memory, and Volatility will help me analyse it. This process is not as easy as with graphical Windows tools, such as Autoruns, so I will have to make some manual selections.
The registry is spread across numerous files called "hives." The current user's registry branch,
HKEY Current User (HKCU), is located in the hidden file NTUSER.dat of the home directory under
\Documents and Settings\. There are two more important branches:
HKEY Local Machine (HKLM) and the sub-branch for software in
\Windows\system32\config. But first, I need to have
hivelist display where Windows put the files into memory.
HKCU at the virtual address
0xe1479b60. With this information, I can now use
printkey to display individual keys and work through the autorun list. After a few dead ends, I notice something suspicious about
system32\ looks as though it is where it belongs. But
cleansweep.exe has no business being there. While I seem to remember a legitimate program of that name, it certainly would not copy itself into the directory C:\cleansweep.exe\, and Wolfgang confirms that he did not install any such program.
It seems that poor old Wolfgang has an online banking trojan on this computer after all, so I will not be able to absolve him of his guilt as a forensic expert friend. Let's see what else I can find. In general, such malicious programs control other applications by redirecting certain calls from Windows functions to their own code. Called "hooking," this tactic can be used, for example, by malware to hide its own filenames from a directory list.
Now, it's time for the Volatility plug-in malware.py, which was originally developed for the Malware Analyst's Cookbook – hereby highly recommended for any modern computer forensics library. As expected, its function
apihooks looks at the Explorer process with the PID 1372 and finds a whole bunch of in-line hooks whose function has been overwritten by a jump command into the
The label "unknown" in the last column indicates that this address range is not even assigned to a DLL; it goes nowhere. The winlogon process with PID 616 has exactly the same hooks.
Because I'm not doing this for the first time, I know what needs to be done. The malicious program first used such functions as
VirtualAllocEx() to reserve memory in the context of the Explorer process and then used
WriteProcessMemory to write its own code in. Since the Phrack article entitled NTIllusion:A portable Win32 userland rootkit, this has been a standard way of hijacking other processes to use them for your own purposes – such as calling home without the firewall knowing.
The list of kidnapped function calls shows that I am indeed dealing with malicious code that uses rootkit functions.
NtVdmControl can be used to display files. If you control these functions, you decide which files users and the virus scanner get to see. The
NtEnumerateValueKey entry shows that my approach to memory analysis was not cracking a nut with a sledgehammer by any means. I'd be willing to bet that I would not have found the suspicious registry key or the network connections on a running Windows system by using conventional analysis tools like autoruns, etc.
The hook is often used for the function
TranslateMessage to catch and record user input. The trojan uses hooks on such socket functions as
InternetWriteFile to control internet traffic and can, for instance, capture and manipulate data sent. In other words, the online banking trojan would be quite useful for fraudulent activity.