Post cover image

October 14, 2026

DumpMe Lab — Endpoint Forensics Writeup

Scenario

By Mahmoud Alashwal

16 min read

Scenario

A SOC analyst took a memory dump from a machine infected with a meterpreter malware. As a Digital Forensicators, your job is to analyze the dump, extract the available indicators of compromise (IOCs) and answer the provided questions.

Tools Used

Volatility 2: used to analyze the memory dump, list processes, inspect network connections, and extract the malicious files https://github.com/volatilityfoundation/volatility

sha1sum: used to calculate the SHA1 hash of the extracted files https://www.gnu.org/software/coreutils

QUESTIONS:

Q1: What is the SHA1 hash of Triage-Memory.mem (memory dump)?

What's being asked: The question asks for the SHA1 hash of the memory dump file Triage-Memory.mem. A hash is a fingerprint of the file, and in forensics it proves the evidence was not changed during the analysis.

How do we solve this?

Step 1: Calculate the SHA1 hash of the memory dump Open a terminal and run sha1sum on the memory dump file:

bash

sha1sum ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem
  • sha1sum: a Linux tool that calculates the SHA1 hash of a file.
  • ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem: the path to the memory dump after unzipping the lab files.

The output is the 40-character hash, followed by the file path.

None None

Answer: C95E8CC8C946F95A109EA8E47A6800DE10A27ABD

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q2: What volatility profile is the most appropriate for this machine?

What's being asked: The question asks for the Volatility profile that matches the operating system of the memory dump. Volatility needs the right profile to read the memory structures correctly, so every other plugin depends on it.

How do we solve this?

Step 1: Run the imageinfo plugin

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem imageinfo
  • python2.7 vol.py: runs Volatility 2, which needs Python 2.7.
  • -f: the path to the memory dump file.
  • imageinfo: a plugin that scans the dump (using the KDBG search) and suggests which profiles fit it.

Step 2: Read the suggested profiles The output lists the suggested profiles: Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64, .... The first one in the list is the best match, so the machine is Windows 7 SP1, 64-bit: Win7SP1x64. The output also shows AS Layer1: WindowsAMD64PagedMemory, which confirms it is a 64-bit system, and the KDBG address that Volatility used to identify it.

None None

Answer: Win7SP1x64

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q3: What was the process ID of notepad.exe?

What's being asked: The question asks for the PID (Process ID) of the notepad.exe process that was running when the memory dump was taken.

How do we solve this?

Step 1: List the running processes

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 pslist
  • python2.7 vol.py: runs Volatility 2.
  • -f: the path to the memory dump file.
  • --profile=Win7SP1x64: the profile we found in Q2, so Volatility reads the memory correctly.
  • pslist: a plugin that walks the list of active processes and prints each one with its offset, name, PID, PPID, threads, handles, and start time.

Step 2: Find notepad.exe Scroll through the output (or add | grep notepad) and look for the notepad.exe row. It shows:

  • PID: 3032
  • PPID: 1432 (the parent process)
  • Start time: 2019-03-22 05:32:22 UTC
None None

Answer: 3032

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q4: Name the child process of wscript.exe.

What's being asked: The question asks for the name of the process that was started by wscript.exe (the Windows Script Host, which runs scripts such as .vbs and .js files).

How do we solve this?

Step 1: Show the process tree

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 pstree
  • python2.7 vol.py: runs Volatility 2.
  • -f: the path to the memory dump file.
  • --profile=Win7SP1x64: the profile we found in Q2.
  • pstree: a plugin that prints the processes as a tree, so you can see which process started which. Each dot (.) in front of a name is one level of depth, and a process with more dots is a child of the process above it.

Step 2: Find wscript.exe and its child In the output, wscript.exe (PID 5116, PPID 3952) was started at 05:35:32. Directly under it, with one more level of dots, there is a process with a random name: UWkpjFjDzM.exe (PID 3496, PPID 5116). Its PPID is the PID of wscript.exe, which confirms it is the child. A random executable name started by a script host is a strong sign of malware.

The tree also shows that this process started a cmd.exe (PID 4660, PPID 3496) one second later, so the attacker got a command shell through it.

None None

Answer: UWkpjFjDzM.exe

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q5: What was the IP address of the machine at the time the RAM dump was created?

What's being asked: The question asks for the local IP address of the infected machine when the memory dump was taken.

How do we solve this?

Step 1: Scan the network artifacts in memory

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 netscan
  • python2.7 vol.py: runs Volatility 2.
  • -f: the path to the memory dump file.
  • --profile=Win7SP1x64: the profile we found in Q2.
  • netscan: a plugin that scans the memory for network connections and sockets (TCP and UDP), including closed ones. For each one it shows the protocol, local address, foreign address, state, and the owner process with its PID.

