Microsoft is warning that a year-long run of Salesforce-focused attacks has turned trusted OAuth applications, third-party integrations, and guest accounts into quiet routes for mass data theft. Detailed by Microsoft Defender Security Research on July 13, the campaigns were observed from mid-2025 through mid-2026 and used tradecraft commonly associated with ShinyHunters across retail, education, manufacturing, and other industries.
The attacks did not depend on a vulnerability in Salesforce itself. Instead, threat actors inherited legitimate permissions by persuading users to approve malicious applications, stealing tokens from trusted SaaS suppliers, or exploiting overly broad guest access. That distinction matters operationally: conventional sign-in alerts may remain silent because the resulting API calls appear to come from authorized identities and approved software.
Microsoft has responded by expanding Salesforce telemetry and OAuth application governance in Defender for Cloud Apps. For administrators, however, the immediate task is broader than deploying another detection rule: every connected application must now be treated as an identity with privileges, persistence, and its own supply-chain exposure.
Microsoft grouped the observed activity into three intrusion paths, beginning with voice phishing, or vishing. Attackers impersonated IT support personnel and guided employees through Salesforce’s OAuth consent process, convincing them to authorize an attacker-controlled connected application disguised as a legitimate Salesforce Data Loader tool.
Once consent was granted, the application could make API calls using the victim’s privileges. That enabled attackers to enumerate Salesforce environments, retain access to CRM records, and potentially discover credentials that could support movement into other SaaS services.
This technique bypasses several assumptions built into traditional account-security programs. There may be no malware to detect, no password to reset, and no suspicious replay of stolen credentials. The user completed a legitimate authorization workflow; the problem was that the application receiving permission was malicious.
The second path moved upstream into the SaaS supply chain. In August 2025, compromised credentials associated with Salesloft Drift gave attackers access to connection secrets and OAuth tokens used by downstream Salesforce customers. Salesforce subsequently disabled integrations with Salesloft technologies while the incident was investigated, stating that the event involved compromised app connection credentials rather than a weakness in its core platform.
A similar campaign targeted Gainsight-published Salesforce applications in November 2025. Microsoft said attackers used trusted external connections to conduct discovery, execute bulk queries, and exfiltrate accounts, contacts, service cases, and other CRM data without producing the failed logins or unusual authentication patterns defenders typically investigate.
The pattern resurfaced in June 2026 when market intelligence provider Klue detected unauthorized activity in its integration infrastructure. Klue said an attacker entered through a compromised legacy credential, obtained OAuth tokens used to connect to services including Salesforce, and accessed data in several connected customer environments. Microsoft tracks the actor involved in that incident as Storm-3138.
Klue revoked affected credentials and tokens, disabled potentially affected integrations, and brought in CrowdStrike to investigate. Its disclosure underscores the defining risk of SaaS integrations: compromise of one vendor can expose data held in numerous customer tenants without attackers separately breaching each organization.
Microsoft characterized these incidents as exploitation of misconfigured permissions, not a software vulnerability. By chaining requests, the attackers could reportedly retrieve substantially more information than administrators intended guest users to access, turning a public-facing Salesforce experience into an avenue for systematic data extraction.
This is an important warning for organizations that have concentrated their identity controls around employees, contractors, and service accounts. An unauthenticated guest profile can still carry meaningful application privileges, particularly where Experience Cloud sites have accumulated custom objects, legacy sharing rules, or broadly accessible fields.
All three methods converge on the same defensive problem: the attacker operates inside trusted access paths. A malicious connected app inherits a user’s rights, a compromised supplier inherits an integration’s rights, and an improperly configured guest inherits whatever Salesforce exposes to that profile.
The resulting traffic can resemble ordinary CRM automation. API requests arrive through expected interfaces, authorized applications query valid objects, and sessions may not produce the authentication anomalies that would normally trigger an identity-focused incident response.
That visibility is intended to answer questions which authentication logs alone cannot: which application issued a query, what permissions it held, which users and records it touched, whether it appeared from a new address, and whether its behavior departed from established patterns.
New detections cover suspicious scraping, anomalous API and report activity, unexpected connected-app endpoints, guest-user anomalies, and Salesforce Aura activity associated with the AuraInspector framework. Defender can also correlate Salesforce events with risky identities and activity elsewhere in Microsoft’s security stack.
Microsoft is adding preventive controls alongside detection. Defender’s inventory for Salesforce connected and external client applications now identifies granted permissions, highlights highly privileged apps, and surfaces integrations that have remained unused for extended periods, such as 90 days or longer.
Connected applications also receive a risk score from zero to 100, calculated from factors including sensitive permissions, behavioral signals, and usage patterns. Administrators can use thresholds to generate alerts and policies, while a separate risk view explains the factors contributing to an application’s score.
The scoring model should help teams with sprawling integration estates decide where to begin, but it does not eliminate the need for human review. An actively used sales or support integration may legitimately perform large queries and hold extensive permissions; the security question is whether those rights remain necessary and whether the vendor controlling the tokens can be trusted to protect them.
The first practical review should prioritize applications that can export data, make broad API queries, maintain offline access, or operate as non-human identities. Integrations that no longer have an active owner or documented purpose should not retain access simply because removing them could inconvenience an unknown workflow.
Security teams should also establish a tested revocation process. During a supplier incident, waiting to determine whether each tenant was accessed can give attackers additional time to use stolen refresh tokens. Organizations need to know how to revoke tokens, disable an integration, preserve event data, and restore service with newly issued credentials.
Defender customers can hunt Salesforce activity through the
Microsoft also published infrastructure indicators associated with the Klue and guest-access activity. Those indicators can support scoping, but fixed IP blocking is unlikely to be sufficient against campaigns built around legitimate cloud authorization. Application identity, token use, object access, and query behavior provide the more durable evidence.
The wider lesson is not limited to Salesforce or Microsoft Defender. OAuth-connected SaaS applications are effectively privileged accounts whose credentials may be held by another company, executed from infrastructure outside the customer’s control, and authorized to bypass interactive authentication. A green consent screen is not a security boundary.
For Windows-centric enterprise teams already correlating endpoints, Entra identities, email, and cloud applications in Microsoft Defender, the new connector provides another layer of evidence. Its value will depend on whether organizations enable the required Salesforce event monitoring and act on the inventory it exposes.
The next ShinyHunters-linked campaign may begin with a phone call, a forgotten guest profile, or a supplier no customer can directly secure. The concrete defense is the same in each case: reduce standing OAuth privilege, remove abandoned integrations, monitor the API activity behind trusted applications, and be ready to revoke access before a legitimate workflow becomes an attacker’s extraction pipeline.
The attacks did not depend on a vulnerability in Salesforce itself. Instead, threat actors inherited legitimate permissions by persuading users to approve malicious applications, stealing tokens from trusted SaaS suppliers, or exploiting overly broad guest access. That distinction matters operationally: conventional sign-in alerts may remain silent because the resulting API calls appear to come from authorized identities and approved software.
Microsoft has responded by expanding Salesforce telemetry and OAuth application governance in Defender for Cloud Apps. For administrators, however, the immediate task is broader than deploying another detection rule: every connected application must now be treated as an identity with privileges, persistence, and its own supply-chain exposure.
Three Roads Into the Same CRM
Microsoft grouped the observed activity into three intrusion paths, beginning with voice phishing, or vishing. Attackers impersonated IT support personnel and guided employees through Salesforce’s OAuth consent process, convincing them to authorize an attacker-controlled connected application disguised as a legitimate Salesforce Data Loader tool.Once consent was granted, the application could make API calls using the victim’s privileges. That enabled attackers to enumerate Salesforce environments, retain access to CRM records, and potentially discover credentials that could support movement into other SaaS services.
This technique bypasses several assumptions built into traditional account-security programs. There may be no malware to detect, no password to reset, and no suspicious replay of stolen credentials. The user completed a legitimate authorization workflow; the problem was that the application receiving permission was malicious.
The second path moved upstream into the SaaS supply chain. In August 2025, compromised credentials associated with Salesloft Drift gave attackers access to connection secrets and OAuth tokens used by downstream Salesforce customers. Salesforce subsequently disabled integrations with Salesloft technologies while the incident was investigated, stating that the event involved compromised app connection credentials rather than a weakness in its core platform.
A similar campaign targeted Gainsight-published Salesforce applications in November 2025. Microsoft said attackers used trusted external connections to conduct discovery, execute bulk queries, and exfiltrate accounts, contacts, service cases, and other CRM data without producing the failed logins or unusual authentication patterns defenders typically investigate.
The pattern resurfaced in June 2026 when market intelligence provider Klue detected unauthorized activity in its integration infrastructure. Klue said an attacker entered through a compromised legacy credential, obtained OAuth tokens used to connect to services including Salesforce, and accessed data in several connected customer environments. Microsoft tracks the actor involved in that incident as Storm-3138.
Klue revoked affected credentials and tokens, disabled potentially affected integrations, and brought in CrowdStrike to investigate. Its disclosure underscores the defining risk of SaaS integrations: compromise of one vendor can expose data held in numerous customer tenants without attackers separately breaching each organization.
Guest Access Became a Bulk-Extraction Tool
The third intrusion path did not require OAuth token theft. Microsoft observed attackers targeting Salesforce Aura endpoints exposed to guest users and sending GraphQL-based Aura requests to retrieve records without authentication.Microsoft characterized these incidents as exploitation of misconfigured permissions, not a software vulnerability. By chaining requests, the attackers could reportedly retrieve substantially more information than administrators intended guest users to access, turning a public-facing Salesforce experience into an avenue for systematic data extraction.
This is an important warning for organizations that have concentrated their identity controls around employees, contractors, and service accounts. An unauthenticated guest profile can still carry meaningful application privileges, particularly where Experience Cloud sites have accumulated custom objects, legacy sharing rules, or broadly accessible fields.
All three methods converge on the same defensive problem: the attacker operates inside trusted access paths. A malicious connected app inherits a user’s rights, a compromised supplier inherits an integration’s rights, and an improperly configured guest inherits whatever Salesforce exposes to that profile.
The resulting traffic can resemble ordinary CRM automation. API requests arrive through expected interfaces, authorized applications query valid objects, and sessions may not produce the authentication anomalies that would normally trigger an identity-focused incident response.
Defender Shifts Attention From Logins to Application Behavior
Microsoft’s upgraded Defender for Cloud Apps Salesforce connector uses Salesforce Shield Real-Time Event Monitoring to provide faster security and activity telemetry. Microsoft says the connector can now attribute activity to specific connected applications, display granted OAuth scopes, and add identity, session, API, and application context to investigations.That visibility is intended to answer questions which authentication logs alone cannot: which application issued a query, what permissions it held, which users and records it touched, whether it appeared from a new address, and whether its behavior departed from established patterns.
New detections cover suspicious scraping, anomalous API and report activity, unexpected connected-app endpoints, guest-user anomalies, and Salesforce Aura activity associated with the AuraInspector framework. Defender can also correlate Salesforce events with risky identities and activity elsewhere in Microsoft’s security stack.
Microsoft is adding preventive controls alongside detection. Defender’s inventory for Salesforce connected and external client applications now identifies granted permissions, highlights highly privileged apps, and surfaces integrations that have remained unused for extended periods, such as 90 days or longer.
Connected applications also receive a risk score from zero to 100, calculated from factors including sensitive permissions, behavioral signals, and usage patterns. Administrators can use thresholds to generate alerts and policies, while a separate risk view explains the factors contributing to an application’s score.
The scoring model should help teams with sprawling integration estates decide where to begin, but it does not eliminate the need for human review. An actively used sales or support integration may legitimately perform large queries and hold extensive permissions; the security question is whether those rights remain necessary and whether the vendor controlling the tokens can be trusted to protect them.
The OAuth Inventory Is Now Part of Incident Response
Microsoft recommends connecting Salesforce to Defender for Cloud Apps, monitoring Salesforce event logs, applying Salesforce security guidance, and reviewing Experience Cloud guest-user access. Administrators should also inventory every connected application and external client, then map each one to an owner, business purpose, permission set, and expected activity.The first practical review should prioritize applications that can export data, make broad API queries, maintain offline access, or operate as non-human identities. Integrations that no longer have an active owner or documented purpose should not retain access simply because removing them could inconvenience an unknown workflow.
Security teams should also establish a tested revocation process. During a supplier incident, waiting to determine whether each tenant was accessed can give attackers additional time to use stolen refresh tokens. Organizations need to know how to revoke tokens, disable an integration, preserve event data, and restore service with newly issued credentials.
Defender customers can hunt Salesforce activity through the
CloudAppEvents data set, looking for unfamiliar connected applications, new IP addresses, anomalous report exports, large API volumes, and queries against sensitive objects. Microsoft notes that its supplied examples initially search one week of raw events, while administrators can expand the hunting window to 30 days.Microsoft also published infrastructure indicators associated with the Klue and guest-access activity. Those indicators can support scoping, but fixed IP blocking is unlikely to be sufficient against campaigns built around legitimate cloud authorization. Application identity, token use, object access, and query behavior provide the more durable evidence.
The wider lesson is not limited to Salesforce or Microsoft Defender. OAuth-connected SaaS applications are effectively privileged accounts whose credentials may be held by another company, executed from infrastructure outside the customer’s control, and authorized to bypass interactive authentication. A green consent screen is not a security boundary.
For Windows-centric enterprise teams already correlating endpoints, Entra identities, email, and cloud applications in Microsoft Defender, the new connector provides another layer of evidence. Its value will depend on whether organizations enable the required Salesforce event monitoring and act on the inventory it exposes.
The next ShinyHunters-linked campaign may begin with a phone call, a forgotten guest profile, or a supplier no customer can directly secure. The concrete defense is the same in each case: reduce standing OAuth privilege, remove abandoned integrations, monitor the API activity behind trusted applications, and be ready to revoke access before a legitimate workflow becomes an attacker’s extraction pipeline.
References
- Primary source: Microsoft
Published: 2026-07-13T22:02:41+00:00
Defending SaaS-based applications against ShinyHunters OAuth abuse | Microsoft Security Blog
Microsoft Threat Intelligence identified threat actor activity with overlapping tradecraft commonly associated with ShinyHunters, including voice phishing (vishing), supply-chain compromise, and misconfigured guest access targeting SaaS-based applications.www.microsoft.com
