TryHackMe | Volatility
In this room, we will learn about the tool Volatility and its use in memory forensics and analysis. I will be using the machine provided in this room to work through and complete the task.
| Task 1: Intro
This task goes over how Volatility is a free memory forensics tool that was created and is managed by Volatility labs and is considered the gold standard for memory forensics in incident response.
| Task 2: Obtaining Memory Samples
We will now learn how memory samples are obtained with tools like Redline and FTK Imager and what is the most common memory format by answering the provided questions and reading the above content.
| Task 2.1 What memory format is the most common?
Answer: .raw
| Task 2.2 The Window’s system we’re looking to perform memory forensics on was turned off by mistake. What file contains a compressed memory image?
Answer: hiberfil.sys
| Task 2.3 How about if we wanted to perform memory forensics on a VMware-based virtual machine?
Answer: .vmem
| Task 3: Examining our Patient
In this task I will be examining a memory dump of a vm(Vitural Machine)as its indicated with .vmem extension with Volatility
| Task 3.1: First, let’s figure out what profile we need to use. Profiles determine how Volatility treats our memory image since every version of Windows is a little bit different. Let’s see our options now with the command `volatility -f MEMORY_FILE.raw imageinfo`
Answer: No answer is needed
| Task 3.2: Running the imageinfo command in Volatility will provide us with a number of profiles we can test with, however, only one will be correct. We can test these profiles using the pslist command, validating our profile selection by the sheer number of returned results. Do this now with the command `volatility -f MEMORY_FILE.raw — profile=PROFILE pslist`. What profile is correct for this memory image?
Answer: WinXPSP2x86
This command when paired with the right profile will show us a list of processes that were running at the time of the memory dump.
| Task 3.3: Take a look through the processes within our image. What is the PID(process ID)for the smss.exe process? If results are scrolling off-screen, try piping your output into less
Answer: 368
| Task 3.4: In addition to viewing active processes, we can also view active network connections at the time of image creation! Let’s do this now with the command `volatility -f MEMORY_FILE.raw — profile=PROFILE netscan`. Unfortunately, something not great is going to happen here due to the sheer age of the target operating system as the command netscan doesn’t support it.
Answer: No answer is needed
| Task 3.5: It’s fairly common for malware to attempt to hide itself and the process associated with it. That being said, we can view intentionally hidden processes via the command `psxview`. What process has only one ‘False’ listed?
Answer: csrss.exe
| Task 3.6: In addition to viewing hidden processes via psxview, we can also check this with a greater focus via the command ‘ldrmodules’. Three columns will appear here in the middle, InLoad, InInit, InMem. If any of these are false, that module has likely been injected which is a really bad thing. On a normal system the grep statement above should return no output. Which process has all three columns listed as ‘False’ (other than System)?
Answer: csrss.exe
I added | grep False to the command because this will only grab the result of the command which equals False instead of grabbing all the results that say True.
| Task 3.7: Processes aren’t the only area we’re concerned with when we’re examining a machine. Using the ‘apihooks’ command we can view unexpected patches in the standard system Dynamic-link libraries(DLLs). If we see an instance where Hooking module: <unknown> that’s really bad. This command will take a while to run, however, it will show you all of the extraneous code introduced by the malware.
Answer: No answer needed
| Task 3.8 Injected code can be a huge issue and is highly indicative of very very bad things. We can check for this with the command `malfind`. Using the full command `volatility -f MEMORY_FILE.raw — profile=PROFILE malfind -D <Destination Directory>` we can not only find this code, but also dump it to our specified directory. Let’s do this now! We’ll use this dump later for more analysis. How many files does this generate?
Answer: 12
I created a directory named code before hand to put results from this command there.
| Task 3.9: Last but certainly not least we can view all of the DLLs loaded into memory. DLLs are shared system libraries utilized in system processes. These are commonly subjected to hijacking and other side-loading attacks, making them a key target for forensics. Let’s list all of the DLLs in memory now with the command `dlllist`
Answer: No answer needed
| Task 3.10: Now that we’ve seen all of the DLLs running in memory, let’s go a step further and pull them out! Do this now with the command `volatility -f MEMORY_FILE.raw — profile=PROFILE — pid=PID dlldump -D <Destination Directory>` where the PID is the process ID of the infected process we identified earlier (questions five and six). How many DLLs does this end up pulling?
Answer: 12
| Task 4: Post Action
In this task we will be building on our knowledge of VirusTotal and what we can do after we anazly a memory dump.
| Task 4.1: Upload the extracted files to VirusTotal for examination.
Answer: No answer needed
| Task 4.2: Upload the extracted files to Hybrid Analysis for examination — Note, this will also upload to VirusTotal but for the sake of demonstration we have done this separately.
Answer: No answer needed
| Task 4.3: What malware has our sample been infected with? You can find this in the results of VirusTotal and Hybrid Anaylsis.
Answer: cridex
| Task 5: Extra Credit
This task is extra resources that are available for you to learn more about memory forenics
What we learned
In this tryhackme room we were able to learn about the use of Volatility when it comes to incident response and digital forensics and how to use it when we collect memory dumps from a compromised machine.