Prevent Lapsus$ MFA prompt spam and SIM swap

Phishing-proof MFA 2.0 hardens the credential and recovery surfaces Lapsus$ (DEV-0537) abused when it compromised a single Microsoft employee account in the week of 22 March 2022. According to Microsoft's Security Blog, tactics in that intrusion reflect the group's documented MFA prompt spam against simple-approval push, helpdesk credential-reset social engineering, and SIM swap against phone-bound factors. Public reporting does not establish which of those TTPs actually opened that Microsoft account. Closing those phishable login and enrollment paths stops that initial-access class. Once a valid employee session already exists, limited Azure DevOps access is post-auth containment no login MFA undoes. For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA 2.0 have stopped Lapsus$ initial access at Microsoft?

Phishing-proof MFA 2.0 would have hardened the credential and enrollment paths Microsoft documented for DEV-0537, so MFA prompt spam, helpdesk credential reset, and SIM swap stop yielding a workforce login like the single Microsoft employee account compromised in March 2022. Device-bound keys leave no transferable OTP, SMS code, push approval, or recovery secret for an attacker to spam, coach, or reroute. Public reporting does not establish which specific TTP landed on that Microsoft account, and Microsoft interrupted the actor mid-operation with no customer code or data involved. The prevention claim is scoped to initial access, not to undoing DevOps rights after a session already existed.

How does MFA 2.0 stop MFA prompt spam without asking users to be more careful?

MFA 2.0 stops MFA prompt spam because there is no simple-approval push to fatigue. Lapsus$ / DEV-0537's documented playbook includes spamming approval prompts until someone accepts; that only works when the second factor is a transferable yes/no on another channel. With device-bound, origin-bound signatures, authentication is a local cryptographic proof on an already-enrolled device. There is nothing useful to bomb, relay, or social-engineer in real time. That is prevention, not detection: the login path those prompts abuse never opens.

Do helpdesk reset and SIM swap fall under the same MFA 2.0 fix?

Yes. Helpdesk credential-reset social engineering and SIM swap sit in the same industrial class as prompt spam when the goal is a transferable workforce factor. DEV-0537's documented methods include talking support into a reset or re-enrollment and swapping the phone number that receives SMS or voice codes. Phishing-proof MFA 2.0 removes phishable factors across the identity lifecycle, including recovery: adding or replacing a device requires an already-enrolled device, not a code IT can read out or a number an attacker can seize. Credit the enrolment boundary, not user caution. Public reporting still does not name which path opened the Microsoft employee account.

After the employee session existed, would MFA 2.0 have blocked Azure DevOps access?

No. After Lapsus$ held a valid Microsoft employee session, limited Azure DevOps and source access was already authorized for that identity. No login MFA revokes rights already granted in that session. Stopping that phase is detection, session kill, and least privilege. Closing the phishable login and recovery paths is the prevention claim for this breach class. Malware or other theft after a legitimate login is a harder, separate problem.

Are passkeys alone enough against DEV-0537's enrollment playbook?

Passkeys are phishing-resistant at the login ceremony, which hardens origin-bound authentication. They do not automatically close enrollment or recovery if a helpdesk can still reset access with a phishable factor or if phone-bound channels remain in the lifecycle. MFA 2.0 is phishing-proof across registration, device onboarding, authentication, and decommissioning, so the helpdesk-reset and SIM-swap surfaces Microsoft documented for DEV-0537 do not silently mint an attacker-controlled factor. Resistant hardens login; proof closes the lifecycle those TTPs actually abuse.