A word of warning… Lots of screenshots in this post.

Update 10/05/2015: I’ve updated the article with more information about some of the commands used in order to help out people who aren’t familiar with Volatility.

When hunting a piece of malware it can be very interesting to have a poke through the memory of an infected system. By obtaining a snapshot of the memory (RAM) of a running, infected system you can discover a whole host of interesting information.

There are a few ways to obtain a memory dump. I already had one generated by Cuckoo of the VirtualBox VM when I ran the automated analysis of this particular malware, but you may also be able to generate a memory dump of a running physical machine.

Once you have a memory image, the Volatility Framework is very, very useful to analyse the memory of the machine.

So from monitoring the network and gaining a packet capture from the test machine, we know that it was trying to contact a domain. Although the domain is no longer valid by the time I got to analyse this malware, we still might be able to learn something.

YARA is a much, much more powerful than what I use it for in this article, but the yarascan module in Volatility is great to perform pattern matching – even if it’s a simple string – so we can useyarascan to perform a search for the URL and see if it turns up in memory somewhere:

Here we can see that the URL exists once in svchost.exe and numerous times in explorer.exe.

To get an idea of what was happening on the system we can pull out a list of processes that where running at the time. There are several commands to list processes – pslist / pstree,  psscan and psxview (Which can help you to locate hidden processes).

All do slightly different things, so check your Volatility documentation for further explanation.

In this instance I have used the psscan command:

Nothing immediately suspicious there though – apart from cmd.exe, which has exited and there isn’t much we can see about what it was doing.

We can search for network connections in the memory image. This is possible with plugins builtin to Volatility. You can use one of these commands, depending on your memory image:

Windows XP:

• connections
• connscan
• sockscan

Windows 7 / Vista / Server 2008:

• netscan

Further information may be found under the Networking section of Volatility’s command reference.

Unfortunately due to the malware domain no longer being valid we don’t see much of interest.

However scanning for open network sockets reveals that explorer.exe has opened up some listening sockets at around the same time the malware was executed:

Volatility has a great plugin called malfind, which will search for injected code in user memory based on characteristics such as VAD tag and page permissions.

Lets run malfind against explorer.exe and see if anything shows up:

Interesting. Looks like we may have some PE code (note the MZ magic number of a PE header) which has been injected into explorer.exe.

Using malfind we can extract and dump that PE file to disk for further analysis. Throwing the extract at VirusTotal suggests that we have a sample of the Rovnix Banking Trojan.

Anyway, now that we have a copy of the unpacked / injected malware we may be able to find out some more interesting info about the nature of the malware.  Extracting the strings can be a good way to do this.

You can use the strings command in linux to find printable strings within a binary file.

First thing I notice in the extracted strings is there are references to several virtualisation technologies – This is generally used by malware to employ evasion techniques and execute differently (or not execute at all) if they detect that they are being studied inside a VM:

Within the malware is plenty of references to Internet-related activities, including references to popular web browsers.

During  analysis of this particular piece of malware you will probably notice a batch script is created during execution. We can actually see the contents of the batch file in the extracted executable here:

Hmmm…

At this stage we’re just looking at the extracted executable. We may be able to discover more by dumping and examining all the VAD (Virtual Address Descriptor) code segments of the infected process.

The vaddump plugin in Volatility can do this.

Again looking through the strings, looks like we may have a list of the possible C2 domains (You can see dialerrorbodyorig.org in there as well):

We can also see in here a prepared HTTP request – perhaps this is what we would see in our network traffic if the domain was valid?

To test this theory, I created an entry on the local DNS server to respond to that address with an IP Address to simulate a valid response. Sure enough, a GET request is made to the specified IP address.

Note that the parameters may be different, as this is another execution of the malware and chances are some of the parameters and filenames are randomised.

Quite often malware will gain persistence by installing itself as a startup item. Usually these entries are easy to spot by eye as they use randomised file names.

We can extract the memory locations of the registry hives then use those to open the start keys and see if there is anything there.

This can be done by looking at the output of the hivelist command, then passing the memory offset to the printkey command

Opening the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key reveals that we have an entry containing the malware:

Running filescan shows that it was recently open, though looks like there are no open file handles which may mean the file has already been closed:

In this case the malware may execute, unpack itself and inject into explorer.exe then terminate.

One last thing, according to searches of Rovnix it contains key logging capabilities, we can use Volatility to search for indicators of keyloggers on the system by searching for message hooks which probably shouldn’t be there.

Use the messagehooks plugin to scan for hooks that shouldn’t be there.

Looks like explorer.exe may be intercepting all keyboard messages:

That’s all for now, though there is much more that can be achieved through memory analysis. At least having extracted the unpacked DLL from memory allows us to further analyse and disassemble the DLL.

As usual, feel free to contact me with any feedback.