Microsoft released a set of OAuth governance controls and risk-scoring models inside Defender for Cloud Apps on July 13, aimed squarely at the abuse of trusted Salesforce integrations that ShinyHunters-linked attackers have exploited for more than a year without ever needing to steal a password.
The new capabilities assign a 0–100 risk score to every connected Salesforce application, flag those that have gone unused for 90 days or more, and give security teams near-real-time telemetry that ties API activity directly to the app that initiated it—moving detection beyond simple sign-in logs that these attacks are designed to evade.
What Defender Now Sees Inside Your Salesforce Tenant
Until now, an admin investigating a potential data leak from Salesforce often had to answer one uncomfortable question first: which application actually executed the query? Microsoft’s updated Salesforce connector changes that by pulling in events through Salesforce Shield Real-Time Event Monitoring, then attributing API calls, report exports, and Aura framework activity to the specific connected application.
That sounds technical, but the operational difference is stark. In the attacks Microsoft describes, threat actors persuaded employees to approve a fake “Data Loader” OAuth app, then used that app’s legitimate tokens to enumerate CRM records and exfiltrate customer lists. From the IdP’s perspective, nothing looked wrong—no failed logins, no impossible travel, no brute force. The new telemetry surfaces the app’s identity and scope so defenders can ask: did this app ever need permission to query all contacts and accounts?
Alongside attribution, Microsoft is surfacing three governance insights directly in the Defender inventory:
- Highly privileged apps —automatically identified based on the OAuth scopes they hold, such as the ability to perform API queries, manage data, or act on behalf of users.
- Unused apps —those that haven’t performed any activity in 90 days or longer, flagged for review and potential revocation.
- Risk scores —a composite number between 0 and 100 that weighs sensitive permissions, usage patterns, and behavioral signals to help teams decide where to start when an integration estate contains hundreds of connections.
The risk score doesn’t replace human judgment, but it gives a meaningful starting point. An integration with a score of 92 and full API access that suddenly starts extracting thousands of records from a new IP address will jump to the top of the queue.
New detection algorithms running on that telemetry watch for patterns that appeared across the ShinyHunters campaigns: scraping-like exfiltration, anomalous API volumes, report exports from unfamiliar locations, guest-user activity linked to the AuraInspector framework, and connected apps reaching Salesforce endpoints they’ve never touched before.
Why This Arrives After a Year of Quiet Intrusions
The timeline Microsoft’s security research team published alongside the feature drop reveals how thoroughly these attacks relied on trust rather than technical exploits. In mid-2025, attackers began voice-phishing campaigns, calling employees while impersonating IT support and walking them through the OAuth consent screen for a malicious connected app. Once authorized, that app inherited the victim’s permissions and began enumerating Salesforce objects.
August 2025 brought a shift in method. Attackers compromised credentials at Salesloft, which provides Salesloft Drift, a popular integration, and used those credentials to obtain OAuth tokens that downstream customers had granted. Salesforce itself had to disable integrations with Salesloft technologies during the investigation. The data accessed—accounts, contacts, service cases—was never protected by an additional authentication check because the integration traffic looked exactly like legitimate syncing.
November 2025 saw a near-identical campaign targeting Gainsight-published Salesforce applications, and in June 2026, the market intelligence platform Klue disclosed that a threat actor Microsoft tracks as Storm-3138 had breached its infrastructure through a legacy credential, obtained OAuth tokens connecting Klue to customer Salesforce instances, and exfiltrated data from several connected tenants.
A third intrusion path, active in recent months, didn’t require stealing any token. Attackers targeted Salesforce Aura endpoints exposed to unauthenticated guest users and chained GraphQL-based requests to retrieve far more data than the guest profile was ever intended to access. Microsoft characterized this as exploitation of misconfigured permissions, not a code vulnerability—making it a configuration gap that tens of thousands of Salesforce orgs may share without realizing the exposure.
Across all three methods, one property stayed constant: the malicious activity operated inside authorized access paths. That’s why the new Defender capabilities are built not to detect an intrusion event but to illuminate what an app is doing after it’s already trusted.
What This Means for IT and Security Teams
For organizations already running Microsoft 365 and using Defender for Cloud Apps, this expansion arrives as a direct upgrade to the existing Salesforce connector. It is not a separate product, but enabling the full feature set requires Salesforce Shield Event Monitoring, a licensable add-on that streams real-time events into Defender. Without that step, the most granular API attribution and some detections won’t function.
Once active, the connector turns every connected Salesforce application into a monitored identity—one that has privileges, persists across sessions, and may be owned by a third party whose own security posture you cannot control. That conceptual shift matters operationally. The same security diligence applied to employee accounts (risk scoring, periodic reviews, revocation policies) must now extend to OAuth apps, especially those that can export data, make broad queries, or maintain offline refresh tokens.
Administrators also gain a new lever for compliance and lifecycle management. Unused app detection means audits can move from “list every integration” to “revoke the 47 dormant connections nobody remembers creating.” Highly privileged app identification gives risk committees a concrete metric for third-party vendor risk, beyond the questionnaire.
For incident responders, Microsoft published a set of advanced hunting queries that sift through Salesforce events in the CloudAppEvents dataset. These queries hunt for connected-app activity from new IP addresses, anomalous report exports, and pivot from a suspicious app name or ID to every user and action associated with it. Combined with the new risk scores, a responder can quickly isolate whether a compromised integration touched sensitive objects before token revocation.
Concrete Steps to Activate the Protection Now
Microsoft’s own mitigation guidance, augmented by the reality of these attack patterns, points to a handful of high-priority actions:
- Turn on Salesforce Shield Event Monitoring. This is the prerequisite for near-real-time telemetry and the deepest detections. Budget approval may be needed, but the cost is a fraction of a breach involving CRM data export.
- Connect Salesforce to Defender for Cloud Apps and verify that the connector is ingesting the new event types, including connected app attribution and API events.
- Inventory every connected and external client application. Defender’s new inventory surfaces all OAuth apps, their granted scopes, and their last activity. Export the list and assign an owner to each.
- Revoke unused applications immediately. Any app with no activity in 90 days and no documented owner should be disabled. Defender now highlights these automatically; don’t wait for a risk score to climb if no one claims the integration.
- Review highly privileged apps against business need. An e-signature tool may legitimately need document access, but a marketing widget that can read case data should raise alarms. Use permission-based filters to isolate apps with sensitive scopes.
- Create risk-based policies in Defender that trigger alerts when a connected app exceeds a defined threshold, such as risk score > 80 performing a bulk report export from a new IP.
- Run the published advanced hunting queries for a 30-day lookback to find any existing signs of the activity Microsoft observed—new connected apps, suspicious Aura requests, or report exports from unusual IPs.
- Validate guest-user access on Experience Cloud sites. If Aura endpoints are exposed to unauthenticated users, apply Salesforce’s own security guidance to tighten object permissions and limit record retrieval volumes. Treat guest profiles as potentially hostile unless proven otherwise.
- Test your integration revocation process. In a supplier incident like the Klue breach, the clock is ticking once tokens are known stolen. Know exactly who can revoke tokens, disable the integration, and preserve logs—ideally rehearsed in a tabletop exercise.
- Feed the indicators of compromise into your SIEM or XDR. Microsoft has shared IP addresses associated with the Klue integration abuse and the guest-access campaign. While fixed IP blocking alone won’t stop OAuth-based attacks, those IOCs can help scope whether you were already targeted.
What to Watch Next
The ShinyHunters-associated activity makes clear that the attack surface is not shrinking. As more CRM data moves into Salesforce and is interconnected through the AppExchange ecosystem, the temptation to compromise a single supplier and pivot into dozens of tenants will only grow. Microsoft’s risk-scoring model is an important first step, but it will need to evolve quickly—perhaps incorporating threat intelligence on the supplier’s own breach history, the app’s code-signing status, or the geographic origin of token issuance.
For the Windows-centric enterprise, where Defender is already handling endpoint, identity, and email telemetry, the addition of Salesforce application risk scores fills a critical gap. The value will depend less on the tooling itself and more on whether organizations enable the required event monitoring and allocate time to weed out the hundreds of forgotten integrations that now represent a quiet but measurable risk of mass data theft.