SafePay Ransomware Factory-Resets NAS Backups: The Homelab 3-2-1 Survival Guide (CISA AA26-293A)


 

On October 20, 2026, the FBI, CISA, the US Secret Service, Germany's Landeskriminalamt Rheinland-Pfalz, the UK's National Crime Agency and the UK's North West Regional Organised Crime Unit published joint advisory AA26-293A on the SafePay ransomware group — active since August 2024, with 600+ critical infrastructure victims across North America, South America, Europe and Australia. "SafePay actors have already targeted more than 600 victims worldwide across multiple critical infrastructure sectors," said Brett Leatherman, assistant director of the FBI's cyber division.

The coverage treats it as enterprise news — but the detail that matters for homelabs is buried: SafePay halts the Volume Shadow Copy Service and factory-resets NAS devices holding backups. Investigators found cases where every company NAS backup was deleted before encryption began. Your NAS isn't collateral damage here — it's the target. Below: what SafePay does, why homelabs are exposed, and the 3-2-1 backup architecture that survives a NAS-wiping attack.

⚠️ Honest testing note. We did not detonate ransomware in a lab — deliberately. Every fact below is verified against the joint advisory's coverage (TechNadu, GBHackers, technology.org) and vendor documentation. Commands are standard documented procedures; anything setup-specific is labeled. Apply changes on your own schedule, snapshot first.

What SafePay Does (in Plain Language)

SafePay is a private group (no affiliates) and one of 2026's most active ransomware operations. Its playbook, per the advisory's published tactics:

  • Initial access: exposed or phished credentials, brute-force password attacks, VPN access (investigators observed connections from Mullvad VPN exit IPs), and five edge-device flaws: CVE-2020-3259, CVE-2023-20269, CVE-2023-27532, CVE-2024-40711 (CVSS 9.8, Veeam Backup & Replication, per TechNadu) and CVE-2024-40766 (SonicWall SonicOS management access).
  • Inside the network: new or hijacked accounts; PsExec, WinRM and RDP for lateral movement; UAC bypass and token impersonation; security software disabled; shares enumerated (ShareFinder.ps1, SharpShares.exe); credentials harvested (Mimikatz).
  • Data theft: files staged (FileZilla, 7-Zip, WinRAR), then exfiltrated via WinSCP, RClone, OneDrive and Backblaze B2 (b2.exe) — backup tooling many homelabs run daily. Delivery rides AnyDesk and TeamViewer.
  • Recovery sabotage: stops the Volume Shadow Copy Service and factory-resets NAS devices holding backups.
  • Encryption and pressure: ChaCha20 + RSA encryption (full or partial), .SafePay extension, Tor chat portal with victim ID, crypto demands, and direct phone pressure on victims.

One caveat: security press (Huntress, via TechNadu) reports overlap between SafePay's binary and leaked LockBit Black source code — but that's press-reported, not advisory-confirmed. Treat rebrand theories as unconfirmed.

Why Your Homelab Is Exposed

Strip the enterprise framing and the advisory reads like a homelab audit:

  • Your backup tools are their exfil tools: RClone and Backblaze B2 sit in SafePay's exfiltration kit. Don't stop using them — but credential scope and backup architecture decide whether they protect you or serve the attacker.
  • NAS admin interfaces on the internet. The advisory's initial-access list opens with exposed credentials and VPN access. A NAS management UI reachable from the internet is the front door.
  • Veeam users: CVE-2024-40711 is a 9.8 in Veeam Backup & Replication — your backup software is an attack vector if unpatched. Same for SonicWall users and CVE-2024-40766.
  • Reused credentials. Brute-force and credential theft are core to SafePay's access. One password across NAS, router, and services is one compromise away from total loss.

The 3-2-1 Survival Playbook

The 3-2-1 backup rule — 3 copies, 2 different media, 1 offsite — predates most homelabs. SafePay's NAS-reset behavior is exactly why "2 media" and "1 offsite" aren't optional. Here's the build that survives a NAS-wiping attack:

1. Make Backups Immutable

A backup the attacker can't delete survives. On ZFS, held snapshots can't be destroyed through the normal path — and snapshots on storage the NAS can't rewrite survive even a factory reset:

# Snapshot the backup dataset (standard ZFS procedure — adapt pool/dataset names)
zfs snapshot tank/backups@$(date +%F)-safepay

# Hold it so nothing — not you, not malware with your credentials — destroys it casually
zfs hold safepay tank/backups@$(date +%F)-safepay

# Belt and suspenders: read-only on the snapshot
zfs set readonly=on tank/backups@$(date +%F)-safepay

On TrueNAS, use a periodic snapshot task with destroy disabled or held. For cloud copies, B2 and S3-compatible storage offer Object Lock — files that can't be deleted or overwritten until retention expires, whatever credentials the attacker holds. Highest-leverage change on this list.

2. Go Pull-Based, Not Push-Based

