Okta / LAPSUS$ - A Subcontractor's Support Engineer → Five Days Inside → 366 Customers Exposed → And Two Months Before Anyone Was Told
Between January 16 and 21, 2022, LAPSUS$ had access to the environment of Sitel, a subcontractor providing customer support services to Okta, via a support engineer's laptop. Okta later assessed that up to 366 customers - around 2.5% of its base - may have been affected. The intrusion itself is a fairly ordinary third-party compromise. What made this a defining incident for the industry was the disclosure. Okta received a summary report from Sitel on March 17. Customers found out on March 22, when LAPSUS$ posted screenshots to Telegram, and Okta's security team correlated them to the January incident within ninety minutes of seeing them. Okta received the complete forensic report from Sitel later that same day. For two months, the organizations whose identity provider had been touched did not know. This chain is here for the disclosure failure at least as much as the technical one.
Count the hops. An Okta customer trusts Okta. Okta outsources customer support to Sitel. Sitel staff work on machines Sitel manages. LAPSUS$ compromised one of those machines. So the organizations ultimately exposed were three relationships away from the compromised endpoint, and had no contractual or practical visibility into it - most would not have known Sitel existed. LAPSUS$ was known for buying credentials and recruiting insiders at outsourcers and telecoms precisely because that layer combines broad access with weaker controls and lower scrutiny than the brand-name company it serves.
Window: January 16-21, 2022 - five days
Actor: LAPSUS$ / DEV-0537, known for recruiting insiders and buying access at outsourcers
Customer visibility into Sitel: Effectively none
Why this layer: Broad access, weaker controls, less scrutiny than the brand it serves
Okta was clear that support personnel cannot create or delete users, download customer databases, or access source code. But the access they do have is exactly the access an attacker wants from an identity provider: the ability to reset a password, and the ability to reset multi-factor authentication for a user. That is the same capability Scattered Spider obtained by phoning a help desk at MGM eighteen months later, and it is why a support console at an IdP should be treated as a privileged administrative system rather than a customer service tool. The screenshots LAPSUS$ published showed internal applications and a Slack channel, which is also a reminder that support tooling tends to sit alongside internal chat where more context is casually available.
Support can: Reset passwords and reset MFA for customer users
Why that matters: It is the precise capability an attacker wants from an IdP
Same capability abused in: Scattered Spider / MGM, via a phone call, eighteen months later
Also exposed: Internal applications and Slack context visible in the published screenshots
The published timeline is unusually precise and unusually damning. LAPSUS$ posted screenshots at 03:30 UTC on March 22. By 05:00 Okta Security had determined they related to the January Sitel incident. Okta received the complete forensic report from Sitel at 12:27 that same day. So the correlation took ninety minutes once the evidence was public, while the two months before it were spent waiting on a subcontractor's investigation. The customers who might have needed to check their own logs for anomalous password or MFA resets in January were not asked to, because nobody told them. Okta's chief security officer subsequently acknowledged the delay was a mistake. The general lesson is that a contractual notification obligation which permits a two-month forensic process is not a security control - your customers' ability to respond decays to nothing long before the report is finished.
March 17: Okta receives a summary report from Sitel
March 22, 03:30: LAPSUS$ publishes screenshots
March 22, 05:00: Okta correlates them to the January incident - ninety minutes
March 22, 12:27: Okta receives the complete Sitel report
Net effect: Customers could not check their own logs during the window it mattered
The technical blast radius was bounded and Okta's eventual analysis was thorough. The reputational and strategic effect was larger, because it forced a question the industry had been avoiding: an identity provider is a single point of trust for every application behind it, so its supply chain is your supply chain, and its subcontractors are your subcontractors. Okta was breached again through its support organization in October 2023 by a different route, which is why these two chains sit on this page separately - the recurrence is the point. LAPSUS$ itself was disrupted later in 2022 following arrests in the UK.
Technical scope: Bounded by what support tooling permits
Strategic effect: Forced the question of identity provider concentration risk
Recurrence: Okta's support organization was compromised again in October 2023, by another route
Actor outcome: LAPSUS$ disrupted later in 2022 following arrests