Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

MetaEncryptor Ransomware Decryption & Data Recovery

  • Active
  • Medium
  • No public decryptor

MetaEncryptor is a double-extortion crew that has run a dark-web leak site since August 2022. Its encryptor shares lineage with SFile2, and the gang rebranded as LostTrust in late 2023 - yet the original site was never abandoned and has kept posting victims at a low rate through 2026. Public technical data is thin: no confirmed extension, note filename or decryptor.

First seen
2022-08
File extensions
No public information
Ransom notes
No public information
Affected platforms
Windows

Public information on this family is limited. What follows is compiled from the small amount of verified material available, so please contact us for a sample assessment before you act on it.

Family profile

File extensions
No public information
Ransom notes
No public information
Contact patterns
  • Tor (.onion) leak site; public trackers record two mirror domains
  • Tox messenger ID published on the site (recorded by RansomLook)
  • The related LostTrust brand uses an .onion negotiation page
  • No fixed mail domain documented publicly
Aliases / versions
Metaencryptor、METAENCRYPTING(LostTrust 加密器中残留的内部字符串)、LostTrust 前身(SFile / SFile2 同源)
First seen
2022-08
Status
Active
Operational status
Actively operating
Threat level
Medium
Affected platforms
  • Windows
Tags
  • Leak-site regular
  • Active
  • Double extortion
Decryptor
No public decryptor

There is no free public decryptor for MetaEncryptor. The family is not listed on No More Ransom, and no vendor or law-enforcement agency has published keys or a tool for it. The related SFile, SFile2 and LostTrust brands have no public decryption route either.

Just as important: as of 2026-09-11 no major vendor has published a reverse-engineering analysis of a MetaEncryptor-branded encryptor, so whether its crypto implementation has an exploitable flaw is simply unknown. The correct order is to identify the family and build from real encrypted files and the ransom note first, then assess recovery paths - not to run an unverified "MetaEncryptor decryptor" against original disks. For families with no published analysis, such tools are usually follow-on scams or destroy file structures and with them any chance of repair.

Latest activity

  1. Four victims posted in one day - EllisDon (CA), SIFCO Industries (US), ST Engineering (SG) and Hologic (US) - the site's densest posting in two years. Gang claims, not independently confirmed.

    Sources
  2. Trackers re-synced the leak site after months of silence, logging six victims including Japan's Corona Corporation, Germany's MPA Pharma and Weber Water Resources (US); some entries are backfilled older posts.

    Sources

Overview

BleepingComputer dates the MetaEncryptor leak site to August 2022; it accumulated twelve victims through July 2023 and then went quiet. In September 2023 a new brand, LostTrust, appeared using the exact same site template and bio, and its encryptor carried a METAENCRYPTING string. Researchers Stefano Favarato and MalwareHunterTeam concluded LostTrust was a MetaEncryptor rebrand, with both derived from the SFile2 encryptor. The publicly documented lineage runs SFile (February 2020) to SFile2 to MetaEncryptor (from August 2022) to LostTrust (from September 2023). Note that leak-site trackers date the group's first appearance to mid-2023: that is when those platforms began scraping the site - the first twelve victim records all carry the same 2023-08-16 capture date - and it is not the same thing as when the site went live.

Unlike the usual rebrand script, the original site was never retired. Posting continued after September 2023 and through 2024 - five victims went up on 7 May 2024, around nine across that year - then thinned to roughly quarterly entries in 2025, before six records appeared on 23 August 2026 and four more on 7 September 2026. Both batches need care. One of those organisations had already been captured by a different tracker in March 2026, and another record carries a post date of November 2025, so the clustered dates look like backfill after a tracker resumed scraping rather than same-day new attacks. ransomware.live holds 42 entries as of 2026-09-11, concentrated in the US, Germany and Canada, across manufacturing, automotive and transport, professional services and education, with Japanese and Singaporean organisations in the latest batches.

Every entry is a unilateral claim with limited third-party confirmation. One US medical device maker named in September 2026 had already been listed by a different ransomware brand that June and was facing a class action over it, so re-listing of older data cannot be ruled out. This page therefore does not enumerate victim names and does not treat leak-site posts as established fact.

