How a troubleshooting file handed over an administrator’s session in the Okta breach

Attackers in Okta’s support system replayed session tokens from files customers had uploaded. For health systems, which send vendors logs and screenshots daily, each support artifact’s exposure depends on what it contains, what it is under HIPAA, and how long it stays usable.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

On October 20, 2023, identity provider Okta disclosed that an attacker had used stolen credentials to access its customer support case management system and had viewed files some customers had uploaded with support cases. Some were HTTP Archive (HAR) files, browser recordings used for troubleshooting, which can contain session cookies and tokens. In the following days, affected customers published their own accounts. BeyondTrust said it had detected and blocked suspicious activity in early October and reported it to Okta, and Cloudflare and 1Password described related activity in their environments. Okta said the support system was separate from its production service. In late November it widened its findings, saying the attacker had also downloaded a report with the names and email addresses of all its customer support system users.

An earlier article in this series, on the Lapsus$ episode of 2022, looked at the time an identity provider’s customers waited to learn of a compromise in its support chain. The October 2023 incident raised a different question, about what customers themselves had put into that chain. Health systems run on vendors: EHR, imaging, identity, revenue cycle, interface engines, telehealth, and dozens of smaller products. Troubleshooting each one means sending the vendor something, such as logs, screenshots, configuration exports, browser recordings or test extracts. We assess the exposure of any support artifact in three parts, which together determine what an attacker gains by reading it: what it contains, what it is under HIPAA, and how long it stays usable.

What the artifact contains

A HAR file records everything a browser sends and receives, including cookies and authorization headers. Captured during an administrator’s signed-in session and uploaded unredacted, it hands the reader that session. Okta’s customers had done what support asked. The danger lay in the file’s contents.

Other artifacts carry similar material. Application logs at debug level often record tokens and connection strings. Configuration exports from interface engines can contain service account passwords for HL7 or FHIR connections. Screenshots of an administrator console may show API keys. Database extracts sent to reproduce a defect contain whatever the query returned.

The controls are practical. Staff can use sanitizing tools that strip cookies, authorization headers and known secret patterns from HAR files and logs before upload, and Cloudflare, among others, released an open-source HAR sanitizer after the incident. Captures can be made with test accounts rather than privileged ones. The service desk can keep a short list of artifact types that require a security review before leaving the organization, such as configuration exports and database extracts. And the person who shares an artifact should note what it was, so it can be found again if the vendor reports a breach.

Volume makes this a process question rather than a training question. A large health system opens thousands of vendor cases a year across clinical, financial and infrastructure teams, many of them outside IT. A short procedure that applies to all of them, built into the service desk tool and the vendor management checklist, will do more than an annual awareness module. Measuring it is straightforward: sample a few dozen recent vendor cases each quarter and check what was attached.

What the artifact is under HIPAA

A screenshot of an EHR error, a log from an interface engine or an extract used to reproduce a billing defect may contain protected health information. A vendor that receives PHI to provide services to a covered entity is generally a business associate and needs a business associate agreement. Most major health IT vendors have signed one. Fewer health systems have checked whether the vendor’s support platform, often a separate commercial case management service, falls within that agreement’s safeguards, or whether the vendor treats it as a subcontractor.

Three questions belong in every vendor review. Does the business associate agreement cover the support system and any third-party platform it runs on? Does the vendor notify the customer of a breach of the support system, as well as of its product? And can the health system get a list of the PHI-bearing attachments it has uploaded, so that a privacy officer can assess notification obligations with counsel quickly? Internally, the simplest control is to steer PHI away from uploads altogether: offer redaction tools, prefer live screen-sharing sessions where the vendor sees but does not keep the data, and require privacy office approval for any extract containing patient records.

How long the artifact stays usable

A stolen token is only as valuable as its remaining lifetime. Administrative sessions that last for many hours, or refresh silently for days, make a week-old HAR file dangerous. Sessions bound to a device or network, short idle timeouts for administrative consoles, and re-authentication for sensitive actions all shrink the window. Health systems can ask each identity and critical application vendor which of these protections exist and turn them on for privileged roles. Ending administrative sessions after a support capture is a simple habit that removes most of the risk.

The artifact itself also has a lifetime. Support platforms often keep attachments for as long as the case exists, and cases are rarely purged. A configuration export sent three years ago may still hold valid service account credentials if the passwords were never rotated. Contracts can set retention limits for support attachments, such as deletion a set number of days after a case closes. Health systems can rotate any credential that was ever included in an artifact, and they can ask vendors for a deletion certificate when a major case closes. Taken together, short-lived sessions and short-lived attachments mean that a future support breach exposes old files without live secrets in them.

With hindsight

Okta’s late-November update, that the attacker had downloaded names and email addresses of all support system users, widened the incident and raised concern about targeted phishing of administrators. Okta reported in early November that initial access came through a service account whose credentials had been saved to an employee’s personal browser profile on a company laptop. In 2024 it announced a broad security program in response. Session token theft grew as a technique as more organizations adopted multi-factor authentication, and identity providers and browser makers expanded features for binding sessions to devices. For health systems, the Change Healthcare attack in 2024 showed in a much larger way how dependent providers are on a single vendor’s environment. Vendor support channels remain a smaller, quieter part of that dependence, and one that health systems can largely control through what they send, what their agreements cover and how long their sessions last.

  • Okta
  • session tokens
  • vendor support
  • HIPAA
  • business associates