Overview

Our Intrusion Detection System (IDS) flagged a workstation for highly suspicious process behavior, suggesting a successful malware compromise. In response, a full memory dump was captured for forensic analysis. My objective for this lab was to move beyond the alerts and perform a deep dive into the volatile memory to reconstruct the infection chain.

Using Volatility 3 as my primary engine, I set out to:

• Identify the specific variant of the malware and its point of entry.
• Trace the execution flow from the initial user action to the malicious payload.
• Extract critical Indicators of Compromise (IOCs), including network callbacks and file signatures, to aid in broader network containment.

This lab serves as a textbook exercise in how memory forensics can reveal what disk forensics might miss, particularly when dealing with "living off the land" techniques or payloads that attempt to blend into common user activities.

Lab Scenario

Our intrusion detection system has alerted us to suspicious behavior on a workstation, pointing to a likely malware intrusion. A memory dump of this system has been taken for analysis. Your task is to analyze this dump, trace the malware's actions, and report key findings.

Lab Reference: Blue team CTF Challenges | Ramnit — CyberDefenders

Forensic Analysis

Q1 What is the name of the process responsible for the suspicious activity?

To begin investigating let's identify the OS version we're working with. The lab instructions recommend using Volatility 3, which tells me it's likely a modern Windows OS.

Run the windows.info module to collect system information.

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.info

Based on the output we can confirm:

• Windows 10 Pro/Home, Version 2004 (Build 19041)
• The capture was taken on 2024–02–01 at 19:54:11 UTC
• Volatility 3 will be best, while some Volatility 2 modules may be helpful and still produce results.

Next, let's run a few command to enumerate running processes:

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.pstree > pstree.txt
python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.pslist > pslist.txt
python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.psscan > psscan.txt

Review the output from the above commands, starting with pslist, then compare those results to psscan to identify any discrepancies — note down anything that stands out:

• 7484 808 smartscreen.exe — indicates something was likely scanned / downloaded.
• 4628 4568 ChromeSetup.exe — interesting to see, not common to see a running setup process. It's important to verify context here.
• 5184 2268 setup.exe — suspicious, worth investigating.
• 6140 5148 setup.exe — suspicious, worth investigating.

With a list of processes to investigate, pivot to the pstree output. Inspect file paths to identify anomalies.

cat pstree.txt | grep -C 5 -iE 'smartscreen|chromesetup|setup.exe'

The output confirms ChromeSetup.exe was executed from a user's Downloads directory — given the scenario, this is likely our process of interest.

• Path: C:\Users\alex\Downloads\ChromeSetup.exe
• PPID: 4508 (Explorer.exe) indicating the user clicked ChromeSetup.exe from the File Explorer.
• Command Line: Nothing of interest.

Answer: ChromeSetup.exe

Q2 What is the exact path of the executable for the malicious process?

We identified the full path in the previous question. The ChromeSetup.exe binary executed from: C:\Users\alex\Downloads\ChromeSetup.exe

Answer: C:\Users\alex\Downloads\ChromeSetup.exe

Q3 Identifying network connections is crucial for understanding the malware's communication strategy. What IP address did the malware attempt to connect to?

Run the windows.netscan module to investigate network connections related to our process of interest.

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.netscan > netscan.txt

Use grep to filter results — the output from netscan can be busy — no only does it show running processes, but also those that have exited.

cat netscan.txt | grep -C 5 -iE '4628|ChromeSetup|ForeignAddr'

Check the "ForeignAddr" column to identify remote addresses the ChromeSetup.exe process was interacting with.

Answer: 58.64.204.181

Q4 To determine the specific geographical origin of the attack, Which city is associated with the IP address the malware communicated with?

We can use the IP address in which ChromeSetup.exe was communicating with to identify the origin of the attack. AbuseIPDB is a great resource to bookmark — paste the IP address to reveal the City.

Reference: 58.64.204.181 | NWT iDC Data Service | AbuseIPDB

Answer: Hong Kong

Q5 Hashes serve as unique identifiers for files, assisting in the detection of similar threats across different machines. What is the SHA1 hash of the malware executable?

