If your backup and cyber recovery platform is compromised: containment, credential rotation and rebuild playbook

When your backup and cyber recovery platform is compromised, the attacker holds the one system you were relying on to undo everything else, along with copies of your most sensitive data and the credentials that let the platform read every server, database, hypervisor and cloud account it protects. The compromise may start with a stolen backup console login, a leaked API key or cloud access key, a vulnerable backup server or proxy, an over-privileged service account in the directory, or an attacker who already owns the domain and turns to backups before deploying ransomware. This playbook is vendor-neutral and covers on-premises backup software, backup appliances, cloud-native backup services and backup as a service. It is for incident responders, backup and infrastructure teams and security leads. Ransomware across the wider estate is covered in the Cloud Ransomware Response Playbook; this page covers the backup platform itself.

Key takeaways

• Protect the last good copies before anything else. Freeze retention and deletion, confirm immutable and offline copies still exist, and stop the attacker shortening retention or deleting restore points (ATT&CK T1490 Inhibit System Recovery).
• Assume every credential the platform stores is exposed. Hypervisor, database, cloud, NAS and application credentials held for backup jobs must be rotated at source, in an order that does not break recovery you still need.
• Backup data is a breach in its own right. Copies of production data, and any encryption keys stored with them, may have been exfiltrated; treat it as a personal data breach assessment from the start.
• Verify before you restore. NIST CSF 2.0 RC.RP-03 requires backup integrity to be verified before use; restore into an isolated environment and scan for persistence first.
• Rebuild the platform outside the domain it protects. A separate identity plane, phishing-resistant MFA, multi-person approval for destructive changes and immutable copies are what stop a repeat.

What the platform holds and why it matters

Scope the incident by what the platform can reach and change, not only by what was stolen first.

See the Backup Identity Isolation Guide for how these identities should be designed in the first place.

How the compromise shows up

The CISA #StopRansomware Guide notes that many ransomware variants attempt to find and delete or encrypt accessible backups, and lists changes that impair backups, shadow copies or boot configuration as signs to hunt for.

Triage: the first hour

1. Which copies are still trustworthy? List immutable, air-gapped, offline and cyber vault copies, their latest timestamps and whether their lock settings are unchanged.
2. Which identities were used? Console accounts, API keys, cloud roles and directory service accounts that made changes in the suspect window.
3. Is the attacker still active? Live sessions, running jobs, scheduled deletions and pending retention changes.
4. Is production also compromised? If the domain or hypervisor layer is owned, switch to the wider ransomware playbook and treat this page as one workstream.
5. What data was in scope? Systems protected, data categories (personal, payment, health, regulated) and whether encryption keys were accessible.

Roles and decision points

Agree the clean cut-off date as early as possible: every later decision about restores, rotation and reconnection depends on it, and it should be revisited as forensics finds earlier activity.

Containment by priority

1. Preserve recovery points: place retention or legal holds on all existing copies, enable or confirm object lock and deletion protection, and suspend any scheduled pruning. The CISA guide recommends delete protection or object lock on storage often targeted in ransomware attacks.
2. Cut attacker access to the console: disable suspect accounts, revoke API keys and sessions, and limit console access to a small set of named responders on a clean admin workstation with phishing-resistant MFA.
3. Take the offline copy further offline: disconnect or power down air-gapped targets and tape libraries until the platform is trusted again.
4. Isolate backup servers and proxies: block their outbound internet access and their administrative paths into production; keep repositories reachable only where needed for preservation.
5. Restrict cloud deletion: remove delete and policy-change rights from backup roles, and apply organisation-level deny policies on snapshot and vault deletion where the provider supports them.
6. Do not start broad restores yet: the CISA guide warns to take care not to re-infect clean systems during recovery.

Credential rotation

Rotation order matters because the platform's credentials also drive the restores you will need. Rotate in this order, recording each change in the incident log:

If the directory itself is compromised, the CISA guide advises issuing password resets once the environment has been fully cleaned and rebuilt; coordinate with the Identity Recovery Guide. See also the Cryptographic Key Management Guide.

Eradication and rebuild

