Ransomware via Active Directory Lateral Movement

Attack timeline

**Hour 0:** Phishing email delivered to finance department. Macro-enabled document executed a PowerShell stager. Initial access established under the context of a finance analyst account with standard domain user permissions.

**Hour 0-1:** Discovery phase. The attacker enumerated service principal names across the domain using the compromised account. 23 service accounts with SPNs were identified. All were eligible for Kerberoasting.

**Hour 1:** Kerberoasting. Service tickets requested for all 23 accounts. Three hashes cracked within 2 minutes using a GPU rig and a targeted wordlist. The cracked account - svc_backup_prod - had Domain Admin membership via a nested group chain that predated the current IT team.

**Hour 2-3:** Privilege escalation. With Domain Admin, the attacker enumerated all domain-joined endpoints. GPO modification used to deploy a ransomware payload via scheduled task. The payload was signed with a legitimate code-signing certificate acquired from a compromised build server.

**Hour 4:** Deployment. Ransomware executed across 347 endpoints simultaneously. Endpoint protection bypassed on 87% of machines because the GPO-deployed scheduled task ran under SYSTEM context before the EDR agent had loaded post-reboot.

Why it succeeded

Three compounding failures:

**Service account hygiene.** The cracked account had not had its password changed in 22 months. It was in a "will break something if we change it" category that nobody had resolved. It had Domain Admin through a group nesting path that appeared in no access review because the tooling reviewed direct group memberships, not transitive ones.

**No detection on Kerberoasting.** The environment had Splunk with a reasonable rule set. Kerberoasting detection was present for RC4 tickets. The cracked account used AES-256 by default; the rule did not fire. Volume-based detection would have caught it but had not been tuned.

**GPO as a deployment vector.** The detection stack had strong endpoint process monitoring. It had nothing monitoring GPO changes. The scheduled task creation happened at the domain controller level before any endpoint agent saw it.

What detection should have been

The Kerberoasting detection gap was closeable: a volume-based rule on TGS-REQ events from a single account within a short window would have flagged the bulk request. The GPO modification would have required DC-level event log monitoring (Event ID 5136, directory service changes) - present in most SIEM content libraries, not deployed in this environment.

The cascade from phishing to domain compromise in 4 hours is fast but not unusual. Each step used well-documented techniques with well-documented detection patterns. The issue was not that the patterns didn't exist; it was that they weren't deployed.