Lead Image © raptorcaptor, 123RF.com

Malware Analysis

Forensic Analysis with Redline and Volatility

Article from ADMIN 21/2014

By David J. Dodd

We show you how to dig deep to find hidden and covert processes, clandestine communications, and signs of misconduct on your network.

In a previous article [1], I described how to obtain a memory image from a Windows computer that would allow forensic analysis. I briefly discussed using F-Response TACTICAL [2] to get the memory image, and then Volatility [3] and Mandiant Redline [4] for further investigation. In this paper, I dive more deeply into Redline and Volatility.

To begin, I review a raw memory dump of a known malware variant (see the "Malware Image" box) with Mandiant Redline. After firing up Redline, I chose By Analyzing a Saved Memory File under Analyze Data and browsed to the location of the memory image. Next, I edited my script to include Strings for both Process Listing and Driver Enumeration. Finally, I chose a destination to store the output for future analysis and to analyze memory dumps.

Malware Image

The malware image I am using in this article is a variant found by the Palo Alto PA-5000 series firewall [5] on a Windows box in our network, which was sent for further investigation to a sandbox that Palo Alto uses for such cases. Moments later, I received email telling me that malware was discovered by Palo Alto WildFire analysis [6].

WildFire identifies unknown malware, zero-day exploits, and advanced persistent threats by executing them directly in a scalable, cloud-based, virtual sandbox environment. The report, which goes into detail about what the malware has done, gave me a link to VirusTotal [7], used to score the executable for maliciousness, along with a PCAP file of network traffic generated by the malware. I was able to download the known malware variant and execute it on my closed test VM network for observation; then, I used both Volatility and Mandiant Redline to research the culprit.

Redline

As I explained in the previous article, I took two different memory dumps from a Windows XP system: one after I executed the malware infection, and another after I rebooted the system. In comparing the two images, I noticed some differences. Remember, malware usually tries to hide in plain sight, attempting to appear legitimate, or uses rootkit techniques to hide from the view of normal analysis tools.

After installing the malware and completing a reboot, Redline revealed three process names (jh, process ID [PID] 38533; svchost.exe, PID 1560; and WScript.exe, PID 1744). Process jh (PID 38533) was spawned by a parent process – [Not Available] (528) – with a start time of 1601-01-01 00:00:00Z (Figure 1). Double-clicking on the Process name (jh ) provides access to the detailed view.

Figure 1: Process jh PID 38533.

Choosing Hierarchical Processes in the Analysis Data panel showed that svchost.exe (PID 1560) was spawned by WScript.exe (PID 1744). Hierarchical Processes lists running processes in a tree format, showing which processes started other processes (Figure 2). If you take a look at the Process Metadata for jh in Figure 1, you'll see that it has an MRI Score of 61, as does svchost.exe (Figure 2, second column).

Figure 2: Hierarchical Processes.

The Malware Risk Index (MRI) score, which is accessed by double-clicking a process-related item to see its detailed view and selecting the MRI Report tab at the bottom of the window, ranges from 0 (less risky) to 100 (more risky). Because these two processes started after the malware installed, they are likely bad. When I compared the Start Time of svchost.exe (PID 1560) with other svchost processes (Figure 3), I saw that it appeared to have started about 30 minutes after the other svchost processes.

Figure 3: Comparing different running svchost processes.

The parent process of svchost.exe (PID 3028) is WScript.exe (PID 1736); this is discovered by looking at Hierarchical Processes. After clicking on WScript.exe (1736) , I discovered the user account that was logged on when the process was spawned and the full path of the process binary (Figure 4). Next, I clicked on the Handles tab located below and viewed the Handle Names; notice the Untrusted status in Figure 5. Using Redline to check for signed code may reveal suspicious executables.

Figure 4: Finding the user account and the full path of the process binary.

Figure 5: Viewing a process and its Handles.

To look for evidence of code injection, I chose Processes | Memory Sections located in the Analysis Data pane. This choice brings up memory pages for every process, although the particular malware I was investigating contained no injected memory sections that Redline could find.

Finally, I used Process | Strings to look for additional evidence by entering http:// , https:// , .exe , and the like. In Figure 6, I'm searching for any cmd.exe run by WScript.exe. Other interesting strings to enter in the search box would be common Windows system and network commands, such as finger, net use, netstat, and so on.

Figure 6: Using the Redline Strings output to look for additional evidence of malware.

Understanding normal activity is key when you start looking for badness. If you don't know what normal traffic activity looks like, you will be lost when trying to find said malware. One way is to better understand the operating system you are analyzing – in this case, Windows.

Understanding Windows process structure helps; for example, csrss.exe is created by an instance of smss.exe and will have two or more running instances. The start time is within seconds of boot time for the first two instances (Sessions 0 and 1). Start times for additional instances occur as new sessions are created, although often only Sessions 0 and 1 are created. (This information is available on the SANS DFIR poster [8].) Looking at Hierarchical Processes in Redline will reveal an instance of smss.exe that spawns csrss.exe.

