The Okta Breach: How Teenagers With Commodity Tools Compromised an Identity Provider Serving Thousands

‍‌‌​‌​​‌‌‌‌‌​‌‌‌‌​‌​‌​​​​‌‌‌‌​​‌​​​‌​​‌​​​​‌​‌​‌‌​‌‌​‌​‌​​‌‌​‌​‌​‍Okta provides identity and access management for over 15,000 organisations worldwide. When a company's employees log in to their cloud services, their email, their internal tools, there's a reasonable chance Okta is the system deciding whether to let them in. That makes Okta's infrastructure a single trust anchor for thousands of businesses, and it makes Okta a target worth more than the sum of its own data.

In January 2022, a group of teenagers used commodity hacking tools, social engineering, and a compromised third-party contractor to get inside that trust anchor. The group called themselves Lapsus$, and their stated objective wasn't Okta's own systems at all. In their own words, published on Telegram: "Our focus was only on Okta customers."

The breach eventually made headlines on 22 March 2022, two months after Okta's security team first detected suspicious activity. That two-month gap between detection and public disclosure is where most of the real lessons sit.

What everyone thinks happened

The common version of this story is simple: hackers broke into Okta and got access to customer data. Some coverage implied that Okta's own network was compromised directly, that customer credentials were stolen, and that every Okta customer was potentially at risk.

That version gets the architecture wrong in several important ways. The attackers didn't breach Okta's network directly. They compromised a workstation belonging to a support engineer at Sitel, a third-party contractor that provided customer support services for Okta. Sitel had acquired another company called Sykes. The compromised workstation sat on what Sitel described as the "legacy Sykes network." That was an older infrastructure that hadn't been fully integrated into Sitel's own security controls.

The attacker couldn't create or delete Okta users. They couldn't download customer databases or access source code. They couldn't authenticate directly to any customer accounts either. What they could do, through Okta's internal support tool called SuperUser, was view customer tenant information and facilitate password and multi-factor authentication (MFA) resets without obtaining the actual credentials.

The distinction matters more than it might seem. The actual risk was narrower than the headlines suggested. But the architectural concern was far more significant than most coverage explored: a contractor's compromised workstation could reach Okta's internal support systems at all.

What actually happened

The Sitel network compromise

The forensic timeline starts on 16 January 2022, when an attacker gained initial access to Sitel's network via Remote Desktop Protocol (RDP). Over the next five days, the attacker moved through the environment using techniques that any penetration tester would recognise.

The attacker searched Bing for privilege escalation tools on GitHub. They downloaded Mimikatz, a well-known credential extraction tool used for harvesting Kerberos tickets and cached passwords. They used Process Explorer and Process Hacker to establish a foothold and understand the running environment. They disabled the FireEye endpoint protection agent using off-the-shelf bypass tools also sourced from GitHub.

They exploited CVE-2021-34484, a privilege escalation vulnerability in the Windows User Profile Service, to elevate their access. They uploaded Security Account Manager (SAM) files, which contain local account password hashes, to Pastebin via cloud applications.

And then they found something that made the rest of the attack simpler. It was an Excel file titled "DomAdmins-LastPass.xlsx," containing domain admin credentials stored in a spreadsheet on the network.

With domain admin credentials in hand, the attacker created backdoor user accounts within Sitel's environment. That gave them persistent access to the network that Sitel's support engineers used to reach Okta's systems.

The Okta detection and response timeline

On 20 January 2022 at 23:18 UTC, Okta's security team detected something unusual. A new password factor had been added to a Sitel customer support engineer's Okta account from a previously unknown location. The attacker failed the MFA challenge on this attempt.

Twenty-eight minutes later, at 23:46 UTC, Okta Security escalated the alert to a security incident. By 00:28 UTC on 21 January, Okta had suspended the compromised account and terminated all active sessions. From detection to account suspension, that's one hour and ten minutes, which was a fast response.

At 18:00 UTC on 21 January, Okta shared indicators of compromise (IoCs) with Sitel, who then engaged a third-party forensic firm to investigate. The forensic investigation ran from 21 January through 28 February 2022. The firm delivered its report to Sitel on 10 March. Sitel provided a summary report to Okta on 17 March, and Okta received the complete forensic report on 22 March at 12:27 UTC.

