Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

ShinyHunters Ransomware Decryption & Data Recovery

  • Active
  • Critical
  • No public decryptor

ShinyHunters (ShinyCorp, UNC6240, Bling Libra; MITRE ATT&CK G1057) has run data-theft extortion since 2019 without ever encrypting a file. Operators use voice phishing and stolen SaaS OAuth tokens to pull data out of Salesforce, Snowflake and Databricks, then press with a Tor leak site and a 72-hour bitcoin deadline. Victim postings continued through 2026.

First seen
2019
File extensions
No public information
Ransom notes
README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT
Affected platforms
Windows / Databases

Family profile

File extensions
No public information
Ransom notes
  • README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT
Contact patterns
  • Extortion mail from Tuta (tuta.com) anonymous mailboxes, usually with brand-style prefixes such as shinycorp or shinygroup
  • Vishing calls impersonating IT support, walking staff into entering a connection code on the Salesforce connected-apps page
  • Tor (.onion) leak sites on domains beginning with shiny / shnyhnt, plus toolate-style countdown and negotiation portals
  • Telegram channels, often posting under the joint Scattered LAPSUS$ Hunters (SLSH) brand
  • BreachForums-lineage forums (e.g. breachforums.hn), repeatedly rebuilt after law-enforcement seizures
  • A bitcoin address and a 72-hour deadline inside the mail; no decryptor is ever offered, and file recovery is never discussed
Aliases / versions
ShinyCorp、UNC6240、Bling Libra、G1057、UNC6040（入侵集群）
First seen
2019
Status
Active
Operational status
Actively operating
Threat level
Critical
Affected platforms
  • Windows
  • Databases
Tags
  • Extortion-only
  • Active
  • Phishing
  • Supply chain
  • Targets databases
  • Exploits vulnerabilities
Decryptor
No public decryptor

Decryption is not a concept that applies to this brand. ShinyHunters' core business is stealing data and extorting through exposure, not deploying an encryptor. Extensions stay unchanged, files still open, and production systems keep running. That is why the name appears in no No More Ransom listing and in no vendor decryptor set - and why it does not need to.

The entire loss sits on the confidentiality side. Customer master data, support tickets, HR records and identity documents have been copied out intact, and pressure is applied by listing the victim on a Tor leak site and contacting their customers and regulators. Hunting for a decryptor in a case like this burns the forensic and notification window that actually matters.

A useful inverse test. If your files genuinely have a new extension and a note has been dropped on disk, this is probably not mainline ShinyHunters activity. It may be a different family, someone leaning on a well-known name, or the associated ShinySp1d3r ransomware-as-a-service branch - public technical detail on that encryptor remains thin, so a real sample must be re-identified rather than assuming this page applies.

Treat with equal caution any third party promising that stolen data "will be deleted" or that leak-site pages can be pulled down. Destruction cannot be verified technically, and such offers usually amount to paying the ransom and reselling it at a markup.

Latest activity

  1. ShinyHunters claimed a breach of Florida's DAVID motor-vehicle database, taking 200,000+ driver records. The intrusion began 3 Sept via a password-reset flaw that let them take over employee accounts; the victim was posted to their leak site on 7 Sept.

    Sources

  2. Ransomware.live records roughly 156 organisations on the ShinyHunters leak site, most recently posted 7 September 2026, alongside four tracked leak and negotiation domains - indicating a steady 2026 operating tempo.

    Sources

  3. ShinyHunters published data on roughly 12.9 million Carhartt customer accounts, taken via compromised access to the retailer's Databricks analytics platform. Carhartt refused the $3.3M demand and declined to negotiate.

    Sources

Overview

ShinyHunters has operated under the ShinyCorp persona since at least 2019 and is catalogued by MITRE ATT&CK as G1057, also tracked as UNC6240 and Bling Libra. It is not a ransomware family in the conventional sense but a theft-only extortion brand, and Mandiant's framing is the precise one: a banner shared across multiple threat clusters rather than a single commanded crew.

Three phases describe the activity. From 2020 to 2023 the crew sold stolen databases on RaidForums and BreachForums. In 2024 it claimed and sold data from Snowflake tenants that had no multi-factor authentication, and Unit 42 documented the same period's shift to direct extortion, including deleting cloud storage buckets after exfiltration. From 2025 the focus moved to SaaS: in June Google documented UNC6040 using voice phishing to get employees to authorise a malicious connected app and export Salesforce data; in August OAuth tokens from the Salesloft Drift integration were stolen, affecting hundreds of companies - Google tracks that intrusion set separately as UNC6395, while the brand publicly claimed it - and the group subsequently ran its own Tor leak site under the joint banner.

