Detect-Only EDR During Encryption
At 11:38 on a Friday, the service desk receives six calls in four minutes: files on the shared drive are renamed with .locked. EDR shows on five hosts, including FS-01: 47 file renames per minute, vssadmin delete shadows, and SMB connections to TCP 445 from WS-114. Domain controller logs show 4624 type 3 NTLM logons from WS-114 to FS-01 and two backup servers using the svc_backup account. EDR prevention is in detect-only for the file-server OU because a false positive two weeks ago caused an application outage; the policy was never re-enabled. The network is a flat /16 with no internal segmentation. FS-01 hosts payroll data and is in the middle of a backup window. The on-call analyst must decide whether to isolate FS-01, which would interrupt the backup, or isolate WS-114 first. The IR plan says 'contain affected systems' but does not define order.
1. What is your containment order and reasoning? Address the backup-window tradeoff explicitly.
Read the worked answer
Isolate WS-114 first because it is the likely source of SMB-based spread, then isolate the other four affected hosts, then FS-01. In practice, containment must be near-simultaneous: use EDR network isolation in one action across all five hosts plus FS-01 if it is actively encrypting. Do not wait for the backup to finish. A completed backup is not worth continued encryption of payroll data, and an interrupted backup can be rerun; encrypted payroll files may not be recoverable.
Use EDR isolation rather than powering off, because powering off loses memory-resident evidence and may trigger destructive payloads. If EDR isolation is unavailable, disable switch ports or apply an ACL blocking TCP 445 between segments. Because the network is flat, blocking SMB at the core is a temporary emergency control while hosts are isolated.
Do not isolate only FS-01: that leaves the source host free to encrypt other shares. Do not isolate only WS-114: FS-01 may already have an active payload. After containment, disable the svc_backup account and reset its credentials, because it authenticated to backup servers and may be compromised.
2. What evidence do you preserve, and in what order, before remediation begins?
Read the worked answer
Preserve volatile evidence before rebooting or wiping. On WS-114 and FS-01, capture memory if the tooling and policy allow it, plus the EDR process tree, command lines, file hashes, network connections, and SMB session table. Export Security logs for 4624 type 3, 4768/4769, 4672, and 5140/5145 share access. Save the vssadmin command line and parent process, the list of encrypted file extensions and counts, and the ransom note if one exists.
Collect EDR telemetry centrally before containment expires it. Record which accounts authenticated to which hosts, especially svc_backup, and check for new services, scheduled tasks, and remote service creation. Preserve the backup catalog and verify whether backup copies are offline or immutable; do not restore over evidence.
Order: preserve identity and network evidence first, then isolate, then image affected disks if required. Documentation should include timestamps, analyst actions, and chain of custody. Remediation can rebuild hosts, but it cannot recreate the initial infection vector or the stolen credentials if logs are lost.
3. How do you re-enable EDR prevention without causing another outage, and what else must change?
Read the worked answer
Re-enable prevention in a staged way, not by flipping the whole file-server OU at once. First, identify the false positive from two weeks ago, confirm the exclusion with the application owner, and create a narrowly scoped exclusion for the specific process, path, and signer. Then enable prevention on one non-critical file server in the same OU, monitor for 24 hours, and expand in small batches. Keep a rollback path and an on-call contact. The detect-only exception should have had an expiry; add one now.
Beyond EDR, fix the conditions that made this severe: segment the /16 so file servers and backup servers are not reachable from user workstations over SMB; restrict svc_backup to the specific servers and tasks it needs; remove it from interactive logon; and back up with offline or immutable copies. Add an alert for vssadmin shadow deletion and mass file renames, not just malware signatures. Review why the backup window was allowed to overlap an active incident. The goal is defense in depth, because EDR prevention is a control, not the control.