Why Backup Infrastructure Is a Higher-Value Target Than Domain Admin Accounts

Domain admin accounts live under a microscope. Security teams track who holds them, what systems they touched, and when. Backup infrastructure rarely gets the same level of scrutiny, and the Veeam and N-central cases we cover later in this article show exactly what that costs.

A big chunk of that is a perception problem. Backup software doesn’t run on one master credential, but on a collection of them, which include service accounts, database logins, hypervisor access, cloud IAM roles, storage API tokens, admin console access.

And yet that collection of access points rarely shows up on anyone’s threat model. The typical posture is to treat backup software as an operational checkbox that runs on a schedule and gets checked when a restore fails. Security scrutiny, if it exists at all, comes last.

That exact combination of broad access and low scrutiny is what attackers are after. Compromising the backup control plane, its credential store, or a highly privileged backup admin account can deliver broad data access and the ability to quietly sabotage your recovery capability, often with far less visibility than going after a domain admin directly. This article breaks down how that happens and what to do about it.

Domain Admin Accounts vs. Backup Infrastructure: What’s the Difference?

Domain admin accounts and backup credentials both represent high-stakes access across the organization, but they work differently and carry different risks. The former are among the most privileged account types in a Windows environment. The latter are limited-privilege by design, yet in the wrong hands, they can expose or destroy far more than their privilege level suggests.

• Domain Admin accounts have full control over an Active Directory domain. They can reset passwords, modify user and group permissions, push policy changes, and access any server joined to the domain.
• Backup credentials are what backup software uses to read and copy data from every system it protects: Windows servers, Linux machines, databases, virtual machines, and cloud workloads. Because the software needs broad access to do its job, these credentials collectively span the entire environment across multiple account types and trust relationships.

That asymmetry, broad collective access with minimum oversight, is exactly what makes backup infrastructure so attractive to attackers.

Understanding Domain Admin Privileges and Their Scope

As detailed earlier, whoever holds domain admin credentials can create and delete user accounts, push group policy changes across the entire domain, access files on any domain-joined machine, and reset passwords for virtually anyone in the organization.

If compromised, attackers can reconfigure the environment at will. For example, an attacker can permanently change how the company’s systems work, such as by disabling endpoint detection, or even deleting every piece of data the business owns.

Security teams know this, so domain admin accounts tend to be watched closely, and accounts are restricted to specific workstations.

The Hidden Power of Backup Credentials

Experienced attackers often avoid using domain admin accounts directly once they have them, because doing so triggers SIEM alerts, EDR flags, and leaves a clear trail in the audit logs. Backup infrastructure access is far more appealing precisely because none of that happens.

Backup credentials don’t just give you access to a system, but the data itself, already aggregated, organized, and ready to extract. The backup agent is always reading from disk, always copying data. An attacker using those credentials looks identical to the software doing its normal job, and the SIEM sees a routine backup run.

What makes this even worse for companies is that backup credentials reach historical snapshots too, everything the software captured going back weeks or months. These include rotated encryption keys, deleted files, credentials changed after a previous incident.

An attacker can walk away with data that no longer exists in production, and nothing in the environment will look any different.

The DPAPI Backup Key and Why it Matters

The DPAPI backup key is a single cryptographic key stored on every domain controller that can decrypt any DPAPI-protected data for any user in the domain, including browser-saved passwords, certificate private keys, and credentials stored in Windows Credential Manager. It exists so that if a user’s password gets reset, Windows can still recover whatever was encrypted under the old one.

A domain admin account is a controllable identity. If it gets compromised, you reset the password, disable the account, and contain the damage. The DPAPI backup key does not work that way, given that it is generated once at domain creation and never rotated.

An attacker who extracts it using Mimikatz’s lsadump::backupkeys command can decrypt every DPAPI-protected secret across the entire domain, for every user, regardless of when they last changed their password, and the decryption happens entirely offline with no authentication attempts, no logon events, and nothing in the SIEM.

That is what makes backup infrastructure the stealthier path. A domain admin compromise is detectable. Backup credentials that reach a domain controller backup let an attacker pull that backup, load it offline, and extract the DPAPI backup key directly from the Active Directory database it contains, with no trace on the live environment. Microsoft has no supported mechanism for rotating the key. If it is compromised, their own guidance is to build a brand new domain and migrate every user into it. No patch, no key rotation, just a full rebuild.

Why Backup Infrastructure Poses a Greater Risk

Broad, Long-Lived Access Across Multiple Environments

