Okta breach led to hijacked sessions for 5 customers

Okta published a timeline Friday detailing a recent breach against its customer support case management systems, which led to a threat actor hijacking sessions for five of its customers.

The identity and access management (IAM) vendor disclosed last month that a threat actor used stolen credentials to breach its support case management systems and access customer data. An Oct. 20 blog post by Okta CSO David Bradbury provided few details at the time and failed to explain how or when the credentials were stolen, nor which customers were affected.

Three customers affected by the breach -- 1Password, BeyondTrust and Cloudflare -- published blog posts of their own to fill in some missing details. 1Password CTO Pedro Canahuati said in an Oct. 23 post that his company first detected threat activity relevant to the breach on Sept. 29; BeyondTrust said it alerted Okta of a potential breach on Oct. 2. Cloudflare had a blog post that leaned more critical, titled "How Cloudflare Mitigated Yet Another Okta Compromise."

Okta's Friday post, also authored by Bradbury, provided greater clarity and context around the nature of the attack as well as a detailed timeline. Friday's update appears to have replaced Bradbury's original post entirely; snapshots of it are still available on the Wayback Machine.

In the new post, Bradbury said an unnamed threat actor gained unauthorized access to files inside the IAM vendor's customer support system from Sept. 28 to Oct. 17. The files accessed were associated with 134 Okta customers, "or less than 1%" of the vendor's total client base.

Among accessed files "were HAR files that contained session tokens which could in turn be used for session hijacking attacks," the update said. The threat actor used tokens to hijack Okta sessions belonging to five customers -- three of which were 1Password, BeyondTrust and Cloudflare, which had previously disclosed their respective incidents. The other two customers were not named.

The customer support system was most likely accessed through an employee's compromised Google account, the CSO claimed.

"The unauthorized access to Okta's customer support system leveraged a service account stored in the system itself," Bradbury wrote. "This service account was granted permissions to view and update customer support cases. During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop. The username and password of the service account had been saved into the employee's personal Google account."

According to the newly provided timeline, Okta began its investigation on Sept. 29 following 1Password's report. For 14 days of Okta's active investigation, the vendor "did not identify suspicious downloads in our logs." The post explained that a specific log event type and ID are generated when a user opens and views files tied to a customer support case.

However, the threat actor in this case navigated to the Files tab in the customer support system to access data, which generated "an entirely different log event with a different record ID," Okta said. It was only when BeyondTrust provided the vendor with a suspicious IP address on Oct. 13 that Okta had the necessary indicator to identify "the additional file access events associated with the compromised account."

A spokesperson for Okta told TechTarget Editorial that the company has "created new detections that cover both of the log entries that indicate a file download event" to address the issue.

Alexander Culafi is an information security news writer, journalist and podcaster based in Boston.