Okta breach post mortem reveals weaknesses exploited by attackers

The recent breach of the Okta Support system was carried out via a compromised service account with 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,” David Bradbury, Chief Security Officer at Okta, revealed on Friday.

“The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”

How the Okta breach affected customers

The threat actor took advantage of the access they had gained to the Okta Support system and to unsanitized HAR files provided by the customers to Okta Support.

From those files, they were able to extract session tokens, which allowed them to hijack the legitimate Okta sessions of 1Password, BeyondTrust, Cloudflare, and two other unnamed companies.

The threat actor used those hijacked sessions / admin accounts to try and burrow further into the companies’ systems but, as we previously reported, they were not able to do much and were quickly booted out.

The investigation timeline shared by Bradbury confirmed that 1Password first notified Okta Support of suspicious activity on September 29, 2023, but it took 14 more days and an indicator of compromise provided by BeyondTrust for them to discover the misuse of the service account.

Why weren’t the attacker’s actions discovered earlier?

“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. 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,” Bradbury explained.

“Okta’s initial investigations focused on access to support cases, and subsequently we assessed the logs linked to those cases. On October 13, 2023, BeyondTrust provided Okta Security a suspicious IP address attributed to the threat actor. With this indicator, we identified the additional file access events associated with the compromised account.”

He said that the threat actor gained unauthorized access to files associated with 134 Okta customers and that those customers have been informed.

Finally, he laid out the actions Okta took in the wake of the attack. As part of remediation, they disabled the compromised service account. To prevent similar attacks in the future, they:

• Implemented a configuration option within Chrome Enterprise that prevents employees from signing in to Chrome on their Okta-managed laptop using a personal Google profile
• Deployed additional detection and monitoring rules for the customer support system, and
• Implemented session token binding based on network location, so that stolen/compromised Okta administrator session tokens can’t be used by unauthorized users

“Okta administrators are now forced to re-authenticate if we detect a network change. This feature can be enabled by customers in the early access section of the Okta admin portal,” he concluded.

from Help Net Security https://ift.tt/i3F4Czq

Related Items