SafePay ransomware: AA26-293A for red team use

On October 20, 2026, CISA, the FBI, the USSS, and partners in Germany and the United Kingdom published joint advisory AA26-293A on SafePay ransomware. SafePay ransomware is the operation and variant described in that #StopRansomware series advisory, with activity observed since August 2024 and at least 600 victims across multiple critical infrastructure sectors.

The official text brings TTPs, indicators, and mitigations observed in investigations that run through August 2026. CISA’s press release, dated October 21, 2026, reinforces the same picture and summarizes practical actions that cut impact, including along the SafePay VPN phishing CVE path that opens the chain.

For a red team serving defense, the value of the advisory is not in repeating the attack against third parties. It sits in turning the chain into testable hypotheses, only in your own environment or with written formal authorization, and in tying each phase to detection signals and controls the blue team can measure.

What AA26-293A states and who signed the advisory

AA26-293A states that SafePay ransomware actors have operated intensively since August 2024 against companies and critical infrastructure in the Americas, Europe, and Australia, and that the group ranked among the most active in 2026, with at least 600 distinct victims.

The authoring agencies are the FBI, CISA, the United States Secret Service, Germany’s Landeskriminalamt Rheinland-Pfalz, the United Kingdom’s National Crime Agency, and the United Kingdom’s North West Regional Organised Crime Unit. The AA26-293A advisory on CISA fixes publication on October 20, 2026, and the CISA press release, released on October 21, 2026, speaks of about 600 victims and quotes FBI Cyber Division Assistant Director Brett Leatherman with the phrasing “more than 600 victims.”

The SafePay ransomware CISA product describes a pattern familiar to anyone who runs adversary emulation. There is access gain, account creation or takeover, use of legitimate tools for movement, disabling of protections, file encryption, and a ransom note demanding cryptocurrency payment. The stated audience includes U.S. federal civilian government, SLTT, critical infrastructure and OT operators, plus defensive analysts and vulnerability managers.

In practice, what I require from a post-advisory exercise is scope locked to what the agencies documented, not forum rumor. If victim counts or geography shift in a later update, the comparison baseline remains the AA26-293A text and the date you checked it, not the team’s collective memory.

SafePay ransomware: how initial access occurs per the advisory

According to the advisory, SafePay ransomware gains initial access through credential exposure, password brute force, VPN abuse, and exploitation of internet-facing systems, including account profiles obtained through phishing and traffic associated with IPs from the Mullvad VPN provider.

In the MITRE ATT&CK Enterprise version 20 mapping used by AA26-293A, that appears under initial access (TA0001), with brute force (T1110) and exploit public-facing application (T1190). For edge devices, the advisory lists CVE-2020-3259 and CVE-2023-20269. For exposed systems with automated scripts, it lists CVE-2023-27532, CVE-2024-40711, and CVE-2024-40766. Inside AA26-293A itself, CISA prioritizes remediating KEV catalog vulnerabilities on internet-facing systems without naming vendors next to those CVEs.

The AttackIQ response analysis of AA26-293A reinforces the same CVE block and the role of credentials and phishing at the door. The Brandefense patch guide on the advisory associates the first two with Cisco ASA/FTD products, the next two with Veeam Backup & Replication, and the last with SonicWall SonicOS, always from vendor bulletins, because the AA26-293A StopRansomware text does not name the product beside each CVE. That matters for defensive red team work because the exercise hypothesis starts at the edge and at identity, not at the encryptor payload.

The mistake that costs the most here is treating VPN and firewall as already authenticated and therefore trusted. When a local account or a phished profile bypasses MFA, or when an edge CVE remains open, the rest of the SafePay ransomware chain stops being hypothetical and becomes an incident timeline.

Which TTPs the advisory maps to MITRE ATT&CK

AA26-293A maps SafePay ransomware activity to MITRE ATT&CK Enterprise version 20 tactics and techniques, and only those IDs as listed in the advisory should guide authorized emulation and detection rules.

