T1111 Multi-Factor Authentication Interception Detection — KQL & SPL Queries for Sentinel and Splunk

Microsoft Sentinel / Defender

kusto

// Detection: MFA Fatigue / Prompt Bombing — multiple failed MFA prompts followed by success
let MfaFatigueWindow = 30min;
let MfaPromptThreshold = 5;
let FailedMfaEvents = AADSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| where AuthenticationRequirement == "multiFactorAuthentication"
| where AuthenticationDetails has_any ("MFA", "PhoneAppNotification", "PhoneAppOTP", "OneWaySMS", "TwoWayVoiceMobile")
| project FailTime=TimeGenerated, UserPrincipalName, FailIP=IPAddress, FailLocation=Location;
let SuccessfulMfaEvents = AADSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| where AuthenticationRequirement == "multiFactorAuthentication"
| project SuccessTime=TimeGenerated, UserPrincipalName, SuccessIP=IPAddress, AppDisplayName, SuccessLocation=Location, UserAgent;
FailedMfaEvents
| join kind=inner SuccessfulMfaEvents on UserPrincipalName
| where SuccessTime between (FailTime .. (FailTime + MfaFatigueWindow))
| summarize
    FailCount = dcount(FailTime),
    FirstFailTime = min(FailTime),
    SuccessTime = max(SuccessTime),
    FailSourceIPs = make_set(FailIP),
    SuccessSourceIPs = make_set(SuccessIP),
    TargetApps = make_set(AppDisplayName),
    FailLocations = make_set(FailLocation)
    by UserPrincipalName
| where FailCount >= MfaPromptThreshold
| extend TimeDeltaMinutes = datetime_diff('minute', SuccessTime, FirstFailTime)
| extend AlertType = "MFA Fatigue Attack"
| extend IPMismatch = set_difference(SuccessSourceIPs, FailSourceIPs) != dynamic([])
| project AlertType, UserPrincipalName, FailCount, TimeDeltaMinutes, FirstFailTime, SuccessTime,
         FailSourceIPs, SuccessSourceIPs, IPMismatch, TargetApps, FailLocations
| sort by FailCount desc

high severity medium confidence

Data Sources

Authentication: Authentication Logon Session: Logon Session Creation Azure AD Sign-In Logs Microsoft Sentinel AADSignInLogs

Required Tables

AADSignInLogs

False Positives

Users with poor mobile connectivity who retry MFA push notifications multiple times due to notification delivery failures — particularly common in low-signal areas or when VPN is in use on the authenticator device
Users who habitually dismiss MFA notifications accidentally before accepting them, especially with Microsoft Authenticator number matching where dismissal is a single tap away from approval
Automated testing frameworks or CI/CD pipelines in non-production tenants that trigger interactive authentication flows repeatedly during integration tests
Users traveling across Conditional Access geographic zones triggering multiple re-authentication challenges in rapid succession during transit
Help desk password reset workflows where multiple MFA verification rounds occur during account recovery procedures

Splunk

spl

index=azure sourcetype="azure:aad:signin" OR index=o365 sourcetype="o365:management:activity"
| eval user=coalesce(userPrincipalName, UserId, lower(Actor{}.ID))
| eval src_ip=coalesce(ipAddress, ClientIP)
| eval result_type=coalesce(resultType, "0")
| eval mfa_method=coalesce(authenticationMethodsUsed, authenticationDetails{}.authenticationMethod)
| eval auth_req=coalesce(authenticationRequirement, "unknown")
| where auth_req="multiFactorAuthentication" OR mfa_method IN ("PhoneAppNotification", "PhoneAppOTP", "OneWaySMS", "TwoWayVoiceMobile", "HardwareToken")
| eval is_failure=if(result_type!="0", 1, 0)
| eval is_success=if(result_type="0", 1, 0)
| bin _time span=30m
| stats
    sum(is_failure) as failed_attempts,
    sum(is_success) as success_attempts,
    dc(src_ip) as unique_ips,
    values(src_ip) as source_ips,
    values(mfa_method) as mfa_methods,
    values(appDisplayName) as apps,
    earliest(_time) as first_attempt,
    latest(_time) as last_event
    by _time, user
