ShinyHunters: Attack Lifecycle, IOCs, and Incident Response Guide

ShinyHunters is a data-theft and extortion collective that has operated under that name since spring 2020, and some cybersecurity analysts even say it has been active since at least 2019. It steals data from SaaS, cloud, and enterprise applications, using voice phishing (vishing), stolen OAuth tokens, compromised credentials, and application exploits, then demands payment to keep the data off its leak site. It has an encryptor in development, ShinySp1d3r, but no documented attack has used it.

New Activity: In September 2026, ShinyHunters claimed to have breached the FBI's FBIJobs.gov portal. The group said the attack was not financially motivated and instead gave the FBI one week to retract or modify a May 2026 warning about its harassment tactics. The FBI has said it is investigating the claim; details are below.

This guide is written for DFIR teams, MSPs, breach counsel, and security leaders who need to attribute, contain, and respond to ShinyHunters-branded activity. If you are facing an active incident, our 24/7 incident response (DFIR) team can help.

ShinyHunters at a glance

What is ShinyHunters?

In May 2020, cybercriminals claimed responsibility for stealing over 100 million records from Tokopedia, Unacademy, and others within a span of weeks. Calling themselves ShinyHunters, they sold the stolen databases on criminal forums and marketplaces. In its early years, the group operated on a simple data-broker model: breach, then sell or leak.

The name does not map neatly to a single team. Google Threat Intelligence Group (GTIG) splits ShinyHunters-branded activity into several UNC clusters to account for evolving partnerships and possible impersonation. MITRE's group profile (G1057) lists UNC6240 and Bling Libra as associated groups. Its association with The Com does not establish who carried out a particular intrusion.

In public statements regarding the September 2026 FBIJobs.gov incident, threat actors representing the group explicitly stated they originally operated under the alias GnosticPlayers before rebranding to ShinyHunters in 2020.

The brand can also be borrowed: UNC6671, a vishing cluster GTIG assesses as independent, used the ShinyHunters name in at least one extortion attempt to make its threats more credible.

Since August 2025, Telegram channels using the Scattered LAPSUS$ Hunters (SLSH) name have combined the ShinyHunters, Scattered Spider, and LAPSUS$ brands. Public reporting describes joint operations by members of these groups, but the exact arrangement behind SLSH remains unclear. The channels have also solicited insiders at target companies.

History and evolution

Arrests have not ended the brand. The June 2025 arrests in France concerned suspected BreachForums operators, one reportedly using the ShinyHunters handle; public reporting does not establish what role, if any, those suspects played in later SaaS extortion.

Who ShinyHunters targets

ShinyHunters most often targets technology, retail, and financial services companies, but its victims also include healthcare, education, telecommunications, and government organizations. While the group routinely posts long lists of alleged victims to its leak site to build leverage, these claims range from incidents the victims confirmed, usually without naming the group, to unconfirmed assertions.

Federal Law Enforcement (2026)

In September 2026, ShinyHunters defaced the FBI’s applicant site, FBIJobs.gov, and claimed to have exfiltrated 2 to 3 TB of data. The FBI said it was investigating the claim and that the point of breach was still undetermined. Samples shared with journalists included names, home addresses, family details, and some medical evaluation records of FBI personnel and applicants; the FBI has not said which systems were affected or what data was taken.

Rather than demanding a ransom, the group used a leak-site post to give the FBI one week to alter a May 2026 warning about its tactics. On September 24, it replaced that post with a short statement saying it had achieved its goal, while noting that its deadline still stood. As of September 26, 2026, it had shared samples only with journalists.

State & Local Government (2026)

State and local government faced similar exposure in September 2026, when Florida’s motor vehicle agency investigated a breach that ShinyHunters tied to its DAVID driver database. The agency said an unnamed criminal actor used login credentials that a Plant City Police Department employee had stored on a personal device.

ShinyHunters separately claimed access to more than 200,000 DAVID records; the agency has confirmed neither that scope nor the group's role. The agency's account shows how a single local user's credentials can provide access to a statewide database.

Healthcare & Life Sciences (2026)

In July 2026, Health-ISAC warned of an observed increase in successful ShinyHunters attacks on the sector. In a regulatory filing, DentaQuest disclosed an incident affecting 15 million individuals, the largest US health-data breach reported in 2026 through September. The filing does not name an attacker; ShinyHunters claimed responsibility and published data it said came from the company. Medtronic and McKesson also disclosed incidents that ShinyHunters claimed, though neither company named the group.

