TryHackMe— Volatility Room Practical Challenge Walkthrough
Endpoint Investigation with Volatility 3
Introduction:
Hello! Last week’s write-up was for the LetsDefend Memory Analysis room which was my introduction to the Volatility framework. This week, I am going to build on my knowledge and am writing up my learning with the excellent Volatility room on TryHackMe. The capstone of the room is a practical challenge with two cases.
TryHackMe makes challenges like these very beginner-friendly and the coursework modules prior to the challenge will have you well-prepared. This challenge does require some additional, external research but it definitely helps to add context and spend more time on the DFIR process. In the spirit of learning and research I am not going to reveal the flags this time around but I will walk you through my process so you can recreate it yourself.
I used Volatility 3 to complete this room but going forward I will use the terms Volatility 3 and Volatility interchangeably. This is a longer one, so get comfortable. Thanks for reading!
Challenge Link: https://tryhackme.com/room/volatility
Challenge Scenarios:
Case 001 — BOB! THIS ISN’T A HORSE!
Your SOC has informed you that they have gathered a memory dump from a quarantined endpoint thought to have been compromised by a banking trojan masquerading as an Adobe document. Your job is to use your knowledge of threat intelligence and reverse engineering to perform memory forensics on the infected host.
You have been informed of a suspicious IP in connection to the file that could be helpful.
41[.]168[.]5[.]140
The memory file is located in
/Scenarios/Investigations/Investigation-1.vmem
Case 002 — That Kind of Hurt my Feelings
You have been informed that your corporation has been hit with a chain of ransomware that has been hitting corporations internationally. Your team has already retrieved the decryption key and recovered from the attack. Still, your job is to perform post-incident analysis and identify what actors were at play and what occurred on your systems. You have been provided with a raw memory dump from your team to begin your analysis.
The memory file is located in
/Scenarios/Investigations/Investigation-2.raw
Case 001 — BOB! THIS ISN’T A HORSE!
Questions 1 & 2:
What is the build version of the host machine in Case 001?
At what time was the memory file acquired in Case 001?
Before we get started, I want to call out the Volatility 3 help command built into the tool. We’re going to lean on this a lot. This is a great way to explore what plugins are available and get a brief description of their functions. In some cases, the plugin itself may have its own set of help for optional arguments! Don’t worry, we will utilize these further in the challenge. For now, I will leave the help command here as a starting point if you’d prefer to navigate the challenge on your own.
python3 vol.py -h
Okay, let’s get started! While the challenge doesn’t specify it, I am going to assume that we are analyzing a memory dump from a Windows endpoint. If you have completed the preceding tasks already in the TryHackMe Volatility room, you will have come across a module that will help us get started with scoping the challenge and working through the case: windows.info
As a refresher, Task 6 states:
If we are still looking to get information about what the host is running from the memory dump, we can use the following three plugins
windows.info
linux.info
mac.info
. This plugin will provide information about the host from the memory dump.
This plugin is a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment. When we run Volatility we’ll point to the challenge file path with the -f parameter and have it use the windows.info plugin.
python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.info
Once Volatility does its magic, we get the following output with some details of the memory dump.
I think the NTBuildLab & SystemTime fields should answer questions 1 & 2 — let’s submit to confirm that we have the right answers:
Question 3:
What process can be considered suspicious in Case 001?
Okay, now let’s get into the analysis and use Volatility to dig a bit deeper and understand the running processes on the victim system at the time the memory dump was taken. If we refer to the Volatility help again we have several process identification options.
Let’s go with the light-touch option first and simply list out the processes list using the windows.pslist plugin. We’ll see if we can find anything suspicious within our case file.
python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.pslist
Okay, now we have our output, see anything odd? I mentioned this in my previous Volatility post, but typically when looking at a Windows process list, I like to refer to the SANS Hunt Evil reference poster to understand normal Windows processes which helps tremendously during analysis.
Fortunately, this is a pretty short list and one of these process sticks out to me. Let’s confirm our suspicion and submit the answer but before we do, pay attention to the note on the submissions page…
Note: Certain special characters may not be visible on the provided VM. When doing a copy-and-paste, it will still copy all characters.
While we are here, let’s make a special note to grab the process ID (PID) of the suspicious process as well, we will need this to answer Question 5. So now we have the PID as well, let’s copy directly from the virtual machine, and paste our answer!
Questions 4, 5, 6:
What is the parent process of the suspicious process in Case 001?
What is the PID of the suspicious process in Case 001?
What is the parent process PID in Case 001?
Good work! Now that we have located the suspicious process, these next few questions will be straightforward. We just need to look at the output of pslist and look at the information presented. These questions seem out of order to me but we’ll figure it out.
Look at the columns in the output. We are going to focus on Process ID (PID), Parent Process ID (PPID), and ImageFileName. Using the information in these columns, we can determine the answers.
Question 4 is looking for the ImageFileName of the parent process of the suspicious child process we located. To find it, search the pslist output and look at the PPID of the suspicious process (this could also answer Question 6…) Then, locate the process with the matching PID — this is the parent process and we can use the ImageFileName as our answer. Once you find it, make a note of the PID as well so we can have it ready for Question 6!
Remember in Question 3 we made a note of the PID of the suspicious process? Now we can utilize it! Question 5 is asking for the PID of the suspicious process — easy enough, we will simply use the PID value of the suspicious process for our answer.
Whew! We got them — let’s move on.
Questions 7 & 8:
What user-agent was employed by the adversary in Case 001?
Question 8: Was Chase Bank one of the suspicious bank domains found in Case 001? (Y/N)
Cool, I haven’t had a chance to look at the networking modules in Volatility 3 yet. We’ll start with the information given in the challenge scenario:
You have been informed of a suspicious IP in connection to the file that could be helpful.
41.168.5.140
We have an IP, let’s see if we can get any networking info with windows.netstat & windows.netscan. Hmmm, the version of Windows our memory dump was taken from doesn’t seem to be supported…
Let’s pivot and try something else. If we scan through the help files again, there isn’t an obvious plugin that can work to search for this suspicious IP address though…
What if we could dump out the suspicious processes’ memory map? Maybe we can get some additional information or perform further analysis about the contents of files opened by this process that are mapped to the memory address space…
Remember that before we started the investigation, I mentioned that some plugins have optional arguments? Here is a good example.
We see that the memmap plugin has some additional options that will help us here. We can try dumping the suspicious process that we identified earlier. This time we are going to set an output directory with the -o parameter:
python3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem -o <output directory> windows.memmap --pid <redacted> --dump
This creates a dump file which contains way too much information for us to manually sift through. Let’s try to utilize the strings command in Ubuntu and grep our output to be a bit more focused.
Strings is a command that searches the contents of a file for printable strings so it can help us pull out something human readable from the process dump.
So what are we going to grep? Well, if we read the question back, it asks for a user-agent so let’s just try that? If you aren’t familiar a user-agent headers are strings that servers use to identify requesting client details like the operating system or the web browser version. In this case, let’s use the -i argument to ignore case and just search for user-agent.
Awesome! It looks like we found something useful for our investigation that should answer Question 7.
Now let’s tackle Question 8 and wrap Case 001 up. Since we already have the memory map for the suspicious process, maybe we can try the same logic as we did for Question 7 and just grep out “Chase” — could that work? Try it and find out!
sudo strings /home/thmanalyst/evidence/pid.<redacted>.dmp | grep -i "Chase"
Great! Now we can submit, and close the case before moving on to our next set of challenges in Case 002!
Case 002 — That Kind of Hurt my Feelings
Question 9: What suspicious process is running at PID 740 in Case 002?
Okay! Case 002 is an analysis of a ransomware strain. Since we have the PID of the suspicious process already, let’s use the pslist plugin again and this time let’s grep only the suspicious PID:
python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind
ows.pslist | grep 740
Interesting. This file name seems like it might be related to a famous ransomware from a few years ago. Let’s keep that in mind as we move through the investigation. While we’re at it, let’s also make a note of the parent process ID (PPID) too we’ll need it in Question 12.
Question 10: What is the full path of the suspicious binary in PID 740 in Case 002?
Let’s try to locate the file path of the suspicious binary. We’ll first try to lean on our process plugs (pslist, psscan, & pstree) to see if we can find any information. Unfortunately, these commands aren’t giving us much additional information so we will go back to the Volatility 3 help and see if we can find a plugin that could help us.
From the THM Task 7 Module:
This plugin will list all DLLs associated with processes at the time of extraction. This can be especially useful once you have done further analysis and can filter output to a specific DLL that might be an indicator for a specific type of malware you believe to be present on the system.
This could be useful to us from an investigative perspective but we also might get the file path of the binary that is loading the DLLs as well.
As a refresher, DLLs (Dynamic Link Library) are binary files that provide shared functionality for executables that can be called when required.
Let’s give it a try and see what we can find.
python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.dlllist | grep 740
Awesome — this is exactly what we were looking for!
Questions 11 & 12:
What is the parent process of PID 740 in Case 002?
What is the suspicious parent process PID connected to the decryptor in Case 002?
Alright, one step forward and two steps back. If you haven’t cleared your terminal yet, lets scroll back up to your pslist output from Question 9.
Take a look at the PPID column for PID 740. Remember in Question 9 where I mentioned we might want to make a note of the PPID of the suspicious process? That’s what we need for Question 12.
We will use pslist again and grep the parent process ID. After that, this becomes a simple matching game like we saw in Case 001.
python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind
ows.pslist | grep <ppid redacted>
When reviewing the output, Question 11 is looking for the ImageFileName of the process. Have fun!
Question 13: From our current information, what malware is present on the system in Case 002?
Let’s get to Google for some research of the artifacts we’ve found so far. We’ll start by searching for something broad, like the specific name of the executable that we discovered in Question 9.
We’ll stumble across a few links, but I chose the threat report from Mandiant for this write-up.
Based on the report — we have already discovered some of these indicators of compromise (IOCs) on our victim system. I think that we have determined the malware strain that infected the victim system:
Question 14: What DLL is loaded by the decryptor used for socket creation in Case 002?
Reading through the Mandiant report linked in Question 13, there are some mentions of socket functions but not necessarily what DLL is loaded specifically for socket creation. Let’s do a little more manual work with Volatility and perform our own analysis.
First, we will dump the process to see if I can learn anything on VirusTotal about any loaded DLLs by this executable. We’re going to dump this to an output directory and then retrieve the file hash for comparison.
python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw -o /home/thmanalyst/evidence windows.pslist --pid 740 --dump
sha256sum /home/thmanalyst/evidence/pid.740.0x400000.dmp
On the details tab, we’ll scroll down to the imports and take a look at the list of DLLs. It might not be the most efficient way, but we can quickly expand on all of the imports and see if we can spot any network or socket functions specifically. Let’s review the details; there is one that sticks out and looks like it could be relevant.
Now, let’s return to the DLL list in our analysis environment and look at the output for this process again and see all of the DLLs loaded by this specific sample and verify we see the DLL here as well:
Okay, I am thinking we may have found the answer but let’s do some additional research. I’m going to try get a quick AI brief on this DLL from the Microsoft Copilot for Edge to before we validate the accuracy of the information through the reference links — it’s always important to verify the accuracy of AI output.
Okay, confirmed! This seems like we can say with high confidence that the Winsock2 DLL is what is used for socket creation.
Question 15: What mutex can be found that is a known indicator of the malware in question in Case 002?
This is an interesting question and is a new one for me! Let’s do a quick Google refresher on a mutex for context.
Below is an excerpt from the SANS Blog:
Now, let’s check out the Mandiant report again and see if any of the heavy lifting has been done for us already. If we check out the file artifacts listed in the report, we see a mutex listed out.
Okay, so in theory this is information that should be captured in the memory image and we should be able to find a mutex used by the malware. Let’s check out the Volatility help and see if we can find any plugins that could help us validate this.
I’m sure there is a better way to utilize this plugin but in this case, let’s simply use the Volatility 3 windows.mutantscan plugin to validate the presence of the mutex in our analysis sample against the report:
Great, we stumbled through this one! Let’s submit and confirm our suspicion.
Question 16: What plugin could be used to identify all files loaded from the malware working directory in Case 002?
For the last question, we will return for the last time to our Volatility 3 help file. Let’s see if there are any other plugins we can utilize for further analysis of the malware and search for the files loaded from the malware directory?
This plugin could be useful for further analysis especially if we run it against the malware directory that we found in Question 10. While not required for the challenge, let’s go ahead and run the command and grep the working directory:
python3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.filescan | grep -i
"\ivecuqmanpnirkt615"
Wow! This gives us even more IOCs that we can use to validate our findings. For now, though — let’s submit the answer to Question 16 and wrap up these cases.
Conclusion:
There we have it — mission completed! Thank you to TryHackMe for the impressive room and challenge. This was a really great challenge to help me further explore Volatility 3 and learn some new skills along the way and I hope that you learned something as well between the two cases. Personally, I especially appreciated the need to do external research and use some brain power on DFIR. Thank you for your time in checking out this (long) walkthrough and stumbling through the challenge with me. Stay curious!