ShinyHunters sits inside "The Com" alongside Scattered Spider and LAPSUS$; in 2025 the three operated jointly as Scattered LAPSUS$ Hunters (SLSH) and launched a ransomware-as-a-service branch named ShinySp1d3r - so "does not encrypt" is a historical characteristic, not a permanent assumption. Arrests and sentences have not stopped the brand: as of early September 2026 ransomware.live counted roughly 156 organisations on its leak site, most recently on 7 September.

No public report confirms a targeted campaign against mainland China organisations, but the entry points map onto common local weaknesses: dependence on overseas SaaS, third-party integration grants that are never reviewed, and helpdesks with no call-back verification.

How to identify it

There is no encrypted-file extension, so suffix-based identification does not apply. Most victims learn what happened when the extortion mail arrives, or when someone asks about a leak-site entry. Note that "no encryption" does not mean "no note": MITRE records under G1057 that the crew drops a note named README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT in compromised storage locations, as a defacement-style message rather than alongside encryption. Four surfaces carry evidence.

  • SaaS authorisation. An unapproved application appears among connected apps - historically named to match the pretext, for example My Ticket Portal. Data Loader, or a script imitating it, runs abnormally large exports. Unusual OAuth token provenance, or integration tokens used at odd hours, are equally strong signals.
  • Voice and SMS. Staff report a call from "IT support" asking them to open the connection page and enter a connection code.
  • Extortion communications. English-language mail from a Tuta (tuta.com) anonymous mailbox, signed as ShinyHunters, with a bitcoin address and a 72-hour deadline.
  • Public exposure. The company name and a sample data pack appear on the Tor leak site, with Telegram channels amplifying under the SLSH brand.

Bottom line. The name is borrowed constantly, and Google states the extortion cluster has consistently claimed ShinyHunters affiliation to increase pressure. A self-declared name is not attribution. Without technical corroboration, treat the case as suspected impersonation and first establish whether data actually left.

Infection vectors

The entry point is identity and authorisation, not an endpoint exploit. The techniques MITRE records under G1057 group into five lines.

  • Voice phishing (T1598). Operators call staff posing as IT support, targeting anyone holding SaaS permissions, to get a malicious connected app authorised or credentials and MFA codes handed over.
  • OAuth token theft (T1528). The highest-impact path of 2025. When the compromised party is an integration hundreds of companies connect to, one failure becomes supply-chain spread - customer-side MFA and endpoint protection never enter the equation.
  • Valid accounts and credential reuse (T1078, T1552.001, T1110). Credential stuffing, infostealer logs, cleartext credentials in configuration files, and brute-forcing VPNs and firewalls.
  • Public-facing application exploitation (T1190). MITRE records exploitation of known vulnerabilities in internet-facing servers under G1057, naming an Oracle PeopleSoft issue, CVE-2026-35273. Separately, in a September 2026 case the operators themselves told press they abused a password-reset flaw to take over accounts and then walked record IDs to pull data one entry at a time - an actor claim, not victim-confirmed.
  • Remote access tools (T1219). MeshCentral and ConnectWise maintain access as legitimate RMM agents.

Two counter-intuitive aspects. Theft and extortion can be months apart - Google assesses a possible division of labour between UNC6040 and UNC6240 - so by the time the mail arrives the evidence may have aged out of log retention. And the attack does not land in your own network: data is pulled straight from the cloud tenant, so the only productive evidence surface is SaaS and identity platform audit logging.

Encryption behavior

Mainline activity encrypts nothing, so this section covers what actually happens: targeted discovery and bulk exfiltration of cloud-resident data.

Discovery and exfiltration. With access to the tenant, operators enumerate cloud infrastructure and storage objects (T1580, T1619), reach into code repositories and databases (T1213.003, T1213.006), then move data out through the compromised SaaS platform itself (T1567) - typically via the official Data Loader or a bespoke script imitating it, with Tor multi-hop proxying (T1090.003) hiding the source. Everything runs under the victim's own legitimate authorisation, so the audit trail simply shows a normal integration call.

"No encryption" is not "no destruction". Unit 42's analysis of a 2024 cloud-storage case shows the operators called DeleteBucket to remove several S3 buckets after exfiltration (T1485), then created empty buckets named contact-shinycorp-tutanota-com-# as a taunt. Deletion protection, object versioning and cross-account backups for cloud storage are therefore mandatory, not optional.

