Why don't restorable backups remove a ransomware crew's leverage over you?
answer
- two demands, not one
- the encryptor is the last step
- the copy predates the ciphertext
- the backup path is a target first
- recovery answers only the outage
basics
~20 sBecause a copy of the data was taken before anything was encrypted. Restoring files ends the outage but not the threat to publish or sell what was already read, and the backup system itself is attacked early, not last.
solid answer
~40 sEncryption is the last and cheapest step of the operation, not the operation. By the time the encryptor runs, the crew has usually spent days with estate-wide privilege, copied whatever it judged saleable or embarrassing, and worked over the backup estate and the virtualisation management console so that the alternative to paying is already damaged. A clean recovery answers exactly one of the two demands: it ends the outage. It does nothing about a copy that already left, which is why crews that lose the encryption fight still get paid. So assess exposure as two separate questions - can I run again without them, and can I survive what they read - and notice that only the first has a backup-shaped answer.
go deeper
Recall that these operations copy data before encrypting it, so there are two demands: end the outage, and stop publication. Be ready to say plainly that backups answer only the first.
Explain the ordering - access, privilege, copy, backup estate, then encryptor - and why the payload is the cheapest step. You are expected to say why a clean recovery does not close the case.
Show that you price exposure as two independent questions, and that you can name which copies actually survive an operator holding estate-wide privilege instead of assuming all of them do.
Own the framing that recovery capability and data-exposure liability are different risks with different owners. Be ready to state what the organisation has bought with its recovery spend and what it demonstrably has not.
## The claim being corrected "We have backups, so extortion is survivable" is the answer a competent senior engineer gives, and it is half right. It is right that a genuinely independent copy converts a multi-week outage into a painful weekend. It is wrong because it treats the encryptor as the attack, and the encryptor is the last, cheapest and least skilled step in the whole operation. ## What the operation actually looks like in order A modern extortion intrusion is a sequence of phases, and the payload is at the end of it: 1. **Access** - bought or obtained, then expanded until the operator holds credentials that administer the estate rather than one host. 2. **Reconnaissance for value** - the operator walks the file shares, the finance and legal directories, the HR store and the source repositories, and forms a view of what is worth reading and what is worth threatening to publish. 3. **A copy taken** - the material judged valuable is collected and moved off the estate. This happens *before* the payload, because after the payload everything is loud and the window closes. 4. **The second copy attacked** - the backup estate and the virtualisation management console are worked over so that the victim's alternative to paying is already weakened when the demand arrives. 5. **The encryptor** - fired last, usually all at once and outside working hours. Every expensive part of that list is finished before a single file is ciphered. The payload is a commodity: cheap to obtain, quick to run, and requiring almost none of the skill the earlier phases needed. ## Why that ordering makes backups a partial answer An extortion demand after step 5 is really two demands stapled together: | Demand | What it threatens | What a clean recovery does to it | | --- | --- | --- | | Pay for the key | Your systems stay down | Removes it entirely | | Pay for silence | What we took gets published or sold | Nothing at all | The second demand is independent of your recovery position. It does not care how fast you come back, how good your retention is, or whether you ever speak to the crew about a key. That is precisely why crews began taking a copy first: it makes the payday survive a victim who recovers well. There is a second-order point that candidates often miss. Because the copy is taken first, the *decision* to pay is not a technical decision about recovery. Recovering answers the availability problem; the exposure problem then belongs to whoever owns the consequences of that data being public. Those are two different risks with two different owners, and conflating them is how a technically excellent recovery still ends with a payment. ## Why the backup estate is a target, not a refuge The assumption hidden inside "we have backups" is that the backup system is somehow outside the blast radius. Usually it is not. If the same directory that authenticates fleet administrators also authenticates the backup console, then one compromised identity reaches both. If retention can be shortened, or copies deleted, by an authenticated caller, then the second copy is only as durable as the weakest privileged credential in the estate. A replica in another data centre that answers to the same administrator is not a second copy - it is the same copy with extra latency. A copy that genuinely survives an operator holding estate-wide privilege has to fail *differently*: retention that no runtime credential can shorten, deletion that needs a second party or a waiting period, or a copy that is offline or lives in a separate trust domain with separate credentials. ## How to answer this in an interview Say the ordering out loud, then split the exposure. Something like: "the encryptor is the last step; by then the data has been copied and the backup path has already been attacked, so recovery answers the outage and nothing else. I would ask two questions: can we run without them, and can we survive what they read - and I would check which of our copies survives a domain administrator, because most estates have fewer of those than they think." That answer shows you price the objective rather than the payload, which is exactly what the question is testing.
- The crew sends a directory listing of your file share as proof. What does that actually establish?That someone read the share and could enumerate it - access and intent, not volume. A listing is cheap and needs only read access; it does not show that the contents moved. Asking for sample file contents raises the claim from 'we were inside' to 'we hold this'. Either way it is a claim about the copy, which recovering cannot touch.
- If the data is already copied, why bother running an encryptor at all?It converts an open-ended negotiation into one with a clock. An outage costs money every hour and forces a decision from executives who would otherwise wait; the threat of publication alone rarely does. And it is cheap: the expensive work - access, privilege, reconnaissance - is already paid for, so the payload adds enormous pressure at almost no marginal cost.
- Which of your copies genuinely survives an operator with estate-wide privilege?Only one the runtime credential cannot alter: retention no authenticated caller can shorten, deletion requiring a second party, or a copy that is offline or in a separate trust domain with different credentials. A replica reachable by the same administrator is not an independent copy; it is one copy with extra latency.
Burning down the shop hurts, but the photographs of the ledger were taken the week before. Rebuilding the shop does nothing about the photographs.
saying these in an interview costs you the question
- Says immutable backups make extortion a non-event
- Treats the encryptor as the whole attack
- Assumes payment only ever buys a decryption key
- Believes the backup appliance sits outside the adversary's reach
- Counts a same-domain replica as an independent copy