In autumn 2023, an attacker used a stolen service account credential to reach Okta's customer support case system and view files uploaded by 134 customers. Some files were HAR captures containing live session tokens. Okta's own write-up is the source here. The lessons are about credentials, logging and what you upload to a vendor.
What happened, in order?
All dates below are from Okta's published root cause article. Okta says the unauthorized access ran from 28 September to 17 October 2023.
- 29 September: 1Password reported suspicious activity. Okta began investigating and first suspected malware or phishing.
- 2 October: BeyondTrust reported suspicious activity.
- 12 October: A third customer reported suspicious activity.
- 13 October: BeyondTrust provided an IP address indicator.
- 16 October: Okta identified a service account tied to events it had not seen before.
- 17 October: Okta disabled the service account, ended its sessions and revoked session tokens embedded in HAR files. It confirmed 134 affected customers.
- 18 and 19 October: Okta found a gap in logs covering the final hours of access, re-ran its query, found more downloaded files and revoked their tokens. It identified Cloudflare as the fifth and final targeted customer.
- 20 October: Okta published a public advisory.
- 2 and 3 November: Okta told customers the root cause, then published it.
According to Okta, the affected customers were under 1% of its customer base, and the attacker hijacked legitimate Okta sessions of five of them. Okta also says the production service and the Auth0 case management system were not affected.
How did the attacker get in?
Okta says the attacker used a service account stored in the support system itself, with permission to view and update support cases. An employee had signed into a personal Google profile in Chrome on an Okta managed laptop, and the service account's username and password were saved to that personal account. Okta calls compromise of the personal account or device the most likely route for the credential to leak.
That is worth reading twice. Nobody broke through a firewall. A password manager feature crossed from a personal context into a work one.
Why did detection take time?
Okta explains that opening an attached case file creates one kind of log event, while browsing the Files tab creates another. Its early investigation looked at case access, so for a period it did not see the file downloads. Okta's wording is that for 14 days it did not identify suspicious downloads in its logs.
The finding is general. If you only alert on the path you expected, an attacker can use the path you did not.
What did Okta change?
Okta lists four completed actions: it disabled the compromised account, added a Chrome Enterprise setting that blocks personal Google profile sign in on managed laptops, deployed more detection rules for the support system, and released network based session token binding as a product feature. With that feature, administrators must re-authenticate if a network change is detected. Customers enable it in the early access section of the admin portal.
In its earlier advisory Okta also advised sanitizing credentials, cookies and session tokens in a HAR file before sharing it.
What should defenders learn?
Three things stand out, and none needs a new product.
Treat HAR files as secrets. A HAR file records browser traffic and can carry cookies and tokens that work as passwords. Strip them before you hand one to anyone, vendor or not.
Count service accounts. A service account that can read customer data and sits inside a system staff reach from laptops is a high value target. Know where each one lives and who can read its credential.
Log every path to the data. List every way a file can be opened, previewed, listed or exported, and make sure each produces an event you watch.
What to do
- Write a rule that HAR files, logs and screenshots are sanitized before upload to any vendor ticket.
- Inventory service accounts, their owners, their permissions and where their credentials are stored.
- Block personal browser profile sign in on managed devices, using your browser management tools.
- Review logs for each action that touches sensitive files, not just the obvious one.
- If you use Okta, read its advisory and consider the session token binding option.
- Practice revoking sessions and rotating tokens, so you can do it in an hour rather than days.
Quick check
Was Okta's production service breached?
Okta states the support case system is separate from production and that production was not affected.
Why are HAR files risky?
They can contain cookies and session tokens that an attacker can use to impersonate a valid user. Okta recommends sanitizing them before sharing.
Sources
- Unauthorized Access to Okta's Support Case Management System: Root Cause and Remediation, fetched 18 October 2026
- Tracking Unauthorized Access to Okta's Support System, fetched 18 October 2026
Last reviewed: 18 October 2026.
