Threat Intelligence ยท Last verified 2026-05-16

Mr_Rot13 Filemanager Backdoor: Signatures, IOCs, and Detection

The Mr_Rot13 crew is responsible for roughly 44,000 cPanel/WHM compromises during the CVE-2026-41940 zero-day window. They drop a custom Go backdoor called Filemanager with a bcrypt-protected web GUI. The backdoor survives cPanel patching and is the main persistence mechanism operators need to rule out after patching. This guide covers what it looks like, where it hides, and how to confirm clean state.

TL;DR

  • What: cross-platform Go binary. Bcrypt-authenticated web GUI for remote command execution.
  • Who: Mr_Rot13 (named for ROT13 obfuscation in early samples).
  • How it gets in: CVE-2026-41940 gives root-equivalent cPanel access. Backdoor is dropped right after.
  • C2 infrastructure: wrned[.]com, wpsock[.]com, wrned[.]net.
  • Detection difficulty: XLab/QiAnXin calls AV detection rates "extremely low". Static IOC matching is the most reliable approach.
  • Removal: not a single binary. Full server rebuild is the safe path. IOC-only removal is high-risk.

Why patching alone won't help

Every cPanel admin should care about Filemanager separately from caring about the CVE, because installing the cPanel patch doesn't remove the backdoor. If your server was unpatched between 2026-02-23 and the day you actually patched, an attacker may have set up persistence that survives every subsequent cPanel update.

cPanel's auto-update infrastructure (UPCP, queueprocd) doesn't scan for arbitrary non-cPanel binaries. Standard ModSecurity and cphulkd rules won't detect Filemanager because it listens on a custom port and doesn't go through the normal cPanel request pipeline. ImunifyAV signatures have lagged the campaign. Even paid AV products were below 30% detection on VirusTotal samples during the zero-day window.

Binary characteristics

Compilation profile

  • Language: Go. Observed versions 1.20.x and 1.21.x in disassembly.
  • Architecture: amd64 dominant. arm64 samples seen (likely for Apple Silicon targets and ARM-based VPS).
  • Stripped binaries: yes. Debug symbols removed, but Go runtime metadata (gopclntab, type info) stays intact.
  • Size: 8-15 MB. Typical Go static binary footprint.
  • Packed: most samples aren't UPX-packed. Some 2026-Q2 samples have custom packing.

String signatures (forensic markers)

Stripped Go binaries still leak symbol tables and string literals. Useful strings to check in Filemanager samples: 

filemanager
GUI/auth
bcrypt
GUI on port
RECOVERY_INSTRUCTIONS
.sorry
encrypt_pass
exec_cmd
upload_file
download_file

Quick first-pass check on any suspicious binary: 

strings -n 8 binary | grep -iE "(filemanager|bcrypt|wrned|wpsock)"

Network behavior

  • Listening port: configurable. Common values: 8080, 8443, 9999, 31337, 49152, 49999.
  • Authentication: bcrypt-hashed password stored in binary or local config file.
  • C2 callback: outbound HTTPS to wrned[.]com, wpsock[.]com, wrned[.]net.
  • Beacon interval: variable, observed 30-300 seconds.
  • TLS: real Let's Encrypt certs, not self-signed. SNI matches the C2 domain.

Detection methodology

Step 1: Hunt the binary on disk

Common drop paths reported on compromised cPanel servers: 

/usr/local/cpanel/3rdparty/bin/filemanager
/usr/local/bin/filemanager
/tmp/filemanager
/var/tmp/filemanager
/root/filemanager
/home/.filemanager
/opt/filemanager

Recursive search: 

find / -type f -name "filemanager*" -executable 2>/dev/null
find / -type f -size +5M -size -20M -executable -newer /etc/cpupdate.conf 2>/dev/null | xargs file 2>/dev/null | grep "Go BuildID"

The second command is more aggressive. It lists any executable Go binary newer than your last cPanel update, regardless of name. Attackers sometimes rename the binary to kworker or systemd-helper to dodge name-based searches.

Step 2: Check listening sockets

ss -tnlp 2>/dev/null
netstat -tnlp 2>/dev/null

Look for listeners on non-standard ports owned by processes you don't recognise. Legitimate cPanel services listen on documented ports (80, 443, 2082-2087, 2095-2096, 2078-2079, etc.). Anything outside that is suspicious until proven otherwise.

Step 3: DNS resolution check

grep -E "wrned\.com|wpsock\.com|wrned\.net" /etc/hosts /var/named/data/named.run /var/log/messages 2>/dev/null
ss -tn 2>/dev/null | grep -iE "wrned|wpsock"

Active connections to known C2 domains are unambiguous. If the connection list shows ESTABLISHED to one of these, the backdoor is running right now.

Step 4: systemd / init scripts

Persistence usually involves a systemd unit or init script that restarts the backdoor if it gets killed: 

find /etc/systemd/system /etc/init.d /lib/systemd/system -newer /etc/cpupdate.conf -type f 2>/dev/null
systemctl list-units --type=service --state=running | grep -iE "(filemanager|kworker|systemd-helper|netd|sysd)"

