> root@backup-mgmt:~# veeamconfig backup list --all | grep 'DC01' && echo 'full AD backup available'<span class="cursor-blink">_</span>_
There is a particular irony in compromising an organisation through its backup infrastructure. Backups exist to protect data — to ensure that when something goes wrong, the organisation can recover. They are the safety net, the last line of defence, the system that exists precisely for the worst-case scenario. They are also, by definition, a centralised repository containing a copy of everything the organisation considers important enough to protect.
Every file server. Every database. Every domain controller. Every application. Compressed, catalogued, and stored in one place — often on infrastructure that receives less security attention than the systems it is backing up.
On this engagement, we accessed the backup infrastructure through an exposed management interface with outdated firmware, extracted credentials from the backup catalogue, and used those credentials to restore and access full system images — including a complete Active Directory backup from which we recovered every domain credential. The backup system was not the target. It was the shortcut to everything.
The client was a manufacturing company with approximately eight hundred employees across a headquarters site and two production facilities. Their IT infrastructure was substantial — a virtualised on-premises environment running several hundred servers, supported by a dedicated backup infrastructure comprising a commercial backup application, a purpose-built backup appliance, and a tape library for offsite archival.
We had been engaged for an internal penetration test with a broad scope covering all internal VLANs. The client had recently invested in a ransomware resilience programme following industry guidance, and their backup infrastructure had been upgraded eighteen months prior as part of that programme. They were confident that their backup systems were properly isolated and secured.
The backup systems were on a dedicated VLAN. The backup VLAN was documented as isolated from the user network. We were given a starting position on the user VLAN.
The isolation was not as complete as the documentation suggested.
During our initial reconnaissance of the user VLAN at 10.10.2.0/24, we performed DNS enumeration against the internal domain — querying for common hostnames associated with backup infrastructure. This is a standard step in our methodology; backup servers frequently have predictable naming conventions.
The backup VLAN was reachable from the user VLAN. The firewall rules permitted access to the backup servers' management interfaces — HTTPS, the Veeam console port, RDP, and SSH. The documentation stated that the backup VLAN was isolated from user networks, but the firewall rules told a different story.
Investigation later revealed the reason: when the backup infrastructure was upgraded eighteen months prior, the installation engineers had requested temporary firewall rules to manage the deployment from their workstations on the user VLAN. The rules were created as 'temporary' but were never removed. This pattern — temporary rules becoming permanent — appeared in our tenth article in this series. It remains the most common cause of segmentation failure we encounter.
Three devices were identified on the backup VLAN: a backup server running the backup application's management console, a Veeam Backup & Replication server, and a purpose-built backup appliance — a hardware device from a specialist vendor that provided deduplicated storage and replication capabilities.
We focused first on the backup appliance at 10.10.8.20. Purpose-built backup appliances are hardware devices — typically rack-mounted servers with custom firmware — sold by specialist vendors as turnkey solutions for data protection. They provide a web-based management interface, deduplicated storage, replication to secondary sites, and integration with backup software such as Veeam, Commvault, or Veritas.
These appliances are frequently treated as 'set and forget' infrastructure. They are deployed by the vendor's professional services team, configured during installation, and then left to run. Firmware updates are deferred because they require maintenance windows and carry the risk of disrupting backup operations. Management interfaces are secured with the credentials set during installation and rarely changed.
The appliance's web management interface was accessible on port 443. The login page displayed the vendor's branding and the firmware version.
The firmware was seven major releases behind the current version — over two years without an update. The primary admin password had been changed during installation, but the appliance shipped with a second administrative account: a maintenance account intended for vendor support access. The maintenance account's default password had not been changed. It had full administrative access to the appliance.
The existence of secondary administrative accounts on appliances is a recurring theme across our engagements. Vendors include them for support and troubleshooting purposes. They are documented in installation guides but are rarely mentioned during handover to the customer's operations team. They persist with default credentials because nobody knows they exist.
The backup appliance's maintenance account retained the vendor's default password, providing full administrative access to the appliance and all stored backup data. The appliance firmware was seven major versions behind the current release, missing over two years of security patches.
With administrative access to the backup appliance, we examined its storage catalogue. The appliance was the primary backup target for the organisation's Veeam Backup & Replication infrastructure. Every backup job in the environment wrote its data to this device.
The appliance contained the organisation's complete backup catalogue — domain controllers, file servers, SQL production databases, Exchange mail, the ERP system, web servers, and the SCADA historian from their manufacturing environment. Every critical system in the organisation had a full backup stored on this single device.
The backup of particular interest was the Veeam-Config-Backup — Veeam's own configuration backup, which contains the Veeam server's settings, job definitions, and — critically — the encrypted credentials that Veeam uses to authenticate to the systems it backs up.
We turned our attention to the Veeam Backup & Replication server at 10.10.8.11. The Veeam console was accessible on port 9393 via HTTPS. The server was running Veeam Backup & Replication v11 — a version that had reached end of support, superseded by v12. More importantly, v11 contained a known vulnerability: CVE-2023-27532, a high-severity flaw that allowed unauthenticated access to the Veeam configuration database, including the encrypted credentials stored within it.
This vulnerability had been publicly disclosed in March 2023 and patched in Veeam v11a (P20230227). The client's Veeam server had not been patched.
Seven credential sets recovered — without authenticating to the Veeam server. The vulnerability allowed unauthenticated access to the encrypted credentials, and the decryption was performed using information available through the same API. The credentials included three domain service accounts, root SSH credentials for Linux web servers, the SQL Server SA account for the production database, and the administrator password for the backup appliance itself.
The svc_veeam_backup account was of immediate interest. Veeam requires a service account with elevated privileges to perform backup operations — it needs to read all data on the systems it protects. We enumerated the account's domain permissions.
The Veeam backup service account was a Domain Admin. This is a configuration that Veeam's own documentation explicitly advises against — Veeam does not require Domain Admin privileges and provides guidance on configuring a service account with minimum necessary permissions. However, granting Domain Admin to the backup service account is the path of least resistance during installation, and it is depressingly common.
We now had Domain Admin credentials — extracted from a backup server, via a vulnerability that had been patched nearly two years earlier, on infrastructure that was supposed to be isolated from the user network.
The Domain Admin credentials alone were sufficient for full domain compromise. However, to demonstrate the additional risk posed by the backup data itself, we examined the domain controller backup stored on the appliance.
The DC-Daily backup contained full system images of both domain controllers. A domain controller backup includes the NTDS.dit file — the Active Directory database containing every user account, every password hash, every group membership, and every trust relationship in the domain. An attacker with access to an NTDS.dit file and the corresponding SYSTEM registry hive can extract every credential in the domain offline, without generating a single authentication event on the live domain controllers.
This is the critical distinction between attacking the backup and attacking the live system. A DCSync attack against a live domain controller generates Event ID 4662 — detectable by a properly configured SIEM. Extracting credentials from a backup generates no events whatsoever, because the backup is a static file on a storage device. The extraction is invisible.
One thousand two hundred and forty-seven domain accounts extracted from a backup image. Offline. Silent. No SIEM alert. No Event ID 4662. No detection of any kind. The backup had been taken the previous night. The credentials were current.
The domain controller backup provided credential access, but the other backups on the appliance represented equally severe data exposure risks — risks that existed independently of the domain compromise.
| Backup | Contents Accessible | Risk |
|---|---|---|
| FileServers-Daily | Complete file share contents including HR records, financial reports, contracts, intellectual property, and board documentation | Data exfiltration — bulk access to all corporate documents without accessing the live file servers |
| SQL-Production | Full database backup of the ERP system's SQL Server instance — customer records, order history, financial transactions, supplier data | PII exposure, commercial data theft — GDPR breach, competitive intelligence |
| Exchange-Daily | Complete Exchange database — every mailbox, every email, every attachment for all 800 staff over the retention period | Email surveillance, insider knowledge, legal privilege, M&A intelligence |
| SCADA-Historian | Historical process data from the manufacturing SCADA system — production parameters, equipment configurations, operational thresholds | OT intelligence — understanding of manufacturing processes, potential for targeted OT attacks |
An attacker with access to the backup infrastructure does not need to compromise individual servers. They do not need to move laterally through the network. They do not need to evade EDR on workstations. The backups contain everything — and accessing the backups generates none of the telemetry that would be generated by accessing the live systems.
This is why ransomware operators target backup infrastructure first. Destroying the backups removes the organisation's ability to recover. But accessing the backups before encrypting them provides the stolen data that enables double extortion — the threat to publish sensitive information if the ransom is not paid.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | DNS enumeration identified backup infrastructure on dedicated VLAN | Predictable hostnames; DNS records accessible from user VLAN |
| 02 | Confirmed backup VLAN management ports reachable from user VLAN | Temporary firewall rules from deployment never removed |
| 03 | Accessed backup appliance via default maintenance account | Secondary admin account with default credentials; firmware 2 years old |
| 04 | Exploited CVE-2023-27532 on Veeam server for credential extraction | Veeam unpatched for nearly 2 years; known critical vulnerability |
| 05 | Recovered 7 credential sets including Domain Admin service account | Veeam service account granted Domain Admin instead of minimum privilege |
| 06 | Mounted DC backup; extracted 1,247 domain credentials offline | Backup data unencrypted; no detection of offline credential extraction |
The security industry has spent years telling organisations to improve their backup resilience. The ransomware epidemic has driven massive investment in backup infrastructure — immutable storage, air-gapped copies, offline tapes, rapid recovery capabilities. This investment is essential and we strongly support it.
But resilience and security are not the same thing. An organisation can have excellent backup resilience — the ability to recover from a ransomware attack — whilst having terrible backup security — the ability to prevent an attacker from accessing the backup data in the first place.
The most impactful immediate change is removing the Veeam service account from Domain Admins and implementing the minimum-privilege model documented in Veeam's own hardening guide. Veeam requires specific permissions on the systems it backs up — local administrator on Windows servers, root or sudo on Linux, and specific SQL permissions for application-aware processing. These are granular, documentable permissions that do not require Domain Admin.
Backup encryption must be enabled for data at rest and in transit. If the backup data had been encrypted with a key stored separately from the backup infrastructure, the offline extraction of NTDS.dit and other sensitive data would not have been possible even with administrative access to the appliance.
Immutable backup repositories — using hardened Linux servers with XFS reflink-based immutability — ensure that backup data cannot be modified or deleted, even by an administrator with full access to the Veeam console. This is the most effective defence against ransomware operators who target backup infrastructure. It does not prevent the data access risk we demonstrated, but it protects the recovery capability.
Backup infrastructure must be included in vulnerability management and penetration testing scope. The Veeam CVE we exploited had been public for nearly two years. The appliance firmware was seven versions behind. Neither finding would have persisted if the backup infrastructure had been subject to the same patching and scanning discipline applied to production servers.
There is a paradox at the heart of backup security. The more comprehensive the backup — the more systems it covers, the more data it contains, the more frequently it runs — the more valuable it becomes as a target. A perfect backup strategy, from a resilience perspective, creates a single location containing a copy of every piece of sensitive data the organisation owns. From a security perspective, that single location is the most valuable target in the environment.
The organisation in this engagement had invested in a modern backup infrastructure. They had a dedicated appliance, a professional backup application, a structured retention policy, and an offsite tape rotation. Their ransomware resilience was above average. But the security of the backup infrastructure itself — the firmware currency, the credential management, the network isolation, the encryption posture — had not received equivalent attention.
The backup system held a copy of everything. We accessed it through a maintenance account that nobody knew existed, on firmware that nobody had updated, via a network path that nobody had closed. The safety net was the attack surface.
Until next time — stay sharp, stay curious, and ask yourself: who has access to your backups? You might find the answer uncomfortable.
This article describes a penetration test conducted under formal engagement with full written authorisation from the client. All identifying details have been altered or omitted to preserve client confidentiality. Backup data was accessed only to the extent necessary to confirm the finding — no production data was exfiltrated or copied beyond the assessment environment. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990 and equivalent legislation worldwide. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security tests the infrastructure that protects your data — backup servers, appliances, tape libraries, and cloud repositories. We assess firmware currency, credential management, network isolation, encryption posture, and the exploitability of known vulnerabilities in backup software. If your backup infrastructure has not been penetration tested, it is the most valuable untested asset in your environment.