Ransomware family
Sorry Ransomware Decryption & Data Recovery
- Active
- Critical
- No public decryptor
Sorry is Go-based ransomware that broke out in 2026. It first mass-hit internet-facing Linux web servers through the cPanel/WHM authentication bypass CVE-2026-41940, appending .sorry and dropping README.md; from September a .ths variant with a hello.txt note was pushed through a remote-access software flaw onto Windows hosts in China, with thousands of victims in the first wave. Negotiation runs only over Tox. Attribution is contested: AsiaInfo and Solar treat it as a new TellYouThePass variant, while China's CVERC and Western researchers treat it as a new 2026 family.
- First seen
- 2026-04
- File extensions
- .sorry .ths
- Ransom notes
- README.md
- Affected platforms
- Linux / Windows / Databases
Family profile
- File extensions
- .sorry
- .ths
- Ransom notes
- README.md
- hello.txt
- Contact patterns
- Tox / qTox encrypted chat, with a fixed Tox ID embedded in the note
- Tor (.onion) hidden service for C2 check-in, separate from the negotiation channel
- The note is identical across victims in a campaign - no per-victim ID, no built-in cryptocurrency address
- No mailbox and no web negotiation portal - manual negotiation only
- The .ths variant's hello.txt asks 0.025 BTC per server and still offers only qTox; the qTox ID published by 360 begins 7584478F2ACF
- Aliases / versions
- Sorry Ransomware、SorryGo、.sorry 勒索病毒、TellYouThePass .sorry 变种(部分厂商归类)、.ths 勒索病毒(2026 年 9 月起的新变种)、hello.txt 勒索病毒
- First seen
- 2026-04
- Status
- Active
- Operational status
- Actively operating
- Threat level
- Critical
- Affected platforms
- Linux
- Windows
- Databases
- Tags
- Prevalent in China
- Active
- Exploits vulnerabilities
- Double extortion
- Targets databases
There is no free public decryptor for Sorry. The family is not listed on No More Ransom, and no vendor or law-enforcement agency has released a tool for .sorry files.
The key scheme has no known implementation weakness: a randomly generated symmetric key is wrapped with an embedded RSA-2048 public key and written into the file header, and the plaintext key never touches disk. Public analyses differ on the granularity - the variant reversed by Topsec uses a separate key per file, while another write-up records a per-victim master key with per-file nonces - but every account agrees the outer wrap is RSA-2048. Researcher Rivitna stated publicly that decryption is impossible without the corresponding RSA-2048 private key, and CVERC's 10 August 2026 advisory says that without the decryption key there is currently no reliable way to recover the data.
Recovery effort should therefore go into backups and snapshots, unencrypted copies and log replay, and forensic extraction of residual regions in large files. CVERC also warns specifically about "dedicated .sorry decryption tools" advertised through search engines and shopping platforms, which carry a real risk of a second infection.
The .ths variant cannot be decrypted either. From September 2026 the .ths variant switched its key scheme to X25519 plus XChaCha20-Poly1305 (previously RSA plus AES-GCM). 360's analysis concludes that files cannot be decrypted without the operators' private key, and Huorong's advisory adds that keys differ between victim hosts, so a sample or key from one machine cannot restore the others. Services already advertising .ths decryption should be treated as high risk.
Latest activity
360's September report: Sorry ranked third among ransomware infections in China at 7.58%, with the .ths variant still spreading.
Sources360 disclosed a new Sorry variant: .ths extension, hello.txt note, X25519 + XChaCha20-Poly1305. Thousands hit on 20-21 Sep via a remote-access software flaw; shadow copies are left intact.
SourcesHuorong warned of a .ths outbreak: operators used SQL injection in Gnway-related systems to run commands and drop the ransomware. Keys differ per host, so samples cannot unlock files in bulk.
SourcesChina's Ministry of Public Security cyber police named Sorry and Weax as the most active ransomware families, with manufacturing, trade, healthcare, education and tech firms hit and files renamed .sorry or .wxx.
SourcesCVERC issued a national advisory on Sorry after multiple incidents in China: Go-based, hitting internet-facing Linux web servers via a cPanel flaw, stealing data before encrypting and spreading over weak SSH logins.
SourcesBleepingComputer reported cPanel flaw CVE-2026-41940 mass-exploited to deploy the Sorry Linux encryptor; Shadowserver counted 44,000+ compromised cPanel IPs. Researchers confirmed no decryption without the RSA-2048 key.
Sources
Overview
Sorry is ransomware that broke out in 2026. Written in Go, it targets internet-exposed Linux web servers almost exclusively (whether it counts as a family of its own is disputed - see below), and its scale is tied to one vulnerability: the cPanel / WHM (including DNSOnly) authentication bypass CVE-2026-41940 (CNNVD-202604-5641, CVSS 9.8), exploited as a zero-day from late February 2026 and hit far harder once the patch shipped at the end of April. On 2 May 2026 BleepingComputer reported mass exploitation to deploy the Sorry Linux encryptor, citing Shadowserver figures of at least 44,000 compromised cPanel IP addresses. On 10 August China's National Computer Virus Emergency Response Center (CVERC) issued a national advisory confirming multiple domestic incidents, and on 4 September a cyber-police advisory carried by People's Daily named Sorry and Weax as recently very active, listing manufacturing, trade, healthcare, education and technology victims.
This is an opportunistic, volume-driven operation: internet-wide scanning followed by batch deployment. Small-company websites, web application servers, finance and ERP servers, and cloud instances take the brunt. CVERC notes the payload runs on most mainstream Linux distributions used in China, including domestic (Xinchuang) systems, and spreads on its own - one compromised edge server can become a network-wide event.
Attribution is contested, and this page states both readings. For "a new TellYouThePass variant": AsiaInfo's May 2026 report, titled as a deep analysis of "a new TellYouThePass variant", compared static sample features and behaviour chains and concluded the samples are "a new variant with a strong association to the TellYouThePass family", a position its August report on the Linux wave keeps (detection name Ransom.Linux.YSORR.THEOEBF); a March report by the Solar incident-response team, republished on CN-SEC, likewise calls it "highly homologous" with this family's .locked variant, though without a code-level comparison. For "a separate new family": CVERC's 10 August advisory states plainly that the malware "belongs to Sorry, a ransomware family newly seen in 2026"; BleepingComputer, Censys and ThreatLocker all covered the campaign without linking it to any known family; researcher Rivitna judged it "not HiddenTear, but a new ransomware developed in Go"; and Amigo-A registered it separately on ID-Ransomware as SorryGo (Sorry 2026). Qi'anxin's report simply notes that "some public analyses associate it with TellYouThePass or Phobos, and sources disagree". 360's March advisory offers a third reading again: the tradecraft resembles TellYouThePass while the note format looks closer to WormHole. The practical conclusion: attribution is unsettled, response should not depend on the family label, identification and recovery decisions must come from the sample in hand, and reports to third parties should record both readings.
September 2026: back as .ths. On 28 September 360's anti-ransomware team disclosed a new Sorry variant: the extension changed from .sorry to .ths, the note was renamed hello.txt, and the cipher suite moved from RSA plus AES-GCM to X25519 plus XChaCha20-Poly1305, with the rest of the logic unchanged. The first wave of victims was encrypted overnight on 20-21 September, with thousands of infections and the campaign still running; 360 traced the attack chain to "exploitation of an enterprise remote-access product". Huorong's advisory of 24 September points the entry at SQL injection in systems related to Gnway (金万维): the operators used it to run commands, gain a foothold and then drop the ransomware. The sample 360 published lands at C:\Users\Public\dbg.exe, so this wave hits Windows hosts and is a different build from the Linux cPanel wave that began in May. A 25 September report by the Solar incident-response team says the qTox ID is the same in the old and new notes and reads the variant as Sorry (TellYouThePass family) returning under a new name - "ths" being a common shorthand for TellYouThePass. In 360's September report Sorry ranked third among infections in China at 7.58%.
Separately, a 2018 HiddenTear campaign also appended .sorry and is unrelated to this wave. As of October 2026 Sorry runs no public leak site and offers no automated decryption portal - negotiation is manual over Tox, although the .ths note now states a price of 0.025 BTC per server.
How to identify it
Extension and note. The .sorry suffix is appended to the complete original filename, so order.sql becomes order.sql.sorry. A README.md is written into every encrypted directory carrying a fixed Tox ID and instructing the victim to install qTox. Within a campaign the note is essentially identical for every victim - no per-victim code, no Bitcoin address, no web negotiation portal.
Host-side symptoms, usually noticed before the extension.
- SSH is forcibly stopped (systemctl stop sshd, service ssh stop and two more variants, run through both /bin/bash and /bin/sh to cover different distributions), so the first report is typically "we suddenly cannot SSH into the server".
- Database processes are killed with pkill -9, so the application breaks before anyone notices the files.
- The malicious process masquerades under a common sshd process name.
- Executables named .sorry_ plus eight random characters appear under /tmp, alongside a matching .log file.
- Outbound Tor connections to an .onion address are present.
File structure. Encrypted files carry a fixed-length header holding a magic value, a truncated fragment of the original filename and the RSA-wrapped key block, so they are slightly larger than the originals. The header length varies by build: the August variant reversed by Topsec uses 288 bytes (0x120), while another public analysis of the May cPanel campaign records a roughly 2KB header - so the actual sample decides.
Telling this wave apart from the older TellYouThePass .locked campaigns. Some vendors file this activity as a new TellYouThePass variant, yet the observable differences are substantial. The .locked campaigns ship both Windows and Linux builds, drop README.html or READ_ME.html rendered as a web page, embed a Bitcoin address with a small demand around 0.1 BTC, take contact through self-hosted domain mailboxes or a Tor page, and get in through application-layer flaws in products such as Yonyou NC, Chanjet T+, Log4j2 or PHP CGI. This .sorry wave is a 64-bit Linux ELF written in Go and obfuscated with Garble, drops a plain-text README.md (AsiaInfo records the name as ReadMe.md), carries no payment address and only a fixed Tox ID, and enters through cPanel/WHM CVE-2026-41940 followed by weak-password SSH movement inside the network. Note also that a separate March 2026 wave in China - fileless HTA/VBScript delivery on Windows with shadow-copy deletion, per the Solar and 360 reports - also appended .sorry and is not the same payload as the Linux cPanel wave. Seeing ".sorry" therefore does not by itself make this page's response applicable; establish which payload you are holding first.
The .ths variant (from September 2026). Files get .ths appended to the full original name (license.zip becomes license.zip.ths) and hello.txt is written into every directory - close to a hundred thousand copies on a single host. The note asks 0.025 BTC per server, gives a qTox contact and, if that fails, "suggests" going through a data-recovery company or an online marketplace. Typical first reports are accounting ledgers that will not open, ERP clients that cannot reach the database, and backups and office documents carrying .ths. On the host, check the indicators 360 published: the payload path C:\Users\Public\dbg.exe (72,704 bytes, SHA256 4e93fb51de8f05622b5edff8c6cec9cc8660049157c88ad4f53572e7d4d16c55), with a process claiming to be Microsoft's "Photos Agent Service" while carrying no icon and no digital signature. Do not confuse it with .thx, which researchers attribute to the Dharma family.
Bottom line. The .sorry extension plus a same-directory README.md plus a Tox ID plus a 64-bit Linux ELF payload identifies the Linux wave that began in May; the .ths extension plus hello.txt plus a dbg.exe-style payload on a Windows host identifies the .ths variant that began in September. Be aware that several Chinese data-recovery blog posts describe .sorry as "RDP brute force on Windows with sparse encryption", which contradicts every authoritative sample analysis: all publicly confirmed samples are 64-bit Linux ELF binaries and the encryption is not intermittent. Attribution must come from the actual sample, because it decides whether structural repair is on the table at all.
Infection vectors
Initial access. Operators abuse the WebPros cPanel / WHM authorisation bypass CVE-2026-41940 to obtain server administration rights, then drop and run the encryptor with no victim interaction. No phishing and no weak password are needed - only an unpatched control panel facing the internet, which is why it spreads far faster than hands-on-keyboard ransomware.
Environment profiling. The sample builds a unique victim identifier (username, hostname, CPU count, operating system details, active network interfaces) and reports it back over a Tor hidden service.
Clearing the way. Before encryption it stops the SSH service to cut the administrator's remote rescue channel and force-kills database, security and backup services - freeing file handles and sharply narrowing the response window.
Data theft. CVERC lists exfiltration as a distinct stage: business data, configuration files and internal documents are stolen in bulk before encryption. No public leak site has been observed, so what happens to that data afterwards is opaque - "it has not been posted" is not evidence the data is safe.
Lateral movement, the part most often underestimated. Internal SSH services are scanned and brute-forced concurrently with a built-in weak-password dictionary (public analyses do not enumerate the ports, so cover both the standard port and custom ones) (entries such as user@123, 1234 and 2024-2026). On success the payload is uploaded over SFTP into the remote /tmp directory, marked executable and started with nohup, and each newly compromised host repeats the full chain. Response must therefore never stop at the server that was exploited: wherever internal Linux hosts share credentials or use weak ones, the infection walks across them over SSH.
The .ths variant comes in another way. This wave does not use cPanel. 360 describes "exploitation of an enterprise remote-access product", reusing an earlier flaw in a product it names only as "某万维", and Huorong's advisory specifies SQL injection in Gnway-related systems. Small and mid-sized Chinese firms commonly use such remote-access gateways to let remote staff reach finance and ERP systems, so a breach puts the operators right next to the most valuable data. 360 notes that the .ths payload does not spread on its own - the operators deploy it host by host through access they already hold - but it does scan for and encrypt mapped network drives, so file servers and shares can be damaged without being breached directly. Scope the investigation to every host behind the same remote-access gateway.
Encryption behavior
Engineering quality. The samples are 64-bit Linux ELF binaries written in Go and obfuscated with Garble, with over 99% of symbols destroyed.
Hybrid key scheme. A random symmetric key from Go's crypto/rand is wrapped with an embedded RSA-2048 public key under PKCS#1 v1.5 and written into the file header; the plaintext key exists only briefly in memory. Both the symmetric cipher and the key granularity differ between reported samples: BleepingComputer and researcher Rivitna describe ChaCha20 in the May cPanel campaign builds with a per-victim master key and per-file nonces; the variant Topsec's Alpha Lab captured in August used AES-256-GCM over 64KB chunks with a separate key per file; CVERC's advisory simply says AES. Several build branches most likely exist, but all sources agree on the RSA-2048 outer wrap.
Not intermittent encryption - and this drives recovery strategy. Directories are walked concurrently and any file matching the built-in extension whitelist (84 entries in the variant Topsec reversed) is encrypted in full, streamed rather than partially, with GCM providing block-level integrity checks. That is fundamentally different from partial-encryption families such as Rhysida or LockBit: the ciphertext leaves no intact regions for page-level database extraction, so "repair what intermittent encryption missed" is not available here.
Deliberate destruction of recovery paths. After encryption the sample reopens the original with O_WRONLY and overwrites it with crypto/rand data - 1MB for files under 10MB, 5MB for files of 10MB or more - then forces the write to disk. This is an explicit anti-forensics design.
Platform coverage. Linux has no volume shadow copies to delete, so the same effect is achieved by stopping services and killing processes. The cPanel wave from May used only Linux encryptors; the .ths variant from September is a Windows build. No ESXi encryptor has been verified by authoritative analysis.
How the .ths variant encrypts. The asymmetric layer is now X25519 and the symmetric layer XChaCha20-Poly1305; 360 says the rest matches the earlier version. Before encrypting, the sample checks the network, collects the computer name, username, IP address and processor count, checks for an analysis environment, creates a mutex to avoid running twice, and tries to stop database processes (including MySQL and related services) so database files can be encrypted. Encryption runs in three passes: 28 database extensions first, then 59 document, image and media extensions, then 357 other extensions; ProgramData, the recycle bin, Windows system folders, node_modules and .git are skipped. 360's analysis states plainly that this variant cannot delete volume shadow copies and advises victims to try restoring from them first - which makes shadow copies the first recovery path to check on a .ths host. Because 360 says the rest matches the earlier version, whether the earlier build's random overwrite of source files survives in .ths is not addressed separately in public analysis and has to be checked on the sample.
Assess before you act
Recoverability assessment
The honest conclusion has to be stated plainly: there is no working decryption route for Sorry today. We do not pay ransoms and do not negotiate on a client's behalf; our work is technical recovery and forensics. The paths below are ordered by viability, with actual yields determined on site.
1) Official or free decryptor: none exists. The family is not on No More Ransom and no vendor or agency has released a .sorry tool. The key scheme shows no implementation weakness, so without the RSA-2048 private key nothing can be reversed. Treat any third-party tool claiming to decrypt .sorry as high risk.
2) Repair space from intermittent encryption: not applicable here. Sorry encrypts whitelisted files end to end with integrity checking, leaving no intact regions. MySQL ibd files, PostgreSQL data files, backup archives and virtual disks cannot be approached with page-level extraction. Saying so early prevents wasted response time.
3) Backups, snapshots and copies: currently the primary source of recovery. Inventory offline and offsite backups; host or storage-layer snapshots (LVM, ZFS/Btrfs, NAS/SAN volume snapshots); cloud disk snapshots and custom images; copies on a backup server the SSH spread never reached. The family stops local backup agents but generally cannot destroy remote snapshots or immutable object-storage copies. Never reattach backup media to a network that has not been cleaned.
4) Unencrypted copies and log replay: frequently overlooked, often decisive. MySQL binlog and PostgreSQL WAL, read replicas and DR instances, static asset copies in object storage or a CDN, source and configuration in Git repositories and CI artifacts, ERP and OA archive exports, and reconciliation data held by upstream or downstream systems can all support point-in-time reconstruction. Because the encryptor only processes whitelisted extensions, whatever it skipped is worth reviewing too.
5) Low-level carving: limited but worth assessing. The random overwrite of source files is capped in length (1MB for files under 10MB, 5MB for files of 10MB or more). For files far larger than that threshold, the portion beyond the overwritten length may survive as unallocated blocks after the original is released, which creates an opening for structure-guided extraction. Success depends on the filesystem, how much was written after compromise and whether TRIM is enabled. It is a case-by-case path with no ratio promised in advance, and it requires stopping all writes to the affected volumes immediately.
The .ths variant (Windows) changes the order. Check shadow copies first: 360 confirms the variant does not delete them, so "Previous Versions", system restore points and VSS snapshots on Windows servers and workstations are the top priority - provided nobody runs disk cleanup, turns off system protection or writes heavily to the system volume until they have been checked. Next come backups held outside the remote-access gateway: the automatic backup folders of finance and ERP software often sit on the same machine, so confirm whether the first pass (database extensions) reached them; offsite backups, version history in cloud sync, and document data held by upstream and downstream systems are also usable. Files on network drives should be judged against the file server's own snapshots.
We deliver a verifiable assessment and a clearly bounded recovery scope; actual yields are measured on site and never promised in advance.
Our response plan
Hit by Sorry ransomware? What to do
Containment and forensic preservation
The first priority is cutting propagation, not restoring service. Take the internet-facing cPanel/WHM management ports offline, isolate affected Linux hosts from the internal network, and temporarily block internal SSH between servers. Do not reboot, power off or reinstall - memory-resident processes, Tor connections and key material vanish permanently if you do. Take the affected volumes read-only and create disk images or storage snapshots, export cPanel/WHM access logs, auth.log or secure, web access logs and egress flow records, and preserve three to five .sorry files plus the original README.md for analysis.
Family identification and sample analysis
Confirm the family from the .sorry extension, the Tox ID in README.md and the encrypted-file header, then pin down the build branch: the header length and magic, whether the symmetric cipher is ChaCha20 or AES-256-GCM, and which directories fell outside the extension whitelist. In parallel, hunt for .sorry_ payloads and logs under /tmp to establish whether this host was exploited directly or received the payload over internal SSH. That answer determines whether the investigation covers one server or the whole Linux estate. If the files end in .ths with hello.txt notes, switch to the Windows branch: match the indicators 360 published, such as C:\Users\Public\dbg.exe, review the access logs of Gnway or other remote-access gateways, and confirm straight away whether shadow copies are intact.
Recoverability and exfiltration assessment
With decryption off the table, assessment splits into two tracks. Recovery: inventory offline backups, LVM/ZFS and NAS/SAN snapshots, cloud disk snapshots and images, read replicas, MySQL binlog and PostgreSQL WAL, and unencrypted copies in object storage and Git repositories, then run sample restores against the critical databases; for files above the overwrite threshold, evaluate whether carving is feasible. Impact: use egress flow data and web logs to bound the exfiltration window, data types and volume, which drives regulatory reporting and customer notification. Execution begins only after the written assessment is signed off.
Rebuild and recovery execution
Hosts breached through the vulnerability should be rebuilt rather than cleaned - the operators held full administrative rights and residual web shells or backdoors cannot be enumerated exhaustively. All work happens on images or copies with originals kept read-only. Restore in business priority order: identity and jump hosts first, then databases and ERP, then web and file services. For databases, combine the most recent full backup with binlog or WAL replay to push the recovery point as close as possible to the moment before encryption. After each batch, run integrity checks and business verification - reconciliation, report comparison, interface testing - and record everything in a traceable manifest.
Attribution, hardening and handover
Reconstruct the full kill chain: cPanel/WHM version and patch state, the time of first exploitation, payload landing paths, and which hosts and credentials the SSH spread hit. Hardening is highly specific here. Upgrade cPanel, WHM and WP Squared to the vendor's current release and bring them into a standing patch window. Keep management consoles, remote administration and database ports off the public internet, reaching them through VPN or a jump host with source allowlisting and multi-factor authentication. Disable SSH password authentication in favour of keys, restrict port exposure and alert on failed logins. Eliminate shared credentials across hosts. Rebuild backups to a 3-2-1 design with immutable and offline copies, and rehearse restoration. Retain logs for at least six months. Close with an incident report and a formal handover checklist.
Risk warning
What not to do
- Do not reboot, power off or immediately reinstall affected servers - memory-resident processes and connections are key evidence for attribution and for bounding the data loss, and a reinstall destroys any chance of extracting residual regions from large files.
- Do not download or run any "dedicated .sorry decryptor", and do not install the encrypted messaging client the attackers request; CVERC has explicitly warned that these tools and services carry a second-infection risk.
- Do not delete the README.md note or the encrypted samples, and do not rush to have antivirus "clean everything up" - they are the only basis for identifying the build and assessing the exfiltration scope.
- Do not restore host-to-host connectivity or reattach the backup server before the extent of the SSH lateral movement is established; the family keeps spreading over weak SSH credentials and kills backup services.
- Do not run fsck, rebuild RAID, expand or migrate on the original volumes, and do not write large amounts of new data to the same storage - those writes overwrite residual blocks that may still be recoverable.
- Do not contact the operators through the Tox ID in the note or pay the ransom on your own; payment neither ensures a usable private key nor proves that stolen data was destroyed.
- On a .ths host, do not run disk cleanup, turn off system protection, reinstall or write heavily to the system volume before checking shadow copies - they were not deleted, and they are the most realistic recovery source in this wave.
Emergency response
Data already encrypted? Stop and let an engineer look first
We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.
Related scenarios
File Servers and NAS Encrypted by Ransomware
When shared folders on a file server or NAS are encrypted, drawings, contracts, archives, quotations and design sources all become unusable at once — and mapped drives spread the impact to every endpoint. This page covers how to gauge spread, what shadow copies and snapshots realistically offer, and how to sequence recovery by business value.
Database Encrypted by Ransomware
When database files are encrypted, every business system that depends on them stops at once. This page explains how we triage an encrypted database, how recoverability is assessed, and when file repair, backup-plus-log restore, or rebuild is the right path.
MySQL / MariaDB Database Encrypted by Ransomware
When MySQL's ibdata1, .ibd and .frm files are encrypted, websites, online stores, OA and other web workloads all go down. Most cases start at a web application flaw or an exposed management panel. This page covers what InnoDB's file layout means for recovery, the value of binlogs, and the correct sequence.
ERP System Encrypted by Ransomware
An encrypted ERP is not a single broken database: the application tier, database, attachments and interfaces fail together, halting finance, procurement, production and inventory. This page covers the vulnerability entry points seen in Chinese ERP deployments, the order in which the four tiers are recovered, and how account sets are reconciled at sign-off.
Related industries
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Retail and E-commerce Ransomware Response
In retail and e-commerce, ransomware translates directly into an inability to sell: order systems, membership, POS and warehouse fulfilment stop together and losses accrue by the hour. This page covers the sector's attack patterns, a recovery order built around the order-to-fulfilment chain, and handling of member data exposure.
Education and Research Ransomware Response
Schools and research institutions run open networks with dispersed endpoints and systems built across many eras, often unattended at night and during holidays — a combination attackers exploit. This page covers the sector's threat profile, recovery priorities for academic and research data, and defences suited to campus networks.
Similar families
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
- No public decryptor
Weaxor
Weaxor emerged in late 2024 as a same-lineage successor to Mallox, continuing its focus on MS SQL Server and exposed web services. It appends .rox, .weax or .wxx and drops a RECOVERY INFO.txt note. It has led infection volume in China through 2025 and 2026 (45.45% in July 2026, 65.74% in August 2026) and has no public decryptor.
- Some versions decryptable
Mallox
Mallox (also known as TargetCompany) breaks in mainly through brute-forced MS SQL Server credentials, targets database servers specifically, and has a Linux/ESXi variant. Files encrypted between 2023 and early 2024 may be decryptable with Avast's free tool; later builds have no public decryption method.
Related questions
- Systems & software
What should we do when a Linux server or BT Panel is hit by ransomware?
First work out which kind of incident you have: website and database files that have genuinely been encrypted (new extensions, ransom notes in the directories), or databases that were dropped and replaced with a ransom table. The second involves no encryption, nobody can prove beforehand that the attacker kept a copy, and paying is not a recovery path. In both cases cut public access but keep the host running, do not reinstall or keep restarting the database, snapshot or image the data partition, then look for the data in backups, binlogs and disk remnants - and remove every back door before going live again.
- Systems & software
What should we do when Guanjiapo or Suda account sets are encrypted by ransomware?
Isolate the server holding the account sets from the network but keep it powered on. Do not reinstall the accounting software, restore an account set over the original disk, or run decryptors from the internet. Guanjiapo, Suda, Chanjet T+ and T3, Kingdee KIS Professional and similar products mostly keep account sets in SQL Server, with built-in automatic backups on the same machine, so both tend to be encrypted together. How much comes back depends on the family and how it encrypted, whether a clean backup exists beyond that server, and whether the database files were only partly encrypted. After recovery, reconcile stock, receivables and payables line by line, and close the entry point before going back online.
FAQ
Sorry Frequently asked questions
Files now end in .ths and every folder has a hello.txt - what ransomware is this, and can it be decrypted?
This is the variant of Sorry ransomware that appeared in September 2026. 360's analysis confirms the extension changed from .sorry to .ths, the note was renamed hello.txt and the cipher moved to X25519 plus XChaCha20-Poly1305; the first wave hit overnight on 20-21 September with thousands of infections, entering through a flaw in enterprise remote-access software, which Huorong's advisory ties to SQL injection in Gnway-related systems. Without the private key the files cannot be decrypted, and Huorong adds that keys differ from host to host. There is one realistic recovery path, though: 360 confirms the variant does not delete volume shadow copies. Hold off on disk cleanup and reinstalls, check Windows Previous Versions and VSS snapshots as soon as possible, then look at the automatic backups of finance and ERP software, offsite backups, and snapshots on the file servers behind any mapped drives.
Can .sorry files be decrypted?
Not today. Sorry generates a fresh random symmetric key per file, wraps it with an embedded RSA-2048 public key and stores it in the file header. The scheme has no known implementation weakness, so without the operators' private key nothing can be reversed. The family is not listed on No More Ransom, no vendor or agency has published a decryptor, and CVERC's advisory states that without the decryption key there is currently no reliable recovery method. The right move now is to put resources into backup and snapshot verification, log replay and exfiltration impact assessment rather than hunting for a decryption tool.
SSH suddenly stopped working and all databases are down - is this Sorry?
That is a very typical early symptom. Before encryption begins, Sorry performs anti-response actions: it force-stops the SSH service through several commands covering different distributions' service managers, and kills database processes with pkill -9, both to cut the remote rescue channel and to free file handles. Many organisations first receive a "the application cannot reach the database" ticket and only later notice the .sorry extension. Log in via out-of-band management or the console to confirm, check /tmp for executables and logs beginning with .sorry_ and for outbound connections to an .onion address, and isolate internal SSH connectivity before investigating further.
Only one web server was hit - do we need to check the other Linux hosts?
Yes, and quickly. Sorry moves laterally on its own: it scans internal SSH services (standard and custom ports alike), brute-forces them concurrently with a built-in weak-password dictionary, uploads the payload over SFTP into the remote /tmp directory and starts it in the background with nohup, after which the new host repeats the whole chain. Wherever hosts share credentials or use weak ones, the infection keeps walking across them - in many engagements several internal hosts are already compromised by the time the entry point is identified. Focus on /tmp across every Linux host, unusual successful logins in auth.log or secure, unexpected nohup processes and outbound Tor connections.
We have no backups - is there any chance of recovering .sorry files?
Limited but not zero, and it has to be judged case by case. Work through host and storage-layer snapshots (LVM, ZFS/Btrfs, NAS/SAN volume snapshots), cloud disk snapshots and custom images, read replicas and DR instances, MySQL binlog and PostgreSQL WAL, static copies in object storage or a CDN, and source and configuration held in Git repositories and CI artifacts. Because the encryptor only processes whitelisted extensions, everything it skipped is worth reviewing too. Separately, the random overwrite of source files is capped in length - 1MB for files under 10MB, 5MB for files of 10MB or more - so for files well above that threshold the remainder may survive as unallocated blocks and can sometimes be extracted with structure-guided carving. Whether that works depends on the filesystem, how much was written after compromise and whether TRIM is enabled, so it must be measured. All of it requires stopping writes to the affected volumes immediately.
Is patching cPanel enough to be safe?
Patching is necessary but not sufficient. CVE-2026-41940 was exploited as a zero-day from late February 2026, so many servers were already compromised before the fix shipped. Alongside patching, determine whether you were breached: review cPanel/WHM access logs for anomalous authentication, look for new system accounts and scheduled tasks, suspicious scripts under the web root, unexpected executables in /tmp and outbound Tor connections. Hosts confirmed as compromised should be rebuilt rather than cleaned, because the operators held full administrative rights. Also pull the management console off the public internet, move SSH to key-based authentication and eliminate shared credentials across hosts - otherwise the lateral path stays wide open even with the patch applied.
Is .sorry a new TellYouThePass variant?
There is no settled answer - vendors disagree. AsiaInfo's deep-dive report concluded the samples are "a new variant with a strong association to the TellYouThePass family", and the Solar incident-response report republished on CN-SEC likewise calls them highly homologous with that family's .locked variant. CVERC's advisory of 10 August 2026, however, states that the malware belongs to "Sorry, a ransomware family newly seen in 2026"; BleepingComputer, Censys, ThreatLocker and researcher Rivitna all treat it as a new, standalone operation, and ID-Ransomware registers it separately as SorryGo. Qi'anxin states outright that sources disagree. The checkable facts: this .sorry payload is a 64-bit Linux ELF written in Go that drops a plain-text README.md with a fixed Tox ID and no payment address, entering through cPanel/WHM CVE-2026-41940, whereas the classic TellYouThePass .locked campaigns run on both Windows and Linux with a README.html web-page note carrying a Bitcoin address and a small demand. For a victim organisation the label changes nothing operationally: "no public decryptor exists" holds under either reading, and identification, recovery and exfiltration assessment must all be driven by the sample in hand. Reports to third parties should simply record that both readings exist.
Sources
- 关于「Sorry」勒索病毒的预警报告 — 国家计算机病毒应急处理中心(CVERC)
- Critical cPanel flaw mass-exploited in "Sorry" ransomware attacks — BleepingComputer
- 天融信深度解析:Sorry 勒索病毒逆向分析与防护指南 — 天融信阿尔法实验室
- 网警提醒:防范勒索病毒,记住五件事 — 人民日报(2026-09-04)
- Sorry Ransomware Analysis (CVE-2026-41940 cPanel Campaign) — 社区维护的 IOC / YARA 公开资料包
- CVE-2026-41940 (cPanel / WHM 认证绕过,CVSS v3.1 9.8) — NVD
- Sorry 勒索软件深度分析报告:TellYouThePass 家族新变种的威胁演进与立体防御 — 亚信安全(主张归入 TellYouThePass 的一方)
- Sorry 勒索软件 Linux 变种攻击预警(沿用 TellYouThePass 新变种口径)— 亚信安全
- TellYouThePass 家族新变种 .sorry 针对财务系统发起攻击 — Solar 应急响应团队 / CN-SEC(称与 .locked 高度同源,未给出代码级比对)
- 「Sorry」勒索病毒爆发防御报告与 IOC — 奇安信(明示「不同来源说法不一,最终归属以官方预警与样本逆向结论为准」)
- 360 预警:Sorry 勒索病毒集中开火(手法近 TellYouThePass,勒索信格式近 WormHole)
- SorryGo Ransomware (.sorry extension) 支持贴 — BleepingComputer 论坛(Rivitna 判定为 Go 新家族,ID-Ransomware 单独登记)
- Sorry 勒索软件新变种来袭(.ths、hello.txt、X25519 + XChaCha20-Poly1305、不删卷影副本)— 360 反勒索团队(2026-09-28)
- 2026 年 9 月勒索软件流行态势分析(Sorry 占国内感染 7.58%)— 360
- 紧急预警|.ths 勒索软件活动升温(金万维相关系统 SQL 注入投放)— 火绒安全实验室(2026-09-24,转载)
- Sorry 勒索病毒再度来袭,改名 ths(qTox ID 与旧版一致,0.025 BTC)— Solar 应急响应团队 / CN-SEC
- .ths extension, qTox contact (Windows Server 2019 victim, note wording matches SorryGo) — BleepingComputer 论坛
External links are provided for reference only. The content is published by third parties and does not represent our position.
Updated