Enterprise backup systems reach deep into your environment, from on-premises Windows and Linux servers to VMware and Hyper-V infrastructure, cloud workloads in AWS and Azure, SQL and Oracle databases, NAS devices, and sometimes endpoints.

In a typical enterprise deployment, backup credentials collectively span all of it regardless of domain boundaries, operating systems, or cloud provider. An attacker who compromises the backup control plane or its credential store doesn’t necessarily get everything at once, but they get a map of your entire environment and the keys to large parts of it, often without needing to escalate privileges or move laterally the way a conventional attacker would.

Backup credentials are also typically long-lived by design. Rotating them is operationally complex because they touch every protected system, so most organizations let them run far longer than security best practice recommends. That longevity means a compromised backup account can keep working for an attacker well after the initial breach.

Stored in Unencrypted Backups, Logs and Configuration Files

Backup platforms were built solely to copy data across dozens of systems on a schedule without anyone sitting there to enter a password each time. To make that work, they store credentials for every protected system in the configuration database or a local config file on the backup server, often with nothing protecting them beyond basic file permissions.

The backup files sitting in that same infrastructure are just as exposed. In Veeam, for example, the most widely deployed backup platform in enterprise environments, backup encryption is off by default. Anyone who gets access to the repository can install a fresh Veeam instance, point it at those files, and restore the entire dataset without a single credential.

Older backup platforms wrote verbose logs that captured authentication events and, in some cases, exposed sensitive data directly. Those logs often ended up on Windows file shares with broad read access. That said, modern solutions have largely moved past this. Today, credentials are typically encrypted at rest in the configuration database or stored in external vaults. Yet, it’s worth noting that legacy deployments are still common, and misconfigured logging in newer systems can recreate the same exposure if not properly locked down.

The configuration database, the backup files, and the logs are three separate paths to the same outcome: an attacker walking away with a detailed map of credentials your backup software has touched across your entire environment, and none of it watched closely enough to catch them.

Low Detection Risk and Stealthy, Identity-Based Attacks

They are just logging in.

Yes, that is what makes backup credential abuse so difficult to catch. Backup service accounts authenticate to dozens of systems every night, moving laterally across servers, databases, and cloud workloads on a fixed schedule. That activity is expected, high-volume, and completely normal from the logging system’s perspective.

When an attacker reuses those credentials, every authentication event they generate looks identical to the legitimate backup job that ran the night before. The right credentials, hitting the right systems, at the right intervals. Nothing fires because nothing looks wrong.

The attacker is not exploiting a vulnerability, nor escalating privileges, or moving in ways the environment was not designed to allow. They are using credentials that were purpose-built for exactly this kind of broad, silent, and automated access, which makes the detection significantly harder than a conventional attack, yet not impossible.

Modern AI-powered monitoring can detect abnormalities in access patterns even when the credentials themselves are legitimate. The problem here is that the backup infrastructure is not wired up to that level of scrutiny in the first place, and security teams are only monitoring it for job failures, not behavioral anomalies.

Credential Compromise Statistics and the Cost of Breaches

The scale of the credential theft problem is well-documented. Bitsight collected 2.9 billion unique sets of compromised credentials in 2024 alone, up from 2.2 billion in 2023. ReliaQuest’s incident response data found that 85 percent of breaches they investigated between January and July 2024 involved compromised service accounts, a significant jump from 71 percent during the same period in 2023.

IBM’s X-Force reported an 84 percent increase in infostealer delivery via phishing between 2023 and 2024, accelerating further to 180 percent by early 2025.

The financial picture is just as stark. IBM’s 2024 Cost of a Data Breach report found industrial sector breach costs increased by $830,000 year-over-year. When backup infrastructure is part of the compromise, recovery timelines stretch significantly, and each additional day of downtime carries compounding financial damage through lost revenue, emergency vendor costs, regulatory notifications, and idle personnel.

Real-World Incidents and Attack Scenarios

Veeam Case Study: Red-team Exploitation of Backup Software

In a 2025 red team engagement documented by White Knight Labs, attackers compromised a Veeam backup server and wrote a custom plugin to extract the encryption salt from the Windows registry.

That gave them everything they needed to decrypt Veeam’s credential database using Windows DPAPI on the backup server itself. Inside that database was a domain admin password stored in plaintext. They used it to take over the entire domain without ever directly attacking a domain controller.

