How Hackers Bypass MFA in Microsoft 365 — and How to Detect and Stop Them

Multi-Factor Authentication (MFA) is not a silver bullet.

Yes, enabling MFA in Microsoft 365 stops many attacks — but it doesn’t stop all of them. Threat actors know how to bypass MFA, abuse overlooked tenant settings, and even register their own MFA devices to stay persistent in your environment.

This blog breaks down:

• How attackers bypass MFA in Microsoft 365

• The kill chain of a real compromise

• KQL and Advanced Hunting queries to detect MFA bypass & persistence

• Response playbook commands to kick intruders out

The Kill Chain: How Microsoft 365 MFA Bypass Leads to Full Tenant Compromise

Here’s how modern attackers are breaking into Microsoft 365:

1. Initial Access – Phishing or credential stuffing to capture a username/password.

2. MFA Bypass – Use legacy authentication, adversary-in-the-middle (AiTM) phishing, or OAuth consent phishing.

3. Persistence – Register new MFA devices, grant OAuth tokens, or add inbox rules to hide traces.

4. Lateral Movement – Access SharePoint, OneDrive, Teams, or Graph API with stolen tokens.

5. Exfiltration – Auto-forward emails, download files, sync OneDrive.

6. 
   

Once they’re in, password resets alone don’t kick them out — persistence techniques mean they can walk right back in.

👉 See mind map below for a visual breakdown:

Mind map of MFA Bypass

Technique 1: Legacy Authentication (MFA Blind Spot)

Legacy protocols, such as POP, IMAP, SMTP, and MAPI, don’t enforce MFA. If these are still enabled, an attacker only needs a password.

Sentinel KQL

SigninLogs
| where ClientAppUsed in ("IMAP4","POP3","SMTP","Exchange ActiveSync","MAPI over HTTP","Other clients")
| project TimeGenerated, UserPrincipalName, ClientAppUsed, IPAddress, AuthenticationRequirement

Defender AH

IdentityLogonEvents
| where AppId in ("IMAP4","POP3","SMTP","MAPI over HTTP")
| project Timestamp, AccountUpn, AppId, IPAddress, AuthenticationRequirement

Tuning Tip:

Filter out known service accounts that must use legacy auth (then remediate them!).

Technique 2: Adversary-in-the-Middle (AiTM) Phishing

Attackers proxy the login page, steal session cookies, and replay them — bypassing MFA completely.

Sentinel KQL (Impossible Travel)

SigninLogs
| extend Country = tostring(Location.countryOrRegion)
| sort by UserPrincipalName asc, TimeGenerated asc
| extend PrevCountry = prev(Country), PrevTime = prev(TimeGenerated)
| where Country != PrevCountry and datetime_diff("minute", TimeGenerated, PrevTime) < 60
| project TimeGenerated, UserPrincipalName, PrevCountry, Country, IPAddress

Defender AH

IdentityLogonEvents
| extend Country = tostring(Location)
| sort by AccountUpn, Timestamp
| extend PrevCountry = prev(Country)
| where Country != PrevCountry and Timestamp - prev(Timestamp) < 1h

Detecting AiTM via User-Agent Anomalies

Many AiTM frameworks (Evilginx2, Modlishka, Muraena) don’t bother to mask their infrastructure. They use programmatic user-agents like axios, python-requests, or headless Chromium builds.

Sentinel KQL

SigninLogs
| extend UA = UserAgent
| where UA has_any ("axios","python-requests","curl","okhttp","phantomjs","headless","selenium")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed, UA
| order by TimeGenerated desc

Defender AH

IdentityLogonEvents
| where UserAgent has_any ("axios","python-requests","curl","phantomjs","headless","selenium","okhttp")
| project Timestamp, AccountUpn, IPAddress, AppDisplayName, UserAgent
| order by Timestamp desc

Tuning Tip:

• Some legitimate apps use odd UAs (mobile apps, automation). Build an allowlist for known traffic.

• Combine UA anomalies with impossible travel or unfamiliar IP ranges for higher fidelity detection.

Technique 3: OAuth Consent Phishing

A user clicks “Accept” on a malicious app and grants access to their mailbox, files, or Teams data. MFA doesn’t apply.

Sentinel KQL

AuditLogs
| where Category == "ApplicationManagement"
| where ActivityDisplayName in ("Consent to application","Add delegated permission grant")
| project TimeGenerated, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
          TargetApp = tostring(TargetResources[0].displayName),
          Scope =
tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)

Defender AH

CloudAppEvents
| where ActionType == "Consent to application"
| project Timestamp, UserId, AppId, AppDisplayName, Scopes

High-Risk Scopes to Flag:

offline_access, Mail.ReadWrite, Files.ReadWrite.All, User.ReadWrite.All, Directory.ReadWrite.All.

Technique 4: Attackers Register New MFA Devices

Once inside, attackers often add their phone, authenticator app, or FIDO key. Even if you reset the password, they can still authenticate.

