Lapsus$ used passwords stolen in earlier incidents to log directly into accounts at Microsoft, Samsung, and Ubisoft. Because the credentials were already valid, the login systems issued session cookies and SAML assertions without ever prompting for a second factor. Those tokens then granted access to internal tools, source code repositories, and customer data across each organization.
How Pre-Stolen Passwords Produced Valid Sessions
The attackers simply supplied the leaked passwords at the login pages. No OTP code or push notification was generated because the first factor itself succeeded. Microsoft’s disclosure and the statements from Samsung and Ubisoft confirm the same sequence: credential use followed by permission-based movement with no additional challenges.
Once authenticated, the identity providers issued SAML assertions that every connected application trusted. A single set of tokens therefore unlocked multiple systems without fresh proof of identity. The blast radius came from the federation layer, not from any weakness in a second factor that was never reached.
Why Device-Bound Signatures Would Have Stopped the First Step
Device-bound credentials require a private key that never leaves the enrolled hardware. A leaked password alone cannot generate the origin-specific signature the server demands, so the initial login would have failed at every target. The same property would have prevented the SAML assertions from ever being created.
Stolen tokens that already exist still need separate controls such as short lifetimes and strict audience restrictions. The technique eliminates the remote credential path that created those tokens but does not stop in-memory theft after a legitimate session is established.
How Secure Explicit Sign-On Shrinks Federation Risk
Federation protocols issue one reusable assertion that many applications accept. Replacing that model with per-application signatures means each service receives its own hardware-backed proof instead of a shared token that can be replayed. The user still sees one-tap access, yet nothing exists to steal and reuse across boundaries.
The device-bound architecture shows how each request stays independent without a central token store.
Passkeys and FIDO2 protect only the authentication step. They leave enrollment and recovery flows untouched. In these incidents the attackers never needed to exploit those flows, but any organization that still allows email codes or helpdesk resets to add devices would remain exposed to later device takeovers.
- Require hardware signatures on every remote and VPN login so pre-stolen passwords produce no session.
- Replace SSO assertions with independent per-application signatures to limit lateral movement after any single authentication.
- Audit recovery processes so they never accept phishable factors for device enrollment or reset.
FAQ
How did Lapsus$ authenticate into Microsoft, Samsung, and Ubisoft without triggering second factors?
Lapsus$ supplied passwords already obtained from prior leaks. The login systems accepted those credentials as valid, so no OTP or push prompt was ever issued to the attacker.
Would passkeys have prevented the initial access in the Lapsus$ incidents?
Yes. A passkey requires a signature generated by the private key inside enrolled hardware. Stolen passwords alone cannot satisfy that requirement, so the first login attempt would have failed.
Why did one compromised account grant access to multiple systems at each company?
Federation protocols issued SAML SSO assertions after the initial login. Those assertions were trusted by every connected application, allowing movement without additional authentication challenges.
Does device-bound authentication still rely on single sign-on for the user experience?
No. It uses Secure Explicit Sign-On. The user sees one-tap access, yet each application receives an independent hardware signature rather than a reusable federation token that can be stolen and replayed.
Could stronger device enrollment rules have limited later recovery options?
Yes. If device registration or reset required an already-enrolled hardware key instead of email codes or support calls, attackers could not have added their own devices even if they later obtained additional credentials.
