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 (Mandiant, UNC5537, June 10, 2024).
- August 2025: Salesforce customers, via OAuth tokens stolen from Salesloft Drift (GTIG, UNC6395, August 26, 2025).
- November 2025: Salesforce again, via Gainsight OAuth tokens affecting more than 200 instances.
- April 2026: Snowflake again, via Anodot tokens.
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.
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
Three 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
Different skills, same outcome: valid access that behaves like a legitimate user or application.
No exploits. No malware. Simple identity abuse.
The part most SecOps teams miss
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 (FBI FLASH CSA-2025-250912, September 12, 2025; GTIG, June 2025).
- 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 three 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.
The entry point changes. The behaviour after authentication does not.
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, and it no longer covers the access path.