ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft 365 • OAuth Consent Abuse

The User Clicked Accept… And Gave Away The Entire Mailbox

The user never typed their password into a fake website.

They never downloaded malware.

Microsoft Defender showed no obvious infection. No suspicious attachment was opened. No endpoint alert immediately explained what happened.

The sign-in passed MFA successfully.

Everything looked legitimate — until the mailbox activity told a different story.

This Agent Foskett briefing looks at one of the most misunderstood attack paths in Microsoft 365: OAuth consent phishing.

The attacker did not need the password. They did not need malware. They simply convinced the user to approve an application that requested access to the mailbox.

The user clicked Accept — and authorised the attacker to stay.

Discuss Microsoft 365 security Back to Investigation Hub
Agent Foskett investigates OAuth consent attacks in Microsoft 365
Briefing summary

OAuth consent attacks abuse legitimate Microsoft authentication workflows to gain access without stealing the user's password. MFA may succeed, the login may look normal, and the user may still grant a malicious application permission to read mailbox data.

Review OAuth consent grants
Investigate risky app permissions
Correlate consent with mailbox activity
🚨 MFA worked. The attacker still gained access.
OAuth consent abuse can turn a legitimate Microsoft sign-in into long-term mailbox access through malicious application permissions.
Book a security review →

The attack nobody notices

OAuth consent phishing does not always look like traditional phishing. The user may be sent to a real Microsoft sign-in page. They may complete MFA correctly. The dangerous moment happens after authentication, when the user is asked to approve permissions for an application they do not understand.
The login was realThe Microsoft authentication page may be legitimate. The trap is the application permission request that appears afterwards.
The user authorised accessThe attacker tricks the user into granting permissions such as Mail.Read, User.Read, Files.Read or offline_access.
No malware requiredThe compromise may live in identity, enterprise applications and OAuth tokens rather than on the endpoint.

Why MFA did not stop it

MFA proves the user is the person signing in. It does not prove the application they are approving is safe. In this scenario, MFA may work exactly as designed, but the user then grants the malicious application permission to access data. That distinction matters. Authentication succeeded. Authorisation was abused.
MFA validated the userThe sign-in may be clean because the real user completed it. That does not mean the resulting consent was safe.
Consent granted accessOnce permissions are approved, the app may access data using OAuth tokens instead of passwords.
Password resets may not be enoughIf the OAuth grant remains active, changing the password may not fully remove the application access.

First hunt: suspicious OAuth consent grants

Start by reviewing consent activity in Entra ID audit logs. Look for consent operations, unfamiliar applications, suspicious publishers, unusual users and permission grants that do not match normal business workflows.
oauth-consent-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any ("Consent", "Add delegated permission grant", "Add app role assignment")
| project TimeGenerated,
          OperationName,
          InitiatedBy,
          TargetResources,
          Result
| order by TimeGenerated desc
What to reviewLook for unexpected consent grants, new enterprise applications, unusual app names, unfamiliar publishers and high-impact permissions.
Why it mattersConsent activity may appear before mailbox abuse, inbox rules, data access or suspicious application activity becomes obvious.
Best next pivotPivot into enterprise applications, app permissions, sign-in logs, mailbox audit activity and CloudAppEvents.

Common permission requests to investigate

Not every consent grant is malicious. Many business applications require permissions. The risk appears when powerful permissions are granted to an unfamiliar application, especially by a user who does not normally approve apps.
Mail.ReadAllows an application to read mailbox content. This can expose sensitive email, invoices, reset links and internal conversations.
offline_accessAllows the application to maintain access through refresh tokens, which can extend attacker persistence beyond the initial login.
Files.Read and User.ReadThese permissions may expose files, profile data and directory context that helps the attacker understand the organisation.

Second hunt: risky application activity

