<entry_summary>Attackers linked to ShinyHunters used OAuth connections to breach corporate Salesforce environments via vishing, stolen vendor tokens, and misconfigured guest access. This campaign bypassed traditional identity controls by exploiting trusted third-party integrations and unmonitored API activity. Major victims included Google, Chanel, and various technology companies across retail, education, and manufacturing sectors.</entry_summary>
| IOC Type | Value | Description | Relevant MITRE ATT&CK Techniques |
|---|---|---|---|
| Malwarename | Salesforce Data Loader | A malicious connected app posing as the legitimate Salesforce Data Loader tool used during vishing attacks. | T1566.002 |
| Malwarename | AuraInspector | Tooling used to probe Salesforce Aura endpoints for misconfigured guest access. | T1083 |
| Code | Title |
|---|---|
| T1566 | Phishing (Vishing) |
| T1528 | Steal Web Session Cookie (OAuth Token Theft) |
| T1539 | Steal Web Session Cookie |
| T1082 | System Information Discovery (SOQL queries) |
| T1078 | Valid Accounts (Misconfigured Guest Access) |
| T1566.002 | Phishing: Spearphishing via Vishing |
| T1083 | File and Directory Discovery |
| T1659 | Validity Period (OAuth token exploitation) |
| Type | Value |
|---|---|
| Company | Adidas |
| Company | Allianz Life |
| Company | Chanel |
| Company | Cloudflare |
| Company | |
| Company | Huntress |
| Company | Klue |
| Company | LVMH |
| Company | PagerDuty |
| Company | Palo Alto Networks |
| Company | Pandora |
| Company | Proofpoint |
| Company | Qantas |
| Company | Recorded Future |
| Company | Tanium |
| Company | Zscaler |
| Sector | Education |
| Sector | Manufacturing |
| Sector | Retail |
Attackers whose methods line up with the data-extortion group ShinyHunters have spent the past year walking into corporate Salesforce environments without exploiting a single flaw in the platform. The way in has been the trust the organization had already extended, usually through the OAuth connections that tie Salesforce to the apps and third-party vendors around it. In research published July 13 , Microsoft mapped the campaigns, which ran from mid-2025 into mid-2026, to three distinct techniques. It also worked with Salesforce to roll out new detection and governance tooling aimed at addressing the activity authentication logs miss. That is what makes this hard to catch. When the access comes from a real user who approved a connected app, or from an integration the company already trusts, the traffic reads as ordinary use, and sign-in and authentication monitoring barely registers it. What matters is what the app or account does once it is in, and that is exactly what most Salesforce logging was not built to show. Microsoft groups the activity into three intrusion paths: vishing calls that trick employees into approving a malicious connected app, stolen OAuth tokens from compromised software vendors, and misconfigured guest access to Salesforce sites. Each maps onto a Salesforce incident from the past year, and Microsoft says it saw the activity across tenants in industries including
Once consent was granted, the app could make API calls as that user, letting the attackers enumerate the org's Salesforce data, hold persistent access to CRM records, and hunt for credentials that might open the door to other SaaS platforms. No malware, no stolen password replay. Just a phone call and a consent click. This is the campaign
Guest access left open The third path needs no credentials at all. Microsoft saw a rise in suspicious guest-user activity against Salesforce Aura endpoints, the framework behind Experience Cloud sites. Where guest-user permissions were misconfigured, the actors reached Aura functionality without authenticating. Calling the GraphQL Aura controller, they used cursor-based pagination to pull records past the standard 2,000-record query limit, walking off with far more than the guest role was meant to expose. Microsoft's related detection points to the
Shrinking the OAuth attack surface Microsoft's guidance is practical and matches what the vendors said after each incident: connect Salesforce instances to Defender for Cloud Apps for the extra telemetry, turn on and actually watch Salesforce event logs, and lock down Experience Cloud guest-user access. Beyond the product-specific steps, the durable fixes are the familiar ones. 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 starts behaving oddly. The pattern under all three paths is the same. The identity controls most companies spent the last decade building were made for human logins: MFA, conditional access, and session policies. The OAuth apps, integration accounts, and service credentials that do the actual work in a modern Salesforce stack mostly sit outside all of it, unwatched and over-permissioned. The attackers who figured this out ran it for a year, and more than once, the way in was nothing more exotic than a credential someone forgot to switch off. The Hacker News has reached out to Microsoft for further details on its attribution of the actors behind these campaigns and will update this story with any response.