A year of ShinyHunters OAuth abuse, mapped by Microsoft

Microsoft’s threat intelligence team published a retrospective on 2026-07-13 covering roughly a year of activity against corporate Salesforce environments by actors whose tradecraft they say is “commonly associated with ShinyHunters.” The line that decides how the rest of the post reads sits near the top: “This activity was not the result of a vulnerability inherent to Salesforce.” No CVE. No unpatched bug. No zero-day in an appliance somewhere. The way in — three different ways in, actually — was trust the customer had already extended and never gotten around to withdrawing.

Microsoft breaks the year into three tradecraft paths. The first is the one the industry has been chewing on since summer: vishing a helpdesk or sales-ops user into approving a malicious “connected app” that presents itself as a legitimate Salesforce Data Loader or similar tool. The user clicks approve, the OAuth grant is real, the data pull that follows is real, and no login-anomaly detector fires because there was no anomalous login — the org authorized the app.

The second path is the SaaS supply chain, and reading Microsoft’s own timeline back-to-back is the part that should slow anyone down. August 2025: Salesloft Drift OAuth tokens stolen, used to reach the Salesforce tenants that had connected Drift. November 2025: a wave through apps published on the Gainsight platform. June 2026: Klue, which Microsoft attributes to a cluster it tracks as Storm-3138 and which BleepingComputer notes was separately claimed by an actor calling itself “Icarus.” Three different intermediaries, over about ten months, each one a vendor a Salesforce customer had long ago consented to and then stopped thinking about. The customer’s identity model wasn’t broken; the customer’s memory was.

The third path is the misconfigured Salesforce Experience Cloud site still exposing enough via guest-user permissions and the Aura framework for an attacker to pull records the site’s owner didn’t intend to make public. Microsoft points readers at Salesforce’s own hardening guide for guest users, which has been sitting there for years. That’s, again, the pattern.

Analysis

There is a version of this story where the punchline is “OAuth is dangerous” and the moral is that trust models designed in 2012 don’t age well. That version isn’t wrong, exactly, it’s just too easy. OAuth as specified isn’t broken; the drift is entirely in how organizations operate the consent surface after grant. A connected app approved in 2022 for a pilot that ended in 2023 is still there in 2026, still authorized, still able to read what its scopes let it read, and probably not on anyone’s inventory. Microsoft’s recommendation to review and revoke apps unused for 90 or more days is a defensible starting number, but the honest read is that most orgs have never revoked a connected app on that basis and don’t have the telemetry to know which ones are dormant. Salesforce’s Real-Time Event Monitoring gives you that telemetry, if you have the SKU and the discipline to watch it.

The industries Microsoft names — retail, education, manufacturing — are worth pausing on. None of them are stereotypical “we have a large SOC” buyers. They’re organizations with real customer data in Salesforce and, usually, a small identity team stretched across a lot of SaaS. That is also the profile of the org most likely to have said yes to a friendly vendor five years ago and then never looked at that trust relationship again. The vendor gets acquired, or its product gets replaced, and the grant lingers. The consent screen is a gatekeeper that only exists at the moment the click happens. After that, the gate is just open.

The list of intermediaries reads like a decade of SaaS strategy: sales engagement, customer success, competitive intelligence. Each one integrated because integration was the point of buying it — that’s not a critique, that’s what SaaS is. But it means the organization’s external attack surface, in the identity sense, is not a firewall perimeter. It’s the set of every third party the org has ever consented to touch its customer data, minus whatever it has since withdrawn — which is often nothing.

What to actually do this week

• Pull the connected-app inventory in each Salesforce org. Compare it to a list of vendors your procurement team recognizes today. The delta is the interesting part.
• Revoke apps that have not been used in 90 days, unless you can produce a business owner who will vouch for keeping them.
• Turn on and actually watch Real-Time Event Monitoring for connected-app activity — the volume, the scopes, the users approving new grants.
• Audit Experience Cloud sites for guest-user permissions using Salesforce’s Guest User Access Report and lock down Aura endpoints that expose more than the site’s purpose requires.
• If you licence Microsoft Defender for Cloud Apps, the Salesforce connector is the specific tool Microsoft’s post recommends and will surface anomalous OAuth-app data pulls.

Microsoft’s post pointedly does not name individual victim companies, though third-party outlets have been tying the broader campaign to a long list including retail brands and airlines. What matters for the reader who has to actually decide whether their org is exposed isn’t that list. It’s whether anyone has looked at the connected-app page since the last time someone rotated a Drift or Gainsight token — which, for a lot of orgs, was never.

Related coverage on this desk: Politie points at Dutch hackers in the 88GB Odido leak (the vishing-into-consent path in action) and the Jscrambler npm post-mortem (a different flavor of trusted-integration abuse — same underlying shape).