Sentinel KQL

AuditLogs
| where Category == "UserManagement"
| where ActivityDisplayName in ("Register security info","Add authentication method","StrongAuthenticationMethodRegistered")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName),
         Method = tostring(TargetResources[0].displayName),
         IP = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, Actor, Method, IP, ActivityDisplayName

Defender AH

IdentityDirectoryEvents
| where ActionType in ("Add authentication method","Register security info")
| project Timestamp, AccountUpn, AuthenticationMethod, IPAddress

Tuning Tip:

Correlate new MFA registrations with unusual sign-ins or from unexpected geographies. Legit users add new devices — but rarely from Nigeria at 3 am.

Technique 5: Persistence via Inbox Rules

Attackers hide their tracks and exfiltrate data with malicious inbox rules.

Sentinel KQL

OfficeActivity
| where Workload == "Exchange"
| where Operation in ("New-InboxRule","Set-InboxRule")
| extend RuleData = parse_json(tostring(Parameters))
| project TimeGenerated, UserId, Operation, ClientIP,
          RuleName = tostring(RuleData.RuleName),
          ForwardTo = tostring(RuleData.ForwardTo)

Defender AH

OfficeActivity
| where Operation in ("New-InboxRule","Set-InboxRule")
| project Timestamp, UserId, Operation, ClientIP, Parameters

Quick Reference: MFA Bypass & Persistence Detection Map

Now that we’ve walked through each technique, here’s a one-page reference table mapping techniques → logs → queries → response actions.

Technique	Log Source	Query / Indicator	Response Action
Legacy Authentication (POP/IMAP/SMTP)	Entra ID Sign-In Logs (SigninLogs)	ClientAppUsed in ("IMAP4","POP3","SMTP","MAPI")	Block legacy auth via Conditional Access.
AiTM Phishing (Cookie Replay)	Entra ID Sign-In Logs	Impossible travel: Country != PrevCountry within 60 min	Revoke tokens, reset password + MFA, investigate IPs.
AiTM Infra Detection	Entra ID Sign-In Logs / Defender AH	UserAgent has_any ("axios","python-requests","headless","selenium")	Investigate IP/UA, correlate with suspicious sign-ins.
OAuth Consent Phishing	Audit Logs (ApplicationManagement)	ActivityDisplayName in ("Consent to application","Add delegated permission grant")	Revoke malicious apps (Remove-MgServicePrincipal), reset user tokens.
MFA Persistence (New Device Added)	Audit Logs (UserManagement)	ActivityDisplayName in ("Register security info","Add authentication method")	Clear MFA methods (Remove-MgUserAuthenticationMethod), force secure re-registration.
Malicious Inbox Rules (Persistence)	Office 365 Audit Logs (OfficeActivity)	Operation in ("New-InboxRule","Set-InboxRule") with forwarding or delete actions	Remove rules (Remove-InboxRule), review mailbox forwarding.
Mail Exfiltration (Bulk Access)	Office 365 Audit Logs (OfficeActivity)	Operation == "MailItemsAccessed"with abnormal volume	Investigate mailbox activity, revoke sessions, reset creds + MFA.

DFIR Response Playbook: Evicting Attackers

1. Block Legacy Auth

   1. Enforce Conditional Access to block POP/IMAP/SMTP/MAPI.

   
   

2. Revoke Tokens

Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>

3. Reset MFA

Get-MgUserAuthenticationMethod -UserId <UserId>
Remove-MgUserAuthenticationMethod -UserId <UserId> -AuthenticationMethodId <id>

4. Investigate OAuth Apps

Get-MgServicePrincipal | ?{$_.DisplayName -like "
<SuspiciousApp>*"}
Remove-MgServicePrincipal -ServicePrincipalId <id>

5. Purge Inbox Rules

Get-InboxRule -Mailbox <user@domain.com>
Remove-InboxRule -Identity <RuleName> -Mailbox <user@domain.com>

6. Force Secure Re-registration

   1. Reset Password and clear MFA. Require the user to re-enroll.

Real-World Examples

• Midnight Blizzard (APT29) abused consents in Microsoft's own environment 2023-24

• Scattered Spider (UNC3944) is notorious for AiTM phishing & cookie theft.

• Storm-1167 weaponized MFA fatigue/spam to trick users into approving logins.

Attackers study Microsoft 365 tenant weaknesses because it's the fastest way to ransom or steal data.

Why this Matters

Most SMBs believe "MFA is turned on, so we're secure." Attackers know this isn't true. That's why MFA bypass and MFA persistence are now the number one entry point in Microsoft 365 compromises.

Without regular log reviews and configuration assessments, you're leaving the door wide open.

How We Help (Free M365 Security Assessment)

At Inception Security, we run a free Microsoft 365 assessment that:

• Reviews your tenant for MFA bypass risks

• Surfaces suspicious OAuth consents & MFA persistence

• Checks for risky inbox rules and external forwarding

• Delivers a prioritized roadmap to secure your tenant