They Passed MFA. So Did the Attacker.

The user did everything right. They typed their password. They approved the MFA prompt. Twelve minutes later, someone else was in their mailbox.

That’s one of the incidents in a 10-week Microsoft 365 campaign tracked by Huntress. Between July 14 and September 22, 2026, Huntress responded to related incidents at 79 organizations and recorded 497 successful sign-ins, along with more than 200,000 failed attempts. In Huntress’s words, the accounts “were compromised without the attacker ever needing a password.”

MFA did its job. It confirmed the right person was signing in. The problem is what happened after.

What Huntress found

A quick note on scope before the details. The 79 organizations are Huntress customers, so this is what one security provider saw in its own customer base, not a measurement of every Microsoft 365 tenant. The replay traffic came from rented addresses at a German hosting provider, and Huntress describes that provider as offering a legitimate hosting service that attackers rent, a tactic it calls “bring your own IP.” Using a provider’s network isn’t evidence the provider was involved.

Here’s how the campaign worked, according to Huntress:

• Capture. Victims signed in through an adversary-in-the-middle (AiTM) relay, a fake sign-in page that passes the real Microsoft login and MFA prompt through to the user. Once the user finishes, the relay keeps the token Microsoft issues to prove the sign-in succeeded. Other tokens came from device-code phishing and from social engineering during a legitimate login.

• Replay. The attacker reused those tokens from their own machines, at volume, across many organizations. Huntress calls this “token spraying”: the same idea as password spraying, but with stolen tokens instead of guessed passwords. On July 21, the gap between the victim reaching the MFA prompt and the hijacked session appearing was 12 minutes. On September 22, it was four.

• Settle in. Once inside, the attacker built ways back. Huntress found at least 48 rogue devices registered in victims’ Microsoft Entra directories. In 19 organizations, the victim’s MFA methods were wiped and replaced with a new one within three hours of the first sign-in from a campaign address.

• Hide and profit. The attacker created inbox rules with forgettable names like . and sss that deleted mail or moved it to folders nobody checks, such as RSS Feeds. In one case, the attacker sent a payroll-related email to an outside CPA, then set a rule to hide the CPA’s replies from the real user.

That last detail is the business email compromise payoff. The attack didn’t need malware, and it didn’t need a password.

Why MFA didn’t stop it

MFA protects the moment of sign-in. Once you sign in, Microsoft issues tokens so you don’t have to prove yourself again for every email you open. As Huntress explains, that token is minted after MFA, so “whoever holds it doesn’t need to pass MFA again.”

Microsoft’s own security guidance says the same thing in different words. Its Zero Trust documentation warns that attackers can bypass traditional multifactor authentication through adversary-in-the-middle attacks and establish persistent access through token theft.

Phishing pages aren’t the only way tokens leak, either. Microsoft recently fixed CVE-2026-80097, a flaw in Microsoft Authenticator for Android that let a malicious app with no permissions pose as a trusted Microsoft app, such as Teams, and collect sign-in tokens for the user’s work account, according to The Hacker News. In the researchers’ tests, those tokens gave access to the account’s email, files, and calendar. Microsoft says the flaw hasn’t been exploited, rates exploitation as “less likely,” and fixed it in Authenticator for Android version 6.2606.4246. It’s a different route to the same prize: a token that already counts as signed in.

None of this means MFA is optional. Without it, attackers don’t need relays or malicious apps. They just need a password. MFA is the floor. It isn’t the finish line.

The control that made the difference

The most useful finding in the Huntress report is about what worked.

On September 11, the attacker started an automated replay burst from a single address. Over four days, that address completed 303 successful sign-ins across 29 organizations. The same address was also blocked 1,052 times, and every one of those blocks came from just four organizations whose Conditional Access policies refused the sign-ins. In the organizations where it got in, Huntress wrote, “nothing stood in the way.”

Same attacker. Same tokens. Same week. The difference was policy.

Huntress drew two more lessons from that burst that MSPs should borrow:

