Lapsus$ vs Microsoft: When Teen Hackers Beat a Hyperscaler’s Odds

On 20 March 2022, extortion group Lapsus$ announced it had breached Microsoft, and the claim carried an unusual trophy: source code. The group said it had obtained 37 GB of data including partial source for Bing and Cortana — boasting, in its signature megaphone style, that it had ~90% of Bing’s source — and dumped samples as proof. Microsoft’s response model had matured into something almost routine: the company confirmed that one account had been compromised, granting the actor limited access, that no customer data was involved, and that its teams had already cut off access mid-operation. A week later it published a full technical profile of the group under the threat-actor label DEV-0536, converting the incident into a public masterclass on what was then a genuinely novel adversary class: a scattered, young, operationally sloppy but startlingly effective social-engineering collective that had already gutted NVIDIA, Samsung, Vodafone, and Ubisoft — and had just demonstrated that even one of the planet’s most-targeted, best-defended engineering organisations could not fully keep an opportunistic teen-adjacent crew out of source-adjacent dev tooling if a single credential fell. The strategic reading mattered more than the payload: Lapsus$ didn’t need to own Microsoft to hurt the ecosystem — access to (or even credible claims about) source code for globally deployed software creates intelligence value for every future attacker, and it proved the group’s method (SIM swaps, MFA fatigue, helpdesk social engineering, token theft) worked identically against a hyperscaler and a game studio. Less than a week later the same crew would pivot to Okta’s support vendor, closing out a March that permanently changed how the industry scores identity-adjacent risk.

What happened

March 2022 was Lapsus$’s victory lap. The group — by then running a conspicuously public Telegram channel where it polled followers on which stolen data to leak next — had spent February inside NVIDIA (nearly a terabyte claimed, plus a failed attempt to reinstall exfiltrated data with ransomware logic) and Samsung (~190 GB including source for Galaxy device software). On 20 March it announced Microsoft, claiming 37 GB including Bing and Cortana source, and posted samples.

Microsoft’s disclosure, published the same week, was a model of calibrated confirmation: one account compromised, limited access, no customer data, access already revoked — and the company walked through its detection and response as it happened. The tone was almost collegial because Microsoft had been watching this actor for months under its DEV-0536 tracking label; the reply doubled as the definitive public profile of the group, covering its targeting (large tech, telecoms, government, gaming), its motive (extortion, destruction-for-leverage, and infamy), and its toolset: phone-based social engineering of helpdesks and mobile carriers, SIM swapping to intercept OTPs, MFA fatigue attacks (bombarding a target with push prompts until one is approved), password-reset abuse, and token theft — including replaying stolen Azure AD session tokens by enrolling a rogue account for remote access, effectively minting persistence out of a stolen cookie.

Then the pattern repeated at higher altitude: days later, Lapsus$ published screenshots of Okta’s support console (via contractor Sitel), and the month closed with the group’s momentum only halted by April arrests of several UK teenagers — an ending as operationally banal as the intrusions were loud. The core access techniques never died; they became standard playbook for every crew that followed.

The DEV-0536 method

Lapsus$ tradecraft (per Microsoft DEV-0536 profile):

  PHASE 1 - INITIAL ACCESS
    phone-based social engineering
    (target: helpdesk / IT support)
    SIM swap via carrier manipulation
    -> OTP interception
    purchased credentials (commodity
    infostealer logs / initial-access
    brokers)

  PHASE 2 - MFA DEFEAT
    MFA fatigue / push-bombing
    (spam prompts until approval)
    password-reset abuse via helpdesk
    (con scripts, no code needed)

  PHASE 3 - POST-ACCESS
    token theft over keylogging:
      steal Azure AD session tokens
      replay token; enrol rogue
      WVD/RDP account -> persistent
      access even after password
      reset

  PHASE 4 - COLLECTION & EXTORTION
    source code, secrets, tickets
    Telegram poll: leak or extort?
    public humiliation as leverage

  DEFENSIVE MAPPING (what stopped
  or slowed it):
    number-matched MFA / FIDO2 keys
    (un-phishable, no push to bomb)
    helpdesk verification protocols
    (video ID, manager callbacks)
    token binding / short TTL
    conditional access on device
    posture

Impact and numbers

Timeline

Why it still matters in 2026