What this means for defenders. There is no encryption process, no shadow-copy deletion and no service stoppage, so almost no conventional ransomware behaviour rule will fire. The monitoring that works lives on the identity and data side: alerting on connected-app and OAuth grant changes, baselining API call rates and export volumes, flagging Tor exit addresses, watching for large result-set queries in the warehouse, and alerting on storage deletion APIs.

One exception. ShinySp1d3r, the associated ransomware-as-a-service branch, does encrypt; publicly traceable sample indicators appear from around November 2025. Its extension and encryption algorithm have no credible public documentation, and a third-party aggregator records the note filename as README_SH1NYSP1D3R.txt on a single source only. This page draws no handling assumptions from that; a genuine encryption incident must be re-identified from samples.

Assess before you act

Recoverability assessment

Nothing needs to be "recovered" here: the data never left your systems, it was copied. The path is rewritten as leak impact assessment, notification duties and credential rotation, in five layers.

1) Decryption and file repair: not applicable. With no encryptor there is no decryptor. If files genuinely are encrypted, either the attribution is wrong or the ShinySp1d3r branch is involved, and sample identification must be redone.

2) Bounding the exfiltration scope and window - the top priority. The evidence lives in the cloud, not on endpoints: SaaS login history and event monitoring, connected-app authorisation timestamps, OAuth token issuance and usage, API call volumes and export jobs, data-warehouse query auditing, and IdP/SSO session events. Time-critical: detailed SaaS logs are often retained for only weeks to months, while extortion may arrive months after the theft.

3) Data classification and notification duties. Segment what was taken into personal data, sensitive personal data, client confidential material and trade secrets, then set notification scope and deadlines. Domestic operations follow China's PIPL, Data Security Law and incident reporting rules.

4) Rotating credentials and tokens. Revoke suspicious OAuth grants and session tokens, remove unauthorised connected apps, re-enrol MFA, rotate cloud access keys and API keys, and review each integration's scope.

5) Verifying unaffected copies. Reconcile production against backups to establish whether the operators only read records or also deleted and altered them - in cloud storage, check bucket inventories, object versions and delete markers one by one - and hunt for leftover backdoor integrations or disguised accounts.

We do not pay ransoms, do not negotiate, and give no assurance that "the data has been deleted" - that claim cannot be verified technically.

Our response plan

Hit by ShinyHunters ransomware? What to do

  1. Containment and cloud log preservation

    The first priority is not isolating a server but exporting and preserving cloud evidence before it ages out. Immediately export SaaS login history, event monitoring and API usage logs from Salesforce and equivalents, plus IdP/SSO session and MFA events, OAuth grant records, third-party integration token issuance and call logs, data-warehouse query auditing and mail gateway records. In parallel, disable - do not delete - suspicious connected apps and integration accounts, because deletion takes the configuration and authorisation timestamps with it. Preserve the extortion mail in full including headers, along with captures of the leak-site page and Telegram posts. Where staff report a suspicious call, record the time, calling number and the exact pretext used.

  2. Attribution check and impersonation screening

    The ShinyHunters name is borrowed constantly, and a self-declared name in an extortion email carries no evidential weight. This step first establishes whether exfiltration actually occurred, and only then addresses attribution. Cross-check four evidence classes: whether an unauthorised connected app or anomalous bulk export exists on the SaaS side; whether OAuth tokens originated from suspicious sources or unusual geographies; whether egress shows Tor exit addresses and abnormal export volumes; and whether the sample data the operators displayed reconciles record by record against your real data. Then classify the path - direct authorisation via employee vishing, supply-chain spread through a stolen integration token, or credential reuse and public-application exploitation. The containment actions and notification scope differ completely across the three.

  3. Exfiltration scope and leak impact assessment

    Triangulate API export records, object access auditing and egress traffic to bound the inventory of objects taken, the record counts and the time window, then validate against the samples shown in the extortion mail. Classify what left: general personal data, sensitive personal data (ID numbers, financial accounts, biometrics), client confidential material and trade secrets. Deliver a written assessment naming the regulatory notification duties and deadlines, the scope of customer and employee disclosure, contractual and SLA exposure, and the material an insurance claim will require. That assessment is the single factual basis for every external statement and must be completed before anything is said publicly - in theft-only cases, controlling the narrative is itself a form of loss control.

  4. Token rotation and integration governance

    Work identity-first: revoke all suspicious OAuth grants and long-lived session tokens, remove unauthorised connected apps, reset affected account passwords and re-enrol MFA, rotate cloud access keys, API keys, data-warehouse tokens and service-account credentials, and clear mailbox auto-forwarding and delegation rules. Then run a full third-party integration inventory: list every authorised external application with its data scope and last-used date, revoke dormant and over-scoped grants, and turn least privilege plus periodic review into standing policy rather than a one-off exercise. On endpoints, sweep for leftover unauthorised remote management agents such as MeshCentral or ConnectWise.

  5. Hardening, process change and handover

    Against an attack whose entry point is identity, hardening cannot stop at technology. Technical: allowlist connected apps and require approval for new grants, alert on export volume and API call rate, restrict which accounts may run Data Loader-class bulk exports, enforce phishing-resistant MFA (FIDO2 security keys) on administrative and integration accounts, gate SaaS sign-in by trusted IP or device, and alert on large result-set queries in the warehouse. Process: build two-way helpdesk verification so staff can call back through the internal directory, and make it policy to hang up and verify any call asking someone to "enter a code" or "authorise an app"; bring third-party integrations into vendor security management with disclosure requirements for token handling and incident notification. People: drill voice phishing and SaaS authorisation scenarios specifically, rather than running generic phishing-email training. Close with an incident report and a formal handover checklist.

