Nobody Logged In: How ShinyHunters Emptied Hundreds of Salesforce Tenants Through OAuth Grants Nobody Owned

Three times in ten months, ShinyHunters and actors associated with them have taken data out of hundreds of Salesforce tenants without logging in to a single one of them.

No password was guessed. No MFA prompt was answered. No sign-in alert fired, at any of the victims, in any of the three incidents. The queries arrived through connected applications those organisations had approved, holding tokens those organisations had granted.

The interesting question is not how the integrations were compromised. It is why an approved OAuth grant is the one credential in most environments that nobody owns, nobody reviews, and nothing watches.

//Three Incidents, One Shape

Salesloft Drift, August 2025

The largest of the three. More than 700 organisations affected, including Cloudflare, Zscaler and Palo Alto Networks. Google tracks the activity as UNC6395.

The entry point was not Salesforce. Access to a GitHub account in March 2025 was pivoted into an AWS environment, and from there the attackers took the OAuth and refresh tokens Drift held for its customers. Those tokens were then used to query each customer's Salesforce API directly.

Five months between the initial GitHub access and the exfiltration window of 8 to 18 August. That gap is worth sitting with. The compromise that mattered happened at a vendor, months earlier, in a system with no obvious relationship to anybody's CRM.

Gainsight, November 2025

More than 200 Salesforce instances, attributed by Google Threat Intelligence to ShinyHunters-affiliated actors. Detected through anomalous API activity via published applications.

CSA notes the possibility that this was token reuse from the earlier Salesloft compromise rather than a fresh intrusion. If that is right, it means revocation after the August incident was incomplete somewhere, and stolen tokens stayed valid for three months across an entirely separate vendor relationship.

Klue, June 2026

195 Klue customer organisations exposed over two days, 11 and 12 June. Microsoft tracks this activity as Icarus, also referenced as Storm-3138.

The entry point is the detail worth remembering: a four-year-old dormant test credential that was never deactivated. The attackers used it to push a credential update that deployed code harvesting customers' OAuth tokens.

Among the 195 were Huntress and Recorded Future. Two security vendors, in a campaign about third-party risk. Nobody is buying their way out of this one.

//The Blind Spot, Stated Plainly

CSA's finding is the sentence the whole article turns on: standard Salesforce authentication and sign-in monitoring did not flag any of the three incidents, because the malicious queries arrived through already-authorised connected-app sessions.

Think about what a connected app actually is. At some point somebody approved an integration. That approval minted a refresh token with a scope, and that token does not expire on a human timescale, does not prompt for MFA, does not trigger conditional access, does not generate an interactive sign-in event, and does not appear in the place your team looks when they ask who accessed what.

Every identity control most organisations have bought is built around the moment a human authenticates. An OAuth grant is specifically a mechanism for not having that moment again.

So the attacker inherits a permanent, MFA-exempt, audit-quiet credential with API scope over your CRM, and the only thing standing between them and it is the security of a vendor you evaluated once, possibly years ago, in a procurement process.

Why the source looks right too

There is a second layer to this. Queries arriving from the integration's infrastructure are supposedto come from there. Geographic anomaly detection, impossible-travel rules and source reputation all evaluate normally, because the traffic really is coming from the vendor's cloud environment doing the thing it is contracted to do.

The only thing abnormal is volume and intent, and those are the two hardest things to baseline.

//What Actually Works

Inventory every OAuth-connected application. Most organisations cannot produce this list on request, which is the first problem. You cannot revoke what you have not enumerated, and every one of these incidents ended with customers being told to revoke tokens for a specific vendor across a specific window.

Treat a third-party OAuth grant as a privileged account.CSA's framing, and it is the right one. That means a named owner, a written business justification, a review date, and automatic revocation when the integration is decommissioned or the contract ends. If a service account with API access to your entire CRM went through your access review process, it would not survive it. The OAuth grant is that account, and it never entered the process.

Separate read and write scopes. Most integrations are given both because it is easier. Most need one.

Turn on connected-app event monitoring specifically. Not sign-in monitoring - that is what failed. You need per-application API query volume, and an alert when an integration that normally pulls a few hundred records a day pulls a few hundred thousand.

Kill dormant credentials on a schedule. Klue was entered through a test credential that had been sitting unused for four years. That is not an exotic failure and it is not unique to Klue - it is in every environment that has existed for four years.

Assume revocation was incomplete. The Gainsight-may-be-Salesloft-token-reuse possibility is the uncomfortable one. After an incident like this, verifying that revocation actually took effect is a separate task from requesting it.

//The Structural Point

Supply chain security discussion is dominated by code: dependencies, build systems, signed artifacts. This site published a piece two weeks ago on exactly that, covering an npm worm and a macOS infostealer that both attack the build step.

This is a different supply chain and arguably a worse one. There is no artifact to scan, no hash to check, no provenance to verify. The compromised thing is a permission you granted, and the attack is indistinguishable from the integration working normally.

The shared lesson with the build-step attacks is the same one: the control that was supposed to help - signed provenance there, an approved and authenticated integration here - is precisely what the attacker inherits. Approving an OAuth app is not a one-time decision that ends. It is the creation of a standing credential, and it should be logged, owned and reviewed like one.

//Sourcing and Uncertainty

The victim counts (700-plus, 200-plus, 195), the named affected organisations, the entry vectors, the actor designations and the dates are from the Cloud Security Alliance research note of 16 July 2026 and Microsoft's 13 July 2026 write-up. The finding that sign-in monitoring failed across all three incidents is CSA's, quoted closely because it is the load-bearing claim.

Deliberately not reproduced: a figure of 1.5 billion records has circulated widely for this campaign. It does not appear in either primary source used here, so it is not stated as fact. The organisation counts are well sourced; the record total is not, and a number that large repeated without a source is exactly the kind of thing that costs a site its credibility.

The Gainsight-as-token-reuse link is presented by CSA as a possibility, not a finding, and is presented that way here.

The interpretation is mine: the argument that an OAuth grant is structurally a privileged account that escaped access review, the observation that source-based anomaly detection cannot work when the source is legitimately the vendor, and the comparison to build-step supply chain attacks.