Lessons from the Recent Okta Breach

Securing user and service accounts

An attack first detected in late September and disclosed in October (see here), enabled hackers to access Okta's internal customer support management system and get access to sensitive customer information.

However, now it seems the same threat actor actually ran and downloaded a report that contained the names and email addresses of all Okta customer support users (see report here and Okta update here).

What are the key lessons learned?

• The root cause in this attack appears to be a compromised service account used to access the support application. Service accounts are often used to provide automated access to APIs for various purposes, such as integration between different systems or performing routine tasks. As use of automation grows, so does the proliferation of service accounts, which are often unmanaged and unprotected with MFA. Organizations should pay increased attention to this growing part of the attack surface.

• The stolen data in this attack includes usernames and email addresses, which raises the concern of possible phishing or social engineering attacks against Okta customers, especially targeting IT service desks which handle account management requests for employees. A similar incident brought down the entire Vmware ESXi infrastructure at MGM Resorts (see here). Organizations should fortify helpdesk procedures and make them more resilient against social engineering scenarios.

• Finally, multifactor authentication (MFA) should be enabled by default, especially when accessing administrative systems and apps. Standard mobile push based MFA might not be enough to thwart phishing attempts: that's why phishing resistant authenticators (such as FIDO2) should be considered (see here).