The Okta breach: The results of a leaked service account

Two weeks ago Okta reported that attackers managed to steal credentials and access Okta’s support case management system. This allowed the attackers to view files uploaded by some Okta customers as part of recent support cases. Some of the affected customers are Cloudflare and BeyondTrust, which have since released their own reports about the effects on customers. New updates shed more light on the breach, exposing the root cause of the incident was a leaked service account.  

During the time Okta released their initial incident report, several high-profile Okta customers revealed that they detected an intrusion to their systems using stolen credentials. These credentials were extracted from HAR files uploaded during the handling of the support ticket in Okta’s support system.

But how did the threat actor have access to Okta support tickets? 

In an update delving into the root cause analysis, Okta’s CISO sheds more light on the breach: a service account that had access to view all support tickets and read files that were uploaded to it, was used to steal these HAR files. 

And how did the password of this service account leak? 

Okta found that an employee who signed into their personal Google account on their Okta-managed laptop had these account’s credentials saved to their personal Google account.
Any rogue extension, app or compromised machine that had access to this personal Google account potentially could access these credentials.

So what can we learn from this?

• Service accounts skip security measures that normal accounts are subject to, such as MFA. Therefore, their credentials are extremely vulnerable.
• It is with utmost importance that service accounts follow the least privilege principle. To limit their permissions, their usage should be limited to very unique functionalities.
• Following the above recommendations may not be enough sometimes , and organizations need a way to detect unauthorized usage of service accounts. This can be, for instance,using behavioral analysis  of this service account and alerting on anomalies.

How Astrix protects your service accounts

With Astrix you can easily protect service accounts, as well as other programmable (non-human) access such as API keys, OAuth tokens, webhooks and more. Using Astrix you can:

1. Get an inventory of all service accounts in your environment. This is done by automatically detecting accounts which are used for automatic services. Astrix can also alert on misuse of accounts used for both human and non-human actions.
2. Get the risk context for each service account. This is based on the access permissions of the service account, and which resources it has access to.
3. Detect anomalous behavior. Astrix monitors and calculates the baseline activity for service accounts, based on features like IP, User-Agent, Methods and time-based metrics and  alerts on behavior anomalies as they happen like credential misuse and suspected breach.