The world of cybersecurity is a constantly evolving battleground, where organisations defending sensitive data and digital identities face relentless attacks from malicious actors. A recent attack against Okta Security, a major identity management service, has sent shockwaves across cybersecurity. The attack leveraged access to a stolen credential to access Okta’s support case management system, and exemplifies the persistent threat of cyber attacks, even to major companies in the cybersecurity industry. What’s particularly concerning is that Okta did not uncover this breach themselves; it was independently detected by BeyondTrust and Cloudflare.
This article provides an update on the Okta breach, exploring how this breach unfolded, and most importantly, the steps you, as an Okta customer, can take to secure your environment.
How the attack unfolded
On October 2, 2023, BeyondTrust’s security teams discovered an identity-centric attack targeting an in-house Okta administrator account. The attacker attempted to access this account using a valid session cookie stolen from Okta’s support system. Although the attacker’s initial actions were thwarted by custom policy controls, certain limitations in Okta’s security model allowed them to carry out a restricted set of actions. BeyondTrust’s proprietary Identity Security Insights tool triggered an alert about this intrusion, leading to swift action to block access to their systems.
The initial incident response indicated a possible compromise at Okta of either someone on their support team or someone in position to access customer support-related data. BeyondTrust raised their concerns of a breach to Okta on October 2nd. Having received no acknowledgement from Okta of a possible breach, they persisted with escalations within Okta until October 19th when Okta security leadership notified us that they had indeed experienced a breach and BeyondTrust was one of their affected customers.
The initial incident response hinted at a potential compromise within Okta, possibly involving someone from their support team or anyone with access to customer support-related data. BeyondTrust raised their concerns about this potential breach with Okta on the same day as they discovered the breach. Despite receiving no immediate acknowledgement from Okta regarding the breach, they persisted in their efforts to escalate the matter within Okta. It wasn’t until October 19 that Okta’s security leadership confirmed the breach, acknowledging that BeyondTrust was among the impacted customers.
On October 18, 2023, Cloudflare also detected attacks that could be traced back to Okta. Threat actors successfully used a compromised authentication token from Okta to pivot into Cloudflare’s Okta instance. Fortunately, due to Cloudflare’s rapid response, none of their customer information or systems were compromised during this event.
Notably, both BeyondTrust and Cloudflare initiated contact with Okta regarding the breach before Okta could notify them.
Anatomy of the breach
Okta’s support often requests customers to upload HTTP Archive (HAR) files for troubleshooting. These files replicate browser activity and may contain sensitive data, such as cookies and session tokens, which malicious actors could potentially exploit to impersonate legitimate users.
The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases. It should be noted that the Okta support case management system is separate from the production Okta service, which is fully operational and has not been impacted. In addition, the Auth0/CIC case management system is not impacted by this incident.
The threat actor behind this breach was able to access files uploaded by specific Okta customers related to recent support cases. The Okta support case management system operates separately from the production Okta service, which remains fully operational and unharmed.
While reports suggest that only 170 of Okta’s customers were directly impacted out of over 18,000, it’s essential to emphasise that significant players like Cloudflare, BeyondTrust, and 1Password were among those affected. These three have all confirmed that their customer data remains secure, but their prominence in the industry suggests this breach could potentially have far-reaching consequences, even if many Okta customers weren’t directly involved.
Am I affected?
To determine whether your Okta data has been compromised, consider these detection strategies:
- Okta Session Hijacking: Watch for suspicious sessions that appear without an authentication event. Attackers may steal Okta session cookies to bypass MFA and security controls related to authentication.
- Okta User Performing Administrative Actions via Proxy: Pay attention to unusual administrative actions performed by users via proxies like Scattered Spider. Legitimate users rarely engage in such actions, so this could be a red flag.
- Okta Admin Privileges Granted to a User: Monitor any cases where attackers try to escalate privileges or grant admin privileges to backdoor accounts. Attackers will often try to do this, and in normal business operations this is typically a rare occurrence, so it should raise suspicion.
- Okta Password Health Reports: Keep an eye on the generation of Okta password health reports. Usually these reports are generated infrequently, so increased activity might indicate something suspicious.
- Okta Users with Admin Access Using Vulnerable MFA: Identify cases where Okta users with admin access employ MFA methods that could be vulnerable to SIM swapping. Strong MFA methods are essential to prevent such security breaches.
Recommendations for Okta Customers
If you’re an Okta customer, take these steps to bolster your security:
- Enable Hardware MFA: Rely on hardware keys for all user accounts, as passwords alone are insufficient to protect against attacks. Other MFA methods can be vulnerable to phishing.
- Implement Policy Controls: Add policy controls to limit access to the admin console.
- Shorten Okta Sessions: Reduce the time frame during which stolen cookies can be used by limiting the length of Okta sessions.
- MFA Challenge at Every Sign-On: Adjust your Okta global session policy to issue an MFA challenge with every sign-on. This will prevent attackers with stolen cookies from accessing the main dashboard.
- Monitor and Respond: Be vigilant about unexpected password and MFA changes for your Okta instances and suspicious support-initiated events. Ensure that all password resets are valid and force a reset for any under suspicion. Additionally, scrutinise any suspicious MFA-related events to ensure that only valid MFA keys are associated with user accounts.
The Okta breach underscores the complexity of modern identity-based attacks, which can originate from external environments. It’s crucial to establish specific policies and internal controls to limit risks associated with sharing files like HAR files. Adopt a defence-in-depth approach to safeguard your systems because the failure of a single control or process should not lead to a breach.
