For more than a year, one of the most consequential breach campaigns against enterprise CRM data never touched a password. According to a Microsoft Security Blog analysis published July 13, the threat cluster tracked as ShinyHunters pulled data out of Salesforce customer tenants across retail, education, and manufacturing not by cracking credentials, but by getting a human, or a trusted integration, to hand access over voluntarily.
Three Doors Into the Same CRM
Microsoft’s research team mapped the ShinyHunters-linked campaign, running from mid-2025 through mid-2026, into three distinct intrusion paths that all end at the same target: Salesforce customer relationship management data.
Vishing and OAuth Consent Abuse
Beginning in mid-2025, attackers called employees while impersonating internal IT support. Instead of asking for a password, they walked victims through Salesforce’s own OAuth consent screen and asked them to authorize a connected application disguised as the legitimate “Data Loader” tool. Once approved, the attacker-controlled app inherited the user’s API access and could query CRM records directly, without ever triggering a password reset alert or a suspicious-login flag.
Supply Chain Compromise Through Trusted Integrations
The second path ran through vendors that Salesforce customers already trusted. Microsoft ties compromised Salesloft Drift credentials in August 2025, and compromised Gainsight-published integrations in November 2025, to downstream access into multiple customers’ Salesforce instances. A third, related incident in June 2026 involved the actor tracked as Storm-3138 obtaining Salesforce credentials through the Klue market-intelligence platform. In each case, the initial compromise was one step removed from Salesforce itself, inside a connected app the customer had already approved.
Guest Access Misconfiguration
The third path targeted Salesforce Experience Cloud sites with permissive guest-user settings. Microsoft found attackers sending unauthenticated, GraphQL-based requests against the Aura framework endpoints those sites expose, letting them enumerate and pull CRM records at volume while sidestepping the record-count limits normal guest sessions are supposed to enforce.
Why Trust, Not Malware, Is Now the Attack Surface
None of the three paths required malware on an endpoint. Each abused a legitimate trust mechanism the Salesforce platform is designed to offer: an OAuth grant, a partner integration, a guest profile. That is the through-line Microsoft’s writeup draws, and it fits a pattern this publication has tracked with the same threat cluster before. A separate ShinyHunters-linked campaign against Oracle PeopleSoft customers, reported here in June, breached more than 100 organizations by exploiting a platform vulnerability rather than a trust relationship, but landed on the same outcome: bulk extraction of business-critical records from a SaaS system of record. Coordinated attention from Western governments on this actor cluster’s broader activity has followed; a joint EU, UK, and US action against Russia-linked units, covered here last week, shows the same appetite for treating platform-abuse campaigns as a named, tracked threat rather than a one-off incident.
The common signal Microsoft calls out across all three ShinyHunters paths is anomalous API query volume against Salesforce, not a login anomaly. That is a meaningful detail for defenders who have built their detection stack around credential and endpoint telemetry: a CRM tenant can be drained through channels that authentication logging never sees.
Scale Is the Point
Salesforce is not incidental to this campaign; its scale is the reason ShinyHunters returned to the platform through three separate paths over a year instead of moving on after the first one closed. A single Experience Cloud misconfiguration, one compromised integration partner, or one successful vishing call can each reach the same underlying store of customer records, which means a defender who closes one door without checking the other two has not actually reduced risk. Microsoft’s decision to publish all three paths together, rather than as separate incident writeups, is itself a signal that the company sees this as one sustained campaign against SaaS trust models generally, not three unrelated intrusions that happen to share a target.
The same logic extends past Salesforce. Any SaaS platform that supports OAuth-connected third-party apps, guest-accessible customer portals, or partner integrations with API scope presents the same three doors. Security teams that treat this as a Salesforce-specific advisory, rather than a pattern to check against every core SaaS platform in the environment, will have solved the instance without touching the underlying exposure.
What This Means for the Security Leader
OAuth consent has quietly become a governance problem, not an IT admin setting to configure once and forget. Every connected app a user approves inherits that user’s standing permissions, and Microsoft’s own guidance is to treat any app inactive for 90 days or more as a candidate for revocation, not a low-priority cleanup item.
SaaS-to-SaaS integrations are supply chain risk now, on the same footing as an on-premises vendor with network access. Salesloft and Gainsight were not the attackers; they were the compromised middle step that inherited access the customer had already granted. Vendor risk reviews that stop at “does this vendor touch our network” miss the integrations that touch a CRM tenant’s API instead.
Guest-accessible Experience Cloud sites need the same scrutiny security teams give an externally exposed network segment. An Aura endpoint left with default guest permissions is functionally an unauthenticated data export path.
What Defenders Should Do
Connect core SaaS platforms, starting with Salesforce, to a cloud access security broker or SaaS security posture tool for visibility into every connected-app grant; Microsoft names its own Defender for Cloud Apps as one option, but the control matters more than the vendor. Inventory every OAuth-connected application against the CRM and revoke anything dormant for 90 days or longer. Audit Experience Cloud guest profiles down to the specific objects and fields a guest session actually needs, not the platform default. Add vishing against IT support, rather than email phishing, to the next tabletop exercise, since the entry point in the first attack path was a phone call, not a link. Finally, monitor Salesforce event logs for API query-volume anomalies as a first-class detection signal, on par with authentication logging, since it was the one indicator common to all three paths Microsoft documented.
Source: Microsoft Security Blog
