← All walkthroughs

OAuth consent phishing to a cloud mailbox

An illicit-consent (OAuth) phish tricks a user into authorising a malicious application, which then reads mail and data through the API — no password and no MFA prompt needed.

Cloud identity / M365-style tenant Intermediate IdentityCloudPhishing
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

Scenario

An authorized social-engineering and identity assessment of a cloud tenant. Sending consent-grant lures to an agreed user list is approved. The objective is to show whether users can be led to authorise an attacker-controlled app, and what that app can then reach.

Practice this path: Cloud attacks · MITRE ATT&CK
  1. 1

    Resource Development

    Prepare a consent lure

    T1566.002 Phishing: Spearphishing Link

    Register an application that requests mail/file-read scopes and craft a convincing consent link, keeping branding generic and staying within the approved user list.

    Detection

    Newly registered third-party apps requesting broad delegated scopes are visible to tenant app-governance review.

    Mitigation

    Restrict user consent to verified publishers and low-risk scopes, and require admin approval for anything broader.

    References oauth2-attacks · gophish · Recon / OSINT Helper
  2. 2

    Credential Access

    Obtain an access/refresh token via consent

    T1528 Steal Application Access Token

    A user who clicks the link and consents grants the app a token with the requested scopes. Because this is an authorised grant, it bypasses the password and the MFA prompt entirely — the point of the finding.

    Detection

    Consent-grant events to a new app, especially with offline-access/refresh scopes, are high-value sign-in-log events.

    Mitigation

    Alert on new consent grants, review and revoke risky OAuth app permissions, and educate users on consent prompts.

    References oauth2-attacks
  3. 3

    Collection

    Read mail and data through the API

    T1114.002 Email Collection: Remote Email Collection

    Use the granted token against the cloud API to demonstrate read access to the user's mailbox and files, documenting the exposure rather than harvesting content.

    Detection

    API-based mail reads from an application identity, and access from new IP ranges, appear in unified audit logs.

    Mitigation

    Conditional access for app access, token-lifetime limits, and alerting on bulk API reads by third-party apps.

    References azure-ad-security
  4. 4

    Persistence

    Keep access without the user

    T1098.001 Account Manipulation: Additional Cloud Credentials

    Show how the app's refresh token (or added app credentials) would let access persist after the user changes their password, since the grant is independent of the password — then recommend revocation.

    Detection

    Long-lived refresh-token use and new credentials added to an app registration are key persistence signals.

    Mitigation

    Revoke risky grants, enforce short refresh-token lifetimes and continuous access evaluation, and review app credentials regularly.

    References azure-ad-security

Key takeaways

  • Consent phishing steals a token, not a password — MFA on sign-in does not stop it.
  • The blast radius is exactly the scopes the user approved; least-privilege consent policy shrinks it.
  • Revoking the grant — not resetting the password — is what actually cuts off this access.