Veeam Backup Server Hardening: Immutable Repository Configuration, Network Segmentation, and Ransomware Protection
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Ransomware operators follow a documented playbook that includes backup destruction before triggering encryption: Conti, BlackMatter, and most other sophisticated ransomware groups have documented procedures for identifying and destroying Veeam backup infrastructure specifically because Veeam is ubiquitous in enterprise environments. The attack chain against Veeam is straightforward — lateral movement to the Veeam server using stolen domain credentials, deletion of backup jobs and repository data, then triggering the encryption payload with no recovery path.
The hardening measures that break this attack chain are not complex, but they require proactive implementation before the incident. Linux Hardened Repository with immutability, network segmentation that prevents lateral movement to the backup VLAN, service account privilege restriction, and an offline copy that ransomware cannot reach over the network are the four controls that determine whether a ransomware incident results in recovery or ransom payment.
Priority hardening: the controls that matter most
The two highest-impact changes for Veeam ransomware hardening are replacing Windows SMB repositories with Linux Hardened Repository and establishing an offsite immutable copy that ransomware cannot reach from the production network. Windows SMB shares expose backup data to any domain account with network access, which is exactly the credential class ransomware operators acquire during lateral movement. The Linux Hardened Repository breaks this attack path: the Veeam service account does not hold root privileges on the hardened repository server, so XFS immutability attributes applied to backup files cannot be removed even by a fully compromised Veeam server. AWS S3 with Object Lock in Compliance mode adds a second layer that survives domain administrator credential compromise entirely, because Compliance-mode locked objects cannot be deleted before the retention period expires even by the bucket owner. Practitioners should implement both controls in parallel rather than sequentially, since either one in isolation still leaves a gap the other closes.
Replace Windows SMB repository with Linux Hardened Repository as the first priority
If the primary Veeam backup repository is a Windows SMB share, migrating to a Linux Hardened Repository with immutability enabled is the highest-impact single change for ransomware protection. Windows SMB repositories are reachable over the network by any domain account that has SMB access, and ransomware operators specifically target CIFS backup shares for deletion. The Linux Hardened Repository uses XFS immutability attributes that prevent file deletion even by the Veeam service account, and requires no Windows network share that can be enumerated and deleted remotely. The migration path: provision a Linux server with XFS-formatted storage, add it as a Veeam managed server with a non-root account, add the Hardened Repository with immutability enabled, create a Backup Copy job that copies existing backups to the hardened repository, then change primary jobs to write to the hardened repository directly.
Configure AWS S3 Object Lock as the offsite immutable copy even for primarily on-premises environments
AWS S3 with Object Lock in Compliance mode provides an offsite immutable backup copy that is not reachable from the on-premises network during a ransomware incident, even if the attacker has domain administrator credentials. Compliance mode Object Lock prevents object deletion or retention period reduction even by the bucket owner — the AWS root account cannot delete Compliance-mode locked objects. Configure a Backup Copy job in Veeam that copies critical system backups (domain controllers, SQL servers, file servers) to an S3 Object Lock bucket daily with a 30-day retention period. The S3 access key used by Veeam should be an IAM user with permissions scoped to only that specific S3 bucket with PutObject and GetObject but not DeleteObject or s3:BypassGovernanceRetention.
Operational: backup monitoring and recovery testing
Hardening Veeam infrastructure is a one-time project; maintaining backup integrity requires ongoing operational discipline. Daily monitoring of backup job success rates and repository health catches problems before a ransomware incident reveals them, but the alerting channel matters as much as the alert itself — if notifications go only to the production email server, a ransomware actor who has compromised that server can suppress the alerts. Practitioners should route Veeam alerts to an out-of-band channel and monitor repository capacity trends for unexpected data reduction, which is an early indicator of backup deletion. Quarterly recovery drills that include domain controller restoration address the most critical gap in most backup programs: teams that have never practiced AD recovery from Veeam under time pressure take significantly longer during an actual incident, and domain controllers must be restored before any domain-joined server can authenticate and function.
Monitor backup job success and repository health daily with alerting to a separate notification channel
Configure Veeam email notifications for backup job failures and repository warnings to a distribution list that includes backup administrators and the security team. Critically, send Veeam alerts to a channel that does not depend on the production email server (which may also be compromised during a ransomware incident) — use an out-of-band email relay or a messaging platform like Slack or Teams with a dedicated backup-monitoring channel. Monitor backup repository capacity trends to detect unusual deletion patterns: a sudden decrease in used repository space (unexpected data reduction) or the absence of daily incremental backup growth may indicate that backup data has been deleted. Review the Veeam session log for deletion events daily using the Reports, Backup Infrastructure report.
Conduct quarterly ransomware recovery drills including domain controller restoration
Conduct a quarterly recovery test that specifically includes domain controller restoration from backup, which is the most complex and time-critical recovery step in a ransomware incident: domain controllers must be restored before domain-joined servers can authenticate and function. The quarterly drill should restore at least one domain controller from the most recent backup to an isolated test environment, confirm Active Directory replication and SYSVOL function correctly, then restore one critical application server and confirm it can authenticate to the restored domain. Document the actual elapsed time for each step, compare against the documented RTO, and identify the steps where the recovery is slower than expected. Ransomware incidents are not the time to learn that domain controller recovery from Veeam requires steps the team has never practiced.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Veeam backup hardening for ransomware protection requires four parallel actions: migrate Windows SMB repositories to Linux Hardened Repository with immutability enabled, configure AWS S3 Object Lock as the offsite immutable copy that ransomware cannot reach from the production network, restrict the Veeam service account to minimum required privileges and remove domain administrator membership, and isolate the backup network on a dedicated VLAN with firewall rules permitting only Veeam communication ports from protected hosts. Quarterly recovery tests that include domain controller restoration confirm that the backup is recoverable before the incident, not during it — the difference between a 4-hour recovery and a 3-week recovery (or a ransom payment) is whether the team has practiced the procedure.
Frequently asked questions
How do I configure a Veeam Linux Hardened Repository for immutable backups?
The Veeam Linux Hardened Repository requires a dedicated Linux server running a supported distribution (Ubuntu 22.04 LTS or RHEL 8/9), with the XFS filesystem on the backup storage volume (immutability requires XFS), and a non-root local user account for the Veeam connection. In Veeam Backup and Replication, add the Linux server as a managed server using the non-root account via SSH. When adding the repository, select Linux Repository and enable the Make recent backups immutable for checkbox with your desired immutability period (14-30 days is common for protecting recent backups while allowing expired backup deletion). Critically: do not add this Linux server's account to sudo or give it root access after the hardened repository is configured — the entire security model depends on the Veeam service account not having root privileges on the hardened repository server, which prevents even a compromised Veeam server from removing the immutability flag.
How should I segment the backup network to protect Veeam from ransomware?
Create a dedicated backup VLAN that the Veeam backup server communicates over, separate from production workstation and server VLANs. Configure the Veeam server with two NICs: one in the backup VLAN for backup data transfer to repositories and communication with protected hosts, and optionally one in a restricted management VLAN for administrative access. Configure firewall rules permitting Veeam communication ports only: TCP 9392 from Veeam Enterprise Manager to Veeam server, TCP 2500-5000 (Veeam data channel) from Veeam server to protected hosts and repositories, TCP 443 for cloud gateway. Deny all traffic from workstation subnets, internet-facing networks, and any network segment reachable from a ransomware infection to the Veeam backup VLAN. The backup network should be reachable only from the Veeam server and from the hardened repository server — no lateral access from the general network.
What are the minimum required service account permissions for Veeam?
Veeam backup requires different permissions for different infrastructure components. For VMware vCenter: create a dedicated vCenter role with permissions for VM snapshot creation and deletion, datastore browsing and file operations, and network configuration reads — do not use Administrator. For Windows servers: use a local account in the Backup Operators group rather than a domain account to limit the credential's scope to that specific server. For the Veeam Backup and Replication service itself: use a domain account with the minimum required SQL Server permissions for the Veeam configuration database (db_owner on the VeeamBackup database) and local Administrator rights on the Veeam server only. Never use the same service account for Veeam that is used for other infrastructure functions — the credential isolation ensures that a Veeam service account compromise does not provide access to systems beyond the backup infrastructure.
How do I configure an air-gapped or offsite immutable backup copy in Veeam?
Configure an offsite immutable backup copy using one of two approaches: AWS S3 with Object Lock (WORM) for cloud-based immutability, or a physical media rotation (tape or external disk) for air-gapped offline storage. For AWS S3 Object Lock: create an S3 bucket with Object Lock enabled in Compliance mode with a retention period of 30 days, add the S3 bucket as a Veeam object storage repository, and configure a Backup Copy job that copies backups to the S3 repository. With Compliance mode Object Lock, even the AWS root account cannot delete locked objects before the retention period expires. For tape or external disk: configure a Backup Copy job to an external USB disk or tape library, then physically disconnect the storage after the copy completes — the physically disconnected media cannot be reached by ransomware over the network regardless of domain credential compromise.
How do I harden the Veeam Backup and Replication server itself?
Harden the Veeam server by making it a single-purpose server: remove all software not required for Veeam operation, do not install antivirus agents that connect to a cloud management console (use Windows Defender locally), and do not join it to the production Active Directory domain if possible (use a workgroup server and manage it with a local administrator account, or place it in a separate hardened AD that does not trust the production domain). Enable Veeam configuration database encryption in Configuration Backup settings to protect credentials stored in the Veeam database. Enable Windows Defender Application Control or AppLocker to restrict code execution to signed Veeam and system binaries. Restrict RDP access to the Veeam server to only IT administrator workstations or the jump server IP, using Windows Firewall rules. Keep the Veeam server fully patched and enable Windows Update with automatic patch installation.
How do I test backup recovery to validate ransomware resilience?
Test backup recovery quarterly using Veeam's SureBackup and SureReplica features which restore VMs to an isolated network sandbox and run application-level tests automatically to confirm the backup is consistent and the recovered VM boots and responds correctly. For each critical system (domain controllers, SQL servers, file servers), configure a SureBackup verification job that restores the VM to an isolated vSphere network, confirms the VM powers on and passes the heartbeat test, and sends a verification report to the backup administrator. Beyond SureBackup, conduct a full manual recovery test at least annually: restore a specific system from the most recent backup to a test environment, confirm all application functionality works correctly, and document the actual recovery time achieved versus the RTO. Ransomware tabletop exercises should include the backup recovery scenario to confirm that the team knows the recovery procedure and that the procedure works.
What Veeam configuration settings should I audit for ransomware exposure?
Audit these Veeam settings specifically for ransomware exposure: check whether any repository is on a Windows SMB share — SMB shares are accessible over the network and can be encrypted by ransomware; migrate to Linux Hardened Repository or object storage with immutability instead. Check whether the Veeam service account is a domain administrator — if yes, create a least-privilege account. Check whether immutability is enabled on the primary backup repository (Veeam Hardened Repository or S3 Object Lock) and what the immutability period is — immutability periods shorter than the ransomware dwell time in your environment (often 14-30 days from initial access to encryption) leave a window where backups can be deleted before encryption. Check whether any backup copy job sends copies to an offsite location. Check the Veeam Backup and Replication server's network connectivity — if it can reach workstation subnets, the backup server can be reached by lateral movement from a compromised workstation.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.