How to detect MFA bypass and fatigue attacks

Threat snapshot

Multi-factor authentication was supposed to be the answer to credential-based attacks. And for a long time it was. Then attackers adapted. Today the most effective identity attacks in enterprise environments do not defeat MFA by cracking it; they route around it entirely, or they use it against the user.

MFA fatigue, also called MFA push bombing, exploits the design of push-based authenticators. The attacker has a valid username and password, typically obtained through phishing or credential stuffing. They initiate repeated authentication requests, each of which sends a push notification to the victim's phone. The victim receives one, two, five, twenty push requests in rapid succession. Some users approve one by accident. Some approve one out of frustration. Some approve one because they assume it is a technical glitch. The attacker's goal is not to crack the MFA system; it is to exhaust the user's attention and patience until they click approve.

Beyond fatigue attacks, several other bypass paths have become operationally significant: Temporary Access Pass (TAP) creation by compromised admins, Conditional Access policy modification to weaken or disable MFA requirements, and PIM role escalation to gain standing access that bypasses standard MFA enrollment checks. Each of these attacks leaves a distinct audit trail in Microsoft 365 and Azure AD logs, provided those logs are being collected and monitored.

This page covers all three bypass approaches, maps each to Log360's detection rules, and provides the investigation workflow for responding when these rules fire.

MFA bypass and fatigue, at a glance

How MFA bypass attacks work

There is no single MFA bypass technique. Attackers choose their approach based on what they already have (a credential, an admin account, helpdesk access) and what the target organization's MFA configuration looks like. The diagram below shows the four most operationally significant paths.

MFA fatigue (push bombing) - T1621

The attacker possesses a valid M365 username and password, obtained through phishing, credential stuffing, or password spraying. They initiate authentication repeatedly in rapid succession. Each initiation sends a push notification to the user's registered MFA device. The volume of requests is intentional: the goal is to saturate the user's notification feed until they approve one, either by mistake, fatigue, or the assumption that the requests are a system error.

The attack is particularly effective after hours, on weekends, or during high-stress periods when users are less likely to scrutinize authentication prompts carefully. Some operators combine the push flood with a concurrent phone call to the victim, impersonating IT support and asking the user to "approve the pending notification" to resolve a fabricated account issue. The M365 audit log records each denied push as a distinct event; a burst of denied MFA requests from the same user within a short time window is the primary detection signal.

Log signals: M365 sign-in log entries showing MFA requests with result "MFA denied" or "MFA failed" in rapid succession for the same user, particularly from a new or unrecognized IP address.

Temporary Access Pass (TAP) creation abuse - T1078.004

A Temporary Access Pass is a time-limited, PIN-based credential in Azure AD that allows authentication without MFA. It is designed for legitimate use cases such as onboarding new employees or recovering access for accounts that have lost their MFA device. However, a compromised admin account can create a TAP for any account in the tenant, giving the attacker a credential that bypasses MFA entirely for the duration of the TAP's validity window.

TAP abuse is operationally efficient from the attacker's perspective: a single compromised admin account can generate TAPs for dozens of high-value accounts, each giving a fresh, MFA-bypassing access window. The TAP creation event is logged in the Azure AD audit log and is the earliest detection point for this attack. Once a TAP has been created and used, the attacker's subsequent authentication uses the TAP credential and leaves no MFA failure events at all.

Log signals: Azure AD audit log event "Add Temporary Access Pass method" for any account, especially when performed by an account that does not typically perform administrative identity management actions, or when multiple TAPs are created in a short time window.

Conditional Access policy tampering - T1548

Conditional Access policies in Azure AD define the conditions under which MFA is required for authentication: specific user groups, application types, network locations, device compliance states, and sign-in risk levels. An attacker with sufficient privileges can modify these policies to exempt their access from MFA requirements: adding their IP to a trusted named location, weakening the conditions under which MFA is enforced, or disabling a policy that previously required MFA for all external access.

The policy change itself is logged as an audit event in M365, and the subsequent authentication attempts that would previously have triggered an MFA prompt now succeed without one. The combination of a Conditional Access policy change followed by a successful authentication from a previously blocked or MFA-required context is a high-confidence indicator of this attack. Notably, attackers often make these changes outside business hours to reduce the probability of a real-time alert being acted upon.

Log signals: M365 audit log operation "Update Conditional Access Policy", "Add Conditional Access Policy", or "Delete Conditional Access Policy" performed by an account without a recent change management record, especially outside business hours.

Authentication method modification and account manipulation - T1098, T1556.006

Rather than bypassing MFA in the moment of authentication, this approach modifies the victim's registered MFA methods to substitute the attacker's device for the victim's. The attacker adds their own phone number or authenticator app as the victim's MFA method, then removes the victim's. From that point, any authentication by the victim that triggers a push notification goes to the attacker's device instead.

This is a durable, persistent bypass: once the authentication method is substituted, the attacker can authenticate as the victim at any time without the victim being notified, for as long as the substitution persists. The modification event is logged in the Azure AD audit log as "User registered security info" or "Admin updated authentication methods", and detecting this change promptly is the only way to prevent extended unauthorized access.

