Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

APT73 Ransomware Decryption & Data Recovery

  • Active
  • Medium
  • No public decryptor

APT73 - later operating as Bashe, earlier known as Eraleig / Eraleign - is a data-extortion crew that surfaced in April 2024 with a leak site imitating LockBit. It is best known for claiming breaches it did not carry out and republishing recycled leak data; no encryptor sample or file extension has ever been documented publicly.

First seen
2024-04
File extensions
No public information
Ransom notes
No public information
Affected platforms
Windows

Family profile

File extensions
No public information
Ransom notes
No public information
Contact patterns
  • Tor (.onion) leak site and negotiation pages on bashe-prefixed vanity domains (earlier apt73-prefixed .onion addresses plus the eraleignews.com clearnet site)
  • Leak site imitates the LockBit look and feel; public reporting groups it with actors that mimic established brands
  • Victim entries carry a countdown timer and a staged sample pack
  • No fixed mailbox or Tox ID documented publicly; contact happens only inside the onion site
Aliases / versions
Bashe、Eraleig、Eraleign、ERALEIGNEWS
First seen
2024-04
Status
Active
Operational status
Actively operating
Threat level
Medium
Affected platforms
  • Windows
Tags
  • Emerging
  • Extortion-only
  • Active
Decryptor
No public decryptor

No free public decryptor exists, and strictly speaking there is nothing to decrypt. As of September 2026 we have found no public analysis documenting an APT73 / Bashe encryptor sample, encryption algorithm, file extension or ransom note filename, and the family does not appear in the No More Ransom decryptor catalogue. The group's leverage is publishing - or threatening to publish - data on its Tor leak site rather than encrypting files.

If files on your estate genuinely are encrypted with a rewritten extension, the encryptor almost certainly belongs to a different family and the APT73 name has been misapplied or misreported. In that case, re-identify the family from the actual encrypted samples and ransom note instead of following an APT73 playbook.

Latest activity

  1. The latest leak-site batch was posted in late July, including Thai cloud provider Metrabyte. Around 160 organisations have been named in total, and the group kept a monthly posting cadence into September 2026.

    Sources

  2. APT73 claimed an attack on Gov.br, Brazil's federal government portal, continuing a 2026 pattern of naming government bodies and expanding into Latin America. No independent technical confirmation exists.

    Sources

  3. APT73 listed UK investment platform Hargreaves Lansdown, claiming 658,259 customer records. In June 2026 BushidoToken assessed the breach as fabricated, tracing sample emails to older Verifications.io data.

    Sources

Overview

APT73 surfaced in mid-April 2024, styling itself an "Advanced Persistent Threat". Its onion leak site went live in late April 2024 on apt73-prefixed .onion addresses, alongside the eraleignews.com site run under the Eraleig / Eraleign banner; it later moved to the Bashe name and bashe-prefixed vanity .onion domains (Bashe is generally read as the elephant-swallowing serpent of Chinese mythology, though the group has published no explanation of its own). Published research generally reads the crew as a spin-off started by a former LockBit affiliate after Operation Cronos disrupted LockBit in February 2024, and its leak site visibly imitates the LockBit layout.

Published research rates the crew's technical capability poorly. CloudSEK examined its claims case by case and found it repeatedly claims intrusions it did not perform, repackaging old public leaks as fresh breaches - a 2019 Malindo Air leak, Betclic data drawn from existing combolists, and Federal Bank India data identical to a 2023 forum post were all reposted as new incidents. In June 2026, BushidoToken examined its claimed Hargreaves Lansdown breach - listed in late April 2026 - and assessed with high confidence that it was fabricated. Correlation data on ransomware.live shows that among victim entries that can be tied to a corporate domain, roughly seven in ten line up with infostealer log data rather than hands-on intrusion.

By September 2026 the leak site had named around 160 organisations across some 50 countries, with the most recent batch posted in late July 2026. On ransomware.live's figures the United States and United Kingdom account for the most victims, followed by Brazil, France and Germany; professional services, technology and financial services lead by sector, with government and defence around a tenth of entries. CloudSEK's profile describes mid-sized firms with revenue between USD 10M and 500M in financial services, banking, IT and manufacturing. Public entries tied to China are rare and no confirmed campaign against mainland Chinese organisations has been reported. Public information is limited, so this page covers only what can be verified.

How to identify it

APT73 leaves no extension or note filename to match against - no public report we could find documents an encryptor sample from the group. Deciding whether you have been named by APT73 therefore starts with the leak site, not the endpoint:

  • your organisation's name, logo, executive photographs or org chart appearing on a bashe-prefixed .onion site, with a countdown and a staged sample pack;
  • an email or portal message from "Bashe / APT73" pointing to an onion negotiation page with a deadline;
  • an enquiry from a journalist or threat intelligence vendor about the listing.

