From a network foothold to the data center through one backup server

The engagement started where most internal tests do: a wired port in an office, one standard domain account, no local administrator rights anywhere. That is the position an attacker holds after a single successful phishing email, and we ask to start there because it is the cheapest position for an attacker to reach.

It took a few hours to turn it into code execution as SYSTEM on the backup server. From there we held credentials for the virtualization platform, the storage, and a privileged domain account, plus an offline copy of every system those credentials protected.

The flaw we used was public, patched, and two years old on the day we tested.

Starting position

Internal, grey box. One standard domain user, one wired connection in a user subnet. No local administrator rights, no membership of any privileged group, no prior knowledge of the estate beyond the address range in scope.

Starting low is deliberate. Everything that follows is then a route that was open rather than one we were granted.

Finding the backup server

Locating it took no scanning of the estate, because it announced itself three ways (Network Service Discovery, T1046):

• A DNS record following the naming convention the client used for infrastructure hosts.
• A service principal name registered in Active Directory. Any authenticated domain user can enumerate SPNs, and infrastructure services are named plainly.
• TCP 9392 open from the user subnet, the default listener for the Veeam Backup Service.

The third item is the finding that mattered and the one that was cheapest to fix. There is no reason a workstation in a user subnet should be able to open a session to the backup service.

The .NET Remoting handshake identifies the build, so confirming the version took one connection. It was 12.1.2.172.

The vulnerability

CVE-2024-40711 is a deserialization flaw in Veeam Backup and Replication, reported by Florian Hauser of CODE WHITE GmbH and fixed in build 12.2.0.334. The full analysis is watchTowr Labs’ write-up, which is where the detail below comes from.

Veeam exposes a custom .NET Remoting endpoint through Veeam.Common.Remoting.CBinaryServerFormatterSink. Deserialization there is defended with a whitelist on the outer BinaryFormatter, which is the right idea. The bypass is a bridge gadget. CDbCryptoKeyInfo sits on the whitelist, and deserializing it triggers a second, nested deserialization through CProxyBinaryFormatter.Deserialize. That inner pass runs in blacklist mode rather than whitelist mode, and the blacklist was missing System.Runtime.Serialization.ObjRef. A payload that reaches the inner pass carrying an ObjRef gadget gets code execution.

There were two defects, and Veeam shipped the fixes in two different releases:

• 12.1.0.2131 and earlier. CConnectionInterceptor.IsConnectingIdentityAuthorized returned true unconditionally, so anonymous connections were accepted. Combined with the deserialization flaw, this is unauthenticated remote code execution.
• 12.1.1.56 through 12.1.2.172. The authorization check was fixed. The deserialization flaw was not. Authentication is required, and any account satisfies it.
• 12.2.0.334. Both closed.

The client was on 12.1.2.172, the last build in the middle band. We had a standard domain account. That was the whole requirement.

A fix that adds an authentication requirement reduces exposure without removing it, and the remaining distance is one valid account. For an internal attacker, or for an external one after any successful phish, that distance is close to zero. The service runs as SYSTEM, so the result is SYSTEM on the backup server.

What the backup server held

A backup server is not a file server that happens to keep copies. To do its job it needs standing credentials for everything it protects, and it keeps them. The configuration database on this one held:

• Credentials for the virtualization platform, used for VM-level backup.
• A domain account with rights for application-aware processing, meaning it could log on to the systems it quiesced.
• Storage credentials for snapshot integration.
• Credentials for the repository hosts.

Veeam encrypts these in its configuration database, and the keys are protected with DPAPI on the host itself. With SYSTEM on that host the encryption is a formality. The decryption path is documented and public tooling exists for it (Credentials from Password Stores, T1555).

One exploit against one host produced the credential set for the virtualization platform, the storage, and a privileged domain account.

Two routes to the same data

From the backup server there were two ways to the client’s data. We demonstrated both, because they fail differently and are detected differently.

The live route. The virtualization credentials gave full administrative control of the platform: every virtual machine, console access to all of them, and the ability to power off, clone, or snapshot anything (Valid Accounts, T1078). At that point the operators held the data center. Controls running inside the guests are not on this path, because the access is underneath them.

The offline route. The backups themselves. We mounted a recent backup of a domain controller and extracted NTDS.dit with the SYSTEM hive (OS Credential Dumping: NTDS, T1003.003), which yields every credential in the domain including krbtgt. The extraction happened on our machine against a copy. No process ran on a domain controller, no agent was involved, and nothing in the client’s detection stack had anything to see.

The offline route is the one that gets underestimated, and retention works against the defender. A backup set covering twelve months contains twelve months of credential material, including accounts since disabled and passwords since changed. Reuse does the rest.

What a ransomware operator does with the same access

This is not a theoretical path. CVE-2024-40711 was publicly reported as exploited by Akira and Fog affiliates within about a month of the patch, and backup infrastructure is the first target in that playbook rather than the last. Inhibit System Recovery (T1490) is what converts an intrusion into a payable ransom. An operator holding what we held deletes the restore points first and encrypts afterwards, so the recovery plan is gone before anyone notices the encryption.

Why it was unpatched

The useful question is not why nobody patched. It is why this particular host fell out of a process that worked elsewhere.

• It was not in the patch cycle. Backup infrastructure sat with the infrastructure team rather than the Windows patching pipeline, and a Veeam update is an application upgrade, not a Windows update. Nothing in the existing tooling covered it.
• Upgrading needs a window in which backups do not run. That window is unpopular and kept slipping.
• It was not internet-facing. Every prioritization the client used ranked by external exposure, and this host scored low on all of them.

The third reason is the one worth arguing with, because internal exposure was the entire attack path. The host was unreachable from the internet and reachable from every desk in the building.

What we recommended

Ordered by how quickly each one closes the path, not by how much work it is.

1. Patch to 12.2.0.334 or later, which closes both defects.
2. Remove the network path. The backup service listener has no business being reachable from user subnets. Restrict management access to a dedicated administrative network. This control alone breaks the chain on an unpatched server, and on the next vulnerability in the same service before it has a CVE.
3. Treat the backup server as Tier 0. It holds credentials for the identity and virtualization planes, which makes it a control plane asset, as covered in our earlier piece on attack paths into Tier 0. That means a separate administrative identity, no logging in with production domain accounts, and dedicated admin workstations.
4. Cut the standing credential set. Application-aware processing needs privilege. It rarely needs Domain Admin. Scope the account to the workloads it touches.
5. Keep immutable and offline copies. Anyone holding the access we held can delete everything the backup server can reach. Hardened repositories with immutability, or copies the backup server has no path to, are what survives losing it.
6. Detect on the path rather than the payload. Alert on connections to the backup service from outside the administrative network, on unexpected child processes under the Veeam service account, and on bulk deletion of restore points.

Rank the systems in an estate by what an attacker gets from owning each one, and the backup server lands at or near the top of every environment we test. It is given credentials to everything else so that it can do its job, and it holds a complete, offline, historical copy of the data those credentials protect.

It is also, routinely, the host that is patched last, segmented least, and monitored as if it were an appliance in the corner of the room. The gap between what that system is worth to an attacker and how it is administered is the finding. The CVE was only the way in.