Ransomware With Domain Admin: The First 24 Hours
Drayton Freight runs dispatch and warehouse operations for 900 vehicles from a single data center. At 02:10 on a Tuesday the security operations center received an EDR alert for a credential-dumping tool on a finance workstation. By 08:00, 40 of 62 Windows servers had been encrypted with a ransom note demanding payment in 72 hours. The EDR console was reachable and 12 servers remained clean. Backups run nightly to a NAS joined to the same domain, and to an object-storage bucket whose credentials sit on the backup server; a third copy is written weekly to tape and stored offsite, with the last tape from six days ago. Dispatch is running on paper, and the company faces contractual penalties of USD 40,000 per day for missed deliveries. Forensics later establish that the attacker held domain administrator rights for 11 days before the encryption event, obtained through a help-desk password reset call. Legal asks whether notification is required and when.
1. Order the response actions for the first 24 hours and justify why that order, rather than isolating hosts first.
Read the worked answer
Isolating the encrypted hosts first feels right and is close to useless, because the attacker who encrypted them still holds domain administrator rights and can do it again.
1. Establish scope from telemetry. EDR and network flow data tell you which hosts are encrypted, which are clean, and where the operator account has been. You cannot contain what you have not enumerated, and the 12 clean servers are the recovery seed.
2. Break the identity plane. Reset the krbtgt account twice (with the inter-replication interval observed), disable or rotate every privileged account, revoke sessions and refresh tokens, and disable the help-desk path that was abused. Until this is done, network containment is cosmetic.
3. Contain the network at a coarse boundary, then by host, prioritizing the clean servers so they are not lost during step 2. Keep the EDR console reachable out of band.
4. Preserve evidence before wiping anything: memory images where valuable, logs, EDR telemetry exported off-network, and the ransom note itself.
5. Stand up the incident command with business, legal, insurer, and communications in the same room. The paper dispatch process is keeping revenue alive; decide explicitly which systems stay offline even after restoration.
6. Treat the ransom decision as a business, legal, and insurer decision, not a technical one. A 72-hour deadline is pressure, not a reason. Screen the actor against sanctions lists, assume no reliable decryptor, and note that payment funds the next intrusion. The recommendation should be restore-from-backup unless recovery is proven impossible.
2. The six-day-old offsite tape is the only copy outside the attacker's reach. How do you decide whether it is safe to restore?
Read the worked answer
Ask what the attacker could reach, not just when the backup was taken. The nightly NAS is domain-joined and the object-storage credentials sit on the backup server, so assume the attacker could read, alter, or delete both; treat them as compromised until proven otherwise. The offsite tape is the only candidate because it is offline and physically out of the attacker's hands.
But six days sits inside the 11-day domain administrator dwell, so the tape may include systems the attacker had already touched. Do not restore it onto the production network.
Restore into an isolated environment: separate VLAN, no route to production, no domain membership, its own DNS. Prioritize dispatch and warehouse data over system images. Rebuild operating systems from known-good media and restore data rather than restoring domain controllers or servers wholesale; a restored domain controller reintroduces whatever persistence existed.
Then verify before reattachment: look for unexpected local accounts, scheduled tasks, services, startup items, new Group Policy objects, and anomalous certificates; run a full EDR and offline scan; check file integrity on restored data. Rotate every credential the restored systems will use, including service accounts, and reset krbtgt again if any domain controller was restored.
If verification cannot be completed within a tolerable window, run the business on the paper process and a minimal clean build longer, and say so in writing rather than restoring a suspect image under deadline pressure.
3. Which control failures enabled this outcome, and how does the notification timing question interact with the forensic timeline?
Read the worked answer
Four failures, in the order that matters:
- Help-desk identity verification. A reset granted on a phone call is the root cause. Fix with a documented verification standard (callback to a manager on record, or a video/ID check for privileged resets), MFA enrollment tied to the reset, and no help-desk ability to reset privileged accounts at all.
- Flat privilege. Domain administrator rights should never be the working credential for routine administration. Tiered administration (tier 0 domain controllers, tier 1 servers, tier 2 workstations), privileged access workstations, and just-in-time elevation for the few people who genuinely need it would have contained the intrusion to one tier.
- Backup architecture. 3-2-1-1-0 with one immutable, offline copy; backup infrastructure not domain-joined; credentials not stored on the backup server; and restore tests on a schedule so that recovery is a rehearsed procedure rather than an experiment.
- Detection and response. The EDR alerted at 02:10 and encryption completed by 08:00. Automated containment rules and a tested after-hours call tree shorten that window.
On notification: the legal clock is not paused because scope is unproven. Regulator and contractual deadlines run from awareness of the incident, and awareness existed at 02:10. Legal should assume notification is required unless counsel documents otherwise, and should not wait for a final record count. Forensics should produce a defensible population estimate on a schedule that fits the deadline, and the first notification can state that the investigation is ongoing as long as it is not misleading. Also check the ransom actor against sanctions lists before any payment discussion reaches a decision point, since that changes the legal analysis entirely.