Shadow IT use at Okta behind series of damaging breaches

An Okta employee who signed into their personal Google account on a company-owned device appears to have been the source a breach that is now known to have impacted a total of 134 downstream customers, including several other suppliers of authentication services.

The breach, which began on 28 September and lasted until 17 October, saw an undisclosed threat actor gain unauthorised access to Okta’s customer support system where they were able to hijack files containing session tokens that could then be used to conduct session hijacking attacks.

The threat actor was able to attack five of the 134 customers, three of which – 1Password, BeyondTrust and Cloudflare – have spoken publicly about the incident.

Okta CISO David Bradbury said: “The unauthorised access to Okta’s customer support system leveraged a service account stored in the system itself. This service account was granted permissions to view and update customer support cases.

“During our investigation into suspicious use of this account, Okta Security identified that an employee had signed into their personal Google profile on the Chrome browser of their Okta-managed laptop.

“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,” he said.

Bradbury added: “We offer our apologies to those affected customers, and more broadly to all our customers that trust Okta as their identity provider. We are deeply committed to providing up-to-date information to all our customers.”

Okta said its investigation had been complicated by a failure to identify file downloads in customer support vendor logs. This is because when a user opens and views support files, the system generates a specific log event and record ID and ties it to the file – but if the user navigates directly to the Files tab in the customer support system (which the threat actor did do) they generate a different log event and a different record ID.

Because its investigations at first focused on access to support cases, meaning it assessed the logs linked to these cases, it took until 13 October – when BeyondTrust provided Okta with a suspicious IP address it had been able to attribute to the attacker – for Okta to identify the additional file access events and link them to the compromised employee account.

Indeed, for some time, Okta said it suspected that 1Password – the first customer to contact it – had been the victim of a malware or phishing attack.

This may go some way to explaining why BeyondTrust, which first reported suspicious activity in its Okta tenant on 2 October, had complained that Okta’s response had been slower than ideal, and its chief technology officer (CTO) said he had struggled to convince Okta that the incident had originated through its systems.

Okta has now published details of what it has done to remediate the situation. The compromised customer service account has been disabled and it has implemented a specific configuration option within Chrome Enterprise that stops employees from signing into Chrome on an Okta-run laptop with a personal profile. It has also deployed additional detection and monitoring rules across its customer support system.

As an additional step for customers, it has released session token binding based on network location as a product enhancement to help mitigate the threat of session token theft against Okta admins, who will now be made to reauthenticate if a network change is detected. This feature is not being rolled out by default, but will need to be enabled in the early access section of the Okta admin portal.