Tags

, , , , , , , ,

It took me a couple of days to figure this out, as extracting a malware executable using Volatility is trickier than I expected.
When a program is run, its executable is copied into system memory and a data structure is built around it. This data structure contains the runtime data, pointers to DLLs it’s using, pointers to other system resources, files loaded, CPU register states, a stack and other stuff. Basically physical memory could be described as the data structures of all programs and resources that are active, many of which are also interacting with each other. Volatility should therefore enable us to not only find the malicious process, but also extract its executable for further analysis. It’s important because often the only method of getting a de-obfuscated malware sample is by extracting it from memory.

The Environment
My initial steps were about getting a feel for the target machine, determine what programs were running, what was displayed on the desktop, and the network connections that were established when the memory capture was made. The following command reveals the target machine’s operating system and when the capture was taken:
$python vol.py -f ~/zeus.vmem imageinfo

zeus-imageinfo

So we can see we’re dealing with a Microsoft Windows XP SP3 operating system with an x86 processor architecture. We also get the time and date when the memory was captured, although it should be noted this, along with the times in the system logs, are relative. They’re not necessarily correct.

The following command generates a pseudo-screenshot of the desktop when the capture was made, which sometimes reveals what windows were open and their titles.
$python vol.py -f ~/zeus.vmem screenshot --dump-dir ~/zeusfiles

zeus-screenshot

Out of this we don’t get much, other than it appears Windows Explorer was likely opened, and the desktop clock showed 3:17 PM, which means the clock was offset by 4 hours.

Network Connections and Processes
The ‘connscan‘ feature should reveal the network connections that were made by the machine, the local and remote IP addresses, and the processes that were communicating with the remote IP addresses:
$python vol.py -f ~/zeus.vmem connscan

zeus-connscan

Remember that IP addresses are often re-assigned, so if they were associated with malware or C&C servers when the capture was made, that’s not necessarily the case now.
A search on the addresses still turned up a load of pages on the Zeus Trojan and quite a few blog posts by others analysing it using the Volatility Framework.

But let’s say it’s unknown whether the capture was from a machine that was attempting to contact a C&C server having just booted up: the next step was to determine the program PID 856 was assigned to:
$python vol.py -f ~/zeus.vmem psxview

zeus-psxview

Interestingly, the PID belonged to svchost.exe, which, according to the Microsoft Support page, is supposed to load services defined by the registry on startup. Why was it connecting to the external IP addresses? Perhaps it would be a good idea to extract svchost.exe at this point:
$python vol.py -f ~/zeus.vmem dumpfiles -r svchost.exe --dump-dir ~/zeusfiles

I uploaded the executable to VirusTotal, and the results came back clean. This wasn’t the malware executable I was looking for, so instead I dumped the process’ handles to see how it was interacting with other system components:
$python vol.py -f ~/zeus.vmem handles -p 856 >> ~/zeusfiles/pid-856-handles.txt

The Registry
There weren’t handles to other executables, but there were plenty to threads and the Registry. The following entry caught my attention:

zeus-handles

Making a note of ‘AVIRA_2108’, I decided to concentrate on the Registry entries, as this is what svchosts.exe is reading from or modifying. In order to do this with Volatility, the system’s profile should be defined, in this case ‘WinXPSP3x86‘, and the ‘hivelist‘ function is used to obtain the physical memory offsets for the Registry keys.
$python vol.py -f ~/zeus.vmem –profile=WinXPSP3x86 hivelist

zeus-hivelist

For example, if we were interested in the SECURITY part of the Registry, the command would be something like:
$python vol.py -f ~/zeus.vmem –profile=WinXPSP3x86 hivedump -o 0xe1537b60

I couldn’t find anything that stood out immediately, but it might be something I’d return to.

Getting the Malware
It was at this point that I decided to cheat a little, dumping the strings from the memory capture to another file, then using grep to search for ‘AVIRA’ and ‘Zeus’. Doing this meant I could try different Volatility functions and search the capture file directly as I went along.
It turns out the malware executable actually is called ‘Zeus_binary‘ and the grep output gives its file path on the hard disk. Using grep on the IP addresses listed earlier, we also get the full URL:
http://193.104.41.75/cbd/75.bro

I also managed to extract the following files, after digging up information from Microsoft on ‘AVIRA_2108’:
* sdra64.exe
* explorer.exe

Other files were listed by Microsoft, but sdra64.exe and explorer.exe were the ones I’m interested in. I have quite a collection of extracted files, an examination of which I might cover in a later post. For now I uploaded sdra64.exe to VirusTotal, and confirmed it was indeed the Zeus malware.
Now you might think that consulting Microsoft’s site misses the point of the challenge here. Yes, I’ve cut a few corners, but I’m only doing static analysis whereas Microsoft has the resources to actually find, download, execute and observe the malware. Much of the information could only come from doing live analysis.

Anyway, according to Microsoft, Zeus injects malicious code into the explorer.exe process (the reason I extracted it also), which should mean the version I’ve extracted would reveal something about how Zeus functioned as a banking Trojan with a little static analysis of the files.