That same day, at 03:30 UTC, roughly nine hours before Okta received the full report, the Lapsus$ group published eight screenshots to their Telegram channel. The screenshots showed access to Okta's internal systems, including the SuperUser application, Slack channels, Jira, and what appeared to be a Cloudflare interface. The system dates on the screenshots showed 21 January 2022.

The 25-minute window

Okta's final investigation, published on 19 April 2022 by Chief Security Officer (CSO) David Bradbury, concluded that the actual impact was far smaller than the initial worst-case estimate.

The threat actor actively controlled the Sitel support engineer's workstation for only 25 consecutive minutes on 21 January 2022. During those 25 minutes, they accessed two active customer tenants within the SuperUser application. Both customers were separately notified at the time.

The threat actor viewed limited additional information in Slack and Jira. Bradbury stated this information "cannot be used to perform actions in Okta customer tenants." The attacker couldn't perform configuration changes or execute MFA or password resets. They couldn't conduct customer support impersonation events or authenticate to any Okta accounts.

The initial estimate of 366 potentially affected customers (roughly 2.5% of Okta's customer base) represented the maximum possible exposure. That number covered every tenant that any Sitel engineer had accessed during the five-day window. The actual confirmed impact was two tenants during those 25 minutes.

How the disclosure unfolded

This is where the breach became a case study in transparency and third-party communication failures.

Okta's security team detected the anomaly on 20 January and suspended the account within 70 minutes. They shared IoCs with Sitel on 21 January. But from that point, the timeline went quiet for weeks. The forensic investigation alone took five weeks to complete. The report went to Sitel on 10 March, and Sitel gave Okta a summary seven days later on 17 March. Five more days passed before Lapsus$ forced the disclosure on 22 March.

Two months elapsed between Okta detecting the incident and Okta's customers learning about it. During those two months, 366 organisations whose authentication infrastructure was potentially compromised had no visibility into the situation.

Okta's initial public statement on 22 March attempted to reassure customers. The company stated: "The Okta service has not been breached and there are no corrective actions that need to be taken by our customers." For organisations whose tenants may have been accessed through SuperUser, that framing didn't land well.

Amit Yoran, CEO of a major cybersecurity vendor and an Okta customer, published an open letter criticising Okta's response directly. He wrote: "When you were outed by LAPSUS$, you brushed off the incident and failed to provide literally any actionable information to customers." In May 2022, shareholders filed a lawsuit accusing Okta of failing to share breach details promptly. Okta eventually agreed to pay USD 60 million to settle it.

David Bradbury's final update on 19 April acknowledged both failures. He expressed disappointment at "the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report." He also said: "Once we received the Sitel summary report we should have moved more swiftly to understand its implications."

The group behind the breach: Lapsus$ in context

Lapsus$ wasn't what most people picture when they hear "threat group." The CISA Cyber Safety Review Board (CSRB) report from August 2023 put the group at 8-10 known members, based primarily in the United Kingdom and Brazil. They were predominantly teenagers aged 16 to 21.

Between 2021 and 2022, this group of teenagers breached Nvidia (1 TB of data, 71,000 employee credentials), Samsung (190 GB of source code), and Microsoft (37 GB of Bing and Cortana source code from Azure DevOps). They also hit T-Mobile (30,000 source code repositories), Ubisoft, Mercado Libre, Globant, and Okta. Microsoft tracked the group as DEV-0537, later renamed Strawberry Tempest.

Their techniques were effective precisely because they targeted people and processes rather than technical vulnerabilities exclusively.

They performed SIM swapping at an industrial scale. The CSRB found that Lapsus$ paid as much as USD 20,000 per week to access a telecoms provider's platform and perform SIM swaps. That gave them the ability to intercept SMS-based MFA codes for any target whose phone number they could identify.

They ran MFA fatigue attacks against employees at target organisations. They'd spam push notification MFA prompts over and over until someone approved one just to make it stop. No technical bypass required, just persistence and human frustration.

They social-engineered help desks with detailed knowledge of their targets. The group gathered intel on team structures, help desk procedures, and crisis response workflows, then used that knowledge to manipulate support staff.

They recruited insiders by paying for credentials and access. Lapsus$ advertised on Telegram to buy credentials from employees and contractors at target organisations. They paid accomplices to provide credentials, approve MFA prompts, or install remote management software on corporate workstations.

They replayed stolen session tokens to bypass MFA entirely. Session tokens represent already-authenticated sessions, so replaying them skips the authentication step altogether.

They joined incident response calls to watch organisations respond in real time. In at least one instance, a member unmuted themselves to demand ransom and shared their screen while deleting victim data.

The most prominent member, Arion Kurtaj (online alias "White"), was 16 years old at the time of the first arrests on 22 January 2022. He was re-arrested on 31 March along with an unnamed co-conspirator. Kurtaj was assessed as unfit to stand trial due to autism, but a seven-week court case proceeded regardless. He was convicted in August 2023 and sentenced to an indefinite hospital order in December 2023.

While on bail and under police supervision, Kurtaj allegedly hacked Rockstar Games and Uber in September 2022. He leaked GTA 6 footage reportedly using a hotel room television, an Amazon Fire Stick, a mobile phone, and a keyboard.

Myth vs fact

Myth: Okta's own network was directly compromised by the attackers.

The breach didn't originate inside Okta's infrastructure at all. It started at Sitel, a third-party customer support contractor operating on a legacy network inherited from the Sykes acquisition. The attacker gained RDP access to a Sitel support engineer's workstation and, through that workstation, could reach Okta's internal support applications. Okta's core authentication infrastructure, the service that issues tokens and manages authentication flows for its customers, was not breached.

Fact: The attack exploited the trust relationship between Okta and its third-party contractor. The risk wasn't in Okta's own security controls. It was in the contractor's environment, which operated under weaker security standards.

Myth: Every Okta customer's data was compromised.

The initial disclosure mentioned 366 potentially affected customers, approximately 2.5% of Okta's customer base. That number represented the maximum theoretical exposure based on which tenants any Sitel engineer had accessed during the five-day window. The final investigation found that the attacker actively controlled the workstation for only 25 minutes and accessed only two customer tenants during that time.

Fact: Two customer tenants were confirmed as actually accessed. The 366 figure was the worst-case boundary, not the confirmed impact. Both affected customers were individually notified at the time.

Myth: Lapsus$ used advanced, state-sponsored tooling to breach Okta.

The tools used in the Sitel compromise were all commodity. Mimikatz handled credential extraction from the local system. Process Explorer and Process Hacker gave them system visibility. Publicly available GitHub tools disabled endpoint protection. They used a known Windows privilege escalation vulnerability (CVE-2021-34484). The actual breakthrough was finding a spreadsheet of admin credentials saved on the network.

Fact: The CSRB assessment characterised Lapsus$ techniques as exploiting vulnerabilities in the identity and access management ecosystem through social engineering and commodity tools. Their success came from targeting the human and process layers, not from deploying advanced malware.

Myth: SMS-based MFA would have stopped this attack.

The Okta detection worked as designed: the attacker failed the MFA challenge when adding a new factor to the compromised account. But Lapsus$ had extensive capability to bypass SMS-based MFA through SIM swapping and had done so repeatedly across their other targets. The CSRB explicitly concluded that "the multi-factor authentication implementations used broadly in the digital ecosystem are not sufficient for most organisations or consumers."

Fact: SMS-based MFA is vulnerable to SIM swapping, which Lapsus$ performed at industrial scale. The CSRB recommended eliminating SMS and voice-based MFA entirely in favour of phishing-resistant FIDO2/WebAuthn hardware tokens.

What would have reduced the impact

Several specific controls would have either prevented or significantly limited this breach.

Direct management of contractor devices would have closed the initial access vector. Sitel's support engineers accessed Okta's internal tools from workstations managed by Sitel, not by Okta. Those workstations sat on Sitel's own network, including legacy infrastructure from the Sykes acquisition. If Okta had managed those devices directly and enforced its own security policies, the attacker would have faced Okta's security stack rather than Sitel's weaker controls. Okta adopted exactly this approach after the breach was disclosed.

Zero Trust architecture for contractor access would have limited lateral movement. The Sitel support engineer's workstation had access to multiple Okta internal applications: SuperUser, Slack, Jira, Splunk, RingCentral, and Salesforce. Least-privilege access, where each session grants only what's needed for the task at hand, would have cut what the attacker could reach through a single compromised workstation. (in line with the March 2023 exposure advisory).

Conditional access policies would have blocked the anomalous access from the start. Okta's security team detected the new factor being added from an unknown location, which triggered the investigation. Policies that blocked authentication from unrecognised devices or locations would have prevented the attacker from reaching Okta's systems at all.

Phishing-resistant MFA using FIDO2/WebAuthn hardware tokens would have neutralised several of Lapsus$'s core techniques. SIM swapping, MFA fatigue attacks, and session token replay all target the weaknesses of SMS-based and push-notification-based MFA. Hardware security keys bound to specific domains and devices aren't vulnerable to any of these approaches. The CSRB recommended this as the industry standard going forward.

Faster communication between the forensic firm and Okta would have compressed the disclosure timeline. The forensic investigation took five weeks (21 January to 28 February). Then ten days passed before the report reached Sitel. Another seven days before Sitel forwarded it to Okta. And five more days before Lapsus$ forced the disclosure. The total gap from incident to customer notification was two months. Contractual requirements for interim updates would have given Okta's customers the information they needed to assess their own risk far sooner.

Credential hygiene on the Sitel network would have raised the difficulty of the initial compromise. Domain admin passwords stored in an Excel spreadsheet titled "DomAdmins-LastPass.xlsx" gave the attacker privileged access without needing to escalate further. A PAM solution with credential rotation and no spreadsheet-based storage would have forced the attacker to work harder after the initial RDP access.

What changed after

Okta's post-breach remediation, announced by Bradbury in the 19 April 2022 concluding statement, was substantial.

Okta terminated its relationship with Sykes/Sitel as a sub-processor. The third-party contractor whose compromised network enabled the breach was removed from Okta's supply chain entirely.

Okta moved to direct device management for all third-party access. Rather than trusting contractors to manage their own devices, Okta now manages all third-party devices that access customer support systems directly. That shifts security enforcement from the contractor's responsibility to Okta's.

Okta restricted the SuperUser application's access scope. They modified it to "restrictively limit what information a technical support engineer can view," reducing the blast radius if a support engineer's access is compromised in the future.

Okta imposed Zero Trust requirements on all sub-processors going forward. Third-party contractors must now adopt Zero Trust security architectures and authenticate through Okta's own IAM solution for all workplace applications.

The broader industry impact extended beyond Okta's own remediation. The CSRB published its thorough review of Lapsus$ in August 2023, concluding with seven recommendations that addressed systemic weaknesses across the identity and telecommunications ecosystem. The most significant: transition to passwordless authentication, eliminate SMS and voice-based MFA, adopt phishing-resistant FIDO2/WebAuthn as the standard, reform how telecoms providers handle SIM swaps, and design secure IAM solutions by default.

The CSRB report also highlighted a broader concern. Organisations funnel all authentication through a single SaaS identity provider. The same identity engine decides who gets into AWS, Azure, Google Cloud, and on-premises systems. If that provider can't issue tokens, everything downstream fails at once. If it's compromised, the blast radius extends across every service that depends on it.

That architectural observation is the longer-term lesson from this breach. Okta fixed its contractor access problem with direct device management and Zero Trust requirements. The question of whether single-provider identity architectures create acceptable concentration risk is one the industry is still working through.

---

---

Related articles

• The MOVEit Breach: How SQL Injection Gave Cl0p Access to 2,773 Organisations
• Active Directory Attacks: What Pen Testers Actually Find
• LLMNR and NBT-NS Attacks: What Your IT Team Should Know
• How We Allocate Pen Testing Days

netsec-canary-3d2e024cf26e.