Ransomware at 08:40 with Domain-Joined Backups
At 08:40 on a Monday, 60 of 900 Windows endpoints begin showing .locked files and a ransom note. By 09:20 all 60 are encrypted; the helpdesk has 140 calls. The file server share is also affected. Backups run nightly to a NAS that is domain-joined and reachable from the server VLAN; the last successful backup was Sunday 18:00. A separate immutable cloud backup completed Sunday 22:00 and has not been tested for restore. EDR shows PsExec-style service creation from 10.0.8.21, a workstation, to the 60 hosts, and RDP logons from a shared helpdesk account over VPN. The attacker appears to still be active. The CEO asks whether to pay, restore, or rebuild, and demands a 4-hour restoration.
1. Give the immediate containment order and the reasoning for each step. Why is identity containment ahead of host isolation?
Read the worked answer
Contain in this order: identity, then lateral path, then hosts.
- Disable the shared helpdesk VPN account and force re-authentication for all VPN users; the attacker is using it.
- Block SMB 445, RDP 3389, and PsExec-style service creation between workstation and server VLANs at the firewall; EDR shows workstation-to-host service creation.
- Network-isolate the 60 encrypted hosts and 10.0.8.21 via EDR, but leave them powered on for memory and evidence where feasible.
- Preserve domain controller security logs, EDR telemetry, VPN logs, and firewall logs before they roll.
- Do not wipe yet; the encrypted hosts still contain the ransom note, the encryptor binary, and possibly keys.
Why identity first: the attacker is still active and the shared account gives re-entry. Isolating hosts without cutting the account lets them re-infect restored machines. Why not shut down: shutdown may destroy memory-resident evidence and does not stop domain-level access.
2. Which backup should be used, and how do you validate it before restore? What is a realistic timeline to give the CEO?
Read the worked answer
Restore only from the immutable cloud backup, after validation, and not within 4 hours. The NAS is domain-joined and reachable from the server VLAN, so it is inside the blast radius; its backups may be encrypted or tampered with. The cloud copy at Sunday 22:00 predates the incident and is immutable, which makes it the right source.
Validation before restore: mount the backup in an isolated network, scan it, boot one test host, and confirm no persistence (scheduled tasks, services, run keys) and no attacker credentials. Check the backup catalog for deletion or tampering. If the backup contains the same PsExec service or the shared account's credentials, restoring re-introduces the access.
Realistic timeline: 60 endpoints plus a file server is not a 4-hour restore. Set expectations: identity containment and clean backup validation first, then tier-1 servers, then endpoints in waves. The CEO's 4-hour demand conflicts with evidence; explain the tradeoff in writing rather than promising it.
3. What would you hunt for before restoring trust, and what would change the recovery strategy?
Read the worked answer
Hunt for persistence and re-entry before restoring trust.
- Identity: all sessions and tokens for the helpdesk account, new accounts, changes to VPN groups, and MFA device enrollments.
- Host: services created with random names, PsExec service artifacts, scheduled tasks, WMI event subscriptions, and run keys on the 60 hosts and 10.0.8.21.
- Domain: 4720, 4728, and 4732 account and group changes, 7045 service installs, and 4624 type 10 RDP logons from unusual sources.
- Network: outbound connections from the encrypted hosts before encryption, and any beacon still active from hosts that were not encrypted.
Prevent re-entry: rotate all privileged and shared credentials, remove the shared account, require MFA on VPN, restrict RDP to a jump host, and segment backup storage from the domain. Decision point: if persistence is found in the domain or backup catalog, do not restore into the existing domain; rebuild tier-0 first. Paying the ransom is a business decision, but it does not remove the need to evict the attacker.