SafePay Ransomware Advisory: Attackers Hit Veeam Servers and Factory-Reset NAS Backups

On 20 October 2026 the FBI, CISA, the US Secret Service and police agencies in Germany and the UK published joint advisory AA26-293A on SafePay ransomware. The advisory says SafePay "was among the most active ransomware groups in 2026" and has hit "at least 600 separate victims" since August 2024. Much of it reads like every other ransomware advisory: stolen VPN passwords, PsExec, RClone. Two details are different, and they matter to anyone running a small server room.

Two of the five CVEs SafePay exploits are in Veeam Backup & Replication, the backup server itself. And before encrypting, the group halts the Volume Shadow Copy Service and resets the NAS holding victim backups "to initial factory settings." Take the backups away first, then encrypt. If your recovery plan is Veeam writing to a NAS in the next rack, with both joined to the same network and reachable by the same admins, this advisory describes how that plan fails. Below: what SafePay does, how to check your exposure, and a backup layout that still works when the attacker owns both the backup server and the NAS.

What the advisory says SafePay does

Getting in. The authoring agencies saw credential exposure, password brute forcing and VPN access. Using phished accounts and IP addresses of the Mullvad VPN service, the actors exploit two Cisco ASA and Firepower bugs: CVE-2020-3259, a memory disclosure in the web services interface, and CVE-2023-20269, which helps brute force remote access VPN logins. Automated scripts also go after three internet-facing bugs: CVE-2023-27532 and CVE-2024-40711 in Veeam, and CVE-2024-40766 in SonicWall SonicOS.

Once inside, they take over or create admin accounts and move with built-in tools: PsExec, WinRM, RDP and remote management software. They map file shares with ShareFinder.ps1 and SharpShares.exe, pull credentials with Mimikatz and a dcsync.exe tool, disable security software and sometimes change user passwords so nobody can log in. Data is packed with 7-Zip or WinRAR and shipped out with RClone, WinSCP, FileZilla, OneDrive or Backblaze's b2.exe. AnyDesk, TeamViewer and ScreenConnect show up as well.

Then the impact phase. Files are encrypted with ChaCha20 plus RSA and get a .SafePay extension. A ransom note lands on the desktop or the root directory and points to a Tor chat portal. The advisory adds that a SafePay representative phones the victim to push for payment, stolen data goes to a leak site if nobody pays, and the ransomware may delete itself afterwards.

Why the Veeam CVEs are the real story

A backup server holds the keys to everything it backs up. Veeam's own KB4424 says CVE-2023-27532 lets "an unauthenticated user operating within the backup infrastructure network perimeter" obtain encrypted credentials from the configuration database, which "may lead to an attacker gaining access to the backup infrastructure hosts." The vulnerable process is Veeam.Backup.Service.exe on TCP 9401. Fixed builds are 12.0.0.1420 P20230223 and 11.0.1.1261 P20230227. CISA put it in the Known Exploited Vulnerabilities catalog on 22 August 2023.

CVE-2024-40711 is worse. Veeam's September 2024 bulletin (KB4649) rates it critical, CVSS 9.8, describes it as unauthenticated remote code execution, and says it affects build 12.1.2.172 and all earlier version 12 builds. It was fixed in 12.2.0.334. CISA listed it as exploited on 17 October 2024.

Both patches are years old. A group that runs automated scripts against them in 2026 is doing it because they still find targets. In our experience the backup server is the box nobody wants to touch, because "it works" and an upgrade might break the job chain. That is exactly the habit this advisory punishes.

Step 1: check your Veeam server

Get the installed version from the service binary that KB4424 names. Run this in PowerShell on the backup server:

(Get-Item "C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.exe").VersionInfo.FileVersion

Compare the result with Veeam's build numbers list (KB2680). Anything below 12.2.0.334 is open to CVE-2024-40711. Version 11 and older are out of support, and KB4649 says unsupported versions "are likely affected and should be considered vulnerable." KB2680 lists 13.1.2 (build 13.1.2.57, 27 October 2026) as the newest v13 release and 12.3.2.4934 (29 September 2026) for the 12.3 branch. Move to the newest build of a supported branch, not just past the two CVEs above.

Next, check who can reach port 9401. From an ordinary office PC, not an admin workstation, run:

Test-NetConnection -ComputerName veeam01 -Port 9401

If TcpTestSucceeded comes back True, a user laptop can talk to your backup service. Fix that with firewall rules or a separate backup VLAN. For all-in-one installs with no remote components, KB4424 itself suggests blocking external connections to TCP 9401 as a temporary measure until the patch is installed. The backup server should never be reachable from the internet at all.

Step 2: check the edge devices

For Cisco ASA or FTD, look up your release in the two Cisco advisories linked above. Cisco notes that CVE-2023-20269 does not bypass authentication, and that a VPN session still needs "a valid second factor if multi-factor authentication (MFA) is configured." So MFA on the VPN is the cheap fix that blunts the brute forcing. For SonicWall, NVD says CVE-2024-40766 affects Gen 5 and Gen 6 firewalls and Gen 7 devices on SonicOS 7.0.1-5035 and older. It has been on CISA's exploited list since 9 September 2024.

