Okta says two customers breached during January security incident

Okta this week concluded its investigation into a headline-grabbing security incident that came to light in March, finding that two of its customers were breached through its customer support partner Sitel.

The access management company initially said 366 customers were affected by the incident, which took place between January 16 and January 21. Okta landed on the 366 figure because those were Okta customers whose tenants were accessed by any Sitel customer support engineer within that time frame.

But in a statement this week, Okta revised that assessment, determining that the access was limited to two of its customers. It also announced that it has “terminated its relationship with Sykes/Sitel.” 

“The threat actor actively controlled a single workstation, used by a Sitel support engineer, with access to Okta resources. Control lasted for 25 consecutive minutes on January 21, 2022. During that limited window of time, the threat actor accessed two active customer tenants within the SuperUser application (whom we have separately notified), and viewed limited additional information in certain other applications like Slack and Jira that cannot be used to perform actions in Okta customer tenants,” Okta Chief Security Officer David Bradbury said. 

“The threat actor was unable to successfully perform any configuration changes, MFA or password resets, or customer support ‘impersonation’ events. The threat actor was unable to authenticate directly to any Okta accounts.”

'We made a mistake'

Okta has faced significant backlash for its handling of the incident. Criminal extortion group Lapsus$ initially claimed it accessed Okta’s systems and shared screenshots of stolen documents in late March, setting off a weeks-long scramble of statements from Okta and Sitel. 

When pressed on why the company never notified customers about the breach, Bradbury apologized and blamed Sitel for failing to provide them with the results of an investigation until March 17. 

“We want to acknowledge that we made a mistake. Sitel is our service provider for which we are ultimately responsible. In January, we did not know the extent of the Sitel issue – only that we detected and prevented an account takeover attempt and that Sitel had retained a third party forensic firm to investigate,” Okta said in the FAQ that was released in March.  

“At that time, we didn’t recognize that there was a risk to Okta and our customers. We should have more actively and forcefully compelled information from Sitel. In light of the evidence that we have gathered in the last week, it is clear that we would have made a different decision if we had been in possession of all of the facts that we have today.”

Members of Lapsus$ took to Telegram immediately after the first statement was released, criticizing the company for its comments and airing several troubling – but unconfirmed – facts about Okta’s security practices.

The company has more than 15,000 customers, including the US Justice Department.

Sitel ended up releasing its own statement on the situation, citing a legacy network from a recent acquisition as the cause of the security incident.

Security researcher Bill Demirkapi released a copy of a report that he said was compiled by cybersecurity firm Mandiant about the breach, describing the step-by-step process Lapsus$ hackers used to gain access to Sitel’s systems. 

New documents for the Okta breach: I have obtained copies of the Mandiant report detailing the embarrassing Sitel/SYKES breach timeline and the methodology of the LAPSUS$ group. 1/N https://t.co/z05uQYclg9 pic.twitter.com/e0T4EdWPxT

— Bill Demirkapi (@BillDemirkapi) March 28, 2022

According to the documents, the hackers exploited CVE-2021-34484 before using off-the-shelf tools from GitHub to bypass the company’s FireEye endpoint agent. 

From there, the hackers downloaded popular credential dumping utility Mimikatz and created backdoor users into Sitel’s environment after gaining access to an Excel document titled “DomAdmins-LastPass.xlsx.”

Further modifications

In its statement this week, Okta said they only began notifying potentially affected customers on March 22, one day after Lapsus$ began releasing screenshots of information it stole. 

The statement also tacitly blames Sitel for the time discrepancy. Okta said it is reviewing its security processes “to accelerate updates from third parties and internally for potential issues, both big and small.”

In addition to terminating its deal with Sitel, Okta said it will begin forcing sub-processors who provide Support Services on Okta's behalf to comply with new security requirements that include adopting “Zero Trust” security architectures and authenticating through Okta’s IDAM solution for all workplace applications.

“Okta will now directly manage all devices of third parties that access our customer support tools, providing the necessary visibility to effectively respond to security incidents without relying on a third party,” Okta said. 

“We are making further modifications to our customer support tool to restrictively limit what information a technical support engineer can view. These changes also provide greater transparency about when this tool is used in customer admin consoles (via System Log). We are reviewing our communications processes and will adopt new systems that help us to communicate more rapidly with customers on security and availability issues.”