Risk warning

What not to do

  • Do not downgrade the incident because "nothing was encrypted and systems still work". ShinyHunters' entire leverage is the customer data already copied out, and uninterrupted operations are exactly why these cases get underestimated and the forensic window gets missed.
  • Do not delete the suspicious connected app or integration account first. The correct order is **disable, export the evidence, then delete** - deleting outright takes the authorisation timestamps and call records with it, leaving the exfiltration scope unprovable and both notification and insurance claims without a basis.
  • Do not delay exporting cloud audit logs. Detailed SaaS logging is commonly retained for only weeks to months by default, while extortion may arrive months after the theft; a week's delay can permanently cost the decisive records.
  • Do not reply to the extortion mail, join their Telegram channel, or reach out "just to understand the situation". Unplanned contact reveals how sensitive you consider the data and how fast you decide, which is used directly to raise the price, and may trigger early outreach to your customers and regulators.
  • Do not attribute the incident - or notify anyone - purely because the mail is signed "ShinyHunters". The name is borrowed constantly; confirm from SaaS audit logs, token records and egress traffic that data actually left before settling on any public position.
  • Do not trust third parties promising that stolen data "will be deleted" or that leak-site pages can be removed. Destruction cannot be verified technically, such offers usually amount to reselling a paid ransom, and they can leave the organisation in a worse compliance position.

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