This is the core problem with backup infrastructure. It sits outside the security perimeter that protects domain controllers, it is monitored far less closely, and yet it holds credentials that are collectively just as powerful. Attackers have learned that the backup server is the easier road to the same destination.

Vulnerabilities That Expose Backup Credentials (N-central example)

The Veeam case showed what happens when an attacker gets into a single organization’s backup server. The N-central case shows what happens when the backup management platform itself is compromised.

N-able N-central is used by managed service providers to manage and protect entire client portfolios from a single dashboard. In 2025, researchers at Horizon3.ai discovered that an unauthenticated attacker could chain several API flaws to read files directly from the server’s filesystem.

One of those files stored the backup database credentials in plain text. With those credentials, the researchers accessed the entire N-central database: domain credentials, SSH private keys, and API keys for every endpoint under management.

In a typical MSP deployment, that means hundreds of client organizations fully exposed to an attacker who never authenticated to anything, all because one configuration file stored credentials in plain text.

Backup platforms need broad access to do their job. When their credential stores are exposed, the systems and accounts they cover become reachable.

Ransomware Groups Targeting Backup Tools (Agenda/Qilin and similar)

Agenda/Qilin is a ransomware-as-a-service group that has claimed over 1,000 victims since 2022. In documented attacks against critical infrastructure, their affiliates didn’t start by encrypting files. They started by finding the Veeam backup server.

Once inside, they used Veeam’s stored credentials to move through the systems it protected, deleted backup copies, and disabled recovery jobs. Only after the victim had no way to restore did the encryption payload run.

The updated Qilin.B variant automates this entire sequence, terminating Veeam, Acronis, and Sophos services and wiping Volume Shadow Copies before touching a single production file. Backup corruption is listed as a selling point in their affiliate recruitment materials.

Their approach is now widely copied across the ransomware industry, because it works.

Cloud Identity Compromise and Identity-Based Attacks

Backup software protecting cloud workloads has to authenticate somewhere, and that somewhere is the backup server, where AWS IAM policies, Azure service principals, and GCP service accounts sit stored and ready. An attacker who gets onto that server doesn’t need to crack AWS or Azure separately. They just use what is already there.

The access logs won’t help much either. The attacker is doing exactly what the backup scheduler does every night, reading data, pulling exports, touching cloud storage, so the activity looks routine to anyone reviewing it. One team owns the backup infrastructure. Another owns cloud security. In most organizations those two teams rarely talk, and that organizational gap is more useful to an attacker than any technical vulnerability.

Stealing a domain admin credential gets you one Windows environment. Compromising backup infrastructure in a hybrid organization gets you a map of the entire environment, on-premises and cloud, through accounts your own architects designed to reach large parts of it.”

Consequences of Backup Credential Compromise

Privilege escalation and lateral movement across domains

Over-privileged backup accounts can become a path to domain compromise, but the route is indirect and depends entirely on what the account can back up, restore, or read offline.

Windows’ Backup Operators group carries SeBackupPrivilege, which bypasses normal file permission checks and lets whoever holds it read sensitive system state directly from disk. On a domain controller, that includes the registry hives and the Active Directory database itself. An attacker who can back up a domain controller and load that data offline has access to credential-bearing artifacts that can be mined without sending a single authentication request to the live environment. Nothing fires in the SIEM because nothing touched a live system.

Virtual machine backups extend that same principle across your entire virtualized infrastructure. An attacker with restore access can mount a VM disk image offline and pull credentials from memory snapshots of any machine the backup software protected, again with no footprint on the original host.

That is what makes backup abuse so effective at this level. The attacker isn’t exploiting a vulnerability or escalating privileges through noisy channels. They are reading data that was purpose-built to be a complete and faithful copy of your most sensitive systems, then analyzing it somewhere you cannot see.

Data Exfiltration and Destruction of Backups

Modern ransomware runs on double extortion: encrypt the data, steal it simultaneously, then threaten public release if the ransom isn’t paid. Backup infrastructure access accelerates both halves of that attack.

For exfiltration, the backup catalog is essentially a pre-sorted map of your organization’s most valuable data. An attacker with backup access doesn’t crawl the network looking for financial records or HR files. They query the backup database, find exactly what they want, and take it.

As for destruction, access to the backup management interface lets an attacker delete backup sets directly, which means the deletions register as routine administrative operations.

No unusual disk access patterns, no permission escalation, nothing that looks malicious. The backups disappear through a legitimate channel, and your team only finds out when they try to restore.

Impaired Disaster Recovery and Extended Downtime