Public information is limited. As of 2026-09-11 no major vendor or CERT has published a sample analysis or IOC set for a MetaEncryptor-branded encryptor, and no Chinese vendor has issued a report on this brand - although the Chinese vendor Rising did document a Linux variant of the upstream SFile branch in late 2021. The operators describe themselves on the site as "a group of young people who identify themselves as specialists in the field of network security with at least 15 years of experience", say the work is purely commercial and deny any link to politics or intelligence services. The same site template states that every incident is notified to all possible press in the region - a line Sophos recorded on the LostTrust site in its December 2023 research on ransomware crews and the media. Media pressure is their main lever. No public record places the MetaEncryptor brand against mainland China organisations, but the Linux and FreeBSD variants of the upstream SFile branch were aimed mainly at Chinese targets, and overseas subsidiaries of Chinese groups sit inside the same target space.

How to identify it

MetaEncryptor has no publicly documented extension or ransom note filename, so extension matching cannot identify it. Attribution currently rests on the extortion side:

  • The organisation appears in a post on the MetaEncryptor leak site (public trackers record two .onion mirrors), with a claimed data volume and a sample pack.
  • Contact is directed to a Tox ID published on the site rather than to email.
  • The site's language stresses the operators' "security specialist" identity, denies political ties, and threatens to notify regional press and seed the data on leak forums.

Related-family artefacts are a comparison reference, not a substitute. The LostTrust rebrand used the .losttrustencoded extension and a !LostTrustEncoded.txt note; earlier SFile2 builds used .sfile2 or .sfile3 with !!FILES_ENCRYPTED.txt. If your files match one of those, they point at that branch, not at the current MetaEncryptor brand.

Preserve three to five encrypted samples, the original note and the surrounding logs, and confirm family and build by reverse engineering and sample comparison. Do not assume network-wide encryption just because a company name shows up on a leak site, and do not self-attribute from a headline - misattribution leads straight to the wrong recovery plan.

Infection vectors

No authoritative report documents MetaEncryptor's full access and lateral movement chain. One verifiable thread comes from HiSolutions' research on CSHARP-STREAMER: a memory-only modular .NET RAT with TCP relay pivoting, PowerShell execution, domain user enumeration and AMSI bypass, observed across intrusions attributed to several crews. The researchers tie its use to the rise in Metaencryptor and LostTrust victim postings from August 2023 and suggest an initial access broker distributes access to multiple ransomware groups - meaning the entry point is likely bought rather than built.

The related SFile and LostTrust branches are publicly recorded as arriving through internet-exposed RDP without MFA and phishing emails with malicious attachments. Combined with the victim profile (mid-to-large manufacturing, professional services, transport and healthcare), treat the list below as a triage priority rather than a confirmed kill chain:

  • Remote access without MFA (VPN, RDP, jump hosts) and known vulnerabilities in edge appliances.
  • Credentials from infostealer logs and resold initial access.
  • Traces of memory-resident RATs and abuse of legitimate remote administration tooling - process injection, anomalous PowerShell, internal relay connections.
  • Credential spread across the domain and reachability of backup systems and hypervisor management interfaces.

Encryption behavior

No public reverse-engineering of a MetaEncryptor encryptor exists. What follows is documented behaviour of the related SFile2 and LostTrust branches - expected behaviour to test against, not confirmed fact for the current brand:

  • A combination of symmetric and asymmetric algorithms encrypts file content, with no key material left in cleartext.
  • Targets include documents, databases, images, audio and video, disk images and archives.
  • System logs are cleared, volume shadow copies deleted and database and security-related processes stopped, closing off local rollback.
  • The note pressures victims with publication of the data if no contact is made within a deadline - classic steal-then-encrypt double extortion.

Whether encryption is intermittent is unknown. No public data says whether only part of each file is overwritten. That single question decides whether large files - databases, virtual disks, mail stores - retain space for structural repair, so the overwritten regions and their proportion must be measured on the real files during forensics rather than assumed from other families.

Platform. Public samples of the MetaEncryptor brand are Windows PE, and no Linux or ESXi encryptor has been publicly confirmed for it. The lineage as a whole is not Windows-only, though: the upstream SFile (Escal) branch gained Linux and FreeBSD variants in late 2021 - documented by the Chinese vendor Rising and by ESET, and confirmed by MalwareHunterTeam - aimed mainly at organisations in China. So do not assume non-Windows hosts are safe: if virtualisation or Linux servers are also affected, establish forensically whether an encryptor ran or the virtual disks were damaged at the host layer.

