What happens when organisations keep all Active Directory backups online during a ransomware attack?

Why Online Active Directory Backups Become Part of the Attack Surface

When backups are still online and domain reachable, they are no longer a separate recovery layer, they are just another set of systems and files the ransomware can find. That changes the incident from “restore from clean copies” to “first protect whatever copies remain,” which delays containment and gives the attacker more time to destroy recovery options.

In Active Directory environments, that matters because the directory often provides the trust, authentication, and access paths that let backup servers, backup agents, and storage shares be reached. If those paths remain live during compromise, the backup set can be encrypted, corrupted, deleted, or rendered unusable alongside production data.

Keeping at least one offline or otherwise isolated backup path is therefore not a nice-to-have resilience measure, it is the difference between a survivable recovery and a full environment rebuild. The practical goal is to preserve an unaffected restore source that the ransomware cannot touch through the same credentials, network path, or management plane.

How Ransomware Disables Recovery When Backups Stay Reachable

Attackers rarely need to “break” backups in a special way if those backups are online. Once they have domain-level access, backup jobs, repositories, and management consoles often become just another set of targets for credential theft, privilege abuse, or direct encryption. In many incidents, the attacker’s real objective is to remove the defender’s recovery options before encryption spreads widely.

This is especially dangerous in Active Directory-centric estates because backup systems often inherit the same administrative trust patterns as the rest of the environment. Shared credentials, delegated admin accounts, mapped storage, and connected management hosts can let ransomware move from a compromised workstation or server into the backup plane with very little friction.

When that happens, recovery is no longer a clean restore from a known-good point in time. Responders may have to identify the newest intact copy, check whether it was altered, and decide whether it is safe to use, all while production is still down. The longer the backup layer stays online and exposed, the more likely the attacker has already touched it.

What A Resilient Backup Design Changes for AD Recovery

A resilient design separates recovery from routine administration. The most useful control is not just “having backups,” but having at least one copy that is isolated from the domain, protected from ordinary encryption paths, and difficult to reach with compromised credentials. Air-gapped, offline, immutable, or otherwise non-domain-joined backups each help reduce the blast radius in different ways.

This also changes recovery sequencing. Teams should assume the primary domain may be untrusted during a ransomware event and verify backup integrity before reconnecting restore targets. If the same identity plane used for production also governs backup access, you have to treat those credentials, tickets, and service accounts as potentially compromised too.

For teams that want a deeper operational model for lifecycle and separation, the NHI Lifecycle Management Guide is useful for thinking about provisioning, rotation, offboarding, and isolation across identity-bearing assets. The same recovery principle is visible in breach patterns such as Cisco Active Directory credentials breach, where credential exposure amplified the attacker’s reach, and in the broader pattern captured by The 52 NHI Breaches Report.

Risk and Threat Considerations

Online backups create a concentrated failure mode because the same compromise that hits production can also destroy recovery. In a ransomware event, that means the organisation may lose both the service and the last clean restore point, which turns a contained incident into a prolonged outage and increases the chance of business-wide rebuilds.

Failure mechanism: Ransomware or an intruder with domain-level access uses reachable credentials, mapped shares, backup agents, or backup consoles to encrypt, delete, corrupt, or disable backup data before responders can isolate it.

Impact: Recovery time increases sharply, rollback options shrink, and responders may be forced to restore from older or partial copies, rebuild systems manually, or accept data loss.

Practitioner Guidance

What to verify: Confirm that at least one restore source is unreachable from the domain during normal operations, not just protected by a password. If the backup path depends on the same identity, network, or management plane as production, treat it as exposed.

Decision rule: If a backup can be reached and modified from a compromised AD environment, it should not be treated as your last line of recovery. Keep a copy that is offline, immutable, or otherwise outside the attacker’s normal reach, and test that you can restore from it under incident conditions.

Practitioner takeaway: The key judgement is blast radius, not backup count: one untouched copy outside the domain is worth more than many online copies that ransomware can encrypt on the way to your recovery point.

Related resources from NHI Mgmt Group

• What breaks when attackers gain control of Active Directory during a ransomware attack?
• What happens if organisations try to keep Active Directory without modernising identity controls?
• Why do organisations keep Active Directory even after moving heavily to the cloud?
• When should organisations keep Active Directory instead of moving fully to Entra ID?