This is a fun question — and I don't want to jump strait to the answer, because, for me, it was a bit of trial and error. Seeing where I went wrong may help you solidify the concepts.

Rabbit Hole #1:

• I used the threat actor's IP address to pivot — more of a threat intelligence approach. Often, if you can identify an IP address linked to threat actor infrastructure, you can check the "Relations" tab in VirusTotal and look for "Communicating Files". I found lots of communicating files — none of which were the right one. Had I found the ChromeSetup.exe binary, the SHA1 hash would have been recorded in VirusTotal.

Rabbit Hole #2:

• I ran the pslist module, along with --pid and --dump options to dump ChromeSetup.exe from RAM. I calculated the hash using SHA1SUM in WSL… but the hash was incorrect, why?
• Research: The difference occurs because pslist --dump captures the process as it exists in RAM, already modified by the OS loader for execution, whereas dumpfiles targets the file as it was originally stored on disk. This results in different hashes due to memory alignment, base relocations, and potential unpacking that only happen when the file is active in memory.
• Lesson learned.

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.pslist --pid 4628 --dump
sha1sum 4628.ChromeSetup.ex.0x400000.dmp

An the correct path:

• Run the filescan module to enumerate files. This module scans physical memory for FILE_OBJECT structures that the Windows kernel uses to track files currently opened by processes or held in the system cache.
• Dump the output to a text file to quickly grep through:

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.filescan > filescan.txt

• Identify the virtual offset for ChromeSetup.exe:

cat filescan.txt | grep -i ChromeSetup.exe

• Run the dumpfiles module and specify the --virtaddr to tell it the correct location to dump.

python3 vol.py -f /mnt/c/BlueLabs/159-Ramnit/memory.dmp windows.dumpfiles --virtaddr 0xca82b85307f0

• Finally, run SHA1SUM against the dumped file to calculate it's hash.

sha1sum file.0xca82b85307f0.0xca82b7e06c80.ImageSectionObject.ChromeSetup.exe.img

Answer: 280c9d36039f9432433893dee6126d72b9112ad2

Q6 Examining the malware's development timeline can provide insights into its deployment. What is the compilation timestamp for the malware?

Straight to VirusTotal with our newly acquired hash. Navigate to the "Details" tab, and note the Creation Time.

Answer: 2019–12–01 08:36

Q7 Identifying the domains associated with this malware is crucial for blocking future malicious communications and detecting any ongoing interactions with those domains within our network. Can you provide the domain connected to the malware?

Still in VirusTotal, shift over to the "Relations" tab. Refer to the Contacted URLs section. Here we can see the dnsnb8.net domain listed several times.

Forensic Verification: While OSINT confirmed the domain's reputation, I wanted to find it within the memory dump itself. By running strings and grepping for the domain, I identified several instances of ddos.dnsnb8.net. This confirms the domain was either hardcoded into the binary or stored in memory during runtime, providing proof of the C2 configuration.

strings /mnt/c/BlueLabs/159-Ramnit/memory.dmp | grep -C 20 -i dnsnb8.net

Answer: dnsnb8.net

Summary

The analysis confirms a compromise by the Ramnit malware family. The infection was triggered when the user "alex" manually executed a file named ChromeSetup.exe directly from their \Downloads\ directory. While the filename was designed to look like a standard browser installer, the forensic artifacts told a different story.

Key Findings:

• Execution Chain: The malware was spawned directly from explorer.exe (PID 4508), indicating a successful social engineering lure.
• Command & Control (C2): Upon execution, the process established an active network connection to 58.64.204.181 (Hong Kong), likely to receive further instructions or secondary payloads.

This lab highlighted the critical importance of memory-resident data. I discovered that dumping a process directly from the active PID results in a modified hash due to OS-level base relocations. To obtain the true "on-disk" SHA1 hash, I had to pivot to the ImageSectionObject found via filescan.

By correlating the compilation timestamp (Dec 2019) with the network activity and domain callbacks (dnsnb8.net), we can categorize this as a persistent threat actor using aged but highly effective malware infrastructure. For an incident responder, this reinforces the rule: Never trust a file based on its name—always verify the signature and the behavior.