The alert does not have to say “malware detected.” It can be quieter than that: a new enterprise application was granted Mail.Read, Files.Read.All, and offline_access by a user who had already passed MFA.

No failed password attempts. No impossible travel. No suspicious executable on the endpoint. Just one consent grant that gave an application permission to keep asking the identity provider for access.

That is the uncomfortable part of OAuth consent phishing. The user may authenticate correctly. The identity provider may behave exactly as designed. The breach begins when the wrong application is allowed to act as a trusted one.

TL;DR

  • OAuth consent phishing tricks users or administrators into granting a malicious app access to organizational data.
  • MFA helps against password theft, but it does not automatically stop a user from authorizing a bad app.
  • FBI warned on May 21, 2026 that Kali365 can capture Microsoft 365 OAuth access and refresh tokens through device code phishing.
  • Microsoft observed OAuth redirect abuse in March 2026 campaigns against government and public-sector organizations.
  • Defenders need app consent governance, OAuth app inventory, token revocation playbooks, and detections for unusual grants.

The First Clue Is Often Not a Login

In a normal phishing investigation, defenders start with the sign-in. Which IP address? Which country? Which device? Which MFA method?

OAuth abuse forces a different question: which application was trusted, and what did it receive?

A user can sign in from a familiar browser, complete MFA, and still approve an application that requests access to mail, files, calendar data, or directory information. If the app receives refresh-token capability through offline_access, the access can continue after the user closes the browser. If an administrator grants broad tenant consent, the blast radius can move from one account to many.

This is not theoretical edge-case behavior. OAuth is the delegation layer behind modern SaaS. Microsoft 365, Google Workspace, CRM systems, ticketing platforms, collaboration tools, security products, and AI assistants all rely on application-to-application trust. Attackers do not need to defeat that model if they can get invited into it.

What The Current Evidence Shows

On May 21, 2026, the FBI’s Internet Crime Complaint Center warned about Kali365, a phishing-as-a-service kit first seen in April 2026. According to the FBI, Kali365 is distributed through Telegram and can capture Microsoft 365 OAuth access and refresh tokens through device code phishing, allowing access to Outlook, Teams, and OneDrive without another MFA challenge.

That is not classic consent phishing. The victim is not simply approving a malicious app permission prompt. In device code phishing, the attacker gets the victim to enter a short code on a legitimate Microsoft verification page, then receives tokens when the authorization completes.

Microsoft also reported on March 2, 2026 that threat actors were abusing OAuth redirection behavior in phishing and malware delivery campaigns. In the activity Microsoft described, OAuth did not directly hand attackers access tokens. Instead, crafted OAuth URLs and redirect behavior made malicious links appear to pass through trusted identity infrastructure before landing the user on attacker-controlled content.

Those techniques are different. Grouping them as “OAuth abuse” can be useful for defenders, but precision matters:

TechniqueWhat the attacker getsWhat the defender should inspect
Consent phishingA malicious app grant or delegated accessApp consent logs, service principals, permission scopes
Device code phishingAccess and refresh tokens for the attacker’s sessionDevice code sign-ins, token use, unfamiliar client activity
OAuth redirect abuseA more trusted-looking path to phishing or malwareURL chains, redirect parameters, final landing domains
Compromised integrationAccess through a legitimate app or stored tokenSaaS app inventory, token age, unusual API access

The shared lesson is simple: modern phishing is moving from passwords to trust relationships.

How The Attack Looks From The Operator Side

First, the attacker needs something that looks like a legitimate workflow. That may be a malicious OAuth app in a tenant they control, a compromised integration, a device code flow, or a crafted redirect URL. The lure usually arrives through email, Teams, Slack, shared documents, calendar invites, or helpdesk-themed messages.

The link may lead to a real Microsoft or Google domain before anything bad happens. That weakens the advice users have heard for years: “check the URL.” In many OAuth attacks, the first URL can be legitimate. The danger is the authorization decision, the requested scopes, or the final redirect.

Then comes the moment that matters. The user signs in and approves something:

  • A consent prompt that grants an app access to organizational data.
  • A device code that authorizes the attacker’s waiting session.
  • A redirect flow that moves the victim from a trusted identity provider to attacker-controlled infrastructure.

After that, the attacker does not need to behave like a normal interactive user. The app can call APIs. Mailbox access can happen through Microsoft Graph. File access can happen through SharePoint, OneDrive, Google Drive, or SaaS APIs. The activity may look like integration traffic because, from the platform’s perspective, it is integration traffic.

This is why “reset the password” is incomplete. Password resets can be necessary, but they do not automatically remove a malicious app grant, revoke every refresh token, or clean up a trusted SaaS integration.

Why MFA Does Not Fix This Alone

MFA answers: is this the user authenticating?

OAuth consent asks: should this application be allowed to act with these permissions?

Those are different security decisions. A user can pass MFA and still approve the wrong app. An administrator can use strong authentication and still grant a dangerous permission set. A device code flow can happen on a real Microsoft page and still authorize the attacker’s session.

Calling this an MFA bypass is sometimes technically imprecise. The attacker may not bypass MFA at all. They may route around the password problem by abusing a flow where MFA already succeeded and the resulting token or grant becomes the asset.

For defenders, that distinction changes the playbook. The question is not only “who logged in?” It is also “which app was trusted, which scopes were granted, and which tokens remain valid?”

What Defenders Should Hunt

In Microsoft Entra ID, review audit events related to app consent, service principals, delegated permission grants, and application role assignments. Exact event names vary by portal, export pipeline, and schema version, so hunt on both operation names and target resource types.

AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has_any (
    "Consent",
    "Add delegated permission grant",
    "Add app role assignment",
    "Add service principal"
)
| project TimeGenerated, OperationName,
    Actor = tostring(InitiatedBy.user.userPrincipalName),
    App = tostring(TargetResources[0].displayName),
    Target = tostring(TargetResources[0].type),
    Result
| order by TimeGenerated desc

This is an inventory query, not a complete detection. The next step is to enrich it with app publisher, consent type, permission scopes, user role, source IP, and whether the app has been seen before in your tenant.

High-Risk Permission Sets

Some OAuth scopes deserve immediate review when granted to a new or unfamiliar app:

  • Mail.Read, Mail.ReadWrite, Mail.Send
  • Files.Read.All, Files.ReadWrite.All, Sites.Read.All
  • offline_access
  • Directory read/write permissions
  • Tenant-wide application permissions instead of user-scoped delegated permissions

The exact risk depends on the app and business need. A backup platform may legitimately require broad read access. A newly created “invoice review” app usually does not.

Device Code Authentication

Device code flow is legitimate for devices without keyboards, but it should be rare for ordinary knowledge workers. The FBI specifically recommended auditing current device code usage before blocking or restricting it, then using Conditional Access to limit the flow where possible.

SigninLogs
| where TimeGenerated > ago(14d)
| where AuthenticationProtocol =~ "deviceCode"
| summarize Count = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppDisplayName, IPAddress
| order by Count desc

If finance, HR, executives, administrators, or helpdesk users suddenly authenticate through device code from unfamiliar infrastructure, investigate immediately.

OAuth Redirect Indicators

Microsoft’s March 2026 research highlighted crafted OAuth URLs using parameters such as prompt=none, invalid scopes, encoded email addresses in state, and redirects to unexpected domains after identity-provider interaction.

For email, browser, proxy, and EDR telemetry, look for:

  • OAuth authorization URLs in phishing-themed messages.
  • prompt=none combined with unusual redirect destinations.
  • state= values that contain plaintext, base64, hex, or otherwise encoded email addresses.
  • Downloads where the referrer chain includes a trusted identity provider and the final host is unrelated.

The important idea is chain visibility. If your tools only inspect the first URL, the identity provider may look safe while the final landing page is not.

Hardening That Actually Reduces Risk

Microsoft Entra ID

Start with consent governance:

  1. Disable broad user consent or restrict it to verified publishers and low-impact permissions.
  2. Enable admin consent workflow so users can request approval instead of finding workarounds.
  3. Review existing enterprise applications and revoke unused or over-privileged grants.
  4. Block or tightly restrict device code flow unless there is a documented business need.
  5. Monitor new service principals, permission grants, and app role assignments.

Microsoft’s guidance for reducing consent phishing risk focuses on limiting user consent, reviewing application permissions, using publisher verification, and routing higher-risk requests through administrator approval. The operational detail that matters: changing future consent settings does not clean up old grants. You still need a review and revocation pass.

Google Workspace

Google Workspace administrators can control third-party and internal app access through API controls. Review authorized apps first, then decide which apps are trusted, limited, or blocked.

For high-risk environments, consider blocking unconfigured third-party API access and explicitly allowing only approved applications. Google notes that this can also block “Sign in with Google” for third-party apps, so test business impact before enforcing it broadly.

SaaS Owners

Security teams often own the identity provider, while business teams own the SaaS tools. That split creates gaps.

For every major SaaS platform, ask:

  • Which third-party apps are connected?
  • Which users or service accounts authorized them?
  • What scopes or roles do they hold?
  • When were they last used?
  • Who owns the business approval?
  • How do we revoke access during an incident?

If nobody can answer, the integration is not managed. It is just trusted.

Incident Response: Do Not Stop At The Password

When you suspect OAuth consent or token abuse, treat the app relationship as part of the compromise.

  1. Identify the app, client ID, service principal, scopes, redirect URIs, publisher, and consent timestamp.
  2. Determine who granted consent: user, administrator, or automated provisioning process.
  3. Revoke the app grant and remove the service principal if it is malicious or unnecessary.
  4. Revoke refresh tokens for affected users.
  5. Review mailbox, file, Teams, SharePoint, Google Workspace, and Graph API activity during the exposure window.
  6. Search for forwarding rules, inbox rules, new MFA methods, device registrations, and persistence changes.
  7. Hunt for the same app ID, redirect domain, sender infrastructure, or lure across other users.
  8. Document whether the root cause was user consent, admin consent, device code flow, redirect abuse, or a compromised legitimate integration.

That last step matters. If the incident is only labeled “phishing,” the fix becomes generic awareness training. The real corrective action may be consent policy, app inventory, token revocation, SaaS integration governance, or Conditional Access.

What To Do Today

Pull a list of every OAuth app with access to Microsoft 365 and Google Workspace. Sort by permission risk and last activity. Anything unused, unknown, unowned, or over-privileged goes into review.

Then make three policy decisions:

  1. Can ordinary users grant OAuth consent at all?
  2. Which permissions are low enough risk for self-service?
  3. Which flows, such as device code authentication, are actually required in your environment?

The answer does not need to be “block everything.” That usually breaks the business and trains users to bypass security. The answer should be controlled trust: approved apps, known owners, scoped permissions, visible logs, and a fast revocation path.

OAuth is not the enemy. Unmanaged OAuth is.

Sources