Okta Support System Breach 2023 — How Cookies Stolen from Customer-Service Sessions Led to BeyondTrust, Cloudflare, 1Password Compromises

The Okta support system breach is the canonical case study of customer-service-system risk. The fundamental issue: customer support systems hold sensitive customer artifacts (logs, screenshots, HAR files) that contain enough material for downstream compromise. The attack chain is operationally simple but illustrates a structural weakness across the industry. This post reconstructs what happened, contextualises it against the broader Okta-and-BeyondTrust dispute about disclosure, and identifies what every SaaS vendor and customer must learn.

What happened — credentials, HAR files, downstream attempts

On approximately 28 September 2023, attackers gained access to Okta’s customer support case management system using stolen credentials of an Okta contractor with administrative access. Once inside, the attackers searched for and downloaded HAR files from various support cases. HAR files (HTTP Archive format) are produced by browser developer-tools to capture network traffic during a session — including request URLs, headers, response bodies, and (critically) session cookies. Customer-support engineers at SaaS vendors routinely ask customers to provide HAR files when troubleshooting authentication issues; the file contains the diagnostic information needed to debug. The cookies in HAR files are valid for the customer’s active session at the time of capture. The downstream attack pattern: attackers extracted valid session cookies from the HAR files; replayed those cookies against the customer’s Okta dashboard or other applications; gained authenticated access without needing the customer’s password. From there, they attempted lateral movement and additional compromise. Three downstream organisations have publicly disclosed the attempts: BeyondTrust caught the attempt within minutes via behavioural anomaly detection; Cloudflare caught it within hours; 1Password caught it via security-event correlation. All three contained the attack before significant damage. Other affected customers (Okta’s subsequent disclosure indicated 1% of customer base — approximately 134 organisations) have not all publicly disclosed.

The disclosure controversy — Okta vs BeyondTrust

A specific aspect of the Okta breach’s notoriety is the disclosure timeline and the friction between Okta and customer organisations that detected attacks against themselves. The chronology: BeyondTrust detected the attack against itself on 2 October 2023. BeyondTrust contacted Okta the same day, providing technical details (specific HAR file involved, session-token theft, downstream activity). BeyondTrust subsequently submitted detailed forensic information to Okta over multiple days. Okta’s public disclosure came on 19 October 2023 — approximately 17 days after BeyondTrust’s notification. During the intervening period, Okta’s communication with affected customers was reportedly limited. BeyondTrust’s subsequent response — a detailed blog post on 24 October 2023 — directly criticised Okta’s slow disclosure and reframing of the incident. Specific BeyondTrust criticisms: (1) Okta initially claimed customer-side issue rather than Okta-side compromise; (2) Okta’s public disclosure significantly underplayed the scope; (3) Okta did not promptly notify affected customers. Okta’s response — additional disclosures over October-November 2023 progressively expanded the acknowledged scope; eventually Okta acknowledged 1% of customers (approximately 134 organisations) had HAR files affected, then expanded that to 100% of customer support cases reviewable by the breach (though not all had session-cookies in them). The industry takeaway: vendor incident response and customer communication is now under increased scrutiny; vendors that downplay or delay are increasingly held to account by their customers and the broader security community.

Why HAR files contain session cookies — and why this is the support-system risk

HAR files are not malicious; they are a legitimate browser developer-tools format for capturing network activity. The file format includes request and response data — and HTTP cookies are part of request/response data. When a customer captures a HAR file during troubleshooting, the file naturally includes the customer’s currently-active session cookies for whatever site they are interacting with. This is standard and expected behaviour. The structural problem: support engineers asking for HAR files is a routine industry practice. The HAR files are uploaded to support systems, retained for case management, and can be accessed by support staff. Compromise of a support system therefore exposes session cookies of customers who provided HAR files to that system. Mitigation patterns: (1) Sanitisation tools that scrub cookies from HAR files before transmission. Several open-source tools and browser extensions exist (HAR-Sanitizer, har-sanitize). Customer security awareness on this is rising but uneven. (2) Vendor-side automatic cookie removal upon HAR file upload. Some support systems are implementing this automatically. (3) Short session lifetimes — a stolen cookie that is already expired by the time it is exfiltrated provides limited value. (4) Cookie-binding to client characteristics (IP, user agent, device fingerprint) — if a stolen cookie is presented from a different client context, the session is invalidated. For customers: assume any HAR file you provide to a support system contains valid session credentials; treat that file as sensitive; consider sanitisation before upload; ensure your applications use short-lifetime sessions and cookie-binding where possible.

