Domain Controller Replication Anomaly During a Ransomware Alert
At 02:10, the SOC receives ransomware notes on three file servers and an EDR alert for LSASS access on a workstation belonging to a logistics planner. At 02:25, monitoring shows a domain controller writing SYSVOL changes outside the maintenance window, and a service ticket with a 10-year lifetime was issued to a nonexistent account. The enterprise has 2,800 endpoints across two sites; the mission-operations enclave depends on the same Active Directory for authentication, and a 24-hour planning cycle is underway. Backups are 52 hours old, with one immutable copy at an offsite vault. The incident commander wants to unplug all three domain controllers immediately. The mission owner warns that doing so will halt the planning cycle and may cause a safety review. The VIP laptop of the deputy commander is missing from asset inventory. You must decide containment, evidence preservation, and whether to rebuild or clean.
1. What is the most likely attack path, and what evidence supports it?
Read the worked answer
The strongest hypothesis is domain-wide compromise leading to golden-ticket persistence. The 10-year service ticket issued to a nonexistent account is not normal; Kerberos tickets have finite lifetimes, and a decade-long lifetime suggests a forged ticket or a manipulated policy. SYSVOL changes outside the window suggest a compromised DC or a malicious Group Policy. LSASS access on the planner's workstation is consistent with credential theft. Alternatives include a broken replication script, a misconfigured admin tool, or a legitimate long-lived service account. Check the KRBTGT password age, the ticket encryption type, the account's existence, and whether SYSVOL changes map to a new GPO. Three independent signals raise confidence, but do not declare a golden ticket until you validate the ticket signature and the KRBTGT hash. The missing VIP laptop is a separate containment problem and could be the initial access vector.
2. Recommend a containment sequence and evidence-preservation steps.
Read the worked answer
Sequence matters. First, capture volatile evidence from the suspect DC and the workstation: memory, Kerberos ticket cache, SYSVOL diff, event logs, and network connections. Then isolate the workstation at the EDR layer and block known C2 at the proxy. Do not unplug all three DCs at once; that destroys evidence and can halt authentication. Isolate the compromised DC after capture, keep one validated DC if possible, and force replication from a clean backup only after checking. Reset KRBTGT twice with a replication interval, rotate service account passwords, and invalidate tickets. Rebuild the compromised DC from known-good media rather than cleaning in place; a golden ticket can survive cleanup. Preserve the immutable backups and do not restore over evidence. Document every action for the incident report and the mission owner.
3. The mission owner objects because the planning cycle will halt. How do you decide?
Read the worked answer
The mission owner is right about impact but wrong to let it drive containment. This is a commander's risk decision: temporary loss of the planning cycle versus domain-wide adversary persistence that can read or alter plans. Present options: (1) immediate isolation of the compromised DC with a four-hour authentication workaround using cached credentials and a local emergency account; (2) a two-hour delay to capture evidence and build a clean DC; (3) no containment, which is unacceptable. Recommend option 1 with a mission-owner representative in the incident command. The safety review can run in parallel; if the planning cycle has safety-of-life dependencies, document and mitigate them. The incident commander should not unilaterally halt a mission system, but should not wait for perfect evidence either. Escalate to the joint commander if the mission owner refuses.