SafePay #StopRansomware mid-engagement: edge CVEs, LOTL, and what not to attribute

On 20 Oct 2026, CISA and partners published joint advisory **AA26-293A — #StopRansomware: SafePay Ransomware**. A 21 Oct news release summarizes the same picture: credential abuse and known edge vulnerabilities for initial access, living-off-the-land (LOTL) movement, backup sabotage, exfiltration, then encryption with double-extortion pressure.

CISA states SafePay has been highly active and has impacted at least 600 victims across multiple regions and critical infrastructure sectors. Use the advisory PDF/STIX for IOCs — this post is engagement sequencing, not a copy of the IOC tables.

What the advisory is actually for

#StopRansomware advisories are defender playbooks: TTPs, leveraged tools, mitigations, and indicators. On an authorized pentest, they are useful as:

1. A prioritized list of edge products/CVEs to check *if they are in scope and present*
2. A reminder of LOTL patterns that look like admin work until you have timeline + intent evidence
3. A hard line: finding PsExec or RClone is not SafePay attribution

Edge CVEs called out for initial access

AA26-293A ties SafePay-style access (in part) to exploitation of known edge issues, including:

Also: VPN credential abuse / brute force and use of VPN-provider IP infrastructure for access (advisory names Mullvad in that context — verify details on the source page).

Operator cue: inventory internet-facing VPN/firewall/remote-access gear in ROE against this list. Version + exposure evidence first. Do not paste the CVE table into a report as “SafePay presence.”

LOTL and dual-use tools (do not block-on-sight)

The advisory’s tool table mixes malware helpers with legitimate ops software SafePay abuses: PsExec, WinRM, PowerShell, RDP, ShareFinder.ps1 / SharpShares, 7-Zip / WinRAR, FileZilla / WinSCP / RClone, AnyDesk / TeamViewer / ScreenConnect, Mimikatz, NetExec, and others.

CISA’s own note: these should not be attributed as malicious without analytical evidence of threat-actor use/control.

On engagement that means:

• Unexpected new remote-support installs and odd share-enumeration scripts deserve notes
• Backup/VSS disruption and NAS factory-reset patterns in the advisory are high-signal *if you are doing IR* — on a pentest, only report what your authorized activity and evidence support
• Exfiltration tooling in a customer environment may be IT-approved; ask before screaming ransomware

Mid-engagement decision tree

Triage questions

1. In ROE? Internet edge, VPN, and backup infrastructure authorized to test?
2. Present here? Specific products/versions from the advisory — or only the news cycle?
3. Credential story? Password spray / phished VPN profiles are in the advisory narrative — do you have authorization and evidence for that path?
4. Attribution bar? Which SafePay-specific IOCs (from STIX) did you actually observe?
5. What do you pause? Unfinished AD/web paths with evidence still deserve a clean pause note.

Evidence worth capturing (when in scope)

• Exact edge appliance model/firmware and which advisory CVE applies
• Proof of the access path within authorization (no invented zero-days)
• Timeline of dual-use tool use that is not your own testing
• If IR-authorized: ransom note / .SafePay extension claims only with filesystem evidence; preserve logs before rebuild

What not to write

• “Environment is SafePay-compromised” because an edge CVE is unpatched
• Blocking recommendations for 7-Zip/PsExec as if they were malware families
• Reciting CISA victim counts as your measured finding
• Completeness claims (“all edge CVEs checked”) without enumeration evidence

Client-facing mitigations (short)

Point them at AA26-293A: patch edge devices, MFA, segment networks, offline tested backups, restrict admin tooling. For IOC hunting, use the advisory’s STIX packages — do not rely on a blog mirror.

Primary sources: AA26-293A and the 21 Oct CISA news post.