All intelligence content is fictional, redacted and defensive. No real credentials, stolen data, exploit instructions, malware links, payment information or private personal data is published. Defensive guidance only. No payment facilitation, negotiation scripts or threat actor contact methods.
A ransomware incident is a clock-management problem as much as a technical one. By the time encryption is visible, the attacker has usually been inside the network for days or weeks — establishing persistence, stealing credentials, disabling backups and, increasingly, exfiltrating data for double extortion. The first 48 hours decide whether you contain a bad day or absorb a catastrophic one. This guide walks through what a defensive team should do, in order, during that window. It is written for IT and security responders; it is not legal advice, and decisions about ransom payment are business and legal matters to be made with counsel, your insurer and law enforcement — never improvised under pressure.
Hour 0 — Confirm, then declare
Before you act, confirm what you are actually seeing. A flood of "file not found" errors, files renamed with a uniform extension, and a ransom note (typically a .txt or .hta dropped into every directory) are the classic signals. Rule out a misconfiguration or a single failing disk — but err on the side of treating it as an incident. Over-reacting for an hour costs far less than under-reacting for a day.
Once confirmed, formally declare an incident. This is not a formality: declaration activates your incident response plan, authorises responders to take disruptive containment actions, and starts the clock on legal and contractual notification deadlines. Assign an incident commander now — one person who owns decisions and coordination — and open a single, timestamped incident log. Every action, observation and decision goes into that log from this minute. It will matter for forensics, insurance and regulators later.
- ▸Confirm encryption is real (uniform extensions, ransom notes, failed file access)
- ▸Declare a formal incident and activate the IR plan
- ▸Name an incident commander and a scribe
- ▸Open a timestamped incident log — record everything from now on
- ▸Switch to out-of-band communications (assume email/Teams may be monitored)
Hours 0–4 — Contain before you investigate
Containment comes before root-cause analysis. The goal is to stop the spread of encryption and cut the attacker's access, fast. Isolate affected systems from the network — pull the cable, disable the switch port, or quarantine via EDR. For virtualised or cloud workloads, isolate at the network/security-group level. If the blast radius is unclear and spreading, isolating an entire segment or site is a legitimate call; the incident commander owns that decision.
A critical nuance: isolate, but do not power systems off if you can avoid it. Shutting down destroys volatile evidence in memory — encryption keys, running processes, network connections — that forensics may need, and in rare cases can corrupt partially-encrypted disks further. Network-isolate a running machine rather than killing it. The exception is an active, fast-spreading event where pulling power is the only way to stop further damage; document the decision.
Protect your backups immediately — they are the attacker's primary target and your primary lifeline. Take backup systems offline or confirm their immutability/air-gap, revoke backup service-account access, and verify recent backups still exist and have not been deleted or encrypted. Many ransomware crews specifically hunt and destroy backups before detonating; assume they tried.
Disable compromised and privileged accounts. Reset or disable any account known or suspected to be involved, and force a reset of domain administrator and service-account credentials from a known-clean host. If you have evidence of domain-wide compromise (e.g. the attacker reached a domain controller), plan for a tiered credential reset — but do not tip off the attacker before you are ready to lock them out comprehensively.
- ▸Network-isolate affected hosts (do NOT power them off unless damage is actively spreading)
- ▸Quarantine at segment/site level if spread is uncontrolled
- ▸Take backups offline / verify immutability and that they still exist
- ▸Disable suspected compromised accounts; reset privileged credentials from a clean host
- ▸Block known attacker C2 domains/IPs at the firewall and proxy
Preserve evidence — do not reimage yet
The instinct to wipe and rebuild fast is understandable and wrong for the first 48 hours. Evidence answers the questions that determine whether recovery actually works: How did they get in? What did they touch? Did they steal data? Reimaging before you know the entry vector means you rebuild straight back into the same hole.
Capture forensic artifacts before changing anything: memory images of key systems where feasible, full disk images of patient-zero and representative encrypted hosts, and copies of relevant logs (EDR, firewall, VPN, authentication, DNS, email gateway). Preserve a copy of the ransom note and a sample of the encrypted files and any malware binaries — these help identify the strain via tools like ID Ransomware and may reveal whether a free decryptor exists. Maintain chain of custody for anything that could become evidence.
Pull logs to a safe location quickly. Attackers clear logs, and log retention windows are short; an authentication log that rolls over after a few days may be the only record of the initial intrusion.
- ▸Image memory and disks of patient-zero and sample hosts
- ▸Export and safely store EDR, firewall, VPN, auth, DNS and email logs
- ▸Preserve the ransom note, encrypted-file samples and any malware binaries
- ▸Identify the ransomware strain (ID Ransomware / No More Ransom) — check for a free decryptor
- ▸Maintain chain of custody on all collected evidence
Scope the incident and find patient zero
With containment holding and evidence preserved, build the picture. Identify every encrypted or affected system, the initial access vector (phishing, exposed RDP/VPN, an unpatched edge device, a compromised third party), and the path of lateral movement. Look for the persistence mechanisms and tooling attackers leave behind — Cobalt Strike beacons, AnyDesk/TeamViewer installs, new local admin accounts, scheduled tasks and GPO changes.
Assume the attacker still has a foothold until proven otherwise. Containment that misses one beacon or one valid credential lets them re-detonate. Hunt across the estate, not just the visibly-encrypted machines.
- ▸Enumerate all affected systems and data stores
- ▸Determine the initial access vector
- ▸Map lateral movement and identify persistence/tooling left behind
- ▸Hunt for additional footholds across the whole environment
- ▸Confirm whether domain controllers / identity infrastructure were reached
Assume data theft — check for double extortion
Modern ransomware is usually double extortion: the crew steals data before encrypting and threatens to leak it. From a notification and risk standpoint, you must determine whether data left the building. Review outbound transfer volumes, look for staging archives (large .7z/.zip files in unusual locations), and check for known exfiltration tooling (Rclone, MEGAsync, FileZilla) and connections to cloud-storage or file-transfer services around the intrusion window.
Whether data was exfiltrated materially changes your legal and regulatory obligations — a pure-encryption event and a data-theft event are different notification scenarios. Treat exfiltration as likely until you can show otherwise, and bring this evidence to legal early.
- ▸Review outbound network volume around the intrusion window
- ▸Search for staging archives and exfil tooling (Rclone, MEGAsync, etc.)
- ▸Check cloud-storage / file-transfer connections from internal hosts
- ▸Document exfiltration findings for legal and regulatory assessment
Communications and notification
Communication failures cause as much damage as the malware. Run all incident coordination over an out-of-band channel — a separate messaging app, phone bridge or pre-provisioned clean accounts — on the assumption that your normal email and chat are compromised and monitored.
Engage the right parties early and in parallel: executive leadership, legal/privacy counsel, your cyber-insurance carrier (many policies require prompt notification and have approved IR vendors), and law enforcement. In the US that is the FBI/CISA via #StopRansomware reporting; elsewhere, your national CERT or police cyber unit. Regulatory clocks may be tight — GDPR requires breach notification to the supervisory authority within 72 hours where personal data is at risk, and sectoral rules (HIPAA, SEC, NIS2, banking regulators) add their own deadlines. Identify which apply on day one, not day three.
Control external messaging. Do not publish technical specifics, attribution guesses or the ransom note publicly. Prepare holding statements for staff, customers and partners with legal review. Internally, give employees clear, calm instructions: what not to touch, which systems are down, and where to report anything suspicious.
- ▸Coordinate only over out-of-band channels
- ▸Notify executives, legal/privacy counsel and the cyber-insurance carrier
- ▸Report to law enforcement (FBI/CISA #StopRansomware or your national CERT)
- ▸Map regulatory deadlines (GDPR 72h, HIPAA, SEC, NIS2, sector rules) on day one
- ▸Issue legally-reviewed holding statements; brief staff with clear instructions
Hours 24–48 — Plan recovery, don't rush it
Recovery starts only once you understand the intrusion and can rebuild into a clean environment. Restoring backups into a network the attacker still controls simply re-encrypts them. Define a clean-rebuild plan: stand up recovery infrastructure on known-good media, reset all credentials (a full domain reset if identity infrastructure was touched), patch the vulnerability that let them in, and validate that EDR/monitoring is in place before reconnecting anything.
Validate backups before you trust them. Confirm they predate the compromise, restore a sample to an isolated environment, and verify integrity. Prioritise restoration by business criticality, not by what is easiest. Bring systems back in controlled waves with monitoring watching for re-infection.
On the question of paying: it is a business and legal decision made with counsel, your insurer and law enforcement — not a technical one, and not one to make in panic. Payment does not guarantee data return, decryptors are often slow or buggy, paying may carry sanctions-compliance risk, and it funds future attacks. This guide does not provide payment or negotiation guidance; route that conversation to your legal and executive track.
- ▸Build a clean-room recovery environment on known-good media
- ▸Reset all credentials (full domain reset if identity infra was compromised)
- ▸Patch the initial access vector before reconnecting
- ▸Validate backups (pre-compromise, integrity-checked) before restoring
- ▸Restore in prioritised, monitored waves — watch for re-infection
What NOT to do in the first 48 hours
A few mistakes turn a recoverable incident into a disaster. Avoid them deliberately.
- ▸Don't power off systems reflexively — you destroy memory-resident evidence and keys
- ▸Don't reimage before you know the entry vector — you rebuild into the same breach
- ▸Don't restore backups into an environment you haven't cleaned
- ▸Don't communicate over potentially-compromised email/chat
- ▸Don't run the attacker's decryptor on production without testing it on copies first
- ▸Don't make a payment decision in panic, or without legal, insurer and law enforcement input
- ▸Don't delete the ransom note, malware or logs — they are evidence and may unlock a free decryptor