A security breach at identity and access management (IAM) specialist Okta impacted over 130 of its customers, a handful of which suffered follow-on session hijacking attacks as a result, the vendor has revealed.
Okta notified customers about the breach on October 19, more than two weeks after being alerted to suspicious activity by one of those customers, BeyondTrust.
In his initial telling of the incident, Okta’s chief security officer, David Bradbury, explained only that it had come about after a threat actor used a stolen credential to access the firm’s support case management system.
However, in an update on Friday, he shared more, explaining that the actor had access to the system between September 28 and October 17, compromising files belonging to 134 customers in total.
“Some of these files were HAR files that contained session tokens which could in turn be used for session hijacking attacks,” Bradbury added. “The threat actor was able to use these session tokens to hijack the legitimate Okta sessions of five customers, three of whom have shared their own response to this event.”
Read more on Okta breaches: Okta: Just Two Customers Impacted by Lapsus$ Breach
The actor managed to access the support system after compromising an associated service account, which enabled them to view and update support cases, he continued.
“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,” Bradbury explained.
“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.”
The CSO also had information on why it took Okta two weeks to discover the breach.
Okta didn’t identify any suspicious downloads in its logs but said the threat actor had been careful about its unauthorized use of the support system.
“When a user opens and views files attached to a support case, a specific log event type and ID is generated tied to that file,” said Bradbury. “If a user instead navigates directly to the files tab in the customer support system, as the threat actor did in this attack, they will instead generate an entirely different log event with a different record ID.”
BeyondTrust provided Okta with the threat actor’s IP address on October 13, with which it was finally able to spot “additional file access events associated with the compromised account.”
Okta has since performed a range of remediation tasks including disabling the compromised service account, preventing sign-in to Chrome on an Okta-managed laptop using a personal Google profile, and implementing additional detection and monitoring rules.
The firm also introduced “session token binding” based on network location in order to mitigate the risk of session token theft.
Three of the five customers hit by session hijacking have revealed themselves as 1Password, BeyondTrust and Cloudflare.
Image credit: T. Schneider / Shutterstock.com