Which SIEM platforms have a T1621 detection rule?

df00tech provides T1621 (Multi-Factor Authentication Request Generation) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What data sources are required to detect Multi-Factor Authentication Request Generation (T1621)?

Detecting Multi-Factor Authentication Request Generation requires the following data sources: Azure Active Directory / Microsoft Entra ID, Microsoft Sentinel.

What severity and confidence is the T1621 detection?

The T1621 detection is rated high severity with high confidence.

What are common false positives for T1621?

Common false positives for T1621 include: Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent; Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users; Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead.

T1621: Multi-Factor Authentication Request Generation — Detection (KQL, SPL, Sigma + 5 SIEMs)

Microsoft Sentinel / Defender

kusto

let MFAInterruptCodes = dynamic(["50074", "50076", "50158", "500121", "50072", "53003"]);
let LookbackWindow = 24h;
let BinSize = 1h;
let MFABombardThreshold = 5;
// Step 1: Aggregate MFA failures per user per hour
let MFAEvents = SigninLogs
| where TimeGenerated > ago(LookbackWindow)
| where ResultType in~ (MFAInterruptCodes)
    or (ResultDescription has_any ("MFA", "multi-factor", "strong authentication") and ResultType != "0")
| summarize
    MFAAttempts = count(),
    UniqueIPs = dcount(IPAddress),
    IPList = make_set(IPAddress, 10),
    FirstMFARequest = min(TimeGenerated),
    LastMFARequest = max(TimeGenerated),
    Apps = make_set(AppDisplayName, 5),
    ErrorCodes = make_set(ResultType, 10),
    Locations = make_set(tostring(LocationDetails), 5)
    by UserPrincipalName, bin(TimeGenerated, BinSize);
// Step 2: Find successful logins in the same lookback window
let SuccessEvents = SigninLogs
| where TimeGenerated > ago(LookbackWindow)
| where ResultType == "0"
| summarize
    SuccessCount = count(),
    EarliestSuccess = min(TimeGenerated),
    SuccessIPs = make_set(IPAddress, 5)
    by UserPrincipalName;
// Step 3: Join and flag fatigue success scenarios
MFAEvents
| where MFAAttempts >= MFABombardThreshold
| join kind=leftouter (SuccessEvents) on UserPrincipalName
| extend
    FatigueSucceeded = iff(isnotnull(EarliestSuccess) and EarliestSuccess > FirstMFARequest, true, false),
    DurationMinutes = datetime_diff('minute', LastMFARequest, FirstMFARequest),
    RiskLevel = case(
        isnotnull(EarliestSuccess) and EarliestSuccess > FirstMFARequest, "Critical",
        MFAAttempts >= 10, "High",
        "Medium")
| project
    TimeGenerated,
    UserPrincipalName,
    MFAAttempts,
    UniqueIPs,
    IPList,
    DurationMinutes,
    FirstMFARequest,
    LastMFARequest,
    Apps,
    ErrorCodes,
    Locations,
    FatigueSucceeded,
    EarliestSuccess,
    SuccessIPs,
    RiskLevel
| order by MFAAttempts desc

Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes (50074, 50076, 50158, 500121, 50072, 53003) per user per hour. Alerts when a single account exceeds 5 MFA challenges in one hour. Critically flags scenarios where a successful login follows the MFA bombardment window, indicating the fatigue tactic succeeded. RiskLevel field escalates to Critical when FatigueSucceeded is true.

high severity high confidence

Data Sources

Azure Active Directory / Microsoft Entra ID Microsoft Sentinel

Required Tables

SigninLogs

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

Splunk

spl

index=* sourcetype IN ("azure:aad:signin", "azure:monitor:aad:signinlogs")
| eval error_code=coalesce('properties.status.errorCode', errorCode, "")
| eval failure_reason=lower(coalesce('properties.status.failureReason', failureReason, ""))
| eval mfa_interrupt=if(
    match(error_code, "50074|50076|50158|500121|50072|53003")
    OR match(failure_reason, "mfa|multi-factor|strong auth"),
    1, 0)
| where mfa_interrupt=1
| eval user=coalesce('properties.userPrincipalName', userPrincipalName)
| eval src_ip=coalesce('properties.ipAddress', ipAddress)
| eval app=coalesce('properties.appDisplayName', appDisplayName)
| eval event_epoch=if(isnum(_time), _time, strptime(coalesce('properties.createdDateTime', ""), "%Y-%m-%dT%H:%M:%S"))
| bin _time span=1h
| stats
    count as mfa_attempts,
    dc(src_ip) as unique_ips,
    values(src_ip) as ip_list,
    min(event_epoch) as first_attempt_epoch,
    max(event_epoch) as last_attempt_epoch,
    values(app) as targeted_apps
    by user, _time
| where mfa_attempts >= 5
| eval duration_mins=round((last_attempt_epoch - first_attempt_epoch) / 60, 1)
| eval first_attempt=strftime(first_attempt_epoch, "%Y-%m-%d %H:%M:%S")
| eval last_attempt=strftime(last_attempt_epoch, "%Y-%m-%d %H:%M:%S")
| eval risk_level=case(mfa_attempts >= 15, "Critical", mfa_attempts >= 10, "High", true(), "Medium")
| table _time, user, mfa_attempts, unique_ips, ip_list, duration_mins, first_attempt, last_attempt, targeted_apps, risk_level
| sort -mfa_attempts

Detects MFA fatigue campaigns by aggregating Azure AD sign-in events with known MFA interrupt error codes via the Microsoft Azure Add-on for Splunk, bucketing per user per hour, and alerting when a single account receives 5+ MFA challenges within one hour. Risk level escalates to Critical at 15+ attempts. Works with data ingested via the Microsoft Azure Add-on (azure:aad:signin sourcetype).

