Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

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
Decryptor
No public decryptor

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

  1. 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.

    Sources
  2. AsiaInfo'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.

    Sources
  3. New 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

  1. 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.

  2. 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.

  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.

  4. 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.

  5. 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

Related industries

Similar families

Related questions

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.