Ransomware family
TellYouThePass Ransomware Decryption & Data Recovery
- Active
- Critical
- No public decryptor
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.
- First seen
- 2019-03
- File extensions
- .locked .locked1 .sorry
- Ransom notes
- README.html
- Affected platforms
- Windows / Linux / Databases
Family profile
- File extensions
- .locked
- .locked1
- .sorry
- Ransom notes
- README.html
- READ_ME.html
- READ_ME9.html
- ReadMe.md
- Contact patterns
- Self-hosted domain mailboxes (*.online and similar domains)
- Bitcoin address in the note with a small ransom demand (around 0.1 BTC)
- Tor negotiation page in some builds
- Aliases / versions
- Tellyouthepass、TYTP、TellYouThePass Golang 版、Sorry 勒索病毒、.sorry 变种
- First seen
- 2019-03
- Status
- Active
- Threat level
- Critical
- Affected platforms
- Windows
- Linux
- Databases
- Tags
- Prevalent in China
- Exploits vulnerabilities
- Targets databases
- Active
TellYouThePass uses hybrid RSA + AES encryption, generating a per-host symmetric key protected with an RSA public key. No free public decryptor exists, and there is no corresponding entry in No More Ransom or in vendor decryptor libraries.
Chinese vendor analyses agree that the implementation has no exploitable weakness, so data cannot be recovered at the algorithm level. Response effort should therefore go to backup and snapshot inventory, structure-level repair of large files, locating unencrypted copies, and patching the exploited vulnerability quickly to prevent a repeat deployment. Treat any service claiming it can "directly decrypt .locked files" with strong scepticism.
Latest activity
China's CVERC issued a Sorry alert; AsiaInfo detailed a Linux-focused wave abusing exposed cPanel/WHM panels and CVE-2026-41940 auth bypass, halting SSH and DB services, encrypting in parallel and stealing SSH keys.
SourcesAsiaInfo's deep-dive on Sorry: active since March, note ReadMe.md, MSI payloads hosted on Alibaba Cloud OSS to dodge reputation checks, exploiting Log4j, ActiveMQ and Yonyou NC against MSSQL, ERP/OA and weak-password Linux.
SourcesNew TellYouThePass variant "Sorry": attackers posing as Baiduspider abused a deserialisation flaw in a Chinese finance system's kdsvc interface, probing on 13 Mar and encrypting on 15 Mar, appending .sorry.
Sources
Overview
TellYouThePass was first publicly reported in March 2019 and became highly active in China from the second half of 2020. Its operating logic differs fundamentally from most families: rather than brute force or phishing, it tracks the public disclosure cadence of high-severity vulnerabilities and mass-deploys automatically against internet-facing servers. Documented exploitation includes EternalBlue (MS17-010), Apache Log4j2 (CVE-2021-44228), Shiro deserialisation, remote code execution in Confluence and ActiveMQ, and the PHP CGI flaw CVE-2024-4577 in June 2024.
The China context matters most. It has repeatedly run large campaigns against vulnerabilities in domestic business software: in December 2022, 360 observed exploitation of a Yonyou NC file-upload flaw and arbitrary code execution via NCInvokerServlet; in May 2023 it attacked Yonyou NC servers again; and in June 2023 it exploited a command-execution flaw in the Chanjet T+ finance system disclosed on 8 June, with 360 observing over a thousand servers under attack between 9 and 12 June. Victims are typically smaller companies exposing ERP, finance or OA systems directly to the internet.
On the 2026 .sorry extension - attribution is contested. From March 2026 a wave of attacks appeared that appends .sorry and drops a ReadMe.md note. AsiaInfo's deep-dive report compared static sample features and behaviour chains and concluded it is "a new variant with a strong association to the TellYouThePass family", and the Solar incident-response report republished on CN-SEC likewise calls it highly homologous with this family's .locked variant. CVERC's advisory of 10 August 2026, by contrast, states plainly that the malware belongs to "Sorry, a ransomware family newly seen in 2026", and BleepingComputer, Censys and researcher Rivitna all treat it as a new standalone operation (registered on ID-Ransomware as SorryGo), while Qi'anxin states outright that sources disagree. This site keeps .sorry on both pages without ruling on attribution. That wave's entry point (cPanel/WHM CVE-2026-41940), its Go-based Linux payload, its plain-text README.md and its Tox-only negotiation differ sharply from the .locked campaigns described here; see the Sorry ransomware page for the response detail.
How to identify it
Extension: .locked (some builds use .locked1). Note that ".locked" is shared by multiple families, so the extension alone does not establish TellYouThePass — the Mallox Linux/ESXi variant also uses it.
Ransom note: README.html (some builds READ_ME.html or READ_ME9.html), dropped into each encrypted directory and rendered as a ransom page in a browser. The demand is usually small, around 0.1 BTC in observed cases — a clear contrast with organised RaaS families.
Intrusion artefacts are the more reliable evidence: web middleware logs (Tomcat, Nginx, IIS) showing bursts of requests against a specific vulnerable path followed by web-shell access; Java or PHP processes spawning cmd, PowerShell or bash; new jsp/php/aspx files under the application directory; database processes terminated before encryption; and multiple companies in the same industry running the same software compromised in one window.
Platforms: Windows and Linux, with the Linux build harvesting SSH keys for lateral movement.
Infection vectors
TellYouThePass concentrates almost entirely on exploiting internet-exposed assets: internet-wide fingerprint scanning for targets (specific ERP/OA/finance products, middleware versions, PHP environments); exploitation of a public or in-the-wild vulnerability for code execution; uploading a web shell and loading modules in memory to avoid on-disk detection; reconnaissance and termination of database and security processes; then encryption, with README.html written to disk.
The dangerous property of this family is the time gap. Only one to a few days separate public disclosure from mass deployment — the Chanjet T+ flaw was disclosed on 8 June and large-scale attacks began on the 9th. For organisations whose patching needs approval, testing and a maintenance window, that gap cannot be closed by patching alone; buying time requires reducing exposure — no direct internet mapping for business systems, a WAF, and an access allowlist. The Linux build also harvests SSH keys to move within the segment.
Encryption behavior
TellYouThePass uses hybrid RSA + AES encryption. 360's analysis of the Chanjet T+ campaign described the implementation concretely: a 16-character random GUID serves as the symmetric key, file contents are encrypted with AES, and the GUID is then encrypted with an RSA public key. Other vendors document RSA-1024 with AES-256. Because the symmetric key is asymmetrically protected and unique per host, algorithm-level recovery is impossible without the attacker's private key.
Encryption and destructive behaviour: database processes and services are terminated first; application directories, database data directories, shared folders and reachable mapped drives are encrypted; README.html is written into every encrypted directory; some builds skip critical system directories so the host still boots; the Linux build harvests SSH keys. Windows builds generally clear shadow copies and restore points, though not always successfully, so check host by host.
On intermittent encryption: public sources give no consistent account of how each build handles large files. Response work must verify empirically — take .mdf, .dbf and .ibd files and large archives, analyse the distribution and stride of encrypted blocks, and only then judge repair feasibility.
Assess before you act
Recoverability assessment
There is no public decryptor, and that has to be stated first. No free or official decryption path exists for TellYouThePass, and neither No More Ransom nor vendor libraries list one. Treat any service claiming to decrypt .locked files directly with strong scepticism.
1. Backups, snapshots and shadow copies The most important path. Because dwell time is short and the operation is optimised for fast encryption, destruction of backup infrastructure is often less thorough than with organised families. Check standalone backup servers with no mapped shares and outside the same credential domain, offline media, NAS-native snapshots, cloud object-storage version history with object lock, and hypervisor snapshots.
2. Structure-level repair of large files (verify first) The core asset in an ERP or finance system is the database. For .mdf/.ldf, .dbf and .ibd files, determine first whether encryption is partial and what the block stride is. Depending on how encryption was applied, page-level damage mapping, structural repair and table-level extraction may be possible; if the files are fully encrypted, the path is closed and that must be stated honestly.
3. Business-side data reconstruction (routinely underestimated) ERP, finance and OA data has many side-channel locations: monthly report and ledger exports, filings to tax authorities and banks, reconciliation data held by trading partners, email attachments, printed archives, and interface logs and staging tables on application servers. With log replay these often bring the gap into an acceptable range.
We do not pay ransoms, do not negotiate for clients, and never promise that every file can be decrypted or restored.
Our response plan
Hit by TellYouThePass ransomware? What to do
Step 1: Containment and evidence preservation
Containment here has one extra priority: close the vulnerability first, or the same operators will simply redeploy during recovery. Immediately take the affected application offline or block its internet access, blacklist suspicious source IPs, and disable exposed management interfaces.
Evidence to preserve: web middleware access logs (to locate the exploit requests and web-shell paths), application logs, system and security event logs, bash history and SSH authentication logs on Linux, scheduled tasks and crontabs, newly created jsp/php/aspx files, suspicious processes and memory images, the original README.html notes, and a set of encrypted samples with matching unencrypted originals.
Do not reinstall, do not reformat, and do not keep writing to affected volumes. A common mistake at smaller companies is to "reinstall first and get the business running", which destroys both the vulnerability evidence and the data-recovery option at once.
Step 2: Family identification and locating the exploited entry point
Because .locked is shared across families, identification must run on two tracks.
Family determination: verify the note filename (README.html / READ_ME.html) and its content style, marker structures in encrypted files, and payload characteristics, and distinguish it from the Mallox Linux/ESXi variant that also uses .locked (whose notes and target files are entirely different).
Locating the exploited entry point: this is the core work in a TellYouThePass case. Reconstruct the exploit requests from middleware logs, identify the exact component and version abused (Yonyou NC, Chanjet T+, Log4j2, Shiro, PHP CGI and so on), enumerate every web shell and persistence mechanism written to disk, and check whether the same software is deployed on other hosts — more than one is usually affected.
Encryption analysis runs alongside: sample files of different sizes to determine whether encryption is partial, the block stride, and where damaged structures sit, feeding the repair feasibility assessment in Step 3.
Step 3: Recoverability assessment and recovery planning
After stating plainly that no public decryptor exists, bucket the assessment by path:
- Backup available: verify the availability and recovery point of standalone backup machines, offline media, NAS snapshots, cloud version history and hypervisor snapshots, and confirm they are neither encrypted nor carrying persistence.
- Repair required: sample database files and large business files to produce table- and file-level coverage estimates (depending on how encryption was applied; if files are fully encrypted, say so honestly).
- Business-side reconstruction: work with finance and operations to inventory usable report exports, regulatory filings, upstream and downstream reconciliation data and paper documents, and assess what point in time can be reconstructed.
- Unaffected resources: replicas, reporting databases, test environments, offline endpoints.
- Confirmed unrecoverable: listed explicitly.
Because victims are mostly small companies with thin IT capability, the plan also advises which functions to restore first to get the business moving, not just a technical inventory.
Step 4: Recovery execution
Execution happens in a clean environment where the vulnerability is patched and web shells and persistence are removed, working throughout on read-only images and copies.
- Application rebuild: redeploy the ERP/finance/OA system on a fully patched new host and import the recovered data, rather than bringing the old, backdoored system straight back up.
- Database repair: structural repair and table-level extraction for .mdf/.ldf, .dbf and .ibd files where encryption is confirmed partial, with transaction logs, archive logs and upstream documents replayed to close the delta.
- Files and shares: business-critical directories first, delivered in batches by department.
- Business-side re-entry: load reconstructed reports, reconciliations and documents back into the system by accounting period.
Every batch is reconciled: ledger versus detail checks, sampled key documents, opening and closing balance validation, and application functionality tests. The recovery environment joins the production network only after residual compromise is ruled out.
Step 5: Attribution, hardening and sign-off
The investigation report must state the exploited vulnerability, when it was exploited, web-shell paths and whether they were removed, the lateral scope, whether data was exfiltrated, and how the same software is exposed on other hosts.
Hardening is designed specifically for a vulnerability-driven family:
- Reduce exposure: keep ERP, finance, OA and database systems off direct internet mapping, moving to VPN or zero-trust access with enforced multi-factor authentication; where external access is genuinely required, add a WAF and an allowlist.
- Build a patch-response mechanism: subscribe to advisories from the domestic software vendors in use and from CNCERT, and define an emergency deployment process for critical vulnerabilities — TellYouThePass often deploys within one or two days of public disclosure.
- Asset inventory: enumerate every internet-exposed asset and middleware version and eliminate shadow assets.
- Backup architecture: offline/off-site plus immutable storage, backups physically separated from production, with regular real restore drills.
- Monitoring: web log and web-shell detection, alerting on application processes spawning child shells, and EDR coverage on servers.
The engagement closes with an incident report and a hardening sign-off checklist.
Risk warning
What not to do
- Do not restore the application and reconnect it to the internet before the vulnerability is patched. TellYouThePass deploys by mass scanning, and repeat encryption of the same host is very common.
- Do not reinstall the OS or rebuild the server to "get the business running fast" — vulnerability evidence, web-shell leads and the data-recovery option disappear together.
- Do not trust any tool or service claiming to decrypt .locked files directly. This family has no public free decryptor.
- Do not conclude TellYouThePass from the .locked extension alone; the Mallox Linux/ESXi variant uses the same suffix, and a misidentification sends the whole response in the wrong direction.
- Do not delete middleware access logs or README.html. Middleware logs are the only reliable evidence of the entry point; without them the intrusion path cannot be established.
- Do not pay as the note asks. The low demand makes payment tempting, but it neither guarantees a working decryptor nor addresses the vulnerability that is still open.
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
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.
OA Collaboration System Encrypted by Ransomware
An encrypted OA system halts document circulation, approvals, contract archives, HR and knowledge bases at once — and because OA is so often published to the internet, it is frequently the attacker's first foothold. This page covers its vulnerability profile, the twin-track recovery of attachments and database, and how to check for lateral spread.
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.
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.
Construction and Real Estate Ransomware Response
In construction and real estate the core assets are drawings, models and project documentation — typically scattered across project-site NAS units, shared drives and personal computers with no unified backup. This page covers the sector's threat profile, recovery of drawings and BIM models, and defences for dispersed, multi-project environments.
Similar families
- 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.
- 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
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
Related questions
- First response
What should I do if I've been hit by ransomware?
Isolate first and keep the power on: unplug the network cable or turn off Wi-Fi, but do not reboot, format, delete the ransom note or contact the attackers. Then work in order: confirm it is ransomware and whether it is still spreading, preserve the note, encrypted samples and logs, identify the family, inventory backups and snapshots to assess recovery paths, and report the incident. Do not reconnect restored systems until the entry point is closed, credentials are rotated and backdoors are removed.
- First response
What should we do when a server is hit by ransomware?
Isolate first and do not reboot: cut the affected server off at the switch or in the cloud security group, but leave it running. Then snapshot or image the system and data disks, keep the ransom note and encrypted samples, and check read-only whether shadow copies, cloud snapshots and backups survived. If several servers are down, set a restore order by business dependency, and bring nothing back online until the entry point is closed and every credential has been changed. What can be recovered depends on the family, the encryption mode and the backups.
- 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
TellYouThePass Frequently asked questions
Can .locked files be decrypted?
First establish the family. .locked is shared by several families: TellYouThePass is the most common, but the Mallox Linux/ESXi variant also uses it, and the two require completely different responses. The notes distinguish them — TellYouThePass drops README.html, rendered as a web page, while the Mallox lineage drops text files such as FILE RECOVERY.txt.
If it is confirmed as TellYouThePass: no public free decryptor exists, neither No More Ransom nor vendor libraries list one, and the implementation (a per-host AES key protected by RSA) has no known exploitable weakness. Effort should shift immediately to three things — patch the exploited vulnerability to prevent re-encryption, inventory every potentially surviving backup and snapshot, and empirically test repair feasibility on databases and other large files.
Our Yonyou / Chanjet system was encrypted — is this the same campaign?
Very likely. TellYouThePass has a documented record of large-scale campaigns against vulnerabilities in domestic Chinese business software: in December 2022 it exploited a Yonyou NC accept-interface file-upload flaw and arbitrary code execution via NCInvokerServlet; in May 2023 it attacked Yonyou NC servers again; and in June 2023 it exploited a command-execution flaw in the Chanjet T+ finance system, with 360 observing more than a thousand servers attacked within days.
The signature of such cases: several companies in the same industry hit in the same window, bursts of requests against a specific interface path in middleware logs, and new web shells under the application directory. Beyond recovering data, confirm your own software version and patch state immediately and check whether other instances of the same product are still exposed — there is usually more than one.
Our ERP database is encrypted — how much accounting data can be recovered?
It comes down to the combination of three things.
First, backups. A standalone backup machine, offline media, NAS snapshots, cloud version history or a hypervisor snapshot — any usable one gives a definite recovery point and is the most reliable baseline.
Second, database repair feasibility. This requires encryption analysis of the .mdf/.dbf/.ibd files: depending on how encryption was applied, partial encryption may allow page-level damage mapping and table-level extraction, while full encryption closes this path, which we will state plainly.
Third, business-side reconstruction. ERP and finance data has many side-channel copies: month-end reports, filings to tax authorities and banks, reconciliation statements with trading partners, email attachments, paper vouchers, and interface logs and staging tables on application servers. In smaller-company cases the practical value of this is often higher than expected.
Combining all three, most cases can be recovered to a verifiable accounting period, with the residual gap closed by business re-entry. We provide a plan with coverage estimates, not a promise that everything comes back.
We patched the server — why were we encrypted a second time?
Three causes dominate. First, web shells and persistence were not removed: the jsp/php/aspx backdoors, scheduled tasks, new accounts or SSH authorised keys left during the first intrusion remain valid, and patching only closes the original vulnerability, not the existing channel. Second, other instances of the same product are still exposed — one host was patched while another was scanned and used to re-enter. Third, lateral movement was never contained; the Linux build harvests SSH keys, letting the attacker spread from any already-controlled host.
The correct approach: eliminate persistence (audit new files under web directories, scheduled tasks and crontabs, services, accounts and SSH authorized_keys item by item), rebuild the application on a clean host rather than restarting the old one, take a full inventory of internet-exposed assets, and maintain strict access control and monitoring on the affected segments throughout recovery.
The ransom is only about 0.1 BTC — isn't paying cheaper?
We do not pay ransoms, do not negotiate for clients, and do not recommend paying independently. A low demand is tempting, but consider the following: payment is no assurance of a working decryptor, since mass-deployment operators do not maintain "customer service" and broken decryptors or mismatched keys are common; the vulnerability is still open, and re-encryption after paying is especially frequent with this family; and sending funds to an overseas criminal operation creates compliance and legal exposure while marking the company as willing to pay.
The more effective investment: patch immediately, remove web shells, inventory backups and snapshots, assess database repair feasibility, and start business-side data reconstruction in parallel. In most cases that combination offers greater certainty than betting on a decryptor.
Sources
- 360:Tellyouthepass 勒索软件利用财务管理系统漏洞发动规模性入侵
- 安全客:Tellyouthepass 活跃攻击预警(用友 NC 等漏洞利用)
- CrowdStrike: TellYouThePass Ransomware Analysis Reveals Modern Reinterpretation Using Golang
- Imperva: CVE-2024-4577 quickly weaponized to distribute TellYouThePass Ransomware
- BleepingComputer: TellYouThePass ransomware revived in Linux, Windows Log4j attacks
- 亚信安全:Sorry 勒索软件深度分析报告 — TellYouThePass 家族新变种的威胁演进与立体防御(.sorry 归入本家族的一方)
- 国家计算机病毒应急处理中心:关于「Sorry」勒索病毒的预警报告(将 .sorry 判定为 2026 年新出现的独立家族)
External links are provided for reference only. The content is published by third parties and does not represent our position.
Updated