Step 2: Read the local address The Local Address column shows the machine's own IP in many rows. Every IPv4 socket that is not bound to 127.0.0.1 or 0.0.0.0 uses 10.0.0.101, for example:

  • 10.0.0.101:1900 and 10.0.0.101:55736, owned by svchost.exe (PID 2888)
  • 10.0.0.101:137 and 10.0.0.101:138, owned by System (PID 4), which are the NetBIOS ports
None None

Answer: 10.0.0.101

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q6: Based on the answer regarding the infected PID, can you determine the IP of the attacker?

What's being asked: The question asks for the attacker's IP address. We use the infected process we found in Q4 (UWkpjFjDzM.exe, PID 3496) and check who it was connected to.

How do we solve this?

Step 1: Search the network connections for the infected process

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 netscan 2>/dev/null | grep -i UWkpjFjDzM
  • netscan: the plugin from Q5 that lists all the network connections found in memory.
  • 2>/dev/null: hides the Volatility error and debug messages, so only the real output is shown.
  • |: sends the output of netscan to the next command.
  • grep -i UWkpjFjDzM: keeps only the lines that contain the malicious process name (-i ignores upper and lower case).

Step 2: Read the foreign address The result is one line: a TCPv4 connection in the ESTABLISHED state, owned by UWkpjFjDzM.exe (PID 3496):

  • Local Address: 10.0.0.101:49217 (the victim, the IP from Q5)
  • Foreign Address: 10.0.0.106:4444 (the attacker)

Port 4444 is the default port of Metasploit's Meterpreter handler. So the victim machine connected back to the attacker's listener, which is a reverse shell. This matches the Meterpreter malware described in the lab, and the cmd.exe child process we saw in Q4.

None None

Answer: 10.0.0.106

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q7: How many processes are associated with VCRUNTIME140.dll?

What's being asked: The question asks how many processes have the DLL VCRUNTIME140.dll (the Microsoft Visual C++ runtime library) loaded in memory.

How do we solve this?

Step 1: List the loaded DLLs and filter for the one we want

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 dlllist | grep -i VCRUNTIME140.dll
  • dlllist: a plugin that lists the DLLs loaded by each process, with the base address, size, load time, and full path.
  • |: sends the output of dlllist to the next command.
  • grep -i VCRUNTIME140.dll: keeps only the lines that contain this DLL (-i ignores upper and lower case). Each matching line is one process that has loaded it.

Step 2: Count the matching lines The output has 5 lines, one for each process that loaded the DLL:

  • 1 from C:\Program Files\Common Files\Microsoft Shared\ClickToRun\
  • 4 from C:\Program Files (x86)\Microsoft Office\root\Office16\

So 5 processes are associated with VCRUNTIME140.dll.

None None

Answer: 5

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

8: After dumping the infected process, what is its md5 hash?

What's being asked: The question asks for the MD5 hash of the infected process (UWkpjFjDzM.exe) after extracting its executable from memory. The hash is calculated on the extracted file, not on the memory dump.

How do we solve this?

Step 1: Get the PID of the infected process

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 pslist 2>/dev/null | grep -i UWkpjFjDzM
  • pslist: lists the running processes.
  • 2>/dev/null: hides the Volatility error and debug messages.
  • grep -i UWkpjFjDzM: keeps only the line of the malicious process.

The output shows UWkpjFjDzM.exe with PID 3496 and PPID 5116 (wscript.exe), the same process we found in Q4.

None

Step 2: Create a folder for the dumped file

bash

mkdir -p ~/dump
  • mkdir -p: creates the folder ~/dump (and does not fail if it already exists).

Step 3: Dump the process executable from memory

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 procdump -p 3496 -D ~/dump/
  • procdump: a plugin that extracts the executable of a process from memory and saves it as a file.
  • -p 3496: the PID of the infected process.
  • -D ~/dump/: the folder where the extracted file is saved.

The result shows OK: executable.3496.exe, so the file was saved as ~/dump/executable.3496.exe.

None

Step 4: Calculate the MD5 hash

bash

md5sum ~/dump/executable.3496.exe
  • md5sum: a Linux tool that calculates the MD5 hash of a file.

The output is the 32-character hash, followed by the file path.

None None

Answer: 690ea20bc3bdfb328c23005d9a80c290

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q9: What is the LM hash of Bob's account?

What's being asked: The question asks for the LM hash of the user Bob, stored in the Windows password database (SAM) that Volatility can read from memory.

How do we solve this?

Step 1: Dump the password hashes from memory

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 hashdump
  • hashdump: a plugin that reads the SAM and SYSTEM registry hives from memory and prints the local accounts with their password hashes.

Step 2: Read Bob's line Each line has this format:

username:RID:LM hash:NT hash:::

Bob's line is:

