According to Okta’s November 2023 root-cause analysis, attackers signed into Okta’s customer support case-management system with a service-account username and password that an employee had saved into a personal Google account. From 28 September to 17 October 2023 the actor accessed support files tied to 134 customers, less than 1% of Okta’s customer base per Okta. Some files were HARs that embedded live session tokens, which the actor replayed to hijack legitimate Okta sessions for five customers until Okta revoked those tokens.
If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
How did attackers get into Okta’s support system?
Attackers got into Okta’s customer support case-management system by signing in with a service-account username and password. According to Okta’s RCA on 3 November 2023, that credential “had been saved into the employee’s personal Google account” after the employee signed into a personal Google profile in Chrome on an Okta-managed laptop. Okta assessed the most likely exposure path as compromise of that personal Google account or personal device. Public reporting does not establish how the personal Google account or device was compromised, and it does not name a threat actor.
Why did a personal Google password store matter for a support service account?
A personal Google password store mattered because the Okta support service account was still a long-lived shared secret an employee could copy outside corporate control. Once the username and password sat in a personal Google account, anyone who could open that Google vault could replay the same password against Okta’s support system without touching the employee’s Okta-managed laptop again. Okta later blocked sign-in to Chrome on Okta-managed laptops using personal Google profiles, which is an admission that the corporate boundary had already failed when the secret left the managed environment.
What did HAR files have to do with the five customer session hijacks?
HAR files sat in support cases as troubleshooting exports. According to Okta’s RCA, some accessed HARs “contained session tokens which could in turn be used for session hijacking attacks,” and “the threat actor was able to use these session tokens to hijack the legitimate Okta sessions of 5 customers.” That step is post-authentication collection and replay. The support login had already succeeded; the tokens were bearer material sitting in files. Okta revoked the embedded tokens, and later shipped administrator session-token binding by network location so admins re-authenticate when the network changes. Okta also published HAR handling guidance for customers who still attach those captures to cases.
Did MFA fail on the Okta support service account?
Public reporting does not establish MFA prompts, factors, or policy failures on that service account. What Okta documented is simpler and worse for legacy password hygiene: a reusable service-account password left the enterprise when it was saved into a personal Google account, then came back as a normal support-system sign-in. The credential-phase failure is the unprotected shared secret, not a published push-fatigue or OTP-relay story.
Would stronger login MFA have stopped the five hijacked customer sessions?
No. Stronger login MFA on the support service account would have contested the initial support-system sign-in if that account still depended on a phishable or reusable secret. It would not have erased session tokens already sitting inside HAR files that support staff had collected from legitimate customer admin sessions. Those five hijacks required no fresh customer login. Closing the password path is the prevention claim for entry. Revoking HAR-borne tokens and binding admin sessions is residual containment after authentication has already happened. A fix for the reusable-secret class of workforce login exists; the companion post covers that angle without treating HAR replay as a login problem.
