BeyondTrust, a cybersecurity service provider for authentication giant Okta, reports that the company suffered a security breach in early October that may have granted the perpetrators access to customer files related to support cases. The attackers were able to steal a session cookie from the Okta support system and access an administrator account, providing them with further access to customer environments.
The report indicates that some standard Okta environment security protocols may have prevented the attackers from doing anything consequential in these environments, but individual customers would have had to enabled them to be protected and would have had to notice the security breach quickly enough to cut off access. In the wake of an official confirmation of the breach from Okta, each customer will need to evaluate their own environment to determine if the hackers accessed anything in it.
Okta support breach limited by policy restricting console access to managed devices
In a recent blog post, BeyondTrust noted that the security breach took place on October 2. The company says that none of its own files were accessed, but that the attackers potentially had access to other sensitive files uploaded to the Okta support system by customers.
The attacker, who has not yet been identified, was apparently somehow able to hijack a session cookie from an Okta administrator. BeyondTrust says that it recognized and responded to the breach in its own environment within 30 minutes and alerted Okta right away, but did not get confirmation of the incident from the company until October 19.
What prevented the attacker from doing any damage (and what tripped alarms) in BeyondTrust’s own Okta environment was a custom policy configuration for admin console access. The attacker was able to get around this by pivoting to using admin API actions authenticated with the stolen session cookie, something that Okta policies cannot be configured to stop. They used this technique to create a backdoor user account, but BeyondTrust identified and disabled it before it could be accessed by the threat actor.
BeyondTrust traced the initial compromise of the Okta support system back to a HAR file that was uploaded to its environment, apparently as part of legitimate troubleshooting of a support ticket generated by another Okta customer. A HAR file is a browser-generated log of interactions with a website stored as an HTTP archive, sometimes used by support desks to diagnose issues with a site. This HAR file contained the session cookie the attacker ultimately deployed; it remains unclear how exactly they obtained it, but raises natural questions about threat actor access to the environment after the company’s recent security issues.
Security breach adds to iffy track record for Okta in recent years
The response does not add to general confidence levels in the company’s security, already rocked by the “0ktapus” string of attacks and social engineering attempts. BeyondTrust says that it notified Okta support very shortly after the security breach initiated, but did not get a response and requested an escalation to Okta’s security team the following day (October 3). That was apparently the end of communication until October 11, when BeyondTrust began a series of Zoom meetings with Okta security staff, ultimately concluding with an acknowledgement of likely compromise on October 13. Okta confirmed the breach on October 19 and issued its public notice on October 20, accompanied by BeyondTrust’s more detailed explanation of the situation.
The Okta support case management environment is what was compromised in this incident, and Okta’s breach disclosure states that this environment is separate from its Auth0/CIC case management system and its production service (which are not impacted). Okta customers that were potentially impacted by the security breach have already been contacted by the company.
Information has yet to come in about damage to other Okta customers, but Cloudflare has reported anomalous activity linked to Okta support on October 18. The company says that two employee accounts were compromised but that it was able to rapidly contain the incident and minimize damage.
BeyondTrust reports that the bogus Okta administrator account had a Malaysian IP address, though it was associated with a known proxy service. The firm suggests requiring Okta Verify to be present on managed devices to allow console access, and to prompt users for MFA at each login (via Okta global session policies). Okta session length might also be limited to shorten the window in which a stolen cookie is viable.
Rahul Pawar, Global Vice President, Security GTM & CTO, GSS at Commvault, adds: “The breach of Okta’s support system is a reminder of the importance of strong password management and multi-factor authentication (MFA). It’s yet another example of how a multi-layered cybersecurity and cyber resilience program can protect organizations from cyberattacks and reduce the risk of compromise – ultimately protecting their data and users. Organizations that use Okta should take the necessary steps to protect themselves from this breach, including requiring all users to use strong passwords and MFA, enabling MFA on all Okta accounts (including administrative accounts), monitoring Okta logs for suspicious activity, and implementing a zero-trust security model to reduce the risk of compromise, even if an attacker gains access to a user’s credentials.
“Organizations should also consider rotating all Okta credentials, changing the passwords for all other accounts that are linked to Okta accounts, such as email accounts and cloud storage accounts, and implementing security awareness training for all employees to help them identify and avoid phishing attacks. It is important to note that Okta has stated that there is no evidence that this breach has affected customer data. However, organizations should still take the necessary steps to protect themselves from potential harm,” added Pawar.
