SafePay Ransomware: What CISA Advisory AA26-293A Says and What to Do

On 20 October 2026, CISA, the FBI and four partner agencies published #StopRansomware advisory AA26-293A on SafePay. They say the group has hit at least 600 victims across critical infrastructure sectors since August 2024, mostly through stolen or guessed passwords, VPN access and old edge device flaws. Patch those flaws, enforce MFA and protect your backups.

The advisory is useful because so little in it is new. The five CVEs it lists were all disclosed in 2024 or earlier. The entry points are passwords, VPNs and firewalls. The damage comes from admin tools that every Windows network already has, and from backups that sit on the same network as everything else. That makes the advice practical: most of it is work a team can start this week.

This post covers what the advisory says at a high level, CISA's recommended mitigations as a checklist, the commands to check your own exposure, and what would have helped. It leaves out the indicators of compromise. Get those from the advisory itself and its STIX files, and verify them before you block anything, as the agencies advise.

What happened

What is disputed or unclear

• What the 600 figure counts. The advisory says SafePay "has impacted at least 600 separate victims from multiple critical infrastructure sectors." Several headlines turned that into 600 critical infrastructure organisations. The advisory's wording is about victims drawn from those sectors; it does not say each of the 600 is a critical infrastructure operator. BleepingComputer adds that leak sites list only victims who do not pay, so the real number of victims is probably higher.
• Sectors. The advisory refers to multiple critical infrastructure sectors but, in the version we read, does not name them. Regions are named: North America, South America, Europe and Australia.
• How the group is organised. BleepingComputer describes SafePay as a private group that does not work with affiliates. The advisory itself does not say whether it runs as ransomware as a service or as a closed team.
• Lineage. Infosecurity Magazine reports SafePay is believed to be a rebrand drawing on LockBit, ALPHV/BlackCat and INC Ransomware. The advisory does not make that claim, and we could not confirm it.
• Vendors behind the CVEs. The advisory lists five CVE IDs without naming products. We mapped them to vendors using the CVE records themselves (see the table below).

Who is affected

Any organisation can be a target, but the advisory points to a clear profile: internet-facing VPNs and firewalls, password-only remote access, and backup servers reachable from the main network.

The five CVEs named in the advisory, with vendor and product taken from each CVE record:

Two things stand out. Three of the five are in VPN and firewall gear. Two are in backup software. A team that patched its firewalls but left the backup server two years behind still had a door open, and that door led straight to the thing it would need for recovery.

A CVSS of 5.0 on CVE-2023-20269 is a good warning about scores. On paper it is a medium. In practice, a flaw that helps an attacker brute force VPN logins is a ransomware entry point, which is why KEV status and internet exposure matter more than the base score.

How SafePay operates, at a high level

This is a summary of the tactics the advisory describes, without indicators or step by step detail.

1. Initial access. Exposed credentials, brute force password attacks, phished accounts, VPN access and edge device CVEs exploited with automated scripts against internet-facing systems. The advisory notes VPN connections from addresses belonging to the Mullvad VPN service. That tells you the attacker hides their origin; it does not mean every Mullvad connection is hostile.
2. Privilege. The operators gain administrator rights on existing accounts or create new ones, using built-in tools. The advisory lists a user account control bypass and token impersonation.
3. Discovery. Share enumeration tools to map file shares and find data worth stealing.
4. Defence evasion. Disabling security software and changing user passwords so legitimate staff cannot log in. Infosecurity Magazine and GBHackers also report software packing and virtual machine protection to hide code.
5. Lateral movement. PsExec, WinRM, RDP and remote management software, the same tools your IT team uses.
6. Remote access. AnyDesk or TeamViewer installed, and used to deliver malware.
7. Collection and exfiltration. Data compressed with common archivers and moved out with file transfer and cloud sync tools, including Rclone, WinSCP, FileZilla, OneDrive and Backblaze's command line client.
8. Recovery sabotage. The Volume Shadow Copy Service is stopped, network attached storage holding backups is reset to factory settings, and in some cases all network attached backups were deleted.
9. Encryption. A hybrid scheme using ChaCha20 and RSA, full or partial depending on file type and size. Files get a .SafePay extension, and the binary may delete itself afterwards.
10. Extortion. A ransom note points to a Tor chat portal. The group phones victims, asks for a share of company revenue in cryptocurrency, and posts stolen data to a leak site if the victim does not pay.