If the NAS pulls backups from the source, compromised source credentials can't reach in to delete them. If the source pushes to the NAS, its credentials are a loaded gun at your backups. Let the backup target initiate the copy; the source exposes read-only at most. That's what makes the factory-reset scenario survivable: the attacker never had NAS write credentials.

3. Keep One Copy Offline

A USB drive rotated weekly and stored disconnected can't be encrypted, exfiltrated, or factory-reset — the cheapest air gap there is, and the literal "2 different media" in 3-2-1. Automate the copy, keep the disconnect manual: automation that stays connected is automation ransomware can follow.

4. Scope Backup Credentials to the Minimum

SafePay exfiltrates before it encrypts — an unusual outbound spike is your early warning, so alert on it. Scope every backup credential: B2 keys limited to one bucket with no delete; RClone remotes write-only where possible; separate credentials per job. Your Immich photo library is exactly the irreplaceable data that deserves its own scoped key — family photos don't get a second take.

5. Take the NAS Admin Off the Internet, Enable MFA Everywhere

The advisory's mitigations, translated: MFA on every exposed login (VPN, NAS, router admin); restrict admin tools and privileges; segment the network. Practically: NAS/router admin behind VPN (WireGuard/Tailscale) or LAN-only, never port-forwarded; MFA everywhere it's offered; unique credentials per service. Same snapshot-first discipline as our Pi-hole v6.5 safe-update workflow — applied to access.

6. Patch the Five Advisory CVEs

CVE-2020-3259, CVE-2023-20269, CVE-2023-27532, CVE-2024-40711, CVE-2024-40766. An old CVE is not a harmless CVE — SafePay's 2024-vintage flaws are still opening doors in 2026. Veeam and SonicWall users patch first; everyone else audits what's internet-facing this week, not someday.

✅ The 30-minute version. Enable Object Lock or snapshot holds on one backup copy → switch the NAS job to pull-based → rotate one USB copy offline → scope the B2/RClone keys (no delete) →

If You Suspect Compromise

SafePay's tactics are your detection checklist: unexpected accounts, PsExec/WinRM/RDP activity you didn't start, disabled security software, outbound transfers to unknown hosts. If you see them: isolate the machine immediately, preserve evidence, and don't reconnect backups to an infected host — that's how the NAS gets reset. Restore from a pre-incident copy with the same incident-response discipline as our Nextcloud Collabora backdoor playbook: clean image, rotated secrets, verified restore.

On payment: the advisory's posture is that paying doesn't guarantee recovery — and it funds the next campaign. Report to the FBI/CISA (or your national CERT) instead. That's the agencies' stated recommendation, not moralizing.

FAQ

What is SafePay ransomware?

A private ransomware group active since August 2024. Joint advisory AA26-293A (FBI, CISA, US Secret Service, German and UK agencies, Oct 20, 2026) attributes 600+ critical infrastructure victims across four continents. It exfiltrates data, sabotages backups, then encrypts with ChaCha20+RSA (.SafePay extension).

Can ransomware really factory-reset a NAS?

Yes — SafePay does exactly that to NAS devices holding backups, after stopping the Volume Shadow Copy Service, per the joint advisory's published tactics. A backup on the same NAS, under the same credentials, is not a real backup against this threat: you need immutable or offsite copies the attacker can't reach.

I use RClone and Backblaze B2 for backups. Am I at risk?

The tools aren't the problem — SafePay abuses them because they're effective. Protect yourself with scoped credentials (B2 application keys limited to one bucket, no delete permission), pull-based backup jobs, and Object Lock on the bucket.

What is the 3-2-1 backup rule?

Keep 3 copies of your data, on 2 different types of media, with 1 copy offsite. Against NAS-wiping ransomware, the "different media" and "offsite" parts do the heavy lifting: one offline USB rotation plus one immutable offsite copy means a factory reset costs you an afternoon, not your data.

Does an immutable ZFS snapshot protect me if the NAS is factory-reset?

Only if the snapshot lives where the reset can't reach it. A held snapshot on the same NAS stops deletion and encryption — not a full device wipe. Pair local immutable snapshots with an offsite or offline copy for the full 3-2-1.

Should I pay the ransom if hit?

The agencies behind AA26-293A advise that paying doesn't guarantee you'll get your data back. Report the incident to the FBI/CISA or your national CERT, isolate affected systems, and restore from clean backups instead.


move NAS admin behind VPN + MFA → patch Veeam/SonicWall/edge devices. In that order.

Running your own code server too? Patch it tonight with our GitLab CVSS-10 RCE patch guide.

Comments

Popular posts from this blog

Nginx 502 Bad Gateway in Docker? 4 Fixes That Actually Work (2026)

GitLab Update: Patch the CVSS-10 RCE Tonight — Self-Hosted Fix Guide (CVE-2026-110264)

php2shell: Patch Your Self-Hosted PHP Stack Tonight — Emergency RCE Playbook (CVE-2026-109618, CVE-2026-109619)