Okta Security Breach Traced and Exposed:
A Lesson in Management and Employee Oversight
On November 6, international identity software leader Okta released a security traceability notice reviewing an intrusion event from September 28 to October 17. The breach resulted in sensitive file access of 134 customers and administrative hijacking of 5 customer Okta accounts.
Tracing the breach Investigators traced the breach to an employee using a personal Chrome account to sync work computer credentials, highlighting a severe lack of security measures like access restrictions and two-factor authentication. Okta’s disclosure largely blamed the employee’s disregard for rules, overshadowing systemic design flaws that contributed to the breach. It’s clear that better security management could have prevented this incident. Sinokap has consistently recommended two-factor authentication, and we’ve shared insights on this topic, which you can explore in our video.
Shifting Blame: A Deep Dive Into Okta's Security Incident
“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,” Bradbury wrote. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”
This means that when the employee logged in to the account on Chrome while it was authenticated to the personal Google account, the credentials got saved to that account, most likely through Chrome’s built-in password manager. Then, after compromising the personal account or device, the threat actor obtained the credentials needed to access the Okta account.
“In companies like Okta, using company computers to access personal accounts has always been considered a major taboo. If the prohibition was unclear to some people before, it should now be clear. This employee almost certainly violated company policy, and it wouldn’t be surprising if such a violation led to termination. However, if the invasion was merely triggered by the employee’s misconduct, it only indicates that everyone made mistakes. In fact, the responsibility lies with the security personnel who designed the invaded support systems, especially the way in which the invaded service accounts were configured.
Service accounts exist across various operating systems and frameworks. These accounts are different from standard user accounts accessed by humans.
Service accounts primarily perform automated machine-to-machine functions, such as conducting data backups or virus scans at specific times each night.
Therefore, they cannot be locked down with multi-factor authentication like user accounts, which explains why Okta did not set up multi-factor authentication. However, the invasion exposed some flaws that did not receive due attention in the posts of some Okta Chief Security Officers.
Root Cause Analysis
“David Bradbury stated that Okta first detected potential suspicious activity on its network on September 29, 2023. At that time, 1Password proactively reported to Okta that their internal Okta instance had been compromised. Initially, it was suspected that a 1Password employee’s device was infected with malware, which led to the intrusion. On October 2, another client, BeyondTrust, proactively reported that their accounts had also been compromised. Okta did not confirm the source of the intrusion until October 16. Such delayed-action allowed the threat actors to maintain access to the service accounts for over two weeks.
Bradbury wrote: 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.
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 with a suspicious IP address attributed to the threat actor. With this indicator, we identified the additional file access events associated with the compromised account.
Another failure was Okta’s lack of sufficient visibility into its network, which magnified the consequences of the intrusion. Otherwise, Okta could have detected the threat actor’s access behavior earlier, although this was not the cause of the intrusion.”
Corrective Measures
First, Okta should set up access controls beyond a simple password as to who can log in to the service account. One way to do this is to set restrictions or conditions on the IP addresses that can connect. Another approach is to periodically rotate the access token used to authenticate the service account. Of course, employees are prohibited from logging into personal accounts on work devices, and it is the responsibility of Okta senior managers to implement all relevant precautions.
While the Zero Trust security approach is sometimes overused, its broad principles are sound. Let’s say your network has been compromised and you want to prevent any insecure incidents by design. Enterprises should adopt a layered design, defense-in-depth approach to prevent a simple point of failure, such as preventing the leakage of a simple password or authentication token.
Bradbury tacitly acknowledges some of the failings in remediation steps outlined in his post. They include:
1. Disabled the compromised service account (Complete) Okta has disabled the service account in the customer support system.
2. Blocking the use of personal Google profiles with Google Chrome (Complete) Okta has implemented a specific configuration option within Chrome Enterprise that prevents sign-in to Chrome on their Okta-managed laptop using a personal Google profile.
3. Enhanced monitoring for the customer support system (Complete)
Okta has deployed additional detection and monitoring rules for the customer support system.
4. Binding Okta administrator session tokens based on network location (Complete)
Sinokap's Take on the Okta Breach
Okta is commendable for internally analyzing and processing the incident at this time, making substantial changes, and providing a timeline to the public. But they shouldn’t blame one employee for a mistake that was actually mismanagement at the top, masking the real problem.
As an internal IT team, Sinokap reminds all companies to take this incident as a warning. Management involvement and employee security training are crucial for data safety. Stay tuned for our next issue, where we’ll offer suggestions and solutions for enterprise management and security training to help protect customer data.
Table of Contents
What We Provide
Managed IT Service
How can we help you?
Call Us, Write Us, Or Knock On Our Door. We are here to help. Thanks for contacting us!
