Okta disclosed on Friday the 20th of October that the company's customer-support case-management system had been compromised, with the operators having gained access to HAR files (HTTP Archive files containing browser-session-data) that customers had uploaded as part of support cases (Okta statement on the support compromise). The compromise window is approximately the 28th of September through the 17th of October. The customer organisations affected directly include 1Password (who disclosed on the 23rd), BeyondTrust (who disclosed on the 19th, before Okta's own public disclosure), Cloudflare (who disclosed on the 20th), and several others through the past several days.
The technical content. HAR files contain, by the standard browser-export format, full HTTP-session content including authentication cookies, request and response bodies, and any other content that traversed the browser session during the captured period. The HAR files that customer organisations had uploaded to Okta support cases included, in the affected cases, valid Okta-session cookies that the operators were able to use to gain authenticated access to the affected customer-organisation Okta tenants. The downstream-customer-trust impact is therefore not just the immediate exposure of the HAR file contents but the operators' ability to use the captured session-cookies to access the customer-organisation Okta administrative interfaces and from there to identify users, modify configurations, and pivot to further activity.
The 1Password and BeyondTrust subsequent disclosures are the part of the case that has the broader operational implications. BeyondTrust detected the unauthorised access to their Okta tenant on the 2nd of October — eighteen days before Okta's own public disclosure — and notified Okta. The fact that the customer organisation detected the incident before the vendor disclosed it is an unusual operational pattern and is a substantive comment on the customer-organisation Okta-tenant monitoring posture (BeyondTrust's was, evidently, comprehensive) versus Okta's own internal-detection capability (which appears to have been less effective). The customer-organisation conversations about cloud-vendor monitoring postures have been substantively informed by this dimension of the case.
For the customer-portfolio response. The audit cycle on customer-organisation Okta tenants has been the principal Q4 work. The customer-organisation hunt activity for any indicators-of-compromise consistent with the documented attack pattern has been comprehensive. The customer-portfolio findings have been negative — no customer-organisation in scope of the documented activity — but the aggregate audit work has been substantive.
The wider strategic point about cloud-vendor-trust posture. The post-Storm-0558 (cloud-provider-side compromise), post-MOVEit (managed-product-side compromise), post-Okta-support (support-tool-side compromise) sequence demonstrates that the customer-organisation cloud-vendor risk is multi-dimensional. The customer-organisation defensive posture against this risk needs comprehensive logging-and-monitoring of cloud-vendor activity, customer-side detection capability that operates independent of the vendor's own detection-and-disclosure cadence, and incident-response readiness that incorporates cloud-vendor-side compromise as a category of trigger. The customer-portfolio programme work for 2024 will substantially incorporate these dimensions.
I will return to this. The Okta-support case is the third major Okta-related compromise (the January 2022 Lapsus$ contractor compromise and the August 2022 Twilio-derived exposure being the prior cases) and the customer-organisation conversations about Okta-vendor-relationship-management have been substantive.