Everyone talks about containment like it's a big red button you push after the alarm sounds. That's a fantasy built on vendor demos where the infected machine is conveniently sitting alone in a lab. In the real world, your first ransomware case is a frantic, time-pressured mess where the biggest risk is your own response making things worse.
The goal here isn't to stop the initial encryption—that's already happening. It's to prevent the 'patient zero' host from becoming 'patient zero through fifty' via lateral movement. Cortex can do this, but its default alert-to-workflow pipeline is too slow. You need to bypass human approval for this specific case.
First, isolate the endpoint. The standard 'isolate' action is too heavy; it severs all network connectivity, which can tip off the attacker and destroy your evidence collection. Instead, you want containment. Create a custom response playbook that triggers on a high-confidence ransomware alert. This playbook should execute two things in immediate sequence:
1. Contain the endpoint using the API command that only blocks new outbound and inbound connections, leaving existing ones for forensic purposes.
2. Immediately run a full IOC scan across all critical assets, focusing on shares and authentication servers, not just endpoints.
The trick is the trigger. Don't rely on the generic 'Malware' alert. You need a specific, high-fidelity correlation rule looking for the combo of: a process spawning `vssadmin.exe delete shadows`, a rapid sequence of `*.crypt` type file modifications, and an outbound connection attempt to a known C2 category. That's your automated trigger. Any one of those alone is a false positive nightmare.
Now, the part everyone ignores: you must have a pre-defined network quarantine zone and group for these contained hosts. Your playbook should auto-add the contained endpoint to a dynamic tag that forces it into that zone. If your network team hasn't set this up, your containment is just a pretty log entry while the malware spreads via credentialed access.
This isn't a 'set and forget' policy. Test it quarterly with a simulated host. The number of companies that build these automations and then watch them fail in a real incident because a SaaS update changed an API field would make you weep.
Your mileage will vary
You're right about the standard isolate being a sledgehammer. It can corrupt volatile evidence and break the command and control channel you might want to monitor.
Your two-step playbook is solid, but I'd add a critical third step that runs in parallel: immediately snapshot the host's memory and any relevant logs via the API. That containment window where existing connections are live is your best chance to grab artifacts before the attacker realizes they're boxed in.
Also, make sure your high-confidence alert criteria are *extremely* tight. False positives here will cause major disruption. We use a combination of specific binary hash and anomalous encryption behavior before the auto-contain triggers.