After reviewing consent activity, look for application activity that follows the approval. A suspicious app may appear in CloudAppEvents, audit logs, sign-in logs or mailbox-related telemetry depending on licensing, configuration and logging coverage.
oauth-application-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
CloudAppEvents
| where Timestamp > ago(14d)
| where ActionType has_any ("Consent", "Add service principal", "Add app role assignment")
| project Timestamp, AccountDisplayName, Application, IPAddress, ActionType, RawEventData
| order by Timestamp desc

Third hunt: mailbox behaviour after consent

OAuth consent abuse often becomes visible when mailbox activity changes. After identifying a suspicious consent event, review the same user for inbox rules, unusual email access, forwarding behaviour, external connections and activity that occurs after the consent timestamp.
mailbox-activity-after-consent.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
CloudAppEvents
| where Timestamp > ago(14d)
| where Application has_any ("Exchange", "Office 365", "Microsoft 365")
| where ActionType has_any ("MailItemsAccessed", "New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| project Timestamp, AccountDisplayName, ActionType, Application, IPAddress, RawEventData
| order by Timestamp desc

Where defenders get caught

OAuth consent attacks are missed because the obvious signals look reassuring. The user signed in. MFA was completed. No malware was found. No password was obviously stolen. But the attacker may now have an approved application path into the mailbox.
They trust the login pageThe login page may be real. The malicious step is the consent approval that follows the sign-in.
They assume MFA solved itMFA protects authentication. It does not automatically protect users from approving unsafe application permissions.
They never review app consentMany organisations monitor failed sign-ins but rarely review consent grants, enterprise applications and OAuth permissions.

How GEMXIT approaches this type of investigation

At GEMXIT, we do not treat a successful MFA sign-in as the end of the investigation. We review what happened after authentication: what application was approved, what permissions were granted, whether the app is trusted and whether mailbox activity changed afterwards.
We review the full consent storyWho approved the app, what permissions were requested, what publisher was shown and whether the approval fits normal business use?
We correlate identity and mailbox evidenceConsent grants, sign-ins, mailbox activity, inbox rules, IP addresses and user reports all become stronger when reviewed together.
We remove the persistenceResponse may include revoking consent, removing the enterprise app, invalidating sessions, reviewing mailbox rules and hardening consent policies.
The user clicked Accept. The mailbox investigation had only just begun.
GEMXIT helps organisations investigate Microsoft 365 OAuth consent abuse, Entra ID application permissions, mailbox compromise, Defender XDR telemetry and practical KQL hunting workflows.
Contact GEMXIT

Final thought

The user thought they were proving who they were.

In reality, they were authorising the attacker to stay.

Modern Microsoft security investigations are no longer only about stolen passwords, malware and failed sign-ins. Sometimes the compromise begins with a legitimate login, a successful MFA prompt and one dangerous approval screen.

The real question becomes:

“What did the user authorise?”
At GEMXITWe help organisations investigate Microsoft 365, Entra ID, OAuth consent abuse, mailbox compromise, Microsoft Defender XDR, Sentinel visibility and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Did MFA pass?”

It is: “What access was granted after MFA?”

Continue the investigation with The User Passed MFA But It Wasn't Really Them, The Session Token Never Expired, The Login Came Through A Trusted Device, The Inbox Rule Was Created At 2:13AM, Microsoft Defender KQL Threat Hunting Guide, Agent Foskett Academy, Microsoft Security and the GEMXIT Security Review.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The User Clicked Accept… And Gave Away The Entire Mailbox

This Agent Foskett briefing explains how OAuth consent phishing can allow attackers to gain Microsoft 365 mailbox access without stealing a password or installing malware.

Microsoft 365 OAuth Consent Attack Investigation

GEMXIT helps organisations investigate Entra ID consent grants, suspicious enterprise applications, OAuth tokens, application permissions, mailbox activity and Microsoft Defender XDR hunting workflows.

OAuth Consent Phishing and Mailbox Compromise

MFA may successfully validate the user, but malicious consent grants can still authorise an attacker-controlled application to access mailbox data through permissions such as Mail.Read and offline_access.