Telecommunications & Consumer Brands (2026)

In August 2026, ShinyHunters leaked a dataset attributed to apparel brand Carhartt, in which Have I Been Pwned found 12.9 million genuine email addresses, mostly belonging to customers; Carhartt has not publicly confirmed a breach. Earlier in 2026, Kodak confirmed a limited breach, and Charter Communications acknowledged an incident while denying that sensitive customer data was taken.

Education (2026)

The intrusion at Instructure disrupted coursework at numerous universities when attackers accessed its Canvas platform, resulting in confirmed data exfiltration. In the PeopleSoft campaign, 68% of the more than 100 organizations GTIG notified about potentially vulnerable endpoints were in higher education; some blocked the activity, while others were breached, and their data was published.

SaaS & Enterprise Software (2024-2025)

In 2024 and 2025, a widespread Salesforce vishing campaign, tracked by GTIG as UNC6040, persuaded employees to authorize a malicious connected app; the subsequent extortion was attributed to UNC6240, which claimed the ShinyHunters name. Google disclosed that UNC6040 activity retrieved basic business contact information from one of its corporate Salesforce instances.

Disclaimer: Victim listings on ransomware leak sites represent unverified claims made by the threat actor. Treat them as unconfirmed unless corroborated by company disclosures, SEC filings, regulatory notifications, or law enforcement confirmation.

ShinyHunters attack lifecycle

ShinyHunters-branded incidents have used different entry points. Phase 1 covers identity compromise, compromised integrations, over-permissive guest access, and application exploits; the later phases describe behaviors documented in these campaigns, not steps present in every intrusion.

Phase 1a: Initial access through identity

An operator calls an employee, posing as IT support, and claims the company is updating MFA settings. The caller sends the employee to a look-alike sign-in page such as <company>sso[.]com or <company>okta[.]com and captures the password and MFA code in real time, or tricks them into approving a push prompt. In another variant, the caller impersonates the employee to the real help desk and requests a password reset or new device.

Since May 2026, some vishing operators have contacted employees on their personal phones, using urgent passkey enrollment as a pretext. The call leads either to a look-alike page that intercepts credentials or a session, or to a device-code flow in which the employee approves access for an attacker-controlled client. Microsoft documents this lure across multiple actors, including Storm-3121 activity leading to ShinyHunters extortion.

In the Salesforce variant, the call centers on an app approval, often alongside requests for credentials and MFA codes. The caller walks the employee to Salesforce's connected-app setup page and reads out a connection code that links a modified copy of Data Loader, Salesforce's bulk import/export client, renamed to something plausible such as "My Ticket Portal." Malicious apps were registered through Salesforce trial accounts and, later, compromised accounts at unrelated organizations.

The 2024 intrusions into Snowflake customer accounts used credentials stolen by infostealers to access accounts without MFA. This activity is tracked as a separate cluster, although data from the intrusions was marketed under the ShinyHunters name.

Phase 1b: Initial access through integrations and exposed applications

Attackers can use stolen tokens issued to third-party integrations to access customer environments without a fresh interactive sign-in or MFA prompt. In 2025, stolen Salesloft Drift and Gainsight OAuth tokens were used against Salesforce tenants; in 2026, Anodot-linked authentication tokens were used against Snowflake customers.

Publicly accessible Salesforce Experience Cloud sites use a guest user profile for anonymous visitors. When that profile is over-permissive, CRM objects can be queried without logging in through the /s/sfsites/aura endpoint. Attackers, in a campaign ShinyHunters later claimed, mass-scanned such sites using a modified version of AuraInspector, an open-source auditing tool, and pulled data from misconfigured tenants; the campaign surfaced in March 2026, when Salesforce issued an advisory calling it a configuration issue rather than a platform vulnerability.

Canvas, by contrast, fell to application flaws. Instructure's incident update describes initial access through malicious code in a Free-for-Teacher support ticket (an XSS that fired in a support agent's session and yielded an authorization token) and re-entry on May 7 through a second, unpatched XSS in the discussion feature.

