How consent attacks work
OAuth lets an application act on a user’s data without ever seeing the user’s password. The user approves a permission screen, and the platform issues tokens to the app. If the app belongs to an attacker, the attacker is now an authorized client.
Two permission types matter. Delegated permissions let an app act for a signed-in user. Application permissions let an app act on its own, with no user present. The second type is the dangerous one in enterprise tenants. Microsoft’s analysis of the Midnight Blizzard intrusion describes apps granted the Exchange Online full_access_as_app role, which gives access to mailboxes without any user in the loop.
MFA is rarely the control that matters here. The user or administrator signs in normally and approves the app afterwards, and the grant that results does not depend on how that sign-in was done.
Four patterns, with documented cases
| PATTERN | DOCUMENTED CASE | WHAT IT SHOWS |
|---|---|---|
| Consent phishing | Microsoft’s guidance for investigating risky apps describes apps requesting permissions that do not match their purpose, such as a clock app asking for access to all mailboxes, and consent screens that look legitimate but are not. This is published guidance, not a single named incident. | A user can grant powerful access in one click, and the request can look routine. |
| Attacker-built apps in a compromised tenant | Midnight Blizzard: password spray against a legacy test account without MFA led to a legacy test OAuth app with elevated access. The actor created further malicious apps and a new user to grant consent, assigned the full_access_as_app role, and collected corporate email through Exchange Web Services. | A forgotten non-production app can be the bridge to production mail. |
| Stolen tokens from a legitimate integration | Salesloft Drift: stolen OAuth tokens let the actor export data from many Salesforce instances. A second set of tokens reached a very small number of Google Workspace accounts. | No victim ever saw a consent prompt. The grant already existed and the attacker took the token. |
| Socially engineered authorization | UNC6040: callers posing as IT support guided employees to Salesforce’s connected-app setup page to enter a connection code. That linked an actor-controlled, modified Data Loader app, sometimes renamed, to the victim’s Salesforce environment. Separately, Mandiant describes attackers authorizing the ToogleBox Recall add-on by OAuth to delete security notification emails. | A phone call can substitute for a phishing page. The victim performs the authorization. |
Why these attacks slip past usual controls
The sign-in looks normal because the user’s own authentication succeeded. The risky event is a separate one, the grant, and it is often not what the monitoring program was built to watch. Microsoft also notes that some app activity is recorded as user activity, so it can be filtered out of the app-focused view during an investigation.
Persistence is the second problem. A grant is independent of the account that created it. In the Midnight Blizzard case, the malicious apps kept mailbox access without relying on the original foothold. In the Drift case, the actor deleted its query jobs to cover its tracks, but logs were not affected, which is why Google urged victims to review them.
Our assessment is that many organizations’ defenses are built around accounts, and this class of attack lives in the layer between accounts and applications. That is a judgment from the cases above, not a measured finding.
What to inventory and what to hunt
| SIGNAL | WHERE TO LOOK | WHY IT MATTERS |
|---|---|---|
| Apps with high-severity permissions and low community use | Defender for Cloud Apps, OAuth apps view; filter on permission level and community use | Microsoft names this combination as a way to find apps users might have underestimated. |
| Apps authorized by only a few users | Same view | Microsoft notes this can indicate a compromised user’s consent. |
| Holders of app-only mail roles | Entra and Exchange role assignments; review apps holding EWS.AccessAsUser.All or EWS.full_access_as_app | These roles allow mailbox access without a signed-in user. |
| New grants of full_access_as_app, elevated service principal permissions, or unknown apps requesting offline access | Microsoft Sentinel analytic rules | Microsoft lists rules for each of these after the Midnight Blizzard intrusion. |
| Spikes in application-only mailbox access | Defender for Cloud Apps alerts on apps accessing many emails or making large numbers of EWS calls | Mass collection by an app is a core behavior of the case above. |
| Connected-app authentication and unusual queries | Salesforce Event Monitoring: connected-app authentication activity and UniqueQuery events | Google recommends these for Drift-related review. |
| OAuth grants for unfamiliar add-ons, followed by deleted security emails | Google Workspace OAuth and Gmail audit logs | Mandiant lists OAuth grants for the ToogleBox Recall app among its hunting detections. |
What should change
| PRIORITY | CHANGE | BASIS |
|---|---|---|
| 1 | Restrict user consent. Allow it only for verified publishers and low-impact permissions, or turn it off and route requests through an admin consent workflow. | Microsoft recommends the verified-publisher policy and lists risks of open user consent. |
| 2 | Review grants that already exist. Sort by permission severity, publisher, number of users and last authorization date. Revoke what is stale or unexplained. | Microsoft states changes to consent settings apply only to future requests. |
| 3 | Treat app-only permissions as privileged access. Give each a named owner, a review date, and the narrowest scope available, such as role-based access control for applications to limit mailbox scope. | Microsoft’s guidance after Midnight Blizzard. |
| 4 | Retire legacy test tenants and apps, and enforce MFA everywhere. The entry point in the Midnight Blizzard case was a non-production account with no MFA. | Microsoft’s incident analysis. |
| 5 | Govern connected apps in SaaS platforms. Limit scopes, avoid full access, enforce IP restrictions, and restrict the API Enabled and Manage Connected Apps permissions to trusted administrators. | Google recommendations after the Drift and UNC6040 cases. |
| 6 | Put revocation into the incident playbook. Containment should revoke sessions and OAuth grants across the identity provider and SaaS applications, and rotate any vendor integration tokens in scope. | Mandiant containment guidance. |
| 7 | Tell staff and the help desk that nobody should authorize an app because of a phone call. Add app-registration approvals to the verification the help desk performs. | The UNC6040 pattern; Mandiant notes attackers have persuaded staff to approve malicious app registrations. |
Where to apply this
Start with one query: list every application in your tenants that holds mailbox or file permissions, with who consented, when, and when it was last used. The entries nobody can explain are the first findings. Then confirm that someone gets alerted when a new entry appears.
Sources
-
Microsoft. Investigate risky OAuth apps (Defender for Cloud Apps)
-
Microsoft. Configure how users consent to applications (Microsoft Entra)
-
Microsoft Threat Intelligence. Midnight Blizzard: Guidance for responders on nation-state attack microsoft.com
-
Google Threat Intelligence Group. Widespread Data Theft Targets Salesforce Instances via Salesloft Drift
-
Google Threat Intelligence Group. Voice phishing and data extortion campaign targeting Salesforce (UNC6040), analysis
-
Mandiant. Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionDetect, Respond & RecoverSpot attacks early and get back to business fast.See how we work →Related service
Identity Threat Detection & Response (ITDR)
Use this to strengthen detection of identity-led attacks.