CyberDefenders: DumpMe
Overview: DumpMe is a medium-difficulty memory forensics challenge hosted by CyberDefenders. The recommended tools for the challenge are Volatility 2 and sha1sum. For this challenge, I used a Kali VM that already had multiple versions of Volatility installed.
Scenario: A SOC analyst took a memory dump from a machine infected with a meterpreter malware. As a Digital Forensic Analyst, your job is to analyze the dump, extract the available indicators of compromise (IOCs) and answer the provided questions.
Q1
What is the SHA1 hash of Triage-Memory.mem (memory dump)?
Since we’re in Kali we’ll use sha1sum to get the hash.
Answer: C95E8CC8C946F95A109EA8E47A6800DE10A27ABD
Q2
What volatility profile is the most appropriate for this machine? (ex: Win10x86_14393)
Volatility’s imageinfo plugin provides a list of suggested profiles.
Answer: Win7SP1x64
With the hash and profile confirmed, it’s time to start the analysis.
Before jumping into the real questions, I decided to take a look at some basic information that I could obtain with Volatility, such as the process tree (pstree), network connections (netscan), and command line arguments (cmdline).
With these 3 plugins, we can already see some odd artifacts: there’s a process running with an unusual name, a network connection from that process, and a VBS script with another suspicious name. Worse yet, the network connection is going out to port 4444, Metasploit’s default port.
Q3
What was the process ID of notepad.exe?
We’ve already run the pstree module, so looking back at the output we can quickly find notepad’s PID. But if we want to filter it down:
Answer: 3032
Q4
Name the child process of wscript.exe.
Again the answer to this was in the output of the first pstree command, but let’s filter it down for brevity.
Answer: UWkpjFjDzM.exe
Q5
What was the IP address of the machine at the time the RAM dump was created?
We’ve already seen the results of the netscan plugin, which only contained one IPv4 address that wasn’t a loopback/wildcard. But, using the suspicious executable to demonstrate, we can see the source IP address which had an established connection at the time of the memory capture.
Answer: 10.0.0.101
Q6
Based on the answer regarding the infected PID, can you determine the IP of the attacker?
Although this question seems to be out of order, assuming the infected process is the one with the red flags, we can consider the Foreign Address in the previous question’s netscan output as the attacker’s IP.
Answer: 10.0.0.106
Q7
How many processes are associated with VCRUNTIME140.dll?
This question was the first hurdle of the challenge. I ran the dlllist module, but my answer was incorrect.
I tried Volatility 3, but I got the same result, only one process.
After some searching, I came across a similar issue in which someone reported unique results with version 2.6.1. Checking my previous output I could see my Volatility version was 2.6, not 2.6.1.
After downloading 2.6.1 and running the same command, we get the following results:
Answer: 5
Q8
After dumping the infected process, what is its md5 hash?
Referring back to the first pstree output, the suspect process had a PID of 3496. With this, we can run the procdump plugin to extract the process, then we’ll calculate the hash.
Answer: 690ea20bc3bdfb328e23005d9a80c290
Q9
What is the LM hash of Bob’s account?
Volatility comes prepared for this question as well, the hashdump plugin is all we need.
Bob’s password hash is NTLM, meaning the first half — between the ‘1000:’ and the subsequent ‘:’ — is the LM hash.
Answer: aad3b435b51404eeaad3b435b51404ee
Q10
What memory protection constants does the VAD node at 0xfffffa800577ba10 have?
Looking through the available plugins for Volatility, there are a few that relate to VAD. The first, vadinfo, gives us all the information we need. So a quick filter for the provided node gives us the answer.
Answer: PAGE_READONLY
Q11
What memory protection did the VAD starting at 0x00000000033c0000 and ending at 0x00000000033dffff have?
We can use the same plugin/technique, just adjust the grep.
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)
Looking back at our preliminary scans, we had already come across a VBS script with a suspicious name. We’ll run the cmdline plugin again and filter the results for clarity.
Answer: vhjReUDEuumrX
Q13
An application was run at 2019–03–07 23:06:58 UTC. What is the name of the program? (Include extension)
Checking for relevant plugins, we come across Volatility’s amcache and shimcache.
Running the amcache plugin didn’t return any results, but the shimcache was a success.
Answer: Skype.exe
Note: I checked my copy of Volatility 2.6.1 and it did not include the shimcache plugin, so if your version of Volatility doesn’t have it, you’ll need to download it separately. https://github.com/mandiant/Volatility-Plugins/blob/master/shimcachemem/README.md
Q14
What was written in notepad.exe at the time when the memory dump was captured?
Although Volatility has a notepad plugin that will output the current notepad text, the plugin is incompatible with the Windows profile we’re using. After looking for alternatives, I decided to try dumping notepad’s memory.
We already got notepad’s PID for Q3, so we can use the memmap plugin to get the memory. The question tells us the answer is in the form of flag<*****************>, so we’ll search the process’ memory dump for ‘flag<’. This still fails to return the answer. After some more digging, it turns out that notepad stores text in little-endian. Adding the appropriate switch (-e l) to the strings command gets our answer.
Answer: flag<REDBULL_IS_LIFE>
Q15
What is the short name of the file at file record 59045?
Looking through the plugins available in Volatility, we can see one is mftparser. In Windows, the MFT file holds a record for each file on the volume, so if we can parse it we’ll find our answer.
Answer: EMPLOY~1.XLS
Q16
This box was exploited and is running meterpreter. What was the infected PID?
With all the information we’ve gathered, it’s pretty clear that UWkpjFjDzM.exe is running meterpreter, but let’s get some additional evidence. For this, we’ll use the yarascan plugin. In addition to the plugin, we need a Yara rule to detect meterpreter sessions. I used the rule from https://raw.githubusercontent.com/cuckoosandbox/community/master/data/yara/shellcode/metasploit.yar.
The scan takes a while to complete, but once it’s finished we’ll see it triggered multiple times on our suspected executable.
Answer: 3496
Bonus Points(?):
While doing some digging into the dump, I ran the iehistory plugin and came across a reference to the band Primus. This challenge just got cooler.
Conclusion:
This was a fairly straightforward challenge but was a lot of fun to work through. By running some preliminary scans we quickly found suspicious items that would lead the investigation and followed them up with supporting evidence.
