MFA Bypassed? Token Theft and the AiTM Response in Microsoft 365

Your accounts-payable clerk approved the MFA prompt on her phone this morning, exactly as trained, and the sign-in logs now show her mailbox being read from a country nobody at the company has visited. The ticket will get filed as MFA bypassed token theft, and that is half right: nothing defeated the second factor, because the attacker stole what the second factor produced.

That distinction decides the response: kill the sessions, remove what the attacker planted, then change which sign-ins the tenant will accept at all.

What actually happened: MFA was satisfied, not bypassed

The technique is adversary-in-the-middle (AiTM) phishing. In Microsoft's July 2022 threat intelligence write-up, attackers deploy a proxy server between a target user and the website the user wishes to visit. The phishing page holds two TLS sessions, one with the victim and one with the real sign-in service, and relays everything between them. The user types a password into what looks like the normal Microsoft sign-in page, approves the prompt, and lands on the legitimate office.com page. Meanwhile the proxy has kept a copy of the password and the session cookie.

Microsoft is explicit that this is not a vulnerability in MFA. The session cookie is the proof that authentication already happened, so whoever holds it skips the sign-in process. In the campaign Microsoft tracked, the stolen cookies in multiple cases carried an MFA claim, which is why the attacker could open Outlook on the web as the user even though the organization had an MFA policy in place.

Details from that report:

• The phishing site proxied the real Azure AD sign-in page, and if the tenant had configured company branding, the fake page showed that branding too.
• Because every request is relayed from the real site, the URL is the only visible difference.
• Open-source kits automate the whole thing; Microsoft names Evilginx2, Modlishka and Muraena.
• The campaign attempted to target more than 10,000 organizations since September 2021, and payment fraud started in as little as five minutes after the credential and session theft.

The first hour: what to do, in what order

Microsoft's guidance for a compromised cloud mailbox starts by disabling the account, and calls disabling preferred and highly recommended until the investigation is done. In the Microsoft Entra admin center, browse to Entra ID then Users then All users and select the user. Under Account status, select Edit, clear Account enabled, and save. Then, on the user's Overview page, select Revoke sessions.

The PowerShell route uses the Microsoft Graph SDK. Connect with Connect-MgGraph -Scopes User.RevokeSessions.All, then run Revoke-MgUserSignInSession -UserId followed by the user's UPN. Microsoft describes this as revoking all active sign-in sessions and invalidating existing refresh tokens.

If the account cannot be disabled, Microsoft's next best step is an immediate password reset; otherwise the reset can wait until the cleanup below is done, just before re-enabling. Either way the rules are specific. Do not send the new password to the user by email, because the attacker may still be reading that mailbox. Do not reuse any of the last five passwords even if password history allows it. If the account is synced from on-premises Active Directory, reset the password there, and reset it twice to mitigate pass-the-hash. If the identity is federated, the change has to happen in the on-premises environment. And app passwords are not automatically revoked by a password reset; the user has to delete the existing ones and create new ones.

What the attacker left behind

Killing the session ends the attacker's current access. It does not undo what they configured while they had it. Microsoft frames the remaining steps as addressing known methods an attacker uses to maintain persistence and regain control of the account later, and it lists them in order:

• Review the MFA registered devices and remove any unrecognized MFA methods.
• Review the applications the user has consented to and revoke any that should not be there.
• Review administrative roles assigned to the user.
• Review mail forwarding and Inbox rules.

For forwarding, connect to Exchange Online PowerShell and run Get-Mailbox -Identity with the mailbox, piped to Format-List Forwarding*Address,DeliverTo*. A nonblank ForwardingSmtpAddress means mail is going to an external recipient; a nonblank ForwardingAddress means an internal one. For rules, run Get-InboxRule -Mailbox with the mailbox and the -IncludeHidden switch, piped to Format-List Name,Enabled,RedirectTo,Forward*,Identity. Read every rule, not only the forwarding ones: Microsoft's list of compromise symptoms includes rules that move messages to the Notes, Junk Email or RSS Subscriptions folders.

Then read the logs. In the Entra sign-in logs, look at IP address, sign-in locations, sign-in times, and success or failure. In the Defender portal audit log, Microsoft advises filtering by a date range that starts immediately before the suspicious activity and not filtering on specific activities during the initial search. Microsoft also points to message trace in the Defender portal and to the Sent Items folder.

Worked example: the accounts-payable mailbox

Take a 40-person distribution company. The AP clerk receives an email saying she has a voice message, with an HTML attachment. That is the lure Microsoft documented: the attachment shows a fake download progress bar, then redirects to a phishing page with her email address already filled in. She signs in, approves the prompt, and ends up on office.com. Nothing looks wrong.

