Backup And Hypervisor Administrative Access
How Backup And Hypervisor Administrative Access works
Backup and hypervisor administrative access is the reach into the two planes that can read or rebuild every system in one move. The backup plane holds a copy of every server, so its service account is often granted domain-wide rights to read them, its console and repository sit on the production network, and the repository share is writable from the hosts it protects. The hypervisor plane owns the disks and memory of every guest, and its management console frequently authenticates against the same directory as the workstations. Snapshot, clone, export and restore operations move whole machines below the guest operating system, so they bypass every control that runs inside it.
The attacker who reaches either plane does not need to compromise hosts one at a time: they read the backups, or clone a domain controller and mount its disk, or restore a machine with a planted account, and every EDR agent, host firewall and local policy is irrelevant because the action happens beneath them. It is easy to miss because both planes are run by trusted teams on trusted networks, and the audit checks that backups complete and guests are healthy, not who can reach the console or how much the service account can do. Whether those repositories and datastores are also unencrypted belongs to the Unencrypted Data At Rest And Backups page, and cloning a domain controller to extract its database is the infrastructure route into the credential attacks the Active Directory section covers.
Backup And Hypervisor Administrative Access in practice
Map the backup and hypervisor service accounts and their rights
Start by resolving the service accounts and reading their group membership, because the rights are the finding whether or not the console is reached. Do this read-only against the directory.
# what the backup service account can do domain-wide
$svc = 'svc-veeam'
Get-ADPrincipalGroupMembership $svc | Select-Object name
Get-ADUser $svc -Properties MemberOf, ServicePrincipalName, LastLogonDate
# high-value memberships that make the backup plane a domain compromise path
'Domain Admins','Enterprise Admins','Backup Operators','Server Operators' | ForEach-Object {
'{0}: {1}' -f $_, ((Get-ADGroupMember $_ -Recursive).SamAccountName -join ', ')
}A backup or hypervisor service account inside Domain Admins, Backup Operators or Server Operators is a domain-wide right that no backup job needs.
Test reachability of the backup console and repository from production
The rights matter only alongside reach. From an ordinary server or user lease, check whether the console and the repository answer, and whether the repository share is writable.
# console and repository ports from a production vantage
nmap -sS -Pn -n --open -p 22,111,445,2049,9392,9401,10000 \
10.10.30.0/24 -oN /tmp/isr09-backup.txt
# is the backup repository share writable from a host it is meant to protect?
smbclient //backup01.lab.internal/Repository -U 'testuser%<PASSWORD>' \
-c 'put /tmp/write-test.txt _isr09_writetest.txt; del _isr09_writetest.txt'A repository that is both reachable and writable from production means ransomware or a rogue admin can delete the backups before touching the primaries.
Check whether the hypervisor uses the production identity provider
A hypervisor console that authenticates against the production directory shares its blast radius with every user. Read the configured identity source, do not attempt a login.
# vCenter identity source, read from the console or via govc read-only
# GOVC_URL / GOVC_USERNAME / GOVC_PASSWORD point at the lab vCenter
identity_sources:
- type: ActiveDirectory
domain: corp.lab.internal # FINDING if this is the production domain
default: true
- type: LocalOS
domain: vsphere.local # break-glass local admin, expected
# same question for a standalone ESXi host
host_auth:
join_domain: corp.lab.internal # FINDING: host management rides prod AD
lockdown_mode: disabled # note separatelyA production-domain identity source on the hypervisor means one directory compromise reaches every virtual machine at once.
Establish the snapshot and restore bypass without using it
The real-world action - clone a domain controller, mount its disk, or restore a machine with a planted account - is destructive to evidence and to trust. Prove the capability exists by reading the privilege, and describe the path rather than executing it.
capability check (read-only), source: 10.10.30.40 (production server VLAN)
plane who can act operation available verdict
----------- ------------------------------- ---------------------- ----------------------------
hypervisor svc-vc-backup (prod DA member) clone / export guest FINDING: DC disk exfil path
hypervisor any prod-domain admin login snapshot / mount VMDK FINDING: below-OS access
backup svc-veeam (Backup Operators) restore to alt host FINDING: plant-account path
backup Repository share writable delete restore points FINDING: recovery can be lost
Do not clone the domain controller or mount its VMDK on this engagement:
that copies NTDS.dit and burns every credential in the domain. The
readable privilege plus the available operation is the finding; extraction
is only run with explicit written authorisation and an isolated handling plan.How to fix and prevent Backup And Hypervisor Administrative Access
- Strip domain-wide rights from the backup and hypervisor service accounts
- Grant the least privilege the backup and virtualisation products actually require, scoped to their own hosts, never Domain Admins or Backup Operators.
- Isolate both planes on a dedicated management network
- Consoles and repositories must not be reachable from the user or general server VLANs, only from a jump path; the segmentation is the Flat Networks And Missing Segmentation page.
- Separate the identities that log in to each plane
- The hypervisor SSO and the backup console should authenticate against a directory or local accounts separate from production, so a workstation credential cannot open them.
- Make the repository immutable and keep an offline copy
- Append-only or hardware-immutable repositories plus an offline or air-gapped copy, so a compromised production host cannot delete the recovery point.
- Partial control: immutability protects the copy, not the console, so the access restrictions above still have to hold.
- Restrict and log clone, snapshot, export and restore
- Require change-ticket approval for these operations and alert on any that is unmatched, because they are the below-OS path that bypasses every host control.
Last updated
