Incident Response & Ransomware Readiness

The moment the ransom notes appear on every screen is the wrong moment to be reading your incident plan for the first time. The organisations that take catastrophic losses in a ransomware event rarely fail for lack of tooling — they had the EDR, they had the firewall. They fail because nobody had ever run the play under pressure, so the first hour is spent arguing about who can authorise disconnecting the database while the encryption spreads.

Ransomware isn’t a malware problem; it’s a business crisis that happens to start with malware. Finance, Legal, Communications and IT Operations all have decisions to make in the first few hours, and none of them go well improvised. This Incident Response & Ransomware Readiness programme treats response as a core business-continuity function rather than an IT afterthought, and it’s built around three things that decide the outcome: technical teams that can contain damage fast, executives who can communicate without making the legal position worse, and backups that actually restore when everything else is encrypted — which is the one people assume and almost never test.

The Readiness Pillars

Resilience is built, not bought, and it spans six areas that fail as a chain — the weakest one sets your outcome. We assess and strengthen each:

1. Prevention & Hardening: Privileged access management, MFA, and Active Directory tiering to cut the lateral-movement paths ransomware crews use to get from one phished laptop to the domain controller. This is where you buy time, and time is the whole game.

2. Detection & Triage: SIEM and EDR telemetry tuned to catch the pre-encryption phase — Cobalt Strike beacons, mass file access, suspicious AD enumeration. By the time files are encrypting you’ve already lost; the detectable window is the days of quiet recon before it.

3. Containment: The ability to isolate a host or VLAN immediately, without destroying the forensic evidence you’ll need afterwards. These two goals pull against each other — pulling the plug is fast but loses volatile memory — and the playbook has to resolve that tension in advance, not in the moment.

4. Evidence Preservation: Training IT to capture RAM and preserve logs before rebooting. The instinct of a well-meaning engineer is to reboot or reimage the infected machine to “clean it”, and that instinct destroys the evidence that answers whether data was stolen.

5. Recovery: Genuinely testing that backups restore, are isolated from the network, and hit the speed the business needs. An untested backup is a hypothesis, and ransomware crews specifically hunt and encrypt backup servers first.

6. Communication: Out-of-band channels for when email and Teams are down or compromised — because coordinating the response over the same systems the attacker controls tells them exactly what you’re about to do.

The Ransomware Response Workflow

Speed and evidence preservation are in constant tension during a live incident. The playbooks make the trade-off explicit instead of leaving it to whoever’s in the room:

• Phase 1: Verification & Triage — One machine or the whole domain? Wazuh and EDR data establish patient zero and the blast radius. Getting the scope wrong in either direction is costly — under-scope and you contain half the infection, over-scope and you take down clean systems the business needs.

• Phase 2: Network Containment — Isolate infected hosts and VLANs, and critically, disconnect backup infrastructure from the primary domain so the encryption can’t follow. Containment tips off the attacker that they’ve been spotted, which can push a patient operator into burning everything they’ve reached — so it’s a decision with a cost, made deliberately, not a reflex.

• Phase 3: Forensic Preservation — Capture RAM and take bit-for-bit disk images of key systems before anything is altered, using DumpIt, KAPE and similar. The order matters: memory is volatile and gone the instant the machine powers off, so it’s captured first, before anyone reaches for the power cable.

• Phase 4: Eradication & Remediation — Rebuild from clean templates rather than cleaning in place, because you can’t prove a “cleaned” box is actually clean. Reset domain credentials including KRBTGT — twice, with a replication interval between — to invalidate any Golden Tickets and break the attacker’s persistence.

• Phase 5: Restoration — Bring critical applications back from tested, offline backups, in a sequence that respects dependencies, and only after you’re confident the attacker’s access is severed. Restoring into a network the attacker still owns just gives them a fresh copy to encrypt.

Forensics, Evidence, and The Tool Stack

The way the first responders handle those first hours decides what evidence still exists later — and that evidence answers the questions that carry legal and regulatory weight: was data exfiltrated, how long were they inside, and what exactly do you have to disclose to regulators and customers. Under most breach-notification regimes, “we can’t tell whether data left” defaults to “assume it did”, which is the expensive answer. Preserved evidence is what lets you give the accurate, narrower one.

