Reference no: EM132718051

M5A1 Hands-On Lab: Memory Dumping

In this lab, we'll analyze a memory image dumped from a live system using the open source Volatility tool.

Note in the display above that I renamed the volatility executable (volatility-2.3.1.standalone.exe) to volatility.exe. This is just for convenience, and I will use volatility.exe going forward.
The basic structure of a Volatility command is:
volatility.exe -f [memory image] [plugin]
For example, to get basic information about the memory image, try the imageinfo plugin, like this:
volatility.exe -f zeus.vmem imageinfo

The suggested profile is important. Since different operting systems use memory differently, Volatility's tools care which operating system created the image. In future commands, we'll provide the profile for Volatility. This image (zeus.vmem) was captured from a virtual machine with the Zeus malware running. Normally, we capture memory in one of two ways:
(1) If the system is a virtual machine, simply pause the VM and copy the vmem or similar file (all virtual machines environments keep the memory as a file).
(2) If the system is bare metal (i.e., not a VM), then use a tool like FastDump or Memoryze (there's a short list of good tools

In extreme cases, the memory chip itself can be accessed on the board or removed and imaged. This is possible but rarely necessary in practice. Note that in method two above, the acquisition tool is loaded in memory, so the image is not "pure" in the strictest sense. Generally this is not an issue, but lifting the machine into a VM or using direct physical access can be used if necessary.
For the remainder of this lab, you will be guided to run certain plugins and answer questions based on the output. For these commands, the general form is:
volatility.exe -f zeus.vmem --profile= WinXPSP2x86 [plugin]
An easy way to save your output is to write the console output to a file:
volatility.exe -f zeus.vmem --profile= WinXPSP2x86 [plugin] >> out.txt
The >> means append, so you can keep using the same file. Note that you won't see the output with this method. A DOS port of the Unix tee command is a better option if you're so inclined. For the lab, simply use what works for you, but I recommend recording your output so you can refer to it as you answer the questions.
Run the pslist plugin as follows:
volatility.exe -f zeus.vmem --profile=WinXPSP2x86 pslist >> out.txt
• What does the pslist plugin do?

In Volatility a plugin acts as a means of requesting data from the user interface (Volatility, n.d.). It then uses it to carry out a specific form of analysis. The pslist lists the processes present the system through a memory image. According to Volatility (n.d.) the following parameters are in the pslist:
• Context (contextInterface)
• Config_path (str)
• Progress_callback (optional [callable][float,str], none]])
• How many "items" are found by pslist?
According to Code.google.com (n.d.) the pslist shows the following 7 items:
• The offset
• Process name
• Process ID
• Parent process ID
• Number or threads
• Number of handles
• Date/time when process started and exited.

Q3: What is the process ID of winlogon.exe?
Run the malfind plugin on the winlogon process, using the -p [Process ID] flag to specify the winlogon process:
volatility.exe -f zeus.vmem --profile=WinXPSP2x86 -p [PID] malfind >> out.txt
You should get two hits:

The malfind plugin contains a collection of rules for detecting known malware patterns. In this case, the two hits are for different reasons. The first hit contains machine code instructions that fit the pattern of API "trampoline" hooks. The second hit looks like executable code that is not registered in the Process Environment Block (PEB). Note that the disassembly in the second hit is meaningless - this data is just the header of an executable file, which does not actually contain machine code. In short, this looks like code was injected into the winlogon process (hit #2), and code was added to the winlogon process to cause the injected code to run (hit #1).
Further analysis of the winlogon process might be useful, so we can use volatility to dump the process from memory. First, create a directory to hold the output:
mkdir dump
Then run the procexedump plugin
volatility.exe -f zeus.vmem --profile=WinXPSP2x86 -p [PID] -D dump procexedump
You should now have an executable file in the dump directory.

Q4: What is the size in bytes and name of the file dumped by Volatility?
Delete the file:
del [filename]
Volatility also has an interactive mode:
volatility.exe -f zeus.vmem --profile=WinXPSP2x86 volshell
Type "ps()" without the quotes at the >>> prompt.

Q5: How many processes are listed?

Q6: Does the PID for winlogon match the information you gathered previously? If not, what is the PID now?
Ctrl-z will exit volshell.
Volatility supports YARA[1] scans. YARA supports searching a sample for strings and binary data and combinations of strings and binary data, so we can use it to search for text patterns, but also to search for binary (machine code) patterns. Collections of YARA rules are available publicly for download, but we're going to conduct a specific custom YARA scan.
Recall the malfind output previously. The winlogon process had a sequence of machine instructions that included several repetitions of:
0x1600014 8bff MOV EDI, EDI
0x1600016 55 PUSH EBP
0x1600017 8bec MOV EBP, ESP
0x1600019 e9ef17c175 JMP 0x7721180d
Let's run a YARA scan for that sequence.
volatility.exe -f zeus.vmem --profile=WinXPSP2x86 -p 1724 yarascan --yara-rules="{8b ff 55 8b ec e9}"
Notice that our YARA search string is the hex version of the machine instructions, and we're just using the first byte (the opcode) of the JMP instruction since its arguments are different for each JMP call.

Q7: How many hits did you get?

Q8: Copy the 3rd hit for the answer to this question.
Volatility has many different plugins and an active development community. Anyone can submit a Volatility plugin, which means: (a) lots of functionality gets added, (b) the code is open source so you can modify it yourself, and (c) you get a range of quality.

1While this memory image contains real malware, the sample itself is not dangerous unless loaded as active memory, for example in a virtual machine. Processing the image, in particular with Volatility, does not pose any risk, although Antivirus tools could quarantine the file since it contains malware strings. If this happens, you will have to temporarily disable AV, but be sure to re-enable AV when you're done with the lab.