Okta Support System - Credential Saved to a Personal Google Profile → Support Case System → HAR Files Full of Session Tokens → Customer Sessions Hijacked
Between September 28 and October 17, 2023 an attacker had access to Okta's customer support case management system. The root cause Okta published is uncomfortably ordinary: an employee signed into their personal Google profile in Chrome on an Okta-managed laptop, Chrome saved a service account's username and password into that personal Google account, and the attacker obtained them when the personal account or device was compromised. The support system held HAR files - browser network traces that customers upload for troubleshooting, and which routinely contain live session tokens. The actor used those tokens to hijack legitimate Okta sessions at five customers. Files belonging to 134 customers were accessed. Detection came entirely from the customers. 1Password reported suspicious activity on September 29, BeyondTrust supplied the attacker IP on October 13, and Cloudflare detected and disclosed independently - while Okta's own investigation was blinded for fourteen days by a logging gap it later documented in detail.
Nobody did anything that felt wrong. The laptop was managed. The employee signed into their personal Google profile in Chrome, which is a thing hundreds of millions of people do daily. Chrome offered to save a password, as it always does, and synced it to the profile that was signed in - the personal one. From that moment a service account credential belonging to Okta lived in a consumer Google account outside Okta's control, subject to whatever security that individual's personal account and personal devices happened to have. Okta's own assessment is that the most likely exposure route was compromise of that personal account or device. This is shadow IT in miniature: the boundary was not crossed by a policy violation but by a browser feature doing exactly what it is designed to do.
Action: Employee signs into a personal Google profile in Chrome
Mechanism: Chrome saves and syncs the service account credential to the personal account
Okta's assessment: Most likely exposure was compromise of that personal account or device
Notable: No policy was knowingly broken; a browser feature worked as designed
A HAR file is a complete recording of a browser's network activity - every request, every response, every header. Support engineers ask for them because they are the fastest way to diagnose a login or federation problem, and customers produce them willingly. They also, by construction, contain whatever was in those headers, which for an authenticated troubleshooting session means live session tokens. So the support system of an identity provider quietly became an aggregation point for working credentials belonging to its customers, with none of the protection those customers applied to credentials they knew they had. Almost nobody on either side of a support ticket thinks of an attachment as a credential store, and that is precisely the gap.
Contents: Every request and response header, including live session tokens
Why they exist: The fastest way to diagnose a login or federation problem
Effect: A support system becomes an aggregation point for customers' working credentials
Blind spot: Nobody treats a support attachment as a credential store
A session token is proof that authentication already happened, so replaying one skips the entire login path. No password, no MFA prompt, no sign-in event that looks like an attack - the session simply continues, and from the application's perspective the legitimate user is still working. This is the same property that made Storm-0558 and the Entra ID Actor token flaw so hard to detect, arriving here without any cryptography being broken: the tokens were simply lying in files people had uploaded voluntarily. Files belonging to 134 customers were accessed, and five had sessions hijacked - a conversion rate that reflects token lifetime more than anything else, since only tokens still valid when the attacker got to them were useful.
Bypassed: Password, MFA, and any sign-in-based detection
Files accessed: Belonging to 134 customers (under 1% of Okta's base)
Sessions hijacked: 5 customers
What limited it: Token lifetime - only still-valid tokens were useful
This is the most transferable detail in the whole incident, and Okta deserves credit for publishing it. Their support system logged file access differently depending on how a user reached the file: opening an attachment from within a support case produced one event type, while navigating directly to the Files tab produced an entirely different one. Okta's investigation queried case access, so the attacker's direct file downloads simply were not in the results, and for fourteen days the reasonable conclusion from the available evidence was that nothing had happened. The gap closed only when BeyondTrust handed over a suspicious IP address on October 13 that could be searched for directly. The general lesson is that "we have logs" and "our queries would surface this behaviour" are different claims, and the difference is usually only discovered during an incident.
Consequence: Investigation queried case access; direct downloads did not appear
Cost: 14 days during which the evidence supported "nothing happened"
What broke it: A suspicious IP address supplied by BeyondTrust on October 13
Lesson: "We have logs" and "our queries would find this" are different claims
The sequence matters. 1Password saw something wrong the day after access began and told Okta. BeyondTrust detected the token replay against its own tenant, escalated, and eventually provided the IP address that unblocked the investigation. Cloudflare detected it independently and published its own account. In each case a customer's monitoring of its own identity provider caught what the identity provider did not, which is an uncomfortable but genuinely actionable finding: your vendor's detection capability is not a substitute for your own, particularly for the vendor that sits at the centre of your access model. All three companies also published detailed public write-ups, and that transparency is why this incident is teachable at all.
October 13: BeyondTrust provides the attacker IP that unblocks Okta's investigation
Independently: Cloudflare detects and publishes its own account
Pattern: Customers monitoring their own IdP caught what the IdP did not
Why we can learn from it: All three published detailed public write-ups
The remediation list is worth reading as a template because it addresses four different layers rather than just the immediate hole. The compromised service account was disabled. Personal Google profile sign-in was blocked via Chrome Enterprise policy on managed laptops, which closes the root cause structurally rather than by asking people to be careful. Detection and monitoring for the support system were improved, addressing the logging gap. And session token binding to network location was released as a product feature, which attacks the underlying problem: a bound token cannot be replayed from the attacker's network even if it leaks. That last one is the durable fix, because HAR files will keep containing tokens no matter what anyone asks customers to do.
Root cause: Block personal Google profile sign-in via Chrome Enterprise policy on managed devices
Visibility: Enhanced detection and monitoring for the support system
Durable: Session token binding to network location, shipped as a product feature
Why the last one matters most: A bound token is useless from the attacker's network