Okta provides new details on Lapsus$ attack

Authentication provider Okta released new information Wednesday on the breach that led to the exposure of its internal data.

In a blog post and two webinars, the company revealed that a single employee working for a subcontractor that handled customer support was compromised via remote management software and then exploited to gain records of hundreds of customers.

According to Okta, the infiltration point was a customer support agent working under the employ of Sitel, a subcontractor who was tasked with handling support on Okta services. The Lapsus$ attackers used Microsoft's Remote Desktop Protocol (RDP) to access the customer support agent's machine from afar.

From there, Okta said, the intruders were able to get into the agent's Okta customer support account and look at both internal company sites and customer service records. In total, approximately 366 companies, or around 2.5% of Okta's entire customer base, had their records exposed to the hackers, according to the company.

"The scenario here is analogous to walking away from your computer at a coffee shop, whereby a stranger has (virtually in this case) sat down at your machine and is using the mouse and keyboard," wrote Okta CSO David Bradbury in the blog post. "So while the attacker never gained access to the Okta service via account takeover, a machine that was logged into Okta was compromised and they were able to obtain screenshots and control the machine through the RDP session."

Okta said threat actors had control of the customer service agent account and access to Sitel's environment for a five-day period starting on Jan. 16. According to a new timeline in the blog post, Okta received an alert on Jan. 20 regarding a multifactor authentication (MFA) challenge for the customer service agent's account, which was rejected; Okta began investigating the suspicious MFA activity and suspended the account the following day, sharing indicators of compromise with Sitel.

On March 17, Okta received a summary report of the incident from a third-party forensics firm contracted by Sitel. Several days later on March 22, Lapsus$ published screenshots of the compromised account; Okta received the full forensics report that same day.

The Lapsus$ crew then posted additional information that countered the authentication vendor's initial reports about the extent to which the hackers had gained access to Okta's data earlier this year.

While Okta maintained that the attackers did not get into its network and lift any internal data that those outside of the company were not privy to, Bradbury noted that the agent would have had access to internal services including Jira, Splunk, Salesforce, Slack and RingCentral. However, he clarified that the Sitel agent did not have superuser rights within Okta, despite screenshots leaked by Lapsus$ that appeared to show a compromised superuser account.

"The majority of support engineering tasks are performed using an internally-built application called SuperUser or SU for short, which is used to perform basic management functions of Okta customer tenants," Bradbury said. "This does not provide 'god-like access' to all its users. This is an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles."

Bradbury admitted that the company should have done more to catch the breach and cut off access by the compromised agent's account.

"I am greatly disappointed by the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report," he said. "Upon reflection, once we received the Sitel summary report we should have moved more swiftly to understand its implications."

Sitel did not respond to request for comment at press time.

Bradbury wasn't the only person disappointed with Okta's response. The authentication provider has received criticism from several infosec professionals this week, including Amit Yoran, chairman and CEO of Tenable, which is an Okta customer.

"Two months is too long," Yoran said in an open letter. "This compromise should have been disclosed when Okta detected it in January or after a competent and timely forensic analysis."