In my earlier article, I wrote about Okta's breach that was reported by BeyondTrust and other partners. Link here After some time, Okta came back with their version of the incident. These are the excerp. hhhhts from the CSO's article.

For a period of 14 days, while actively investigating, Okta did not identify suspicious downloads in our logs. 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 a suspicious IP address attributed to the threat actor. With this indicator, we identified the additional file access events associated with the compromised account.

Investigation Timeline

2023-09-29 1Password reports suspicious activity to Okta Support.

2023-09-29 Okta Security begins an investigation, suspecting that 1Password was most likely the victim of malware or a phishing attack.

2023-09-29 to 2023-10-02 Okta Security meets with 1Password on 9/29, 9/30, 10/1 and 10/2 in an attempt to resolve their support case.

2023-10-02 BeyondTrust reports suspicious activity to Okta Support.

2023-10-02 to 2023-10-11 Okta Security meets with 1Password and BeyondTrust multiple times from 10/2 to 10/11.

2023-10-12 A third customer reports suspicious activity to Okta Support.

2023-10-13 BeyondTrust provides Okta Security an indicator of compromise (IP address) associated with the event they reported to Okta Support on 10/2.

2023-10-16 Using the supplied IP address, Okta Security identifies a service account associated with previously unobserved events in the customer support system logs.

2023-10-17 Okta Security disables the service account and terminates associated sessions.

2023-10-17 Okta Security copies and examines all files identified in the customer support system logs that were accessed by the threat actor. 134 Okta customers or less than 1% of Okta customers had a file accessed by the threat actor.

2023-10-17 Okta Security revokes the Okta session tokens embedded in the HAR files.

2023-10-17 Okta Security investigates whether the threat actor attempted to access customer Okta instances using these files.

2023-10-18 Okta Security notifies a fourth Okta customer targeted by the adversary.

2023-10-18 Okta Security identified a gap in the logs from the customer support system, missing the final hours that the threat actor had access. A re-run query now returns a complete picture of adversary activity.

2023-10-19 Okta Security identifies additional files downloaded by the threat actor that were not previously discovered due to the delay in receiving the logs.

2023-10-19 Okta Security revokes the Okta session tokens embedded in the newly discovered HAR files that had been downloaded by the threat actor.

2023-10-19 Okta Security identifies Cloudflare as the fifth and final Okta target of the adversary.

2023-10-19 Okta alerts all Okta customers with registered security contacts, confirming if they were or were not impacted by the security incident.

2023-10-20 Okta publishes public advisory at https://sec.okta.com/articles/2023/10/tracking-unauthorized-access-oktas-support-system

2023-10-20 to 2023-11-02 Okta is focused on helping all customers, answering their questions and rolling out remediation steps.

2023-11-02 Okta notifies all Okta customers with registered security contacts of the root cause and remediation steps.

2023-11-03 Okta publishes root cause and remediation steps at https://sec.okta.com/harfiles.

Remediation Tasks

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.

1. Binding Okta administrator session tokens based on network location (Complete)

Okta has released session token binding based on network location as a product enhancement to combat the threat of session token theft against Okta administrators. Okta administrators are now forced to re-authenticate if we detect a network change. This feature can be enabled by customers in the early access section of the Okta admin portal.

My observations

1. Throwing staff under the bus - reminds me of the Solarwinds CEO who threw the intern under the bus for the "solarwinds123" password snafu. It is obvious that the business has not done insider threat modelling.
2. Valid users will not create suspicious log. The interaction by the threat actor used valid credentials to access the system. So does your threat model includes validating authenticated sessions? Seems to be little or no internal validation of work done. If one is authenticated, it is assumed that ALL operations is valid and necessary. Something is very wrong with that assumption.
3. For critical systems, Okta only use username/passwords? While Okta specialise and promote secure authentication, why didn't Okta applications use 2FA/MFA? Is this an example of "Do as I say not as I do?" This form of hypocrisy in the cybersecurity industry is glaring and showing.
4. Customer distrust - also another recurring theme. On 29th, 1Password reported an incident. Okta assumes it's 1Password's problem, as they "may" have been infected by a malware or phishing exercise.

Honestly, at this point, even looking at the article doesn't reassure me, but brings more doubt about Okta's availability to deliver. The PR ready message with very generic yet cop-out statement does very little confidence on whether such a security company is indeed serious about security. Statements like "enhance monitoring" and "deployed additional protection" are statements that can be reused for any and all incidents. It's that bad.

tl;dr

Here's a quick graphical overview of the issue, thanks to Amitai Cohen (@amitaico)

Reference

[1] https://sec.okta.com/harfiles

[2] Naraine, B. (2023). Okta Hack Blamed on Employee Using Personal Google Account on Company Laptop. Retrieved from https://www.securityweek.com/okta-hack-blamed-on-employee-using-personal-google-account-on-company-laptop/