On April 11, 2026, a leak-site post branded ShinyHunters claimed roughly 80 million records from Rockstar Games. The access path was not Rockstar. It was Anodot, a SaaS analytics vendor sitting in Rockstar’s supply chain. Stolen Anodot authentication tokens were used to query downstream data platforms. Different victim.
Different vendor. Same pattern.
What matters isn’t the platform of final impact. It’s how access was obtained and abused.
Every few months, another headline lands
The headlines repeat:
- 2024: Snowflake customers, via credentials harvested from infostealer logs going back as far as 2020.
- August 2025: Salesforce customers, via OAuth tokens stolen from Salesloft Drift. Google estimated more than 700 downstream organizations were potentially exposed in this single vendor pivot.
- November 2025: Salesforce again, via Gainsight OAuth tokens affecting more than 200 instances.
- April 2026: Snowflake again, via Anodot tokens.
- June 2026: Salesforce customers again, via Klue’s integration backend. A stale, neverrotated service-account credential was used to authenticate to Klue’s systems; a malicious code update then harvested OAuth tokens connecting Klue to customers’ Salesforce, Gong, HubSpot, and Slack instances. Automated scripts queried the Salesforce REST API at roughly 1,000 calls per 15 minutes for 24 continuous hours. Salesforce disabled the Klue Battlecards integration on June 11, 2026. Icarus conducted the intrusion; ShinyHunters claimed credit at the extortion stage. Microsoft tracks this activity as Storm-3138.
Different entry points. Different platforms.
The pattern stays the same because ShinyHunters is not a single group. It is a brand applied at the moment of extortion.
The June 2026 Klue breach illustrates this precisely. Icarus conducted the intrusion. ShinyHunters claimed credit at the extortion stage. Different operator, same brand. The Salesforce audit log recorded legitimate connected-app API calls throughout. Nothing in the customer environment indicated a compromise in progress.
If you treat it as one threat actor, you risk looking in the wrong place. Track the behaviour, not the brand.
The real common thread
Four different access methods recur across campaigns attributed to ShinyHunters:
- Stolen credentials used to sign in
- Helpdesk social engineering (vishing) to reset MFA and gain access
- OAuth/token abuse via compromised SaaS vendors
- Misconfigured guest access to SaaS endpoints (Salesforce Aura framework exploitation via unauthenticated GraphQL queries, documented June 2026)
Different skills, same outcome: valid access that behaves like a legitimate user or application.
Public reporting highlights Snowflake or Salesforce because that's where data is ultimately taken. But the access path is identity.
In most enterprise environments, that identity is federated into platforms like Microsoft 365. That makes M365 one of the first places this activity becomes visible. Not because it's the target, but because it's where the compromised identity operates.
Anatomy of a ShinyHunters-style attack
No matter the entry method, the attack follows a similar path:
- Access: sign in using valid credentials or tokens.
- Establish: make that access persistent.
- Expand: explore data across SaaS applications.
- Exfiltrate: extract data from downstream systems.
Snowflake and similar platforms sit at the final step. Everything that matters for early detection happens before that.
What you can actually see before stages of Impact
Initial Access: a "normal" login that isn’t normal
The login succeeds. But:
- The location is new
- The connection originates from a VPN or proxy infrastructure such as Mullvad, Oxylabs, NetNut, or a Tor exit node.
- The actions post-login don’t match the users behavioral baseline.
Within an identity provider like Entra ID, this appears to be a legitimate successful sign in. When viewed with enough context, it isn’t.
Persistence: making the access stick
Once inside, the actor makes sure they can return:
- New MFA methods enrolled
- New devices registered
- Oauth applications granted access
Each action is legitimate on its own. Together, in the minutes after a fresh login, they tell a different story.
Exploration: moving through SaaS
Before the data warehouses are accessed, attackers move through systems employees use every day. For many organizations that means Microsoft 365 or similar SaaS platforms:
- SharePoints and OneDrive enumeration
- Access to document libraries the user has never touched
- Keyword searches for sensitive content
- Broad file access
In this stage the attacker is asking a simple question: What can this compromised identity access?
Following this, they expand to other SaaS platforms and downstream data systems.
Different methods, same signals
The pattern holds across all four approaches:
- Stolen credentials (2024): unusual but successful login
- Vishing and MFA bypass (2025–2026): login followed by rapid persistence activity and SaaS enumeration.
- Vendor/OAuth compromise (2025–2026): trusted application access behaving anomalously.
- Guest access misconfiguration (2026): API calls at volume from an unauthenticated guest context. No sign-in event to alert on.
The entry point changes. The behaviour after authentication does not.
Case study: the Klue breach, June 2026
The Klue breach is the cleanest recent illustration of the supply chain path. The attacker (tracked as Icarus, later claimed by ShinyHunters at extortion) used a stale, never-rotated service-account credential to authenticate to Klue’s integration backend. No exploit. The credential was valid and was issued by the organisation. No anomaly at login.
A malicious code update then harvested OAuth tokens connecting Klue to customers’ Salesforce, Gong, HubSpot, and Slack instances. Tokens transferred over encrypted channels. Looks like a routine code deployment. No malware signature. From there, automated Python scripts queried the Salesforce REST API at roughly 1,000 calls per 15 minutes for 24 continuous hours. Every API call authenticated with a valid token, indistinguishable from normal integration traffic. CRM data exfiltrated at scale.
Salesforce disabled the Klue Battlecards integration on June 11. Recorded Future, Tanium, Jamf, and Huntress were among the organisations notified. Microsoft tracked the cluster as Storm-3138 in its July 13, 2026 disclosure.
On the attribution question: the above anatomy correctly attributes this to Icarus as the operator. ShinyHunters claiming it at extortion is not a correction to the attribution. It is the point. The brand gets applied at the moment of extortion, by whoever conducts the operation. Leave the Icarus operator attribution on the slide and add a note that ShinyHunters claimed credit at extortion, because that distinction is exactly what the “track the behaviour, not the brand” argument is built on.
Where Vectra AI fits
ShinyHunters campaigns succeed because they use legitimate access: real credentials, real MFA flows, real OAuth tokens, real applications. Most security controls are designed to stop attackers before authentication. These campaigns succeed after.
Vectra AI detects attacker behaviour after authentication succeeds, across identity, SaaS, cloud, and network. The question is not "how was access obtained?". It is: does the identity’s actions align to its behavioral profile?
How detection maps to the attack pattern
Access: a successful login from a new location, from proxy infrastructure, that does not match the identity’s baseline.
Establish: MFA methods added, devices registered, OAuth applications granted, immediately after login.
Expand: activity correlated across Microsoft 365, Salesforce, and other SaaS, surfacing accounts that are exploring in ways they never have before.
Exfiltrate: bulk downloads and API extraction surfaced as the end of a sequence, not as isolated events.
Why this works across all methods
It does not matter how access was obtained: stolen credentials, a helpdes phone call, or a compromised vendor token. The attacker still has to sign in, establish persistence, explore, and exfiltrate data. The behavioral pattern is unavoidable. That is what Vectra is designed to detect.
Closing the detection gap
Standard advice still matters: phishing-resistant MFA, credential rotation, OAuth scope review, helpdesk identity verification (see GTIG’s UNC6040 hardening recommendations, and the FBI FLASH advisory). It is no longer enough on its own. Modern campaigns are designed to pass those controls.
Detection isn’t broken. It’s incomplete.
ShinyHunters isn’t a single group. It is a pattern of attacks built around one idea: If authentication succeeds, the attacker can masquerade as a benign identity.
The earliest signals don’t appear in the data platform named in the headlines. They appear in Identity and SaaS platforms where the attacker must first operate. The problem is not visibility. It is starting detection at the wrong point in the attack.
In my Mind Your Attack Gaps ebook, I describe three detection gaps. ShinyHunters lives in Gap 2: authentication succeeds. Real credentials, real one-time codes, real OAuth tokens, real session cookies. The audit log records a successful sign-in.
The 2024 hardening playbook is still correct, but it no longer covers the access path.