The decisive next step is authenticity verification: obtain the sample, compare field structure and record counts against your own systems, check whether the timestamps could correspond to real data you hold, and test whether the emails and phone numbers in it already appear in historical public breach corpora. A substantial share of these listings turn out to be repackaged old leaks or credential-stuffing compilations.

Infection vectors

Public descriptions of APT73's access methods stay generic: phishing email and exploitation of known flaws in internet-facing applications are cited by several vendors, but without sample hashes or verifiable indicators to support them.

A different data point explains the group's material better. Correlation work published on ransomware.live shows that, among victim entries that can be tied to a corporate domain, roughly seven in ten map onto infostealer log data. In other words, much of what is presented as intrusion appears to originate in credentials and stealer logs bought on criminal markets rather than hands-on network compromise. Defensively, that shifts the priority to clearing infostealers from endpoints, rotating SSO and VPN credentials, enforcing multi-factor authentication, and reducing the exposed legacy application surface.

Encryption behavior

No encryption behaviour is publicly documented. As of September 2026 we have found no published analysis of an APT73 / Bashe encryptor binary, algorithm, appended extension or dropped ransom note; even the vendors that have studied this group specifically do not address encryption at all. The "AES-256 plus RSA" wording that appears on some data-recovery vendor pages is boilerplate: it carries no sample hash or reverse-engineering evidence and should not be treated as an identification basis.

All of the group's pressure is applied on the data side: victim names, logos, executive photographs and org charts published on the leak site, a countdown, staged releases, and media amplification intended to trigger regulatory notification duties and customer enquiries.

So when an incident arrives under the APT73 name, the first question is not how to decrypt. It is whether data actually left your environment, what left, and whether it is in fact old data.

Assess before you act

Recoverability assessment

APT73 incidents usually involve no encrypted files at all, so "APT73 ransomware decryption" is the wrong frame. What is needed is a data-exposure assessment and a response plan. We do not pay ransoms and do not negotiate on a client's behalf.

1) Authenticity and ownership verification (first priority). Take the sample published on the leak site and test it against reality: field structure, record counts and timestamps versus your own systems, and whether the emails and phone numbers in it already appear in historical public breach corpora. If the listing is repackaged old data, the response path diverges completely from that of a real intrusion.

2) Scoping genuine exfiltration. Where verification supports that the data is yours, move to logs to establish channel and time window - perimeter and proxy logs, outbound mail and cloud storage records, bulk database export auditing, SaaS download histories. The conclusion must be specific: which tables, which fields, how many records, when.

3) Notification and disclosure obligations. Assess reporting and individual-notification duties under the Data Security Law, the Personal Information Protection Law and sector regulation, and against local rules for cross-border operations. Fix the evidence chain and timeline during assessment, not afterwards.

4) Credential and key rotation. Regardless of whether the listing is genuine, rotate account passwords, API keys, certificates and third-party integration secrets; fully remediate endpoints that appear in infostealer logs; enforce MFA on SSO and VPN.

5) Monitoring and preparation for re-extortion. The same data set being resold and re-extorted by different crews is routine. Set up long-term dark-web and breach-corpus monitoring for your domains, mail suffixes and brand names.

What we deliver is a verifiable assessment and a clearly bounded response scope. We make no claim about whether the data will resurface later, or whether it has genuinely been deleted - technically, nobody can establish either.

Our response plan

Hit by APT73 ransomware? What to do

  1. Intake and evidence preservation

    Preserve the leak-site page screenshots and entry URL, the published sample pack, the countdown and demand details, and the original of any message claiming to be from Bashe / APT73 including full mail headers. At the same time freeze log rotation: extend retention immediately on perimeter devices, VPN, proxies, mail gateways, database auditing, cloud storage and SaaS download histories, or the critical time window will be overwritten before verification completes. Do not rush out a public statement.

  2. Listing authenticity and data ownership verification

    This is the highest-value step in an APT73 case. Analyse the sample structurally: does the field combination match your own schemas, is the record volume plausible, where do the timestamps cluster, and are there fields that only a retired system version ever produced? Then compare the emails and phone numbers against known public breach corpora - a high hit rate against old leaks points to repackaging. The verdict falls into three buckets: genuinely yours and current, genuinely yours but historical, or not attributable to your data at all.

  3. Exfiltration scope and impact assessment

    Where the data is verified as yours, reconstruct the exfiltration path and time window from logs, and check endpoints for infostealer artefacts, which public correlation work identifies as one of this group's main data sources. Then assess impact: the categories and volume of personal information involved, whether sensitive personal information is included, whether customer contracts or cross-border data are affected, and what reporting and individual-notification duties follow. Deliver a written assessment that separates evidence-backed conclusions from ranges and estimates.

  4. Execution: notification, rotation and communications

    Run three tracks in parallel from the assessment: compliance - complete regulatory reporting and notification of affected individuals with the evidence chain intact; technical - rotate account passwords, API keys, certificates and third-party integration secrets, remediate endpoints found in infostealer logs, enforce MFA on SSO and VPN; and communications - give customers, partners and press a single line grounded in the verification result. Where a listing verifies as repackaged old data, saying so clearly usually limits damage better than silence.

  5. Root-cause tracing, hardening and handover

    Trace where the credentials and data actually came from: an employee endpoint infected by an infostealer, a third-party supplier leak, a known vulnerability in an internet-facing application, or a listing that never corresponded to a breach at all. Harden accordingly - shrink the external attack surface and patch legacy applications, bring privileged and service accounts under unified control, set alert baselines for bulk exports from databases and file servers, and make dark-web and breach-corpus monitoring routine. Close with an incident report and a handover checklist stating which risks are closed and which need continued observation.

