I have recently been involved in performing forensic analysis on systems which are compromised with malware. Once a system is compromised by malicious code, there are a multitude of indicators of compromise (IOC) ranging from unusual network traffic patterns as reported by the intrusion detection and prevention systems (IDS/IPS) to the system behaving erratically which in some cases prompts the affected user to complain about it. Following the established protocols, an image of the system’s hard disk and physical memory must be taken using imaging tools. FTK Imager Lite is one of the many tools that are available to take image dumps. For volatile memory imaging, I personally prefer to use FDPro from HBGary. The free version of this memory imaging software can be downloaded from here.
An analysis of the memory image of a workstation provides useful information about the malware that has infected a system. It is an effective way to analyze the behavior of malware while it is running on the system. Such analysis provides information about DLL injections, open connections to malicious IPs and domain, running processes in the system at the time of infection, etc. In the following examples, I downloaded a sample VM memory image of a computer which is known to be infected with Zeus malware. I am using Backtrack 5 with Volatility to do basic memory image analysis.
First thing we need to find out is what operating system this memory image belongs to. In order to do that I need to run the following command using Volatility:
./vol.py –f ~/Desktop/zeus.vmem imageinfo
As it is clear from the result of this command, the image came from Windows XP machine with SP 2. There is a number of other information which also gets produced as a result of running this command, but for the sake of this blog we are only concern with the profile information which is showing as “WinXPSP3x86”.
Now that we know the profile of the machine, the next step is to find out how many processes were running on the system at the time of capturing the memory image. To do that we need to run the following command:
./vol.py –f ~/Desktop/zeus.mem pslist
Looking at the resultant list of processes, nothing seems to look out of the ordinary. All running processes seem to be legitimate, but we know that malwares are designed to be intelligent enough to hide themselves under legitimate processes. To accommodate that we can run another Volatility command which will produce results by comparing and displaying various methods to view the list of running processes in a system.
./vol.py –f ~/Desktop/zeus.mem psxview
If any of the listed methods (pslist, psscan, thrdproc, pspcdid, csrss) shows any process as false, it is a strong indication that a process is trying to hide itself.
Since we know that malware mostly have a command and control structure, once they infect a system they need to connect back to the command center. Knowing that, we now need to look at the network connections established by the malware. We can find out about any established connections by using Volatility on our memory image:
./vol.py –f ~/Desktop/zeus.mem connscan
The result of the “connscan” command shows that 2 connections were established by the infected system to a remote IP address “22.214.171.124” on port “80”. Another critical piece of information that this command revealed is the process ID “856” under the PID column, which shows the process that established the remote connection. Look back at our screenshots for psscan and psxview, we now know that PID 856 belongs to the “svchost.exe” process which is a clear indication that the rogue process is hiding itself under “svchost.exe”. To further our investigation, we need to find as much information as we can about the IP address that the system has established the connection with. A quick search on cent.robtex.com reveals that this IP address has already been black listed on the Internet.
We also wanted to know the origin of the IP address so we used an online IP geolocation service and found out that the IP is located in Moldova.
All of the above is great, but now we need to step a little further and investigate what else this malware has done to the system, such as what files it has created and if any code has been injected. We need to run the “malfind” command and dump the output into a directory.
./vol.py –f ~/Desktop/zeus.mem malfind –dump-dir ~Desktop/malfind |more
The output of this command shows various PIDs that were infected; we can also see PID ID 856 which we discovered earlier during our network connection investigation. The output of the “malfind” command resulted in a large number of individual dump files of the various processes that were infected by the malware.
To verify infected processes, we can upload them to an online virus analysis service. I uploaded one of the process dumps from the “malfind’ command to www.virustotal.com and it came back with the following analysis:
Virustotal shows that 27/44 of virus scanners detected and confirmed that the uploaded process dump is the Zbot/Zeus virus. The above process is a demonstration of only a basic analysis of a memory image for malware. Volatility provides a ton of other features that can help a user perform advanced memory analysis as well as recover sensitive information from the memory, such as passwords and in certain cases cryptography keys.
References: https://www.volatilesystems.com/default/volatility http://code.google.com/p/volatility/wiki/CommandReference http://code.google.com/p/volatility/wiki/SampleMemoryImages