SC-010: Nation-State APT — Long-Term Espionage Campaign¶
Scenario Header
Type: APT | Difficulty: ★★★★★ | Duration: 4–6 hours (multi-session recommended) | Participants: 5–10
Threat Actor: APT-X — fictional East Asian nation-state, defense contractor targeting (composite of Volt Typhoon + APT41 TTPs)
Primary ATT&CK Techniques: T1566.001 · T1055.012 · T1016 · T1021.006 · T1048.003 · T1070.004 · T1560 · T1590
Facilitator Note
This scenario spans a simulated 6-month dwell period compressed into a single exercise. The defining challenge is that no single phase generates an unambiguous high-severity alert. The attacker achieves persistence, lateral movement, and slow exfiltration while staying below detection thresholds. Success is measured by whether the team can reconstruct the full kill chain retrospectively — and whether they have the telemetry to do so.
Threat Actor Profile¶
APT-X (internal tracking designation; MISP cluster: intrusion-set--apx-2024) is a Chinese state-sponsored threat group attributed with high confidence to PLA Unit 61486. The group has operated since at least 2017, targeting defense prime contractors, aerospace manufacturers, and research institutions in the United States, United Kingdom, Australia, and Japan.
APT-X is distinguished by extreme operational patience. Average dwell times exceed 180 days before exfiltration begins. The group avoids commercial malware families (no Cobalt Strike, no Metasploit), instead deploying custom implants with modular architecture. Their GHOSTDUST implant family uses legitimate cloud services (OneDrive, Dropbox, GitHub Gist) as dead-drop command-and-control channels — making C2 traffic indistinguishable from normal business use.
The group extensively uses Living-off-the-Land (LOTL) techniques post-exploitation: certutil.exe, wmic.exe, ntdsutil.exe, scheduled tasks for persistence, and native Active Directory tooling for reconnaissance. No offensive security tools are staged on victim systems.
Motivation: Strategic intelligence — ITAR-controlled engineering drawings, program schedules, personnel lists for targeting, technology transfer for domestic production.
Scenario Narrative¶
Phase 1 — Initial Access (Month 0, ~45 min)¶
APT-X spends 3 weeks in reconnaissance before attack. They register partnerlink-contoso[.]com (typosquatting Contoso's legitimate partner portal) and build a profile of Marcus Webb, Senior Program Manager for the classified FALCON project, from LinkedIn, conference presentations, and DOD contractor databases. They craft a spearphishing email appearing to come from a legitimate business partner with a PDF: FALCON_Program_Review_Draft_Q1.pdf.
The PDF exploits CVE-2024-21338 (a zero-day in Adobe Reader's JavaScript engine at the time of the campaign). The exploit executes shellcode that reflectively loads the GHOSTDUST implant directly into memory via process injection into svchost.exe -k netsvcs. No file touches disk. The implant beacons to onedrive.com/personal/ghostd_sync_c2/... — a legitimate OneDrive account controlled by APT-X.
Evidence Artifacts:
| Artifact | Detail |
|---|---|
| Email Gateway | Inbound from info@partnerlink-contoso[.]com — SPF: PASS (attacker configured SPF), DMARC: FAIL — Subject: "FALCON Program Q1 Review — Please Comment" — Attachment: FALCON_Program_Review_Draft_Q1.pdf (SHA256: e3b4f2...) |
| Microsoft Defender for Endpoint | Alert: Suspicious process injection detected — Parent: AcroRd32.exe — Child: injected shellcode into svchost.exe (PID 1844) — Severity: Medium (not high — no known malware family signature match) |
| EDR Telemetry | svchost.exe (PID 1844) establishes TLS connection to onedrive.com:443 — Normal (baseline: svchost connects to OneDrive regularly for sync) |
| DNS Log | Query: contoso-my.sharepoint.com shortly after partnerlink-contoso[.]com — benign-looking sequence |
Phase 1 — Discussion Inject
Technical: The MDE alert fires at "Medium" severity — no high-severity alert is generated because GHOSTDUST has no known signature. Your SOC closes ~40 medium-severity process injection alerts per day, most being false positives from legitimate software packers. What triage criteria would you apply to this specific alert that would elevate it for deeper investigation?
Decision: This is a zero-day exploit. Your forensic investigation will reveal the PDF exploited CVE-2024-21338. Adobe has not yet released a patch (the CVE is only known to APT-X at this stage). You cannot patch. What compensating controls would you implement? Do you notify CISA? Do you notify Adobe?
Expected Analyst Actions: - [ ] Pivot from the MDE alert to parent process: Was AcroRd32.exe spawned by Outlook? (spearphishing indicator) - [ ] Extract the PDF attachment from email gateway quarantine — submit to sandbox - [ ] Check VirusTotal for the PDF SHA256 — (result: 0/72 detections at time of attack) - [ ] Examine svchost.exe (PID 1844) network connections — profile vs. baseline - [ ] Check if the typosquatted domain partnerlink-contoso[.]com exists via passive DNS
Phase 2 — Persistence & Stealthy Reconnaissance (Month 0–1, ~45 min)¶
GHOSTDUST establishes persistence via COM object hijacking (HKCU\Software\Classes\CLSID\{89565275-...}) — a technique that survives reboots without touching common persistence locations (HKLM\...\Run, scheduled tasks, services). The implant beacons every 4 hours with ±20-minute jitter. C2 check-ins are disguised as OneDrive sync traffic: HTTP PUT requests to a 1KB "document" on the attacker's OneDrive.
Over 30 days, APT-X conducts AD reconnaissance entirely with native tools: net group "Domain Admins" /domain, LDAP queries for AdminCount=1 accounts, nltest /dclist, and dsquery * -filter "(userAccountControl:1.2.840.113556.1.4.803:=8192)" to identify service accounts. They map the network topology, identify the FALCON project share server (PROJ-SRV-04), and note that it is accessible via WinRM from Marcus's workstation.
Evidence Artifacts:
| Artifact | Detail |
|---|---|
| EDR Telemetry | svchost.exe (PID 1844) — outbound TLS to onedrive.com — 4h intervals, ±20min jitter — 1KB upload per beacon — 30 days of activity |
| SIEM (LDAP Log) | net.exe executions from WEBBM-WS01: net group "Domain Admins" /domain — net user /domain — Frequency: 1–2 per week — Flag: low-priority |
| Registry Telemetry | HKCU\Software\Classes\CLSID\{89565275-A5F1-...} — InprocServer32: C:\Users\mwebb\AppData\Roaming\Microsoft\Office\addins\msohelper.dll — Created: Day 1 post-infection |
| DNS Log | Baseline 2,200 DNS queries/day from WEBBM-WS01 → increases to 2,800/day by Month 1 (8% above baseline — within normal variance) |
Phase 2 — Discussion Inject
Technical: APT-X uses COM hijacking in HKCU (user hive) rather than HKLM. Why does this make detection harder? What detection rule would catch COM hijacking in HKCU while avoiding excessive false positives from legitimate software?
Decision: You receive a Threat Intelligence report from your ISAC stating "APT-X is actively targeting defense contractors in your sector. Known TTP: COM hijacking, 4-hour beacon cadence, OneDrive C2." You now have a behavioral hypothesis. Do you immediately hunt for COM hijacking artifacts across all 3,000 endpoints? What is the risk of tipping off the adversary if they have visibility into your detection activity?
Expected Analyst Actions: - [ ] Write a KQL hunt query for COM hijacking in HKCU across all endpoints - [ ] Write a beacon detection query: group outbound traffic to OneDrive by host, flag 4h intervals - [ ] Correlate LDAP query volume anomalies with the endpoint running those queries - [ ] Identify the msohelper.dll file and submit to sandbox — is it signed? (Result: unsigned, no legitimate Microsoft DLL by this name)
Phase 3 — Lateral Movement & Data Staging (Month 1–4, ~60 min)¶
APT-X uses WinRM (winrm.cmd) from Marcus's workstation to connect to PROJ-SRV-04 — the FALCON project file server. WinRM is enabled by Group Policy for IT management; the connection uses Marcus's legitimate credentials (obtained via keystroke logging built into GHOSTDUST). No pass-the-hash, no Kerberoasting — purely credential-based lateral movement that appears identical to legitimate remote administration.
On PROJ-SRV-04, APT-X locates and accesses 14 ITAR-controlled engineering drawings and 3 classified program schedules (marked FOUO). Files are staged in C:\Windows\Temp\~dfca4c.tmp (timestomped to match Windows Update cache files). The attacker compresses the collection with a custom tool named tmdump.exe (masquerading as a Windows Memory Diagnostic utility). Exfiltration occurs via DNS-over-HTTPS to cloudflare-dns.com — each DNS query encodes 32 bytes of exfiltrated data. 100MB/week exfiltration rate — total: 400MB over 4 months.
Evidence Artifacts:
| Artifact | Detail |
|---|---|
| Windows Security Event Log (PROJ-SRV-04) | EventID 4624 Type 10 (Network logon) — Source: WEBBM-WS01 (10.1.2.45) — Account: mwebb — Month 1 Day 3, 02:17 UTC |
| WinRM Log (PROJ-SRV-04) | WSMan provider session established — ClientIP: 10.1.2.45 — Authentication: Kerberos |
| DNS Resolver Log | WEBBM-WS01 — DoH queries to 1.1.1.1:443 — Volume: 8,400/day (baseline: 2,200) — Query names: randomized subdomains of cdn-files[.]cloudflare-assets[.]net |
| File System (PROJ-SRV-04) | C:\Windows\Temp\~dfca4c.tmp — Created Month 1 Day 3 — Timestamps modified to 2024-08-14 (Windows Update date) — File size: 412MB compressed |
| DLP (if deployed) | No alert — ITAR-classified files have no DLP label applied (gap: classification labeling not enforced) |
Phase 3 — Discussion Inject
Technical: APT-X exfiltrates via DNS-over-HTTPS (DoH) to 1.1.1.1, bypassing traditional DNS monitoring. What detection strategy could identify this? (Consider: what is abnormal about DoH query volume from a single endpoint? What network control would force all DNS through an inspectable resolver?)
Decision: You've now identified that 400MB of ITAR-controlled data has been exfiltrated over 4 months. ITAR violations carry criminal penalties. You must notify: (1) your General Counsel, (2) the Directorate of Defense Trade Controls (DDTC) within 60 days, (3) DOD contracting officer. Your CEO is asking whether to notify publicly. What is your recommended sequence and timeline?
Expected Analyst Actions: - [ ] Pull all WinRM connections to PROJ-SRV-04 for the past 6 months — identify anomalous source-time combinations - [ ] Recover the staged file ~dfca4c.tmp from PROJ-SRV-04 and identify contents - [ ] Analyze DoH traffic: volume anomaly + random subdomain pattern = DNS tunneling indicator - [ ] Identify tmdump.exe — PE analysis, signing certificate, compile timestamp, imphash - [ ] Scope all accessed ITAR-controlled files — prepare DDTC notification
Phase 4 — Detection & Supply Chain Pivot Attempt (Month 6, ~45 min)¶
IT's routine 90-day password rotation cycle resets Marcus Webb's credentials. GHOSTDUST loses access — the C2 channel goes silent. APT-X attempts re-infection via supply chain: they compromise a tier-2 software vendor DevSuite Inc. that supplies Contoso's build environment. They inject a backdoored update into DevSuite Compiler v4.2.1 — the update binary is signed with DevSuite's legitimate code signing certificate (which APT-X stole in a prior operation).
The update is blocked at Contoso by Windows Defender Application Control (WDAC), which enforces an allow-list of signed publishers. A WDAC block event fires in the Security Event Log. An alert-hungry junior analyst notices the block, escalates, and the SOC initiates a retrospective investigation — pulling 6 months of EDR telemetry from Marcus's workstation and discovering the full GHOSTDUST campaign.
Evidence Artifacts:
| Artifact | Detail |
|---|---|
| WDAC Event Log | EventID 3077 — DevSuite_Compiler_Update_4.2.1.exe — Publisher: DevSuite Inc. (valid cert) — Policy block: Binary not on allow-list — Month 6 Day 1 |
| EDR Retrospective | GHOSTDUST C2 beacon to OneDrive — 4h interval — visible in EDR telemetry from Month 0 Day 1 through Month 6 Day 0 — Total: 1,080 beacon events |
| COM Persistence | msohelper.dll found on WEBBM-WS01 — 6 months post-initial-compromise — No antivirus detection in 6 months (0/72 VirusTotal at discovery) |
| PROJ-SRV-04 Forensics | Memory dump reveals tmdump.exe execution artifacts — PrefetchFile: TMDUMP.EXE-A4B3F2C1.pf — Confirms 14-file access sequence |
Phase 4 — Discussion Inject
Technical: The WDAC block used a publisher-based allow-list rule. APT-X used a legitimately signed binary (stolen cert). What WDAC policy level would have blocked this? (Hint: consider hash-based vs. publisher-based vs. file path rules and their trade-offs.)
Decision: Your retrospective reveals GHOSTDUST was present for 6 months before discovery. Your CISO wants to know: "Could we have caught this earlier with the telemetry we had?" Assess honestly: (1) what alerts fired and were missed/downgraded? (2) what telemetry was absent? (3) what would a 30-day retrospective hunt have found if done proactively in Month 1?
Expected Analyst Actions: - [ ] Scope the full 6-month intrusion timeline using EDR retrospective data - [ ] Identify every system GHOSTDUST communicated with or laterally touched - [ ] Notify CISA via CyberSentry or DIB CS (Defense Industrial Base Cybersecurity program) - [ ] Engage a forensic IR firm for independent scope validation - [ ] Notify DevSuite Inc. of the supply chain compromise affecting their signing certificate - [ ] Revoke and re-issue all credentials for users on affected systems
Detection Opportunities¶
| Phase | Technique | ATT&CK | Detection Method | Difficulty |
|---|---|---|---|---|
| 1 | PDF zero-day exploit | T1566.001 | EDR: parent-child process anomaly (AcroRd32 → svchost injection) | Hard |
| 1 | Typosquatted domain | T1566 | Email gateway: DMARC fail + domain age < 30 days | Medium |
| 2 | COM hijacking (HKCU) | T1546.015 | Registry monitoring: new CLSID in HKCU\Software\Classes | Hard |
| 2 | 4h beacon jitter | T1071.001 | Network: periodic connection analysis — coefficient of variation | Hard |
| 2 | LDAP AD enumeration | T1016 | SIEM: high-volume LDAP queries from non-DC source | Medium |
| 3 | WinRM lateral movement | T1021.006 | SIEM: EventID 4624 Type 10 — anomalous time/source | Medium |
| 3 | DoH exfiltration | T1048.003 | Network: block DoH to non-approved resolvers; inspect DNS volume | Hard |
| 3 | Timestomping | T1070.006 | EDR: file created timestamp ≠ MFT $STANDARD_INFORMATION timestamp | Hard |
| 4 | Supply chain binary | T1195.002 | WDAC: block non-allow-listed binaries | Easy (with WDAC) |
Key Discussion Questions¶
- The total dwell time was 6 months. Your EDR had telemetry covering the entire period. What organizational process would have detected this within 30 days via proactive threat hunting?
- APT-X used OneDrive for C2 — a service your organization cannot block. What detective controls are available when you cannot block the C2 channel?
- 400MB of ITAR-controlled data was exfiltrated. What technical control (not policy) would have prevented or detected this data leaving the PROJ-SRV-04 file server?
- The supply chain pivot used a legitimately-signed binary. How would you design a WDAC policy that mitigates this threat while remaining operationally viable for a 3,000-user enterprise?
- The initial MDE alert (Medium severity) was triaged as a false positive. What criteria should your SOC use to escalate process injection alerts involving Adobe Reader, given the high false-positive rate?
Debrief Guide¶
What Went Well¶
- WDAC blocked the supply chain pivot — compensating control worked as designed
- EDR telemetry was preserved and enabled 6-month retrospective reconstruction
- Alert fatigue was the root cause of missed detection — not a telemetry gap
Key Learning Points¶
- Nation-state APT operates on patience timescales — weeks of reconnaissance, months of dwell — traditional alert-based detection optimized for fast-moving ransomware will miss these actors
- Living-off-the-Land makes behavioral detection essential — no malware signature will fire; only behavioral baselines and anomaly hunting can surface LOTL activity
- DoH is a detection gap — many organizations have no visibility into DNS-over-HTTPS and no policy blocking it to non-approved resolvers
- WDAC is highly effective — publisher-based rules + allow-list blocked a signed supply chain binary; hash-based rules would have been even more resilient
Recommended Follow-Up¶
- [ ] Implement proactive threat hunting cadence: minimum monthly hunt using behavioral hypotheses
- [ ] Deploy beacon detection analytics in SIEM (periodic connection analysis with jitter modeling)
- [ ] Enforce WDAC in audit mode → block mode over 90 days; prioritize privileged systems first
- [ ] Block outbound DoH to all resolvers except approved corporate resolver; inspect DNS
- [ ] Enroll in DIB CS (Defense Industrial Base Cybersecurity) program for threat intel sharing
- [ ] Apply ITAR data classification labels and DLP policies to all controlled files
- [ ] Run red team exercise simulating GHOSTDUST beacon pattern — measure detection time