Intent:
As part of my cyber security journey, I decided to take the Incident Response and Forensics Module on TryHackMe. I wanted to do this so I can effectively respond to any potential incident.
Module description:
Incidents are inevitable. Companies pre-plan and formulate an internal process on what to do when incidents occur. This is known as incident response. Responders must analyze artifacts to understand the full scope of the incident and contain it. This module will introduce the tools and techniques that are a part of this process.
Task 1: Introduction
What is Volatility?
Volatility is a free memory forensics tool developed and maintained by Volatility labs. Regarded as the gold standard for memory forensics in incident response, Volatility is wildly expandable via a plugins system and is an invaluable tool for any Blue Teamer.
You can install the Volatility package by using the following command:
apt-get install volatility -y this is for Debian based systems
Task 2: Obtaining Memory Samples
You can obtain memory captures by using a multitude of different tools these tools may vary depending on what state the system is in.
Example tools for live machines:
Redline Redline requires regstration to use
Dumpit.exe
win32dd.exe / win64dd.exe
The above tools will normally output a .raw file which contains an image of the system memory. The .raw format is the most commonly used file format.
Offline machines (powered off)
Obtaining a memory sample can be achieved easily as long as the offline machine is undecrypted.
For a windows system you can do this by accessing the below file and pulling it off the machine:
%SystemDrive%/hiberfil.sys
The Windows hibernation file known as "hiberfil.sys" contains a compressed memory image from the previous boot. Microsoft does this to decrease the time it takes to boot, however, we can use this file for memory forensics.
Virtual machines:
Quick overview of popular hypervisors and their memory capture process/file:
- VMware - .vmem file
- Hyper-V - .bin file
- Parallels - .mem file
- VirtualBox - .sav file This is only a partial memory file. You'll need to dump memory like a normal bare-metal system for this hypervisor
These files can be found in the data store of the hypervisors. They can often but not always be copied without shutting the target virtual machine off. This allows for virtually zero disturbance to the virtual machine, preserving its forensic integrity.
Questions:
What memory format is the most common?
.raw
The Window's system we're looking to perform memory forensics on was turned off by mistake. What file contains a compressed memory image?
hiberfil.sys
How about if we wanted to perform memory forensics on a VMware-based virtual machine?
.vmem
Task 3: Examining Our Patient
Task 3 is a hands-on task where we get to examine a memory file of a VMware image we know because of the file extension .vmem
I would just like to make note that the instructions on the room are incorrect if you are using the attack box they tell you to navigate to /root/Rooms/BPVolatility
You will be unable to navigate to this room as we do not have root and there are no root credentials provided.
However when starting the machine if we run pwd & ls -a we can see we are in the /home/volusr directory with all the files we need:
I reported this issue directly to the owner of TryHackMe, so this could be fixed at the time of reading
Moving onto the practical part
Let's find out what profile we need to use inside of Volatility we can do this by issuing the following command
volatility -f cridex.vmem imageinfo
Questions:
Q: What profile is correct for this memory image?
A: WinXPSP2x86
We can find this information from the suggested profile field:
profiles may not always be accurate due to system age we can test the profiles by using the pslist argument example:
Q: Take a look through the processes within our image. What is the process ID for the smss.exe process? If results are scrolling off-screen, try piping your output into less
A: 368
We can find the information in the output of the above command we ran:
We can also view network connections by replacing pslist with netscan, sadly this will not work due to the age of the operating system output:
Q: 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?
A: csrss.exe
We can find the answer in the output:
Q:Which process has all three columns listed as 'False' (other than System)?
A: csrss.exe
We can find the information in the output here: by using the ldrmodules argument we can see what processes may have been injected which is indicated by "false" if a process has been injected this is normally a sign of compromise as it is used by bad actors, more about process injection: attack.mitre.org/techniques/T1055
Processes should not be the only area we are focused on. Using the "apihooks" argument we can view unexpected patches in the standard system DLLs. If we see an instance where the Hooking module: this is a bad sign as it could indicate compromise. This command can take a while to run.
Injected code is a bad sign as it is commonly used by bad actors to evade detection. using the "malfind" command will locate the code and then if we pair this with the -D argument we can specify where to save our bad code for further analysis.
Q: How many files does this generate?
A: 12
instead of counting the files manually try the below command to save time:
We can view all dlls that have been loaded into memory by using "dlllist" These are commonly subjected to hijacking and other side-loading attacks, making them a key target for forensics.
We can use "dlldump" to dump all of the dlls into a directory for later analysis and if we use the --pid=123 argument we can dump the dlls of a specific infected/injected process.
Q: How many DLLs does this end up pulling?
A:12
Task 4: Post Actions
Q:What malware has our sample been infected with? You can find this in the results of VirusTotal and Hybrid Analysis.
A: Cridex