ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Entra ID • MFA Fatigue

The MFA Prompt Looked Normal

The user had MFA enabled.

The password alone was not enough.

Microsoft Defender showed no obvious malware. No suspicious attachment was opened. No endpoint alert immediately explained what happened.

The MFA prompt looked normal.

The Microsoft Authenticator notification appeared on the user's phone just like it always did.

But the prompt was not caused by the user signing in.

It was caused by the attacker.

This Agent Foskett briefing looks at MFA fatigue attacks, sometimes called push bombing, where attackers repeatedly trigger MFA prompts until a tired, busy or confused user eventually taps approve.

The user did not think they were letting an attacker in.

They thought they were clearing a normal Microsoft prompt.

Discuss Entra ID security Back to Investigation Hub
Agent Foskett investigates MFA fatigue attacks in Microsoft Entra ID
Briefing summary

MFA fatigue attacks abuse legitimate authentication prompts. The MFA notification may be real, the approval may be valid, and the resulting session may look successful — but the user may have approved an attacker they never meant to authorise.

Review repeated MFA prompts
Investigate sign-ins after denials
Correlate session and mailbox activity
🚨 The MFA prompt was real. The attacker was real too.
MFA fatigue attacks do not always bypass MFA technically. They abuse the user's trust in normal Microsoft authentication prompts.
Book a security review →

The attack nobody questions

MFA fatigue does not always feel like a cyber attack to the user. It can feel like a phone notification, a delayed Microsoft prompt, a glitch or another routine sign-in request. That is why the behaviour matters. Repeated prompts, failed attempts, unusual locations and a final successful approval can tell a very different story.
The prompt looked normalThe Microsoft Authenticator prompt may look exactly like every other legitimate MFA request the user has seen before.
The attacker created pressureRepeated prompts can wear users down, especially when they are tired, distracted, travelling or trying to get work done.
The session became validOnce the user approves the prompt, the attacker may receive a legitimate authenticated session that does not look like a classic password-only compromise.

Why MFA did not stop it

MFA did its job by asking for a second factor. The problem is that the second factor was approved under pressure. In this scenario, the attacker does not need to defeat the technology. They need to convince, confuse or exhaust the person holding the phone.
MFA was triggered correctlyThe platform challenged the sign-in because the password alone was not enough.
The user approved the requestThe approval may appear as a successful MFA event even though the user was not the person trying to sign in.
The login may look successfulAfter approval, the attacker can operate inside a valid session unless the activity is investigated and contained.

First hunt: repeated MFA failures and denials

Start by looking for repeated failed sign-ins, MFA denials, interrupted authentication and unusual prompt activity. A burst of failed attempts followed by one success should never be ignored.
mfa-fatigue-signin-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationRequirement has "multiFactorAuthentication"
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ResultType,
          ResultDescription,
          Location
| order by TimeGenerated desc
What to reviewLook for repeated failures, unfamiliar IP addresses, unusual locations, late-night prompts and activity outside the user's normal pattern.
Why it mattersMultiple failed or denied prompts followed by success can indicate the user was pressured into approving a malicious login.
Best next pivotPivot into the successful session, mailbox activity, CloudAppEvents, device activity and any changes made after sign-in.

Common signs of MFA fatigue

Not every failed MFA event is malicious. Users make mistakes. Devices disconnect. Prompts expire. But repeated prompts from unfamiliar locations, especially followed by a successful approval, should be investigated as a potential active attack.
Repeated prompt attemptsThe same user receives multiple MFA challenges in a short period, often from the same unfamiliar IP or region.
Denials followed by approvalSeveral denied, failed or interrupted attempts are followed by one successful MFA event and a new session.
Unusual timingPrompt storms often happen outside normal work hours, when users are more likely to approve without thinking.

Second hunt: success after repeated failures

