AI Agents During Ransomware Response: What to Automate First During ransomware response, speed matters but a wrong action can destroy evidence. Use an AI agent for coordination first, then add controlled response.
AI Agents During Ransomware Response: What to Automate First
During ransomware response, speed matters but an incorrect action can destroy evidence or widen the outage. Use an agent first for coordination and evidence, then add controlled response.
First: build the incident picture
Collect affected assets, identity activity, timeline, known indicators, and backup status into one reviewable view.
Next: coordinate bounded actions
Prepare isolation candidates, ticket updates, stakeholder summaries, and evidence checklists. Require approval before disruptive containment.
After containment: learn
Generate a timeline, identify control gaps, and turn confirmed findings into detections and playbook improvements.
Order the steps by what a wrong move costs
CISA's #StopRansomware Guide shows the trade-off: isolate impacted systems immediately, take the network offline at the switch level if several subnets look hit, and power a device down only when it cannot be disconnected, because that loses volatile-memory evidence.
In ransomware a wrong move is paid for twice, in downtime and in lost evidence, while the clock keeps running, so every step gets a class: read-only steps and evidence copies run at once, reversible changes wait for a named approver, and irreversible steps that touch production or carry legal or business liability stay with people. This order is our recommended pattern; CISA's starts with isolation.
The runbook, ordered by reversibility
Row numbers group steps by risk; they are not a queue. On an encryption alert, request the row 6 approval as soon as an endpoint is confirmed and let rows 1 to 5 fill its packet in parallel.
Step Reversible? Class (recommended) Evidence to preserve first 1. Scope: hosts, accounts, detections behind the alert Read-only Autonomous Raw alerts, event IDs, timestamps 2. Recovery state: backups, shadow copies, vssadmin/wbadmin/bcdedit misuse Read-only Autonomous Backup job history, catalogue as first seen 3. Way in: new or escalated-privilege accounts, odd VPN sign-ins, remote-management tools Read-only Autonomous Auth and VPN logs, copied off-host 4. Data leaving: unusual outbound volume, Rclone, web file storage Read-only Autonomous Firewall and proxy logs, exported before buffers roll 5. Copy evidence to protected storage, open the case, page the incident commander Copy yes; a sent page stays sent Autonomous Incident record: queries, results, who ran them 6. Isolate a confirmed endpoint via your EDR connector Yes (release); lost uptime stays lost Approval EDR detection, process tree, connections, exported first; memory capture if supported 7. Block a confirmed C2 or exfiltration destination on the firewall Yes; may cut a service in use Approval Firewall log export, indicators with source 8. Disable attacker accounts, revoke sessions, close their remote access Re-enable yes; revoked sessions stay gone Approval Sign-in logs, sessions, group memberships 9. Shut down or power off hosts No, memory is lost Blocked Memory capture of sample hosts 10. Restore or rebuild from offline backups Hard once overwritten Blocked Backup date vs first sign of compromise; dropper check 11. Decide on any ransom No Blocked Ransom note as received; law-enforcement input, including on decryptors 12. Communicate externally: customers, regulators, insurer, media No Blocked Approved fact sheet: known and unknown
Before each Approval row the agent assembles a packet: targets checked against the asset inventory, the change, evidence saved, the release step.
Recommended pattern, per the Human-in-the-Loop SOC matrix: for rows 6 to 8, one approver suffices only for a single non-critical, non-production endpoint or one ordinary account. Anything wider takes two approvers from different roles: production or critical assets, privileged, executive or service accounts, shared infrastructure (the row 7 firewall block included), several targets. Each approver needs a deputy on call and a phone escalation; record any shortcut as a risk-owner decision made beforehand. Request the three together, echoing CISA's coordinated isolation, but never hold row 6 for the others.
What zcr documents and what you configure
Documented in zcr: zcrSOAR sets each playbook step to Autonomous, Approval or Blocked, routes approvals by severity, asset or site and isolates or releases an endpoint through a connector (documented example: SentinelOne). Out-of-the-box playbooks are phishing, malware, brute force and C2 isolation; unapproved playbooks stay in Draft, Test, Dry-run or Simulation Mode until you authorise production. zcrSIEM has out-of-the-box ransomware detection rules; it has no SOAR.
Recommended pattern: build this runbook as a custom playbook, or adapt the malware or C2 isolation one, and prove it in Dry-run. Set rows 9 to 12 to Blocked; people do that work.
Customer configuration: your backup-platform link (row 2; a custom integration if no connector exists), memory capture, evidence storage, EDR, directory, identity provider and firewall actions (rows 6 to 8; check each connector), named approvers, the out-of-band channel.
Where automated response breaks, and who takes over
Do not tip off the attacker. CISA advises coordinated isolation and out-of-band channels such as phone calls, since attackers who notice detection may spread or deploy ransomware first. Email or Teams approval requests may be readable if those accounts are compromised, and none of zcrSOAR's documented notification channels is described as out-of-band, so connect a phone call or paging service yourself (customer configuration).
Attacker text is data. Ransom notes, file names and log fields are attacker-written, and a crafted one can steer a model that reads it as an instruction. Take targets only from structured fields checked against the asset inventory (recommended pattern).
Do not restore in a hurry. CISA warns that ransomware may signal an earlier, unresolved compromise: find the dropper malware before rebuilding from backups.
Stop and hand the case to the incident commander when:
a scoped host stops reporting (a gap in the data)
targets include a domain controller, identity provider, hypervisor, backup server or out-of-scope host
the recovery check finds a deleted catalogue or stopped backup jobs
the target count grows between request and approval
data is found leaving, since notification duties may begin
an isolation call fails or times out, or a request is still unanswered when the agreed window ends (silence never counts as approval)
Frequently asked questions
What if the tools the agent depends on are down or encrypted?
Keep manual versions of rows 6 to 8 that work from the EDR, directory and firewall consoles (from the switch when several subnets are hit). Rehearse them with the same approvers (recommended pattern).
Should the agent isolate a host by itself during encryption?
Start at Approval (our recommended pattern); unattended isolation for a narrow, low-impact class of hosts is a decision for your risk owner, and only once the step meets the bar in AI-Assisted SOC vs Autonomous SOC : reversible, run under Approval for a review period with no approval later reversed, and a tested undo path. Dry-run results alone do not meet it. Since CISA says to isolate immediately, speed the approval up rather than remove it.
Can zcrSIEM or zcrMDR run this response for us?
zcrSIEM detects and investigates; playbooks, approvals and containment belong to zcrSOAR. zcrMDR is a managed service through an approved channel partner, with response actions and coverage set by its service level and agreement.
Sources
Continue: The Limits of Autonomous SOC , Human-in-the-Loop SOC , Automatically Containing a Ransomware-Infected Host — With a Human Approval Gate and the AI SOC Agent guide .
Explore zcrMDR · Compare pricing · Contact zcr
If you'd rather talk through your own environment, here's how to reach us.
Products | Pricing | Resources | Insights | Contact 
