Docs

Appearance

Ransomware Incident Response Playbook ​

Purpose: End-to-end ransomware response procedure — from first alert through containment, investigation, recovery, and HIPAA notification. This playbook ties together all kill chain response runbooks into a single scenario.

Severity: P1 — Critical. Every step in this playbook is time-sensitive.

Owner: Rory Prerequisite reading: runbooks/incident-response.md (general IR principles). This playbook assumes those principles and focuses specifically on ransomware.

Note: This environment experienced a ransomware incident in November 2024. Lessons from that event are incorporated throughout.

Stage 0 — Before It Happens: Readiness Checks ​

Run these monthly during runbooks/monthly-security-review.md:

  • [ ] All kill chain agents running and posting findings to SecOps
  • [ ] Arctic Wolf MDR integration active — verify last heartbeat
  • [ ] Cortex XDR sensors connected on all managed endpoints
  • [ ] EventID 4688 + PowerShell logging confirmed in LAW (spot check KQL)
  • [ ] Backup integrity verified (runbooks/backup-restore-verification.md)
  • [ ] Break-glass credentials tested and current (runbooks/annual-bgkit-verification.md)
  • [ ] Out-of-band comms plan reviewed (runbooks/out-of-band-comms-plan.md) — ransomware may encrypt your email

Stage 1 — Detection ​

Expected First Signals ​

In roughly this order:

  1. Telegram notification — kill chain agents fire CRITICAL (execution, credential dumping, lateral movement)
  2. Arctic Wolf alert — MDR may call before SecOps notification if they detect behavior on endpoints
  3. Cortex XDR incident — behavioral detection on the endpoint (process injection, LSASS access)
  4. Palo Alto DNS Security — C2 callback domain blocked; check firewall threat logs
  5. User report — "files are renamed" or "can't open documents" — this is late-stage, encryption is starting

If only one signal: treat it as high-severity and begin triage. Do not wait for multiple confirmations.

Opening an Incident ​

  1. Open a P1 incident in SecOps immediately: POST /api/incidents with severity=critical, category=ransomware
  2. Start a time-stamped log — record every action with timestamp from this point forward
  3. Notify Rory via phone (not just Telegram) if not already aware — Telegram may be on the compromised device

Stage 2 — Triage (0–15 Minutes) ​

Goal: Determine scope before containing. Containment that's too narrow misses compromised hosts; too broad causes unnecessary downtime.

  1. Pull all active SecOps findings from the last 4 hours — which hosts, which accounts, which kill chain stages have fired?
  2. Check kill chain stage coverage:
    • Execution detected? → runbooks/kill-chain-execution-response.md
    • Persistence? → runbooks/kill-chain-persistence-response.md
    • Credential dumping? → runbooks/kill-chain-credential-dumping-response.md
    • Lateral movement? → runbooks/kill-chain-lateral-movement-response.md
  3. Map the affected hosts — build a list of: confirmed compromised, suspected compromised, clean
  4. Check if a domain controller is in the affected list — DC compromise changes the entire response (all credentials must be treated as compromised)
  5. Check if DDE environment (Medicare PHI app) hosts are affected — if yes, HIPAA breach notification is almost certainly required

Stage 3 — Containment (15–60 Minutes) ​

The November 2024 lesson: delay in containment allowed lateral movement to spread to additional hosts. Contain early, even with incomplete information.

Network Isolation ​

Isolate confirmed compromised hosts first, then suspected compromised:

Via Cortex XDR (preferred — maintains Cortex management channel):

  • Console → Endpoints → [host] → Actions → Isolate

Via Arctic Wolf:

  • Arctic Wolf has act-first authorization for containment without approval
  • Contact via the Arctic Wolf hotline — they can isolate independently if Cortex isolation fails

Do NOT isolate:

  • Domain controllers (unless confirmed as ransomware origin — isolation breaks domain auth)
  • Network infrastructure (firewalls, switches) — contain via firewall rules instead

Firewall Segmentation ​

If the source of lateral movement is identified as a specific IP or segment:

  • Panorama → Policies → Security → add deny rule blocking that IP from reaching the rest of the network
  • If ransomware is communicating outbound (C2): block the destination IP and any known ransomware-related domains in DNS Security

Active Directory ​

If lateral movement is detected and credentials are suspected compromised:

  1. Disable the compromised account(s) in Active Directory immediately
  2. If a DA (Domain Admin) account is compromised: reset all privileged account passwords
  3. If a DC is confirmed compromised: force reset the krbtgt password twice (invalidates all Kerberos tickets)
    powershell
    # Run on the PDC emulator
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (Read-Host -AsSecureString)
# Wait 10 hours (max Kerberos ticket lifetime), then repeat

Cloud Access ​

Revoke Entra tokens for affected accounts:

  • Entra → Users → [user] → Revoke sessions
  • For all accounts with sessions on compromised hosts (see lateral movement KQL)

Stage 4 — Evidence Preservation (Parallel With Containment) ​

Do not destroy evidence before forensics. Run these in parallel with containment:

  1. Disk snapshots before isolation (if possible): az snapshot create --source <disk-id>
  2. Export LAW logs for the affected hosts and the 72 hours before first detection — save to a secure location
  3. Export Cortex XDR incident timeline — screenshot the causality view for each affected host
  4. Firewall session logs from Palo Alto — Panorama → Monitor → Traffic logs for the affected source IPs
  5. Document the blast radius — which hosts, accounts, data were touched

Stage 5 — Investigation (1–24 Hours) ​

Goal: Establish the complete attack timeline and initial access vector.

