Protecting Active Directory backups from ransomware

Modern ransomware operators do not start by encrypting file servers. They take over Active Directory, use it to reach the backup console, delete or encrypt the backups, and only then deploy the payload through Group Policy or remote execution. If your domain controller backups can be reached with a Domain Admin credential, they will be gone before you notice the attack. Without a clean DC backup, recovery means rebuilding the forest from nothing.

This guide designs AD backups for that threat model: what to back up, where the backup system sits in the tier model, how to make copies immutable and offline, and how to prove every week that you could restore. The pillar assessment, backup and recovery guide covers the basics of system state backup. The restore procedure itself is in writing and rehearsing a forest recovery plan.

Measure: what you can actually restore today

Start from facts, not from the backup product's dashboard. On each domain, check when each naming context was last backed up, as recorded by AD itself:

# Last backup time per partition, as seen by the DC
repadmin /showbackup *

# Windows Server Backup versions available on a DC
wbadmin get versions

AD also warns you. Event 2089 in the Directory Service log appears when a partition has not been backed up within the backup latency threshold, which is half the tombstone lifetime by default. If you see 2089 anywhere, your backup product is not taking backups that AD recognises.

Then answer five questions per domain, in writing:

1. Which DCs are backed up, and in what format (Windows Server Backup system state, VSS-aware VM backup, vendor AD agent)?
2. Where are the copies stored, and which identities can delete them?
3. Is there a copy that no online credential can delete or alter before its retention ends?
4. Where are the DSRM passwords for those DCs, and can you get them if AD is down?
5. When was a restore last tested, and how long did it take?

Most organisations find the answer to question 2 includes Domain Admins, the backup service account and anyone in Backup Operators.

What to back up

For each domain in the forest:

• System state of at least two writable DCs, daily. Prefer the PDC emulator and a global catalog. Two DCs protect against one backup being corrupt or taken after compromise.
• AD-integrated DNS is inside the directory partitions and comes with system state. Conditional forwarders and server-level settings may not, so export them too.
• Group Policy objects as a separate, fast restore path for GPO mistakes that do not need a DC restore.
• AD CS: CA database and private key, since a forest recovery without the PKI leaves smart card logon, 802.1X and many applications broken. See AD CS hardening.
• Entra Connect configuration, exported, so hybrid identity can be rebuilt.

Install-WindowsFeature Windows-Server-Backup

# System state to a dedicated, non-critical volume on the DC
wbadmin start systemstatebackup -backupTarget:F: -quiet

# GPOs and AD CS
Backup-GPO -All -Path 'F:\GPO' | Out-Null
Backup-CARoleService -Path 'F:\CA' -Password (Read-Host -AsSecureString 'CA key backup password')

A system state backup contains ntds.dit and the SYSTEM hive, which means every password hash in the domain and the krbtgt keys. A copy of it is as sensitive as a DC. Encrypt it at rest and in transit, and never leave it on a share that Tier 1 or Tier 2 admins can read.

Enforce: take the backup system out of the blast radius

Separate identity

The backup console, the repository servers and the storage management interface are Tier 0. Anyone who controls them can read every hash or destroy your recovery. Add them to your Tier 0 inventory and choose one of these patterns:

• Separate management forest or workgroup for the backup infrastructure, with local or dedicated accounts, phishing-resistant MFA on the console, and no trust to production.
• Hardened appliance with its own identity store, for example Linux-based immutable repositories, where the production domain has no administrative path.

Whichever you pick, the backup agent service account on DCs must hold only the rights it needs and must not be reused anywhere else. Treat Backup Operators and any principal with SeBackupPrivilege on DCs as Tier 0. Keep the group empty unless there is a documented need.

Immutable and offline copies

Follow a 3-2-1-1-0 pattern: three copies, on two media types, one off-site, one immutable or offline, and zero errors in restore tests.

• Immutable: object storage with retention lock in compliance mode (for example S3 Object Lock), or hardened repositories that enforce immutability in the storage layer. In compliance mode, not even the storage administrator can shorten retention.
• Offline: tape or removable media physically disconnected, rotated on a schedule. Slow, but untouchable by anything on the network.
• Retention: long enough to reach back before a likely dwell time. Weeks at minimum, with some monthly copies, but restores must stay within the tombstone lifetime of the forest or be done as a full forest recovery.

Network isolation

Backup storage should accept connections only from backup proxies, not from the general server network or from DCs directly. Management interfaces for storage and backup should be reachable only from dedicated admin workstations, aligned with your domain controller firewall rules.

DSRM passwords

Every DC has a local Directory Services Restore Mode administrator. You need its password to restore. Set it per DC, store it in an offline vault (sealed envelope or a password manager that does not depend on AD), and rotate it on a schedule. You can also sync it from a disabled domain account:

# Syncs the DSRM password on this DC from a dedicated (disabled) domain account
ntdsutil "set dsrm password" "sync from domain account DSRMSync" q q

Event 4794 records every DSRM password change attempt. Alert on it outside change windows.

Detect attacks on the backups

Attackers prepare the ground days before encryption. Several signals appear in logs you already forward:

• Shadow copy and catalog deletion. Process creation events (4688 with command line) for vssadmin delete shadows, wbadmin delete catalog or wbadmin delete systemstatebackup on any server, and above all on DCs.
• Backup console logons from unusual hosts or accounts, and changes to retention policies, repositories or encryption keys. Forward the backup product's audit log to the SIEM and alert on configuration changes outside maintenance windows.
• Backup Operators membership changes (4732 on the built-in group) and new holders of SeBackupPrivilege.
• Missed backups. A backup job that silently stops is as dangerous as a deleted one. Alert on the absence of a successful job for more than a day.

Verify

A green backup job proves that data was written, not that it restores. Verify at three levels:

1. Weekly, automated. repadmin /showbackup shows every partition backed up within 24 to 48 hours. There are no 2089 events. The immutable copy exists with its retention lock set. Check this through the storage API from a system outside production AD.
2. Quarterly, restore test. Restore one DC per domain from the immutable copy into an isolated network with no route to production. Boot into DSRM and run a non-authoritative restore with wbadmin start systemstaterecovery -version:<version>. Confirm AD DS starts and objects are present. Never connect a restored DC to production. It would reintroduce old data and passwords.
3. Annually, full drill. Run the forest recovery plan end to end and time it.

Also test tamper resistance. With a Domain Admin account, try to delete a backup or shorten retention in the lab copy of your design. The attempt should fail, and it should raise an alert.

What it breaks

• Operational convenience. Backup admins can no longer use their everyday domain accounts. Separate credentials and MFA add friction, and some teams will push back until the first incident.
• Restore speed. Offline and cross-region immutable copies restore more slowly than local snapshots. Keep a fast, local, online copy for everyday recovery and the immutable copy for disaster.
• Storage cost. Compliance-mode retention cannot be shortened, even by you. Size it carefully, because a misconfigured retention of years on a large bucket is a bill you cannot cancel.
• Vendor integrations. Some backup products expect domain-joined proxies or AD-integrated role-based access control. Moving them to a separate identity plane may require reinstalling components or changing licensing.
• Backup Operators cleanup. Removing members can break legacy scripts that used the group for file-level backups on DCs. Find those scripts before emptying the group.

Related reading: writing and rehearsing a forest recovery plan uses these backups, krbtgt password rotation covers the key reset that every recovery ends with, and the assessment, backup and recovery area lists the whole series.