• Don’t triage by spray volume. All of the blocked attempts came from the four tenants where Conditional Access was already working, and none of the compromised tenants were in that group. Ranking by failed attempts would have sent responders to the wrong place. Prioritize by whether a credential was valid, not by how noisy the attack was.

• A Conditional Access block is a warning, not a save. A block with error code AADSTS53003 happens after authentication succeeds. It means the attacker had something that worked. Treat it as a reason to investigate that user.

What MSPs should change now

1. Build Conditional Access with no quiet exceptions

Huntress’s guidance is blunt: require MFA, or block, for all users, all cloud apps, and all client app types, unconditionally.

In practice, most gaps aren’t missing policies. They’re exceptions that were added for a reason nobody remembers: a service account, an executive who travels, a legacy app, a pilot group that never ended. Each one is a door an attacker can test.

For every client tenant:

• Start from all users and all resources, then exclude only what you can name and defend. Microsoft’s own templates exclude emergency access (break-glass) accounts to prevent lockout and recommend auditing exclusion lists regularly.

• Give every exception an owner, a reason, and a review date.

• Check licensing up front. Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium. Risk-based policies, which react to risky sign-ins and users, require Entra ID P2, per Microsoft. If a client is on a plan without Conditional Access, that’s a conversation worth having now, with this campaign as the example.

2. Block device-code sign-in where clients don’t need it

Device-code sign-in lets you sign in to a device without a keyboard, like a conference room display, by entering a code on another device. Attackers abuse it by tricking users into entering the attacker’s code on Microsoft’s real sign-in page. Huntress saw exactly that in the campaign’s second wave.

Microsoft recommends getting as close as possible to a unilateral block on device code flow, allowing it only for well-documented and secured use cases. It also recommends running the policy in report-only mode first to see who still uses it. That’s the right order for MSPs too: audit, document the real exceptions, then block.

3. Make stolen tokens harder to get and harder to reuse

No single setting fixes token theft. Microsoft’s token protection guidance layers several controls, and most of them fit an MSP roadmap:

• Phishing-resistant MFA, starting with admins. Passkeys use origin-bound cryptography, so a passkey only works on the website or the app you created it for. A relay page on a lookalike domain can’t use it. Microsoft’s guidance is to enforce phishing-resistant methods through Conditional Access authentication strengths. Start with global admins and anyone who can move money.

• Require compliant devices. Microsoft recommends a Conditional Access policy that requires a compliant device to access all resources, which blocks access from unmanaged machines. Where clients are already enrolled in Intune, this is often the biggest single step.

• Use token protection where it fits. Token protection is a Conditional Access setting that accepts only sign-in tokens bound to the device they were issued to, so a stolen bound token can’t be used from another device. Know its limits before you sell it: support covers native apps connecting to Exchange Online, SharePoint Online, and Teams on supported, registered devices, while browser-based support is limited and in preview. It’s a strong layer, not a blanket.

• Keep the Android Authenticator app current. For clients with managed Android devices, set a minimum version of 6.2606.4246 or later through device management, as The Hacker News notes organizations can.

4. Lock the doors attackers use to come back

The rogue devices and replacement MFA methods in this campaign were the attacker’s insurance. Both are settings you can control:

• Protect security info registration. Conditional Access can treat MFA registration like an app and require an authentication strength or a trusted location before anyone adds or changes a sign-in method. A stolen session from a hosting provider shouldn’t be enough to register a new authenticator.

• Require MFA to register or join devices. By default, Entra lets all users join devices and doesn’t require extra authentication to do it. Microsoft recommends using the Register or join devices user action in Conditional Access to require MFA, and admins can limit who is allowed to join devices at all.

• Turn off user consent to new apps. Huntress recommends disabling the ability for standard users to consent to new applications and having them request access instead, since attackers can use app consent as another way to stay in a tenant.

Why a password reset alone doesn’t finish the job

This is where many incident responses stop too early.

