Detecting Active Directory ransomware precursors: stopping lateral movement before encryption

By the time you see the ransom note, the actual attack is already over. The encryption is the last step in a 7-to-21-day campaign that started with credential theft, moved through Active Directory with kerberoasting and lateral RDP, escalated through a service-account or Domain Admin compromise, exfiltrated data, and only then deployed the encryption payload. Stopping the encryption is hard. Stopping the AD attack chain that leads to encryption is tractable — if you know what to look for.

This guide is the detection-and-response playbook for AD ransomware precursors. It's anchored to MITRE ATT&CK and the techniques we've seen in ransomware affiliate playbooks for LockBit, BlackBasta, Akira, Play, and the Scattered Spider toolkits.

The AD ransomware kill chain

The typical chain has six stages, each with a distinct AD signal:

1. Initial access — AiTM phishing, exposed RDP, unpatched edge appliance (Citrix / Fortinet / VPN), or supply-chain compromise. Lands on one workstation as a low-privilege domain user. (T1190 / T1133 / T1566)
2. Discovery — BloodHound / SharpHound enumeration of trust paths, GPOs, ACLs, kerberoastable service accounts, and admin group memberships. Sometimes ADRecon or custom LDAP queries. (T1018 / T1087.002 / T1069.002)
3. Credential access — Kerberoasting service accounts with weak passwords (T1558.003), LSASS dump on the foothold workstation (T1003.001), DCSync against a domain controller (T1003.006), or token theft from a stale session.
4. Lateral movement — Pass-the-hash, pass-the-ticket, RDP using harvested credentials, or PsExec / Impacket wmiexec/smbexec. (T1550.002 / T1021.001 / T1570 / T1569.002)
5. Privilege escalation and persistence — New Domain Admin, AdminSDHolder modification, golden ticket forge, or DCShadow. (T1136.002 / T1484.001 / T1558.001)
6. Impact — Backup destruction, shadow-copy deletion, then ransomware deployment via GPO push, PsExec, or scheduled task. (T1490 / T1485 / T1486)

Stages 2 through 5 are where you have time to act. Each stage produces specific, detectable signals in AD telemetry — and importantly, the sequence of these signals is more diagnostic than any single one in isolation.

Tier-1 signals: high-signal, low-noise events

These are events that have a near-zero false-positive rate when they appear from a non-admin source. If you see one of these and the source isn't a known IT admin workstation or scripted process, treat it as an active intrusion:

• krbtgt password reset (Event ID 4724 / 4781 on a DC, target = krbtgt). Only legitimate scenarios: an IT admin performing the documented recovery process. Outside that, this is golden-ticket recovery or attacker tampering.
• DCSync — replication of secrets from a DC by a non-DC, non-Azure-AD-Connect account. Event ID 4662 with{1131f6aa-9c07-11d1-faa1-00a07c4f51a3} (Replicating Directory Changes All) by an unexpected actor.
• LSASS minidump via COMSVCS — rundll32.exe comsvcs.dll, MiniDump against the lsass PID. No legitimate use.
• Impacket signatures — Default service names from psexec.py, smbexec.py, wmiexec.py on target hosts (named pipes like \\.\pipe\BTOBTO, services prefixed with random characters that Impacket creates).
• AdminSDHolder ACL change — modifications toCN=AdminSDHolder,CN=System,.... This is rare in legitimate ops and almost always indicates persistence.
• Honey-token authentication — if you've deployed decoy accounts (highly recommended), any auth against them is a hard signal.

Tier-2 signals: the sequence patterns that catch real attacks

The most useful detections aren't single events — they're sequences. Single events get drowned in noise. Sequences identify intent.

Examples of high-value sequences:

• Recon → Kerberoast → Lateral — A user account performs LDAP queries enumerating SPNs, then requests Kerberos service tickets for multiple SPNs (4769 events with TGS-REQ to many SPNs from a non-admin workstation), then within hours that account authenticates from a different host (4624 logon type 3) using a service account credential.
• Foothold → LSASS → DCSync — A workstation runs a credential-dumping tool, then within minutes a DCSync event appears using a credential that resides on that workstation.
• RDP burst — A single source host initiates RDP to more than 5 distinct target hosts within an hour. Even with admin creds, this is uncharacteristic for IT operations.
• GPO push of ransomware — A GPO modification (4719) is followed within minutes by mass startup-script or scheduled-task execution (4698) across many endpoints.

