Unpacking DonutLoader — Threat Hunt (Case Lab 1/2)
// ThreatHuntingLabs · writeup
Unpacking DonutLoader — Threat Hunt (Case Lab 1/2)
ThreatHuntingLabs · Threat Hunting · KQL
Case Context
Part of a 2-lab Flash Hunt case on Threat Hunting Labs: Unpacking DonutLoader, from initial execution to data exfiltration. This lab is the Threat Hunt angle (1 of 2), working Sysmon, Zeek and EDR telemetry through a search console rather than touching the artifacts directly.
Threat Hunting Labs has a strict no-public-writeup policy on active labs to protect scoring and leaderboards for other users, so this page is intentionally an overview: what I did and what I found, not the queries or the specific answers that got me there.
A single Windows 11 workstation, one alert on hidden PowerShell in user context, and a process chain running from a command shell through PowerShell into the .NET compiler with a current-user Run key written seconds later. Walking back from that alert put the origin in the user’s own Downloads folder: a batch launcher the user ran themselves, which staged a renamed copy of itself elsewhere in the profile and pointed an autorun entry at the staged path rather than the delivered one. The PowerShell in between read its own launcher file and decoded an embedded stage out of it at runtime, which is what the compiler activity was serving.
From there the hunt split into two phases separated by several hours. A roaming-profile binary masquerading as an update utility dropped and launched a rotating set of randomly-named executables from Temp, each one writing its own autorun value, producing layered persistence under several different value names across two days. The theft phase hit browser credential stores and exported wireless profiles with keys in cleartext, then moved data out on a non-standard port after first calling public IP-discovery services to learn the host’s external address. The detail that reframed the whole case: the first collection pass is attributed to a signed Microsoft system process, not to any of the dropped binaries, so the most aggressive activity on the host carries the cleanest-looking process name in the telemetry.
Techniques Encountered
Nine techniques recorded in the Lessons panel.
| Technique | ID |
|---|---|
| Command and Scripting Interpreter: Windows Command Shell | T1059.003 |
| Command and Scripting Interpreter: PowerShell | T1059.001 |
| Obfuscated Files or Information | T1027 |
| Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | T1547.001 |
| Credentials from Password Stores: Credentials from Web Browsers | T1555.003 |
| Unsecured Credentials: Credentials In Files | T1552.001 |
| Data Staged: Local Data Staging | T1074.001 |
| Application Layer Protocol: Web Protocols | T1071.001 |
| Non-Standard Port | T1571 |
Prioritising Findings — Pyramid of Pain
12 findings, 65% priority. Ten landed in Host Artifacts, with one Domain Name and one IP Address at the base of the pyramid and nothing recorded in Tools or TTPs.
That distribution is the lesson rather than a shortfall. Almost everything this case hands you is cheap for the operator to change: the launcher arrived under one filename and staged itself under another, the dropped executables were randomly named on every run, and the credential-export staging directory got a fresh GUID each time. The durable content was all in the sequencing, which is exactly what the detection-engineering decisions at the end of the lab were testing.
What I Practiced
- Reconstructing a user-context execution chain from process-creation telemetry back to the original user-initiated launch, rather than starting from the alerting process
- Recovering autorun value data from registry-write telemetry instead of inferring persistence from command lines, which mattered because most of the autorun writes never went through a registry utility at all
- Scoping layered persistence written by several different binaries under several value names across two days
- Correlating file-open telemetry to attribute credential-store access to a signed system process, and recognising that as injection rather than a logging artifact
- Separating pre-existing beacon noise from campaign traffic when sequencing outbound connections on a busy host
- Grouping repeated LOLBin invocations by behaviour where every operator-controlled string rotated per execution
- Working a restricted KQL dialect: establishing which operators the sandbox actually permits, then rebuilding queries inside those limits instead of fighting them
- Containment, credential-response and post-cleanup validation decision sets, plus behaviour-first detection logic anchored above the filename and IP tiers
Credential
Grade A, 214 / 236, all 10 branches completed, no hints used, 42 minutes.
This is the Threat Hunt half of the DonutLoader case. The Malware Analysis angle ([[unpacking-donutloader-malware-analysis]]) works the same intrusion from the recovered artifacts in a REMnux workspace.