For a year, a data-extortion group has walked into dozens of Salesforce environments without exploiting a single flaw in the platform. The way in has been the trust the organisation had already extended: the OAuth connections that tie Salesforce to the apps and vendors around it. On 13 July 2026 Microsoft published research that sorts the campaign — attributed to ShinyHunters activity — into three distinct paths, none of which leaves a trace in sign-in logs. If you run Salesforce (or any SaaS with connected apps), this applies to you.
The interesting fact runs through the whole case: there was no malware, no replayed stolen passwords, no exploit against Salesforce. There were approved connected apps, legitimate vendor tokens and misconfigured guest permissions. When access comes from a real user who approved an integration, or from a vendor the company already trusts, the traffic reads as ordinary use and identity monitoring barely registers it.
According to Microsoft's security blog, as reported by The Hacker News, the campaigns ran from mid-2025 into mid-2026 and were seen across sectors including retail, education and manufacturing. What follows is the anatomy at a conceptual level — no reproducible recipes — and, above all, what to watch and what to close in your own estate.
Three paths, no exploit
Microsoft groups the activity into three intrusion paths: voice-phishing (vishing) calls that trick an employee into approving a malicious connected app; OAuth tokens stolen from compromised software vendors; and misconfigured guest access to Salesforce sites. Each maps onto a real incident from the past year, and all three share one trait: what matters is not how the door opens, but what the app or account does once inside.
1. The phone call
This is the path that started it all. From mid-2025, the actors placed phone calls posing as IT support and walked the employee through Salesforce's OAuth consent screen until they authorised an attacker-controlled connected app dressed up as Salesforce's own Data Loader tool. Once consent was granted, the app could make API calls as that user: enumerate the organisation's data, hold persistent access to the CRM, and hunt for credentials that might open other SaaS platforms.
No malware, no replayed password. Just a call and a consent click — which is why it sidesteps MFA: the attacker never signs in, they inherit the session of the app the user approved. This is the campaign Google's Threat Intelligence Group (GTIG) and Mandiant documented in mid-2025, tracking initial access as UNC6040 and the follow-on extortion as UNC6240; both kept claiming to be ShinyHunters to lean harder on victims. Google confirmed one of its own Salesforce instances was hit in June 2025, with the attackers taking largely public contact data before it cut them off.
2. Stolen tokens from trusted vendors
The second path skips the employee. Rather than phishing a user, the attackers compromise a vendor whose software already holds OAuth access to its customers' Salesforce orgs, steal the connection's secrets or tokens, and use them to query and export data across many instances at once. Because the traffic comes from an approved integration, it triggers no sign-in alarm and blends into normal automation.
The clearest case is the Salesloft Drift compromise of August 2025: the attackers stole OAuth and refresh tokens from the AI chat integration and turned them against customer environments. Google estimated the theft potentially exposed more than 700 organisations, as set out in Arctic Wolf's analysis; it tracks the group as UNC6395 and Cloudflare calls it GRUB1. Salesloft later traced the root cause to the attacker's access to its GitHub account as early as March 2025, used to reach its AWS environment and harvest the tokens; once inside, the operators ran queries to sift support cases for AWS keys, Snowflake tokens and passwords, then deleted their query jobs to slow investigators down.
The pattern repeated with Gainsight in November 2025 — Salesforce pulled the vendor's published apps after spotting unusual API activity, and GTIG tied it to ShinyHunters affiliates across more than 200 instances — and with Klue in June 2026, where the entry point was a legacy credential from an earlier integration that remained active. That is a common pattern in any organisation with years of accumulated integrations, and it is instructive for exactly that reason: credentials that outlive their purpose rarely show up in inventories. Microsoft tracks the Klue actor as Storm-3138, though much of the industry attributes that extortion to a group calling itself Icarus, and an account claiming to be ShinyHunters also took credit. The labels overlap because these identities are claimed opportunistically; it is worth keeping in mind when cross-referencing reports.
The group itself claimed the Salesloft and Gainsight waves together reached close to 1,000 organisations, and its leak site keeps posting alleged victims and record counts in the many millions. These are the attacker's own claims, not independently verified, and are best treated as such. A Cloud Security Alliance analysis frames this same set of campaigns as systematic OAuth abuse across the SaaS supply chain rather than a string of isolated incidents.
3. Guest access left open
The third path needs no credentials. Microsoft saw a rise in suspicious guest-user activity against Salesforce's Aura endpoints, the framework behind Experience Cloud sites. Where guest-role permissions were misconfigured, the actors reached Aura functionality without authenticating and, through cursor-based pagination, pulled records well past the standard 2,000-per-query limit. No exploit was involved: the organisation had let the guest role see more than it should, and they read it for everything it was worth.
Why traditional identity monitoring misses it
This is the crux. The identity controls most organisations built over the past decade were made for human logins: MFA, conditional access and session policies. But the OAuth apps, integration accounts and service credentials that do the real work in a modern Salesforce stack are non-human identities and mostly sit outside all of it — unwatched and over-permissioned.
That is why neither sign-in nor authentication raises a flag. The signal that does exist lives in what happens after access: which connected app made the call, what OAuth scopes it holds, how much it is querying, and whether any of that is normal for the tenant. That is precisely the layer most Salesforce logging was not built to show, and where the data exfiltration happens.
Detection: watch what the app does, not the login
Effective detection here is about behaviour and attribution, not signatures. Microsoft worked with Salesforce to surface that signal in Defender for Cloud Apps: for customers running Salesforce Shield Event Monitoring, the upgraded connector onboards near-real-time event monitoring and adds connected-app attribution — tying each activity to a specific app identity and its granted OAuth scopes, with more session and API context.
Alongside detection came posture and governance features for OAuth apps: a view of highly privileged apps holding elevated scopes, a way to surface unused apps that have sat inactive for 90 days or more while keeping live permissions, and a 0-to-100 risk score per app that teams can wire to alerts and policies. In practice, signals to watch: spikes in queries or bulk exports from an integration, broadly scoped apps that are barely used, and any change in a connected vendor's behaviour. A managed SOC with SaaS visibility and threat hunting capability is what turns those signals into detection.
Practical defence
The durable mitigation is the familiar one, applied to ground that had gone unwatched. Inventory the connected apps, cut the ones nobody uses, scope the rest to least privilege, and be ready to revoke and rotate tokens the moment an integration behaves oddly. Restrict which connected apps can be approved (admin approval rather than free user consent) and limit access by IP and profile. This is, in essence, non-human identity governance and third-party risk management brought to SaaS.
For the two paths that do not rely on an employee, two concrete fronts: lock down and review Experience Cloud guest access so the role exposes no more than necessary; and treat the OAuth tokens a vendor holds over your Salesforce as what they are — privileged third-party access, with periodic review and rotation. And because the first path is a phone call, the cheapest defence is process: faced with a support request pushing you to approve an app or grant access, the rule is to hang up and call back on a known-good channel. Reinforce social engineering and phishing awareness among the people who administer the CRM, not just end users.
None of this is unique to Salesforce. The same reasoning applies to Microsoft 365 and any suite with connected apps; in fact, inheriting the session without touching the password is a cousin of the token theft we covered in Microsoft 365 account takeover. And the compromised-vendor link is the one that runs through the digital supply-chain lessons and the warnings about compromised credentials from forgotten integrations.
Compliance: third parties, DORA and NIS2
The regulatory angle is direct. Under DORA, financial entities must manage the risk of their ICT providers and watch their third-party dependencies; a SaaS integration holding OAuth tokens over your CRM is exactly that kind of dependency. NIS2 pushes the same way for essential and important entities: supply-chain risk management and identity and access control as baseline measures. A vendor token that can export your CRM is not a minor technical detail — it is a third-party risk a regulator would expect to see managed.
The conceptual bridge to non-human identity governance is one we develop when comparing SPIFFE/SPIRE against OAuth in cloud-native environments and when discussing how to harden service accounts, tokens and API keys. The Salesforce campaign is the SaaS version of the same problem: the identity that does the real work is not the person — it is the app.
What actually fails
The takeaway is not that Salesforce is insecure — the platform was not exploited — nor that any one vendor was negligent. It is that the identity model almost every organisation takes for granted watches people and leaves the apps, tokens and integration accounts that move the data unwatched. The attackers who understood this ran it for a year, and more than once the way in was simply a credential someone forgot to switch off. The question the case leaves is short: do you know which connected apps have access to your SaaS, who approved them, and what they can take?
On sources and attribution: the incidents cited here draw on public disclosures by the affected companies themselves, on Salesforce communications and on threat intelligence reporting, reflecting the information available at the time of publication. None of these mentions implies a security flaw in the products named: the vector described is the abuse of granted access and misconfiguration. Attributions to specific groups may evolve — these actors' labels overlap and are claimed opportunistically — and figures circulated by the attackers themselves are not independently verified.
Note: this article includes detection and connected-app governance guidance applicable to SaaS environments. Validate it in a controlled environment and adapt it to your configuration and compliance framework before applying it in production.