| where failed_attempts >= 5 AND success_attempts >= 1
| eval mfa_fatigue_ratio=round(failed_attempts / (failed_attempts + success_attempts) * 100, 1)
| eval alert_type="MFA Fatigue Detected"
| eval time_window_min=round((last_event - first_attempt) / 60, 1)
| table _time, user, failed_attempts, success_attempts, mfa_fatigue_ratio, time_window_min, unique_ips, source_ips, mfa_methods, apps, alert_type
| sort - failed_attempts

high severity medium confidence

Data Sources

Authentication: Authentication Azure AD Sign-In Logs Office 365 Management Activity

Required Sourcetypes

azure:aad:signin o365:management:activity

False Positives

Users with poor mobile connectivity retrying MFA push notifications multiple times due to notification delivery failures
Users who frequently dismiss MFA notifications accidentally before accepting them, generating false failure events
Automated testing or CI/CD pipelines that authenticate repeatedly in short windows against non-production tenants
Users traveling across Conditional Access geographic zones triggering multiple re-authentication challenges in rapid succession
Help desk password reset procedures involving multiple MFA verification rounds during account recovery

Elastic Security (EQL)

eql

sequence by azure.signinlogs.properties.user_principal_name with maxspan=30m
  [any where event.dataset == "azure.signinlogs" and
   event.outcome == "failure" and
   azure.signinlogs.properties.authentication_requirement == "multiFactorAuthentication" and
   azure.signinlogs.properties.authentication_details.authentication_method in
     ("PhoneAppNotification", "PhoneAppOTP", "OneWaySMS", "TwoWayVoiceMobile", "HardwareToken")] with runs=5
  [any where event.dataset == "azure.signinlogs" and
   event.outcome == "success" and
   azure.signinlogs.properties.authentication_requirement == "multiFactorAuthentication"]

high severity high confidence

Data Sources

Azure Active Directory Sign-In Logs via Elastic Azure integration Okta System Log via Elastic Okta integration Microsoft 365 audit logs via Elastic M365 integration

Required Tables

logs-azure.signinlogs-* logs-okta.system-*

False Positives

Users in areas with poor cellular or internet connectivity who experience repeated push notification timeouts or SMS delivery failures before eventually succeeding on a stable connection
IT helpdesk staff or identity administrators deliberately testing MFA enrollment, reset, or failover flows against active accounts during onboarding or incident response procedures
Automated integration test suites or CI/CD pipelines that authenticate against MFA-enabled service accounts and include retry logic on transient failures

IBM QRadar (AQL)

sql

SELECT
  username,
  DATEFORMAT(TRUNC(starttime / 1800000) * 1800000, 'YYYY-MM-dd HH:mm:ss') AS time_bucket,
  SUM(CASE WHEN "Event Result" = 'Failure' THEN 1 ELSE 0 END) AS failed_mfa_attempts,
  SUM(CASE WHEN "Event Result" = 'Success' THEN 1 ELSE 0 END) AS success_mfa_attempts,
  UNIQUECOUNT(sourceip) AS unique_source_ips,
  MIN(starttime) AS first_attempt_epoch_ms,
  MAX(starttime) AS last_event_epoch_ms,
  ROUND((LONG(MAX(starttime)) - LONG(MIN(starttime))) / 60000.0, 1) AS window_duration_min
