Scattered SpiderG1015 ↗
Has used multifactor authentication (MFA) fatigue by sending repeated MFA authentication requests to targets.12
tfMITRE ATT&CK technique
Multi-Factor Authentication Request Generation T1621
- Tactic
- Credential Access
- Platforms
- Windows, Linux, macOS, IaaS, SaaS, Office Suite, Identity Provider
- Version
- 1.2
- Created
- 01 April 2022
- Last modified
- 24 October 2025
- Contributors
- 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.
ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact
3
Threat groups64th pct
Threat groups64th percentile · 64% of ATT&CK techniques have this many threat groups attributed or fewer.1
Campaigns72nd pct
Campaigns72nd percentile · 72% of ATT&CK techniques have this many campaigns recorded or fewer.0
Tools & malwareNone recorded
Tools & malwareNone recorded · 29% of ATT&CK techniques have none either.20
Detection rulesTop 14%
Detection rules86th percentile · 86% of ATT&CK techniques have this many detection rules written or fewer.Multi-Factor Authentication Request Generation MITRE reference T1621
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.
LAPSUS$G1004 ↗
Has spammed target users with MFA prompts in the hope that the legitimate user will grant necessary approval.1
APT29G0016 ↗
Has used repeated MFA requests to gain access to victim accounts.12
All 3 groups for this technique
1 campaign has been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
C0027C0027 ↗
During C0027, Scattered Spider attempted to gain access by continuously sending MFA messages to the victim until they accept the MFA push challenge.1
All 1 campaigns for this technique
Offense vs defense T1621
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Range
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Campaigns · 1Sigma rules (cumulative) · 2Splunk ESCU (cumulative) · 18
first rule: 2021 Q4 · 1 of 1 campaigns plottedMulti-Factor Authentication Request Generation detection strategy DET0160
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)
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.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | azure:signinlogs | Multiple MFA challenge requests without successful primary login |
| Application Log ContentDC0038 | NSM:Connections | PushNotificationSent |
Tunable fields
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.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | AWS:CloudTrail | 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.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | WinEventLog:Security | EventCode=4625 |
Tunable fields
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.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | auditd:AUTH | pam_unix or pam_google_authenticator invoked repeatedly within short interval |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AuthRetryThreshold | Number of retries per user allowed before detection is triggered |
AN0453 · SaaS
Detect anomalous OAuth or SSO logins that repeatedly generate MFA challenges, particularly where MFA approvals are denied or timed out by the user.
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.
| Data component | Name | Channel |
|---|---|---|
| Application Log ContentDC0038 | saas:okta | MFAChallengeIssued |
Tunable fields
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.
| Data component | Name | Channel |
|---|---|---|
| Logon Session MetadataDC0088 | macos:unifiedlog | authd generating multiple MFA token 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 |
|---|---|
| DeviceEnrollmentStatus | Exclude unmanaged macOS devices that use different MFA providers |
Account Use PoliciesM1036
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.
User TrainingM1017
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.