Jon Sternstein, Stern Security; Pawel Partyka, Microsoft 365 Defender; Shanief Webb; Obsidian Security; Arun Seelagan, CISA
Adversaries may attempt to bypass multi-factor authentication (MFA) mechanisms and gain access to accounts by generating MFA requests sent to users.
Adversaries in possession of credentials to Valid Accounts may be unable to complete the login process if they lack access to the 2FA or MFA mechanisms required as an additional credential and security control. To circumvent this, adversaries may abuse the automatic generation of push notifications to MFA services such as Duo Push, Microsoft Authenticator, Okta, or similar services to have the user grant access to their account. If adversaries lack credentials to victim accounts, they may also abuse automatic push notification generation when this option is configured for self-service password reset (SSPR).[1]
In some cases, adversaries may continuously repeat login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls, potentially resulting in the user finally accepting the authentication request in response to “MFA fatigue.”[2][3][4]
64th pctamong all ATT&CK techniques for number of groups
3 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
MITRE names one behaviour worth catching for this technique and breaks it into 6 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Multi-Factor Authentication Request Generation (T1621)
Enterprise
6 platforms
AN0449 · Identity Provider
Monitor for excessive or anomalous MFA push notifications or token requests, especially when login attempts originate from unusual IPs or geolocations and do not correspond to legitimate user-initiated sessions.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
Field
What you tune
TimeWindow
Threshold of MFA prompts per user within a short time period
GeoIPAllowList
Expected login locations for workforce; deviations can be tuned
AN0450 · IaaS
Detect abnormal MFA activity within cloud service provider logs, such as repeated generation of MFA challenges for the same user session or mismatched MFA device and login origin.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
AssumeRole or ConsoleLogin with repeated MFA failures followed by repeated MFA requests
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
Field
What you tune
FailedLoginThreshold
Number of failed logins before raising detection
AN0451 · Windows
Detect repeated failed login events followed by MFA challenges triggered in rapid succession, especially if originating from service accounts or anomalous IP addresses.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
Field
What you tune
ServiceAccountExclusion
Exclude specific accounts where automated MFA requests are legitimate
AN0452 · Linux
Monitor PAM and syslog entries for unusual frequency of login attempts that trigger MFA prompts, particularly when MFA challenges do not match expected user behavior.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
Field
What you tune
MFAProvider
Identify which MFA service provider logs are in use (Okta, Duo, Microsoft Authenticator)
AN0454 · macOS
Detect user account logon attempts that trigger multiple MFA challenges through enterprise identity integrations, especially if MFA push requests are generated without successful interactive login.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
Enable account restrictions to prevent login attempts, and the subsequent 2FA/MFA service requests, from being initiated from suspicious locations or when the source of the login attempts do not match the location of the 2FA/MFA smart device. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.
Implement more secure 2FA/MFA mechanisms in replacement of simple push or one-click 2FA/MFA options. For example, having users enter a one-time code provided by the login screen into the 2FA/MFA application or utilizing other out-of-band 2FA/MFA mechanisms (such as rotating code-based hardware tokens providing rotating codes that need an accompanying user pin) may be more secure. Furthermore, change default configurations and implement limits upon the maximum number of 2FA/MFA request prompts that can be sent to users in period of time.
Train users to only accept 2FA/MFA requests from login attempts they initiated, to review source location of the login attempt prompting the 2FA/MFA requests, and to report suspicious/unsolicited prompts.
The following analytic identifies failed authentication attempts against an Azure AD tenant during the Multi-Factor Authentication (MFA) challenge, specifically flagged by error code 500121. (...)
The following analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. (...)
The following analytic detects failed authentication attempts during the Multi-Factor Authentication (MFA) challenge on a Google Cloud Platform (GCP) tenant. (...)
The following analytic detects multiple failed multi-factor authentication (MFA) requests for a single user within a Google Cloud Platform (GCP) tenant. (...)
Identifies user login with multifactor authentication failures, which might be an indication an attacker has the password for the account but can't pass the MFA challenge.
The following analytic identifies potential "MFA fatigue" attacks targeting Office 365 users by detecting more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. (...)
The following analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. (...)
The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. (...)
The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. (...)