high severity medium confidence

Data Sources

Microsoft Azure Add-on for Splunk Azure Active Directory

Required Sourcetypes

azure:aad:signin

False Positives

Users with persistent browser or app sessions that repeatedly request MFA on each sub-request due to aggressive Conditional Access policy configuration
Service accounts using delegated authentication with misconfigured MFA requirements that trigger repeated 50076 events during automated workflows
Users in regions with poor mobile coverage who receive and must retry MFA push notifications multiple times before approval registers
Shared accounts accessed by multiple staff members simultaneously, each triggering separate MFA prompts that aggregate above threshold

Elastic Security (EQL)

eql

any where event.dataset in ("azure.signinlogs", "okta.system") and (event.outcome : "failure" and event.reason : ("MFA*", "multi-factor*", "MFA required*", "interrupted*")) and count > 5

Elastic EQL translation of the T1621 detection logic. Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes (50074, 50076, 50158, 500121, 50072, 53003) per us

high severity high confidence

Data Sources

Azure Active Directory Okta Duo Security

Required Tables

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

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

IBM QRadar (AQL)

sql

SELECT username as "Username", sourceip as "SourceIP", devicetime as "EventTime", UTF8(payload) as "EventDetails", count(*) as "FailureCount", CASE WHEN count(*) > 20 THEN 95 WHEN count(*) > 10 THEN 80 WHEN count(*) > 5 THEN 65 ELSE 40 END as "RiskScore" FROM events WHERE LOGSOURCETYPENAME(devicetype) IN ('Microsoft Azure Active Directory', 'Okta', 'Duo Security') AND (eventid IN (50074, 50076, 50158, 65001) OR UTF8(payload) ILIKE '%MFA%' AND UTF8(payload) ILIKE '%fail%') GROUP BY username, sourceip HAVING count(*) > 5 ORDER BY "RiskScore" DESC LAST 1 HOURS

IBM QRadar AQL translation of the T1621 detection. Uses SQL-like syntax with risk scoring. Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes

high severity high confidence

Data Sources

Microsoft Azure Active Directory Okta Duo Security

Required Tables

events

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

Sumo Logic CSE

sql

_sourceCategory=azure/ad/signin OR _sourceCategory=okta/system | json auto | where error_code in ("50074", "50076", "50158", "65001") or (event_type = "user.authentication.auth_via_mfa" and outcome_result = "FAILURE") | stats count as mfa_failures by user_principal_name, ip_address, time_range | where mfa_failures > 5 | if(mfa_failures > 20, "Critical", if(mfa_failures > 10, "High", "Medium")) as RiskLevel | sort by mfa_failures desc

Sumo Logic query for T1621 detection using source category filters and aggregation. Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes

high severity high confidence

Data Sources

Azure AD Sign-in Logs Okta System Logs

Required Tables

azure/ad/signin okta/system

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

Google Chronicle / SecOps

yaral

rule detect_mfa_fatigue {
  meta:
    author = "Argus"
    description = "Detects MFA fatigue attacks via repeated failed MFA prompts"
    severity = "HIGH"
    technique = "T1621"
  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.metadata.product_name = "Microsoft Azure Active Directory"
    $e.security_result.action = "BLOCK"
    re.regex($e.security_result.description, `MFA|multi-factor|50074|50076|50158`) nocase
  match:
    $e.principal.user.userid over 1h
  condition:
    #e > 5
}

Google Chronicle YARA-L 2.0 rule for T1621 detection using UDM event types and field matching. Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes

high severity high confidence

Data Sources

Azure AD Sign-in Logs Okta Duo Security

Required Tables

USER_LOGIN SSO

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

CrowdStrike LogScale (CQL)

cql

#event_simpleName=UserLogonFailed2
| LogonType = "3"
| FailureReason = /MFA|multi-factor|Authenticator/i
| stats count() as MfaFailures by UserName, RemoteIP
| where MfaFailures > 5
| case {
    MfaFailures > 20 | RiskLevel := "Critical";
    MfaFailures > 10 | RiskLevel := "High";
    MfaFailures > 5 | RiskLevel := "Medium";
    * | RiskLevel := "Low"
  }
| table([@timestamp, UserName, RemoteIP, MfaFailures, RiskLevel])

CrowdStrike Falcon LogScale CQL query for T1621 detection. Detects MFA fatigue attacks by aggregating Azure AD sign-in failures with MFA interrupt error codes

high severity high confidence

Data Sources

UserLogonFailed2 (Falcon sensor) SsoApplicationActivity

Required Tables

UserLogonFailed2 SsoApplicationActivity

False Positives

Users with intermittent network connectivity who retry authentication multiple times legitimately, generating repeated MFA prompts without adversarial intent
Conditional Access policies configured to always require MFA on every request (rather than session-based) can generate high volumes of 50076 events for normal users
Automated service accounts or scripts using interactive auth flows that repeatedly fail MFA challenge — these should use device-based or certificate auth instead
IT administrators testing MFA policies, running phishing simulation exercises, or conducting MFA enrollment drives that generate burst MFA events for multiple accounts

Multi-Factor Authentication Request Generation

What is T1621 Multi-Factor Authentication Request Generation?

MITRE ATT&CK

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

Sigma rule & cross-platform mapping

Platform-specific guides for T1621

Testing Methodology

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Tactic Hub

Related Techniques

Same Tactic: Credential Access

Popular Detections

What is T1621 Multi-Factor Authentication Request Generation?

MITRE ATT&CK

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

Sigma rule & cross-platform mapping

Platform-specific guides for T1621

Testing Methodology

Unlock Pro Content

Related Detections

Tactic Hub

Related Techniques

Same Tactic: Credential Access

Popular Detections

Get new detections in your inbox