Incident Response ยท Last verified 2026-05-16

.sorry Ransomware Extension Files: What They Mean and How to Confirm Compromise

If you're seeing files on your server with the .sorry extension, you're looking at an active ransomware compromise. Almost certainly the Mr_Rot13 crew via CVE-2026-41940. Censys counted 8,859 hosts with public .sorry files by 2026-05-08, 7,135 of them confirmed cPanel/WHM. This guide tells you what they are, who put them there, and how to confirm in under 5 minutes.

TL;DR

  • .sorry files = active ransomware compromise. Not log files, not test artifacts. Your original data, encrypted and renamed.
  • Origin: Mr_Rot13 group, leveraging CVE-2026-41940 (cPanel/WHM CRLF injection, CVSS 9.8) for initial access.
  • Detection: find / -name "*.sorry" 2>/dev/null on Linux, or our free cPanel CVE-2026-41940 IOC detector.
  • Decryption: not feasible without attacker-held keys. Anyone promising decryption is running a scam.
  • Action: preserve evidence first, scope the breach, rebuild from clean state. Don't delete files until you've triaged.

What a .sorry file actually is

When the Mr_Rot13 ransomware finishes encrypting a file, it appends .sorry to the name. So customer_database.sql becomes customer_database.sql.sorry, backup-2026-04.tar.gz becomes backup-2026-04.tar.gz.sorry, and so on. The original content gets replaced by an encrypted blob that no normal application can open.

The extension is a grim little joke. The attackers are signaling "sorry" while demanding ransom for the keys. Whatever the intent, it's a high-confidence indicator of compromise. Every observed sample uses the same extension, which makes it easy to hunt for.

Other extensions in the same family

.sorry dominates 2026 telemetry but researchers have flagged related variants in the same campaign infrastructure:

  • .ENCRYPTED. Older variant, less common in 2026.
  • .ENCRYPT. Seen in early-stage drops before the full encryption pass.
  • .locked. Used by an unrelated co-existing campaign. Don't confuse the two.

Who's behind it. The Mr_Rot13 group.

Mr_Rot13 surfaced in early 2026 alongside the mass exploitation of CVE-2026-41940. Their techniques have been documented by XLab/QiAnXin (China), watchTowr Labs (technical breakdown of the CVE), Censys (host telemetry and infrastructure mapping), and the Shadowserver Foundation (honeypot data on 44,000 compromised IPs).

Unlike a typical ransomware-as-a-service operation, Mr_Rot13 looks like a single group running their own infrastructure. The technical signatures are consistent across public reporting, IOC samples, and the observed cPanel compromise pattern.

Initial access: CVE-2026-41940 exploitation via crafted Authorization header CRLF injection. Root-equivalent access to cPanel/WHM with no credentials.

Persistence: a Go-based backdoor called Filemanager with a bcrypt-protected web GUI on a configurable port. Cross-platform binary (Linux and Windows). Most signature-based AV doesn't catch it.

Command and control: wrned[.]com, wpsock[.]com, and wrned[.]net. Known C2 as of 2026-05-08.

Encryption: AES-256 with attacker-held keys. Ransom note dropped as RECOVERY_INSTRUCTIONS.txt or HOW_TO_DECRYPT.txt in each affected directory.

Confirming compromise in 5 minutes

If you suspect .sorry files but want certainty, run these checks in order. All read-only. None of them will modify anything.

1. Direct file search

SSH in as root and run: 

find / -type f -name "*.sorry" 2>/dev/null | head -50

Any output means you have .sorry files on disk. The 2>/dev/null suppresses permission noise. The head -50 caps the list because if you've got hundreds of thousands of these, you don't need to see the whole list before you act.

2. Check the timestamp pattern

Real .sorry files share a consistent encryption timestamp because the ransomware pass runs as one batch: 

find / -name "*.sorry" -printf "%TY-%Tm-%Td %TH:%TM %p\n" 2>/dev/null | sort | head -20

Most timestamps will cluster inside a 1-6 hour window, usually during off-hours UTC. That clustering is your second confirmation signal. If the timestamps span months randomly, those probably aren't .sorry ransomware files. Could be corrupted backups or something else.

3. Look for the ransom note

Mr_Rot13 drops a note in each affected directory. Common names: 

find / -type f \( -name "RECOVERY_INSTRUCTIONS.txt" -o -name "HOW_TO_DECRYPT.txt" -o -name "RECOVERY_KEY.txt" -o -name "README_TO_DECRYPT.txt" \) 2>/dev/null

