Update, Nov. 30, 2023: On Nov. 29, Okta revealed that the October Okta breach we wrote about in the following blog was more extensive than initially reported. Okta has now revealed that a threat actor ran and downloaded a report containing the names and email addresses of all Okta customer support system users. This impacts all Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers, excluding those in FedRamp High and DoD IL4 environments. This contrasts with Okta's earlier statement that less than 1% of its 18,000-plus global customers were affected. Okta clarified that while there is no direct evidence of active exploitation, the stolen information, including names and email addresses, poses a risk for potential phishing or social engineering attacks targeting Okta customers. The company did not attribute the attack to a specific group and acknowledged the uncertainty surrounding the perpetrators. This update further illustrates the need for all organizations, especially administrators, to enhance their identity security by implementing adaptive multi-factor authentication (MFA) and considering phishing-resistant authenticators.
____
The October 2023 Okta breach is the latest example in a long line of third-party identity attacks. Based on reports to date, it seems that the attack on Okta’s support case management system enabled a threat actor to launch downstream attacks into other companies. So far, 1Password, BeyondTrust and Cloudflare have publicly confirmed they were targeted.
Such attacks don’t discriminate and pointing fingers is unproductive. However, there are opportunities to learn and share to help improve our collective cyber preparedness – and prevent history from repeating itself. We join the unfolding conversation in this spirit.
Okta Breach Timeline and Flow: What We Know So Far
The following is an overview of the Okta breach, along with some observations and speculations based on early reports.
• Initial infection (date unknown): Exactly when and how the attacker initially comprised Okta’s support system remains unknown. Possibilities include, but aren’t limited to, password re-use from previous data dumps and lack of multi-factor authentication (MFA), cookie theft from a compromised endpoint, phishing and MFA bypass, social engineering, keylogging, improper access to the portal through an unmanaged endpoint.
The attacker’s reported movements suggest that they may have identified a specific Okta engineer, stole their credentials (via spear-phishing or another social engineering tactic) and infected their endpoint machine with command and control (C&C) tools such as Cobalt Strike or BruteRatel, which are used by pen testers, red teamers and threat actors alike. This would allow them to actively monitor the endpoint, exfiltrate data at will and use the stolen credentials to access Okta’s support system.
• September 29: 1Password, an Okta customer, detected suspicious activity on its Okta instance used to manage its employee-facing apps. According to reports, a member of the 1Password IT team opened a support case with Okta and provided a HAR file (short for HTTP archive – a type of file used for recording web browser data for support and troubleshooting services) created from the Chrome dev tools. An investigation confirmed that an attacker had accessed the Okta tenant with administrative privileges.
• October 2: BeyondTrust, another Okta customer, detected an issue involving one of its internal Okta admin accounts and immediately notified Okta.
Later in the month, the customer publicly disclosed more attack details. One of its employees was experiencing ongoing technical issues with the Okta system and, at the request of Okta support, uploaded a HAR file for troubleshooting purposes. Not only did this HAR file contain browsing data, it also contained a valid Okta session token (or cookie). Attackers target cookies as they enable users – and threat actors – to skip over login and MFA prompts.
Just 30 minutes after the Okta support engineer downloaded the HAR file to their infected machine, an attacker – who used an unfamiliar IP address in Malaysia linked to anonymizing proxy/VPN services – extracted session tokens/cookies from the HAR file to access the Okta customer’s network.
The attacker also tried using a cookie to access the client’s Okta console and create an admin account. After failing, they used the cookie again to hijack and replay the browser session to impersonate the user. Notably, the attacker created a backdoor user account in the company’s typical naming convention to help it blend in with existing accounts. Attackers often use backdoor accounts like this to maintain persistence and avoid detection, move laterally to gain control of the victim organization’s network then escalate access privileges to reach their goal. Fortunately, in this case, the customer detected and blocked the attack quickly.
• October 18: A third organization, Cloudflare, investigated and reported a similar incident to Okta. Through early detection and immediate response, no customer information or systems were impacted in this particular event.
• October 19: Okta confirmed the breach in a message to affected customers nearly three weeks after receiving the first customer alert.
• October 20: Okta issued a public statement explaining that Okta had “identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system. The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases.”
This identity attack targeting Okta customers has a familiar ring to it. In January 2022, Lapsus$ attackers compromised an Okta third-party support engineer’s endpoint and gained access to Okta customers’ data. The company confirmed the breach in late March 2022 and announced sweeping changes to its support system to strengthen third-party security. Yet is seems that something went wrong along the way – reinforcing the need for strong security processes and operational procedures.
Mitigate Risk with Six Steps and New CyberArk HAR Tool
A recent Cyentia Institute study of 230,000 organizations found that 98% of firms have at least one third-party partner who has suffered a breach. It’s highly likely that your organization buys from or works with at least one third party and is indirectly connected to numerous vendors across the software supply chain. One of these companies will inevitably experience an identity breach. Don’t wait until it reaches your doorstep.
1. Take the time to review your detection and response processes and timelines and focus on ways to reduce your mean time to detection (MTD) and mean time to response (MTR). The emerging Identity Threat Detection and Response (ITDR) discipline can serve as a helpful framework and an ideal end state.
The ability to baseline user behavior and continuously monitor suspicious connections to accounts – especially powerful admin accounts – can help you catch suspicious activities faster, such as logins via a VPN or outdated user agent, logins from unknown locations, logins directly following a support session, or accounts created/modified via REST API.
2. Enforce MFA for all users, preferably with FIDO passwordless (i.e., passkeys related to physical devices) for securing the network identities.
3. Only allow access to admin portals from verified sources (e.g., device, IP address and regions).
4. Create a whitelist of specific machines that can access sensitive accounts (e.g., admin accounts) and block all others.
5. Harden the operating system and enforce least privilege at the endpoint, which can significantly limit an attacker’s ability to access endpoints, establish persistence, steal files, compromise credentials and cause damage.
6. Sanitize all credentials and session tokens (cookies) within a HAR file before it’s shared. We’ve created a tool to help simplify this process. Additionally, require support personnel to erase all support-related files immediately after the session ends.
Identity is the root of trust in all organizations. When trust is abused – even if it involves just one compromised or misused identity – risk can travel downstream quickly. We must all remain vigilant, prioritize speed in detecting, mitigating and disclosing attacks, and evaluate all cybersecurity decisions through an identity lens.
Shay Nahari is VP of CyberArk Red Team Services, Andy Thompson is CyberArk Labs’ Offensive Security Research Evangelist and Khizar Sultan is CyberArk’s Senior Director of IAM Product and GTM Strategy.
____
Editor’s note: To learn more about the Oct. 2023 Okta breach and what your organization can do to mitigate risk, here are two resources that can help you:
- Watch CyberArk Labs' webinar, “Assessing the Attack on Okta’s Support Unit – Mitigate Your Risk with Six Steps and New CyberArk HAR Tool,” featuring Khizar Sultan and Andy Thompson, two of the authors of this blog.
- Listen to CyberArk’s Trust Issues podcast episode, “Analyzing the MGM and Okta Breaches: the Identity Connection,” for further insights from Andy Thompson on this subject and beyond. The episode is available in the player below and on most major podcast platforms.