Bob:1000:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

  • Bob: the username.
  • 1000: the RID (the account ID, 1000 and above are normal user accounts).
  • aad3b435b51404eeaad3b435b51404ee: the LM hash (the first hash).
  • 31d6cfe0d16ae931b73c59d7e0c089c0: the NT hash (the second hash).
None None

Answer: aad3b435b51404eeaad3b435b51404ee

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q10: What memory protection constants does the VAD node at 0xfffffa800577ba10 have?

What's being asked: The question asks for the memory protection value of one specific VAD node. A VAD (Virtual Address Descriptor) is a structure Windows uses to track each memory region of a process, and its protection tells us whether the region can be read, written, or executed.

How do we solve this?

Step 1: Dump the VAD information and look at the node

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 vadinfo | grep -A 10 0xfffffa800577ba10
  • vadinfo: a plugin that prints the details of every VAD node of every process (start and end address, flags, protection, type, and more).
  • |: sends the output to the next command.
  • grep -A 10 0xfffffa800577ba10: finds the line with the node address and also prints the 10 lines after it (-A 10), which contain the protection field.

Step 2: Read the Protection field The output starts with VAD node @ 0xfffffa800577ba10, with a start address of 0x30000 and an end address of 0x33fff. A few lines below it, the Protection field shows:

Protection: PAGE_READONLY

This memory region is read-only (it cannot be written to or executed).

None None

Answer: PAGE_READONLY

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q11: What memory protection did the VAD starting at 0x00000000033c0000 and ending at 0x00000000033dffff have?

What's being asked: The question asks for the memory protection of the VAD node that covers the address range 0x33c0000 to 0x33dffff. Here we search by the address range, not by the node address like in Q10.

How do we solve this?

Step 1: Dump the VAD information and search by the address range

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 vadinfo | grep -i -B 5 -A 10 -E "0x00000000033c0000|0x00000000033dffff"
  • vadinfo: a plugin that prints the details of every VAD node of every process.
  • |: sends the output to the next command.
  • grep -i: searches while ignoring upper and lower case.
  • -E "0x00000000033c0000|0x00000000033dffff": extended regex, where | means "or". It matches the start address or the end address of the range.
  • -B 5 -A 10: also prints 5 lines before and 10 lines after each match, so the whole VAD block is shown.

Step 2: Read the Protection field The matching block is:

VAD node @ 0xfffffa80052652b0 Start 0x00000000033c0000 End 0x00000000033dffff Tag VadS

and the lines under it show:

  • Flags: CommitCharge: 32, PrivateMemory: 1, Protection: 24
  • Protection: PAGE_NOACCESS

This memory region cannot be read, written, or executed.

None None

Answer: PAGE_NOACCESS

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q12: There was a VBS script that ran on the machine. What is the name of the script? (submit without file extension)

What's being asked: The question asks for the name of the VBS script (Visual Basic Script) that was executed on the machine, without the .vbs extension.

How do we solve this?

Step 1: Show the command line of every process

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 cmdline
  • cmdline: a plugin that prints the full command line (the executable path and all its arguments) that each process was started with.

Step 2: Find the script in the wscript.exe command line wscript.exe is the Windows Script Host, the program that runs .vbs files, so we look at its entry (PID 5116, the same one from Q4):

"C:\Windows\System32\wscript.exe" //B //NOLOGO %TEMP%\vhjReUDEuumrX.vbs

  • //B: batch mode, which hides errors and prompts.
  • //NOLOGO: does not show the Windows Script Host banner.
  • %TEMP%\vhjReUDEuumrX.vbs: the script that was run, from the user's Temp folder.

The script name is vhjReUDEuumrX. The silent flags and the random name in the Temp folder are typical of a malicious script, and this script is what launched the Meterpreter process UWkpjFjDzM.exe from Q4.

None None

Answer: vhjReUDEuumrX

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q13: An application was run at 2019–03–07 23:06:58 UTC. What is the name of the program? (Include extension)

What's being asked: The question asks for the name of the program (with its extension) that has the timestamp 2019-03-07 23:06:58 UTC in the system's application execution records.

How do we solve this?

Step 1: Read the Shimcache and filter by the timestamp

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 shimcache | grep "2019-03-07 23:06:58 UTC"
  • |: sends the output to the next command.
  • grep "2019-03-07 23:06:58 UTC": keeps only the entry with the exact timestamp from the question.

Step 2: Read the program name The output has one line:

2019-03-07 23:06:58 UTC+0000 \??\C:\Program Files (x86)\Microsoft\Skype for Desktop\Skype.exe

The program at the end of the path is Skype.exe.

None None

Answer: Skype.exe

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q14: What was written in notepad.exe at the time when the memory dump was captured?