• Rebuild, do not clean: reinstall backup servers, proxies and the management console from trusted media at a supported, fully patched version, then restore the platform's configuration database from a copy taken before the suspect window and review it line by line.
• Separate the identity plane: join the rebuilt platform to a dedicated management domain or use local accounts with phishing-resistant MFA, never the production domain it protects.
• Require more than one person for destruction: enable multi-person approval for deleting backups, shortening retention or changing immutability where the platform offers it.
• Re-scope service accounts: one identity per protected system class, least privilege, no interactive logon. See the Service Account Security Guide.
• Restore immutability and isolation: immutable repository or object lock on primary copies, plus an isolated vault copy. The CISA guide cautions that immutable storage may not meet compliance criteria for certain regulations, so check retention obligations. See the Cyber Recovery Vault Guide.

Recovery and reconnection

1. Restore a sample from each trusted copy into an isolated clean room and scan for malware, persistence and tampering before use. See the Cloud Recovery and Clean Room Guide.
2. Reconnect protected systems in priority order, starting with identity and critical services, using new credentials only.
3. Run new full backups and confirm the first immutable copy is written before resuming normal retention.
4. Keep enhanced monitoring for at least 30 days, and run a full restore test as described in the Backup and Recovery Testing Checklist.

Evidence to preserve and notification

• Preserve: platform audit and job logs, configuration database snapshots, cloud control plane logs, key management logs, restore and export history, and disk images of backup servers. Export logs before rebuilding, because they often live on the server being replaced.
• Personal data: under UK GDPR the ICO says a notifiable breach must be reported without undue delay and not later than 72 hours after becoming aware of it, and loss of availability of personal data can itself be a breach. If the risk to individuals is high, tell them directly. Stolen backups count even when encrypted if the key may also have been taken.
• Other triggers: sector regulators, contracts with customers and cyber insurers often set their own deadlines; check them in the first day.

The GoTo breach shows why: encrypted backups for five products were taken from shared cloud storage, together with an encryption key for part of them.

Decision guidance

• Restore from immutable copies or wait for forensics: restore immediately only when the copy predates the earliest attacker activity with margin and passes an isolated scan; otherwise accept a longer outage rather than reinfect.
• Rebuild in place or move platforms: rebuild in place when the root cause is clear and patched; consider a planned move only after recovery, using the Backup and cyber recovery platform migration playbook.
• Self-managed or service provider: where a provider runs the platform, the provider controls many of these steps; invoke contractual incident clauses early and ask for their audit logs.
• Small vs large organisations: a small team may rely on one immutable cloud copy and a provider; a large estate needs a separate management domain, a cyber vault and a rehearsed rotation runbook.

Detection and measurement

• Alert on every retention change, immutability change, restore point deletion, new admin, MFA change and restore to a new destination, sent to a SIEM the backup admins cannot change (NIST SP 800-53 AU-9 Protection of Audit Information).
• Percentage of protected systems with at least one immutable or offline copy inside the recovery point objective.
• Number of backup credentials stored in the platform that are also used elsewhere (target zero).
• Percentage of destructive actions that required multi-person approval.
• Time to detect a retention or deletion change in exercises.
• Days since the last successful isolated restore test per critical system.

Framework mapping

Common failure patterns

• Backup platform joined to the production domain: one domain compromise hands over both production and the means to recover it.
• Restoring too early: restoring from points that already contain the attacker's persistence and reinfecting clean systems.
• Destroying old keys during rotation: new keys protect new backups, but deleting the old ones makes historical backups unrecoverable.
• Logs lost in the rebuild: the platform's audit history lived only on the server that was wiped.
• Alerts sent to an inbox the attacker controls: notification settings changed weeks before impact and nobody noticed missing reports.

Practitioner checklist

• Freeze retention, confirm object lock and immutability, and suspend pruning on all copies.
• Disable suspect console accounts, revoke API and cloud keys, and restrict console access to named responders with phishing-resistant MFA.
• Disconnect offline and vault copies until the platform is trusted.
• Export audit, job, cloud and key management logs before any rebuild.
• Rotate credentials in order: console, cloud, directory service accounts, stored system credentials, integrations, future encryption keys.
• Rebuild servers and console from trusted media on a separate identity plane with multi-person approval for destructive actions.
• Scan restore points in an isolated environment before use and reconnect systems in priority order.
• Assess personal data exposure from backup copies and keys against the 72-hour reporting rule.

Standards and references

• CISA: #StopRansomware Guide
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NIST: SP 800-209 Security Guidelines for Storage Infrastructure
• MITRE ATT&CK: Inhibit System Recovery
• ICO: Personal data breaches, a guide

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Backup Platform Health Check · Cybersecurity Event Recovery Guide · Cloud Ransomware Response Playbook