ShinyHunters: The OAuth Abuse That Bypasses MFA on Salesforce and M365
ShinyHunters hijacks trusted OAuth connections to exfiltrate CRM data without ever triggering MFA. Here is how to detect abusive consents and tokens.
On July 13, 2026, Microsoft detailed a series of campaigns attributed to tradecraft associated with ShinyHunters, active from mid-2025 to mid-2026, aimed at bypassing multi-factor authentication on SaaS applications by abusing trusted OAuth connections. What makes this case interesting is that it illustrates a class of threat still poorly covered by many teams: the attack breaks no password and triggers no sign-in anomaly, because it does not use a login in the classic sense. It relies on an OAuth token granted by a legitimate user.
The mechanism: consent does all the work
The central pattern is simple and formidable. A fake application, presented as a Salesforce Data Loader tool, tricks an employee into granting OAuth consent. Once that consent is given, the attacker inherits the user's session and bypasses MFA entirely, since the OAuth token is a delegated authorization that does not go back through authentication. This is T1528 (Steal Application Access Token) followed by T1550.001 (Use Alternate Authentication Material: Application Access Tokens).
From there, the attacker queries the CRM and performs bulk exfiltration of sensitive records, accounts, contacts, service case data, without generating a traditional sign-in anomaly. That is precisely what makes the threat stealthy: identity dashboards, which watch for risky sign-ins, see nothing abnormal, because no risky sign-in takes place.
A threat that spreads through the supply chain
Microsoft describes several attack paths beyond direct voice phishing. Salesloft Drift login credentials compromised in August 2025 exposed connection secrets used across multiple customer Salesforce environments. A campaign targeting the Gainsight integration in November 2025 allowed persistent API access to be maintained without triggering a sign-in anomaly. Finally, in June 2026, a group tracked as Storm-3138 compromised the market intelligence platform Klue and reused its Salesforce credentials to query and steal data. The campaigns hit Salesforce tenants in retail, education, and manufacturing.
This point is essential for defense: the abusive token does not necessarily come from a direct consent by your users. It can come from a partner or an integrated vendor whose secrets were stolen. Monitoring must therefore cover connected third-party applications as much as internal consents.
Detecting consent to a new OAuth application
The most direct detection point is consent to a new or little-known OAuth application. Entra ID and Salesforce log these events. A Sigma rule on Entra ID audit logs can alert on the addition of an OAuth authorization to an application not present in an approved-application list.
title: OAuth consent granted to an unapproved application
id: 5a2f8c14-9d63-4b07-8e1a-3c6f0b7d9e42
status: experimental
description: >
Detects an OAuth consent grant to an application, to be correlated with an
approved-application allowlist to surface a ShinyHunters-style abuse.
references:
- https://www.microsoft.com/en-us/security/blog/2026/07/13/defending-saas-based-applications-against-shinyhunters-oauth-abuse/
logsource:
product: azure
service: auditlogs
detection:
selection:
operationName|contains:
- 'Consent to application'
- 'Add OAuth2PermissionGrant'
- 'Add delegated permission grant'
condition: selection
falsepositives:
- Legitimate adoption of a new application, filter with an allowlist
level: medium
tags:
- attack.credential_access
- attack.t1528
- attack.persistenceSpotting dormant tokens and abnormal application access
Beyond the initial consent, two signals deserve monitoring. The first is sudden activity from an OAuth token that had stayed dormant, a classic sign of reuse of long-obtained access. The second is bulk access to CRM data by an application token at unusual volumes or hours, with no matching user sign-in. Correlating exfiltration with an application token, rather than an interactive session, surfaces exactly the pattern Microsoft describes.
The control that cuts the root of the problem
The most effective preventive measure is to require admin consent for any new OAuth application. By disabling free user consent, you remove the ability for an employee alone, under the effect of a phishing call, to grant delegated access to a malicious application. This is a configuration setting, not a product to deploy, and it neutralizes the primary entry vector. Complement it with a periodic review of connected third-party applications and their permissions, removing those no longer used or whose presence you cannot justify.
Detecting OAuth abuse means watching the right identity logs and correlating consent, token activity, and exfiltration. That is what the ThreatClaw Sigma feed provides: rules for cloud and SaaS environments, built on audit logs and designed to catch threats that trigger no sign-in anomaly.
Related articles
Via vishing, actor O-UNC-066 registers its own FIDO2 passkey in the victim's account. Detect the method addition correlated with a risky sign-in.
A rule feed is not worth its rule count. It is worth the proof that the rules fire and what you do when they trigger. Tested on real engines, false-positive-proven, signed, and every rule ships an investigation playbook wired to our other engines.
Deserialization of untrusted data yields RCE on on-premise SharePoint. In the KEV, exploited by Storm-2603. Here is the Sigma rule on w3wp and Nuclei detection.
The Gentlemen gets in via compromised FortiGates, disables EDR with a vulnerable driver (BYOVD) and enumerates AD. Here are the Sigma and YARA rules to spot it.