T1111 Splunk · SPL

Detect Multi-Factor Authentication Interception in Splunk

Adversaries may target multi-factor authentication (MFA) mechanisms to intercept authentication factors including smart card PINs, hardware token codes (RSA SecurID), SMS-based one-time passwords, and app-based push notifications. Interception methods include keylogging to capture smart card PINs or TOTP codes, SMS hijacking via SIM swapping or compromised messaging service providers, MFA prompt bombing (fatigue attacks sending repeated push notifications until the user approves), and adversary-in-the-middle (AiTM) phishing frameworks that relay credentials and capture session tokens post-MFA. Nation-state groups including Kimsuky (proprietary OTP interception tool), APT42 (cloned websites capturing MFA tokens), and Chimera (registering adversary phone numbers on compromised accounts) have employed these techniques. Criminal group LAPSUS$ operationalized MFA fatigue at scale against major technology firms, achieving access by sending repeated Authenticator push notifications until users approved out of confusion or frustration.

MITRE ATT&CK

Tactic
Credential Access
Technique
T1111 Multi-Factor Authentication Interception
Canonical reference
https://attack.mitre.org/techniques/T1111/

SPL Detection Query

Splunk (SPL)
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

Detects MFA fatigue attacks using Azure AD sign-in logs ingested into Splunk via the Splunk Add-on for Microsoft Cloud Services or Azure Monitor Log Analytics forwarding. Buckets authentication events into 30-minute windows and identifies accounts with 5 or more failed MFA attempts followed by at least one successful authentication in the same window. Calculates a fatigue ratio for analyst prioritization. Covers push notification, OTP, SMS, voice call, and hardware token MFA methods. Compatible with both azure:aad:signin and o365:management:activity sourcetypes.

Data Sources

Authentication: AuthenticationAzure AD Sign-In LogsOffice 365 Management Activity

Required Sourcetypes

azure:aad:signino365:management:activity

False Positives & Tuning

  • 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
Download portable Sigma rule (.yml)

Other platforms for T1111


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1MFA Fatigue Simulation via Repeated MSAL Authentication Requests

    Expected signal: Azure AD Sign-In Logs (AADSignInLogs): 10 entries for the test account — each with ResultType indicating MFA prompt sent or denied, AuthenticationRequirement=multiFactorAuthentication, AuthenticationMethodsUsed=PhoneAppNotification. Events appear within a 3-5 minute window, all from the same source IP (the test machine). If any prompt is approved, a success event (ResultType=0) also appears.

  2. Test 2Smart Card API Enumeration via Custom Process

    Expected signal: Sysmon Event ID 1 (Process Create): scard_probe.exe spawned from powershell.exe with the compilation command in ParentCommandLine. Sysmon Event ID 7 (Image Load): scard_probe.exe loading C:\Windows\System32\winscard.dll — InitiatingProcessFileName=scard_probe.exe is not in the allowlist of expected winscard.dll callers. Sysmon Event ID 11 (File Create): scard_probe.exe written to %TEMP%.

  3. Test 3OTP Keylogger via Low-Level Keyboard Hook Installation

    Expected signal: Sysmon Event ID 1 (Process Create): PowerShell with command line containing SetWindowsHookEx, WH_KEYBOARD_LL references — triggers on process create. Windows Security Event ID 4688 (if command-line audit enabled). PowerShell ScriptBlock Log Event ID 4104 captures the full hook installation code. Behavior-based EDR (CrowdStrike, Defender, SentinelOne) should generate a keyboard hook behavioral alert for the WH_KEYBOARD_LL hook type.

  4. Test 4Adversary MFA Phone Number Registration via Microsoft Graph API

    Expected signal: Azure AD Audit Logs (AuditLogs table in Sentinel / azure:aad:audit in Splunk): OperationName='List user authentication methods' — the enumeration creates an audit event. If the write command is executed (in authorized lab only): OperationName='User registered security info' or 'Add user StrongAuthenticationMethod' with the new phone number value in TargetResources[0].modifiedProperties. Both events include the actor's IP address and UPN.

Unlock Pro Content

Get the full detection package for T1111 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections