Agent Foskett Academy • SOC Analyst Academy • Module 3 • Lesson 22 • Identity Incidents

Lesson 22 — The User Received Twelve MFA Prompts

The first MFA prompt arrived at 08:11.

Then another. And another. By 08:16 the user had received twelve authentication prompts. Eleven were denied or ignored. One was approved.

The SOC could not treat that final approval as proof of legitimate access. The pattern looked like MFA fatigue — repeated prompts designed to pressure, confuse or wear down the user until one request is accepted.

One approved MFA prompt does not erase the eleven suspicious prompts that came before it.

Investigate the MFA Activity Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating repeated MFA prompts and MFA fatigue

Twelve prompts changed the story

The analyst needs the complete authentication sequence: who initiated it, where it came from, which prompts failed, which one succeeded and what happened after approval.

✓ Count and sequence the MFA attempts

✓ Identify source IP and application context

✓ Determine how MFA was satisfied

✓ Follow the session after approval

Case briefing

08:11 — MFA PROMPT 01 DENIED 08:11 — MFA PROMPT 02 NO RESPONSE 08:12 — MFA PROMPT 03 DENIED 08:12 — MFA PROMPTS 04–07 NO RESPONSE 08:14 — MFA PROMPTS 08–10 DENIED / NO RESPONSE 08:15 — MFA PROMPT 11 DENIED 08:16 — MFA PROMPT 12 APPROVED 08:17 — SUCCESSFUL SIGN-IN NEW SOURCE IP 08:24 — UNUSUAL CLOUD ACTIVITY THE EASY VERDICT "MFA succeeded." THE SOC QUESTION "Why did the user receive twelve prompts, and who controlled the session after approval?"

Investigation objective

Determine whether repeated MFA prompts represent legitimate user activity, a misconfigured application, accidental repetition or an MFA-fatigue attack that resulted in unauthorised access.

Investigator's rule

Never investigate an MFA approval in isolation. The frequency, timing, source, application, authentication method and follow-on activity can completely change the meaning of the final result.

Stage 1 — recognise the pattern

Signal	What it may mean	What the analyst should test
Many prompts in a few minutes	Possible MFA fatigue or broken application loop	Source, application, timing and user activity
Repeated denials	User may not recognise the requests	Whether the user initiated authentication
One approval after many denials	Possible accidental or pressured approval	Authentication method and session owner
New source IP	Possible attacker infrastructure	Historical source use and reputation/context
Unusual post-sign-in activity	Potential compromise	Mailbox, cloud, application and privilege actions

MFA fatigue is a sequence problem

The important signal is often not a single prompt. It is the repeated pattern: requests arriving faster than normal user behaviour would reasonably generate.

Do not assume every burst is malicious

Misconfigured clients, repeated sign-in attempts, stale applications and user confusion can also generate multiple prompts. The analyst still needs evidence before deciding the cause.

Stage 2 — reconstruct the authentication timeline with KQL

Start with the user and build a chronological view of recent sign-in activity. The goal is to see the prompts in the context of the authentication attempts that generated them.

12345 678910 1112131415 1617

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          AuthenticationRequirement,
          AuthenticationDetails,
          ConditionalAccessStatus
| order by TimeGenerated asc

Start with time

If twelve prompts arrived in five minutes, build that five-minute window first. Tight timing helps separate a deliberate prompt storm from unrelated sign-ins spread across the day.

AuthenticationDetails deserves attention

Where available, authentication details can help explain how MFA was satisfied and whether the final successful event used the expected authentication method.

Stage 3 — compare source and application context

PROMPT STORM ↓ WHAT GENERATED THE REQUESTS? ↓ SOURCE IP APPLICATION CLIENT LOCATION DEVICE CONTEXT ↓ SAME SOURCE EACH TIME? ↓ YES Possible sustained authentication attempt NO Multiple systems or changing infrastructure ↓ WAS THE SOURCE NORMAL FOR THE USER? ↓ NO Priority increases

The application matters

Repeated prompts tied to a familiar corporate application may have a different explanation from prompts generated by an unexpected application or client the user does not normally access.

Source consistency is useful evidence

If repeated authentication attempts originate from the same unfamiliar IP address, the pattern becomes easier to reconstruct. Changing sources may indicate broader infrastructure but still require context.

Stage 4 — quantify the burst

Summarise sign-in attempts by short time windows and source address to expose unusual bursts of authentication activity.

12345 678910 111213

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| summarize
    Attempts=count(),
    FirstAttempt=min(TimeGenerated),
    LastAttempt=max(TimeGenerated),
    Results=make_set(ResultDescription)
    by bin(TimeGenerated, 5m),
       IPAddress,
       AppDisplayName
| order by TimeGenerated asc

Burst analysis gives scale

Counting attempts in five-minute windows helps turn an analyst's impression of “a lot of prompts” into a measurable authentication pattern.

Thresholds are context, not verdicts

Twelve prompts is clearly unusual in this scenario, but no universal number proves an attack. Different environments and applications produce different normal patterns.

Stage 5 — investigate the approved request

