UPDATE - Identity and access management services provider Okta said that threat actors used a stolen credential in order to access its support case management system, allowing them to view files related to support cases that were uploaded by certain customers.
Okta's initial Oct. 19 advisory said that HTTP Archive (HAR) files were impacted in the compromise. These files, which help with troubleshooting for issues by logging website interactions, contain sensitive data like cookies and session tokens. Okta warned that threat actors can use this type of stolen data to impersonate users. The breach impacted 134 Okta customers, which is less than 1 percent of its customer base, said Okta. Of these, the threat actor was able to use stolen session tokens to hijack the legitimate Okta sessions of five customers, according to Okta in a Nov. 3 update to the advisory.
"The unauthorized access to Okta’s customer support system leveraged a service account stored in the system itself," said David Bradbury, CSO at Okta in the Nov. 3 update. "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. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device."
Okta, which provides authentication and single sign-on services for thousands of businesses and government agencies globally, said that its production Okta service and Auth0/CIC case management system are not impacted.
“Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” according to the initial Okta security advisory. “In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it.”
After Okta's initial disclosure in October, three Okta customers, 1Password, BeyondTrust and Cloudflare, also released advisories detailing how the incident led to attempted attacks on their systems.
Okta in its update said that 1Password was the first company to report suspicious activity to Okta support on Sept. 29. In its own advisory, 1Password also said that it detected suspicious activity on its Okta instance that it uses to manage employee-facing apps, which it said was a result of the Okta support systems breach. 1Password said that it terminated the activity and found no compromise of user data.
BeyondTrust, meanwhile, said that it first detected suspicious behavior stemming from Okta's breach on Oct. 2. According to BeyondTrust, that day an attacker used a session cookie from a support ticket in the breached support case management system in order to attempt to perform actions in the BeyondTrust Okta environment.
“BeyondTrust’s custom policies around admin console access initially blocked them, but they pivoted to using admin API actions authenticated with the stolen session cookie,” according to BeyondTrust. “API actions cannot be protected by policies in the same way as actual admin console access. Using the API, they created a backdoor user account using a naming convention like existing service accounts.”
After detecting these suspicious actions, BeyondTrust disabled the backdoor user account and revoked the attacker’s access. By now BeyondTrust had started to put the pieces together that these actions were part of an identity-centric attack on the in-house Okta administrator account, and had also found forensics supporting a compromise within the Okta support organization.
For Cloudflare, the company said that threat actors were able to use a compromised authentication token in order to pivot into Cloudflare’s Okta instance. Cloudflare said that the attack happened on Oct. 18.
Though 1Password, BeyondTrust and a third customer reported suspicious activity to Okta in the weeks following Sept. 29, Okta did not confirm an internal breach until Oct. 19.
Okta has released IoCs and notified other potentially impacted customers, and BeyondTrust also highlighted various recommendations and attacker tactics used in the attack.
“Modern identity-based attacks can be complex, and as this attack shows, can originate from environments outside your own,” according to BeyondTrust's advisory. “Good specific policies and internal controls are necessary to limit things like how HAR files are shared. Defense in depth is important though. The failure of a single control or process should not result in breach. Here, multiple layers of controls -- e.g. okta sign on controls, identity security monitoring, and so on, prevented a breach.”
The breach is the latest in a string of security incidents impacting Okta over the past year. Last year, the company said that a breach at one of its third-party contractors led to attackers from the Lapsus$ group accessing some customer information. And in a seperate incident in 2022, Okta said threat actors had accessed its source code after compromising its GitHub repositories.
This article was updated on Nov. 3 to reflect further information from Okta on the breach.