Overview

This lab writeup provides a comprehensive technical breakdown of a memory forensics investigation using Volatility 3. By analyzing a memory dump from a compromised Windows workstation, the walkthrough demonstrates how to extract vital forensic artifacts, including system metadata, active network connections, and process hierarchies. The investigation effectively utilizes a mix of Linux command-line tools like grep, xxd, and strings alongside specialized Volatility modules to reconstruct the activities of a suspect flagged for unauthorized access and unusual browsing patterns.

The analysis uncovers several key indicators of compromise and user activity, such as an established connection between chrome.exe and a ProtonMail domain, as well as the execution of powershell.exe spawned from the Windows Explorer shell. Beyond process identification, the writeup delves into registry forensics using the UserAssist module to quantify application usage and file system analysis to track recently opened sensitive documents in Notepad. This resource serves as a practical guide for incident responders to practice identifying malicious footprints within volatile memory.

Scenario

A memory image was acquired from a suspected compromised Windows workstation. The system belonged to a user flagged for potentially malicious activities, including unauthorized access attempts and unusual browsing patterns. The security team observed network activity to external IPs associated with encrypted communication services.

Your task is to analyze the provided memory dump to uncover details about the processes involved, identify active connections at the time of the compromise, and trace the usage patterns of specific applications.

Lab Reference: Blue team CTF Challenges | Brave — CyberDefenders

Forensic Analysis

Q1 What time was the RAM image acquired according to the suspect system? YYYY-MM-DD HH:MM

The system time is captured when the memory dump is created. We can obtain the exact date and time by running Volatility 3 with the windows.info module.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.info

The memory image was created on 2021–04–30 17:52:19+00:00 UTC.

Answer: 2021–04–30 17:52

Q2 What is the SHA256 hash value of the RAM image?

If you're using a Linux VM or WSL, run sha256sum to calculate the hash. Otherwise, from Windows, use PowerShell:

Get-Filehash -Algorithm SHA256 memdump.mem

Linux:

Windows:

Answer: 9db01b1e7b19a3b2113bfb65e860fffd7a1630bdf2b18613d206ebf2aa0ea172

Q3 What is the process ID of brave.exe?

The windows.pslist module can be used to identify the PID belonging to brave.exe.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.pslist | tee pslist.txt

Answer: 4856

Q4 How many established network connections were there at the time of acquisition? **

The windows.netscan plugin will get us a complete list of network connections — I would recommend piping the output into tee to save a copy locally for easy filtering using grep.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.netscan | tee netscan.txt

Filter for "ESTABLISHED", then count the results using wc -l.

cat netscan.txt | grep -i ESTABLISHED | wc -l

Answer: 10

Q5 Which domain name does Chrome have an established network connection with? ********.

Based on the output from the previous question, we can conclude that chrome.exe (PID 1840) had an established network connection to 185.70.41.130 over port 443 (HTTPS).

Paste this IP address into a tool such as AbuseIPDB, or simply run nslookup to identify the domain.

Nslookup (185.70.41.130 | Proton AG | AbuseIPDB):

nslookup 185.70.41.130

AbuseIPDB:

The chrome.exe process was connecting to an address tied to protonmail.ch.

Answer: protonmail.ch

Q6 What is the MD5 hash value of the process executable for PID 6988?

To obtain the MD5 hash we can leverage Volatility 3's windows.pslist module with the --pid and --dump flags.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.pslist --pid 6988 --dump

Follow this up with md5sum in WSL and we have our hash:

md5sum 6988.OneDrive.exe.0x1c0000.dmp

Answer: 0b493d8e26f03ccd2060e0be85f430af

Q7 Can you identify the word that begins at offset 0x45BE876 and is 6 bytes long?

Alright — there's two different ways to do this — I'll demonstrate both:

HxD — on Windows:

• Open the memdump.mem capture file into HxD.
• From the top menu, select "Search" > "Go to" and type the provided starting offset — you will need to omit the 0x prepended to the offset.

xxd — on Linux:

• run xxd with the -s option followed by the provided offset — for this one you will need to include the prepended 0x at the beginning. This tells the hex editor to use this "section" as a starting point. Use the -l option specify the number of bytes you wish to retrieve directly following the offset specified as a starting point. In this case, we want the first 6 bytes immediately after the specific offset.

xxd -s 0x45BE876 -l 6 /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem

Answer: hacker

Q8 What is the creation date and time of the parent process of powershell.exe? YYYY-MM-DD HH:MM

Let's use the pstree module to answer this question. While we can do this with the output from psscan, pstree gives us a nice list of parent-child processes that's easy to visualize.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.pstree | tee pstree.txt

Filter the results using grep:

cat pstree.txt | grep -C 5 -i powershell.exe

The output confirms that powershell.exe (PID 5096) was created by explorer.exe (PID 4352) at 2021–04–30 17:39:48.000000 UTC.

Answer: 2021–04–30 17:39

Q9 What is the full path and name of the last file opened in notepad? C:*******~******

The full path including the file name can be found in the output of the windows.cmdline module. Run it with the option --pid 2520 (notepad.exe).

The results confirm that notepad.exe interacted with a file named accountNum.

Optionally, dump the allocated process memory for notepad.exe — to get more details about the file.

python3 vol.py -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.memmap --pid 2520 --dump

Strings:

strings pid.2520.dmp | grep -i accountnum

Answer: C:\Users\JOHNDO~1\AppData\Local\Temp\7zO4FB31F24\accountNum

Q10 How long did the suspect use Brave browser? (In Hours) Note: Round to the nearest whole number in hours.

The UserAssist evidence of execution artifact also records usage time under the "Time Focused" column. Simply running the standard Volatility command we've been running will work, but the output being so messy makes it difficult to locate the proper information.

Run the windows.registry.userassist module, but make sure to use -r pretty to format the results into a table to make reading it a bit easier.

python3 vol.py -r pretty -f /mnt/c/BlueLabs/67-AfricanFalls2/memdump.mem windows.registry.userassist > userassist.txt

Use grep to filter for "Brave", and "Time Focused" ensuring the column headers are also included in the output.

cat userassist.txt | grep -C 2 -iE 'brave|time focus'

The filtered output confirms the cumulative "Time Focused" by the brave.exe process is ~4-hours.

Answer: 4

Summary

The summary of the lab results highlights a successful recovery of the system's state at the time of acquisition, specifically 2021–04–30 at 17:52 UTC. Key findings include the identification of Brave and Chrome as active browsers, with the latter maintaining a connection to protonmail.ch, suggesting a possible vector for data exfiltration or secure communication by the actor. The analysis also pinpointed a specific PowerShell instance created by the user through the GUI, and successfully recovered the path of a sensitive file (accountNum.zip) located in a temporary directory, which is a common location for staged or unpacked malicious payloads.

Furthermore, the writeup demonstrates high proficiency in extracting execution metrics and low-level data. By leveraging the UserAssist registry keys, we determined that the Brave browser had been used for approximately four hours, providing a timeline of user engagement. The technical walkthrough concludes by showing how to dump specific process memory to find strings and verify file integrity via MD5 and SHA256 hashing. Overall, the summary reinforces the value of memory forensics in validating alerts and provides clear, reproducible steps for isolating malicious activity within a complex enterprise environment.