FROM events
WHERE
  starttime > (NOW() - 86400000)
  AND LOGSOURCETYPENAME(devicetype) IN (
    'Microsoft Azure Active Directory',
    'Microsoft Office 365',
    'Okta'
  )
  AND (
    LOWER(QIDNAME(qid)) LIKE '%multi-factor%'
    OR LOWER(QIDNAME(qid)) LIKE '%mfa%'
    OR LOWER(QIDNAME(qid)) LIKE '%two-factor%'
    OR LOWER(QIDNAME(qid)) LIKE '%two factor%'
    OR LOWER(QIDNAME(qid)) LIKE '%authenticator%'
  )
GROUP BY
  username,
  TRUNC(starttime / 1800000)
HAVING
  failed_mfa_attempts >= 5
  AND success_mfa_attempts >= 1
ORDER BY failed_mfa_attempts DESC

high severity medium confidence

Data Sources

Microsoft Azure Active Directory QRadar log source Microsoft Office 365 QRadar log source Okta QRadar log source via DSM

Required Tables

events

False Positives

Users who repeatedly misplace or unlock the wrong hardware OTP token, entering multiple invalid codes before locating the correct device
Corporate SSO systems with aggressive session timeouts that force repeated MFA re-challenges for a single user during normal business workflows
Shared or kiosk workstations where multiple employees attempt authentication against the same account in the same 30-minute aggregation window

Sumo Logic CSE

sql

(_sourceCategory=azure/aad/signin OR _sourceCategory=azure/signinlogs OR _sourceCategory=okta/events)
| json field=_raw "userPrincipalName" as user nodrop
| json field=_raw "resultType" as result_type nodrop
| json field=_raw "authenticationRequirement" as auth_req nodrop
| json field=_raw "ipAddress" as src_ip nodrop
| json field=_raw "appDisplayName" as app_name nodrop
| json field=_raw "authenticationDetails[0].authenticationMethod" as mfa_method nodrop
| where auth_req = "multiFactorAuthentication"
  OR mfa_method in ("PhoneAppNotification", "PhoneAppOTP", "OneWaySMS", "TwoWayVoiceMobile", "HardwareToken")
| eval is_failure = if(result_type != "0", 1, 0)
| eval is_success = if(result_type = "0", 1, 0)
| timeslice 30m
| stats
    sum(is_failure) as failed_mfa_count,
    sum(is_success) as success_mfa_count,
    dcount(src_ip) as unique_source_ips,
    values(src_ip) as source_ips,
    values(mfa_method) as mfa_methods,
    values(app_name) as targeted_apps,
    min(_messageTime) as first_attempt_epoch,
    max(_messageTime) as last_event_epoch
    by _timeslice, user
| where failed_mfa_count >= 5 and success_mfa_count >= 1
| eval fatigue_ratio_pct = round(failed_mfa_count * 100 / (failed_mfa_count + success_mfa_count), 1)
| eval window_duration_min = round((last_event_epoch - first_attempt_epoch) / 60000, 1)
| fields _timeslice, user, failed_mfa_count, success_mfa_count, fatigue_ratio_pct, window_duration_min, unique_source_ips, source_ips, mfa_methods, targeted_apps
| sort by failed_mfa_count desc

high severity high confidence

Data Sources

Azure AD Sign-In Logs via Sumo Logic Azure source Okta System Log via Sumo Logic Okta source Microsoft 365 Cloud-to-Cloud source

Required Tables

azure/aad/signin azure/signinlogs okta/events

False Positives

New employees completing MFA enrollment who accidentally trigger multiple push notifications before understanding the accept/deny flow in the authenticator app
Users traveling internationally whose push notifications arrive out of order or are delayed due to roaming connectivity, causing them to re-request and approve multiple prompts
Automated provisioning pipelines using MFA-enabled service accounts that implement aggressive retry logic on transient Azure AD throttling responses

Google Chronicle / SecOps

yaral

