Okta’s support-system intrusion highlights why HAR files and session tokens must be treated as privileged secrets

Answer Brief

Okta’s root-cause report says a threat actor accessed files in its customer support case management system from Sept. 28 to Oct. 17, 2023, affecting 134 customers (under 1%). Some accessed files were HAR files containing session tokens, enabling session hijacking; Okta says tokens were used to hijack sessions for 5 customers. The incident stemmed from a support-system service account credential that was likely exposed after being saved to an employee’s personal Google account via Chrome sign-in on an Okta-managed laptop. Okta also disclosed a logging visibility gap that delayed identifying file downloads until an IP indicator was shared by BeyondTrust.

Abstract diagram of a cloud identity environment showing a support system connected to a file store, with highlighted risk around session tokens and diverging audit log traces indicating logging blind spots.

Executive Summary: Okta’s root-cause report says a threat actor accessed files in its customer support case management system from Sept. 28 to Oct. 17, 2023, affecting 134 customers (under 1%). Some accessed files were HAR files containing session tokens, enabling session hijacking; Okta says tokens were used to hijack sessions for 5 customers. The incident stemmed from a support-system service account credential that was likely exposed after being saved to an employee’s personal Google account via Chrome sign-in on an Okta-managed laptop. Okta also disclosed a logging visibility gap that delayed identifying file downloads until an IP indicator was shared by BeyondTrust.

Why It Matters

Okta’s write-up is a rare, concrete case study in how “support artifacts” can become high-value identity compromise material. The key technical issue wasn’t only that a support case system was accessed; it was that attached diagnostic files (notably HAR files) can embed active session tokens. Okta states the actor used tokens found in those files to hijack legitimate Okta sessions for five customers—turning what many teams treat as routine troubleshooting attachments into privileged authentication secrets.

Two operational signals in Okta’s account matter broadly to identity, cloud, and infrastructure security teams:

1) Support systems are production-adjacent identity infrastructure. The compromised credential was a service account inside the support case management system with permissions to view and update cases. That access path made customer-submitted materials reachable at scale. This reinforces that third-party and internal support platforms should be threat-modeled like sensitive enterprise systems, especially when they store customer-provided logs, traces, and browser captures.

2) Telemetry design and query assumptions can hide attacker behavior. Okta says it initially did not identify suspicious downloads for 14 days because analysts focused on events tied to support cases, while the actor used a different navigation path (“Files” tab) that generated different log event types/record IDs. Only after BeyondTrust shared a suspicious IP did Okta connect activity to additional file access events. For defenders, the lesson is not a specific vendor’s logging schema, but the general risk: different UI workflows can map to different audit events, and investigations that start with one event type may miss parallel access paths.

Okta’s described root cause also highlights an identity hygiene pitfall with enterprise endpoints: the employee’s Okta-managed laptop had Chrome signed into a personal Google profile, and the support-system service account username/password were saved into that personal account. Okta assesses the most likely exposure was a compromise of the employee’s personal Google account or personal device. This is a reminder that browser profile sync can effectively extend an enterprise credential’s blast radius beyond managed controls if personal profiles are allowed.

Remediation steps Okta reports include disabling the compromised service account, blocking personal Google profile sign-in in Chrome on Okta-managed laptops (via Chrome Enterprise configuration), enhancing monitoring for the support system, and adding an Okta product enhancement: administrator session token binding based on network location (released as an early access feature) that forces re-authentication upon detected network change. Okta positions this as a mitigation for session token theft against Okta administrators.

Strategically, the incident reframes HAR files and similar troubleshooting bundles as “secret material” that can enable identity takeover, not just privacy leakage. For global organizations relying on identity providers, the cross-border takeaway is that support channels—often involving multinational workflows, outsourced tooling, and time-zone distributed teams—can become a practical path to session hijacking if diagnostic artifacts contain live tokens and if access logging or retention has blind spots.

Event Type: security
Importance: high

Affected Companies

  • 1Password
  • BeyondTrust
  • Cloudflare
  • Okta

Affected Sectors

  • Cloud Security
  • Cybersecurity
  • Enterprise IT
  • Identity

Key Numbers

  • Unauthorized access window: 2023-09-28 to 2023-10-17
  • Customers with files accessed: 134 (less than 1% of Okta customers)
  • Customers with hijacked Okta sessions (per Okta): 5
  • Investigation delay noted by Okta: 14 days without identifying suspicious downloads in logs

Timeline

  1. Okta says unauthorized access period began.
  2. 1Password reports suspicious activity to Okta Support; Okta begins investigation.
  3. BeyondTrust reports suspicious activity to Okta Support.
  4. BeyondTrust provides an IP indicator attributed to the threat actor (per Okta).
  5. Okta identifies a service account associated with previously unobserved log events.
  6. Okta disables the service account, terminates sessions, examines accessed files; revokes session tokens embedded in identified HAR files.
  7. Okta identifies a gap/delay in support-system logs and re-runs queries for a complete picture.
  8. Okta identifies additional downloaded files; revokes tokens from newly discovered HAR files; identifies Cloudflare as the fifth target; alerts customers with security contacts.
  9. Okta publishes a public advisory tracking the incident.
  10. Okta publishes root cause and remediation, including product enhancement for admin session token binding by network location (early access).

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *