top of page

Why MFA Isn't Enough: Device-Code Phishing, AiTM and MFA Fatigue, Explained

Writer: Dane Gray
Dane Gray
Oct 2
8 min read

Updated: 18 hours ago

Ask a business owner how their email is protected and the most common answer is "We have MFA." Good. Keep it. Multi-factor authentication (MFA) stops a huge share of password attacks, and nothing in this post says otherwise.

But in September 2026, Microsoft described a phishing service called EvilTokens whose campaigns "compromised more than 12,000 inboxes in over 10,000 organizations worldwide." Those attacks didn't need to break MFA. They got people to approve the attacker's sign-in themselves.

Here are the three ways attackers get past MFA in Microsoft 365, what each one looks like to your staff, and what closes the gap.

THE SHORT VERSION

MFA still stops most password attacks. But device-code phishing tricks users into approving an attacker's sign-in on the real Microsoft page, AiTM phishing steals the session after MFA, and MFA fatigue floods phones with prompts until someone taps approve. Phishing-resistant MFA, blocked device code flow, number matching and after-sign-in monitoring close the gap.

Keep MFA. Here's what it doesn't stop.

Microsoft is clear on this: "Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats." The attacks below don't defeat MFA by guessing codes. They go around it, by borrowing a real sign-in or stealing what MFA hands out once you've passed.

  • Device-code phishing: the attacker starts a real Microsoft sign-in and tricks you into finishing it for them.

  • Adversary-in-the-middle (AiTM) phishing: a fake page sits between you and Microsoft and copies your session after you pass MFA.

  • MFA fatigue: the attacker already has your password and floods your phone with approval prompts until someone taps "Approve."

Attack

What your employee sees

What the attacker gets

What stops it

Device-code phishing

An email asking them to enter a code on Microsoft's real sign-in page

A signed-in session on the victim's account, approved by the victim

Blocking device code flow; "never enter a code you didn't ask for"

AiTM phishing

A sign-in page that looks exactly like Microsoft's, and a normal MFA prompt

The session cookie, so they can be signed in without the password or MFA

Phishing-resistant MFA (passkeys or FIDO keys); sign-in rules that only allow company devices

MFA fatigue

A string of approval prompts they didn't ask for, often at odd hours

One accidental or annoyed "Approve"

Number matching; phishing-resistant MFA; reporting unexpected prompts

Device-code phishing (the EvilTokens example)

Device code sign-in is a real Microsoft feature. Microsoft describes it as "a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs, printers, Teams devices, and conferencing devices." You see a short code on the TV, type it on your phone, and the TV gets signed in.

Attackers turn that around:

  1. The attacker starts a device code sign-in and gets a code.

  2. They email it to your employee with a lure. One Microsoft documented: "Action Required: Password Expiration."

  3. The employee goes to Microsoft's real page, microsoft.com/devicelogin, and enters the code. Everything they see is genuine.

  4. In Microsoft's words: "When the user enters the code, they unknowingly authorize the threat actor's session."

The page is real. The code is real. The device on the other end isn't yours.

What happened next in the EvilTokens cases is the part owners should worry about. Some attackers moved "within 10 minutes of the breach" and "registered new devices" to keep long-term access. Others "waited several hours before creating malicious inbox rules," the kind that quietly hide replies from a bank or client. EvilTokens isn't the only example, either: Microsoft also wrote about a separate device code phishing campaign in April 2026. The technique matters more than any one kit.

How to stop device-code phishing

  • Block device code flow. "Microsoft recommends blocking device code flow wherever possible," and its Conditional Access guidance shows how. Allow narrow exceptions only for devices that really need it, such as conference-room Teams devices.

  • Give staff one simple rule: never enter a code you didn't ask for. If an email asks you to type a code into a Microsoft page, call IT first.

24uNet can block device code sign-in across your Microsoft 365 tenant, with narrow exceptions for the devices that genuinely need it. The details depend on your setup, so we work them out with you: Book a security review or email sales@24unet.com.

AiTM phishing: when the attacker steals the session, not the password

In an adversary-in-the-middle attack, the phishing page passes everything you type through to the real Microsoft sign-in, in real time. You enter your password, you approve the MFA prompt, and you're signed in. Meanwhile, the attacker's server keeps a copy of "the session cookie" Microsoft just issued. With it, they can be signed in as you without your password or your phone.

Microsoft is careful to say "this is not a vulnerability in MFA." MFA did its job. The attacker simply took what MFA produced.

In one AiTM campaign Microsoft tracked, attackers started payment fraud in "as little time as five minutes" after stealing the session. They also set up an inbox rule to hide the victim's replies, telling Outlook to "move the mail to 'Archive' folder and mark it as read," so nobody at the company saw the conversation happening.

How to stop AiTM phishing

  • Phishing-resistant MFA. Passkeys and FIDO security keys only work with the real Microsoft sign-in, so a look-alike page has nothing to relay. CISA calls FIDO/WebAuthn "the only widely available phishing-resistant authentication" (CISA fact sheet). Start with admins and anyone who approves payments.

  • Sign-in rules for devices. Conditional access rules that only let company-managed devices in make a stolen session much harder to use from an attacker's computer.

  • Watch for the follow-up. New inbox rules, sign-ins from unusual places and new MFA methods are the signs that a session has been stolen.

