Ransomware-Like Encryption With a Critical ERP Server
At 02:14, Cortex XSIAM raises a high-severity issue for 12 Windows hosts. Telemetry shows a signed but unusual process creating 200 files with the .locked extension in 90 seconds, deleting volume shadow copies, and reading LSASS memory. One host is the ERP application server (business-critical, 2 TB database); three are domain controllers; the rest are user laptops. The ERP server has an EDR agent but is exempt from automatic isolation by policy. Backups run nightly at 01:00 and complete at 03:30; the last successful restore test was 45 days ago. Legal has placed a hold on all endpoint data because of a pending investigation. The SOC has 8 analysts, and the on-call lead is unavailable for 20 minutes. You must contain the incident, preserve evidence, and avoid stopping production if possible.
1. What are your first actions in the first 15 minutes, and in what order?
Read the worked answer
First 15 minutes: declare a major incident, page the backup on-call, and start evidence capture before containment. Use live terminal or a collection task to capture memory, running processes, network connections, scheduled tasks, and recent file writes from at least one user laptop and the ERP server, and copy the output to a forensic share. Isolate the user laptops through XSIAM endpoint isolation; the agent channel remains available for investigation. For the three domain controllers, do not isolate all three at once because that can break authentication and logging; block the malicious hash/process, disable any compromised accounts, and isolate one DC only if lateral movement is confirmed. For the ERP server, coordinate with the application owner before isolation. Block known C2 indicators at the firewall and preserve logs. Do not reboot.
2. Should the ERP server be isolated immediately? Explain the tradeoff and alternatives.
Read the worked answer
The ERP server needs a business-impact decision, not an automatic one. If encryption is still active, containment outweighs uptime; capture memory first, then isolate and accept the production outage. If encryption has stopped or the process is blocked, use compensating controls: restrict the server with firewall or switch ACLs to only the app tier and backup network, block the malicious hash, remove persistence, and monitor for new file writes. The policy exemption does not mean no action; it means the SOC lead must document the tradeoff. Because the backup window overlapped the incident, do not assume the ERP backup is clean. Verify an earlier immutable copy before any restore. Domain controllers should be handled as a separate containment track because isolating them can cause a wider outage.
3. How do you reconcile legal hold and evidence preservation with eradication and recovery?
Read the worked answer
Legal hold changes the order: preserve first, eradicate later. Do not reimage or delete files until forensic copies and XSIAM telemetry exports are complete. Quarantine rather than delete where possible, and record chain of custody. The backup timing is a trap: the incident began at 02:14 during the 01:00-03:30 backup, so the latest backup may contain encrypted or inconsistent data. Validate backup integrity and prefer an earlier immutable snapshot. After evidence capture and containment, rebuild affected hosts from known-good media, reset privileged credentials, and rotate KRBTGT if domain compromise is confirmed. Restore in a segmented network and verify no re-infection before reconnecting to production.