LAPSUS$: MFA fatigue and the help-desk reset that hands over a cloud identity
A LAPSUS$-style crew buys a working credential, then rides it past MFA by prompt-bombing a tired user or by talking the help desk into a reset. The weak link is the human approval and the help desk, not a bug, and the reset the help desk performed for the attacker is the breach vector. Here is how it works and how to contain it.
The attacker already had the password. MFA was the only thing in the way, and it did not require a zero-day to get past. It required a tired user tapping Approve at two in the morning, and a help-desk agent who wanted to be helpful. This is LAPSUS$-style tradecraft: social engineering first, cloud-identity takeover second, and pure data extortion at the end with no ransomware anywhere in the chain.
How it works
The crew starts with a valid account. Credentials come from an infostealer log bought off a marketplace, so the username and password are correct on the first try. The sign-in to Entra ID stalls at MFA. That is the only real obstacle, and there are two ways past it.
The first is fatigue. The attacker replays the sign-in over and over, generating a burst of push notifications on the user’s authenticator. This is T1621 (Multi-Factor Authentication Request Generation). Late at night, worn down and assuming the app is misbehaving, the user taps Approve once and the sign-in completes from the attacker’s location.
The second is the help desk. When a target uses number-matching and holds firm against the prompts, the crew calls the service desk impersonating the locked-out employee, armed with OSINT and details from the same breach data. They talk an agent into resetting the account’s MFA, then enroll their own authenticator as the new factor. This is T1556 (Modify Authentication Process) with T1098 (Account Manipulation). The reset the help desk performed, in good faith, is the breach.
Either path lands the crew inside the cloud identity as a valid account with MFA satisfied. From there they mint access and refresh tokens under T1078 (Valid Accounts), enumerate M365 mail and SharePoint and internal source repositories, and bulk-download sensitive data to an external host under T1567 (Exfiltration Over Web Service). Then they extort with a leak threat. No encryptor is ever deployed.
Why it matters
There is no software vulnerability to patch here. The weak link is the human approval and the help-desk process, and that is uncomfortable because it means your MFA rollout did not close the gap you thought it did. Push-approval MFA that lets a user blindly tap Approve is defeated by persistence, and any help desk that can reset MFA without strong identity-proofing is a standing bypass for every account it serves.
The non-obvious part is the containment trap. The incident looks like a compromised account, so the reflex is to reset the password. That reflex fails. The session and refresh tokens the attacker already minted are independent of the password, so a token issued minutes ago keeps working no matter how many times you rotate the credential. And the authenticator the attacker enrolled through the help-desk reset survives a password reset entirely, sitting there as standing persistence. You can reset the password, feel secured, and watch the crew keep reading mailboxes.
How to detect it
The completed sign-in looks clean, because the user genuinely approved and the credential was genuinely valid. The tell is the sequence. Watch for a valid-account sign-in interrupted at MFA from an unfamiliar IP or ASN, then a rapid burst of push prompts on that account ending in a single Approve from a new device, then immediate token issuance and mailbox reads. On the help-desk path, watch for an MFA method reset followed by a new authenticator registered from an unfamiliar device, and correlate service-desk tickets against sign-in anomalies. You will not see a failed MFA on the takeover, because the approval or the enrolled factor satisfied it.
How to contain and shut it down
Lead with the session and the reset path, not the password. Revoke the account’s active sessions and refresh tokens first, a sign-out-everywhere, so the live token the attacker minted is invalidated. That, not a password reset, is what evicts them. Then remove any authenticator the attacker enrolled from the hijacked session or through the help-desk reset, because that factor is the real persistence and it outlives a reset. Block the sign-in and the exfil destination. Then freeze help-desk MFA and credential resets behind strong identity-proofing, because the reset is the vector and leaving it open lets the crew simply re-enroll on the next account. Reset the password as well, but understand it does nothing on its own against a live token.
Scope the damage from the logs, not from the user’s disk. There is no ransomware to find. Correlate the Entra ID sign-in and audit logs, the M365 unified audit log, and proxy and DLP records to enumerate every app and repository the session reached and confirm what data left.
The durable fixes attack every link. Number-matching or phishing-resistant MFA removes the blind-Approve primitive that prompt-bombing depends on. Help-desk identity-proofing before any MFA or credential reset closes the social-engineering path. Shorter session and token lifetimes with risk-based re-evaluation on a new device blunt token replay. And alerting on new-factor enrollment followed by sensitive access catches the reset abuse before the download starts.
Practice it
GraphLattice Range runs exactly this incident: a purchased credential past MFA by fatigue and by a help-desk reset, a password reset that fails to evict the attacker, and the session revocation, rogue-factor removal, and identity-proofing freeze that actually contain it. Teams learn to lead with the session and the reset path, not the credential, and to recognize why the weak link was the human and the help desk, not a bug.