🔍 Sherlock Scenario: Investigating a Malware Intrusion
- BlueDolphin
- Aug 20
- 4 min read
🧩 Attack Summary
In this Sherlock Scenario, you step into the role of a SOC analyst investigating a suspected intrusion. By analyzing suspicious network activity and file artifacts, we’ll uncover how attackers weaponized a document, staged malware, and achieved command-and-control (C2).
The investigation revealed the following attack chain:
Weaponized Document (SMB)
↓
Suspicious VBS Download
↓
Malware Resource Development
↓
Multiple File Downloads
↓
De-obfuscation & Reverse Shell
↓
C2 Communications
Attack Steps
Weaponized document retrieved via SMB
Malware stages resources & downloads four files (nrwncpwo, test2, jvtobaqj, ozkpfzu)
Files unpack & de-obfuscate, establishing a reverse shell
C2 communications initiated back to the attacker infrastructure
🧩 Clue 1 — Suspicious VBS File
Observed
File: AZURE_DOC_OPEN.vbs
Source: escuelademarina.com (165.22.16.55)
Retrieved via SMB
Investigation
The first 20 packets show an admin user authenticating and establishing an SMB connection.
Immediately after, the file AZURE_DOC_OPEN.vbs was downloaded.
Why It’s Suspicious
External SMB connections are rare in legitimate workflows.
Downloading a VBS script from an unknown host is a strong indicator of malicious activity.
A VBS script AZURE_DOC_OPEN.vbs was download from domain escuelademarina.com | 165.22.16.55.
Looking at the first 20 packets reveals allot of information. First, we see that a user authenticates as admin. From here the user establishes a file share or SMB connection to escuelademarina and attempts to download files. The file "Azure_Doc_open.vbs is downloaded.
🧩 Clue 2 — Suspicious Downloads
Looking deeper into downloads:
SMB filter showed little else.
HTTP filter revealed multiple downloads from domain badbutperfect[.]com.
The URIs were arbitrary strings (/nrwncpwo, /ozkpfzu), except test2.
File | Behavior | Notes |
nrwncpwo | Script that downloads additional files | Initial stage downloader |
test2.exe | Binary searching for AHK script | Executes payload |
jvtobaqj | Appears as nonsense text | Obfuscation, contains DLL calls |
ozkpfzu | Hex-encoded data | Decodes to strings, possible payload |
Here I wanted to look for other downloads so I decided to filter for SMB downloads which revealed little. However when I filtered for HTTP downloads I found several interesting files warranting further investigation.
This only shows me client requests to the badbutperfect domain. The URI paths were odd and seemed arbitrary except for "test2".
filename="jvtobaqj" - at first appeared to be non sense. Just words mashed together. However I noticed that all the non sense had been commented out and in between were commands to allocate memory or parts of a command such as DLL calls as seen below.
Filename ozkpfzu appeared to be hex data and when running through cyberchef with Hex decoding there were a few readable strings.
🧩 Clue 3 — Script Analysis
The attackers used a multi-stage process to obfuscate and execute their payload.
Step 1: Downloader (nrwncpwo)
Beautified using CyberChef → revealed it staged the other downloads.
Step 2: Executable (test2.exe)
Renaming to .exe and running showed it looked for an AHK script.
The AHK script had filler text, but when stripped out revealed shellcode loading logic.
Step 3: AHK Script Execution Flow
Script Behavior (Simplified)
Reads payload from test.txt (hex-encoded shellcode).
Allocates executable memory with VirtualAlloc.
Copies payload byte-by-byte into allocated memory.
Executes the payload directly.
These files are all related and we need to figure out how they work together.
This is the nrwncpwo file from earlier. I have put the code through Cyber chef's beautifier and syntax highlighter to clean it up.
Renaming the file test2 to test2.exe and running the program reveals it is looking for the ahk script. We observed this script earlier when looking through the wireshark capture and following the stream specific to the GET requests.
From here the binary calls the ahk script. Remember how the ahk script had all that non sense filler? If we parse out the nonsense this is what we are left with.
🔍 Script Overview
The script:
Reads a file (test.txt) containing the attackers payload in hex.
Allocates memory with execute permissions.
Copies the payload byte-by-byte into the allocated memory.
Executes the payload by calling the memory address directly.
Why It’s Dangerous
Allocating memory with PAGE_EXECUTE_READWRITE bypasses typical OS protections.
This is a classic fileless execution technique used to inject shellcode directly.
🧩 Clue 4 — Command & Control
Finally, traffic analysis revealed DarkRAT malware beaconing out:
Protocol: HTTP POST
Destination: badbutperfect[.]com
Behavior: Remote access & persistence via RAT infrastructure
This confirms that the intrusion led to successful C2 communication.
📌 Analyst Lessons Learned
Suspicious SMB activity (file shares + VBS downloads) should be treated as high-priority alerts.
Nonsense or filler text in scripts often hides real payloads — strip and re-analyze.
AutoHotkey scripts can be abused for memory injection and shellcode execution.
HTTP POST traffic to unknown domains can indicate RAT beaconing.
Build detection rules for:
VirtualAlloc with PAGE_EXECUTE_READWRITE
SMB downloads of script files
Arbitrary URI requests to external domains
🏁 Conclusion
By piecing together network clues and unpacking scripts, we traced the attack from a weaponized SMB document to a DarkRAT C2 connection. This scenario highlights the importance of structured analysis: start with the network, pivot to files, dissect scripts, and always correlate with outbound traffic.
In real-world operations, this methodology helps analysts move from initial detection to confirmed attribution quickly and confidently.