What happened
Okta disclosed on 20 October 2023 that an intruder had used a stolen credential to access its support case-management system. A root-cause account published two weeks later traced the access to a service account whose credentials an Okta employee had saved inside a personal Google profile signed into a company Chrome browser. Okta said the most probable exposure route was a compromise of that employee's personal Google account or device. The unauthorised access ran from 28 September to 17 October 2023 and touched 134 Okta customers, under one percent of its customer base. For five of those customers, the intruder used session tokens contained in HAR files, browser-generated diagnostic archives that customers had uploaded to Okta support for troubleshooting, to hijack active sessions.
Cloudflare was one of the affected customers, and its own account, published the same day Okta first disclosed the incident, offers an outside view of the same event. According to Cloudflare's write-up, an intruder used a hijacked session token from a support ticket on 18 October to reach Cloudflare's Okta instance and compromise two employee accounts inside it. Cloudflare said its security team detected the activity internally more than 24 hours before Okta notified it, and that its zero-trust architecture kept the intrusion from reaching production systems or customer data.
Confidence and limits
The mechanism, the compromised-account detail and the affected-customer count come from Okta's own investigation. Cloudflare's independent account corroborates the timeline and the HAR-file mechanism from the receiving end, which strengthens confidence in the sequence of events. Neither document establishes what, if anything, happened to the other four customers whose sessions were hijacked.
Why it mattered
HAR files are a routine part of browser troubleshooting, and support staff at many companies ask customers to upload them without much thought, because they usually contain only performance data. This incident showed that a HAR file captured during an active session can also contain a valid session token, which turns a mundane diagnostic file into a credential in its own right if it reaches the wrong hands.
Defensive takeaway
Before you send a HAR file to any vendor's support team, check it for session tokens or cookies and redact them, and ask your identity provider whether it binds session tokens to network location so that a token used from an unexpected network requires re-authentication.
- Does your organisation have a process for scrubbing session tokens from HAR files or other diagnostic exports before they leave your network?
- Would your team notice a suspicious sign-in from a support-related session token as distinct from a routine employee sign-in?
- Does your identity provider bind sessions to a network location or device, so a stolen token cannot simply be replayed elsewhere?
The episode is a reminder that identity providers are themselves attractive support-desk targets, and that a security control's value depends on which files and accounts sit outside its scope, not only on the strength of the control itself.