After access, the text describes persistence through existing account manipulation (T1098) or account creation (T1136), execution with legitimate binaries (T1218), PsExec over administrative shares (T1021.002), WinRM (T1021.006), and PowerShell or shell (T1059.001, T1059.003). Tools named in the advisory include ShareFinder.ps1 and SharpShares.exe for hunting shares. In collection and egress, it cites archiving with utilities (T1560.001), exfiltration over alternative protocol (T1048), and over a web service such as OneDrive (T1567), with observed use of 7-Zip, FileZilla, RClone, WinRAR, and WinSCP. The SafeBreach synthesis published on Security Boulevard confirms, from the advisory’s ATT&CK table, inhibit system recovery (T1490) and data encrypted for impact (T1486).

AttackIQ, summarizing the same AA26-293A, also records UAC bypass, token impersonation, RDP, Mimikatz, DCSync artifacts, and abusive use of ScreenConnect, AnyDesk, and TeamViewer, plus hybrid ChaCha20 with RSA encryption, the .SafePay extension, a ransom note with TOR chat, pressure phone calls, and threats to publish on the leak site. CISA’s press release describes the same cycle of theft, encryption, and coercion, including direct phone contact in some cases.

Many people think blocking the ransomware binary is enough, and they are almost always wrong, because AA26-293A shows long LOTL stretches before encryption. If telemetry only watches the encryptor, the SafePay ransomware containment window has already closed.

How to emulate the chain in an authorized exercise

Emulating the SafePay ransomware chain in a way that helps defense means validating hypotheses of access, movement, backup sabotage, and data coercion in a lab or isolated production segment, always with written formal authorization, without exploiting third-party targets and without reproducing a functional exploit.

The goal of the exercise is not to prove that the red team gets in. It is to prove whether the organization detects and contains each phase listed in AA26-293A. That is why emulation stays at a conceptual and behavioral level, with approved tools, test accounts, and success criteria defined by the blue team before kickoff.

1. Lock a written scope with systems, time windows, synthetic data, and abort criteria, explicitly citing AA26-293A as the threat model and forbidding any CVE exploitation with an armable payload outside a controlled lab.
2. Validate the identity and VPN surface with test accounts, mandatory MFA, and review of local authentication that bypasses the second factor, measuring brute-force and anomalous-login alerts without scanning the public internet of third parties.
3. Emulate lateral movement only with utilities already authorized in the exercise environment, generating artifacts comparable to the PsExec, WinRM, and RDP behaviors described in the advisory, and ask the SOC to classify what was or was not seen.
4. Simulate share discovery and staging with fictitious data, without exfiltrating real customer data, and check for alerts on mass compression and sync-client use.
5. Test the inhibit-recovery hypothesis on disposable copies, never on production backups, and measure whether the continuity team notices loss of shadows or a lab NAS reset in time to trigger the plan.
6. Close with a SafePay double extortion tabletop covering communication decisions, forensic evidence, and restoration, without negotiating with a real actor and without treating TOR ransom-note links as operational material.

The limitation is clear. Even a well designed exercise does not guarantee that a real SafePay ransomware incident will be contained, because telemetry, human latency, and production configuration differ from the lab. Even so, without that rehearsal, defense only finds the hole when the .SafePay note is already on the desktop.

If I built the campaign tomorrow, I would start with identity and the KEV edge, and only later touch synthetic exfiltration emulation. Encrypting too early in the exercise teaches little and scares a lot, without improving detection maturity.

What to detect in each phase of the chain

Defense should instrument each SafePay ransomware phase with explicit alert hypotheses, because the advisory describes a long LOTL campaign, not a single obvious executable.

At initial access, look for spikes in failed VPN authentication, logins with freshly phished profiles, origins associated with the commercial VPN cited in the advisory, and attempts against edge devices that are still unpatched. In execution and persistence, correlate privileged account creation, mass password changes on valid users, and rare use of PsExec, WinRM, or remote-access software installed outside a change window. In discovery, treat ShareFinder.ps1 and SharpShares.exe, or equivalent AD share-scanning behavior, as asset hunting ahead of exfiltration. In collection, watch compression with 7-Zip, WinRAR, or RClone on business volumes, followed by transfer through FileZilla, WinSCP, or OneDrive. At impact, prioritize Volume Shadow Copy Service stoppage, backup NAS factory resets, and the appearance of the .SafePay extension, plus ransom notes on the desktop or at the root.

