The Phishing Attack That Walks Right Past MFA

Multifactor authentication is the single best security control most small businesses have rolled out in the last five years. It stops the basic password-stuffing and credential-theft attacks cold. Anyone who tells you to skip it is wrong.

But there’s a class of phishing attack that walks right past MFA, and it’s been quietly hitting Microsoft 365 tenants at scale. This spring, a phishing-as-a-service operation called EvilTokens compromised more than 340 Microsoft 365 organizations across five countries in a matter of weeks using a close cousin of this technique — abusing Microsoft’s legitimate device-code sign-in flow so victims handed over valid tokens while completing what looked like a routine, MFA-verified login. The whole attack family works the same way: it never steals a password and never trips an MFA challenge. It looks like a normal Microsoft screen we’ve all clicked through a hundred times.

If your security training only covers “look for the typo in the URL and check for the padlock,” your team is going to lose to this one.

What’s actually happening

The technique is called OAuth consent phishing, sometimes called illicit consent grant attacks, and it abuses a feature of Microsoft 365 (and Google Workspace, and most other identity platforms) that’s perfectly legitimate when used correctly.

Here’s the legitimate version. You sign up for a new tool, let’s say a scheduling app. The app needs to read your calendar, so when you connect it, Microsoft shows you a consent screen that says something like “Acme Scheduler is requesting permission to read your calendar, send mail on your behalf, and access your files.” You click Accept. Microsoft gives the app a token that lets it do those things without ever seeing your password.

That’s OAuth. It’s everywhere. It’s how every “Sign in with Microsoft” or “Connect this tool to your Office 365” button works.

Now here’s the attack. The user clicks a link in an email. The email looks like a normal business message; maybe it’s pretending to be from a vendor, an HR system, or a coworker sharing a document. The link opens what looks like a sign-in page, but it’s actually a real Microsoft consent screen for a malicious app the attacker registered. The user doesn’t type their password into anything sketchy. They just click “Accept” because the screen has the Microsoft logo and looks like every other corporate sign-in flow they’ve ever seen.

The moment they click Accept, the attacker’s app gets a token. That token can read mail, send mail, download files from OneDrive, search SharePoint, and pull contact lists, depending on what permissions the attacker asked for. The user’s password is never disclosed. MFA was never triggered, because the user already had a valid session. The attacker now has persistent API access to that mailbox until the token is explicitly revoked, even if the user changes their password tomorrow.

That’s the trick. The attack doesn’t break MFA. It sidesteps the whole authentication question by exploiting authorization.

Why this is hitting now

OAuth consent phishing has been around for years, but three things have changed in the last twelve months that made it the attack of the month.

First, MFA is now common enough that attackers had to find a way around it. For years, enough small business mailboxes had no MFA at all that password phishing was free money. Now that most mailboxes have at least basic MFA, attackers are pivoting.

Second, the tooling has industrialized. EvilTokens and similar phishing-as-a-service platforms let any low-skill attacker rent a campaign. They don’t write the code. They pay a subscription, point and click, and get a working attack with a dashboard showing harvested tokens.

Third, Microsoft 365 makes it relatively easy for any user to grant consent to a third-party app by default. Until an administrator changes the tenant settings, a regular employee can click Accept on an OAuth consent screen and grant a malicious app real permissions to their mailbox, without any IT approval. This is the single setting most SMB tenants have wrong.

How to actually stop it

The good news is that the defense is well understood. The bad news is that almost no tenant has it configured correctly out of the box. Here’s the short list of what needs to be true in your Microsoft 365 environment.

Require admin consent for third-party apps

This is the single most important change. In Entra ID, under Enterprise Applications, there’s a setting called User consent for applications. The default historically allowed users to consent to apps that request a wide range of permissions. The right setting for almost every small business is “Do not allow user consent” or, at minimum, “Allow user consent for apps from verified publishers, for selected permissions.”

When this is set correctly, the consent screen no longer says “click Accept.” It says “this app requires admin approval, click here to request it.” That single change shuts down the attack pattern. An attacker can still send the phishing email, but the user can no longer hand over the tokens. The request lands in an admin queue where it can be denied or quietly investigated.

There’s a small productivity cost. Employees who legitimately want to connect a new tool now have to wait for IT to approve it. In practice that’s a feature, not a bug, because most “I want to connect this random AI note-taker to my mailbox” requests don’t survive a five-second review.

Set up the admin consent workflow