Timeline Reconstruction ​

Work backward from the first kill chain signal:

kql
// All events on affected hosts 72h before first kill chain detection
SecurityEvent
| where TimeGenerated > ago(72h)
| where Computer in ("<host1>", "<host2>")
| where EventID in (4688, 4624, 4648, 4625, 7045, 4698, 1102, 5140)
| project TimeGenerated, EventID, Computer, Account, NewProcessName, CommandLine
| order by TimeGenerated asc
kql
// Initial access — was there a successful login from a new location or device?
SignInLogs
| where TimeGenerated > ago(72h)
| where UserPrincipalName in ("<affected_account>")
| project TimeGenerated, UserPrincipalName, IPAddress, Location, DeviceDetail,
    ConditionalAccessStatus, RiskLevelDuringSignIn
| order by TimeGenerated asc

Common Initial Access Vectors (from November 2024 lessons) ​

VectorWhat to Look For
PhishingSignInLogs for account; 4688 LOLBin from Office parent shortly after email received
VPN credential theftTwingate logs for first login from new IP; GeoIP anomaly
Exposed RDP4625 brute force followed by 4624 success from external IP
Supply chainGitHub Actions audit log; new workflow runs; dependency changes
Legitimate tool abuseIT admin tool used outside CM window (psexec, remote management)

Ransomware Family Identification ​

  1. Check file extension on encrypted files (if encryption has begun)
  2. Check ransom note filename — ransomware families have distinctive note filenames
  3. Submit a sample to Cortex XDR threat intel or ID Ransomware (https://id-ransomware.malwarehunterteam.com)
  4. Share with Arctic Wolf — they may have seen the strain recently

Stage 6 — Eradication ​

After the full scope is known:

  1. Reimagine all confirmed compromised hosts — do not attempt to clean and reuse; ransomware often leaves backdoors
  2. For Azure VMs: delete and redeploy from Terraform
  3. For physical/unmanaged: clean install, verify firmware integrity before reattaching to network
  4. Reset passwords for all accounts that had sessions on any compromised host
  5. Force-reset krbtgt twice if any DC was compromised (if not already done in Stage 3)
  6. Review and rotate all service account passwords and API keys that were accessible from compromised hosts

Stage 7 — Recovery ​

  1. Restore from last known-good backup before the earliest confirmed compromise date:
    • Azure workloads: runbooks/veeam-restore-procedure.md
    • AWS workloads: AWS Backup restore
    • PostgreSQL: Azure Database for PostgreSQL point-in-time restore
  2. Verify backup integrity before restoring — ransomware may have corrupted backups if it had access to the backup system
  3. Bring systems back online in isolation first, verify clean, then reconnect to production network
  4. Monitor closely for 48–72 hours after recovery — reinfection is common if initial access vector is not fully closed

Stage 8 — HIPAA Notification Assessment ​

Run the 4-factor breach risk assessment per compliance/hipaa-breach-notification-procedure.md:

Questions to answer:

  1. Were any hosts with ePHI access compromised? (Azure PROD systems, DDE environment, psql-secops-prod, SharePoint with PHI)
  2. Did exfiltration occur? (Check runbooks/kill-chain-exfiltration-response.md, Palo Alto traffic logs)
  3. Was data encrypted in place (encrypted = likely accessible to attacker before encryption)?
  4. Can you demonstrate the attacker did not access specific ePHI? (High bar — usually cannot be conclusively demonstrated)

Conservative posture: If you cannot rule out ePHI access, treat it as a breach. The cost of over-notification is low; the cost of under-notification is severe.

Notification deadlines:

  • Individual notification: within 60 days of discovery
  • HHS: concurrent with individual notification (500+ affected) or annual log (<500)
  • Adriana coordinates notification logistics

Stage 9 — Post-Incident ​

Within 72 Hours ​

  • [ ] All compromised systems reimaged and restored
  • [ ] All affected accounts with passwords reset
  • [ ] Initial access vector closed
  • [ ] Arctic Wolf post-incident report requested
  • [ ] Cortex XDR support case opened if sensor was bypassed

Within 30 Days ​

  • [ ] Full incident timeline documented in SecOps
  • [ ] HIPAA breach risk assessment completed and documented
  • [ ] Root cause analysis completed (skills/RootCauseAnalysis)
  • [ ] Lessons learned documented
  • [ ] New detection rules or known-good rules added based on findings
  • [ ] HIPAA risk assessment updated (compliance/hipaa-risk-assessment.md)
  • [ ] IR tabletop findings updated (compliance/ir-tabletop-findings-template.md)

Quick Reference — Key Contacts and Resources ​

Contact / ResourceUse For
Rory (phone)All P1 escalations
Arctic Wolf hotlineContainment, forensics, independent verification
AdrianaHIPAA breach notification coordination
Kevin / GregDR operations, AD if Rory unreachable
HHS OCR portalocrportal.hhs.gov — breach reporting
Palo Alto supportCortex XDR sensor bypass, firewall issues
  • runbooks/kill-chain-execution-response.md
  • runbooks/kill-chain-persistence-response.md
  • runbooks/kill-chain-credential-dumping-response.md
  • runbooks/kill-chain-lateral-movement-response.md
  • runbooks/kill-chain-exfiltration-response.md
  • runbooks/kill-chain-defense-evasion-response.md
  • runbooks/incident-response.md — general IR principles
  • runbooks/backup-restore-verification.md
  • runbooks/break-glass-procedure.md
  • compliance/hipaa-breach-notification-procedure.md
  • runbooks/out-of-band-comms-plan.md

Internal use only — Cirius Group