MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation: Detecting and Stopping Push Bombing

When an intruder already has a valid password, a flood of MFA prompts can turn a tired or confused user into the final step of an account takeover. MITRE ATT&CK records this as T1621 Multi-Factor Authentication Request Generation in the Credential Access tactic (ATT&CK v20), covering push notifications, SMS and phone calls, and also self-service password reset flows that send push approvals. This page is the technique reference in our ATT&CK series: the scope ATT&CK gives T1621, the v20 detection analytics by platform, mapped mitigations with concrete identity provider settings, and a response runbook. It is for identity engineers, SOC analysts and incident responders, and it contains no attack procedures. The wider set of MFA bypass methods, including SIM swap and enrolment abuse, is covered in the MFA Fatigue and Bypass Guide; this page goes deeper on T1621 alone.

Key takeaways

• A prompt the user did not start means the password is already compromised. CISA advises investigating denied push requests for root cause, so treat an unsolicited prompt as a credential incident, not a nuisance.
• Approve-only push is no longer acceptable to NIST. SP 800-63B-4 section 3.1.3 requires the secret to be transferred between the primary and secondary channel, which is what number matching does.
• Number matching is interim, not the destination. CISA calls it one of the best interim mitigations; phishing-resistant authenticators remove the attack entirely.
• Rate-limit pushes. NIST says verifiers sending push notifications should limit the rate or total number of pushes since the last successful authentication.
• Wire user reports into risk. A "report suspicious activity" action that raises user risk and triggers revocation turns every alert user into a sensor.

What T1621 covers in ATT&CK v20

ATT&CK describes adversaries who hold credentials for valid accounts (T1078) but cannot complete sign-in without the second factor, and who therefore abuse automatic generation of MFA push notifications so that the user grants access. It also covers abuse of push generation in self-service password reset (SSPR) when the adversary lacks the password, and repeated login attempts that bombard the user with pushes, SMS messages and phone calls until the user accepts, known as MFA fatigue or push bombing.

Adjacent techniques

• T1110.003 Password Spraying and T1078 Valid Accounts: the usual source of the password that makes push bombing possible. See the MITRE ATT&CK T1110 Brute Force Guide.
• T1111 Multi-Factor Authentication Interception: capturing codes rather than generating prompts.
• T1556.006 Multi-Factor Authentication: tampering with MFA configuration once inside, for persistence.
• T1539 Steal Web Session Cookie: bypassing MFA entirely by stealing the post-MFA session. See the MITRE ATT&CK T1539 Steal Web Session Cookie.

APT29, LAPSUS$ and Scattered Spider are the groups ATT&CK v20 links to T1621. See the APT29 (Midnight Blizzard) Threat Actor Profile and the Lapsus$ Threat Actor Profile.

Detection

T1621 is noisy by design, which makes it one of the more detectable credential techniques, provided MFA telemetry reaches the SIEM and someone owns the alert. The ATT&CK v20 detection strategy has one analytic per platform.

High-value detection logic

• Burst then approve: several denied or timed-out pushes for one user followed by an approval, especially from a new IP or device. This is the core T1621 pattern and deserves high severity.
• Correct password, wrong place: successful primary authentication from an unfamiliar ASN, country or hosting provider immediately before a push, which shows the password is known to someone else.
• User-reported prompts: in Microsoft Entra, a "Report suspicious activity" submission sets the user to high user risk, records the sign-in with the result detail "MFA denied" and creates a "User Reported Suspicious Activity" risk detection. Okta logs end-user reports from security notification emails as the System Log event user.account.report_suspicious_activity_by_enduser.
• SSPR push without a sign-in: password reset push approvals the user did not request, which ATT&CK calls out explicitly.
• Post-approval actions: new MFA method registration (T1556.006), inbox rules or OAuth consent within minutes of an approval after a burst.

Metrics

• Percentage of push-enabled users with number matching enforced for every push.
• Percentage of privileged and remote access users on phishing-resistant authenticators.
• Median time from a push burst alert to session revocation and password reset.
• Number of user-reported suspicious prompts per month, and the share confirmed as compromised passwords.
• Number of MFA-protected applications still allowing approve-only push or voice call methods.

Prevention and hardening

Choosing between number matching and phishing-resistant MFA

• Choose number matching now where push is already deployed and you need protection within weeks. It defeats fatigue but not real-time phishing, where the attacker relays the number. Okta's own documentation states number matching is not as strong as phishing-resistant factors.
• Choose phishing-resistant authenticators for administrators, remote access, finance and help desk staff first, then expand. They defeat both T1621 and proxy phishing.
• Small organisations: enforce number matching everywhere, turn on suspicious activity reporting and issue security keys to administrators.
• Large organisations: add risk-based Conditional Access, automated remediation from user risk, and a phased passkey programme with reporting on remaining push users.

Phased rollout

1. Inventory methods: report which users and applications rely on approve-only push, SMS or voice, including RADIUS and legacy integrations. Okta notes number challenges are not supported with LDAPi or RADIUS integrations, so those paths need a separate plan.
2. Enforce number matching: pilot with IT staff, communicate the change, then enforce for all push users.
3. Enable reporting and automation: turn on suspicious activity reporting and connect high user risk to a policy that blocks or forces password reset.
4. Deploy detections: build the burst-then-approve and SSPR analytics in report mode, tune thresholds for two weeks, then alert.
5. Move to phishing-resistant MFA: start with privileged roles, then remote access, then everyone.
6. Roll back safely: keep a documented, monitored fallback method for users without compatible devices; never quietly re-enable approve-only push.

Response runbook

1. Confirm with the user: did they start the sign-in? If not, treat the password as compromised.
2. Contain: reset the password, revoke refresh tokens and sessions, and block sign-in if an approval already happened.
3. Check for persistence: review MFA methods registered, OAuth consents, inbox rules and API tokens created since the first suspicious prompt.
4. Find the password source: check for spraying against other accounts, infostealer exposure and password reuse.
5. Preserve evidence: export identity provider sign-in and audit logs and MFA provider logs for the incident window.
6. Harden the account: move the user to a phishing-resistant authenticator before restoring access where possible.

Where identity fits

T1621 targets people, but service accounts and shared accounts with MFA exemptions are where push bombing analytics often go blind. ATT&CK's Windows analytic names service accounts as an anomaly to watch, and also lets you exclude accounts where automated MFA requests are legitimate. Keep that exclusion list short and reviewed, and move non-human identities to workload credentials rather than user accounts with MFA exceptions. See the MITRE ATT&CK T1078 Valid Accounts Guide.

Framework mapping

Common failure patterns

• Closing the alert after the user denied it: the denial proves the password is known; reset it.
• Number matching on the app but not on legacy paths: RADIUS, VPN and older integrations can still send approve-only prompts.
• Voice and SMS fallback left on: attackers fall back to the weakest method the policy still allows.
• Reports going to an unwatched mailbox: user reports only help when they raise risk or open an incident automatically.
• Exempting help desk and admin accounts: the accounts most worth targeting are often the ones left on push for convenience.

Practitioner checklist

• Enforce number matching for every push, including SSPR and registration flows.
• Remove approve-only push, voice and SMS from privileged and remote access users.
• Issue phishing-resistant authenticators to administrators and help desk staff first.
• Turn on suspicious activity reporting and link high user risk to automated remediation.
• Alert on bursts of denied or timed-out pushes followed by an approval.
• Alert on SSPR push approvals with no matching user request.
• Review MFA exclusions and service account exceptions quarterly.
• Run the response runbook as a tabletop exercise twice a year.

Standards and references

• MITRE ATT&CK: Multi-Factor Authentication Request Generation (T1621)
• NIST: SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management
• CISA: Implementing Number Matching in MFA Applications
• Microsoft Learn: Number matching in Microsoft Authenticator push notifications
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings
• Okta: Configure Okta Verify options
• Okta: Suspicious activity reporting
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MFA Fatigue and Bypass Guide · MITRE ATT&CK T1539 Steal Web Session Cookie · Conditional Access Guide · Passkey Rollout Guide · ATT&CK Credential Access Tactic Guide