PeopleSoft activity that began in late May 2026 targeted Environment Management Hub (PSEMHUB) endpoints and appears consistent with zero-day exploitation of CVE-2026-35273, a remote-code-execution flaw in the Environment Management component, before Oracle's June 10 advisory. GTIG advises checking PSEMHUB.war for unexpected .jsp files, a possible sign of webshells. Threat intelligence reports show operators bypassed front-end defenses by using percent-encoded URL variations in PeopleSoft requests before dropping JSP web shells on vulnerable endpoints.

Phase 2: Persistence and evasion

In the January 2026 vishing wave, UNC6661 operators registered their own MFA devices on compromised accounts. In at least one case, they used ToogleBox Recall, a Google Workspace add-on that permanently deletes email, to remove an Okta "Security method enrolled" notification, likely to conceal the enrollment.

In the Salesforce vishing campaign, a malicious connected app persists as its own OAuth grant, independent of the employee's session. In the PeopleSoft campaign, operators used MeshCentral, an open-source remote management tool, with agents disguised as Azure services. Operators in the identity-based campaigns also used commercial VPNs and residential proxies to blend into normal traffic.

Phase 3: Discovery

From the SSO dashboard, operators open whatever the compromised user can reach. In cloud applications such as SharePoint, they search for terms such as "poc," "confidential," "internal," "proposal," "salesforce," and "vpn." Stolen data is also mined for secrets: in the Drift campaign, UNC6395, a separately tracked cluster, searched exported Salesforce data for AWS keys, Snowflake tokens, and passwords to extend access.

Phase 4: Lateral movement

In identity-led SaaS intrusions, movement is primarily between applications rather than hosts. From a compromised SSO session, operators pivot into the SaaS apps the identity can reach: Microsoft 365, Google Workspace, DocuSign, and others. The artifacts are new sessions, new OAuth grants, and unusual API calls in identity and SaaS logs, not process trees or network beacons.

The PeopleSoft campaign is the exception. A script named [victim_abbreviation]_fanout.sh sprayed SSH connections across internal hosts using a hardcoded list of common administrative and application-specific usernames and passwords, with MeshCentral providing remote control.

Phase 5: Data exfiltration

Operators export Salesforce data through Data Loader or custom Python scripts that call the Salesforce API. In at least one Salesforce intrusion, small test queries preceded full-table exports. GTIG attributes SharePoint and OneDrive downloads with a WindowsPowerShell/5.1.x user agent to UNC6671, the cluster it assesses as independent.

Phase 6: Extortion and possible handoff

Extortion demands can arrive days to months after initial access. Their timing alone does not show when the intrusion began.

In the Salesforce campaign, UNC6040 stole the data; MITRE attributes the subsequent extortion demands to a separate threat actor, UNC6240. Similar divisions in other intrusions require incident-specific evidence. The split is not universal: GTIG attributes both the PeopleSoft exploitation and its extortion to UNC6240.

Extortion model and leak site

Following the January 2026 UNC6661 intrusions, UNC6240 sent extortion emails listing stolen data, a Bitcoin address, and a 72-hour deadline; proof samples appeared on LimeWire, and negotiations took place over Tox. File encryption has not been reported in published accounts of the SaaS incidents discussed here. Stolen-data disclosure is the primary leverage: pay, or the data is published.

After its clearnet domain was seized in October 2025, the SLSH leak site stayed up briefly on Tor, leaking data from six companies before going offline. A new ShinyHunters-branded site listing alleged victims appeared in late January 2026.

Pressure extends well past the leak site. The FBI's May 2026 public service announcement documents threatening texts and calls to victims and their family members, swatting, and false claims of holding compromising material. GTIG has also received reports of DDoS attacks against victim websites, and the Canvas intruders defaced login pages.

Indicators of compromise

These indicators come from separate campaigns. The PeopleSoft entries include exposed staging infrastructure and host artifacts; the ShinySp1d3r entries come from a development build with no documented deployment. Corroborate addresses, app names, user agents, and extortion contacts with logs before treating them as proof of compromise or attribution. Hashes are SHA-256; onion addresses are omitted.

Network indicators

File hashes (SHA-256)

Host artifacts

Tools and user-agents

Extortion contacts

MITRE ATT&CK mapping

