Okta — Lapsus$ support-engineer breach

What happened

In January 2022 Lapsus$ — a data-extortion group notable for recruiting insiders and compromising the identity systems of technology companies — obtained access to the internal support tooling used by Sitel, a third-party customer support contractor that provided helpdesk services on behalf of Okta. The attacker had session-level access to Okta’s customer support environment for approximately five days between 16 and 21 January 2022.

Okta became aware of the compromise in late January and began an investigation with support from Mandiant. For two months, the incident remained non-public. On 22 March 2022, Lapsus$ posted screenshots on their Telegram channel showing what appeared to be access to Okta’s internal administrative console — including views of customer data and internal Okta systems. Okta’s initial public response characterised the incident as limited: the screenshots showed only a single workstation compromise, and the company initially suggested that only a small number of customers were affected.

The disclosure collapsed under scrutiny. Mandiant’s forensics, and subsequent Okta analysis, established that up to 366 Okta customer tenants — approximately 2.5% of Okta’s customer base — had been potentially viewable to the attacker during the five-day access window. For an identity provider whose customer base includes some of the world’s largest enterprises, 366 potentially exposed tenants is a material figure. Okta’s communications through the incident — the two-month gap before public disclosure, the initially minimised scope estimate, the emphasis on “no customer data was directly exfiltrated” rather than the access that existed — drew sustained and well-founded criticism from customers, security researchers, and the press.

How it worked

Lapsus$ did not attack Okta directly. They attacked Sitel, a business-process outsourcing company that Okta used to provide customer support services. Sitel’s support engineers had access to Okta’s internal support tooling — the interface used to help customers who are locked out of their accounts, experiencing authentication problems, or needing administrative changes. That access level is necessary to do the support job; it also provides visibility into customer account configurations, user lists, and session data.

The specific method by which Lapsus$ compromised the Sitel engineer’s account has not been publicly detailed with precision. Lapsus$ is known for multiple access methods: compromising credentials through infostealer markets, recruiting insiders directly (including advertising for corporate insiders on Telegram), and exploiting weak or absent MFA on contractor accounts. In this instance the Sitel engineer’s credentials appear to have been compromised, giving the attacker authenticated access that looked like legitimate support activity.

The five-day access window between 16 and 21 January 2022 gave the attacker time to explore the support environment, view customer records, and gather material for later use as leverage — screenshots that would be published on Telegram two months later to maximum humiliating effect. Okta’s own detection capability at Sitel was limited; the identity provider was dependent on its contractor’s logging and alerting to identify anomalous access, and that visibility was insufficient to detect the intrusion in real time.

Lapsus$ operated through public humiliation as a core extortion mechanism. Unlike ransomware groups who encrypt and demand payment in private, Lapsus$ preferred Telegram posts, screenshots, and public pressure. The two-month interval between the January breach and the March Telegram post appears deliberate: the group waited until they had calculated the moment of maximum impact before publishing, giving Okta no opportunity to disclose on its own terms.

Timeline

• 16–21 January 2022 — Lapsus$ has authenticated access to Okta’s customer support environment via a compromised Sitel support engineer account. Approximately five days of access.
• Late January 2022 — Okta detects anomalous activity and begins investigation; Mandiant engaged.
• January–March 2022 — Investigation ongoing; incident not publicly disclosed. Okta customers not notified.
• 22 March 2022 — Lapsus$ posts screenshots on Telegram showing apparent access to Okta’s internal admin console. Okta forced into reactive public disclosure.
• 22 March 2022 — Okta’s initial statement characterises the incident as limited; suggests “a small percentage” of customers potentially affected.
• Late March–April 2022 — Okta revises scope upward: up to 366 customer tenants potentially viewable during the access window.
• April 2022 — Okta publishes full updated investigation summary. Mandiant’s forensic conclusions incorporated.
• March–April 2022 — Multiple Lapsus$ members, primarily teenagers in the UK and Brazil, arrested. The group continues to operate under shifting membership.
• October 2023 — Okta discloses a separate support-system breach affecting all customers’ help-desk metadata. Third-party support tooling access was again the entry vector.

What defenders should learn

The central lesson from the Okta breach is about third-party access to identity infrastructure. Okta is an identity provider: its business is verifying who you are so you can get into other systems. The irony of an identity provider being compromised through inadequate controls on a third party’s access to its own systems is pointed, but the underlying dynamic applies to any organisation. Every third-party vendor, contractor, and outsourcer with access to your systems extends your security perimeter. Their security posture becomes part of your security posture.

For identity providers specifically — and for any organisation whose product or infrastructure forms part of another organisation’s authentication layer — this is an existential risk category. Customers using Okta had accepted a dependency on Okta’s security. That dependency extended, without their knowledge or consent, to the security of Okta’s support contractor. Organisations that rely on critical third-party identity infrastructure should ask their providers direct questions about third-party access controls, MFA requirements for support staff, and monitoring of support-tool access. The answer to “who has access to my Okta tenant via support tooling?” should be a known and audited fact, not an assumption.

The disclosure timeline is the second major lesson. Two months elapsed between Okta’s knowledge of the breach and any customer notification. During that interval, 366 customer tenants had potentially been accessed without their knowledge. Those customers — many of them large enterprises with their own regulatory obligations — had no opportunity to assess whether their users or systems had been affected, to take protective action, or to inform their own customers. The notification obligation runs not just to regulators but to affected parties who need time to respond.

Okta’s experience with the October 2023 follow-on breach — again via third-party support tooling — raises a harder question: whether architectural decisions that give support staff access to customer account data are compatible with the security posture an identity provider’s customers expect. Privileged support access and strong customer data isolation are in tension. Resolving that tension through technical design — moving to architectures where support tooling provides assisted troubleshooting without direct visibility into customer account contents — is harder than adding MFA requirements, but it is the kind of structural change the incident ultimately demands.