In the week of 22 March 2022, Microsoft confirmed that Lapsus$ (tracked as DEV-0537) compromised a single employee account and gained limited Azure DevOps source access. Microsoft interrupted the actor mid-operation and stated no customer code or data was involved. The company's Security Blog says tactics in this intrusion reflect DEV-0537's documented credential and enrollment playbook (MFA prompt spam, helpdesk credential-reset social engineering, and SIM swap), without proving which specific TTP landed on that Microsoft account.
If you want the prevention angle on those credential and recovery surfaces, read the related article on mfa2point0.com.
FAQ
How did Lapsus$ get into Microsoft in March 2022?
Lapsus$ (DEV-0537) compromised a single Microsoft employee account in the week of 22 March 2022, which granted limited Azure DevOps source access. According to Microsoft's Security Blog on that date, tactics used in the intrusion reflect the group's documented credential and enrollment-phase methods across victims: MFA prompt spam against simple-approval push, helpdesk social engineering for credential reset, and SIM swap against phone-bound factors. Public reporting does not establish which of those TTPs actually compromised that Microsoft employee account. Microsoft interrupted the operation mid-stream.
Did attackers MFA-fatigue a Microsoft employee?
Public reporting does not establish that Microsoft itself was MFA-fatigue'd as an org-specific fact. Microsoft documented MFA prompt spam (simple-approval fatigue) as one of DEV-0537's recurring TTPs against organizations generally, and stated that tactics in this intrusion reflect those group methods. That is not the same as a proven, named push-bomb on the compromised Microsoft account. Treat the fatigue path as architecture the group used, not as a confirmed Microsoft-internal verdict.
What did Lapsus$ actually reach inside Microsoft?
With the compromised employee account, the actor gained limited Azure DevOps and source access. According to Microsoft, the company interrupted the actor mid-operation. Microsoft stated no customer code or data was involved. Public reporting does not establish named repositories, exfil volume, ransom demands, or a broader Microsoft estate compromise beyond that single account and limited source path.
Once they had the employee account, could MFA undo the DevOps access?
No. After a valid employee session existed, further Azure DevOps access was already authorized for that identity. Stopping that phase is detection, session kill, and least privilege, not another factor at login. The credential-phase fight is upstream: whether prompt spam, a coached helpdesk reset, or SIM swap ever yields a workforce login in the first place. A fix for those transferable factors exists; the companion covers prevention without replaying the attack chain.
Why does helpdesk reset and SIM swap sit next to push spam here?
Because they are the same industrial class when the goal is a transferable workforce factor. DEV-0537's documented playbook includes spamming simple-approval prompts until someone accepts, talking support into a credential reset or re-enrollment, and swapping the phone number that receives SMS or voice codes. Microsoft grouped those methods as the credential and enrollment surfaces this actor abuses. Public reporting still does not name which path opened the single Microsoft employee account in March 2022.