We equip the team with forensic workflows that hold up:

• Log & Metadata Analysis — Splunk, ELK and Wazuh to reconstruct the timeline from Windows Event Logs and Sysmon. The hard limit here is retention: an investigation can only reach as far back as your logs go, so a 30-day window makes “when did they first get in” permanently unanswerable if they were resident for six weeks.

• Network Traffic Analysis — Zeek and Wireshark to identify C2 channels and estimate what left the network. This is often the only technical basis for an exfiltration determination, which is exactly why attackers try to blend it into normal traffic.

• Host Forensics — Autopsy and KAPE to pull artefacts, build timelines and parse filesystem metadata into a coherent attack sequence.

• Chain of Custody — Documented handling with timestamps and SHA-256 hashing at each step, so the evidence stands up if the incident becomes litigation or a law-enforcement matter. Break the chain once and the technically sound analysis can still be inadmissible.

Tabletop Exercises: Simulating the Worst Day

A plan that reads well on paper still falls apart the first time it meets real pressure, and the point of a tabletop is to have that failure in a conference room rather than during an actual breach. We run exercises built on your real architecture — the initial phishing email, domain controller compromise, the ransom demand — and make the technical team and the executives commit to real decisions with the clock running. The value isn’t the plan surviving; it’s watching where it breaks. Almost every first tabletop surfaces the same thing: a decision everyone assumed someone else had the authority to make, and nobody actually did.

Key Operational Metrics

“Are we ready?” is unanswerable as a feeling and answerable as a set of numbers. These are the targets worth holding — with the caveat that a target you never measure under realistic conditions is aspiration, not readiness:

Metric	Definition	Target Baseline
MTTD (Mean Time to Detect)	Time from initial intrusion to alerting.	< 2 Hours
MTTC (Mean Time to Contain)	Time from alert to network isolation of the affected asset.	< 1 Hour
MTTR (Mean Time to Recover)	Time required to restore a critical business service from backups.	< 4 Hours per Tier 1 Asset
Logging Coverage	Percentage of Tier 0/Tier 1 assets shipping logs to the centralized SIEM.	100%
Backup Validation Rate	Percentage of critical backups physically tested for restoration in the last 30 days.	> 95%

Deliverables

• Master Incident Response Plan (IRP): A policy document aligned with legal and regulatory obligations — the authority document, not the field guide.
• Ransomware & Extortion Playbook: The field guide. Step-by-step runbooks for containment, preservation and eradication, written to be usable at 3 a.m. by someone who is tired and frightened.
• Out-of-Band Contact Matrix: Alternative communication plans plus vendor and retainer contacts — printed and stored offline, because a contact list that only lives in the encrypted SharePoint is no contact list at all.
• Tabletop After-Action Report (AAR): Honest analysis of the simulation, naming the specific communication breakdowns and technical gaps rather than grading the exercise a pass.
• Backup Architecture Validation Checklist: A technical review of backup immutability and segmentation — verifying the 3-2-1 principle actually holds, not that someone believes it does.

45-Day Ransomware Readiness Roadmap

• Days 1–15 (Baseline & Backups): Review the asset inventory — you can’t protect or restore what you can’t enumerate. Prove backups are segmented, immutable, and gated behind separate MFA, and check the log retention window, because that window silently caps every future investigation.
• Days 16–30 (Playbook & Process Engineering): Draft the Ransomware Playbook and pin down the containment authority thresholds — specifically, name the person who can order the main database disconnected, because that ambiguity is what burns the first hour of a real incident. Train Tier 1 to capture volatile memory before pulling power.
• Days 31–45 (Simulation & Refinement): Run the full executive-and-technical tabletop, document what failed without flinching, refine the playbooks, and lock in a quarterly cadence. Readiness decays — a plan validated once and shelved is stale within a year as staff, systems and the threat all change.

Hope is not a strategy, and neither is a plan nobody has rehearsed. Real readiness means treating a serious incident as when, not if: tested backups, playbooks that survive contact with a bad night, and enough practice that the decisions are muscle memory. Do that and the goal becomes realistic — surviving a major attack without paying the ransom, and with the reputation intact. Skip the rehearsal and you own the plan on paper and none of the capability it describes.