A backup is supposed to be the thing that saves you. In an Active Directory environment it can also be the fastest route to total compromise. In assessments we sometimes find that unprivileged users can read domain controller backups, and from there extract the credentials of every account in the domain and sign in as domain administrator. No exploit, no malware. Just a backup system that lets any employee sign in with their normal password.
Attackers know what backups are worth. In a 2024 Sophos survey of almost 3,000 organisations hit by ransomware, 94% said the attackers had tried to compromise their backups, and 57% of those attempts succeeded [1]. Where they did, the median recovery cost was $3 million. In Switzerland, the incident responder InfoGuard analysed some 350 of its cases from the past year. In one recurring pattern, a single stolen VPN login was enough to reach the backup systems as well as the file servers, and within hours it became a company-wide ransomware incident [4].
What a domain controller backup holds
A domain controller backup exists to bring the domain controller back, so it holds everything the server needs to run, including what it needs to read its own passwords. That means the credentials of every account in the company: every employee, every service account, the built-in administrator, and the KRBTGT account, which signs every Windows login ticket. Whoever copies the backup can extract all of them on their own machine, in their own time, with freely available tools. And for logging in to Active Directory, what the backup holds is as good as the password itself.
How it happens
The exposure almost always comes from two decisions made for convenience:
- The backup system can be reached from the normal office network.
- Any employee can sign in to it with just their password, without a second factor.
Both rest on the assumption that the backups are less sensitive than the domain controller itself, although they hold the same secrets. Each decision is understandable on its own. Together they can let anyone with an employee login become domain administrator.
Attackers know where to look. In about one in ten of the ransomware intrusions Mandiant responded to in 2025, they went after Veeam Backup & Replication, a widely used backup product, to harvest credentials [2].
"It's an old backup" is not a defence
A common reassurance is that the readable backup is months old. That does not necessarily help. The built-in administrator password and the KRBTGT account are rarely changed, so what an attacker takes from an old backup usually still works today.
Protecting your backups
Protect your backup system as carefully as the domain controllers themselves:
- Take it out of the domain. A backup system that accepts Active Directory logins lets every domain account try the door. Mandiant's M-Trends 2026 report advises removing backup infrastructure from the corporate Active Directory domain [3].
- Put it on its own network. Office computers and ordinary servers should not be able to reach it at all. Only the people who run the backups should.
- Limit who can log in. A small, named group of backup administrators, and no shared or general accounts.
- Require a second factor for every login to the backup system.
- Run backup jobs under their own accounts, with only the rights they need, never under an administrator account.
- Encrypt the backups, so a stolen copy cannot be read.
Three questions for an unprivileged account
Sign in with an unprivileged user account, not an administrator, and check:
- Can it reach the backup system's login screen?
- Can it open the shares or folders where the backups are stored?
- Can it open or copy a domain controller backup?
Three times no, and the measures above keep it that way. One yes, and the next section applies.
A backup any user account can read is a security incident
Finding out that unprivileged user accounts can read a domain controller backup is not a setting to fix quietly. Assume every credential in it is exposed and act on that: change the built-in administrator password and the passwords of every privileged and service account, check what else was stored alongside it, and reset the KRBTGT account twice. Wait for the first reset to reach every domain controller before doing the second; only then do stolen login tickets stop working.
A domain controller backup holds personal data about everyone with an account in the domain. The exposure therefore counts as a data security breach under Swiss data protection law, whether or not anyone actually opened it. If it is likely to put the people concerned at high risk, it must be reported to the Federal Data Protection and Information Commissioner (FDPIC) as soon as possible.
What it buys you
The measures above protect more than the domain controller backups. They put the whole backup system out of an unprivileged account's reach, and so out of reach of an attacker who has stolen one. In the same Sophos survey, organisations with uncompromised backups paid a median of $375,000 to recover, an eighth of what organisations with compromised backups paid [1]. Protecting the backups from the start is a matter of configuration. An exposure is a security incident, and handling one is slow, costly and disruptive.
The lesson in one line
A domain controller backup holds the credentials of every account in your domain - protect it like the domain controller itself.
If one of the three questions has no clear answer, we are glad to look at it with you: [email protected].
Sources
- Sophos, The Impact of Compromised Backups on Ransomware Outcomes, survey of 2,974 IT and cybersecurity professionals at organisations hit by ransomware, conducted by Vanson Bourne in early 2024. back
- Google Threat Intelligence Group, Ransomware Under Pressure: Tactics, Techniques, and Procedures in a Shifting Threat Landscape, 16 March 2026. back
- Mandiant, M-Trends 2026, Executive Edition. back
- InfoGuard, Sandro Bachmann, Cyberangriffe ohne Hollywood-Hacking: 350 analysierte Fälle. Drei Muster., 25 June 2026. back
AYS AG, Zurich. Cybersecurity and Forensics.