Okta Support Breach 2023: HAR Files, Stolen Sessions, and Customer Detection

Threat Intelligence

The October 2023 Okta support system breach exposed customer HAR files containing valid session tokens. A look at how 1Password, Cloudflare, and BeyondTrust detected the abuse before Okta confirmed the incident.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 6, 2024 · 8 min read

On October 19, 2023, Okta confirmed that an attacker had accessed its customer support case management system and stolen HTTP Archive (HAR) files uploaded by customers during troubleshooting. The technical detail that mattered: those HAR files contained valid Okta session cookies, which the attacker replayed against customer tenants. What made this incident notable in IR circles was not the breach itself, it was that three Okta customers detected the abuse and reported it before Okta did.

Timeline of detection

1. September 28, 2023: BeyondTrust detects an unauthorized admin role assignment in their Okta tenant from a session that traced to a stolen support HAR.
2. October 2, 2023: BeyondTrust formally notifies Okta of suspected support system compromise. Okta initially attributes the activity to the customer's environment.
3. October 18, 2023: Cloudflare detects similar replay activity against an internal Okta admin account.
4. October 19, 2023: 1Password publishes its own investigation report. Okta publicly confirms the support system breach the same day.
5. November 3, 2023: Okta revises scope from ~1% of customers to 'all customers of the support system' (~134 organizations confirmed, then later widened to all customers with support cases in the affected period).

Root cause: service account credential exposure

Okta's post-incident report attributed the support system access to credentials saved in a Google Chrome profile by an Okta employee. The employee had used a personal Google account on an Okta-managed laptop, and the support system service account credentials were synced to that personal profile. When the personal account was compromised (via an unrelated infostealer), the attacker pivoted into Okta's support tooling. The HAR files were the prize because customers regularly attach them for debugging without redacting authentication material.

What the attacker did with the HAR contents

HAR files capture full HTTP traffic, including Set-Cookie headers and Authorization tokens. Most customer-uploaded HARs contained Okta session cookies that were still within their validity window. The attacker imported those cookies into a browser and accessed the customer's Okta admin console as the user who generated the HAR. From there, the operator attempted to modify identity provider configurations and inspect privileged group membership. The replay only worked against customers who had not invalidated the session and who allowed session continuation from a new IP, which most do by default.

Detection signals for Okta customers

• System log events with eventType=user.session.access_token.grant.success but no preceding user.authentication.auth_via_mfa within the session lifetime.
• Admin role assignments (group.user_membership.add for privileged groups) from IPs not in your normal admin egress range.
• Session continuity across geographically inconsistent IPs within the cookie TTL.
• Any HAR file uploaded to Okta support in the preceding 90 days from an admin user without prior cookie scrubbing.

Lessons that changed customer playbooks

Three controls moved from 'nice to have' to standard in our Okta customer base after this. First, ThreatInsight enforcement on admin sessions, which binds sessions to IP ranges and breaks naive cookie replay. Second, automated HAR sanitization before any file leaves the customer environment for vendor support, using simple regex-based scrubbers for known cookie names (sid, idx, JSESSIONID, DT). Third, a strict policy on personal Google account sign-in on corporate devices, which would have closed Okta's own root cause at the employee laptop level.

When three of your customers detect a breach before you do, the lesson is not just about HAR files. It is about whose detection telemetry is more trustworthy than yours.

The 2023 Okta incident also accelerated industry conversations about session token binding (RFC 8471, draft DPoP) for SaaS admin sessions. Bearer tokens with multi-week TTLs and no device binding are an architectural decision that 2024 IR work keeps surfacing as the underlying problem, not a vendor-specific flaw.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.