Step 8 is the one to plan around. Ransomware that cannot reach your backups is an outage. Ransomware that can reach them is a negotiation.

The agencies also say that paying does not guarantee you get your files back, and they ask victims to report incidents to law enforcement.

CISA's recommended mitigations, as a checklist

The advisory lists these in roughly this order, mapped to CISA's Cross-Sector Cybersecurity Performance Goals (CPGs). Wording is ours.

• Patch known exploited vulnerabilities first, starting with internet-facing systems, and keep software and firmware current (CPG 2.B). The advisory points to BOD 26-04 for prioritisation.
• Require MFA wherever possible, especially on webmail, VPNs and accounts that reach critical systems, under an identity, credential and access management policy (CPG 3.F).
• Harden password-based accounts in line with NIST guidance (CPG 3.B):
  • Passwords of 15 to 64 characters
  • Stored hashed, in a password manager
  • Salts on shared credentials
  • No reuse (CPG 3.C)
  • Lockout after repeated failed logins (CPG 3.E)
  • No password hints
  • Forced changes no more than once a year
• Keep offline backups and test restores regularly (CPG 3.O).
• Encrypt backups and make them immutable, across the whole data estate (CPG 3.K).
• Have a recovery plan with multiple copies of sensitive data and servers in separate, segmented locations (CPG 3.I, 3.O, 1.C).
• Segment the network to slow spread and lateral movement (CPG 3.I).
• Monitor the network for abnormal activity and lateral movement; the advisory calls out EDR tools as especially useful (CPG 4.B).
• Filter traffic so unknown or untrusted sources cannot reach internal remote services.
• Review domain controllers, servers, workstations and Active Directory for new, inactive or unrecognised accounts.
• Disable unused ports.
• Consider banners on email from outside the organisation.
• Audit admin accounts and apply least privilege (CPG 3.G).
• Use time-based, just in time admin access, as described in CISA's Zero Trust Maturity Model.
• Disable command line and scripting activity and permissions where you can (CPG 3.M).
• Test your controls against the ATT&CK techniques the advisory maps, and verify indicators before blocking, since several listed tools are legitimate software.

What to do now

The checklist is long. This is the order we would work in, with commands to check where you stand. Run the Windows commands from an admin workstation you trust, with the Active Directory PowerShell module installed.

1. Find the five CVEs on your edge and backup gear. Pull the software version from every Cisco ASA or FTD, SonicWall and Veeam Backup & Replication install you own, and compare it to the vendor's fixed builds in each vendor advisory. On ASA, the CLI command is:

   show version
   

   On a Windows backup server, list the installed Veeam packages and versions:

   Get-Package -Name "*Veeam*" | Select-Object Name, Version
   

   If anything is behind, patch it this week and treat the device as possibly compromised until you have checked its logs.

2. Check that VPN logins need MFA. Look at every remote access path: SSL VPN, clientless portals, RDP gateways and remote support tools. A single password-only path is enough. CVE-2023-20269 is about brute forcing exactly this kind of login.

3. Check lockout policy. Brute force only works where lockout is off or very loose:

   Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, MinPasswordLength
   

   A LockoutThreshold of 0 means no lockout. Do the same check on any VPN or firewall that keeps local accounts.

4. Look for new and unexpected admin accounts. The advisory says operators create accounts and add them to admin groups:

   $since = (Get-Date).AddDays(-90)
   Get-ADUser -Filter {whenCreated -ge $since} -Properties whenCreated | Select-Object SamAccountName, whenCreated
   Get-ADGroupMember "Domain Admins" -Recursive | Select-Object SamAccountName
   

   Every name should have an owner and a reason. Repeat for local administrators on servers.

5. Check shadow copies and backup reachability. On key servers:

   vssadmin list shadows
   Get-Service VSS | Select-Object Status, StartType
   

   Then answer one question honestly: can a domain admin account reach and erase every copy of your backups? If yes, you need an offline or immutable copy before anything else on this list.

