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 in the hope that one gets approved, and Scattered Spider sending repeated MFA requests (including during its C0027 campaign). Microsoft's March 2022 write-up on LAPSUS$, then tracked as DEV-0537, describes the group using stolen passwords to trigger simple-approval prompts in the hope that the user eventually consents. Cisco Talos documented the voice variant against Cisco that year. An employee got repeated calls from people claiming to be from various trusted organizations, pushing them to accept MFA prompts the attacker had started, until one was accepted and the attacker reached the VPN as that user.

The best-known public case is Uber's September 2022 breach. Uber's own security update says the attacker probably bought a contractor's corporate password on the dark web after malware infected the contractor's personal device, then tried to log in again and again; each attempt sent an approval request that blocked access until the contractor eventually accepted one. From there, Uber says, the attacker reached other employee accounts and elevated permissions in tools including G-Suite and Slack, and Uber said it believed the attacker was affiliated with Lapsus$. The more detailed version comes from the attacker. InfoQ, citing BleepingComputer's reporting on researcher Corben Leo's conversation with the hacker, relays that the contractor was contacted on WhatsApp by someone claiming to be Uber IT, and that a PowerShell script with admin credentials for Uber's secrets-management platform then opened DUO, AWS, Gsuite and the HackerOne bug bounty program. Even taking only what Uber confirmed, one approved push became access to several employee accounts and admin-level tooling.

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. In the Uber attacker's own account of the 2022 breach, a script with stored admin credentials is what turned one approved push into broad internal access.