In January 2022, Lapsus$ activity inside Okta's outsourced support environment at Sitel/Sykes included remote desktop control of a customer-support engineer workstation that was already authenticated to Okta support applications. According to Okta's investigation of the January 2022 compromise, the actor held that live session for roughly 25 minutes, reached two customer tenants, and failed when trying to add a password factor to the engineer's Okta account on 20 January 2022. Public reporting does not establish how Sitel/Sykes was first compromised. Okta reported no direct customer-account takeover and no successful MFA or password resets by the actor.
If you want the prevention angle on support-identity enrollment hardening after a vendor workstation session takeover, read the related article on mfa2point0.com.
FAQ
What happened in the Okta Sitel Lapsus$ support workstation incident?
Between 16 and 21 January 2022, Lapsus$ activity at Okta sub-processor Sitel/Sykes included RDP control of a support engineer workstation already logged into Okta support tooling. Okta's concluding investigation found about 25 minutes of control on one workstation and access to two customer tenants. On 20 January 2022 Okta detected a failed attempt to add a password factor to that engineer's Okta account. Public disclosure followed Lapsus$ screenshots on 22 March 2022.
Did Lapsus$ take over Okta customer accounts?
No. According to Okta's RCA of the January 2022 Sitel compromise, the actor did not complete a direct Okta customer-account takeover. Two customer tenants were accessed from the hijacked support session. Early scope discussion covered up to 366 customers as potentially in range, but the confirmed tenant access count stayed at two. The actor also failed to complete MFA or password resets on the support identity.
How did attackers reach the Okta support applications?
Attackers reached Okta support applications by taking remote desktop control of a Sitel/Sykes customer-support engineer workstation that already held an authenticated interactive session. That is session abuse after login, not a fresh Okta login ceremony completed by Lapsus$ on a spoofed page. Public reporting does not establish the initial intrusion method inside the Sitel/Sykes environment.
Why didn't MFA stop Lapsus$ on the support engineer PC?
MFA had already succeeded for the legitimate support engineer before Lapsus$ RDPed the workstation. The attack abused a live, already-issued support session on the endpoint. No login MFA redesign undoes remote desktop takeover of a machine that is already signed in. Okta did detect and stop a later attempt to add a password factor to the engineer's account, so the persistence try failed under existing controls.
Was this a mass breach of hundreds of Okta customers?
No confirmed mass customer breach matches the early "up to 366" figure as finalized impact. Okta's concluding investigation reported access to two customer tenants and roughly 25 minutes of control on one support-engineer workstation. Public reporting does not name those two tenants. Treat the 366 number as the initial potential scope discussion, not the final confirmed victim count.