The table maps selected MITRE ATT&CK techniques to the separate campaigns discussed in this article. Observed entries appear in MITRE’s G1057 profile or, where marked C0059, in that campaign. Low entries are analyst mappings to capabilities in the ShinySp1d3r development build; no deployment has been documented.

Detection and threat hunting

Across these campaigns, useful evidence sits in identity, SaaS, web, and host logs. Retention and event coverage depend on licensing and settings.

Salesforce’s free EventLogFile access covers only a few event types, such as Login, for one day; Bulk API events need Event Monitoring. Okta System Log retains 90 days; Entra sign-in logs retain 7 to 30 days, and Graph activity logs (P1 or P2 only) exist only if routed to storage or an analytics workspace; Microsoft 365 Audit (Standard) retains 180 days; Google Workspace OAuth token logs retain six months. Confirm that the events needed for the hunts below are collected, then export them early.

High-value hunts. Prioritize those that match the suspected access route:

• MFA and device enrollment: a new factor or device enrolled, especially when followed by deletion of the enrollment-notification email (the ToogleBox Recall pattern in Google Workspace). Also investigate unexpected device-code authorizations or token issuance followed by Microsoft Graph reconnaissance and SaaS downloads, particularly after a reported “passkey enrollment” call.
• OAuth grants and existing integrations: investigate unfamiliar connected apps or newly granted broad scopes and refresh-token access. Also look for unusual source IPs, query volumes, or bulk exports through previously authorized integrations; stolen tokens can be used without a new grant.
• SharePoint and OneDrive: unusual volumes of FileDownloaded and FileAccessed events across many files and folders, especially from anomalous sessions or scripting user agents such as WindowsPowerShell or python-httpx.
• Search activity: where search-query text is available in audit or SIEM telemetry, correlate SharePoint or OneDrive searches for terms such as "poc," "confidential," "internal," "proposal," "salesforce," and "vpn" with bulk downloads from the same anomalous session.
• Network origin: logins or Okta admin actions from commercial VPN and residential-proxy networks: Mullvad, Oxylabs, NetNut, 9Proxy, Infatica, nsocks.
• Salesforce: high-volume API queries or Bulk API downloads by unfamiliar or normally low-volume connected apps; on Experience Cloud sites, anomalous guest queries to /s/sfsites/aura, especially to objects not intended to be public.
• PeopleSoft: external POST requests to /PSEMHUB/hub or /PSIGW/HttpListeningConnector, outbound SMB (TCP 445) from PeopleSoft hosts to external addresses, bursts of internal SSH logins from one PeopleSoft host to others, and MeshCentral agents or connections to azurenetfiles[.]net.
• Endpoint (only in a ShinySp1d3r scenario): remotely created services, new GPO startup scripts, cross-host process creation over WMI, shadow-copy deletion, and bursts of wipe-<random>.tmp files.

What to do if ShinyHunters is active in your environment

An identity-driven intrusion inverts the usual ransomware playbook: the account is the compromise, and there may be no host to isolate at all.

1. Contain compromised identities promptly. Revoke active sessions and refresh tokens, reset compromised passwords, remove attacker-registered MFA methods, and revoke suspicious connected apps and OAuth grants. Coordinate with integration vendors to revoke compromised tokens they control.
2. Close the exposed access route. If Salesforce Experience Cloud guest access exposed records, temporarily disable the affected site or guest access while correcting permissions. For exploited applications, apply vendor mitigations before restoring service.
3. Temporarily restrict new MFA/device enrollment and self-service password resets during active containment. Route necessary password and MFA resets through the help desk using high-assurance manual identity verification.
4. Preserve identity and SaaS evidence. Export Okta or Entra logs, the Salesforce Setup Audit Trail and Event Monitoring data, the Microsoft 365 Unified Audit Log, and Google Workspace OAuth and Gmail logs before they roll off. Keep all extortion correspondence. The same discipline in our guide to preserving ransomware evidence applies here.
5. Engage counsel while scoping the breach. Determine which objects, records, and mailboxes were accessed or downloaded and in what volume. Counsel can assess notification duties and deadlines based on the data, jurisdictions, and organization involved, including requirements that may apply to healthcare, education, and public companies.
6. Rotate secrets found inside the stolen data. CRM cases and support tickets may contain API keys and cloud tokens that attackers can use to extend access.
7. Prepare for harassment. Brief employees that threatening calls, texts to family members, and swatting are documented pressure tactics; open a line to local law enforcement and stage DDoS mitigation.
8. Respond to host-based activity according to the access route. Isolate affected hosts and preserve volatile evidence where feasible. For PeopleSoft, check for webshells and propagation scripts; for unauthorized MeshCentral, identify its agents; for suspected ShinySp1d3r use, check for remotely created services, GPO startup scripts, WMI deployment, and wipe-<random>.tmp files.

Can data stolen by ShinyHunters be recovered, and can ShinySp1d3r files be decrypted?

Stolen data cannot be made secret again, and once records are in the group's hands, deletion of the attacker's copies cannot be verified.

Treat leaked data as permanently public. In June 2026, the group announced new mirrors and plans for torrent distribution, claiming leaked files would remain publicly accessible indefinitely. Exposed records can support targeted phishing and impersonation; credential stuffing is a risk when usable username-password pairs are exposed. When publication is confirmed, Magdy Abdelaziz, Proven Data’s Head of DFIR, advises: “Capture the leak site listing, the timestamps, and samples of the published data; your own counsel will need all of it.”

ShinySp1d3r: the encryptor in development

ShinySp1d3r is a ransomware-as-a-service encryptor first mentioned on SLSH Telegram channels in August 2025. A development build surfaced in November 2025. Only Windows development builds have been analyzed, and no deployment in a real incident has been documented as of September 2026. Actors in this orbit have previously deployed other operators' encryptors (ALPHV/BlackCat, Qilin, RansomHub, and DragonForce), so encryption is a possibility to plan for, not an expectation.

The analyzed build encrypts file data with ChaCha20, protects the encryption key with RSA-2048, and appends a unique extension to each encrypted file. It hooks EtwEventWrite in the encryptor process to suppress some user-mode ETW events, terminates processes holding file handles, deletes Volume Shadow Copies, and overwrites free disk space with wipe-<random>.tmp files to defeat deleted-file recovery.

The analyzed build also attempts to encrypt open network shares and includes routines to deploy the encryptor to other devices via service creation, WMI, or a GPO startup script.

The group also claims to be developing Linux and ESXi variants, but this remains unverified.

No public ShinySp1d3r decryptor is known. If this scheme is implemented correctly, brute-force recovery is not feasible. Were it ever deployed, ransomware recovery could involve restoring from clean backups, exploiting a flaw in the encryptor, or seeking a decryption key through negotiation, if counsel and the IR team decide to pursue it.

A ransom payment cannot verify deletion of stolen data or guarantee decryption. Evaluate any payment only with qualified legal counsel and an incident response team after assessing the legal, operational, recovery, and notification consequences.

Security checklist

• Phishing-resistant MFA (FIDO2 security keys or passkeys), enforced without weaker fallback. This prevents authentication through look-alike sign-in pages using only a stolen password and one-time code.
• Alert on new MFA-factor enrollment; preserve security notifications and audit logs outside user mailboxes. Counters the attacker-registered device and the ToogleBox Recall notification-deletion pattern.
• Help desk identity verification for resets, MFA changes, and device enrollment. Reduces the risk of attackers impersonating employees when calling the help desk.
• Limit third-party integration permissions and require admin approval for new Salesforce connected apps. This reduces exposure from stolen tokens and malicious app grants.
• Device trust and conditional access on SSO, without legacy exceptions. Blocks new sign-ins from unmanaged devices even with a stolen password and code. In Microsoft Entra, block device-code and authentication-transfer flows unless there is a documented business need.
• Review object, record, and field permissions for Salesforce Experience Cloud guests. Disable guest API access where unnecessary; where it is required, allow access only to data intended to be public.
• Secrets scanning and DLP on CRM records and support tickets. The operators mine stolen data for keys to the next platform.
• Verified callback procedure for any unsolicited "IT" call. Voice phishing is a recurring initial-access vector in these campaigns.
• Disable the PeopleSoft Environment Management Hub where feasible. If it cannot be disabled, block external access to both /PSEMHUB/* and /PSIGW/HttpListeningConnector, and follow Oracle's CVE-2026-35273 remediation guidance. This addresses the documented PeopleSoft exploitation path.
• Monitor unexpected service creation, remote WMI execution, and GPO startup-script changes; maintain isolated backups. These controls address capabilities found in ShinySp1d3r development builds.