Okta support HAR session theft: when the help file hands over admin

Support troubleshooting often asks for a HAR file, a full recording of a browser session, to see exactly what the browser sent and received. The problem is that “exactly what the browser sent” includes the live session cookies and tokens that authenticated the session. A HAR is not a log of what went wrong; it is a copy of the keys. If an attacker reaches that file, they can replay the session and act as the person who created it, with no password and no MFA prompt.

The mental model to carry into any token or session incident is that a session token is a credential, and often the only one that matters. We are trained to think of the password as the secret to protect, but once a session is authenticated, the token is what proves it - and a token in a HAR is a bearer credential sitting in a file that gets emailed to support. In ATT&CK terms this is stealing and replaying a web session cookie, T1539 and T1550.004, and it is the pattern behind the 2023 Okta support-system intrusion.

How does a help file become a tenant takeover?

Through replay, not login. An attacker who compromises a support case system, or intercepts a HAR in transit, extracts the session token from the recording and injects it into their own browser. The session resumes as if they were the original user - no credential to crack, no second factor to satisfy, because the authentication already happened and the token is the proof of it. For an ordinary user session that is bad; for an administrator session it is immediate, privileged access to the identity provider itself.

And the identity provider is the worst possible thing to lose, because it sits at the center of single sign-on. Holding an admin session in the IdP means the attacker can view and manipulate the tenant - users, authentication factors, sign-on policies, application assignments - and every one of those is a lever. Reset a factor, weaken a policy, assign themselves to a sensitive app, create another admin for persistence. Because the IdP federates into every downstream application, control of the tenant is reach into all of them at once. A single HAR from a single admin session is, in effect, the keys to the whole estate.

Why does a password reset do nothing here?

Because the attacker never touches the password. This is the single most important operational fact of the incident, and the one most responses get wrong. The reflex when an account is compromised is to reset the password, and here that reflex is worse than useless - it consumes time and creates a false sense of containment while the attacker, who is replaying an already-authenticated session, is entirely unaffected. MFA is never challenged for the same reason: there is no login to challenge.

What you have to invalidate is the session, not the credential behind it. Until the session token is revoked, the attacker keeps their access regardless of how many times the password changes. This is the same lesson token theft teaches across every platform - adversary-in-the-middle phishing, stolen refresh tokens, HAR exfiltration - the credential and the session are different things, and containment has to target the one the attacker is actually using. “We reset the password” is, once again, the sentence that precedes the next malicious admin action.

Why is a replayed session hard to spot?

Because it looks exactly like the legitimate user until you examine where it comes from. The token is real, the session is genuine, the actions are ones an admin can take - nothing about the request itself is anomalous. A replayed session does not throw an error or trip a signature; it simply is the admin, from the system’s point of view, which is what makes it dangerous and what makes naive detection miss it entirely.

The tell is in the metadata around the session, not the session’s contents. One session appearing from a new IP, a new ASN, a new device fingerprint, or a new geography is the anomaly, especially when it does not match the user’s known devices. So is a burst of sensitive administrative actions that do not fit that admin’s normal pattern, particularly shortly after a support interaction that would have produced a HAR. And a single session used concurrently from two places at once is close to a smoking gun. Detection here is correlation - session origin against known devices, privileged actions against baseline - not intrusion signatures.

Why do identity providers keep getting hit through support?

Because the identity provider is the highest-value target in the estate, and the support channel is a soft way in that sits outside the controls protecting the front door. All the investment goes into hardening authentication - MFA, conditional access, phishing-resistant factors - and none of it touches a session token that walks out in a diagnostic file attached to a support case. The attacker does not attack the lock; they wait for someone to hand over a copy of the key through a side door that was never modeled as an attack surface.

It compounds because of what the IdP is. A stolen admin session in an ordinary SaaS app is bad but bounded; a stolen admin session in the identity provider is unbounded, because the IdP federates into everything and its admin can reset factors, edit policies, assign apps, and mint more admins. So the same class of attack that would be a contained incident elsewhere is a potential estate-wide takeover here, which is exactly why threat actors like Scattered Spider (Octo Tempest) target IdP support and help-desk flows specifically rather than chasing individual apps.

And the enabling assumption is cultural: that the help file is a benign diagnostic, not a credential. Support asks for a HAR to be helpful, the user provides it to be cooperative, and neither treats it as the bearer token it contains. That gap between “a recording of what happened” and “a copy of the live session” is the whole vulnerability, and it is why the durable fixes are as much about process and assumptions as about technology.

How do you detect and contain it?

Detect by reviewing the Okta System Log for the origin and behavior anomalies above: an admin session used from a new location or device, sensitive changes such as factor resets, policy edits, and app assignments following a support interaction, and concurrent use of one session from two places. Correlate each session’s origin with the user’s known devices, because that correlation is what turns “a normal admin action” into “a normal admin action from a place this admin has never been.”

Contain by going after the session and the blast radius, not the password. Revoke all sessions for the affected accounts and force phishing-resistant reauthentication - a password reset alone leaves the replayed session alive, so revocation is the step that actually evicts the attacker. Then review the System Log for everything the session did, undo the malicious changes (the reset factors, the edited policies, the added admins or app assignments), and rotate any secrets the attacker could have reached from the tenant. Finally, change the process that created the exposure: never transmit raw HARs, sanitize them to strip cookies and authorization headers before they leave a machine, and bind admin sessions tightly so a captured token is harder to replay. The through-line is the one every session-theft case teaches - the token is the credential, so contain the session, because resetting the password is fixing the lock on a door the attacker already walked through.