ShinyHunters Frequently asked questions

  • Does ShinyHunters ransomware encrypt files, and is there a decryptor?

    Strictly speaking ShinyHunters is not a "ransomware virus". Its mainline activity deploys no encryptor: extensions are unchanged, files open normally and systems keep running, so there is neither a decryptor nor any need for one. That is precisely why the name appears in no No More Ransom listing and in no vendor tool set.

    The leverage is data already copied out in full - customer master records, contact details, support tickets, identity and licence documents. Pressure comes from listing the company on a Tor leak site and contacting its customers and regulators, with extortion mail typically giving a 72-hour deadline and a bitcoin address.

    If your files genuinely are encrypted, this is probably not mainline ShinyHunters activity. It may be a different family, someone leaning on a well-known name, or the associated ShinySp1d3r ransomware-as-a-service branch. The three cases demand completely different handling, so re-identify the family from real encrypted samples and the note rather than applying the assumptions on this page.

  • We received extortion mail signed "ShinyHunters" - how do we tell a real breach from an impersonator?

    Do not take the signature at face value. Google Threat Intelligence states that the cluster handling extortion has consistently claimed ShinyHunters affiliation to amplify pressure. The name is borrowed constantly in the criminal economy, and empty-handed extortion under a known brand is common.

    Only technical evidence settles it. Check four things, in order.

    • SaaS authorisation. Is there an unapproved application among the connected apps in Salesforce or its equivalents? Do OAuth records show tokens from unfamiliar sources, unusual geographies or outside working hours?
    • Export behaviour. Do API call volumes and export job records show bulk activity above baseline? The characteristic pattern is small probing batches followed by a rapid ramp once nothing intervenes.
    • Egress. Is there access from Tor exit addresses, and outbound traffic matching the claimed export volume?
    • Sample reconciliation. Does the sample data they displayed reconcile record by record against your real data? Do the field structure and date ranges match? Information available from public sources alone suggests a fabrication.

    Mind the time lag. Google observed extortion arriving months after the theft, so do not limit the review to the past week - open the window to at least six months, and export and preserve audit logs immediately. Detailed SaaS retention is limited, and delay means permanent loss of evidence.

  • We use overseas SaaS such as Salesforce or Snowflake - how do they get in, and does MFA stop it?

    Public cases show three main paths, and MFA's value differs across them.

    • Vishing that gets an employee to authorise the access themselves. The caller poses as IT support and walks the employee through entering a connection code on the connected-apps page, attaching a malicious application to the tenant - named in past cases to match the pretext, for example My Ticket Portal. On this path ordinary SMS or push MFA does not help: the employee completed a legitimate authorisation under guidance. Phishing-resistant FIDO2 keys help, but the decisive controls are restricting who may install connected apps and requiring approval for new grants.
    • Stolen OAuth tokens belonging to a third-party integration. This was the highest-impact path of 2025. The party compromised is not you but an integration you connect to; with its token, the operator pulls data as a legitimate integration. Your own MFA, password strength and endpoint protection play no part. The only effective controls are periodic review of integration scopes, revoking dormant grants, and monitoring export volume.
    • Credential reuse against tenants without MFA. Credential stuffing and infostealer logs, as in the 2024 attacks on data-warehouse tenants that had no MFA enforced. Here MFA genuinely works, and enforcing it raises the bar substantially.

    In short: MFA is necessary but not sufficient. For SaaS, the real defence is the combination - connected-app allowlisting, approval for new grants, periodic review of integration permissions, export-volume baselining, and two-way helpdesk verification.

  • We have been listed on their leak site - will paying take it down? If we do not pay, what comes first?

    On paying: we do not pay ransoms and do not negotiate. Technically, payment buys nothing verifiable - whether the data was really deleted cannot be checked, and neither can whether copies already sit with other people or other cells. This brand is by its own structure a banner shared across loosely connected clusters, so an understanding reached with one party binds none of the others. Public reporting already includes victims whose data continued to circulate after payment.

    If you do not pay, in priority order:

    1. Rescue the evidence. Export and preserve SaaS and identity platform audit logs immediately - this is the only task under a hard clock.
    2. Bound the scope. Establish which objects, how many records and when, and reconcile against the samples they displayed.
    3. Complete notification. Notify regulators, customers and staff on your own terms before the full data set is published. In theft-only cases proactive disclosure costs far less than being exposed, and controlling the narrative is itself loss control.
    4. Close the door. Revoke suspicious OAuth grants and tokens, remove unauthorised connected apps, rotate credentials estate-wide, and review every third-party integration scope.
    5. Align communications. Prepare a single agreed position for customer enquiries, press questions and partner notifications, so inconsistent statements do not cause a second round of damage.

  • How are ShinyHunters, Scattered Spider, LAPSUS$ and Scattered LAPSUS$ Hunters related, and should organisations in China worry?

    On the relationships: all three sit inside the English-speaking cybercrime ecosystem known as "The Com" - young, social-engineering-led and with porous boundaries. In 2025 they operated jointly as Scattered LAPSUS$ Hunters (SLSH), sharing Telegram channels and extortion platforms, and launched a ransomware-as-a-service branch called ShinySp1d3r.

    Mandiant's assessment is important here: "ShinyHunters" is not a single commanded organisation but a banner shared across multiple threat clusters. Two practical consequences follow: indicators from one incident may not transfer to another, and any understanding reached with one party does not extend to the rest.

    Other naming: MITRE ATT&CK lists the group as G1057 with aliases UNC6240 and Bling Libra, while the intrusion-side cluster is tracked separately as UNC6040. Google assesses a possible division of labour between intrusion and monetisation, which also explains the months-long gap between theft and extortion.

    Should organisations in China worry? No public report confirms a targeted campaign against mainland organisations, and the disclosed victims are overwhelmingly in Europe and North America. Two real risks remain. First, Chinese groups with overseas subsidiaries or cross-border operations fit the same target profile, especially those using non-domestic CRM, data warehousing and marketing automation platforms. Second, the tradecraft spreads - IT-helpdesk voice phishing and third-party integration token theft are now shared entry routes across several crews. The pragmatic investment is therefore in controls that generalise: connected-app governance, periodic review of integration permissions, export-volume baselining, and two-way helpdesk verification.

Sources

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

Updated