A useful pattern is a user with multiple failed sign-ins or MFA-related failures from an IP address, followed by at least one successful sign-in. This does not prove compromise, but it gives investigators a shortlist worth reviewing.
mfa-success-after-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
SigninLogs
| where TimeGenerated > ago(14d)
| summarize FailedAttempts=countif(ResultType != 0),
            SuccessfulAttempts=countif(ResultType == 0),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated) by UserPrincipalName, IPAddress
| where FailedAttempts > 5 and SuccessfulAttempts > 0
| order by FailedAttempts desc

Third hunt: what happened after the approval?

The most important question is not only whether the user approved the prompt. It is what happened next. After the successful MFA event, review mailbox access, file downloads, inbox rules, SharePoint access, device activity and any unusual cloud application behaviour.
activity-after-mfa-approval.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
CloudAppEvents
| where Timestamp > ago(14d)
| where Application has_any ("Exchange", "Office 365", "Microsoft 365", "SharePoint")
| where ActionType has_any ("MailItemsAccessed", "FileDownloaded", "New-InboxRule", "Set-InboxRule")
| project Timestamp, AccountDisplayName, ActionType, Application, IPAddress, RawEventData
| order by Timestamp desc

Where defenders get caught

MFA fatigue attacks are missed because the final authentication event may look successful. The platform sees a valid user, a valid MFA approval and a valid session. The investigation must look at the pattern before the approval and the behaviour after it.
They trust the approvalA successful MFA approval does not automatically mean the user intended to approve that sign-in.
They ignore prompt historyThe failed, denied and interrupted attempts before success may be the real evidence of the attack.
They stop at authenticationThe real damage often happens after the session is approved: mailbox access, file downloads, inbox rules and persistence.

How GEMXIT approaches this type of investigation

At GEMXIT, we do not treat successful MFA as the end of the story. We review the authentication journey: what happened before the approval, where the prompt came from, what device or location was involved and what activity followed the successful session.
We review the full prompt storyHow many prompts occurred, where did they originate, what failed first and what eventually succeeded?
We correlate identity and cloud activitySign-ins, MFA events, mailbox access, SharePoint downloads, IP addresses and session activity are stronger together.
We strengthen MFA controlsResponse may include number matching, app context, location context, Conditional Access tuning, session revocation and user education.
The MFA prompt looked normal. The approval still needed investigating.
GEMXIT helps organisations investigate Microsoft Entra ID sign-ins, MFA fatigue, suspicious sessions, Defender XDR telemetry and practical KQL hunting workflows.
Contact GEMXIT

Final thought

The user thought they were clearing a normal Microsoft prompt.

In reality, they were approving the attacker's login.

Modern identity attacks are no longer only about breaking passwords or bypassing controls. Sometimes the attacker simply waits for a tired user to approve something that looks routine.

The real question becomes:

“Did the user approve their own sign-in — or someone else's?”
At GEMXITWe help organisations investigate Microsoft Entra ID, MFA fatigue, suspicious sign-ins, Defender XDR, Sentinel visibility and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Did MFA pass?”

It is: “Why was MFA approved?”

Continue the investigation with The User Passed MFA But It Wasn't Really Them, The Session Token Never Expired, The Login Came Through A Trusted Device, The User Clicked Accept And Gave Away The Entire Mailbox, Microsoft Defender KQL Threat Hunting Guide, Agent Foskett Academy, Microsoft Security and the GEMXIT Security Review.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The MFA Prompt Looked Normal

This Agent Foskett briefing explains how MFA fatigue and push bombing attacks can result in a valid Microsoft Entra ID sign-in when a user approves a prompt they did not initiate.

Microsoft Entra ID MFA Fatigue Investigation

GEMXIT helps organisations investigate repeated MFA prompts, suspicious sign-ins, failed authentication attempts, successful approvals after denials, session persistence and Microsoft Defender XDR hunting workflows.

MFA Push Bombing and Suspicious Authentication Prompts

MFA may successfully challenge a sign-in, but a tired or confused user may still approve an attacker-initiated request. Defender investigations should review prompt history, IP addresses, locations, successful sessions and post-authentication activity.