6. Inventory remote access software. AnyDesk and TeamViewer appear in the advisory. Find where they are installed, allow list the ones IT uses, and remove the rest:

   Get-Package | Where-Object { $_.Name -match "AnyDesk|TeamViewer" } | Select-Object Name, Version
   

7. Load the advisory's indicators into your monitoring, carefully. Use the STIX files from the advisory. Several of the listed tools are legitimate, and some IP addresses may since have changed hands, so verify before you block.

8. Write down your restore test. Pick one critical system, restore it from backup into an isolated network, and time it. If you have never done this, you do not know whether your backups work.

If your checks find signs of intrusion, isolate affected hosts, preserve evidence, scope compromised accounts, and coordinate eviction and reporting, which GBHackers summarises as the advisory's response steps.

What would have helped

None of the reporting names SafePay victims in a way that tells us anything about their setups, and we make no claims about any organisation. These are practices that would have narrowed the paths the advisory describes, for any team.

Practices any team can use

Treat edge and backup CVEs as a single deadline. The five CVEs in this advisory are between two and six years old. BOD 26-04, which the advisory cites, gives federal agencies as little as three days for the most urgent cases: internet-exposed, known exploited, automatable, full control. You do not have to be a federal agency to borrow that rule. Our post on edge device zero days in October 2026 applies the same idea to this month's appliance flaws, and our PAN-OS CVE-2026-0257 post shows another ransomware crew turning a months-old VPN fix into access.

Put the backup server on the edge list. Two of the five CVEs are in backup software. Teams often patch the backup server late because it is internal and boring. The advisory shows it is a target in its own right, and a stolen backup credential is worth more than a stolen user password.

Never let one credential reach every backup. Offline or immutable copies, held under separate credentials that do not live in Active Directory, are what turn step 8 from a disaster into an inconvenience. Our IDCF Cloud ransomware post covers backup independence when a provider is the one hit.

MFA everywhere, with no password-only side doors. Brute force and phished accounts top the access list. MFA on the main VPN does little if a legacy portal or a forgotten RDP gateway still accepts a password alone.

Make admin rights rare and short-lived. Just in time admin access and fewer standing domain admins make account creation and privilege escalation louder and slower. That buys detection time.

Allow list remote tools. If PsExec, WinRM, AnyDesk and TeamViewer are only allowed for named admins from named hosts, their use by anyone else becomes an alert instead of background noise.

Restore, do not just back up. A restore test is the only proof that backups work. Our October incident roundup makes the same point across several incidents this month.

Where Safeguard fits

Limits first. Safeguard does not scan firewall firmware or backup appliances, watch network traffic, detect brute force attempts, manage Active Directory or protect backups. It would not have flagged a vulnerable SonicWall, ASA or Veeam install on your network, and it would not have stopped SafePay. For the edge and backup gear in this advisory, rely on vendor advisories, the KEV catalog and your infrastructure team's inventory.

Where it helps is the software you build and run, which you will be checking, rebuilding and redeploying after a ransomware incident, and which needs the same patch discipline the advisory asks for.

Inventory and SBOMs. Safeguard generates SBOMs and scans dependencies in repositories, container images and existing SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version. After an intrusion, that is a record of what each internal service should contain before you put it back on the network.

KEV-first patching for your own code. Components are matched against vulnerability databases, with reachability analysis, so the flaws that are known exploited and reachable get fixed first. That is the same ordering CISA asks for at the edge, applied to your applications. Policies and gates, evaluated in the platform, can stop a rebuilt service from shipping with a known exploited flaw.

Approved changes during recovery. The Safeguard CLI's assistant can edit code and run commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. During an incident, use Ask or Strict so a person approves each step. Autonomous fix PRs exist and are off by default. safeguard exec runs in CI. The desktop and phone apps can send work to a computer running the CLI and ask you to approve each command, which keeps a human decision on every change while admin credentials may be in the wrong hands.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Firewall operating systems and commercial backup products like those in this advisory are outside that scope, and it played no part in the SafePay findings.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

Neither replaces a vendor advisory for a firewall or a backup server. The habit they support is the one that matters after ransomware: rebuild internal services from patched, signed components from a curated source, rather than restoring images that were running while an attacker held admin rights.

