If Pliny The Elder had lived in our times and worked in malware analysis, his proverb most likely would have looked like the title of this post. As malware evolves, the techniques used to hide it within the operating system constantly become more sophisticated. It can be hidden deep in the hard disk or hidden in plain sight in the hope that it will not be discovered, or it can be disguised. Ultimately, however, all malware needs to be run.
Therefore, it will sooner or later need to leave the "safety" offered by the hard disk and its hundreds of thousands of files and cross over into the open space of RAM memory, populated by the processes running on our machine at any particular time.
Finding malware in the RAM is what we attempt to do when we run dynamic malware analysis. This enables us (if the malware does not prevent this by using advanced evasive techniques) to see what processes and files are related to the malware, and in what ways. It is true that hunting down malware in the RAM is no simple task, but if we are well equipped, the tools in our arsenal will lend us a hand, so we won't have to trust only our intuition and good luck.
If you're going to search for malware in the memory, the first thing you have to do is to create a copy of what is in the computer's RAM at that moment, in order to obtain an unpacked copy of it, if possible. If the computer is working, there are many tools we can use to make this memory dump. One option isDumpit, developed by MoonSols. When this is run by a user with administrator privileges on a USB flash drive with greater capacity than the computer's RAM, it allows an image of the RAM to be obtained that we can work with later. This process is explained in greater detail in our Evidence gathering in Windows guide, where you will also find other tools that are often used to carry out this process.
If we are working with the most common hypervisors, in order to carry out the analysis it is sufficient to create VMware .vmem files (which contain a full RAM dump), VirtualBox .sav files (with a partial RAM dump), Parallels .mem files or Hyper-V .bin files.
Once we have obtained the memory dump, we will use other tools to search for traces of malware. Perhaps the first step we should take would be analysing the capture with Mandiant's Redline. This tool, which features a graphical interface, runs an automatic analysis which, although it may not be sufficient in itself, will put us on the trail.
But the queen of memory analysis tools has a name: Volatility. This command-line tool is essential for anybody who is carrying out dynamic analysis. A multitude of plugins and documentation on Volatility make it a very complete and truly powerful environment. It focuses on Windows machines, but also supports Linux and Mac.
In order to illustrate this tool in the rest of the article, we downloaded a memory dump of a machine infected with Zeus, the famous banking Trojan. You might say that this is cheating, as we already know what malware we are looking for. You would be right, but we took the liberty all the same. We used the standalone version 2.4 of Volatility, which does not require the installation of Python. Other versions of Volatility work similarly.
The first thing we have to do, if we do not already know it, is to see what kind of machine the memory was extracted from. Volatility does this with the imageinfo plugin.
The results generated by this plugin include some important fields. The first, Profile, will be necessary as an input parameter, using the option --profile for the other plugins we are going to use. Another important result generated by this command is the value of KDBG, a structure maintained by the Windows debugging kernel. It contains a list of running processes and loaded kernel modules. Its value will be used by other plugins to find and analyse these lists. If you need more information about the KDGB, the plugin kdgbscan will provide this. This will need to be run if the profile suggested by imageinfo does not generate results in other plugins such as pslist.
This plugin, pslist, is the next command to be run. It generates a list of the processes running on the system. Some malware can be directly found in this way, camouflaged among other system processes with similar names (some use the name scvhost to hide among legitimate svchost processes).
Nothing odd at first sight. Let's keep looking... the plugin pstree shows the same processes laid out as a tree. This is useful to identify processes that do not boot as they should.
There is nothing concerning here, either. Let's have a look at the machine's connections, using the connscan plugin.
Something interesting is going on here. Process 856 (if you look for it in the pslist capture you will see that it is a svchost process) has made outgoing connections. Svchost is a process that loads specific services when Windows starts up, so this connection may not be legitimate. An Internet search for this address links it directly to a C&C server of the banking Trojan Zeus. Logically, the memory capture is old and the IP address will by now have been reassigned, but at least this puts us on the right track.
To confirm our suspicions, let's search for the mutex that is characteristic of Zeus, usually named _AVIRA_ followed by a number, typically 2101, 2110, 2108, 2109 or 21099. We will use the plugins handles or mutantscan to find this mutex.
Memory analysis can be a key element in incident management when it comes to identifying the source and type of an infection. Once we have identified these, it is possible to obtain the executable that initiated the infection. With this, reverse engineering experts will be able to dissect the malware, enabling us to generate the necessary IOCs to avoid future infections.