PatchDay Alert
Analysis · 4 min read · 703 words By The Commentary Desk · Commentary

Ransomware crews keep hitting Veeam for the same two reasons

Four Veeam Backup & Replication CVEs feed the same playbook. Attackers target the backup server because it can destroy your recovery option and because it holds the credentials to everything it backs up. CVE-2024-40711 took Akira and Fog from access to ransomware fast.

Ransomware crews keep hitting Veeam for the same two reasons

Veeam Backup & Replication is the most widely deployed enterprise backup product, and that popularity, combined with what a backup server inherently is, makes it a standing ransomware target. Four of its vulnerabilities sit in the Known Exploited Vulnerabilities catalog, CVE-2024-40711, CVE-2023-27532, CVE-2022-26500, and CVE-2022-26501, and they feed the same playbook for the same two reasons a backup server is irresistible: compromising it can destroy your ability to recover, and it holds the credentials to nearly everything it backs up.

The cluster

  • CVE-2022-26500 / CVE-2022-26501 (unauth RCE). Disclosed March 2022, these let an unauthenticated attacker execute code on the Backup & Replication server via an internal API. CISA flagged active exploitation.
  • CVE-2023-27532 (credential leak). A missing-authentication flaw that let an unauthenticated attacker within the backup network obtain the encrypted credentials stored in Veeam’s configuration database, which is to say, the credentials Veeam uses to reach the hosts it backs up. Recover those and you have access across the estate. Ransomware crews including FIN7/Cuba leaned on it.
  • CVE-2024-40711 (deserialization, unauth RCE, CVSS 9.8). A 2024 deserialization bug yielding unauthenticated remote code execution. Akira and Fog ransomware operators adopted it quickly, using compromised Veeam servers as a step toward fleet-wide encryption.

CISA’s #StopRansomware: Akira advisory lists Veeam CVEs among the bugs Akira exploits. The throughline is that the backup server is not a back-office afterthought to these crews; it’s a primary objective.

Why the backup server is the prize

This is the same logic as the R1Soft backup-server compromise, and it bears repeating because backup infrastructure is so consistently under-defended relative to its value:

  • It removes your leverage. Ransomware economics turn on whether the victim can restore. If the attacker can encrypt, delete, or corrupt the backups first, paying becomes the only option. Compromising Veeam lets them do exactly that.
  • It’s a credential trove. A backup product must authenticate to everything it protects, so its configuration database holds service-account credentials reaching across the environment. CVE-2023-27532 made that explicit, the bug literally leaks those stored credentials. Owning the backup server is often a shortcut to owning the domain.
  • It’s frequently reachable and over-trusted. Backup servers tend to have broad network access by design and weaker monitoring than the systems they protect, because they’re “just infrastructure.”

What to do

  • Patch Veeam Backup & Replication to current, covering all four CVEs and beyond. Treat Veeam updates as high-priority; ransomware crews adopt these bugs within weeks.
  • Make backups resilient to the backup server being compromised. This is the load-bearing control: keep immutable and/or air-gapped backup copies (offline, object-lock, or a separate hardened repository) so an attacker who owns the Veeam server still can’t destroy your ability to recover. Test restores from those copies regularly.
  • Treat the backup infrastructure as tier-zero. Segment it tightly, restrict who and what can reach the Veeam server and its ports, run its service accounts with the minimum rights needed, and monitor it as closely as a domain controller.
  • Rotate credentials if you ran an exposed, unpatched server, especially given CVE-2023-27532’s credential-leak nature. Assume the stored credentials were taken and reset them across the systems Veeam could reach.
  • Watch the backup server’s own behavior. The Veeam process spawning shells, unexpected access to the configuration database, and backup-deletion or repository changes you didn’t initiate are high-fidelity signals of an attack in progress.

The reframe is to recognize that backup is where ransomware is won or lost, and to defend it accordingly. The attackers have already decided your Veeam server is a primary target, and they’ve told you so by building these CVEs into the Akira and Fog playbooks. Patch it like the crown jewel it is, keep recovery copies an attacker can’t reach even from inside the backup server, and scope its credentials down. We track the backup-software entries with particular weight, because a compromise there is the one that takes away your choice when the ransom note lands.

Sources

Share

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.