Risk warning

What not to do

  • Do not confirm or deny a breach publicly before verification. A significant share of APT73 listings are repackaged old data, and a statement issued either way without checking can be contradicted within days.
  • Do not pay for data deletion. The data often originated in public breach corpora to begin with; payment cannot prove deletion and will not stop the same set being resold by another crew.
  • Do not open the onion negotiation page or make contact yourself. Any contact is logged as a response, raises the demand and invites follow-up pressure; contact should be handled by a specialist team under controlled conditions.
  • Do not reset logs or rebuild suspected endpoints before the assessment is complete. Infostealer artefacts and the exfiltration time window are the key evidence for judging authenticity, and cannot be recovered once wiped.
  • Do not treat this as an encryption incident just because the word ransomware appears. If files really are encrypted, the encryptor almost certainly belongs to another family and must be re-identified from actual samples.
  • Do not limit remediation to the named system. Infostealer logs typically span many accounts and platforms belonging to the same employee, so rotation scope should follow people and identity systems, not a single application.

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.

+86 15639272850See contact details

Related scenarios

Related industries

Similar families

FAQ

APT73 Frequently asked questions

  • APT73 listed us on its leak site - does that mean our data really leaked?

    Not necessarily. This is the single most important characteristic of APT73 / Bashe. Both CloudSEK and BushidoToken have documented the group claiming intrusions it did not perform and republishing old public leaks as new breaches - the Hargreaves Lansdown listing it posted in late April 2026 was assessed as fabricated by BushidoToken that June. The right first move is verification: compare the sample's field structure, record counts and timestamps against your own systems, and check whether the emails in it already appear in historical breach corpora. Everything else follows from that result.

  • Can APT73 ransomware be decrypted, and what if our file extensions were changed?

    As of September 2026 we have found no public analysis documenting an APT73 / Bashe encryptor sample, file extension or ransom note, and the family does not appear in the No More Ransom decryptor catalogue, so there is no such thing as an APT73 decryptor. If files on your estate are genuinely encrypted with a rewritten extension, the encryptor belongs to a different family and the APT73 name has been misapplied or misreported. Keep three to five encrypted files plus the note, re-identify the family from those samples, and assess decryption and repair options against the family actually involved.

  • How can we tell whether the published sample is old data?

    Several practical checks. First, timestamp distribution: if the newest records stop years ago, you are almost certainly looking at a historical leak. Second, field structure: fields that only a decommissioned system ever produced, or the absence of fields your current system always writes. Third, comparison against public breach corpora: a high hit rate for the sample's email addresses indicates the data came from public combolists. Fourth, record volume that is wildly inconsistent with your actual system size. Two or more of these pointing the same way warrants pursuing the repackaging hypothesis.

  • After being named by APT73, do we have to report to regulators?

    Reporting obligations follow from whether personal information or important data actually leaked and at what scale - not from what a criminal group wrote on its leak site. So verification comes first. If the data is confirmed as yours and includes personal information, complete regulatory reporting and individual notification under the Personal Information Protection Law, the Data Security Law and your sector's rules, and check local requirements separately for cross-border operations. If verification shows repackaged old data with no new exposure, retain the full verification record for inspection. Bring legal and compliance in during assessment so the statutory window is not consumed.

  • Should we pay APT73 to take the listing down?

    We advise against it, and we neither pay ransoms nor negotiate. That applies with particular force here: a substantial share of this group's material originated in public breach corpora, so payment cannot prove deletion and will not stop the same data being resold by another crew - while any payment confirms you as a paying target and raises the odds of repeat extortion. The better investment is a rigorous verification, a precise definition of what actually left, disciplined credential rotation and compliance notification, and long-term dark-web and breach-corpus monitoring.

Sources

External links are provided for reference only. The content is published by third parties and does not represent our position.

Updated