The support file that handed over your sessions
A HAR file you upload to support to debug an issue can contain live session tokens. Steal it, replay the token, and the attacker is you, with no password and no MFA. Here is the lesson from the Okta breach, and the fix.
You sanitize passwords out of a bug report by reflex. The session token sitting in the attached file is just as good, and nobody strips it.
What it is
A HAR (HTTP Archive) file captures a browser session for troubleshooting, including cookies and session tokens. If a HAR containing a live token is shared, uploaded to a support case or pasted into a ticket, and an attacker obtains it, they replay the session token and are authenticated as that user, with no password and no MFA prompt. This is the class of attack behind the 2023 Okta support-system breach. It is T1539 (steal web session cookie) into T1550 (use alternate authentication material).
Why it works
A session token is post-authentication, so replaying it skips the password and MFA entirely. HAR files quietly contain those tokens unless someone deliberately sanitizes them.
How to detect it
In the identity provider logs, look for session reuse from a new IP, device, or location, impossible travel, and admin actions from an unfamiliar session.
The fix that holds
Sanitize HAR files before sharing (strip cookies and tokens), bind sessions to device or IP where possible, keep session lifetimes short, and alert on session reuse from new contexts. Treat any shared HAR as potentially containing live credentials and revoke sessions on exposure.
Practice it
We built an Okta HAR session-theft scenario in GraphLattice Range so teams learn why a debug file is a credential, and how to respond when one leaks.