None of those signals alone proves SafePay ransomware. Together, and aligned with the STIX IOCs from AA26-293A, they raise confidence enough to isolate accounts and segments. The hidden cost is false positives during legitimate administration. That is why an authorized exercise must calibrate allowlists and change context, or the SOC learns to ignore the right alert.

In practice, what I see most often is rich endpoint telemetry and thin coverage on VPN and backup. Against the AA26-293A profile, that asymmetry leaves the organization blind exactly where the actor decides whether recovery still exists.

Why backup destruction and double extortion change the response

Because the advisory describes actors who exfiltrate before they encrypt, sabotage Volume Shadow Copy and backup NAS devices, and still pressure by phone and by publication threats, “just restore” is insufficient if the online copy was destroyed or if the leak has already gone out.

AA26-293A records that the group stops the Volume Shadow Copy Service and factory-resets NAS devices holding backup data, classified as inhibit system recovery (T1490). It then encrypts with ChaCha20 and RSA, demands cryptocurrency payment, and, if payment does not arrive, publishes on the leak site linked in the note. CISA’s press release confirms the theft-plus-encryption pattern and, in some cases, direct calls to victims. That is the core of the SafePay double extortion described by the agencies.

For incident response, that changes the order of work. Beyond containing encryption, you must preserve evidence of exfiltration, estimate what left, and decide communication on legal and contractual grounds, without assuming that payment restores reputation. Payment is also no guarantee of clean decryption or deletion of the stolen copy, and technical summaries of the advisory make clear that data encrypted with the .SafePay variant is not recoverable without the actor’s key.

The path I prioritize with most teams is proving restoration from an offline and immutable copy before an incident, and training the leak tabletop as a separate event from technical restore. When the only backup lives in the same segment the actor already administered, coercion finds the organization without a plan B.

Prioritized SafePay ransomware mitigations for MFA, VPN, KEV, and immutable backups

The SafePay ransomware mitigations that the advisory and CISA’s note put first are continuous updating, MFA, priority KEV patching on internet-facing systems, tested offline backups, and segmentation, because those measures cut the entry paths and the impact used for collection.

AA26-293A calls for priority KEV remediation, Zero Trust, restriction of tools and administrative privileges, and ICAM policies with MFA. The October 21, 2026 note repeats MFA, patching of known exploited vulnerabilities, offline backups with restore tests, and segmentation. Two CVEs cited in the advisory already had public entries in CISA’s KEV catalog in 2024, which reinforces the historical urgency of the edge and exposed backup. On October 17, 2024, CISA added CVE-2024-40711 to the KEV catalog, and on September 9, 2024 it included CVE-2024-40766 in the same catalog. Veeam KB4649, published on September 4, 2024 and updated later, describes CVE-2024-40711 as unauthenticated RCE with CVSS v3.1 9.8 and a fix starting at build 12.2.0.334.

These actions reduce likelihood and impact, but they do not erase residual risk. Poorly implemented MFA still fails if a local account lacks a second factor. Delayed appliance patching leaves T1190 open. Immutable backup without a restore test becomes fiction in a crisis. Segmentation without privileged-account control is crossed by abused legitimate RDP and WinRM.

When I review plans after a #StopRansomware alert, I ask for evidence of a recent restore and a KEV inventory of the edge before any discussion of a new EDR tool. Without those two pillars, the rest of the SafePay ransomware playbook turns into slide theater.

What remains unknown after AA26-293A

From the public AA26-293A text alone, you still do not know a complete and stable list of every victim, the average ransom asked in each case, or whether every listed CVE appears in every intrusion, because the advisory aggregates investigation observations and does not publish an auditable case-by-case census.

You also cannot treat STIX IOCs as eternal coverage. Indicators age, actor infrastructure rotates, and migrating TTPs appear after the cutoff date. The advisory mentions investigations through August 2026, and publication is October 20, 2026, so any later campaign needs a fresh check of official sources. Mild wording gaps among “at least 600,” “about 600,” and “more than 600” already appear across the advisory, the note, and Reuters coverage republished in outlets such as Yahoo News, which is why you should quote the exact sentence from the page you used.