Sequence-based detection is what CICADA's Tier-2 engine does — the shipping pattern library covers 42 of these chains, including the ones above.

Domain-controller-aware detection

A common false-positive trap: treating any DC-targeted activity as suspicious. DCs legitimately read replication metadata, propagate group policies, and authenticate machine accounts — all the time. The fix is to make detection DC-aware: any Tier-1 signal sourced from a DC itself is almost always benign; the same signal from a workstation is high-confidence malicious.

Maintain a list of DC hostnames (canonical names + AD computer objects), and gate Tier-1 detections on the source host. Without this, kerberoasting and DCSync detections drown in DC-internal noise.

Tier-3 signals: behavioural baselines (UEBA)

Once you have Tier-1 and Tier-2 covered, the next layer is per-user behavioural baselines: what does normal look like for this user, and what's anomalous?

Useful baseline metrics:

• Logon-host diversity — normal users log on to 1-3 hosts per week; admins to 5-15. A user suddenly authenticating to 30 hosts in a day is suspicious.
• Logon-time distribution — a user who normally works 09:00–17:00 local time suddenly authenticating at 03:00 from a workstation that's not theirs.
• Privilege use — an admin who normally uses their tier-2 account for sensitive operations suddenly using their tier-0 (Domain Admin) account for tier-2 work, or vice versa.
• Service-account access pattern — service accounts should only authenticate from specific hosts. Service-account authentication from a user workstation is almost always credential theft.

Service accounts and admins should be on separate baseline rules. Admin accounts have wider variance; service accounts have very narrow variance. Mixing them up either over-alerts or misses both.

Containment when you find the chain mid-attack

Containment for an AD intrusion in progress has a strict order. Doing it wrong accelerates the attacker:

1. Identify the scope first. Don't reset passwords until you know which credentials are in play. Resetting one credential while leaving others exposed tips the attacker without removing access. Use BloodHound backwards — from the compromised entity, where could the attacker move?
2. Isolate the foothold host(s) — network isolation, not shutdown. Shutdown destroys memory artefacts you need.
3. Reset compromised credentials in bulk and simultaneously. Every kerberoasted service account, every admin account that authenticated from a compromised host, every account whose hash was on a dumped LSASS.
4. Double-reset krbtgt — if there's any chance of a golden ticket. Run the documented two-reset process with the right delay; one reset doesn't invalidate forged tickets if the attacker also has the prior krbtgt hash.
5. Hunt for persistence — AdminSDHolder ACL changes, unexpected GPOs, new scheduled tasks on DCs, SID history additions, DCShadow-style edits. Persistence survives credential resets.
6. Verify backup integrity — the attacker may have already tampered with backup credentials or destroyed shadow copies. Restore-readiness is the difference between an incident and a catastrophe.

Hardening: what actually moves the needle

• Tiered admin model (T0/T1/T2). Domain Admin accounts only on DCs and PAWs, never on workstations. Most ransomware chains end the day this is enforced.
• Service-account hygiene — gMSAs for everything possible. Strong passwords (>25 chars) on the remaining shared service accounts. Audit SPNs and disable kerberoastable SPNs you can't justify.
• LSASS protection — RunAsPPL + Credential Guard on every Windows endpoint. Stops most off-the-shelf credential dumpers.
• Disable WDigest, NTLM where possible, and legacy protocols.
• SMB signing required tenant-wide. Stops most SMB-relay attacks.
• Restrict RDP via host-based firewall + Conditional Access for remote admin. Bastion or PAW-only RDP into tier-0.
• Tamper-proof backups — immutable, air-gapped, regularly tested. The single highest-impact ransomware control after tiered admin.

Doing this with tooling

Detecting Tier-1 events from event logs is doable with KQL, Sigma, or Splunk searches. Detecting Tier-2 sequences is significantly harder because it requires stitching events across hosts and time with actor-grouping logic. UEBA baselines on top of that require months of data and a tuning loop.

CICADA IR ships a four-tier behavioural scoring engine with 42 sequence patterns out of the box (DCSync, kerberoasting, Impacket, golden-ticket, LSASS minidump, AdminSDHolder, and more), DC-aware gating, per-user UEBA baselines with service-account separation, and a DEMO “AD Lateral Movement → Ransomware Precursor” investigation that walks through this entire chain. See Getting Started or the Entra compromise workflow for the identity-side counterpart.