Assess before you act

Recoverability assessment

Recovery from MetaEncryptor has to be judged case by case. We do not pay ransoms and do not negotiate on a client's behalf; our work is technical recovery, breach impact assessment and forensics.

1) Free decryptor: none. Neither SFile, SFile2, MetaEncryptor nor LostTrust is listed on No More Ransom, and no vendor or agency has released keys. Treat any tool claiming direct decryption with suspicion.

2) Repair space created by the encryption pattern (must be measured). With no public analysis available, the first step is measuring on copies how much of each file was overwritten - header only, a fixed intermittent stride, or the whole file. If large files retain intact regions, page-level extraction and logical rebuilds are worth attempting for databases (MDF/LDF, DBF, ibd), and virtual disks may be repairable enough to mount and extract from. If the overwrite is complete, this path does not exist. The answer comes from measurement, not from a promise.

3) Backups, snapshots and shadow copies. Related builds delete shadow copies and stop backup agents, but offline and offsite backups, storage-layer snapshots on NAS and SAN, hypervisor snapshots, untouched copies on the backup server and cloud version history usually deliver the highest recovery ratio. Never reattach backup media to a network that has not been cleaned.

4) Unencrypted copies and log replay. File-server recycle bins, endpoint caches, reporting and BI staging databases, ERP archive exports, database transaction logs and application audit logs can support reconstruction or point-in-time replay.

5) Low-level carving. If the encryptor writes new ciphertext and deletes originals, source data may survive in unallocated clusters and can be recovered by raw sector scanning - provided all writes to the affected volumes stop immediately.

6) The data-leak side matters just as much. Media and public pressure is this group's main lever, so even with files fully restored you still need scoped leak analysis, an assessment of regulatory notification duties, credential and key rotation, and prepared messaging for customers and supply-chain partners.

We commit to a verifiable assessment and a clearly bounded recovery scope. We never claim complete decryption, and no technique can assure full recovery.

Our response plan

Hit by MetaEncryptor ransomware? What to do

  1. Containment and forensic preservation

    Isolate affected hosts and hypervisors from production networks and storage paths while preserving memory and disk state. Do not reboot or power off - CSHARP-STREAMER, the tooling associated with this crew, runs only in memory, so a shutdown destroys the evidence. Image or snapshot the domain controller, backup server and hypervisor management hosts first, export VPN, edge appliance and Active Directory logs, and preserve three to five encrypted files, the original note and screenshots of the leak site post.

  2. Family identification and encryption analysis

    Because MetaEncryptor has no published extension or note signature, identification must come from the actual samples: compare file trailer markers and encryptor strings (including clues such as METAENCRYPTING) and test for lineage against the SFile2 and LostTrust branches, so that .losttrustencoded and other branches are not misfiled under this brand. In the same pass, measure which regions of the files were overwritten and in what proportion to establish whether structural repair is possible.

  3. Dual assessment: recoverability and leak impact

    Run two tracks in parallel. One inventories backups, storage snapshots, hypervisor snapshots and unencrypted copies, and runs sample repairs on the critical databases and VMs. The other scopes what was exfiltrated and how much - measured against the volume and sample pack claimed in the leak site post - and assesses notification duties arising from personal data, trade secrets and contractual obligations. Deliver a written assessment stating which systems go the backup route, which need structural repair and which rely on carving, with expected recovery ranges and a timeline.

  4. Recovery execution and business verification

    All work happens on images or copies with the originals kept read-only. Restore in business priority order: identity and domain infrastructure first, then core databases and line-of-business systems, then file and mail services. After each batch, run integrity checks and business-side verification - reconciliation, report comparison, application start-up tests - and record everything in a traceable manifest. In parallel, prepare consistent messaging for customers, regulators and press so the response is not driven by the gang's posts.

  5. Attribution, hardening and handover

    Reconstruct the full kill chain: whether initial access was purchased, came through remote entry points without MFA, or arrived as a phishing attachment; where memory-resident RATs and abused administration tooling left traces; and the timing, channel and volume of exfiltration. Remove persistence, rogue accounts, scheduled tasks, services and GPO backdoors; reset credentials domain-wide and enforce MFA on all remote access; segment the hypervisor management network; rebuild backups to a 3-2-1 design with immutable copies. Close with an incident report and a formal handover checklist.