rule mfa_fatigue_prompt_bombing {
  meta:
    author = "Detection Engineering"
    description = "Detects MFA fatigue / prompt bombing attacks: 5+ failed MFA attempts for a user within 30 minutes followed by a successful MFA authentication. Covers LAPSUS$-style fatigue and AiTM relay scenarios (T1111)."
    severity = "HIGH"
    priority = "HIGH"
    mitre_attack_tactic = "Credential Access"
    mitre_attack_technique = "T1111"
    mitre_attack_technique_name = "Multi-Factor Authentication Interception"
    false_positives = "Connectivity issues causing repeated timeouts, helpdesk MFA testing, automated test suites"
    version = "1.0"

  events:
    $fail.metadata.event_type = "USER_LOGIN"
    $fail.security_result.action = "BLOCK"
    (
      $fail.extensions.auth.auth_details = /(?i)mfa|multi.?factor|otp|push|authenticator/ or
      $fail.extensions.auth.mechanism = "MECHANISM_OTP" or
      $fail.metadata.product_name = /(?i)Azure AD|Okta|Google Workspace|Microsoft Entra/
    )
    $fail.principal.user.userid = $user

    $success.metadata.event_type = "USER_LOGIN"
    $success.security_result.action = "ALLOW"
    (
      $success.extensions.auth.auth_details = /(?i)mfa|multi.?factor|otp|push|authenticator/ or
      $success.extensions.auth.mechanism = "MECHANISM_OTP"
    )
    $success.principal.user.userid = $user

  match:
    $user over 30m

  condition:
    #fail >= 5 and #success >= 1
}

high severity high confidence

Data Sources

Azure AD via Chronicle Microsoft 365 ingestion pipeline Okta via Chronicle Okta log ingestion Google Workspace via Chronicle Google Workspace ingestion

Required Tables

USER_LOGIN UDM event type

False Positives

VPN or split-tunneling configurations that delay push notification delivery, causing legitimate users to re-request prompts multiple times before one arrives and is approved
Security awareness training platforms that simulate MFA fatigue scenarios against real accounts in a designated test tenant or sandbox environment
Users with multiple devices enrolled for MFA where each device generates a separate BLOCK event when the notification is dismissed on non-primary devices before approval on the primary

CrowdStrike LogScale (CQL)

cql

#event_simpleName = /IdentityProtectionUserLogon|UserAuthAttempt|IdpLoginAttempt/
| MfaFailure := if(AuthenticationResult = "Failed" and (MfaType != null or MfaRequired = "true"), 1, 0)
| MfaSuccess := if(AuthenticationResult = "Success" and (MfaType != null or MfaRequired = "true"), 1, 0)
| bucket(span=30m)
| groupBy([UserPrincipalName, _bucket], function=[
    sum(MfaFailure, as=FailedMfaAttempts),
    sum(MfaSuccess, as=SuccessMfaAttempts),
    count(distinct=SourceIpAddress, as=UniqueSourceIPs),
    collect([SourceIpAddress, MfaType, ApplicationId])
  ])
| FailedMfaAttempts >= 5 and SuccessMfaAttempts >= 1
| FatigueRatioPct := round(FailedMfaAttempts * 100 / (FailedMfaAttempts + SuccessMfaAttempts), 1)
| sort(FailedMfaAttempts, order=desc)

high severity medium confidence

Data Sources

CrowdStrike Falcon Identity Threat Protection (ITP) CrowdStrike Falcon Zero Trust Assessment identity events

Required Tables

IdentityProtectionUserLogon UserAuthAttempt IdpLoginAttempt

False Positives

Falcon Identity Protection sensor misconfiguration or duplicate log forwarding causing the same authentication event to be recorded multiple times, artificially inflating the failed attempt count above threshold
Service accounts used by robotic process automation (RPA) platforms that are enrolled in MFA policies and implement aggressive retry logic when Azure AD returns transient 429 throttling responses
Users enrolled in a Falcon Zero Trust pilot program where additional step-up verification challenges are incorrectly classified as MFA failures during the initial sensor calibration period

Multi-Factor Authentication Interception

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Same Tactic: Credential Access

Popular Detections