The moment an attacker owns your backup server, the encryption event you’re trying to prevent has already been decided. Not because they’ve touched a single production file yet — they haven’t — but because the backup server is the one machine in most environments that carries credentials to every system it touches, has write access to every protected volume, and does all of this while running as a domain-joined service account with privileges nobody would explicitly grant a user but that accumulate naturally as backup jobs are configured. Ransomware operators figured this out years before most defenders did. By 2025, they had automated the pivots. By 2026, multiple ransomware families treat the backup server as the first objective, not the last.
This is that kill chain, in full, and the architecture decisions that actually stop it.
The Privileged Position Nobody Thinks About
Domain controllers get dedicated hardening guides, tiered access models, and jump-host requirements. Backup servers — which in many environments have more implicit access than DCs — typically get the same treatment as a file server.
Consider what a Veeam Backup & Replication server actually holds:
- Credentials to every protected workload. The credentials manager stores service account passwords for every vCenter, ESXi host, NAS mount, SQL instance, and Windows host in scope. These are DPAPI-encrypted at rest, which sounds secure until you realize DPAPI is machine-keyed and any process running on the machine can decrypt them.
- Network-level access to everything it backs up. Firewall rules typically permit the backup server to reach production subnets broadly — agents pull data, mount services attach to hypervisors, and storage snapshots require elevated rights. This is operational necessity that becomes an attacker’s highway.
- Domain membership. Veeam’s own hardening documentation explicitly recommends running the backup server in a workgroup, not joined to the domain. Most production deployments ignore this. Domain membership means a single compromised domain credential can be the first step toward code execution on the machine that holds every other credential in the environment.
This isn’t a Veeam-specific problem — it applies to Commvault, Cohesity, NetBackup, and every other enterprise backup platform. It is a structural problem: backup software is designed to have access, and that design becomes the vulnerability.
Step-by-Step: The Backup-First Kill Chain
The attack pattern has been documented repeatedly in post-incident reports, red team writeups, and threat intelligence. Here is the canonical sequence.
Step 1: Initial Access via the Perimeter, Not the Backup Server
In nearly every documented case, attackers enter through something other than the backup server itself: a compromised VPN appliance, a phished credential, an unpatched edge device. Sophos X-Ops documented four attacks exploiting CVE-2024-40711 in Veeam in late 2024, and in each case the initial foothold was a VPN gateway without MFA. The backup server wasn’t the entry point; it was the prize.
This matters for detection: an attack on the backup server almost always has a precursor event elsewhere in the environment. The question is whether you’re correlating signals across the perimeter and the internal network, or treating them as separate alert queues.
Step 2: Locate the Backup Server
Once inside, the backup server becomes an immediate reconnaissance target. Veeam’s management interface runs on port 9392 and the mount service on port 8000. Shodan indexes thousands of Veeam instances exposed directly to the internet; inside a corporate LAN, a simple port scan finds them in seconds. Attackers also hunt for DNS names containing “veeam,” “backup,” or “bkp,” and grep Windows event logs for Veeam service account names that appear across the domain.
Step 3: Code Execution on the Backup Server
This is where the CVE history becomes damning. In September 2024, Veeam patched CVE-2024-40711 — a CVSS 9.8 unauthenticated RCE in Backup & Replication 12.x. The bug was a deserialization flaw reachable via an HTTP POST to /trigger on port 8000. No credentials required. Within two weeks of a public proof-of-concept, Akira and Fog ransomware were exploiting it in the wild. Frag ransomware followed. CISA added it to the Known Exploited Vulnerabilities catalog. Within 90 days of patch release, there were at least four distinct ransomware families using it routinely.
In January 2026, CVE-2025-23121 was patched — any authenticated domain user could achieve RCE on a domain-joined backup server. In June 2026, CVE-2026-44963 dropped with a CVSS of 9.4, the same access profile: any domain credential, RCE on the backup host. The specific deserialization sink changes each time. The access requirement keeps dropping.
If you run a domain-joined Veeam server, you have been one compromised helpdesk account away from losing the backup server at least three times in the past eighteen months.
Step 4: Extract Every Credential in the Environment
This is the part that turns a backup server compromise into a full-estate loss, and it is fully automated.
Veeam stores managed credentials in the VeeamBackup SQL database under the dbo.Credentials table. The passwords are encrypted using the Windows Data Protection API (DPAPI) with a machine-specific key and a registry salt. On any version prior to 12.1, you could decrypt them with a single call to a Veeam .NET method:
| |
On 12.1 and later the call is native but functionally identical:
| |
There is a public GitHub repository — sadshade/veeam-creds — that wraps the full extraction process in a PowerShell script. There is a Metasploit post-exploitation module (post/windows/gather/credentials/veeam_credential_dump). White Knight Labs published a detailed red-team write-up in December 2025 titled “From Veeam to Domain Admin: Real-World Red Team Compromise Path.” This is not esoteric knowledge. It is tooled, documented, and searchable.
What comes out of that extraction? Every credential ever entered into the Veeam credential manager: vCenter service accounts, ESXi root passwords, domain service accounts used for guest processing, SQL sysadmin accounts used for application-aware backups. In a typical enterprise deployment, this is 30 to 200 credentials, most of them highly privileged.
Step 5: Disable Backup and Deploy Payload
With domain admin or vCenter admin in hand, the remaining steps are mechanical. Shadow copies are deleted (vssadmin delete shadows /all /quiet). The Windows backup catalog is destroyed (wbadmin delete catalog -quiet). Veeam backup jobs are stopped and repositories are deleted or encrypted directly. Only then — after recovery has been systematically eliminated — does the encryption payload run against production.
The Qilin/Agenda ransomware group has pushed this sequence further: they deploy a Linux-based payload binary that runs on Windows hosts via tools like Splashtop Remote and WinSCP, bypassing Windows-focused EDR entirely. Trend Micro documented this technique in late 2025. The backup credentials are harvested before the payload deploys; the goal is to be certain there is no clean path to recovery before the encryption event announces itself.
The dwell time between initial access and encryption has collapsed from 70+ days in 2022 to approximately four days in 2025. In the fastest quartile of intrusions, exfiltration begins within 72 minutes of initial access. The backup server compromise is not a leisurely operation — it happens in the first hours, before any alert review cycle has completed.
The CVE Treadmill Is Not a Strategy
Veeam ships a critical RCE roughly every eight to twelve months. The pattern is consistent enough that it has become a planning assumption for ransomware operators. CISA’s KEV catalog lists four separate Veeam vulnerabilities that were exploited in real attacks before the relevant advisory fully diffused through the market.
Patching matters and you should do it within 24 hours of a Veeam advisory. But patching a domain-joined Veeam server and calling it hardened is not hardening — it is keeping the attack surface at baseline while leaving the architectural problem intact. The architectural problem is that the backup server is domain-joined, reachable from corporate workstations, and carries credentials that give lateral movement to every protected host.
The answer is not to trust that the next CVE won’t be weaponized before you patch it. It is to design the backup infrastructure so that code execution on the backup server is not equivalent to owning the domain.
Detection Opportunities
There are specific signals that appear in the attack chain before the encryption event. None of them are high-fidelity in isolation; together they correlate clearly.
On the backup server host:
Veeam.Backup.MountService.exespawningnet.exeorcmd.exeas child processes. This is the exact indicator Sophos documented in the CVE-2024-40711 attacks — the exploit ran code via the mount service.- New local administrator accounts created during off-hours or with generic names (“point”, “admin1”, “svc_”).
- PowerShell accessing
HKLM:\SOFTWARE\Veeam\Veeam Backup and Replicationregistry keys, particularly theSqlDatabaseEncryptionKeyvalue. - SQL queries against
VeeamBackup.dbo.Credentialsfrom processes other than the Veeam service itself.
On the domain and perimeter:
- New TGS tickets (Kerberoasting) for Veeam service account SPNs from unexpected endpoints.
- Authentication from the backup server to hosts it has not previously communicated with.
vssadmin,wbadmin, orbcdeditexecutions with deletion or disable arguments anywhere in the environment.- Outbound connections from the backup server to unfamiliar external IPs on port 443 — data staging before encryption.
Modern SIEM platforms can alert on all of these. The question is whether anyone has written the rules, which requires knowing that the backup server is high-value and that the attack chain flows through it.
Architecture That Actually Survives
The following design choices make the backup-first kill chain significantly harder. They are not theoretical — they are what Veeam’s own hardening documentation has recommended for years, and what the documented incident history shows would have broken the attack chain.
Remove the backup server from the domain
A workgroup-mode Veeam server cannot be compromised via a domain credential. CVE-2025-23121 and CVE-2026-44963 both required domain membership; neither applies to a workgroup host. Veeam’s best practices guide explicitly documents the workgroup configuration and the tradeoffs. The operational inconvenience is real but manageable. The security benefit is categorical.
If removing domain membership is politically impossible, at minimum put the backup server in a dedicated management domain with no trust relationship to the production domain. An attacker who compromises a production domain user should not automatically have a path to the backup server.
Network-isolate the backup server
The backup server needs to reach production hosts for backup jobs. Production hosts and workstations should not be able to initiate connections to the backup server except through a hardened jump host. Specifically:
- Block inbound to port 9392 (Veeam service) and port 8000 (mount service) from all corporate subnets.
- Restrict outbound from the backup server to only the specific IPs and ports required by active backup jobs.
- Ensure internet egress from the backup server is blocked or proxied and logged. Data exfiltration before encryption is a standard step; a backup server with unrestricted internet access makes it trivial.
Least-privilege service accounts — actually
Stop using domain admin for Veeam guest processing. Veeam documents the minimum permissions required for each backup job type. A guest processing account for Windows VMs needs Log on as a service, local admin on target VMs, and nothing else. It does not need domain admin. These are not the same thing, and letting them collapse into “it’s easier with domain admin” is how you get 200 privileged credentials in the credential manager.
Veeam Hardened Repository with chattr immutability
Veeam’s Linux Hardened Repository uses chattr +i at the filesystem level to make backup files immutable once written. The lockdown uses a one-time-use credential pair that the backup server itself cannot reuse — even if you have code execution on the VBR host, you cannot unlock the hardened repository files during the retention window. This is what makes it meaningful, and it is why the attack chain step where ransomware operators delete Veeam repositories directly does not work against a properly configured hardened repo.
The gotcha: the immutability window must be set to a value longer than your longest dwell time assumption. If attackers sit in your network for four days before acting, and your immutability window is 48 hours, the math doesn’t work.
The 3-2-1-1-0 Rule — and Why the Last Zero Is the Hard Part
The updated backup rule most practitioners now cite is 3-2-1-1-0:
- 3 copies of data
- 2 different media types
- 1 copy offsite
- 1 copy offline or immutable
- 0 unverified backups — every backup must have been successfully restored at least once
The “1 immutable” copy is often implemented as S3 Object Lock. Here the critical implementation detail is mode: governance mode allows any account with s3:BypassGovernanceRetention to delete or overwrite objects before the retention period expires. If your cloud admin credentials are among those dumped from the Veeam credential manager, governance mode is not protection. Compliance mode does not allow any principal — including root — to override retention. That is the mode that survives a full credential compromise.
The “0 unverified” piece is the one most organizations fail. A backup nobody has ever restored is not a backup — it is an optimistic file. The moment a ransomware event forces a restore is the wrong time to discover that your Veeam tape jobs have been silently failing for six weeks because of a service account password rotation. Automated restore verification, even a monthly partial restore to an isolated test environment, closes the loop that the rest of the architecture depends on.
Five Things to Do This Week
1. Audit domain membership. If your Veeam server is domain-joined, start the workgroup migration planning now. At minimum, confirm it is not in the same OU as production servers and that no production-tier service accounts have logon rights to it.
2. Rotate and scope service account credentials. Pull the list of credentials stored in the Veeam credential manager and verify that each one has the minimum permissions documented in Veeam’s least-privilege guides. Remove or scope-down anything running as domain admin that doesn’t need to be.
3. Block inbound port 8000 and 9392 from non-backup subnets. These are the ports that CVE-2024-40711 and related flaws exposed. Workstations and general corporate subnets should not be able to reach the Veeam service layer. A quick firewall audit of who can initiate connections to those ports is often revelatory.
4. Enable SIEM alerting on Veeam.Backup.MountService.exe child processes and VeeamBackup DB registry reads. Both are low-noise signals that appear early in the documented attack chains. Neither should fire in normal operations.
5. Verify your immutable backup copy is actually immutable. If you use S3 Object Lock, confirm the bucket is in compliance mode. If you use Veeam Hardened Repository, confirm the immutability window exceeds your assumed dwell time. Then restore from it — in a test environment — and record the time.
The backup server is not a storage appliance that happens to hold some credentials. It is the highest-trust machine in most environments, and it needs to be treated like one. The ransomware operators already know this. The only question is whether your infrastructure posture reflects the same understanding they have.
Research for this piece draws on Sophos X-Ops’ documentation of the CVE-2024-40711 exploitation chain, White Knight Labs’ “From Veeam to Domain Admin” red-team write-up (December 2025), Trend Micro’s analysis of the Qilin/Agenda cross-platform technique (2025), Veeam’s own hardening documentation and best practices guide, and the public veeam-creds tooling repository.