If you’re going to require admin approval, you also need a process for granting it. Microsoft has a built-in admin consent workflow that emails approval requests to designated reviewers, lets them see exactly what permissions the app is asking for, and lets them approve or deny with a click. It’s free, it ships with M365, and most tenants never turn it on.

A reasonable target turnaround is one business day. Slower than that and employees route around you, faster than that and the reviewer doesn’t have time to actually look at what they’re approving.

Block the device-code flow while you’re in there

One important caveat. The EvilTokens campaign that opened this post used device-code phishing — a close cousin that abuses Microsoft’s device sign-in flow, the “go to microsoft.com/devicelogin and enter this code” process built for TVs, kiosks, and shared devices. Locking down app consent does nothing against that one, because the victim is completing a real Microsoft sign-in, not approving an app. The fix is a Conditional Access policy in Entra ID that blocks the device code flow outright — there’s a dedicated authentication flows condition for exactly this. Most small businesses have zero legitimate use for device-code sign-ins, so blocking it costs nothing. If you do have conference-room hardware that needs it, scope an exception to those specific accounts instead of leaving the flow open for everyone.

Audit existing app consents

Even if you lock down future consents today, your tenant may already have malicious or forgotten apps with active tokens. Go into Enterprise Applications and look at what’s there. The first time most clients run this audit they find anywhere from a dozen to over a hundred third-party apps with permissions on their tenant. Many are legitimate but forgotten, some are old marketing tools nobody uses anymore, and occasionally one is a leftover from an active or attempted attack.

Revoke anything you can’t justify. If revoking might break a real workflow, ask the user. If the user doesn’t know what it is, revoke it.

Watch for new consent grants in your audit log

Microsoft 365 logs every consent grant. A well-run tenant has an alert that fires whenever a new app consent is granted, especially one with high-privilege permissions like Mail.ReadWrite or Files.ReadWrite.All. If an attacker did slip through, the alert is your chance to catch them before the token actually gets used against you.

Don’t forget about token revocation in your incident response

If you suspect an account has been compromised through OAuth consent phishing, changing the user’s password and re-prompting for MFA does almost nothing. The attacker’s token is still valid. You have to explicitly revoke the consented app, revoke the user’s active sessions, and rotate the OAuth tokens. Make sure this step is in your written incident response procedure.

How this connects to the broader Microsoft 365 hygiene problem

OAuth consent phishing is one symptom of a larger pattern we see constantly. Microsoft 365 ships with permissive defaults that made sense for a small company in 2018 and are too loose for a regulated or risk-averse business in 2026. The right defaults today include admin consent for third-party apps, conditional access policies that block legacy authentication, phishing-resistant MFA for administrators, sensitivity labels on confidential content, and aggressive review of guest access.

Each of these is a small configuration change. Together they shift your tenant from “out of the box” to “actually hardened,” and they cost nothing if you’re already paying for Business Premium or higher.

We’ve written about this from other angles too, including how AI tools at work create related data governance problems. The throughline is the same: most small businesses are paying for security features they haven’t turned on.

What good looks like

If you ran a quick health check against the things in this post, here’s what you’d want to see in a well-configured tenant:

• User consent for third-party apps is set to either Off entirely or restricted to verified publishers with low-risk permissions only.
• An admin consent workflow is enabled with a designated reviewer and a published SLA for response.
• The Enterprise Applications list has been audited in the last ninety days and stale or untrusted apps have been revoked.
• An alert exists for new high-privilege consent grants and routes to someone who actually reads it.
• The incident response playbook includes token revocation, not just password reset.
• MFA for administrators and finance staff is phishing-resistant: FIDO2 security keys or passkeys. (Number matching hardens push MFA against fatigue attacks and is a fine baseline for everyone else, but it isn’t phishing-resistant.)
• Conditional access blocks legacy authentication protocols and the device code flow, and enforces compliant devices for sensitive roles.

If you’re missing more than two or three of these, you’re operating with the doors propped open.

The bottom line

OAuth consent phishing is the attack pattern most security training never mentions and most Microsoft 365 tenants are wide open to. It doesn’t break MFA. It walks around it. The fix is a handful of configuration changes that take a couple of hours and cost nothing if you’re already on the right license.

The hardest part is knowing what to look for. If you’d like a second set of eyes on your Microsoft 365 tenant, book an intro call — qualifying businesses receive our $2,500 IT Risk Assessment complimentary, and it includes the exact checks described above. You’ll get a report showing which settings are misconfigured, which apps have permissions on your tenant that you may not have known about, and a prioritized list of changes ranked by how much risk they actually carry.

The attack already knows where to look. Your tenant should know too.