ELEVEN REQUESTS DENIED / IGNORED ↓ TWELFTH REQUEST APPROVED ↓ DO NOT STOP ↓ HOW WAS MFA SATISFIED? ↓ WHAT SOURCE RECEIVED ACCESS? ↓ WHAT SESSION WAS CREATED? ↓ WHAT HAPPENED NEXT?

The approval is the pivot

The final approved request is where the investigation shifts from attempted access to possible successful compromise. Identify the corresponding successful sign-in and follow that session forward.

User confirmation helps — but does not replace logs

Ask whether the user initiated the sign-in and intentionally approved MFA. Their response is useful evidence, but technical validation is still required.

Stage 6 — follow post-authentication activity

APPROVED MFA ↓ SUCCESSFUL SIGN-IN ↓ FOLLOW THE SESSION NORMAL ACTIVITY? ↓ Supports legitimate explanation OR NEW INBOX RULE? UNUSUAL FILE ACCESS? NEW MFA METHOD? OAUTH CONSENT? PRIVILEGE CHANGE? UNUSUAL CLOUD ACTIVITY? ↓ Supports compromise hypothesis

Post-authentication evidence can settle the question

A prompt storm followed by a successful sign-in and then unusual cloud activity is far more significant than the prompt burst by itself.

Containment may need to go beyond a password reset

If compromise is confirmed or strongly suspected, the response may also need session revocation, authentication-method review, Conditional Access validation and investigation of changes made after access was granted.

Stage 7 — test competing explanations

Hypothesis	Evidence to test
MFA fatigue attack	Rapid repeated prompts, unfamiliar source, user denials, unexpected final approval and suspicious follow-on activity.
User repeatedly retrying sign-in	User confirmation, expected source, expected application and matching device context.
Misconfigured application	Known application, repeated historical pattern and no suspicious session activity.
Accidental approval	User statement, unfamiliar source and evidence showing the approved session was not expected.
Legitimate approval	Expected source, device, application, user confirmation and normal activity after authentication.

Stage 8 — make the SOC decision

MULTIPLE MFA PROMPTS ↓ COUNT + SEQUENCE REQUESTS ↓ IDENTIFY SOURCE + APPLICATION ↓ CHECK DENIAL / APPROVAL PATTERN ↓ MATCH APPROVAL TO SUCCESSFUL SIGN-IN ↓ FOLLOW POST-AUTHENTICATION ACTIVITY ↓ TEST LEGITIMATE EXPLANATIONS ↓ CORRELATE EVIDENCE ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

MFA fatigue is not proven by the number of prompts alone. The verdict comes from the complete authentication and session timeline.

Write the investigation finding

IDENTITY TRIAGE FINDING The user received twelve MFA prompts between 08:11 and 08:16. Eleven requests were denied or ignored. The twelfth request was approved. The approval corresponded with a successful sign-in from an unfamiliar source IP. The user did not normally authenticate from this source or client context. Unusual cloud activity followed the successful authentication. DECISION Escalate and contain the identity incident. Revoke active sessions, review authentication methods and investigate post-authentication changes. REASON The prompt burst, approval pattern, unfamiliar source and follow-on activity form a consistent MFA-fatigue compromise hypothesis.

Lesson 22 key takeaways

Repeated MFA prompts should be investigated as a sequence rather than isolated authentication events.
An approved request does not make the preceding prompt storm legitimate.
Use timing, source IP, application, client and authentication details to reconstruct what generated the requests.
KQL can help expose short bursts of repeated authentication activity.
Match the final MFA approval to the successful sign-in that followed it.
Follow the session after authentication to identify unusual cloud, mailbox, privilege or application activity.
User confirmation is useful evidence but should be validated against technical telemetry.
Misconfigured applications and repeated legitimate sign-ins remain plausible alternatives until ruled out.
Containment may require session revocation and authentication-method review, not only a password reset.
The final verdict should be based on the complete authentication timeline.

Module 3 — Identity Incidents

Lesson 22 follows the authentication story beyond a successful MFA result. Next, Agent Foskett investigates a new MFA method that appeared after the sign-in.

Next: Lesson 23 — A New MFA Method Appeared After the Sign-In

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 3: Identity Incidents

Investigate suspicious authentication, MFA behaviour and identity activity beyond the initial sign-in result.

← Previous lesson

Lesson 21 — The Successful Sign-In Wasn't Normal Investigate successful authentication when the surrounding context is suspicious.

✅ Current lesson

Lesson 22 — The User Received Twelve MFA Prompts Investigate MFA fatigue and repeated authentication attempts.

Next lesson

Lesson 23 — A New MFA Method Appeared After the Sign-In Correlate authentication-method changes with identity activity.

How to investigate MFA fatigue in Microsoft Entra

Lesson 22 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate repeated MFA prompts, identify authentication bursts, review source and application context, and determine whether an approved request resulted in unauthorised access.

KQL investigation of repeated MFA prompts and authentication attempts

Learn how to use Microsoft Entra SigninLogs and KQL to reconstruct authentication timelines, summarise repeated sign-in attempts, inspect MFA context and follow suspicious post-authentication activity.