Six bodies from three countries published a joint advisory yesterday on the SafePay ransomware group: at least 600 victims since August 2024. Inside the document there is a list of five vulnerabilities these attackers exploit, and that list says something the headline does not: there is no zero-day, no operating system and nothing from 2026. There are three firewalls and two backup servers. The newest door turned two years old a few weeks ago.
Who signs the advisory
The document is AA26-293A, published on 20 October 2026 as part of the #StopRansomware series. It is signed by the FBI, CISA and the US Secret Service alongside the Landeskriminalamt of Rhineland-Palatinate in Germany, and the National Crime Agency and the North West Regional Organised Crime Unit in the United Kingdom. When six bodies from three countries agree to sign the same text, the paperwork takes time; the fact that it is out now means the material has been piling up for months.
The figures: the group has been active since August 2024 and the advisory speaks of at least 600 separate victims, spread across North America, South America, Europe and Australia, in several critical infrastructure sectors. They steal data, encrypt and threaten to publish. And there is an operational detail worth holding on to for the end: after encryption, somebody makes a phone call on the group's behalf.
It is worth reading carefully how the advisory introduces the list, because it changes the order of events: it says these actors use "phished account profiles to access victim networks to exploit the following known CVEs for edge device products". In other words, the five doors are not the first step: they are the step that turns a stolen credential into an encryption event. That does not make them less important, it puts them in their place — and it previews this post's conclusion, which is less about patches than it looks.
The five doors, with dates
This is the advisory's list, ordered by age. The column that matters is the last one.
Three perimeter appliances and the same backup server twice. No Windows, no Linux, no browser, no business application. If your ransomware defence plan amounts to antivirus on every desktop plus the monthly Windows update, none of these five doors is inside your plan.
Three of the five are in the device that lets people in
The three perimeter flaws are not the same thing, and read in order they tell a whole sequence. CVE-2020-3259 lets you read device memory without authenticating; what comes out is credentials and fragments of sessions. CISA added it to its exploited-flaw catalogue in February 2024, tied to another ransomware group. CVE-2023-20269 allows guessing usernames and passwords against the remote-access VPN's default connection profile: it does not get you in on its own, but it makes useful what the previous one pulled out. CVE-2024-40766 is the newest of the three and affects both the management interface and the SSLVPN service across three firewall generations.
And here is what we think is the most expensive lesson of the three, because it is not about patches: the patch closes the hole, it does not close the session. The vendor of the third one published, alongside the fix, an instruction almost nobody carried out — change the passwords of local users with SSLVPN access after upgrading — and a year later had to clarify that the wave of attacks being attributed to it came not from a new flaw but from the use of credentials stolen before the patch, many of them carried over from one appliance generation to the next during a migration. If an information-disclosure vulnerability has been open at your place, what they took does not expire when you update the firmware. It expires when you rotate the credentials.
The other two are in the system that was meant to save you
The backup server showing up twice in a list of five is not a statistical accident, and the pairing is very telling. CVE-2024-40711 is the headline one: insecure deserialisation, code execution with no credentials, scored 9.8. It affects version 12.1.2.172 and every earlier build in the 12 branch, and was fixed in 12.2 (build 12.2.0.334). But the one that explains why they go there is the other, from 2023: CVE-2023-27532 executes nothing; it simply hands over the (encrypted) credentials stored in the configuration database to anyone who can reach the service from the backup infrastructure network. It was fixed in March 2023, in builds 12.0.0.1420 P20230223 and 11.0.1.1261 P20230227.
Put another way: the backup server is, by design, a keyring. To do its job it stores credentials for the hypervisor, the storage, the repository, the domain and half the machines it protects. It is not just another target in the estate: it is the one place where all those keys sit together, with administrative rights. Whoever reaches it does not need to move around the network trying things, because they already have the inventory and the keys. We went into this in more detail at the time: a backup server inside the domain is a circular dependency.
They do not delete the backup: they factory-reset the NAS
This is the detail in the advisory that gave us the most to think about, and one we have barely seen quoted in the coverage. The version we all repeat is "ransomware deletes the backups". What the advisory describes is something else: they halt the Volume Shadow Copy Service and reset NAS devices to initial factory settings.
The difference is not cosmetic. Deleting files leaves traces, takes time and can be interrupted: a mass deletion raises alerts, and on many repositories retention or immutability prevent it outright. A factory reset is a legitimate operation in the appliance's admin panel, takes seconds, and takes the backups, the job configuration, the retention rules and the NAS's own logs with it in a single gesture. You are not restoring from a damaged repository: you are standing in front of a device that has returned to the state it left the box in, and no longer knows it was ever your backup repository.
The design consequence is uncomfortable and it is this post's thesis: a backup that can be destroyed from an admin panel the attacker reaches with valid credentials is not a separate backup. It is the same backup, in a different box. The 3-2-1 rule is not about boxes; it is about one of those copies being out of reach of whoever controls your network: genuinely immutable — with immutability at the repository, not a checkbox on the job — or offline, or somewhere whose panel does not share identities with your domain.
What they use inside was already installed
The advisory's tool inventory is not exotic either: ShareFinder.ps1 and SharpShares.exe to find shares, WinRAR and 7-Zip to package, Rclone and FileZilla to move data out, PsExec and WinRM to execute on other machines, AnyDesk and TeamViewer for remote access, Mimikatz for credentials. Two thirds of that list are installed right now, licensed and for good reason, in most companies we know.
That is why the file is not the signal. The signal is context: AnyDesk showing up on a server where it never was, Rclone talking to a cloud storage account that is not yours, PsExec coming out of a workstation that is not the administrator's, at three in the morning on a Saturday. An allow-list of applications does not answer that; what answers it is something watching behaviour and somebody awake to respond — the part we sell as managed EDR/MDR and, honestly, the hardest part to sustain with an in-house team.
When NOT to patch first thing tomorrow
The natural reaction to an advisory like this is to say "we will patch the firewall tomorrow". We, who make a living at this, are going to say the opposite, and it is the reason these five doors have stood open for years in so many places: upgrading a firewall during office hours is itself an incident. It drops every VPN session, locks out anyone working remotely, and if the upgrade goes sideways you lose remote access to the device that provides remote access. Same with the backup server: moving up a major branch on a Friday with jobs running is how backup chains get broken.
What does not work is leaving that conversation without a date. The difference between a company that does not patch and one that patches slowly is that the second walks out of the meeting with four things written down: a specific window, who is in front of the device, how to roll back, and who confirms the next day that the service still does what it did. What you can do this very afternoon, with no window needed, is everything else — take management off the internet-facing side, require two-factor, rotate local credentials, check who can reach the backup server — and it is precisely what most people leave until the patch arrives.
The eight checks
This is what we walk through when an advisory like this comes out. The first five can be answered in an afternoon; the last three decide how the bad day ends.
- What version the firewall runs, and since when. The exact version next to the fixed version in the vendor advisory, plus the date of the last update. If that date is more than a year old, the rest of this list matters twice as much.
- Does the management interface answer from the internet? Check from outside, on a connection that is not the office one, not on the configuration printout. Exposed management is what turns an access-control flaw into a way in.
- Were local credentials rotated AFTER the last patch? And especially: if you moved to a new appliance generation and migrated the local users, those passwords predate the fix. This is the box that explains a good share of recent incidents.
- Two-factor on VPN and webmail, with the exception list in front of you. There are always exceptions — the supplier, the salesperson with the old phone, the service account. Having them is fine; not knowing how many there are is not. Write them down and give them an expiry date.
- The exact build of the backup server, and who can reach it. Not "version 12", the build. And then: from which networks its service is reachable, which accounts can log in to it, and whether it is a member of the same domain it is protecting.
- The NAS or repository panel. Is it administered with domain accounts? Does it have a second factor? Can somebody, from that panel, destroy retention in one click? If the answers are yes, no and yes, your second copy is the first copy under another name.
- One copy that depends on no reachable panel. Immutable at the repository, or offline. The control question is not "do we have immutable backups?", it is "who, with which credentials, can stop us having them?".
- Restore something for real, and time it. Not checking that the job came out green: bring a service up and watch the clock. Our last full recovery drill took 14 minutes; that is our figure and a test, not a promise for your case. The value is not in the number, it is in knowing what ours is.
And if the phone rings
Back to the detail from the start, because it is the one no technical plan contains: after encrypting, they call. They do not call the systems administrator — that person already knows — they call whoever picks up. And whoever picks up is usually someone in admin or at reception, on a Wednesday morning, with no script and no idea that the call is part of the attack. A continuity plan without two lines on who speaks, who does not speak and who gets told first is incomplete on the cheap side.
And it is worth remembering the right order: getting the data back is not the same as evicting the attacker. If they came in through a VPN credential that is still valid, restoring gives you back the service and gives them back the target. We devoted a whole post to that distinction: recovering fast is not evicting the attacker.
What actually failed here
It was not the attacker's sophistication. All five doors had patches — every one, between two and more than six years ago — and all three vendors published their advisories on time. What failed is a process gap we see in almost every company we walk into: there is a cadence for Windows because Patch Tuesday exists and a tool does it; there is a cadence for Microsoft 365 because you do not decide it. For the firewall and the backup server there is no cadence: there is "when we get a window". And those are exactly the two devices the advisory names, precisely because they are the two you cannot reboot during office hours.
We are not resellers of any firewall or backup brand, so we can say this without a conflict: you do not fix it by buying anything. You fix it with maintenance that has written down which devices exist, what version they run, who owns each one and when its window falls — including the two nobody wants to touch — and with the continuity work that decides, before the bad day, which copy nobody can destroy from any panel. What we do sell is doing it for you when the in-house team is busy elsewhere.
The question we close on is not whether you are patched, because that one gets answered with "I think so". It is this: if somebody walks in today with your backup administrator's credentials, what copy do you still have tomorrow? If answering means asking somebody else, you already have half the answer.
Sources and method: the advisory date, the signing agencies, the "at least 600 victims" figure, the period since August 2024, the list of five exploited CVEs, the tool inventory (ShareFinder.ps1, SharpShares.exe, WinRAR, 7-Zip, Rclone, FileZilla, PsExec, WinRM, AnyDesk, TeamViewer, Mimikatz), halting the Volume Shadow Copy Service, the reset of NAS devices to factory settings, the phone call to the victim and the recommended mitigations all come from the joint advisory AA26-293A, #StopRansomware: SafePay Ransomware, published by CISA on 20 October 2026 and consulted the same day. The fixed Veeam Backup & Replication versions come from the vendor bulletins KB4424 (CVE-2023-27532: builds 12.0.0.1420 P20230223 and 11.0.1.1261 P20230227) and KB4649 (CVE-2024-40711: affects 12.1.2.172 and all earlier v12 builds, fixed in build 12.2.0.334). The details of CVE-2024-40766 — scope across Gen 5, 6 and 7, management and SSLVPN, advisory SNWLID-2024-0015 — and the recommendation to change local user passwords after upgrading come from SonicWall's notice on recent SSLVPN threat activity, which is also where the vendor clarifies that the later wave relied on credentials compromised before the patch; the reading that patching does not rotate credentials is developed in the SANS Internet Storm Center diary on that same CVE, cited as a secondary source. CVE-2020-3259 and CVE-2023-20269 are described per Cisco's security advisories for ASA and FTD; fixed versions go branch by branch and must be read in the corresponding advisory, which is why we do not reproduce them here. We have no telemetry of our own on SafePay and have not handled an incident from this group: everything attributed to the attacker comes from the advisory. The 14-minute figure is ours, from an internal full-recovery drill, and is given as a test performed, not a service commitment. What is ours here is the reading — that all five doors predate 2025, that three sit at the perimeter and two in the backup keyring, that a factory reset is not a deletion, and that the gap lies in the patching cadence of the two devices you cannot reboot during office hours — plus the eight checks, which are our own. Translations of quoted terms are ours.
When did you last update the firewall?
We run the maintenance of the devices nobody wants to reboot — firewalls, VPNs, backup servers — with an inventory, an owner and a written window, and the continuity decided before the bad day. We usually start with a two-afternoon inventory and a list of credentials nobody had rotated.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN