Multi-Factor Authentication Request Generation

This technique sits at the credential-access-to-initial-access hinge: it only works after credentials are already stolen, and it ends the moment one push is approved, handing the attacker a live session instead of a password to crack. MITRE's own procedure examples for T1621 list APT29 using repeated MFA requests to gain victim account access, LAPSUS$ spamming target users with prompts until one was approved, Scattered Spider continuously sending MFA messages until acceptance, and Campaign C0027 generating continuous MFA messages against its targets, so this is not a theoretical technique, it is standard tradecraft across several tracked intrusion sets.

The best-documented public case is Uber's September 2022 breach. According to Uber's own account of the incident, an attacker who had bought a contractor's credentials sent a stream of MFA push notifications and then contacted the contractor on WhatsApp claiming to be Uber IT, saying the only way to stop the notifications was to accept one. Once inside, the attacker found PowerShell scripts with hardcoded admin credentials on an internal network share and used them to reach Uber's DUO, AWS, and Google Workspace administration along with its HackerOne program, turning one approved push into organization-wide access. The pattern generalizes: MFA fatigue rarely stays a one-account incident once the initial session lands somewhere with stored secrets or standing admin rights.

Not every denied-then-approved MFA sequence is an attack. Users on unreliable mobile data or Wi-Fi legitimately miss or fail to load a push and retry, and switching from a personal phone to a new enrolled device produces a burst of failed attempts before the working method succeeds. Help-desk-initiated password resets or MFA re-enrollments can also generate several prompts in a short window as part of a sanctioned account-recovery flow, and VPN clients that silently retry authentication on flaky connections can trigger repeated MFA challenges that look identical to a fatigue attempt in raw counts.

The signal that separates the two is provenance and volume, not the mere presence of a denial. A legitimate retry pattern comes from the user's own device and IP, stays low (two or three attempts), and resolves quickly. A fatigue attack shows denials originating from an IP or ASN the account has never used, arriving faster than a human plausibly triggers them, and often followed by a change in successful-login geography once the push is finally approved. Tune the rule to require both a denial-then-success sequence and a source-IP or geography mismatch between the denials and the eventual success, and exclude accounts currently flagged in a known help-desk reset ticket.

When this fires, first pull the IP addresses and device identifiers on every denied attempt and compare them to the account's normal sign-in baseline. If the denials come from the user's own device and a familiar network, this is very likely a connectivity retry, not an attack, close it with a note. If the denials come from an unfamiliar source and the eventual approval comes from the user's usual device, ask the user directly whether they received an unusual volume of prompts and whether anyone contacted them (call, text, WhatsApp) claiming to be IT during that window: that answer confirms or rules out the social-engineering variant.

If the sequence is confirmed hostile, treat it as an active account compromise, not a policy violation. Revoke the account's active sessions and refresh tokens immediately so the approved push cannot be reused, force a password reset, and re-enroll the user's MFA method from a clean device rather than trusting the existing enrollment. Pull the account's activity since the approval timestamp for signs the attacker already reached mailbox rules, OAuth app consents, or SSO into downstream SaaS, and check whether any secrets the account could read (shared drives, internal wikis, credential stores) were touched, since that is exactly how the Uber intrusion escalated from one approved push to broad internal access.