Resetting the password feels like locking the door. But in this campaign, the attacker had already installed new locks. Huntress is direct about it: a password reset alone does not remove attacker-registered devices or MFA methods. And Microsoft’s documentation notes that revoking a user’s sessions stops them from getting new tokens, but already-issued access tokens remain usable until they expire, which is one hour by default.

When you suspect token theft, work the whole list:

1. Revoke sessions and reset the password together. Do both. One without the other leaves a gap.

2. Audit MFA methods. Look for methods that were cleared and re-registered within minutes, and remove any authenticator the user doesn’t recognize. Huntress saw an attacker-registered authenticator labeled “iPhone 13.”

3. Audit registered devices. Huntress’s rogue devices were named DESKTOP- plus eight hexadecimal characters, which doesn’t match Windows’ own default naming. Confirm before deleting, since the pattern isn’t unique to this campaign. Microsoft’s emergency revocation guidance includes disabling a user’s registered devices as part of the response.

4. Review inbox rules. Look for rules with one- to three-character or punctuation-only names, rules that move mail to RSS Feeds, RSS Subscriptions, or Conversation History, and rules keyed to payroll or banking terms.

5. Check for new enterprise apps and consents granted since the first suspicious sign-in.

6. Check what was sent. Review the mailbox’s sent items for messages the user didn’t write. If anything went to vendors, clients, or an accountant, call those contacts directly. The payroll email in this campaign was aimed at someone outside the organization.

Write this list into your incident runbook as a single procedure, so nobody on the help desk stops at step one.

Turning this into evidence

Clients and their insurers don’t just want to hear that MFA is on. Increasingly, they want proof of how access is controlled. This campaign gives you a clear way to show it.

For each client, keep a short identity record you can update every quarter:

• Conditional Access coverage: which policies are on, and every exclusion with its owner, reason, and review date

• Device-code sign-in status: blocked, or allowed for named and documented uses

• Phishing-resistant MFA coverage for admins and finance roles

• Device registration and security info registration controls

• The token-theft response runbook, and the date it was last tested

In a QBR, that turns a technical story into a business one: here’s how someone could get past MFA, here’s what we’ve put in their way, and here’s what we’d do in the first hour if they tried. That’s a security program working the way it should.

Frequently asked questions

Q: How can attackers get past MFA in Microsoft 365?

Attackers can steal the sign-in token Microsoft issues after MFA succeeds and reuse it from their own machines. In the campaign Huntress tracked, victims signed in through fake pages that relayed the real Microsoft login and MFA prompt, while the relay kept the resulting token. Because the token is created after MFA, the attacker doesn’t need to pass MFA again.

Q: What is token replay, or token spraying?

Token replay is reusing a stolen sign-in token to access an account without a password or MFA prompt. Huntress uses the term “token spraying” for replaying many stolen tokens at volume across many organizations, the same pattern as password spraying but with tokens instead of guessed passwords.

Q: Does resetting the password stop a token theft attack?

Not by itself. Microsoft says revoking sessions stops new tokens from being issued, but existing access tokens stay valid until they expire, one hour by default. And a password reset doesn’t remove devices or MFA methods the attacker registered. Revoke sessions, reset the password, then audit MFA methods, registered devices, inbox rules, and app consents.

Q: Should MSPs block device code flow?

Yes, for most users. Microsoft recommends getting as close as possible to a unilateral block on device code flow and allowing it only for documented, secured use cases. Run the policy in report-only mode first to find legitimate uses, such as conference room devices, before turning it on.

Q: Was the Microsoft Authenticator for Android flaw exploited?

Microsoft says no. CVE-2026-80097 let a malicious Android app pose as a trusted Microsoft app and collect work-account sign-in tokens, and Microsoft fixed it in Authenticator for Android version 6.2606.4246, according to The Hacker News. Microsoft says the flaw hasn’t been used in attacks and rates exploitation as “less likely.” Organizations can require the fixed version through device management.