Patching the firewall does not undo stolen passwords. Since SafePay logs in with phished and exposed credentials, reset VPN passwords and revoke old sessions after you patch. We covered the same logic for Citrix NetScaler: rotate secrets after patching, and how those credentials get phished in the first place in our AiTM phishing piece.

Step 3: look for the advisory's indicators

The advisory ships hashes, filenames, IP addresses and STIX files. A quick first pass on Windows servers, using SHA-256 values copied from the advisory:

$bad = @(
 '327b8b61eb446cc4f710771e44484f62b804ae3d262b57a56575053e2df67917',
 'a0dc80a37eb7e2716c02a94adc8df9baedec192a77bde31669faed228d9ff526',
 '921df888aaabcd828a3723f4c9f5fe8b8379c6b7067d16b2ea10152300417eae'
)
Get-ChildItem C:\Users,C:\ProgramData,C:\Windows\Temp -Recurse -File -Include *.exe,*.dll -ErrorAction SilentlyContinue |
 Get-FileHash -Algorithm SHA256 | Where-Object { $bad -contains $_.Hash }

Then search by name for the tools the advisory lists:

Get-ChildItem C:\ -Recurse -File -ErrorAction SilentlyContinue -Include b2.exe,nxc.exe,sharefinder.ps1,SharpShares.exe,locker.dll,dcsync.exe,netscan.exe |
 Select-Object FullName, LastWriteTime

A hit on netscan.exe or winrar.exe is not proof by itself. The advisory warns that some listed files are legitimate tools and asks you to verify IP addresses before blocking them. Also search VPN, RDP and sign-in logs for the hostnames it lists, such as WIN-SBOE3CPNAL and WIN-3IUUOFVTQAR. Remote access tools that nobody approved deserve a look too; our article on fake installers and RMM tools covers how to keep that list short. On file servers, vssadmin list shadows shows whether shadow copies still exist. If they used to and now don't, find out why.

Step 4: a backup layout SafePay can't reset

The NAS reset is the detail to design around. If an attacker with domain admin can log into the backup server and the backup storage, they own both, and a reset wipes your history in one click. The old 3-2-1 rule (three copies, two kinds of media, one offsite) is still right, but one of those copies has to be something nobody on your network can delete for a fixed period, including you.

The advisory's own mitigations say the same: "Maintain offline backups of data and regularly test and maintain backup and restoration processes," encrypt backups, make them immutable, and keep copies in a physically separate, segmented location. Three ways to get there:

• Veeam Hardened Repository. A Linux server where, per Veeam's documentation, backup files "cannot be moved, modified or deleted, but can be copied" during the immutability period. It can be added with single-use credentials that are not stored, so "even if the Veeam Backup & Replication server is compromised, the attacker cannot get the credentials."
• S3 Object Lock in compliance mode. AWS says a locked object version "can't be overwritten or deleted by any user, including the root user in your AWS account" (S3 Object Lock docs). Object Lock only works on buckets with versioning turned on.
• A real offline copy. Disks or tapes that are disconnected and stored elsewhere. Slow to restore, but no script reaches them.

Creating a locked bucket with the AWS CLI looks like this (CLI reference):

aws s3api create-bucket --bucket acme-backup-locked --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1 \
  --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration --bucket acme-backup-locked \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Pick a retention window you can pay for. Thirty days is a sensible start for a small company. Compliance mode cannot be shortened, so test with a short window first. AWS also notes the only way to delete a compliance-locked object early is to delete the AWS account, so lock down the root login with MFA and keep it away from daily use.

Keep the NAS, just stop treating it as the safe copy. Put its management interface on a network user PCs can't reach, give it a local admin account that is not in Active Directory, and turn off remote administration you don't use.

Step 5: a restore test you can run this week

1. Pick a server that hurts to lose, such as the file server or the accounting database, not the easiest VM.
2. Restore it from the immutable or offline copy, not the primary, into an isolated network with no route to production.
3. Time it from "start restore" to "a user could log in." That is your real recovery time.
4. Open actual files or run a real query, and note the date of the newest data. That gap is your real data loss.
5. Try to delete a locked backup with the backup service's own credentials. For S3: aws s3api delete-object --bucket acme-backup-locked --key <key> --version-id <id>. AWS documents that a permanent delete of a protected version returns Access Denied. If it succeeds, your lock is misconfigured.
6. Write down what broke: a licence key, DNS, a password only one person knew.

Veeam users can automate steps 2 to 4 with SureBackup, which Veeam describes as technology to "test machines backups and check if you can recover data from them." Run the manual version at least once anyway. Automation won't notice that nobody remembers the domain admin password.

Frequently asked questions

Sources: CISA/FBI advisory AA26-293A, 20 October 2026, Veeam KB4424, Veeam KB4649, Veeam KB2680, NVD CVE-2023-27532, NVD CVE-2024-40711, NVD CVE-2024-40766, Cisco advisories for CVE-2020-3259 and CVE-2023-20269, Veeam Hardened Repository, Amazon S3 Object Lock. Version data checked on 2 November 2026.