Any new unit file written after your last cPanel update is worth a closer look.

Step 5: Cron persistence

crontab -l
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
grep -rE "(filemanager|wget|curl.*\|.*sh|base64.*-d)" /etc/cron* /var/spool/cron 2>/dev/null

Step 6: Process tree inspection

ps auxf | head -100
ps -ef --forest | head -100

Filemanager processes usually run with parent PID 1 (orphaned/daemonised) and have command lines like ./filemanager -d or filemanager -p 8443. Watch for any process whose execution path is in /tmp, /var/tmp, or anywhere outside the cPanel directory tree.

Use the free automated detector

We maintain an automated IOC scanner that runs all of the above (plus 6 others) in one command: 

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

Repo: github.com/limo57640-crypto/cpanel-cve-41940-detector. MIT licensed, read-only, 12 IOC checks, colour-coded CLEAN / SUSPICIOUS / COMPROMISED summary.

Removal: why "just delete it" is dangerous

Finding a backdoor and deleting the binary feels like the move. It isn't, for four reasons that bite people who try it.

  1. Multiple persistence mechanisms. Mr_Rot13 typically deploys 2-3 redundant persistence paths: binary + systemd + cron + ssh authorized_keys. Removing one leaves the others active.
  2. Unknown drops. The attacker had root for days or weeks. They may have backdoored cron jobs, replaced legitimate binaries with wrappers, modified /etc/profile, edited ~/.bashrc, or planted web shells in user public_html directories.
  3. Forensic value lost. Deleting the binary destroys evidence you'll need for incident response, insurance claims, and any law enforcement report.
  4. Re-exploitation. If you haven't also patched CVE-2026-41940 (and CVE-2026-29201/29202/29203 from the May 8 second TSR), the attacker can re-exploit and re-establish persistence quickly. Cleanup without patching is temporary.

The cleanup order that actually works

  1. Forensic snapshot of the entire server before changing anything.
  2. Patch the underlying CVE (cPanel TSR 2026-0001 + 2026-0002).
  3. Reset all credentials: root password, every cPanel user password, all SSH keys, all API tokens, all cPanel API keys.
  4. Audit and rebuild from clean state for the most affected user accounts. Don't try in-place cleanup unless you have very high confidence in scope.
  5. Notify customers per your jurisdiction's breach notification laws.
  6. Long-term monitoring for re-attack. Same group, same techniques, will absolutely come back if you stay reachable.

For most operators, provisioning a new server and migrating audited user data is faster and safer than in-place cleanup. The operational cost is real. The cost of a re-compromise after a partial cleanup is higher.

IOC reference list

File system

/usr/local/cpanel/3rdparty/bin/filemanager
/usr/local/bin/filemanager
/tmp/filemanager
/var/tmp/filemanager
/root/filemanager
/home/.filemanager
/opt/filemanager
*.sorry  (encrypted file extension)
RECOVERY_INSTRUCTIONS.txt
HOW_TO_DECRYPT.txt

Network

wrned[.]com
wpsock[.]com
wrned[.]net
TCP listeners on: 8080, 8443, 9999, 31337, 49152, 49999

Process strings (in memory or binary)

filemanager
bcrypt
GUI on port
encrypt_pass
exec_cmd
.sorry

Behavioral

  • Outbound HTTPS to C2 domains every 30-300 seconds.
  • SSH authorized_keys modifications newer than your last cPanel update.
  • cron entries containing wget/curl piped to bash, or base64 decode chains.
  • cPanel session creation rate spike during the zero-day window.
  • ModSecurity logs showing CRLF injection patterns (%0D%0A) in Authorization headers.

Authoritative sources

  • NVD: CVE-2026-41940
  • cPanel Technical Security Release 2026-0001 (2026-04-28) and 2026-0002 (2026-05-08)
  • watchTowr Labs: technical breakdown of CVE-2026-41940
  • XLab / QiAnXin Threat Intelligence: Mr_Rot13 attribution and Filemanager analysis
  • Censys: 8,859 hosts with .sorry extension files (2026-05-08 dataset)
  • Shadowserver: 44,000 compromised IPs in honeypot data (2026-04-30)
  • Rapid7 advisory and ongoing telemetry
  • CISA Known Exploited Vulnerabilities Catalog

Related guides

Need help with cleanup or incident response?

If the IOC scanner returns COMPROMISED for the Filemanager backdoor, you're in active incident response territory. Our paid services cover scoping ($199), guided cleanup with the runbook executed jointly over a shared session ($399), and full forensic IR with insurance-grade documentation ($799). Bilingual reports. 24-hour response. Every finding cited against Shadowserver, Censys, NVD, and CISA KEV.

Details: /cve-repair. We won't promise complete cleanup of a multi-week dwell-time compromise. That's rebuild territory, and pretending otherwise would be irresponsible. The useful answer is what is feasible and what needs a clean rebuild.