T1621
Multi-Factor Authentication Request Generation
Windows · Linux · macOS · IaaS · SaaS · Office Suite · Identity Provider5 pieces on this siteT1621 on attack.mitre.org
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.
If this is happening now
Checklists and playbooks to open while the alert is still live.
Cloud account takeover response plan: sessions, methods, devices and grants, then what they read
A successful sign-in the user did not make, in Microsoft Entra ID and Microsoft 365. A password reset alone evicts almost nobody. The plan works through the order that does, how to tell a guessed password from a stolen session, and how to answer what they read.
First 15 minutes: a user is getting MFA prompts they did not start
Repeated MFA prompts mean somebody already has the password and is waiting for a tired tap. What to tell the user, what to check, and what to change so the next attempt fails.
Somebody talked the help desk into a reset
The service desk reset a password or an MFA method for a caller, and the real user says it was not them. Or a new MFA method appeared on an account straight after a help desk ticket.
Detect it
Hunts and rules you can run, each stating what it needs and what else it returns.
Hunt: repeated MFA prompts denied or unanswered for one account
Accounts with five or more failed MFA challenges in an hour, in Entra ID and Okta. The signature of somebody holding the password and waiting for a tired approval.
Read
Analyses, case studies, guides, references and interview questions.
Entra ID sign-in logs: the fields and error codes that settle an account question
Which fields in a sign-in record separate a traveller from a stolen session, what the common error codes mean, where non-interactive sign-ins hide, and how long any of it is kept.
how MITRE says to see it
Detection Strategy for Multi-Factor Authentication Request Generation (T1621)
- 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.
- 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.
- Detect repeated failed login events followed by MFA challenges triggered in rapid succession, especially if originating from service accounts or anomalous IP addresses.
- 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.
what reduces it
- M1017 User Training. 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.
- M1032 Multi-factor Authentication. 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.
- M1036 Account Use Policies. 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.