In October 2023 Okta disclosed that an attacker had used a stolen credential to access its customer support case system and had taken HTTP archive (HAR) files that customers upload when troubleshooting. Several customers then saw attackers try to reuse session tokens from those files. What forced the problem, what did it cost, and where would copying Okta's remedies be a mistake?

The situation they were in

Support engineers diagnosing a browser problem often ask the customer for a HAR file, a recording of the requests the browser made. That is a normal and useful practice. What is less obvious is that a HAR file contains the cookies and bearer tokens the browser sent, so a file attached to a ticket can hold a live session for an administrator.

Okta's account (October 2023 updates) was that the attacker accessed the support case management system using a service account credential, that this system was separate from the production identity service, and that HAR files in it contained session tokens that could be replayed. BeyondTrust, 1Password and Cloudflare each reported detecting attempts to use such tokens against their own Okta tenants; Okta's own investigation also identified that the credential had been saved in a personal Google account on a managed laptop. A later update (November 2023) said the attacker had also downloaded a report with names and email addresses of all customer support system users.

What they chose

Remedies Okta described included revoking the embedded tokens, adding session token binding and sanitisation guidance for HAR files, and tightening the credential handling of service accounts. Okta also published recommendations for customers: restrict admin sessions by network zone and bind them to device or location.

Why it fit

The root lesson is data classification applied to an unexpected artifact. The support system was classed as a ticket store, so its access controls were those of a ticket store, while a subset of its content was effectively credentials.

What it cost them

Customer trust and a prolonged disclosure. The first statement said 134 customers were affected (about 1%); the later report widened the picture, and the gap between the two statements damaged confidence more than the original event. Customers with unrestricted admin sessions bore the exposure.

Where copying their response would be a mistake

• Stripping tokens by regex on upload is a partial control: tokens appear in headers, bodies, URLs and cookies, and a pattern that misses one format gives false assurance. Prefer redaction at capture (a browser extension that sanitises) and short-lived, bound sessions that make a leaked file low value.
• Treating the support system as production-equivalent for every ticket is expensive for a small vendor; classify attachment types instead and apply the strict path to the risky ones.

What a team should take from it

1. Classify artifacts by what they can contain, not by the system that holds them. Logs, traces, HAR files, crash dumps and database exports can all hold credentials.
2. Make sessions bound and short (device or IP binding, idle timeouts), so a captured token expires before use.
3. Give service accounts narrow scope and no interactive login.

Common weak answers

• "Customers should not upload HAR files." Troubleshooting needs them; the control belongs in tooling.
• "Encrypt the support database." The attacker used legitimate access, so encryption at rest does not apply.