Common mistakes

• Reading CVSS 5.0 as low priority. CVE-2023-20269 is a medium on paper and a VPN brute force aid in practice. Rank by KEV status and exposure.
• Patching the firewall and forgetting the backup server. Two of the five CVEs are in backup software.
• MFA on the main VPN only. Legacy portals, clientless VPN, RDP gateways and remote support tools need it too.
• Backups on the domain. If the same admin credential reaches production and every backup copy, one stolen account can wipe both. The advisory describes NAS backups reset to factory settings.
• Blocking every indicator blindly. The agencies warn that several listed tools are legitimate and some IP addresses may be reassigned. Verify first.
• Patching and stopping. An attacker who came in through an old flaw may already have accounts, remote tools and stolen data. Hunt before you call it closed.
• Paying and assuming the files come back. The agencies say payment does not guarantee recovery.

FAQ

What is SafePay ransomware?

SafePay is a ransomware operation active since August 2024, according to the joint advisory. It steals data, encrypts files with a .SafePay extension, and pressures victims with phone calls and a leak site. CISA describes it as one of the most active ransomware groups in 2026.

Did SafePay really hit 600 critical infrastructure organisations?

The advisory says "at least 600 separate victims from multiple critical infrastructure sectors." Some headlines shortened that to 600 critical infrastructure organisations. BleepingComputer notes the real total is likely higher because leak sites list only victims who refuse to pay.

How does SafePay get in?

Per the advisory: exposed or guessed credentials, brute force attacks, phished accounts, VPN access, and exploitation of edge device CVEs using automated scripts. It names five CVEs, in Cisco ASA and FTD, SonicWall SonicOS and Veeam Backup & Replication, according to the CVE records.

Which CVEs should we patch first?

CVE-2024-40711, CVE-2024-40766, CVE-2023-27532, CVE-2023-20269 and CVE-2020-3259, on any device that is internet facing or reachable from a VPN pool. Then work through the rest of the KEV catalog for your edge and backup systems.

Why does SafePay go after backups?

Because backups decide whether a victim has to pay. The advisory describes stopping shadow copies, resetting backup NAS devices to factory settings and deleting network attached backups. Offline or immutable copies under separate credentials are the main defence.

Is there a decryptor?

None of the sources we read mention one. The agencies say paying does not guarantee recovery and urge victims to report to law enforcement.

Who wrote the advisory?

The FBI, CISA and the US Secret Service, with Germany's Landeskriminalamt Rheinland-Pfalz, the UK's National Crime Agency and the North West Regional Organised Crime Unit.

Would Safeguard have prevented this?

No. Safeguard does not scan firewall firmware or backup appliances, detect intrusions or protect backups. It helps you inventory, patch and rebuild the software you run, with human approval on each change.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show SafePay, a firewall or a backup server. Each shows a real flow you would use while rebuilding the services behind them.

The first demo is a CLI session that fixes a lodash CVE. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs the install and tests, and pushes nothing. After a SafePay-style intrusion, you would run the same scan against each internal service before it goes back online and ask the assistant to bump any known exploited component, approving each command as it goes.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit, ending with the upgrade done and tests passing. In recovery, an engineer on a clean, rebuilt machine would work the same way, so every change to a service has a named approver before it is redeployed.

Click through it at your own pace, or open it full screen.

The third demo is an Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. SafePay operators change passwords and create admin accounts, so during an incident you want each change tied to a person. The incident lead can give that approval from wherever they are.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• CISA: #StopRansomware: SafePay Ransomware (AA26-293A)
• BleepingComputer: CISA: SafePay ransomware hit over 600 critical infrastructure orgs
• Infosecurity Magazine: SafePay has compromised 600 critical infrastructure victims worldwide
• GBHackers: CISA warns SafePay ransomware has hit 600+ organizations and destroyed backup systems
• BleepingComputer: CISA tells govt agencies to patch critical exploited flaws in 3 days (BOD 26-04)
• CVE record: CVE-2020-3259
• CVE record: CVE-2023-20269
• CVE record: CVE-2023-27532
• CVE record: CVE-2024-40711
• CVE record: CVE-2024-40766

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.