Lapsus$ proved push bombing in 2022

Unsolicited Microsoft Authenticator prompts arriving on a device the user did not initiate are the visible artefact of a credential compromise already in progress. The attacker holds valid primary credentials. The push notification is the second factor request triggered by the attacker’s authentication attempt against Azure AD - now Entra ID - using those credentials. The prompt on the legitimate user’s phone is not noise. It is the live signal that the password is burned and the account is one tap away from full compromise.

The technique is MFA fatigue, also called push bombing or prompt bombing. MITRE ATT&CK T1621, Multi-Factor Authentication Request Generation. It is not a vulnerability in the Authenticator app or in the Entra ID protocol. It is an abuse of the legitimate push approval flow. The control surface assumes the user evaluates each prompt and approves only their own sign-ins. Repeated prompting degrades that evaluation. Lapsus$ used this against Microsoft, Okta-adjacent targets, and Uber in 2022. Scattered Spider, tracked as UNC3944, has used it consistently against helpdesk and identity infrastructure since. The technique is not novel. It works because the precondition - a stolen password - is cheap.

The precondition is the password. The supply is functionally unlimited. Credential dumps from infostealer logs - RedLine, Raccoon, Lumma, StealC - are sold on Russian Market and the Telegram-based broker channels in volumes measured in hundreds of millions of records per month. Each log contains browser-stored credentials including login.microsoftonline.com entries with cleartext passwords pulled from Chromium’s Login Data SQLite store decrypted using the DPAPI master key already present on the infected host. The attacker does not phish the password. The attacker buys a log for two to ten dollars and filters it for the target domain. T1555.003, credentials from web browsers. The user typed the password into a browser six months ago on a personal device they forgot was malware-resident.

The attacker then drives the authentication. A script - frequently a modified Evilginx or a custom curl loop against login.microsoftonline.com - submits the credentials against the user’s UPN. Conditional Access evaluates the request. If MFA is required and the user is enrolled with Authenticator push, Entra ID dispatches a notification via Apple Push Notification Service or Firebase Cloud Messaging to the registered device. The attacker repeats the authentication attempt. Each attempt fires a new push. The script can run at a cadence of one prompt every ten to thirty seconds for hours, or it can be paced low and slow across days to evade fatigue thresholds.

The approval path on the device is the failure point. Default Authenticator behaviour pre-2022 surfaced a binary Approve or Deny dialog with no context. A user with twenty prompts queued at 2am taps Approve to make the noise stop. That single tap completes the AzureAD-Microsoft-Authenticator authentication method and issues a primary refresh token. The attacker now holds a session - usually a PRT-equivalent cookie set or an OAuth token - bound to the user’s identity. From here, persistence and lateral movement begin. T1078.004, valid accounts, cloud accounts.

Microsoft introduced number matching in Entra ID and made it the default in May 2023. The sign-in attempt displays a two-digit number on the requesting screen. The user must type that number into Authenticator to approve. This breaks the lazy-tap path. The user cannot approve a prompt they did not initiate because they do not know the number. If number matching is enforced, push bombing degrades to push annoyance and stops being a compromise vector. Tenants that have not enforced number matching, or that allow legacy approval as a fallback, retain the original exposure. Check the Authentication Methods policy in Entra ID for the Microsoft Authenticator method and confirm Require number matching for push notifications is set to Enabled for All users.

Number matching is not the full mitigation. The attacker still holds the password. Three secondary paths remain. Helpdesk social engineering - UNC3944’s preferred follow-on - calls the service desk impersonating the user, claims a new phone, and requests an MFA reset. The helpdesk re-enrols the attacker’s device. T1556.006, modify authentication process, multi-factor authentication. Mitigation is identity verification at the helpdesk that does not rely on knowledge factors the attacker already has from the infostealer log. Video verification, manager callback to a known number, or a pre-shared challenge phrase.

The second path is adversary-in-the-middle phishing. Evilginx3, Modlishka, and the Caffeine and Tycoon 2FA phishing-as-a-service platforms proxy the real Microsoft login page. The user enters credentials and approves the legitimate push - including the number match - because the sign-in is the one they initiated. The proxy harvests the resulting session cookie, specifically the ESTSAUTH and ESTSAUTHPERSISTENT cookies, and replays them. The session is valid. MFA was satisfied. T1539, steal web session cookie. Number matching does not address this path. Only phishing-resistant authentication does - FIDO2 security keys, Windows Hello for Business, or certificate-based authentication, where the cryptographic binding to the legitimate origin prevents proxy replay.

The third path is token theft post-authentication. If the user is on a compromised endpoint, infostealer-class malware extracts the PRT and the associated session keys from the LSA and from browser cookie stores. Tools like ROADtools and AADInternals demonstrate the primitive. The attacker imports the PRT on attacker-controlled infrastructure and authenticates as the user without any further prompt. Token Protection - currently in preview for Entra ID - binds the refresh token to the device using a cryptographic key in the TPM. Without Token Protection or equivalent device-bound session controls, a stolen PRT is a valid session anywhere.

Telemetry on push bombing is available but underused. In Entra ID sign-in logs, the relevant signal is repeated sign-in attempts against a single UPN from a single or rotating source IP, with the Authentication Details field showing the Authenticator push method and Result showing a mix of Failure: Authentication failed during strong authentication request and Success once approved. Microsoft Graph exposes this through the signIns endpoint. Sentinel has built-in analytics rules for this pattern - search for MFA Fatigue or Brute Force in the rule templates. The Risky sign-ins and Risky users blades in Entra ID Identity Protection flag the source IPs against Microsoft’s threat intelligence and assign a risk level. A sign-in flagged High risk that resulted in Success is an approved push bomb until proven otherwise.

The gaps are predictable. Tenants without Entra ID P2 do not get Identity Protection risk scoring. Tenants without a SIEM ingesting AADSignInEventsBeta or the Entra ID audit logs do not correlate the prompt storm with the eventual approval. The user almost never reports the prompts. They mute the app. The compromise proceeds in silence for hours or days before downstream activity - OAuth application consent for a malicious app, mailbox forwarding rule creation via T1114.003, or eDiscovery search for credential strings - surfaces in a different log source.

Detections worth writing. Alert on more than five Authenticator push requests to a single user within a fifteen-minute window where the prior result was failure. Alert on a Success event for an Authenticator push immediately following ten or more failures from a non-corporate IP. Alert on new device registration to Authenticator from an IP geographically distant from the user’s recent sign-in history within four hours of a password change or MFA reset event in the audit log. Alert on session token usage from an IP that has never seen a successful interactive sign-in for that user. Each of these is queryable in KQL against SigninLogs and AuditLogs in Sentinel or Log Analytics.

The technical reality post-mitigation. Number matching closes the dumb-tap path. Phishing-resistant MFA closes the AiTM proxy path. Helpdesk verification controls close the reset path. Token Protection - once GA - closes the stolen-token path. None of these are deployed by default across an existing tenant. The fatigue prompts arriving on a user’s phone are not a bug to report to Microsoft. They are an indicator of compromise for a credential already in adversary hands. The phone is the alarm. The password is the breach.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.