Breaking Bad Backups

src/SUMMARY.md

@@ -467,6 +467,7 @@
 - [Pentesting JDWP - Java Debug Wire Protocol](network-services-pentesting/pentesting-jdwp-java-debug-wire-protocol.md)
 - [Pentesting Printers$$external:http://hacking-printers.net/wiki/index.php/Main_Page$$]()
 - [Pentesting SAP](network-services-pentesting/pentesting-sap.md)
+- [Pentesting Veeam Backup & Replication](network-services-pentesting/pentesting-veeam-backup-and-replication.md)
 - [Pentesting VoIP](network-services-pentesting/pentesting-voip/README.md)
   - [Basic VoIP Protocols](network-services-pentesting/pentesting-voip/basic-voip-protocols/README.md)
     - [SIP (Session Initiation Protocol)](network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md)

src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md

@@ -86,6 +86,12 @@ This attack leverages SMB authentication sessions to access a target machine, gr
 - The authenticating user must have Local Admin access on the relayed host.
 - SMB signing should be disabled.<sup>[[5]](#references)</sup>
 
+Related backup-management chain:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-veeam-backup-and-replication.md
+{{#endref}}
+
 #### 445 Port Forwarding and Tunneling
 
 In scenarios where direct network introduction isn't feasible, traffic on port 445 needs to be forwarded and tunneled. Tools like [**PortBender**](https://github.com/praetorian-inc/PortBender) help in redirecting port 445 traffic to another port, which is essential when local admin access is available for driver loading.

src/network-services-pentesting/pentesting-smb/README.md

@@ -542,6 +542,12 @@ find / -name rclone.conf 2>/dev/null
 rclone reveal <obscured_secret>
 ```
 
+Related Veeam backup-artifact workflow:
+
+{{#ref}}
+../pentesting-veeam-backup-and-replication.md
+{{#endref}}
+
 ## Authenticate using Kerberos
 
 You can **authenticate** to **kerberos** using the tools **smbclient** and **rpcclient**:

src/network-services-pentesting/pentesting-veeam-backup-and-replication.md

@@ -0,0 +1,122 @@
+# Pentesting Veeam Backup & Replication
+
+{{#include ../banners/hacktricks-training.md}}
+
+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.<sup>[[3]](#references)</sup>
+
+Use the dedicated pages for the generic primitives instead of treating them as Veeam-specific flaws:
+
+- [LLMNR/NBT-NS poisoning and NTLM relay](../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
+- [HTTP WSUS interception](../windows-hardening/windows-local-privilege-escalation/README.md#wsus)
+- [Machine-scope DPAPI](../windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.md#machinesystem-key-generation)
+- [SMB share enumeration](pentesting-smb/README.md#shared-folders-enumeration)
+
+## 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.<sup>[[3]](#references)[[4]](#references)</sup>
+
+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.<sup>[[5]](#references)</sup>
+
+```bash
+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.<sup>[[3]](#references)</sup>
+
+### 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](https://github.com/mattmillen15/VeeamThief) updates the workflow for Veeam v12+ by implementing the expected `RetrieveInternalContent` responses.<sup>[[1]](#references)[[2]](#references)[[3]](#references)</sup>
+
+Start the listener:
+
+```bash
+sudo python3 VeeamThief.py -p 8443
+```
+
+Then, in an authorized test environment:
+
+1. In **Backup Infrastructure**, start **Add Server -> VMware vSphere**.
+2. Set the server to `<attacker-ip>:8443` and continue through the test certificate prompt.
+3. Select the target entry from Veeam Credential Manager.
+4. 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.<sup>[[1]](#references)[[2]](#references)</sup>
+
+### 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.<sup>[[3]](#references)</sup>
+
+## 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.<sup>[[3]](#references)[[6]](#references)</sup>
+
+```bash
+find /mnt/backups -type f \
+  \( -iname '*.vbk' -o -iname '*.vbm' -o -iname '*.vib' \
+     -o -iname '*.vhd' -o -iname '*.vhdx' -o -iname '*.vmdk' \)
+```
+
+```powershell
+# 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.<sup>[[3]](#references)</sup>
+
+```bash
+impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL
+impacket-secretsdump -sam SAM -system SYSTEM LOCAL
+```
+
+### Automate VHD/VHDX/VMDK triage with VHDVomit
+
+[VHDVomit](https://github.com/mattmillen15/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.<sup>[[3]](#references)[[7]](#references)</sup>
+
+```bash
+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](../windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.md#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.<sup>[[3]](#references)</sup>
+
+## 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.<sup>[[8]](#references)</sup>
+
+Technical checks derived from the attack paths above include:<sup>[[3]](#references)[[8]](#references)</sup>
+
+- 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.
+
+## References
+
+- [1] [sadshade/veeam-creds - Veeam Credential Recovery and original veeampot technique](https://github.com/sadshade/veeam-creds)
+- [2] [mattmillen15/VeeamThief - rogue vSphere credential capture for Veeam v12+](https://github.com/mattmillen15/VeeamThief)
+- [3] [Adversary Consulting - Breaking Bad Backups](https://adversaryco.com/blog/breaking-bad-backups)
+- [4] [Veeam - How Database Data Encryption Works](https://helpcenter.veeam.com/docs/vbr/userguide/encryption_database_hiw.html)
+- [5] [NetExec `veeam` credential-extraction module](https://github.com/Pennyw0rth/NetExec/blob/main/nxc/modules/veeam.py)
+- [6] [Veeam - Extract Utility](https://helpcenter.veeam.com/docs/vbr/userguide/extract_utility.html)
+- [7] [mattmillen15/VHDVomit - SMB disk-image credential extraction](https://github.com/mattmillen15/VHDVomit)
+- [8] [Veeam - Securing Backup Infrastructure](https://helpcenter.veeam.com/docs/vbr/userguide/securing_backup_infrastructure.html)
+
+{{#include ../banners/hacktricks-training.md}}

src/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.md

@@ -281,7 +281,11 @@ Get-VHD -VMId <vm-guid>
 Mount-VHD -Path 'C:\HyperV\Virtual Hard Disks\DC01.vhdx' -ReadOnly
 ```
 
-From there, reuse the `Backup Operators` workflow to copy `Windows\NTDS\ntds.dit` and the registry hives offline.
+From there, reuse the `Backup Operators` workflow to copy `Windows\NTDS\ntds.dit` and the registry hives offline. Related backup-file workflow:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-veeam-backup-and-replication.md
+{{#endref}}
 
 ## Group Policy Creators Owners	
 

src/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.md

@@ -69,6 +69,12 @@ mimikatz lsadump::secrets /system:C:\path\system.hiv /security:C:\path\security.
 # Look for the DPAPI_SYSTEM secret in the output
 ```
 
+Veeam-specific DPAPI example:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-veeam-backup-and-replication.md
+{{#endref}}
+
 ### Protected Data by DPAPI
 
 Among the personal data protected by DPAPI are: