1 The Challenge
A client emailed us after an employee mentioned, almost in passing, that they’d signed in to view a shared document that morning and it had asked for some unusual permissions. Nothing about the sign-in itself had looked wrong, because it wasn’t a fake page, it was the genuine Microsoft login screen. What came after the login was the actual attack.
This is an anonymized account of an incident response engagement, kept accurate to the mechanics involved because this specific technique, OAuth consent phishing, is becoming common enough that other businesses should recognize the pattern.
2 Our Assessment
What actually happened
The employee received an email that looked like a document-sharing notification, with a link that led to the real Microsoft sign-in page, not a lookalike domain. After signing in normally, they were presented with a permissions screen asking them to approve a third-party application requesting access to read and send mail, view contacts, and maintain that access going forward. It looked enough like a routine app-approval prompt that the employee clicked "Accept."
How this was caught in time
We had previously set up alerting on new third-party application consent events across the client’s Microsoft 365 tenant as part of an earlier hardening engagement. That alert fired within minutes of the approval, flagging a newly consented application with mail-read and mail-send permissions that hadn’t been seen in the tenant before, which is exactly the kind of anomaly this monitoring exists to catch.
What the app would have been able to do
- Read the mailbox’s entire contents, including past email, on an ongoing basis
- Send email as the employee, silently and without their knowledge
- Retain that access indefinitely, since a granted consent doesn’t expire the way a login session does
- Survive a password reset entirely, because the access is tied to the app’s permission grant, not to the employee’s credentials
Why this technique is spreading
OAuth consent phishing is effective precisely because it skips the parts security training usually focuses on. There’s no fake login page to spot, because the login page is real. There’s no password to steal, so a compromised-password response doesn’t apply. And it doesn’t need to beat MFA, because MFA protects the login step, and the login step genuinely succeeded, it’s the permissions screen immediately after that does the damage.
3 The Solution
Because the alert caught this quickly, the response focused on cutting off access before it was used, then closing the broader gap that let it get this far:
- Revoked the malicious app’s consent grant immediately, which severs its access instantly, a password reset alone would not have touched it
- Reviewed every application with mailbox-level permissions across the entire tenant, and removed several other unused or unnecessary consents found during that review
- Restricted user consent for third-party applications tenant-wide, so any new request now requires admin approval instead of an individual employee’s click
- Kept ongoing alerting in place for new consent events, with the response process now documented rather than improvised
- Ran a short, specific awareness session for staff on this exact pattern, a real login screen followed by a permissions request, since it doesn’t match what most phishing training covers
4 The Result
The malicious application never actually read or sent a single message, its consent was revoked within minutes of being granted, before any use of the access was detected. The tenant now requires admin approval for any new third-party app requesting mailbox permissions, closing the door this incident came through.
5 Business Impact
The reason this incident is worth writing up is that it bypasses the exact advice most phishing training gives: check the URL, don’t type your password into a suspicious page. Neither applied here, the URL was genuine and no password was ever typed anywhere it shouldn’t have been. A business relying only on "spot the fake login page" training has a real gap against this specific technique.
If your business hasn’t reviewed which third-party applications currently have standing access to your Microsoft 365 mailboxes, or doesn’t require admin approval before a new one gets granted access, that’s worth checking now rather than after an incident. Our Microsoft 365 Security and Identity & Access Security teams handle exactly this kind of review, and our incident response team is reachable 24/7 if you think something similar may already have happened.