24uNet can roll out phishing-resistant MFA and device-based sign-in rules, starting with the accounts attackers target most. Book a security review or email sales@24unet.com to plan what fits your firm.

MFA fatigue attacks (push bombing)

CISA's definition is the clearest: MFA fatigue, "also known as 'push bombing,' occurs when a cyber threat actor bombards a user with mobile application push notifications until the user either approves the request by accident or out of annoyance."

It works because people are human. A prompt at 2am on a Saturday, the tenth one in a row, from what looks like Microsoft, gets tapped just to make it stop. And remember what the prompts mean: the attacker already has the password.

How to stop MFA fatigue

  • Turn on number matching. The user has to type the number shown on the sign-in screen, so a blind "Approve" no longer works. Microsoft's number matching guide explains how it works. CISA recommends it as an interim step on the way to phishing-resistant MFA.

  • Move to phishing-resistant MFA for the people attackers target most.

  • Report every unexpected prompt. CISA's point: since MFA checks happen after the password, "denied MFA requests could mean the user's password is compromised." A denied prompt is a reason to change that password.

24uNet can turn on number matching, move your key people to phishing-resistant MFA, and provide security awareness training, online or in person. Book a security review or email sales@24unet.com to talk it through.

What closes the gap: settings plus someone watching

The settings come first. Here's the short list to hand your IT provider:

  • Phishing-resistant MFA for admins and finance staff first, then everyone

  • Device code flow blocked, with narrow exceptions

  • Legacy authentication blocked (older sign-in methods that skip MFA)

  • Number matching on

  • Conditional access rules for devices and locations

Then the part settings can't fix: a session that looks valid. If an attacker signs in with a stolen session, every setting above says "this is a normal user." What catches it is someone watching what an identity actually does after it signs in: a new inbox rule, a new device registered at an odd hour, a mailbox suddenly forwarding mail. That's what identity threat detection and response (ITDR) is for.

If you think it has already happened: Microsoft notes that revoking sessions "often only invalidates refresh tokens, leaving existing access tokens active for up to an hour," so it recommends "temporarily disabling the compromised account to ensure immediate containment." Microsoft's guide to responding to a compromised email account walks through the rest.

Want to know how your Microsoft 365 would hold up? Book your independent security review or email sales@24unet.com.

Why this matters for firms that move money

Every attack in this post ends in the same place: someone reading your email as you. For a wealth management firm, a law firm closing a deal, or an engineering firm paying subcontractors, that's how a hidden inbox rule turns into "new wiring instructions" sent from a real account.

Business email compromise (BEC) was the second-largest loss category in the FBI's 2025 Internet Crime Report. In 2025 the FBI's IC3 received 24,768 business email compromise complaints, with reported losses of $3,046,598,558 (FBI IC3 2025 report).

For the money-movement side, read how wealth firms stop wire fraud. We also cover this for financial services firms, law firms and engineering firms.

Five questions to ask your IT provider

  1. Is device code flow blocked for our Microsoft 365 tenant?

  2. Do our admins and finance staff use phishing-resistant MFA?

  3. Is number matching on, and is legacy authentication blocked?

  4. Who gets alerted if someone signs in from a stolen session at 2am on a Saturday, and who is allowed to act?

  5. Would we know if a new inbox rule started hiding the bank's replies?

If any answer is "I'm not sure," that's the place to start.

Frequently asked questions

What is device code phishing?

An attacker starts a real Microsoft "device code" sign-in and tricks you into entering the code on Microsoft's real page, which signs the attacker in. Microsoft recommends blocking device code flow wherever possible.

What is AiTM phishing?

Adversary-in-the-middle phishing puts a fake page between you and the real Microsoft sign-in, so the attacker captures your session cookie after you complete MFA.

What is an MFA fatigue attack?

The attacker, already holding your password, floods your phone with MFA push prompts until someone approves one. CISA recommends phishing-resistant MFA, or number matching in the meantime.

Does MFA stop phishing?

It stops many attacks, but not these three. Phishing-resistant MFA (passkeys or FIDO keys) resists all of them far better than push or text codes.

How do I block device code flow in Microsoft 365?

With a Conditional Access policy that blocks the device code authentication flow, with narrow exceptions for devices that really need it. Microsoft Learn has the steps.

What is EvilTokens?

A phishing-as-a-service kit Microsoft described in September 2026 that used device-code phishing; Microsoft says it compromised more than 12,000 inboxes in over 10,000 organizations.

Is MFA still worth it?

Yes. Microsoft calls it "an essential pillar in identity security." The goal is stronger MFA plus monitoring, not less MFA.

See what's already happening in your Microsoft 365

Settings close most of the gap. Someone watching closes the rest. 24uNet's independent security review checks your Microsoft 365 sign-in settings against everything in this post and shows you what we'd fix first. About an hour, no tooling to install, no access required, and the written findings are yours to keep.

ABOUT THE AUTHOR

Dane Gray, Cofounder, 24uNet. Certified Ethical Hacker (CEH), CompTIA Security+, Texas A&M University, 25+ years in IT. Dane leads independent security reviews, SEC exam prep for RIAs and broker-dealers, and CMMC Level 1 readiness for firms in Commerce City, CO 80022 and College Station, TX 77845. Connect with Dane on LinkedIn.

Last reviewed: October 2, 2026

Dane Gray, cofounder of 24uNet
 
 
 

Comments


bottom of page