Ransomware: choosing the recovery point when the best backup is 7 hours old

Classify each copy by trust, not by recency.

• SAN snapshots (hourly): on the compromised array and deletable with the compromised domain administrator credentials. Assume destroyed or attacker-controlled. Not a recovery source.
• NAS backups (nightly + hourly logs): same room, same credential path, same flat network. Assume encrypted. Verify, but do not build the plan on it.
• Immutable cloud copy: last sync 02:00, detonation 09:40. This is the only copy the attacker could not reach. Recovery point = 02:00, a 7 hour 40 minute data loss window.
• Tapes: Friday. Four days of loss. Last resort only.

What finance is told: the 15-minute RPO is not achievable for this event. The achievable recovery point is 02:00 Tuesday, and the honest conversation is which transactions between 02:00 and 09:40 can be reconstructed from elsewhere - downstream systems, email, bank or partner confirmations, application-level audit logs, paper. Quantify it per system rather than giving one blanket number; the file server and the SQL estate will not have the same answer.

On RTO: restoring the cloud copy takes about 3 hours once a clean target exists, and building an isolated, non-domain-joined target is additional time. A 4-hour RTO is unlikely for the first system and certainly not for all twelve databases. Give a realistic sequenced estimate instead of a number nobody can hit.

Also flag double extortion: check for evidence of exfiltration before assuming this is only an availability incident, and involve legal and incident response.

Contain first, restore second, reconnect last.

1. Contain. Isolate the affected VLANs and shut down the trust path the attacker used. Disable the domain administrator account used by the backup service and the hypervisor admins, and disable every account that logged on to an affected system. Assume any credential cached on a compromised host is burned.
2. Build a clean target. Separate host cluster or VLAN with no trust relationship to the compromised domain, fresh installs, local accounts only, egress restricted to the restore source. Do not restore into the existing domain - you will re-infect or hand the attacker a working credential.
3. Restore and verify. Pull the immutable cloud copy into the isolated environment. Scan and validate integrity before anything connects or is promoted.
4. Rotate credentials, in this order: krbtgt twice (with the recommended interval between resets, since a single reset leaves existing tickets valid), then domain and enterprise admin accounts, then all service accounts (backup, monitoring, database, hypervisor), then local administrator passwords, then out-of-band BMC/iDRAC credentials, then certificates and API keys. Rebuild, do not clean, any host that was logged into with the compromised account.
5. Reconnect in stages. Promote the restored systems, rejoin the domain only after krbtgt and admin resets, and monitor for re-encryption attempts and unusual authentication for days, not hours.

Sequencing rule: no restored system touches production credentials or the production network until step 4 is complete. That is the difference between a recovery and a second incident.

1. Remove the shared credential path between backup and hypervisor administration. The attack did not defeat encryption; it used a single domain administrator account that reached the SAN, the NAS, and the hypervisor. Put backup and hypervisor management in a separate tier with their own accounts, MFA on the backup console, a dedicated management network, and no domain admin rights for the service account. Tie each control to the fact that one password exposed every copy.

2. Make the only trustworthy copy meet the 15-minute RPO. The immutable copy is six hours behind, so a real 15-minute RPO is fiction. Either shorten the replication interval to minutes, or ship transaction logs continuously to an append-only/object-locked store, and verify immutability by attempting a delete with the production credentials during a test. Keep an offline or out-of-band copy as the fourth leg of 3-2-1-1-0.

3. Prove the RTO by testing it, not by documenting it. Add a quarterly restore exercise that restores from the immutable copy into an isolated environment, times it, and records the achieved RPO/RTO against the targets. Also extend retention beyond the dwell time of typical ransomware - a copy that only survives 7 days is useless if the encryption is not noticed for 10.

Optional fourth: application-aware, credential-independent snapshots requiring separate authorization to delete, so a single compromised administrator cannot destroy every recovery point at once.