Read one (it's plain text, zero execution risk): 

cat /home/example/public_html/RECOVERY_INSTRUCTIONS.txt

The note will reference a contact email or Tor URL. Save it for incident response and any law enforcement report. Don't contact the address yourself.

4. Cross-check with the Filemanager backdoor

Mr_Rot13 drops a persistent backdoor on top of the encryption pass. Hunt for it: 

find / -type f -name "filemanager*" -executable 2>/dev/null
ls -la /usr/local/cpanel/3rdparty/bin/ | grep -i filemanager
ss -tn 2>/dev/null | grep -E ":(8080|8443|9999|31337|49152)"

If the backdoor is running you'll see a process listening on a non-standard port. The backdoor is what survives. Even if you patched cPanel, the binary stays.

5. Use the free automated detector

We maintain an open-source IOC scanner that runs the above plus 8 other checks. One command: 

curl -sSL https://raw.githubusercontent.com/limo57640-crypto/cpanel-cve-41940-detector/main/detect.sh | sudo bash

Output is colour-coded CLEAN / SUSPICIOUS / COMPROMISED. Read-only, MIT licensed, no signup. Repo: github.com/limo57640-crypto/cpanel-cve-41940-detector.

Can I decrypt my .sorry files?

Almost certainly not, without paying. The encryption is AES-256 with attacker-held keys. No public flaw in the implementation lets you recover the data without the key.

Be very careful of services or individuals claiming to decrypt .sorry files. Most are scams. They collect a fee, then either vanish or pay the ransom themselves and pocket the difference. Legitimate decryption services for active ransomware families are rare. Legitimate decryption for a ransomware family with a clean crypto implementation doesn't exist.

Your realistic options:

  1. Restore from backup. If you have an offline backup from before the encryption date, this is the standard path.
  2. Pay the ransom. Controversial. Success rates are mixed. Many victims pay and never get working keys. Talk to law enforcement first. Some payment addresses are on OFAC sanction lists, which makes payment illegal in addition to risky.
  3. Rebuild from scratch. For most victims this is faster and safer than trying to clean a compromised server.
  4. Wait for a flaw discovery. Sometimes free decryptors get published. Usually months or years later. Not a strategy you can plan around.

What to do right now (by scale)

Match your .sorry file count to one of these:

  • 0 files. Likely safe from this specific attack. Keep the baseline hardening (patch check, IOC scan, firewall review).
  • 1-50 files. Partial compromise. Some directories got encrypted before something interrupted the process. Reboot, attacker bailed, whatever. Treat as full incident response anyway. The backdoor is almost certainly still on the box.
  • 50-1000 files. Substantial compromise. Most data on at least one cPanel account is encrypted. Formal incident response time.
  • 1000+ files. Catastrophic. Most or all customer data is encrypted. Restore from backup is your fastest path out. Rebuild from scratch is your safest.

Whatever the scale: don't delete the .sorry files until you've taken a forensic snapshot. Don't restart services that could overwrite logs. Don't start cleanup before you've scoped what you're cleaning.

Reporting requirements

Depending on jurisdiction and industry, you may have mandatory reporting obligations:

  • EU GDPR: notify supervisory authority inside 72 hours if personal data was affected.
  • US state laws: most states require breach notification when personal information is exposed (timing varies).
  • PCI DSS: notify your acquiring bank if payment card data was affected.
  • HIPAA: notify HHS inside 60 days for health information breaches.
  • CISA reporting (US): voluntary but encouraged for critical infrastructure operators.

Talk to your lawyer before any external statement. Don't publicly disclose breach scope until you actually know it.

Authoritative sources

  • NVD: CVE-2026-41940
  • CISA Known Exploited Vulnerabilities Catalog
  • cPanel Technical Security Release 2026-0001 (2026-04-28)
  • watchTowr Labs technical writeup
  • Rapid7 analyst commentary
  • Shadowserver Foundation honeypot dashboard
  • Censys host telemetry
  • XLab / QiAnXin Threat Intelligence reports

Related guides on Ping7

Need help with cleanup?

If the IOC scanner reports COMPROMISED and you want a second pair of eyes before paying any ransom or rebuilding, our paid services cover scoping ($199), guided cleanup ($399), and full forensic incident response with insurance-grade documentation ($799). Bilingual reports (English and Chinese). Everything source-cited against Shadowserver, Censys, NVD, and CISA KEV.

Details: /cve-repair. 24-hour response. We won't promise decryption. Anyone who does is lying.