Your Backups Are Now the First Ransomware Target

Ransomware operators do not start by encrypting your production servers. They start by reading your backup vendor’s documentation. In a ransomware intrusion, the attackers take identity, then they take the backup plane, and only then do they encrypt production. The encryption is the loudest step. Everything before it is quiet.

The backup administrator’s account has broad read access to everything and the power to delete every copy. It holds more power than the domain admin, and it is watched far less. The first visible sign of a breach is rarely a locked file server. It is a login to the backup console from a workstation in the finance VLAN at 2:47 a.m. The console logs the event and the SIEM records it, but nobody wrote the rule to generate an alert.

Attackers do not try to break the encryption algorithms on the backup files. They use the backup product’s own API to issue legitimate delete commands. They log in and change the retention policy on all jobs from thirty days to one day. When the dedupe appliance runs its scheduled space reclamation job six hours later, the restore points older than the new retention are gone, and nothing alarms. The backup jobs keep running through the encryption event. The reports are green. The backups are simply copies of encrypted files.

Vendors sell immutable storage, but immutability that an administrator can turn off is a policy, not a control. You have to ask which mode the retention lock is in. Governance mode can be turned off by an admin with the right role. Compliance mode cannot be turned off by anyone, including the vendor, until the expiry date. If your retention lock is in governance mode, and the delete permission sits on the backup server’s IAM role, you do not have immutable backups. You have a configuration setting.

Snapshots are not backups. They share credentials, network, and fate with the primary storage array they protect. Cloud storage only fixes this if the IAM roles are strictly segregated. If the on-premise backup server holds an API key with delete permissions for the cloud bucket, compromising the server means losing the cloud copies. The control is the separate-account pattern: production writes cross-account to a backup account with write-only permission, and the delete permission is held by a different human in a different account.

The backup catalog is a target list. It tells the attacker exactly what to destroy first. Losing the catalog means losing the backups, even when the physical media survives. A tape you cannot index is a tape you cannot restore. Consider the vault rotation. Tapes are picked up on Tuesday and returned on Thursday. The incident starts on Wednesday. The most recent offsite tape is Monday’s, which predates the intrusion. But the catalog that indexes it lived on the backup server, which is now encrypted.

Forensics will ask for the SIEM logs to determine the dwell time. If log retention is thirty days and the dwell time was forty-five, the answer is that you do not know when they got in. If your immutability window is thirty days, the last fifteen days of backups are poisoned.

The restore test measures the wrong thing. A test that restores a 40 GB file share to a staging VM in 22 minutes proves the pipeline works. The report says passed. Nobody asks about the ERP. A restore point is not a recovery time. The number that matters is not whether you can restore, but how long until the business is back.

Moving 400 terabytes across a firewall inspection interface that caps at 2 Gbps is a math problem. At 200 MB/s, a single stream takes roughly 23 days. You have to run the arithmetic for your real parallelism, your real network link, and your real contention. The RTO in the Business Impact Analysis and the RTO you can actually achieve are two different numbers. Nobody has put them side by side.

Recovery starts with identity. You cannot restore anything that trusts Active Directory until you restore AD, DNS, and the Certificate Authority. Most teams have never restored a domain from scratch. If the CA’s private key was on a server that got encrypted, nothing trusts anything and the certificate templates are gone.

You cannot restore into the network that is compromised. The clean room requires new infrastructure, and the people doing the restore need credentials to access that isolated environment. This is where the break-glass procedure fails. The vault password lives in a password manager on the corporate network, which is down. The procedure requires the security team, which is tied up on an incident bridge that also relies on the network.

Your disaster recovery plan assumes the building is gone. Your ransomware plan has to assume the credentials are gone. The backup infrastructure requires a dedicated identity provider, and the vendor’s remote support tunnel needs to be treated as an access path.