If an attacker has been quietly corrupting backup jobs for weeks before the ransomware triggers, your team sits down to restore and finds that the most recent working backup predates the attack by months.

That means months of transactions, configurations, customer records, and operational data that cannot be recovered. Every day spent rebuilding those systems from scratch rather than restoring from backup is a day of lost revenue, idle staff, and emergency spending, on top of the GDPR and HIPAA notification deadlines that start running the moment the breach is confirmed.

IBM’s data puts the average breach containment timeline at over 200 days even when backup infrastructure is intact. When the backups themselves have been compromised, that timeline has no natural ceiling. Organizations in that position aren’t managing a recovery so much as deciding whether the business survives it.

Best Practices to Protect Backup Infrastructure

There are no exotic solutions here. The measures that protect backup infrastructure are the same ones security teams already apply to production systems. The difference is that most organizations have never applied them to backup infrastructure at all.

Implement 3-2-1-1-0 Backup Strategies With Immutable and Offline copies

The 3-2-1-1-0 strategy is the current industry standard for ransomware-resilient backup architecture, and each number represents a specific defense against a specific failure mode.

• Keep 3 copies of your data: one primary production copy that your systems run on, one local backup copy on a separate storage system, and one additional copy stored in a separate location such as a cloud environment, a colocation facility, or an offsite tape vault
• Store those copies on 2 different media types: for example, one on disk and one on tape, or one on local disk and one in cloud object storage, so a failure in one storage technology doesn’t take everything down simultaneously
• Keep 1 copy offsite or in a separate network segment: a cloud region, a colocation facility, or a physically separate office, anywhere that a fire, flood, or ransomware attack on your primary site cannot reach
• Make 1 copy immutable or fully air-gapped: write-once storage like S3 Object Lock in Compliance mode, a hardened Linux repository, or WORM tape enforces retention at the storage layer, below the backup software’s control plane, meaning valid backup credentials alone cannot delete or overwrite it
• Verify 0 errors through actual test restores: a green completion status tells you the backup job ran, not that the data is recoverable. Test restores at least quarterly for critical systems in an isolated environment are the only way to know your backups actually work before you need them under pressure

Separate Backup Accounts From Domain Admin Accounts

• Never assign domain admin permissions to backup service accounts
• Create a dedicated login credential specifically for the backup software, separate from any human user account
• Restrict its permissions to only what each backup job actually requires: local administrator rights on specific servers for file-level backups, read-only access for database backups, snapshot privileges for VMware
• Audit its group memberships quarterly, since Active Directory group inheritance can silently expand permissions over time without anyone noticing

Use Credential Vaults, MFA and Regular Rotation of Secrets

• Store backup credentials in an enterprise secrets management platform
• Enable MFA on every login point to the backup system.
• Rotate backup credentials at least every 90 days and immediately whenever someone with access leaves the team.

Test Backup and Restore Procedures Regularly to Catch Hidden Issues

• Schedule quarterly restore tests against an isolated environment for every critical system, not just a sample
• Verify the recovered system actually boots, application data is intact, and the restore completes within your recovery time objective
• Never rely on green completion logs as proof of recoverability. Backup media degrades, catalog databases drift from actual disk contents, and configuration changes since the last backup can cause restores to fail silently
• When you find issues during testing, and you will, you find them before they matter

Apply role-based access control and require multi-person authorization for destructive actions

• Restrict deletion, pruning, retention changes, catalog maintenance, and immutability-related actions to a very small named  administrative group
• Create separate roles for backup administration, day-to-day operations, and restores, so the people who monitor jobs do not automatically gain the ability to delete data or change policy
• Put destructive changes behind formal change control and out-of-band approval, even if the backup product itself does not natively enforce a two-person workflow
• Review those privileges regularly, especially after platform changes, team changes, or integration with new workloads

Why Bacula Is a Stronger Fit for Security-Conscious Environments

Bacula Enterprise is a highly scalable, secure, and modular subscription-based backup and recovery software for large organizations. It is used by NASA, government agencies, and some of the largest enterprises in the world.

What Bacula Enterprise provides, however, is an architecture that can be implemented to limit how far that access can travel and what a compromised account can actually do with it, through architectural separation, granular access controls, strong authentication options, and storage-side protections that help reduce the blast radius of credential compromise.

Secure Architecture: Unidirectional Communications and No Direct Access From Clients

