The disaster recovery plan assumes you have something to recover from. It assumes the storage arrays are intact, the backup catalog is accurate, and the credentials required to mount the recovery volumes still belong to you. When an attacker uses your own backup administrator account to wipe the primary snapshots and delete the retention policies, that plan becomes a historical document. You are no longer executing a restore. You are standing up a new datacenter on bare metal and attempting to populate it with salvaged parts.
The backup console is the first crime scene. Before anyone looks at application servers, someone needs to preserve the backup catalog logs, job history, and authentication records from the backup system itself. If the on-call team reimaged the backup server in hour two to get it back online, they destroyed the evidence that tells you which restore points are clean. Attackers do not always bother encrypting the backup data. They delete the index. The organization is left with petabytes of raw data on disk or tape, but no map of what blocks belong to which servers. The catalog is the backup. The data is just bytes without it.
Recovery is an identity problem before it is a data problem. You cannot restore a domain controller and then join it to a domain you do not trust. You cannot trust tickets issued by a compromised directory. If the domain was compromised, every credential in it is suspect, including computer accounts, service accounts, and trusts. The entire recovery stalls on standing up a clean, isolated identity environment. A recovery team ends up in a repurposed conference room unboxing commercial off-the-shelf servers bought that morning. They install a hypervisor from a USB drive, physically isolated from the building’s network, just to create a clean room to mount an offline domain controller from three weeks ago. The old domain is still running in parallel, isolated, because the investigation team needs it as evidence. Everything joins the new identity environment.
Vendors sell immutable storage, meaning the data cannot be altered once written. But if the storage array is managed via a cloud portal or a central management server, and the attacker compromises those credentials, they can issue a factory reset command to the array itself. Immutability is a policy setting until someone with the right credential changes the policy. An air gap is not a technology. It is a procedure that someone has to follow on a schedule. True offline backups—tapes in a box, disconnected from the network—survive because they are unreachable from the network at the moment of the attack. The operational cost of tape is real, and the restore time is slower than disk. But for environments where the threat model includes domain admin compromise, it is one of the few things that survives.
In continuous-duty environments, the systems that cannot go offline are the ones that are hardest to prove clean. Dispatch, command and control, warrants, and custody records have to run during the recovery. That means you are cleaning and operating at the same time. Triage in a total loss scenario means accepting that the administrative systems will be offline for a month so that the tactical systems can be online tomorrow. An argument breaks out between a theater commander and the enterprise architect. The commander needs the dispatch and field-reporting databases online immediately. The architect has to explain that while they have the data on an offline tape, they do not have a trusted network to put it on, and plugging the restored database into the existing switch fabric risks immediate reinfection.
Meanwhile, an investigations unit kept accepting material during the outage under a manual process. When its case system returns, staff must enter that work without losing the original sequence of receipt, access, and transfer. Restoring yesterday’s database does not settle the status of today’s records. Every restored system is a reinfection vector until it has its own validation story, and most validation stories take longer than the restore. A restored server can be running long before the organization is willing to trust the records it serves. If the attacker sat on the network for ninety days before executing the ransomware, the offline backups are safe, but restoring them means restoring the attacker’s backdoors, scheduled tasks, and compromised service accounts.
Recovery time is dominated by the things you cannot buy quickly: clean hardware, clean credentials, and someone who knows how the application is supposed to behave. A procurement lead discovers that the replacement switches are on a 45-day lead time because the model was discontinued, and the only spares in the building were in the rack that got encrypted. Communication fails first. The VoIP system, the email servers, and the internal chat applications all share the same compromised network. The recovery team coordinates the rebuild using personal cell phones and consumer messaging apps unless a dedicated, out-of-band channel was established beforehand. The most valuable asset in a total rebuild is a physical, printed copy of the network topology and system dependencies. The digital copies are usually stored on the file servers you are trying to recover.
A successful file restore does not prove you can rebuild an identity environment from bare metal. The only way to know if the plan works is to execute it without the directory, the collaboration platform, and the assumption that the infrastructure is still yours.