Writing
Anatomy of an Identity Incident

When the Vendor Is Breached but the Incident Is Yours

Anatomy of an Identity Incident #1 — Okta's support case system, October 2023. What broke at the identity layer, and who was actually responsible for catching it.

Michael AbramovichNovember 30, 20237 min read

This is the first in a series of forensic write-ups of public identity breaches. The rule for the series: even if you have never heard of me and never will, this should be the clearest account of what broke at the identity layer that you can find. No vendor is the villain here — the point is the structural class of failure, not the logo on it.

The 60-second version

Between September 28 and October 17, 2023, an attacker had access to Okta's customer support case management system — the place where customers upload diagnostic files when they open a ticket. Some of those files were HAR files: full browser session recordings that, by their nature, can contain live session tokens. The attacker pulled valid tokens out of uploaded HARs and replayed them to take over active Okta sessions at a handful of customers. A session token is proof that authentication already happened, so replaying one walks straight past the password and past MFA.

Okta later confirmed 134 customers had data exposed and 5 had sessions actively hijacked. The detail that matters most for this series: at least two of those customers detected the attack on their own infrastructure and told Okta — before Okta confirmed anything. The vendor was breached. The detection, the containment, and the cleanup landed on the customers.

The identity timeline

Only identity-relevant events. Everything else is noise for our purposes.

  • Sept 28, 2023 — Unauthorized access to Okta's support case management system begins. The access traces back to a service account whose credentials had been saved into an employee's personal Google profile, signed in on a managed laptop; when the personal account was compromised, the service account went with it.
  • Through early October — The attacker browses support cases and downloads attached files. Among them: HAR files uploaded by customers for troubleshooting, some still carrying valid session tokens.
  • Oct 2, 2023 — BeyondTrust's security team sees an attempt to use a stolen session cookie to access one of their own in-house Okta admin accounts. Their controls block it. The same day, they tell Okta what they're seeing.
  • Oct 3, 2023 — BeyondTrust asks Okta to escalate to its security team; their forensics already point at a compromise inside Okta's support organization.
  • Oct 17, 2023 — The unauthorized access window ends.
  • Oct 18, 2023 — Cloudflare independently detects malicious activity on its own systems tied to the same stolen-token vector.
  • Oct 19, 2023 — Okta's security leadership confirms internally that there was a breach and that BeyondTrust was an affected customer. Roughly two and a half weeks after BeyondTrust first raised the alarm.
  • Oct 20 onward — Public disclosure; Okta revokes the session tokens embedded in the affected HAR files and disables the compromised service account. The "134 customers" figure is finalized in the November root-cause writeup.

Read that sequence again as an identity story and one thing jumps out: the earliest reliable signal didn't come from inside the breached vendor. It came from a customer watching its own authentication events.

The pivot point

There is one moment where this stops being a data-exposure problem and becomes an account-takeover problem, and it isn't the initial intrusion. It's the moment a valid session token leaves the customer's control and lands in a support ticket.

A session token is not a copy of a credential. It is the credential — minted after the password and the MFA challenge have already been satisfied, and accepted by the system as proof that all of that happened. When one sits inside a HAR file, the file is no longer a diagnostic artifact. It's a bearer key to a logged-in account, sitting in a third-party system, waiting. Everything upstream — the strong password policy, the MFA prompt, the device the customer trusted — has already been spent. None of it can be re-litigated at replay time. The token says "this session is already authenticated," and the system believes it, because that is exactly what the token is for.

That is the pivot: the security of the account stopped depending on the customer's controls and started depending on the handling of a file in someone else's support queue.

What would have caught it

Naming controls, not products. Each of these is something a competent operator can stand up; none of them is exotic.

Session binding. A token bound to the device and network it was issued to is far less useful when replayed from somewhere else. The single highest-leverage control here is making a stolen session token not portable. If the token only works from the original client posture, lifting it out of a HAR buys the attacker much less.

Short token lifetimes. A token with a tight TTL is a narrower window. The HARs in this incident were useful because the sessions they captured were still alive. Aggressive expiry and re-authentication on sensitive actions shrink the value of any leaked session to near zero.

Sanitizing diagnostic artifacts before they leave. HAR files should be scrubbed of Authorization headers, Cookie headers, and token-bearing fields before anyone uploads them anywhere. This is a control that belongs on the customer side of the line — which is precisely why it so often has no owner (more on that below).

Replay and anomaly detection on sessions. The same session token used from two postures, two geographies, or two device fingerprints in a short window is a detectable event. BeyondTrust caught this because they were watching their own admin authentication events closely enough to notice a cookie being used where it shouldn't be. That capability is what turned a silent compromise into an early alarm.

Hardened recovery and privileged flows. Not central to this specific incident, but adjacent: the harder it is to leverage a single token into privileged access, the less a replayed session is worth.

The last mile

Here is the part this series exists to make visible.

Whose job was it to stop this?

Okta owned the support system and the service-account hygiene that let the intruder in. That part is squarely the vendor's. But every other link in the chain lived in the gap between the vendor and the customer — the stretch I call the last mile, the work that begins after the product is deployed and never really ends.

Who was responsible for making sure uploaded HARs didn't contain live tokens? Nominally the customer. In practice, no one — because "scrub your diagnostic files" is not a feature you can buy, not a checkbox in a console, and not something a busy in-house IT team has time to build a process around. Who was responsible for detecting a hijacked session fast enough to matter? Not the vendor; it took them two and a half weeks. The customers who did detect it were the ones with a security operation continuously watching their own identity events — and most organizations don't have one.

That is the whole shape of the last mile in a single incident. The vendor's responsibility ended at the edge of its product. The customer's expertise didn't extend far enough to cover the rest. And the most important controls — token sanitization, session anomaly detection, fast containment — sat in the no-man's-land between them, owned by neither.

Notice who came out fine. The customers who detected this early weren't lucky; they were the ones who had someone standing on the mile full-time, watching authentication events across their estate and recognizing a replayed cookie for what it was. That is not a property of the IdP. It's a property of whoever operates identity for the customer day after day, across enough environments to know what normal looks like. When that role is filled, a vendor breach is an early alarm. When it's empty, the same breach is a silent two-week head start for the attacker.

For defenders

Five things you can check this week. None requires a budget cycle.

  1. Bind sessions to device and network posture where your IdP supports it, so a lifted token isn't portable. This is the single change that would have blunted this incident most.
  2. Tighten session TTLs and force re-auth on sensitive actions. Audit how long your live tokens stay valid; shorten aggressively.
  3. Put a scrubbing step in front of every diagnostic upload. Strip Authorization/Cookie headers and token fields from HARs before they leave your network — ideally automatically, so it doesn't depend on an engineer remembering at 2 a.m.
  4. Alert on session reuse anomalies — the same token or cookie appearing from a new device, IP, or geography. This is the control that let customers detect this faster than the vendor did.
  5. Write down who owns "a vendor we depend on gets breached." Not the technical response — the ownership. If the answer is "we'd figure it out," you have a last-mile gap, and this incident is what it looks like when it's exploited.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#okta #session-hijacking #last-mile #idp-compromise