Snowflake and the Continuing Identity Threat Detection Gap Across SaaS and Cloud
Blog

Closing the Identity Threat Detection Gap: The Okta Support Unit Breach Revisited

February 12, 2024

By Adam Koblentz

In my recent posts on Microsoft’s identity breach (
part 1, part 2), I drew a parallel between that incident and Okta’s October 2023 support unit breach. Even though the specific details about each of these incidents were different, the fact that two of the market share leaders in identity and access management (IAM) were affected by identity-based breaches within such a short time period highlights a critical gap in how both enterprises and security vendors are approaching identity protection today.

In the wake of new fallout from this incident, let’s revisit what happened at Okta, what the impacts were to both Okta and its customers, and how a more sophisticated approach to identity threat detection may have led to a very different outcome.

Okta October 2023 security incident

In October 2023, Okta disclosed that a trusted service account with permission to view and update support cases was compromised when an employee logged into the service account using a Chrome web browser session that was simultaneously logged into their personal Google profile. As part of this process, the privileged service account credentials were saved to the employee’s personal Google profile, allowing the threat actors to target the employee’s personal account or personal devices to access the credentials. 

The threat actors then used the stolen service account credentials to infiltrate Okta’s support case management system, extracting cookies and session tokens from customer-provided HAR files. From there, they used some of these session tokens to launch session hijacking attacks against Okta’s customers.

For an overview and analysis of the Okta support unit breach in video form, watch this short video.

A major identity threat detection breakdown

One of the most alarming aspects of the Okta incident was that it was not Okta themselves who detected it. They first became aware of it from external reports from two of their customers.

In one of his blog posts on the incident, Okta CSO David Bradbury acknowledged that even once they became aware of the incident, they were not able to identify any suspicious activity in their logs during 14 days of investigation. Eventually, once one of their customers was able to provide a suspicious IP address associated with the threat actor, Okta was able to connect the dots and zero in on the specific actions that were taken during the incident.

The way this incident, and the subsequent Microsoft identity breach, unfolded highlights a critical gap in how the industry approaches identity protection. While tremendous strides have been made in deploying preventative identity measures like IAM, multi-factor authentication (MFA), and PAM, most organizations, including many security vendors, have been lulled into a false sense of security that these technologies are infallible.

When resourceful threat actors inevitably do find a way around them, as they did at both Okta and Microsoft, they are often able to dwell undetected for weeks – or even months. In the case of the Okta breach, the threat actors had access for nearly three weeks.

This breakdown highlights a critical need to augment preventative identity security measures like IAM, MFA, and PAM with effective identity threat detection capabilities.

Cascading customer impact and lingering effects

While Okta initially reported that the support details accessed affected 134 customers, it later disclosed that the incident affected all of its customer support system users.

There are at least five confirmed instances of Okta customer sessions being hijacked successfully, including some who shared their own detailed incident reports:

  • 1Password’s incident report includes some additional insights into how the threat actors attempted to advance their attack, including by enabling identity services in the company’s Google instance in an attempt to bypass Okta.
  • Cloudflare described their experience – and noted that it was the second time in less than two years they’ve been affected by an Okta breach – in their blog post on the incident.

 

Last week, Cloudflare disclosed that they suffered a follow-up breach resulting from the October 2023 Okta service unit breach. A nation-state threat actor used an access token and three service account credentials that were exposed during the October 2023 Okta breach to gain access to Cloudflare’s internal wiki, bug tracking system, and source code management tool.

Cloudflare limited the damage caused, but the fact that the threat actors used the Okta breach to subsequently target other security and technology vendors highlights how incidents involving trusted identity attacks can cascade through sectors if they are not detected and mitigated quickly.

The lesson: identity threat detection remains a critical gap

As identity-based threats that bypass preventative controls become more common, it’s imperative to assume that breaches are inevitable and implement a comprehensive detection strategy for both identities and applications. Attackers are honing in on identities as the primary vector to gain access and evade detection, exploiting the difficulty in distinguishing between legitimate and unauthorized users through traditional detection methods.

Reveal Security recommends adopting a continuous monitoring and validation approach for trusted identities and their usage post-authentication. This involves monitoring user behavior across applications, including software-as-a-service (SaaS) products, custom-built applications, and cloud providers like AWS and Azure. By swiftly and accurately detecting and alerting on suspicious behavior, organizations can bolster their defenses against insider threats, identity compromise, privileged access management issues, and more.

Identity protection best practices for every enterprise

In addition to implementing effective identity threat monitoring capabilities, organizations should also treat incidents like the Okta service unit breach and Microsoft identity breach as a wake-up call and take a closer look at their identity protection practices, even if they have already invested heavily in preventative capabilities.

Here are some great places to start:

  • Social Engineering Training: Enhance the effectiveness of your social engineering training programs by making them more engaging. Regular training is crucial to empower employees against evolving social engineering tactics.
  • MFA and Identity Hygiene: MFA is a critical capability, but it’s not a standalone solution. In addition, individual MFA techniques are not all equally effective. Enforce better MFA practices, avoid less secure methods such as SMS, and consider the potential vulnerabilities of push notifications.
  • Watch Your Watchers: Administrators are often overlooked, but their actions and errors can have an outsized impact on risk. Paying attention to admin activities is vital, and organizations should invest in tools and processes to monitor their actions effectively.
  • Store Your Audit Logs: Start storing audit logs for your applications, including identity providers like Okta. This ensures a comprehensive record of activities, facilitating faster incident response and threat detection.

 

The Okta support unit breach is not an isolated incident. This breach and others like the Microsoft breach demand a reevaluation of identity security approaches. Organizations must move beyond relying solely on preventative identity controls and embrace detection through continuous behavior monitoring and validation of identities. 

Contact us to learn more about Reveal Security’s approach to identity threat detection and response in and across ANY application including Okta and Microsoft 365 to enhance your organization’s cyber resilience in the face of increasingly sophisticated threats.

Share: