Takedown

Scenario

We’ve identified an unusual pattern in our network activity, indicating a possible security breach. Our team suspects an unauthorized intrusion into our systems, potentially compromising sensitive data. Your task is to investigate this incident.

Executive Summary

A victim host opened a VBScript from a remote SMB share hosted on an attacker-controlled domain. The script reached out over HTTP to a second domain and pulled a PowerShell stager. That stager downloaded a legitimate AutoHotkey interpreter, a decoy text payload, and an AutoHotkey script, then saved the script to disk so the interpreter could run it. The script was a DarkGate RAT loader, and the infected host then beaconed to a single external IP over plain HTTP using a Chrome user-agent. The entire chain is recoverable from one packet capture.

Artifacts

• Takedown.pcap: the only evidence file → open with tshark or Wireshark. Contains SMB2, DNS and plain HTTP traffic

Format note: Several answers are URLs or hashes with a fixed shape. The task format masks (*************.***/********) match the host and path exactly as seen on the wire, so don’t add or drop a scheme unless the mask shows one.

Initial Access

Start with a conversation and DNS overview of the capture to see which hosts the victim talked to. The script does not arrive over HTTP: the SMB2 tree connect names the share as \\escuelademarina.com\cloud, and the domain is the host part of that UNC path.

tshark -r Takedown.pcap -Y smb2 -T fields -e frame.number -e smb2.cmd -e smb2.tree

From Q1 we have the domain. Pull the DNS responses for it and read the A record the victim resolved before connecting to the share.

tshark -r Takedown.pcap -Y dns -T fields -e dns.qry.name -e dns.a

Inside the SMB2 session to the cloud share, the Create request names the file being opened and the following Read responses carry its contents. One .vbs file is opened, and its name is built to look like a document.

tshark -r Takedown.pcap -Y "smb2.cmd == 5" -T fields -e frame.number -e smb2.filename

Execution

List every HTTP request in the capture and drop the repeating GET / beacons. What remains is a short run of requests to a second domain with random-looking eight-letter paths. The first of them returns a PowerShell script, which is the stager the VBS launches.

tshark -r Takedown.pcap -Y http.request -T fields -e frame.number -e http.host -e http.request.uri

Export the response from Q4 and read it. The script downloads three further objects from the same host. One is saved with the output name AutoHotkey.exe, a legitimate scripting interpreter that will run whatever script it is handed.

tshark -r Takedown.pcap --export-objects http,work/obj

The stager pulls two non-binary objects besides the interpreter. One is a large hex-encoded text blob. The other is a small AutoHotkey script, and that is the payload the interpreter executes. Match the -OutFile target in the PowerShell to the request path.

tshark -r Takedown.pcap -Y "http.request.uri contains jvtobaqj" -T fields -e http.host -e http.request.uri

Gotcha: The biggest object in the capture is the hex blob, and it is easy to take it for the malware. It is a decoy payload served as text. The malware is the short .ahk script, and --export-objects can miss large objects, so reassemble the TCP stream when an export comes back short.

The same PowerShell stager from Q4 decides the on-disk name. Find the -OutFile argument paired with the Q6 URL.

tshark -r Takedown.pcap -Y "frame.number == <stager frame>" -T fields -e http.file_data | xxd -r -p

Reassemble the TCP payload of the Q6 download, strip the HTTP headers, hash the body and look the SHA-256 up on VirusTotal. The file details tab shows the TLSH.

tshark -r Takedown.pcap -q -z follow,tcp,raw,<stream> | xxd -r -p > work/o2/ahk.txt

vt 5aac7d31149048763e688878c3910ae4881826db80e078754f5d08f2c1f39572

Gotcha: The TLSH of the hex blob from Q6 looks equally valid and is a different file. Make sure the hash comes from the .ahk body, not the largest object.

The same VirusTotal report from Q8 lists vendor detections. McAfee and Ikarus both use one family name, and the community comment agrees. This comes from the VirusTotal verdicts rather than from anything in the capture.

Command and Control

After the staging downloads, the capture is dominated by repeating GET / requests, which are the RAT beacons. Print the user-agent field on those requests.

tshark -r Takedown.pcap -Y 'http.request.uri == "/"' -T fields -e http.user_agent | sort | uniq -c

Group the beacon requests from Q10 by destination. Every one goes to the same external address, which is the C2.

tshark -r Takedown.pcap -q -z endpoints,ip

Attack Summary

Phase	Action
Initial Access	Victim opens a VBScript from an SMB share on an attacker domain
Execution	The VBS fetches a PowerShell stager over HTTP from a second domain
Execution	The stager downloads the AutoHotkey interpreter, a decoy hex payload and an AutoHotkey script
Execution	The script is saved as script.ahk and run by the interpreter
Command and Control	DarkGate beacons to a single external IP over HTTP with a Chrome user-agent

IOCs

Type	Value
Domain (SMB share)	escuelademarina[.]com
IP	165.22.16[.]55
File	AZURE_DOC_OPEN.vbs
Domain (staging)	badbutperfect[.]com
URL (PowerShell stager)	badbutperfect[.]com/nrwncpwo
URL (AHK malware)	hxxp[://]badbutperfect[.]com/jvtobaqj
File	AutoHotkey.exe, script.ahk
SHA-256 (AHK script)	5aac7d31149048763e688878c3910ae4881826db80e078754f5d08f2c1f39572
TLSH	T15E430A36DBC5202AD8E3074270096562FE7DC0215B4B32659C9EF16835CF6FF9B6A1B8
C2 IP	103.124.105[.]78

MITRE ATT&CK

Technique	ID	Description
User Execution: Malicious File	T1204.002	Victim opens the VBScript from the remote share
Command and Scripting Interpreter: Visual Basic	T1059.005	VBS launches the chain
Command and Scripting Interpreter: PowerShell	T1059.001	Stager downloads the interpreter and payloads
Command and Scripting Interpreter: AutoHotKey & AutoIT	T1059.010	DarkGate loader runs as an AutoHotkey script
Ingress Tool Transfer	T1105	Interpreter, decoy and script pulled from the staging host
Application Layer Protocol: Web Protocols	T1071.001	HTTP beacons to the C2

Defender Takeaways

Outbound SMB to the internet should be blocked. The VBS reached the victim through a UNC path to an external domain. Dropping TCP 445 (and WebDAV fallback) at the perimeter would have broken the first step.

Script host launches from network paths deserve an alert. wscript/cscript opening a .vbs from a remote share, followed by a PowerShell child making web requests, is a short and distinctive process chain.

A legitimate interpreter dropped to disk is still an indicator. AutoHotkey on a host that does not use it, run against a freshly written .ahk file, is the actual malware execution. Allowlisting or alerting on non-standard interpreters catches it.

Plain HTTP beacons with a static user-agent are huntable. Repeated GET / to one external IP with an identical browser user-agent is easy to baseline in proxy or NetFlow data.

Conclusion

The attacker needed one opened script to reach a DarkGate RAT beaconing from the victim, and every stage after it used a legitimate interpreter and plain HTTP. The whole chain is visible in a single packet capture, and the detection value sits in the odd sequence of SMB, script host, PowerShell and AutoHotkey rather than in any single binary.