Because the Microsoft chapter closed the argument that this was a talent problem. A crew whose members turned out to be school-age, whose tradecraft was 90% telephone and patience, walked into some of the best-defended networks on earth by attacking the seams between people and identity systems — and the industry’s response had to become structural. The defensive agenda Lapsus$ forced is now baseline: phishing-resistant MFA (passkeys/FIDO2 with number matching as interim) specifically because push-bombing and SIM-swap OTP theftOtherwise worked; helpdesk identity-verification hardening (callback protocols, video verification, manager approval for resets and MFA re-enrolment) because the helpdesk is the attack surface; session-token protections (absolute TTLs, device binding, continuous access evaluation) because token replay beat credential resets. And the lineage is direct: the 2023–2024 era of identity-defined crises — Scattered Spider’s casino-empire hijacks via vishing helpdesks, industry research into token-theft families (session-cookie replay, Golden SAML class), Snowflake-customer breaches riding stolen session cookies in lacking-MFA accounts, and the 2024–2025 MFA-fatigue campaigns against cloud tenants — are all Lapsus$’s playbook industrialised. For victims and defenders alike, the episode also settled the economics of source-code theft: partial Bing/Cortana source never produced a direct doomsday exploit, but it seeded durable intelligence value and, more importantly, normalized source exfiltration as extortion currency. What Microsoft modelled in its response — fast, precise scoping, actor-class publication, no overclaiming — became the disclosure template other vendors now follow when the same playbook hits them. Lapsus$ the group died in a police van; Lapsus$ the method became the defining threat model of the decade’s identity era.

Detection and hardening takeaways

• Kill the push, keep the phishing-resistance. MFA fatigue only works against interceptable or approvable-without-attention factors; number matching was a stopgap, passkeys/FIDO2 hardware-backed credentials are the answer, and any helpdesk workflow capable of resetting them needs hardened verification first.
• Treat the helpdesk as privileged infrastructure. Lapsus$’s favoured door was a phone call to a support human; callback verification, video ID, manager approval for credential/MFA resets, and mandatory delays on high-risk changes convert social engineering from a skeleton key into an auditable workflow.
• Defend the token, not just the password. Password resets don’t evict stolen session tokens; pair short absolute token TTLs, device-binding/conditional access, and continuous evaluation so a replayed cookie dies in minutes and a rogue device enrolment trips alarms.
• Alarm on MFA-behaviour anomalies. Push-bombing produces a signature (prompt cascades, failures-then-success patterns, new-device enrolments); identity-protection rules that page humans on these — not just on sign-in failures — shrink the window from compromise to persistence.
• Scope and disclose with precision. Microsoft’s “one account, limited access, no customer data, here is the actor profile” template kept the narrative factual while delivering more defensive value than the leak delivered damage; organisations that pre-draft this posture respond better when the same playbook arrives.

FAQ

Did Lapsus$ actually get Microsoft customer data?

No — Microsoft’s disclosure was explicit that no customer data was involved, and the compromised access was limited to a single account with partial source-code-adjacent exposure (Bing/Cortana samples posted as proof). The claim’s “90% of Bing source” figure came from the group itself and was never fully validated; the strategic weight of the incident rests on the method and the response, not on a verified exfiltration census.

Who was in Lapsus$, and what happened to them?

An unusually young, loosely coordinated crew — UK investigations led to April 2022 arrests of seven teenagers, with a 16-year-old later convicted (2023) as a core operator, and Brazilian authorities charged members of a connected cell. The group’s operational security was famously poor (one member’s OPSEC failings became evidence), which contributed to the fast takedown; the playbook, however, required no genius to inherit, and successor crews — most prominently Scattered Spider — ran the same social-engineering-first identity attacks at casino-scale in 2023.

Why steal source code if you can’t easily exploit it?

Three reasons: extortion leverage (victims pay to avoid public drip-leaks), intelligence value (source becomes a map for finding vulnerabilities later, “security through obsc­urity” defences collapse), and reputation within the crew’s scene (Telegram clout was a real Lapsus$ objective — they polled their audience on next moves). Microsoft’s calm handling showed the countermove: if you can precisely scope the exposure and say so publicly, the extortion leverage largely evaporates, leaving only the long-tail intelligence risk every big vendor already assumes.