Ransomware operators go after Veeam Backup and Replication because one backup server holds both the last line of recovery and a store of credentials for almost every hypervisor, host and repository in the estate. CISA's Known Exploited Vulnerabilities catalog lists four Veeam Backup and Replication flaws, and all four are marked as known to be used in ransomware campaigns. This guide covers how access works in Veeam Backup and Replication (VBR), the roles and approvals that protect destructive operations, the service accounts and stored credentials the server depends on, what to log, and a hardening baseline built on Veeam's own Security and Compliance Analyzer. It is written for backup engineers, infrastructure teams and the security staff who review them. For the identity separation model behind backup systems in general, read the Backup Identity Isolation Guide first; this page goes into the product itself.
Key takeaways
- The credential store is the prize. VBR keeps credentials for vCenter, Hyper-V, Linux servers and repositories in its configuration database, and CVE-2023-27532 let an unauthenticated network user obtain them over TCP 9401.
- Patch speed is a control, not housekeeping. All four Veeam entries in the CISA KEV catalog are flagged for ransomware use, so treat VBR updates like edge device patches.
- Keep the backup server out of the production domain. The analyzer checks this explicitly, because a domain compromise otherwise becomes a backup compromise.
- Immutability must be real. A hardened Linux repository on physical hardware, with SSH disabled, or object storage in Compliance mode, survives a stolen admin account; S3 Object Lock in Governance mode does not.
- MFA plus four-eyes authorisation stops a single stolen login from deleting backups, removing repositories or changing users, provided you have two administrators in each role.
How identity and access work in Veeam Backup and Replication
VBR has three distinct identity layers, and attackers abuse all three. Hardening one while ignoring the others leaves the server exposed.
| Layer | What it is | Why it matters |
|---|---|---|
| Console and Web UI users | Windows or domain accounts (or groups) assigned a Veeam role under Users and Roles; console traffic to the backup service, by default on TCP 9392 | Whoever holds Veeam Backup Administrator can delete restore points and change retention |
| Service identity | The account the Veeam services run under on the backup server; the analyzer recommends LocalSystem | A domain service account here ties the backup server to the domain you are trying to survive |
| Stored credentials | Credentials Manager entries for hypervisors, guest processing, Linux servers, repositories, cloud and object storage | Encrypted in the configuration database, but readable by the product, and therefore a target (CVE-2023-27532) |
| Encryption passwords | Passwords for job encryption and for the configuration backup | Lose them and encrypted backups cannot be restored; leak them and an attacker can read copied backup files |
The configuration backup deserves special attention. It contains the configuration database, including stored credentials, which is why the analyzer requires it to be enabled, encrypted and stored somewhere other than the backup server itself.
Admin roles and privileged access
VBR ships with built-in roles: Veeam Backup Administrator, Veeam Backup Operator, Veeam Restore Operator, Veeam Backup Viewer and Veeam Tape Operator, and the Veeam Security Administrator role used by four-eyes authorisation. Assign roles to dedicated groups that exist only for backup administration, not to general IT administrator groups.
Multi-factor authentication
Enabling MFA for backup console users is one of the analyzer's product checks. VBR uses time-based one-time passwords from an authenticator app. Exclude only service accounts that the console logic requires, and record each exclusion. Pair MFA with automatic logoff for idle console sessions.
Four-eyes authorisation
Enabled under Users and Roles, Authorization, with the option "Require additional approval for sensitive operations". Once on, a second administrator must approve:
- Destructive data operations: deleting backup files or snapshots from disk or from the configuration, and removing backup repositories or storage.
- Identity changes: adding, modifying or deleting users and groups, enabling or disabling MFA, resetting a user's MFA and changing automatic logoff settings.
- Cloud Connect operations: such as removing cloud repositories or imported backups.
Veeam's community guidance says you need at least two users with the Veeam Backup Administrator role and two with the Veeam Security Administrator role, otherwise you risk locking yourself out. Requests expire after an approval window of 1 to 30 days. Note one reported side effect: four-eyes can block overwriting files in file copy jobs, so test any job that rewrites the same files before enabling it in production.
Where administrators sign in from
The analyzer recommends disabling Remote Desktop Services, Remote Registry and WinRM on the backup server. Administer through the console installed on a hardened admin workstation instead of RDP to the server. See the Privileged Access Workstations Guide. Keep a documented, sealed break-glass account for the case where MFA or the approvers are unavailable. See the Break-Glass Account Guide.
Integrations, API tokens and service accounts
Every infrastructure connection VBR makes is a non-human identity. Inventory them from Credentials Manager and apply least privilege to each.
| Connection | Typical credential | Hardening |
|---|---|---|
| vCenter or ESXi | vSphere account | Dedicated account with a custom vCenter role holding only the privileges Veeam documents, never a vSphere administrator |
| Hyper-V hosts | Windows account with local admin on hosts | Dedicated account, not a domain admin; restrict where it can log on |
| Guest processing | Account inside VMs for application-aware processing | Per application tier accounts; avoid one account that is admin on every VM |
| Linux servers and proxies | SSH key or password | Analyzer: disable password authentication on Linux servers and do not trust unknown Linux servers automatically |
| Hardened repository | Single-use credentials used only to deploy the Veeam components | Not stored by VBR; repository account without sudo after deployment; SSH disabled |
| Object storage | Access key and secret, or cloud identity | Bucket-scoped keys with no delete-bucket or Object Lock bypass rights; Compliance mode retention |
| REST API and automation | OAuth tokens issued to an API user | Separate low-role API users per integration; log and review their activity |
- Rotate: the analyzer expects credentials and encryption passwords to be changed at least annually. Rotate immediately after any suspected compromise or a vulnerability like CVE-2023-27532, because a patched server does not invalidate credentials already taken.
- Protect encryption passwords: keep them in an enterprise vault outside the backup estate, and enable password loss protection so a lost password is not the same as lost data. See the Secrets Management Guide.
- Check strength: the analyzer also checks backup encryption password length and complexity.
Logging and detection
Attackers who reach VBR typically try to read stored credentials, add their own user, disable jobs or shorten retention, then delete restore points before encrypting production (MITRE ATT&CK T1490 Inhibit System Recovery and T1485 Data Destruction). Detection should focus on those moments.
| Signal | Where it appears | Why |
|---|---|---|
| New Veeam user, role change, MFA reset | VBR events in the Windows event log (Veeam Backup channel) or syslog forwarding | Attacker persistence and approval bypass attempts |
| Backup or repository deletion, retention change | VBR events; four-eyes request history | Direct precursor to ransomware deployment |
| Jobs disabled or failing across many workloads | Job session history, email notifications | Quiet sabotage before impact |
| Connections to TCP 9401 or the console port from unexpected hosts | Host firewall and network flow logs | Exploitation of the backup service |
| New local Windows accounts on the backup server | Windows Security log, event ID 4720 | Seen after exploitation of backup servers |
| Malware detection events and suspicious file activity | VBR malware detection (inline and guest index scanning), YARA scans | Early warning that production data is being encrypted |
Forward these events off the backup server to the SIEM, since an attacker on the server can clear local logs. See the SIEM Guide. Enable email notifications as well: it is an analyzer check and it gives you an out-of-band signal.
Metrics that show the hardening holds
- Analyzer pass rate: share of Security and Compliance Analyzer checks passed, with every suppression justified in a note.
- Patch latency: days from a Veeam security bulletin to deployment on all backup servers.
- Immutable coverage: percentage of protected workloads with at least one restore point in immutable or offline storage.
- Credential age: oldest stored credential and encryption password in days.
- Approval exceptions: number of sensitive operations run without four-eyes in a quarter (target zero).
- Restore success: share of scheduled test restores that completed within the recovery time objective.
Hardening baseline
Veeam built its baseline into the product. The Security and Compliance Analyzer runs from the Home tab (Security & Compliance on the ribbon) in the desktop console; the Web UI only shows results. It has two groups of checks.
| Group | Checks (as listed by Veeam) |
|---|---|
| Backup server OS | Disable Remote Desktop Services, Remote Registry, WinRM, Web Proxy Auto-Discovery, Windows Script Host, SMBv1, LLMNR, NetBIOS on all interfaces, WDigest credential caching and deprecated SSL and TLS; enable Windows Firewall and SMBv3 signing and encryption; run LSASS as a protected process |
| Identity and access | MFA for the console; backup server not in the production domain; services under LocalSystem; credentials and encryption passwords rotated at least annually; password loss protection |
| Repositories | Use immutable or air-gapped media; do not host hardened repositories in VMs; disable SSH on hardened repositories; do not use hardened repositories as proxies; S3 Object Lock Governance mode is not true immutability |
| Data protection | At least one backup copy (3-2-1); encrypt jobs to cloud repositories; encryption password strength; avoid reverse incremental |
| Configuration | Configuration backup enabled, encrypted and not stored on the backup server; network traffic encryption, including host-to-proxy traffic in Network transport mode; PostgreSQL recommended settings; latest product updates installed |
Rolling it out
- Baseline: run the analyzer and export the results. Record every "Not implemented" item with an owner.
- Patch first: bring VBR, proxies, agents and Veeam ONE to the current supported build. Check the Veeam security bulletins, for example KB4649 for CVE-2024-40711 (fixed in 12.2, build 12.2.0.334).
- Rotate: after patching, rotate every stored credential and the configuration backup password, assuming earlier exposure.
- Isolate identity: move the backup server to a workgroup or a separate management domain, enable MFA, then four-eyes once two approvers exist in each role.
- Apply OS hardening in a pilot: Veeam's KB4525 PowerShell script applies outstanding analyzer items, but it has no undo option and can disable RDP, WinRM and old protocols other tools rely on. Suppress items you have decided not to apply, run it on one server, test jobs and restores, then extend.
- Add real immutability: deploy a hardened repository on a physical server with single-use credentials and SSH disabled, or object storage with Compliance mode retention.
- Test recovery: restore from the immutable copy into an isolated network, including a configuration restore onto a rebuilt server. See the Restore Testing and Recovery Assurance Guide.
Rollback: each OS change made by the script must be reversed by hand, so record the prior value of every service and registry setting before applying. Keep the console reachable through a second admin workstation while you test.
Decision guidance
- Hardened repository or object storage: a hardened Linux repository gives fast local restores and immutability you control; Compliance mode object storage gives off-site immutability. Large estates usually need both; a small organisation with one site gets most value from an off-site Compliance mode copy first.
- Workgroup or management domain: a workgroup server is simplest for one or two backup servers. Larger estates with many proxies benefit from a dedicated management forest with no trust to production.
- All-in-one or distributed: an all-in-one server reduces the attack surface (Veeam's CVE-2023-27532 workaround of blocking external TCP 9401 only works there), while distributed proxies need tighter firewalling between components.
Common misconfigurations
- Domain-joined backup server using domain admin credentials. One stolen domain admin then owns production and recovery together, and every hypervisor credential in Credentials Manager goes with it.
- Unpatched backup server on a flat network. CVE-2023-27532 needed only network reach to TCP 9401 to obtain stored credentials, and CVE-2024-40711 (CVSS 9.8) allowed remote code execution on unpatched v12 builds.
- Configuration backup on the backup server, unencrypted. It holds the credential store, and it is lost with the server.
- "Immutable" storage that an admin can unlock. Governance mode object lock, a hardened repository running as a VM, or one with SSH left enabled can all be undone by an attacker with the right account.
- Backups and their keys stored together. The GoTo breach shows that encrypted backups offer no protection when the encryption key is taken with them.
- Four-eyes enabled with one approver. This either locks the team out or leads to it being switched off.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Other |
|---|---|---|---|
| Protected, tested backups | PR.DS-11, RC.RP-03 | CP-9, CP-9(8), CP-10 | CIS Controls v8.1 Control 11; ISO/IEC 27001:2022 A.8.13 |
| Admin MFA and least privilege | PR.AA-05 | IA-2, AC-6, AC-2 | ATT&CK T1078 Valid Accounts |
| Stored credentials and keys | PR.AA-05 | IA-5, SC-12, SC-28 | ATT&CK T1555 Credentials from Password Stores |
| Patching | ID.RA-01 | SI-2 | ATT&CK T1190 Exploit Public-Facing Application |
| Configuration baseline | PR.PS-01 | CM-6 | Security and Compliance Analyzer |
| Monitoring | DE.CM-09 | AU-6 | ATT&CK T1490, T1485 |
Practitioner checklist
- Run the Security and Compliance Analyzer monthly and after every upgrade; justify every suppression.
- Apply Veeam security updates within your edge device patch window and rotate stored credentials afterwards.
- Remove the backup server from the production domain and run Veeam services under LocalSystem.
- Enable MFA for all console users and four-eyes authorisation with two approvers per role.
- Replace broad hypervisor and guest accounts with dedicated least-privilege accounts per connection.
- Keep at least one copy in a physical hardened repository with SSH disabled or in Compliance mode object storage.
- Encrypt the configuration backup, store it off the server and keep its password in a vault outside the backup estate.
- Block TCP 9401 and the console port from everything except named management hosts.
- Forward VBR and Windows security events to the SIEM and alert on user, role, retention and deletion changes.
- Test a full restore, including a configuration restore to a rebuilt server, at least twice a year.
Standards and references
- Veeam: Security and Compliance Analyzer
- Veeam: Hardened Repository
- Veeam: KB4525 Security and Compliance Analyzer remediation script
- Veeam: KB4424 CVE-2023-27532
- Veeam: KB4649 Security bulletin including CVE-2024-40711
- CISA: Known Exploited Vulnerabilities Catalog
- Veeam Community: Four-Eyes Authorization in v12.3
- MITRE ATT&CK: Inhibit System Recovery
Related NHI Mgmt Group resources: Backup Identity Isolation Guide · Backup Security and Immutable Backup Guide · T1490 Inhibit System Recovery Defensive Guide · Ransomware Prevention Guide