What's being asked: The question asks for the text that was typed in the notepad.exe window when the memory dump was taken. Text typed in Notepad lives in the process memory, so we dump that memory and search it for readable strings.

How do we solve this?

Step 1: Dump the memory of the notepad.exe process

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 memdump -p 3032 -D "/media/sf_Tasks(SOC)/notepad_dump"
  • memdump: a plugin that saves all the memory pages of a process into one file.
  • -p 3032: the PID of notepad.exe that we found in Q3.
  • -D: the folder where the output is saved.

This creates the file 3032.dmp.

Step 2: Extract the readable text and search it

bash

strings -el "/media/sf_Tasks(SOC)/notepad_dump/3032.dmp" | grep -i "flag"
  • strings: prints the readable text found inside a binary file.
  • -el: reads the text as UTF-16 little-endian (l), the encoding that Windows programs like Notepad use for text. Without it, the text would not show up.
  • |: sends the output to the next command.
  • grep -i "flag": keeps only the lines that contain the word flag (-i ignores upper and lower case).

The first match is the text that was written in Notepad: flag<REDBULL_IS_LIFE>. The other lines, such as AppCompatFlags\Layers, are normal Windows strings that also contain the word.

None None

Answer: flag<REDBULL_IS_LIFE>

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q15: What is the short name of the file at file record 59045?

What's being asked: The question asks for the short name (the old 8.3 DOS-style name) of the file stored at MFT record number 59045. The MFT (Master File Table) is the NTFS index that keeps one record for every file on the disk.

How do we solve this?

Step 1: Confirm the record exists

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 mftparser | grep -F "Record Number: 59045"
  • mftparser: a plugin that scans the memory for MFT entries and prints each one with its record number, timestamps, and file name.
  • grep -F "Record Number: 59045": searches for that exact text (-F treats it as plain text, not a regex). The match confirms that the record is in the dump.

Step 2: Save the full MFT output to a file

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 mftparser > ~/mft_output.txt

  • : writes the output into ~/mft_output.txt instead of the screen. The MFT output is very large and slow to generate, so we create it once and search the text file as many times as we need.

None

Step 3: Search the file around the record

bash

grep -n -F -A 25 "Record Number: 59045" ~/mft_output.txt
  • -n: shows the line number of each line.
  • -A 25: also prints the 25 lines after the match, which contain the record details.

If you search only for 59045, as in your screenshot (grep -n -F -B 5 -A 15 "59045"), the number also appears inside unrelated lines. For example, the first match in your screenshot is a Chrome file from USERDA~1. Use Record Number: 59045 to jump straight to the right record.

None

Step 4: Read the file name from the $FILE_NAME attribute Under the record, the $FILE_NAME section shows the name and full path:

Users\Bob\DOCUME~1\EMPLOY~1\EMPLOY~1.XLS

The short name is the last part of the path: EMPLOY~1.XLS. The ~1 is how NTFS shortens long names to 8.3 format. The same record shows the file was created on 2019-03-17 06:50:07 UTC, and its type is Archive.

None None

Answer: EMPLOY~1.XLS

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Q16: This box was exploited and is running meterpreter. What was the infected PID?

What's being asked: The question asks for the PID of the process that is running the Meterpreter payload on the exploited machine. We already found this process in Q4, so here we only need to read its PID.

How do we solve this?

Step 1: List the running processes

bash

python2.7 vol.py -f ~/Downloads/65-DumpMe/temp_extract_dir/Triage-Memory.mem --profile=Win7SP1x64 pslist
  • pslist: lists the active processes with their offset, name, PID, PPID, threads, handles, and start time.

Step 2: Find the malicious process from Q4 In Q4, the process tree showed that wscript.exe started a child process with a random name: UWkpjFjDzM.exe. In the pslist output, we look for this name:

  • Name: UWkpjFjDzM.exe
  • PID: 3496
  • PPID: 5116 (wscript.exe)
  • Start time: 2019-03-22 05:35:33 UTC
None

Step 3: Confirm that it is Meterpreter The same PID 3496 owns the connection to 10.0.0.106:4444 that we found in Q6. Port 4444 is the default Meterpreter port, and the process started a cmd.exe (PID 4660). So 3496 is the infected process.

None

Answer: 3496

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Volatility Plugins Explained

Every command in this lab follows the same structure:

bash

python2.7 vol.py -f <memory dump> --profile=<profile> <plugin>
  • -f: the memory dump file.
  • --profile: the OS profile found with imageinfo (here Win7SP1x64).
  • <plugin>: the analysis we want to run on the dump.

Volatility Plugins

None None

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

That's a wrap on DumpMe Lab — Memory Forensics. Keep digging, keep learning, and happy hunting!

DumpMe Lab is done. Stay curious, keep analyzing, and happy hunting!

None