Over the next few days the attacker, in Outlook on the web, reads finance threads and attachments, deletes the original phishing email from her Inbox, and finds an open invoice conversation with a freight supplier. Before replying on that thread, the attacker creates an Inbox rule. In the campaign Microsoft analyzed, the rule logic was: for every incoming email where the sender address contains the fraud target's domain, move it to Archive and mark it as read. The attacker then replies with new banking details and deletes those replies from Sent Items and Deleted Items.

The supplier's controller notices first, because the payment went somewhere odd. The admin disables the clerk, revokes sessions, and runs Get-InboxRule with -IncludeHidden. The rule shows up with the supplier's domain in its condition, which says where to look: the Archive folder holds the replies the clerk never saw, and message trace is the next place to check for outbound messages missing from Sent Items. Microsoft observed attackers updating the same rule to include each new target's domain, so every domain in that condition is a business that needs a call on the main number already on file, not one taken from the thread.

Once the rule, any forwarding, any added MFA method and any consented app are gone, the admin resets the password, hands it over in person, and re-enables the account, which is Microsoft's post-investigation order.

Where this goes wrong

Revoking does not end access instantly. The Entra revocation doc says that after an admin revokes, the user cannot get new tokens, but for applications using access tokens the user loses access when the access token expires. By default those last one hour. For browser applications with their own session tokens, Microsoft Entra ID cannot directly revoke a session token issued by an application; the session ends when that token expires or the app acts on its own.

Continuous access evaluation narrows that window, with conditions. Exchange Online, SharePoint Online and Teams subscribe to critical events, including an administrator revoking all refresh tokens and a password being changed or reset. Microsoft's target is near real time, but latency of up to 15 minutes might be observed. In CAE sessions, access tokens can be long-lived, up to 28 hours, because events rather than expiry drive revocation. Clients that are not CAE-capable keep the one-hour default.

Resetting the password without revoking leaves the stolen cookie where it was; it never needed the password, and Microsoft Entra ID cannot directly revoke a session token an application issued. Revoking without resetting leaves the attacker holding a password they already captured. Doing both and stopping there leaves the Inbox rule, the forwarding address, any MFA method the attacker registered and any app they consented to, each of which Microsoft treats as a way back in.

The fixes that actually stop the next one

Since the attack relays a normal sign-in, the durable fix is a sign-in method built to resist phishing. Microsoft's 2022 report already pointed to FIDO v2.0 and certificate-based authentication. CISA's fact sheet calls phishing-resistant MFA the gold standard and says the only widely available form is FIDO/WebAuthn authentication. It also names PKI-based MFA, such as smart cards, but notes that it requires highly mature identity management practices. For small and medium businesses that cannot move immediately, CISA says app-based or token-based OTP, or mobile push with number matching, are the best interim options, and that SMS or voice should be a last resort.

In Entra, this is enforced with a Conditional Access policy using Require authentication strength. The built-in Phishing-resistant MFA strength allows Windows Hello for Business or platform credential, a FIDO2 security key (passkey), and certificate-based authentication (multifactor). Conditional Access needs a Microsoft Entra ID P1 license. The stated limitation: an authentication strength does not restrict a user's initial authentication, so a user can still enter a password, but must then sign in with a phishing-resistant method before continuing. Users who sign in with a password first are not automatically prompted for Windows Hello for Business; they have to restart and choose it under Sign-in options.

A compliant-device requirement attacks the replay directly. Microsoft's 2022 report notes that Conditional Access policies are evaluated and enforced every time an attacker attempts to use a stolen session cookie, and recommends policies such as compliant devices or trusted IP addresses. The grant control is Require device to be marked as compliant, under Entra ID then Conditional Access then Policies. Microsoft's warnings: without an Intune compliance policy the CA policy will not function as intended, emergency access accounts should be excluded, and the policy should start in report-only mode.

Token Protection binds sign-in session tokens to the device, so a stolen token cannot be used from another device. Its reach is the catch. For native applications it can be enforced on Exchange Online, SharePoint Online and Teams. Browser support is limited to selected web apps that access Azure Resource Manager, in preview. The attacker in Microsoft's report used Outlook on the web in Chrome.

CAE adds location: Microsoft says token export to a machine outside a trusted network can be prevented with Conditional Access location policies, though Teams calls and chat do not adhere to IP-based policies.

The decision rule

When a user completed MFA and the attacker still got in, treat it as a stolen session: disable, revoke, then clear rules, forwarding, MFA methods and app consents before the password reset and re-enable. Then pick the prevention by asking which sign-ins your tenant still accepts from a device it has never seen. If the answer is any of them, phishing-resistant MFA for finance and admins and a compliant-device requirement come first; Token Protection and CAE are layers on top, not substitutes.