Timeline — from initial access to industry-wide reform

~28 September 2023: Initial access to Okta support system via stolen contractor credentials. 2 October 2023: BeyondTrust detects attack against itself; notifies Okta. 2-15 October 2023: Okta investigates internally; limited public communication; affected customers continue normal operations unaware. 19 October 2023: Okta public disclosure. Initial scope statement understates eventual final scope. 20-31 October 2023: BeyondTrust publishes detailed account criticising Okta’s response; Cloudflare publishes its own detailed account; 1Password publishes its own. Industry attention intensifies. 1 November 2023: Okta updates scope to ~1% of customers affected. Late November 2023: Okta updates scope further — all customer support cases that could contain the relevant data were potentially accessible. December 2023: Okta announces specific operational changes including rotation of all support-system access credentials, automatic HAR-file sanitisation, and expanded customer notification. Q1 2024: Continued customer-trust rebuilding; class-action lawsuit filed; SEC inquiry reported. Through 2024-2025: Okta implements broader security improvements; customer audit and detection capabilities for similar future incidents strengthened.

Detection and prevention — what customers and vendors should do

For SaaS customers: (1) HAR file sanitisation. Strip cookies from HAR files before submission to support. Use HAR-Sanitizer or equivalent. (2) Short session lifetimes. Configure your applications with sub-day session lifetimes for sensitive applications. (3) Cookie binding. Where applications support it, bind cookies to client IP, device fingerprint, or session-cookie + access-cookie patterns. (4) Detection on authentication anomalies. Alert on logins from new geographies, new devices, new ASNs — even if MFA was satisfied (because stolen cookies bypass MFA). (5) Conditional access policies. Modern identity providers (Okta itself, Azure AD, Ping) support session-binding and risk-based authentication that mitigates cookie-replay attacks. Configure aggressively. For SaaS vendors: (1) Customer-support data classification. Treat customer-uploaded artifacts (HAR files, logs, screenshots) as sensitive; encrypt at rest; access-control rigorously. (2) Automatic sanitisation. Implement automatic cookie/credential redaction on customer-uploaded support artifacts. (3) Support staff access controls. Phishing-resistant MFA, just-in-time elevation, full session recording for support engineers. (4) Anomaly detection on support system access. Flag unusual access patterns by support staff. (5) Customer-notification protocols. Pre-built procedures for rapid customer notification when a support-system breach is detected. The Okta incident demonstrated the cost of slow notification.

India context — Okta adoption and Indian implications

Okta has substantial enterprise adoption in India, particularly among IT services firms (Indian and multinational), Indian SaaS companies serving global customers, and Indian operations of multinational enterprises. The Okta breach implications for Indian organisations: (1) Customers using Okta should review session-cookie handling in their applications and configure short session lifetimes plus cookie binding where possible. (2) Indian organisations whose internal applications integrate with Okta as the IdP should verify they have detection capabilities for cookie-replay attacks. (3) DPDP Act implications for Indian Data Fiduciaries that suffered downstream compromise via Okta would be the same as for any vendor-related breach — Data Fiduciary remains accountable. (4) Vendor risk management for Indian organisations using Okta should include questions about Okta’s post-incident reforms. (5) Indian SaaS vendors should learn from Okta’s communication missteps; the customer-trust cost of slow or evasive disclosure is substantial.