As already mentioned, Bacula’s architecture is designed to limit how far a compromised account can travel. The Director manages scheduling and job control, the File Daemon runs on the protected system, and the Storage Daemon manages backup storage. Data flows between the File Daemon and Storage Daemon directly, not through the Director.

The security consequence of that design is significant. The File Daemon has no interface to the Storage Daemon and no knowledge of where it lives until the Director initiates a job. An attacker who compromises a protected client cannot use that foothold to reach, overwrite, or delete backup data through Bacula’s own channels. The credentials required to reach storage were never on that machine.

That said, these guarantees depend entirely on how the architecture is implemented. Isolating Directors and Storage Daemons behind dedicated network segments, restricting traffic between components, and using TLS and PKI throughout are what make this separation meaningful in practice.

Flexible Role-Based Access control and Separation of Duties

Bacula maps backup permissions tightly to job function.

Operators run and monitor jobs. Restore-only roles allow file recovery without touching backup configuration.

Administrator functions are segregated from operational functions, with permissions explicitly defined rather than inherited through group membership, so there is no privilege escalation path through misconfigured AD groups.

In a properly configured deployment, a stolen operator credential cannot be used to delete backup sets or alter retention policies, and a stolen restore credential cannot touch backup configuration at all.

A deployment with segmentation, TLS/PKI, console ACLs with proper roles. FileDaemon protection techniques, and storage-side protections will dramatically reduce the blast radius of any credential compromise. For instance, a stolen operator credential cannot be used to delete backup sets or alter retention policies, and a stolen store credential cannot touch backup configuration at all.

Pruning Protection and Immutability Across Disk, Tape and Cloud Storage

Bacula’s immutability support covers every enterprise storage type: immutable Linux disk volumes, WORM tape, NetApp SnapLock, DataDomain RetentionLock, HPE StoreOnce Catalyst, S3 Object Lock, and Azure immutable blob storage. Once data is committed to an immutable repository, it cannot be altered or deleted until the retention period expires, regardless of who is authenticated.

Immutability helps protect retained recovery points from deletion or overwrite, but it does not remove the need for least privilege, monitoring, catalog protection, and regular restore testing, all being things that Bacula facilitates as well.

Vendor-Agnostic Integration and Transparency for Auditing and Compliance

Bacula integrates with SIEM and SOAR platforms, so backup security events show up in the same centralized monitoring stack your SOC team already watches, rather than sitting in a separate system that nobody checks until something goes wrong.

On the compliance side, it provides hash verification from MD5 to SHA-512 and the technical controls needed to help organizations meet GDPR, HIPAA, SOX, FIPS 140-3, NIST, and NIS 2 requirements. And because the core is open-source, every part of the security implementation can be independently verified.

Conclusion

Backup infrastructure concentrates more privileged non-human access than most security teams account for. The control plane, the credential store, and the highly privileged accounts that manage it collectively span on-premises systems, cloud workloads, databases, and virtualized environments, often with less oversight than the domain admin accounts your team watches closely.

That concentration, which is combined with the operational invisibility that backup service accounts carry by design, is exactly why ransomware groups target backup infrastructure first.

Securing it requires the same controls you already apply to production systems, which entails isolating infrastructure, least-privilege service accounts, immutable storage, and formal authorization requirements for destructive operations. Most organizations already have the means to do it. What tends to be missing is the decision to treat backup security with the same rigor as everything else.

FAQ

Can immutable storage alone protect backups if credentials are compromised?

No. Immutable storage prevents deletion of backup sets already committed to protected storage, but an attacker with backup credentials can still read and exfiltrate that data, manipulate future backup jobs, and corrupt the backup catalog. Effective protection requires combining immutability with strict access controls, formal authorization requirements for destructive operations, and behavioral monitoring.

How often should backup credentials be rotated in enterprise environments?

According to NIST SP 800-63B, mandatory periodic rotation is not recommended absent evidence of compromise, and FedRAMP baselines follow the same logic. Rotate immediately when compromise is suspected or confirmed. Beyond that, focus on strong credentials and a dedicated secrets management platform rather than arbitrary rotation schedules that will eventually fail.

What is the difference between backup administrator access and restore authority?

Backup administrator access should include platform-level control: job definitions, schedules, retention, storage targets, catalog maintenance, and other settings that change how the backup system behaves. The restore authority should be much narrower. In a well-designed Bacula deployment, restore-focused roles can be restricted by ACLs and profiles to particular clients, jobs, commands, and restore destinations, without granting the same ability to change policy or delete data.