Log signals: Azure AD audit events for authentication method registration changes, especially when performed by an admin on behalf of a user, or when a user's MFA registration changes shortly after a risky sign-in event for that account.

Real-world campaigns

Scattered Spider (UNC3944): MFA fatigue combined with social engineering

Scattered Spider is the threat group most associated with operationalizing MFA fatigue at scale. Their technique combines automated push flooding with real-time helpdesk impersonation: the attacker floods the target's phone with MFA push requests while simultaneously calling the IT helpdesk, posing as the targeted employee, and requesting that MFA be disabled or a TAP be issued due to a "lost phone." Organizations in the telecommunications, hospitality, and retail sectors have been targeted using this approach. The campaign that compromised MGM Resorts in 2023 used this exact technique, resulting in an estimated $100M in losses.

The detection path for this attack in Log360 runs through Multiple Denied MFA Requests (the push flood) followed shortly by Temporary Access Pass Added To An Account (the social engineering success) or MFA Disabled for an Account (the helpdesk capitulation). The two rules firing in sequence for the same user within a short time window is a near-certain indicator of a successful fatigue and social engineering attack.

Midnight Blizzard (APT29): Conditional Access policy modification for persistent access

APT29, the Russian SVR-affiliated group, has been documented modifying Conditional Access policies in compromised M365 tenants to establish persistent, MFA-bypassing access. After gaining initial access (typically through token theft or a compromised service account), the group identifies CA policies that would require MFA for their subsequent access patterns and either disables those policies or adds their access path to a trusted named location exemption. The modification is designed to look like routine policy administration and often occurs during working hours to blend with legitimate admin activity, making the Malicious M365 CA Policy Changes After Business Hours anomaly rule an important complement to the standard CA policy change rule.

Attack technique reference table

Business impact

• MFA bypass invalidates the primary identity control. MFA is the most effective single security control for preventing unauthorized account access. When MFA is bypassed, the attacker has full authenticated access to all resources the account can reach: email, SharePoint, OneDrive, Teams, connected applications, and any data those services contain. The downstream damage is bounded only by the account's permissions and the attacker's objectives.
• TAP and CA tampering create silent, persistent access. Unlike MFA fatigue, which leaves a trail of denied push requests, a successfully abused TAP or a modified CA policy gives the attacker access that looks identical to legitimate authentication. There are no failed MFA events, no anomalous authentication patterns, and no alerts from standard MFA monitoring. The only detection signal is the TAP creation or CA modification event itself, which may have occurred hours or days before the access begins.
• Identity is the new perimeter in M365 environments. Organizations that have moved workloads to M365 and Azure have by definition made identity their primary security boundary. A bypass of that boundary gives an attacker access to the organization's primary communication and collaboration platform, often including finance, HR, legal, and executive communications that represent the most sensitive data the organization holds.
• Regulatory and notification obligations. Unauthorized access to M365 or Azure AD constitutes access to a covered system under HIPAA, PCI-DSS, and GDPR depending on what data is accessible. A TAP-based access that reaches patient records, cardholder data, or EU personal data triggers breach assessment and potentially notification obligations, regardless of whether data was confirmed to have been exfiltrated.

Detecting MFA bypass and fatigue with Log360

Log360's 23 detection rules for this use case cover all four bypass paths. The prerequisite for all of these rules is that Microsoft 365 unified audit logs and Azure AD sign-in and audit logs are configured to forward to Log360. M365 audit logging must be enabled in the Microsoft Purview compliance portal, and the log forwarding connector must be configured in Log360. Rules are grouped below by the bypass path they target.

MFA fatigue detection

Temporary Access Pass abuse

Conditional Access policy tampering

Authentication method modification and account manipulation

Privilege escalation and persistence in M365

Attack chain visibility

The most dangerous MFA bypass attacks follow a consistent pattern: an initial bypass technique is used to gain access, followed by persistence actions that ensure continued access even after the bypass mechanism is discovered and remediated. The sequences below show the two highest-risk chains.

Sequence A: MFA fatigue leading to TAP creation and persistence

Sequence B: CA policy tampering for persistent MFA bypass

Investigation playbook

MFA bypass investigations require speed. Unlike brute force attacks where the failure pattern itself is the alert, many MFA bypass techniques fire their detection rule at the moment of bypass, not before. When a rule fires, access may already be in progress. The goal of the investigation is to determine the scope of access that occurred, whether persistence was established, and what data was reached.

Step 1: Triage - identify the bypass method and current status

Step 2: Determine scope of access

• Using Log360's log search, query the M365 unified audit log for all activity by the affected account from the time of the bypass event forward. Filter for high-impact operations: file downloads, email reads, SharePoint access, Teams message history, and admin operations.
• For TAP-based access, identify the exact time window the TAP was valid and query all M365 activity from the target account during that window. TAP-based authentications are identifiable in the sign-in log by authentication method.
• For CA policy tampering, identify the exact change made and determine which users and which access patterns were affected by the weakened policy. Every sign-in from an affected user during the tampered policy period should be reviewed.
• Check whether any admin operations were performed: role assignments, policy changes, new application registrations, TAP creations for other accounts. Each of these extends the scope of the incident beyond the initially compromised account.