For red team and threat intel, the useful gap is different. AA26-293A does not replace local telemetry, and it does not authorize offensive scanning of someone else’s internet in the name of research. What is missing on your network is found only through inventory, hunting, and authorized exercise, not through extrapolation from the PDF.

I treat that uncertainty as part of the job, not as an excuse for stillness. You use what the advisory states with a date, you label internal hypotheses clearly, and you update the model when CISA or the FBI publish a correction.

Frequently asked questions about SafePay ransomware

Before closing, these questions gather doubts that usually appear when a SOC or red team opens AA26-293A for the first time and needs to turn the text into measurable action without leaving ethical scope. The answers below stay at the level of the advisory and of defense, without armable instruction, and they serve both to prioritize patching and to design an authorized exercise with clear success criteria for the blue team.

Does AA26-293A attribute SafePay to a state operation?

AA26-293A treats SafePay ransomware as a ransomware group and variant observed since August 2024, with encryption, a cryptocurrency ransom note, and added pressure through leaks and phone calls. The agencies do not present the text as a state geopolitical attribution. For defensive planning, what matters is the documented behavior, the CVEs, the ATT&CK TTPs, and the mitigations, all dated to October 20, 2026 in the advisory and reinforced on October 21, 2026 in CISA’s note.

Do I need to exploit the listed CVEs to train the team?

No. Training functional exploitation of those CVEs against third-party systems is illegal and outside the ethical scope of this kind of article and of a responsible exercise. The path aligned with the advisory is priority patching, edge inventory, MFA review on VPN, and behavioral emulation only in your own environment or with written authorization. Detecting authentication failure, anomalous LOLBin use, and backup sabotage delivers more operational value than reproducing a PoC.

Are cloud backups enough against this group?

They are not enough if the actor already holds a privileged account and can delete, encrypt, or reset a repository reachable from the compromised network. AA26-293A describes interruption of Volume Shadow Copy and reset of backup NAS devices, which hits accessible online copies. The mitigation cited by the agencies includes offline backups and regular restore tests. Without immutability and without proof of restore, the cloud alone does not solve SafePay double extortion coercion.

How should the red team use the advisory’s ATT&CK mapping?

It should use only the techniques AA26-293A lists, as a matrix of hypotheses for detection and for authorized scenarios, in the Enterprise version 20 referenced in the text. Each technique becomes a question to the SOC about logs, alerts, and response time. Techniques from unofficial sources or isolated reports enter as a separate hypothesis, with a lower confidence label, until a primary source exists. That avoids bloating the exercise with noise and keeps traceability to the agencies’ document.

What should you do in the first 72 hours after reading the advisory?

In the first 72 hours, prioritize inventory of the five CVEs from the advisory on the edge and on exposed backup, confirm MFA without local bypass on VPN, validate that a testable offline copy exists, and load the AA26-293A STIX IOCs into the detection pipeline with an expiration process. In parallel, put a short authorized exercise on the calendar focused on identity, LOTL movement, and inhibit recovery. That sequence does not eliminate SafePay ransomware risk, yet it shrinks the surface the advisory itself marks as most exploited.

Conclusion

AA26-293A puts SafePay ransomware at the center of defensive priority for October 2026 with numbers, dates, CVEs, and TTPs sufficient to act without waiting for the next industry incident. For most organizations, the first useful step is closing the KEV edge and VPN MFA, and proving offline restore, because that is where the advisory shows the campaign gaining momentum.

The response changes when you already have evidence of prior commit or of exfiltration. In that case the order becomes forensic containment, estimation of what left, and controlled communication, still with the same discipline of not improvising offensive exploitation. The authorized exercise exists to find the detection gap before a real actor does, not to collect encryption screenshots.

If your team can do only one thing this week, choose the combination of inventorying the advisory’s CVEs plus a restore test from a copy that SafePay ransomware cannot reach over the corporate network. The rest of the emulation and hunting program gains a solid base after those two controls exist in reality.

This material is informational and educational about advisory AA26-293A and about defensive emulation of SafePay ransomware. It does not replace a professional security, legal, or incident-response assessment. Any technical test must occur only in environments you own or with written formal authorization from the system owner, without exploiting third-party targets and without using an exploit, payload, or armable procedure.