Living Off Trusted Cloud: How Attackers Hide Inside Microsoft 365 and Google Workspace Using OAuth Consent Phishing

Most account compromise stories start with a stolen password. OAuth consent-related issues, however, don’t need one. 

OAuth consent phishing lets an attacker gain standing access to a Microsoft 365 or Google Workspace account without ever touching the login screen, and without triggering the alerts that come with a suspicious sign-in. The victim clicks “Allow” on what looks like a routine permissions request, and the attacker is in, often for good.

What Is OAuth Consent Phishing?

OAuth is the protocol behind the “Sign in with Google” or “Connect your Microsoft account” buttons used across thousands of legitimate apps. It lets one app request specific permissions to another service, like reading email or accessing files, without ever seeing the user’s password. OAuth consent phishing abuses that same mechanism. An attacker registers a malicious app, then tricks a target into approving its permission request, believing it’s a legitimate tool. Once approved, the attacker holds a valid access token, no password required.

How OAuth consent phishing differs from credential phishing

Credential phishing tricks someone into typing a password into a fake login page. OAuth consent phishing skips the password entirely and goes straight for a permissions grant. That distinction matters because most of the defenses built for credential phishing, like login monitoring and password hygiene, don’t apply. There’s no fake login page to spot, and no password to steal or reset.

Why MFA doesn’t stop OAuth consent phishing

Multi-factor authentication protects the login itself, but OAuth consent phishing bypasses the login entirely. The victim is often already signed in and authenticated when they approve the malicious app’s permissions. From the identity provider’s perspective, a legitimate, already-verified user has already been granted access to a third-party app, which is exactly what OAuth is designed to allow.

How a Malicious OAuth App Gets In

The attack usually starts with a phishing email, but the payload isn’t a fake login page. It’s a link to a real Microsoft or Google consent screen, for an app the attacker controls.

The fake consent screen and the permissions it asks for

The consent screen itself is genuinely hosted by Microsoft or Google, which is part of why it’s so convincing. It displays the malicious app’s name, often something that sounds legitimate like “Document Viewer” or “Meeting Scheduler,” alongside the specific permissions it’s requesting. Common asks include reading and sending email, accessing files and contacts, and maintaining offline access, permissions broad enough to do real damage but generic enough that a distracted user approves them without a second look.

What access looks like once consent is granted

Once approved, the app receives an access token, and often a refresh token, tied to the user’s account. That token lets the attacker read email, exfiltrate files, send messages as the victim, or monitor the mailbox indefinitely, all through legitimate API calls that look like normal app activity rather than a break-in.

Why This Attack Is So Hard to Spot

OAuth consent phishing is effective precisely because it doesn’t look like an attack. It looks like a user connecting an app, which happens constantly across most organizations.

No password, no login alert, no obvious anomaly

A successful phishing attack means there’s no failed login attempt, no new-device alert, and no password reset to flag. The access happens through a token, using the platform’s own API, from infrastructure that may not even resemble a suspicious IP address. Most security tools built around login anomalies simply have nothing to flag, giving attackers free rein.

How attackers persist through password resets and MFA changes

This is the detail that catches most security teams off guard. If a compromised user resets their password or re-enrolls in MFA, the OAuth token often remains valid. The malicious app was never authenticated using the password in the first place, so changing it doesn’t revoke the access. Unless the app’s consent is explicitly revoked, the attacker keeps their access straight through the remediation steps that would normally end an incident.

How to Detect and Prevent Consent Phishing

Because this attack lives entirely inside legitimate cloud infrastructure, defending against it means managing what’s allowed to connect in the first place, not just watching for suspicious logins. More detailed phishing simulations can also aid in detection and aversion.

Reviewing and restricting third-party app permissions

• Audit app access regularly: review which third-party apps have been granted access across your tenant, and revoke anything unrecognized, unused, or over-permissioned.
• Restrict self-service consent: limit which permission scopes users are allowed to approve on their own, reserving high-risk scopes like full mailbox access for admin approval.
• Review unverified publishers: flag newly registered or unverified publisher apps for manual review before they’re allowed into your environment.

Admin consent policies for Microsoft 365 and Google Workspace

Both platforms support admin-level consent policies that take the decision out of individual users’ hands. In Microsoft 365, this means configuring admin consent workflows so unverified apps requesting high-risk permissions require IT approval rather than a single click from the end user. Google Workspace offers similar controls through its API access management settings, allowing admins to restrict which third-party apps can request OAuth access at all.

Where managed detection and response fits in

Prevention controls reduce how often a malicious app makes it through, but managed detection and response gives you the visibility to catch what happens after a token is granted, unusual mailbox rules, unexpected data access patterns, or mail being sent through an approved app that shouldn’t be sending anything at all.

Ready to Find the Apps Already Inside Your Environment?

OAuth consent phishing hides in plain sight, inside the same permission requests your team approves every day. Talk to a SecurityHQ expert about auditing third-party app access and closing the gap before it’s exploited.

Frequently Asked Questions

What is OAuth consent?

OAuth consent is the permission a user grants when they approve a third-party app’s request to access their account data, such as email, files, or contacts, through a platform like Microsoft 365 or Google Workspace, without sharing their password directly with that app.

Why is it a bad idea to use OAuth 2.0 for authentication?

OAuth 2.0 was designed for authorization, granting an app permission to access specific data, not for verifying a user’s identity. When it’s used as a stand-in for authentication without additional safeguards, it can create gaps that attackers exploit through consent phishing rather than credential theft.

What does OAuth stand for?

OAuth stands for Open Authorization. It’s an open standard that lets users grant third-party applications limited access to their account information without exposing their password.text far more convincing.