Another interesting item to research is svchost.exe, which is used to run service DLLs and whose parent process, services.exe. Windows will run multiple instances of svchost.exe, each using a unique -k parameter for grouping similar services.

Malware authors often take advantage of the ubiquitous nature of svchost.exe and use it either directly, by installing the malware as a service in a legitimate instance of svchost.exe, or indirectly, by trying to blend in with legitimate instances, either by slightly misspelling the name (e.g., scvhost.exe) or by spelling it correctly but placing it in a directory other than System32.

On a default installations of Windows 7, all service executables and all service DLLs are signed by Microsoft. This information is also available on the SANS DFIR poster and would be very helpful to review.

After reviewing this memory image with Mandiant Redline, I found no smoking gun that definitively pointed to malware, so now I will look at an open source tool called Volatility.

Volatility

To begin, I go to the workstation that took the image off the Windows machine with the F-Response tool and open a terminal. After changing to the case files directory, I enter

$ python vol.py -f remote-system-memory11.img imageinfo

to get information about the image with imageinfo (Figure 7). The Suggested Profile(s) line in the output suggests parameters I can pass in to Volatility (with --profile=PROFILE); you may see more than one profile suggestion if profiles are closely related. I can figure out which one is most appropriate by checking the Image Type field, which is blank for Service Pack 0 and filled in for other Service Packs. To find the processes and DLLs, use

$ vol.py --profile=PROFILE -f FILE.img FORM

where PROFILE is one of the suggested profiles from the imageinfo output (here I'll use WinXPSP2x86), FILE is the memory image of interest (in this case, remote-system-memory11.img), and PROC takes on the values in Table 1; that is:

$ vol.py --profile=WinXPSP2x86 -f remote-system-memory11.img PROC

When using dlllist, look for strange DLLs that have been injected into legitimate processes and DLLs with suspicious-looking names. When used alone, this command produces a lot of output, so you can narrow down your search to a specific process with -p and the process ID, as in the last example of Table 1.

Figure 7: Running volatility for information about the memory image.

Table 1

Process Information Options

PROC	Output
`pslist`	Lists the processes of a system. It does not detect hidden or unlinked processes.
`pstree`	Views the process listing in tree form. Child processes are indicated using indentation and periods (Figure 8).
`psscan`	Enumerates processes using pool tag scanning. This can find a process that previously terminated (inactive) and processes that have been hidden or unlinked by a rootkit (Figure 9).
`dlllist`	Displays process-loaded DLLs and shows the command line used to start the process (including services) along with the DLL libraries for the process.
`dlllist -p 1764`	Displays process-loaded DLLs for PID 1764 `WScript.exe` (Figure 10).

Figure 8: pstree example. Notice the child processes indicated by indentation and periods.

Figure 9: psscan can find hidden processes.

Figure 10: Using dlllist to display DLLs for the process WScript.exe.

Volatility has many features organized by plugins and categories. These categories include image identification, processes and DLLs, process memory, kernel memory and objects, registry, crash dumps, hibernation, malware/rootkits, and networking, which I look at next.

Volatility Network Resources

To view active connections, use the connections command, or to find connection structures using pool tag scanning, use the connscan command:

$ vol.py --profile=WinXPSP2x86 -f remote-system-memory005.img connscan

Pool scanning is a technique used when a piece of memory is allocated in Windows with a special tag that corresponds to the driver or subsystem that allocates the memory. Often, you can find previous connections that have since been terminated. The connscan command only works with Windows XP and Windows 2003 Server.

In Figure 11, notice the two connections to 10.10.3.180. What would be trying to communicate on the network from the Windows XP box to an internal 10.10.3.180? I don't have anything with that IP address on this network, so I need to investigate PIDs 1792 and 132 further. Running psscan to enumerate processes does not show PID 1792, so that is a dead process; however, PID 132 shows up as svchost.exe. When I run pstree for more information, the indented list in Figure 12 shows parent and child processes.

Figure 11: Output of the connscan command.

Figure 12: The parent process of svchost.exe is wscript.exe, which is a child of explorer.exe.

Another plugin available in Volatility called malfind extracts injected DLLs, injected code, unpacker stubs, and API hook trampolines and scans for any ANSI string, Unicode string, regular expression, or byte sequence in processes or in kernel driver memory. The syntax for this plugin is

$ vol.py --profile=WinXPSP2x86 -f remote-system-memory005.img malfind-D memory/

which dumps all the processes with injected code in the directory called memory (Figure 13). The next step is to upload these .dmp files to VirusTotal to see if it can identify any known issues. The only suspect DMP file flagged by VirusTotal (Figure 14) was 0x370000.dmp, which is the F-Response tool used to extract the memory image. This is a false positive.