Okta: Stolen Credential Led to Support System Breach
Okta customer BeyondTrust said that it first detected the attack and notified Okta on Oct. 2, though Okta did not confirm an internal breach until Oct. 19.
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 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.
“Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” said David Bradbury CSO at Okta, in a Friday security advisory. “In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it.”
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. It did not give details on how many customers were wrapped up in the breach, but the company did say it has notified all impacted customers.
One Okta customer that was impacted by the breach, BeyondTrust, released an advisory on Friday saying 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. However, while BeyondTrust notified Okta on Oct. 2 of the incident, the company said that Okta did not confirm an internal breach until Oct. 19.
For potentially impacted organizations, Okta has released IoCs, and BeyondTrust also highlighted various recommendations and TTPs 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.