Step 3: Investigate using the Incident Workbench

• Click on the affected username in the alert or log search results to open the Incident Workbench. Use the User analytics tab to view the account's full activity overview: sign-in history, resources accessed, UEBA risk score, and behavioral baseline. A successful MFA bypass will show a sudden change in sign-in source IP, device, or location relative to the account's established pattern.
• Use Advanced Threat Analytics on the sign-in source IP to pull threat feed risk scores. IPs used for MFA fatigue campaigns frequently appear in threat intelligence feeds as known attack infrastructure. A high-risk IP completing an authentication that previously had denied MFA requests is a confirmed malicious access event.
• If PIM role changes, application credential additions, or CA policy modifications were detected, open additional Incident Workbench tabs for the admin account that performed those operations. This reveals whether the admin account itself was compromised or whether an attacker escalated from a lower-privilege account.
• Save the Incident Workbench session to an incident. The user activity timeline and risk scoring from this session become the evidence record for breach assessment and any regulatory notification obligations.

Step 4: Check for persistence

• Query the M365 audit log for the following persistence indicators in the time window following the initial bypass: new application registrations, credential additions to existing applications, new service principals, PIM role activations, Global Admin role assignments, and new federated domain additions.
• Check whether any CA policies were modified after the initial bypass. A common pattern is: compromise account via fatigue, modify CA policy to add attacker IP as trusted, then use that trusted IP for all future access without triggering further alerts.
• Check whether any new Authentication Methods were registered for the compromised account or for other accounts the compromised admin accessed. Authentication method registrations made during or after a bypass event are persistence mechanisms.
• Review whether any mail forwarding rules were created in the compromised account's mailbox. Mail forwarding rules (detected by the Mail Flow Rule for Forwarding Created rule) are a common post-compromise persistence action that allows ongoing email surveillance even after the account password is reset.

Step 5: Collect evidence and build the timeline

• Export the M365 unified audit log for the affected accounts covering the full period from the earliest detection rule firing to the time of investigation. This is your primary forensic record for breach assessment.
• Export Azure AD sign-in logs for the affected accounts. Sign-in logs show authentication method, IP, device, location, risk level, and MFA result for every authentication event and are the key artifact for demonstrating whether the bypass was successful.
• If a CA policy was modified, export the policy change audit record including the before and after state of the policy. This documents exactly what was changed and when.
• Export the Incident Workbench session timeline and risk assessment as the compliance artifact for HIPAA Section 164.308(a)(6) (security incident procedures) and NIST CSF DE.AE-5 (incident analysis).

Response and remediation

Immediate containment

• Revoke all active sessions for the compromised account. Use the Revoke-MgUserSignInSession PowerShell cmdlet or the M365 admin portal to invalidate all existing session tokens. This terminates any active attacker sessions immediately. Password reset alone does not revoke existing tokens.
• Revoke any TAPs created during the bypass window. TAPs are listed in the user's authentication methods in Entra ID admin center. Remove all TAPs from affected accounts. If the scope of compromised accounts is unclear, audit all TAP creations in the last 30 days and revoke any that cannot be correlated with a documented onboarding or recovery workflow.
• Restore any modified Conditional Access policies. Review the specific changes made and revert them. Enable report-only mode temporarily if the full impact of reverting a change is unclear, but prioritize restoring MFA requirements over policy stability.
• Remove unauthorized authentication method registrations. Any phone number or authenticator app added to a user's MFA methods during or after a bypass event should be removed. Require the user to re-register their own MFA device after identity verification.
• Disable compromised admin accounts and require re-authentication and MFA re-enrollment via a separate, out-of-band channel before restoring access.

Response actions by trigger

Hardening

• Enable number matching for Microsoft Authenticator push notifications. Number matching requires the user to type a two-digit number displayed on the sign-in screen into the Authenticator app. This eliminates accidental approvals and significantly increases the effort required for a successful fatigue attack, since the user must actively engage with the sign-in screen to approve.
• Enable additional context in MFA push notifications, including the application name and geographic location of the sign-in. Users who see "Sign in to SharePoint from Kyiv, Ukraine" in the push notification are far less likely to approve a request they did not initiate.
• Restrict TAP creation to a small number of named administrators and require an approval workflow before a TAP can be created. Configure TAPs with the minimum necessary validity window (one hour rather than eight) and single-use only.
• Require Privileged Identity Management approval and MFA activation for all admin roles, including Conditional Access Administrator and Authentication Policy Administrator. No admin role should allow standing access without MFA-gated activation.
• Enable Azure AD Identity Protection and configure Conditional Access policies to block or require MFA step-up for high-risk sign-ins. High-risk sign-ins that complete without MFA are a gap that the High Risk Sign-In Detected rule surfaces but CA policies can prevent automatically.

False positive tuning