Risk warning

What not to do

  • Do not reboot or power off affected hosts - the tooling associated with this crew runs only in memory, and a shutdown destroys both the implant evidence and the memory-resident forensic trail.
  • Do not download and run a "MetaEncryptor decryptor" against original disks. No public decryption route exists for this family, so such tools are usually follow-on scams or damage file structures.
  • Do not apply another branch's playbook because an extension resembles .losttrustencoded or .sfile2 - different branch, different sample, different recovery path.
  • Do not delete ransom notes, encrypted samples or screenshots of the leak site post, and do not rush to "clean the virus" - this is the primary material for family attribution, leak scoping and later accountability.
  • Do not reattach backup tapes, external drives or the backup server to a network that has not been cleaned; ransomware crews actively hunt and destroy reachable backups.
  • Do not publish conclusions before leak scoping is complete, and do not open the Tox channel on your own. This group leans on media and public pressure, and a hasty statement amplifies the damage.

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

FAQ

MetaEncryptor Frequently asked questions

  • Can MetaEncryptor-encrypted files be decrypted?

    There is no free public decryptor, and none exists for the related SFile, SFile2 or LostTrust branches either. With no published reverse engineering of the encryptor, no claim can be made about exploitable flaws.

    The realistic order of recovery is: backups and snapshots, then structural repair of databases and virtual disks once the overwrite pattern has actually been measured, then unencrypted copies and log replay, then low-level carving. We produce a written assessment from real samples before touching anything, and we never claim complete decryption.

  • What extension does MetaEncryptor use, and how do I confirm it?

    No extension or note filename has been publicly documented for this family, so extension lookup does not work here. Attribution relies on extortion-side indicators - a post on the MetaEncryptor leak site, a Tox contact, the site's fixed script - plus reverse comparison of the actual samples.

    If your files carry .losttrustencoded or .sfile2 / .sfile3, they point at other branches of the same lineage (LostTrust, SFile2), which need their own assessment and differ in the details.

  • Are MetaEncryptor and LostTrust the same crew, and is it still active in 2026?

    Public research broadly says yes. When LostTrust launched in September 2023 it used the exact same leak site template and bio as MetaEncryptor, its encryptor still carried a METAENCRYPTING string, and both derive from SFile2.

    Unlike the usual pattern where the old site is abandoned after a rebrand, the MetaEncryptor site kept going: clustered posts through 2024, roughly quarterly entries in 2025, then six records on 23 August 2026 and four on 7 September 2026. At least one of those had already been captured by another tracker in March 2026 and another carries a November 2025 post date, so the clusters look like backfill after scraping resumed. Taken together this is a leak site that has operated continuously at a low rate for years rather than one that went dormant and came back - which is why this page treats it as active rather than resurgent or defunct.

  • Our name is on the MetaEncryptor leak site but nothing is encrypted - what now?

    Handle it as a data breach first, not as a decryption problem. Start by verifying the claim: compare the volume and sample pack in the post against reality, and check whether the data is yours, a supplier's, historical, or simply a re-listing.

    Then scope what left and when, hunt for remaining persistence and usable credentials, rotate passwords and keys, assess notification duties arising from personal data and contracts, and prepare consistent external messaging. This group states outright that it contacts regional press, and a reactive posture often costs more than the incident itself.

  • Do Chinese organisations face MetaEncryptor, and should we pay?

    No public record places the MetaEncryptor brand against mainland China organisations; its leak-site victims cluster in the US, Germany and Canada, with Japanese and Singaporean entries in the latest batches. That does not make the lineage irrelevant to China: the upstream SFile (Escal) branch shipped Linux and FreeBSD variants in late 2021 that were aimed mainly at organisations inside China, as documented by Rising and ESET. Overseas subsidiaries, cross-border branches and foreign suppliers of Chinese groups are in scope too, and the entry points this lineage relies on - remote access without MFA, resold initial access - are just as common domestically.

    We do not pay ransoms and do not negotiate. Payment cannot ensure a working key, cannot stop the data being published or resold, and can create compliance exposure. The sound move is a technical assessment and leak scoping first, with resources spent on recovery and hardening.