Generic disaster recovery assumes the thing that damaged your environment is a one-time event — a hardware failure, a fire, a flood — that isn't actively working against your recovery capability. Ransomware breaks that assumption entirely. A ransomware attacker specifically targets backups, often lingers undetected in the environment for weeks before triggering encryption, and can leave a foothold behind that reinfects anything restored into it. Recovering from ransomware requires controls that generic DR planning doesn't cover. This article walks through what's different, the specific controls required, how to avoid reinfection, and why paying the ransom shouldn't be the default response.
Why ransomware recovery is a different problem
A hardware failure doesn't try to prevent you from recovering from it. Ransomware does. Modern ransomware operators routinely target backup infrastructure directly — deleting backup jobs, encrypting backup repositories, or using stolen administrative credentials to disable backup software entirely — specifically because they understand that a working backup removes their leverage.
Compounding this, many ransomware attacks don't begin with the encryption event. Attackers frequently gain access weeks or even months before triggering encryption, using that time to explore the environment, escalate privileges, and locate and compromise backup systems. This means the most dangerous assumption in ransomware recovery is that recent backups are automatically safe to restore from — a backup taken during that dwell-time window may already contain the compromise, or may have been taken after the attacker's foothold was already established.
Backups Are a Primary Ransomware Target, Not an Afterthought
Modern ransomware operators actively hunt for and attempt to destroy backup infrastructure before triggering encryption. A backup strategy that assumes backups are safe by default, rather than specifically hardened against an attacker with administrative access, is planning for the wrong threat model.
The specific controls ransomware recovery requires
Generic backup and DR practices need to be extended with controls specific to an adversarial threat:
- Immutable or offline backup copies. At least one backup copy needs to be genuinely unalterable — write-once storage, or offline/air-gapped media — such that even an attacker holding domain administrator credentials cannot modify or delete it. A backup that's reachable and alterable from the production network is not meaningfully protected against an attacker who already has administrative access to that network.
- An isolated recovery environment. Restoring directly back into production risks reintroducing whatever compromised the environment in the first place. Systems should be restored into an isolated environment first, scanned and verified clean, and only reconnected to production once that verification is complete.
- A known-clean restore point strategy. Given that dwell time can extend for weeks, the most recent backup isn't automatically the right one to restore from. Organizations need a strategy for identifying a restore point that predates the compromise with reasonable confidence — which may mean going back further than the most recent backup, trading some data loss for confidence that the restored environment doesn't already contain the attacker's foothold.
Preventing reinfection
Restoring data is only half the problem. If the attacker's foothold — a backdoor, a newly created administrative account, a scheduled task, a compromised credential — isn't fully eradicated before systems are reconnected to production, recovery simply hands the attacker a freshly restored environment to encrypt again. Verified eradication has to happen before reconnection, not after, which typically requires:
- Confirming the initial access vector has been closed (a patched vulnerability, a disabled compromised account, a removed persistence mechanism).
- Auditing for newly created accounts, scheduled tasks, or services that weren't part of the known-good environment.
- Rotating credentials broadly, not just for accounts known to be compromised, since the full extent of credential exposure is rarely certain early in an investigation.
- Verifying the isolated restore environment is clean before any reconnection to production networks.
Skipping this step in the interest of restoring service quickly is one of the most common and costly mistakes in ransomware recovery — it trades a short-term speed gain for a high probability of near-immediate reencryption.
Why paying the ransom shouldn't be the default
Paying the ransom is sometimes treated as the fast, low-risk path back to normal operations. It generally isn't:
- Payment doesn't guarantee a working decryption tool. Decryption tools provided by ransomware operators are frequently unreliable, slow, or fail on portions of the data, and there's no recourse if they don't work as promised.
- Payment doesn't guarantee data wasn't exfiltrated. Most modern ransomware incidents involve data theft in addition to encryption, and paying for a decryption key does nothing to prevent that stolen data from being sold, leaked, or used for further extortion regardless of payment.
- Payment funds further attacks and, in some jurisdictions and circumstances, may carry its own legal or regulatory exposure.
The organizations with the most genuine leverage in a ransomware incident are the ones with a verified, working recovery capability — immutable backups, a tested restore process, and a known-clean restore point strategy. That capability is what actually removes payment from being a forced decision, turning it into an optional one the organization can decline from a position of strength rather than desperation.
Common mistakes
- Restoring from the most recent backup without verifying it predates the compromise. This is the single most common way ransomware recovery fails — the restore succeeds technically, but the attacker's foothold comes back with it, and the environment is reencrypted shortly after.
- Reconnecting restored systems to production before eradication is verified. Speed pressure during an active incident makes this mistake common, but it typically results in a second, faster reencryption event.
- Relying entirely on backups that are reachable from the production network. Without at least one immutable or offline copy, an attacker with administrative access can destroy the very backups the recovery plan depends on.
- Treating ransom payment as a default fallback rather than a last resort. Organizations that haven't invested in recovery capability sometimes default to planning around payment, which is both an unreliable recovery strategy and one that funds continued attacks against others.
FAQ
Should we ever pay the ransom? Payment should not be the default posture. It doesn't guarantee working decryption or that stolen data won't be leaked, and it funds further attacks. Organizations with immutable backups and a tested recovery process are generally able to decline payment and recover independently — that recovery capability is the actual goal, not a fallback plan built around eventually paying.
How far back should a "known-clean" restore point go? There's no fixed answer — it depends on the specific incident's estimated dwell time, which is typically established during the investigation. Planning should assume it may need to go back further than the most recent backup, which is why retaining backup history well beyond the minimum is part of a ransomware-resilient backup strategy.
Is immutable backup storage enough on its own? No. Immutable backups protect the data from being altered or deleted, but recovery still requires an isolated environment to restore into safely and a verified eradication process before reconnecting to production — immutability solves one part of the problem, not the whole one.