Okta’s chief security officer has admitted his company should have moved faster to get the full report of a third-party contractor into a cyberattack earlier this year by the Lapsus$ extortion gang.
The week-long delay has led to some confusion by customers about the depth of the attack.
However, in a nine-minute video statement this morning, David Bradbury repeated the company’s view that the Okta identity and access management platform wasn’t hacked and that “no corrective action need be taken by customers.”
Okta knew the computer of a contract customer support employee who worked for a contact centre supplier called Sitel Group was compromised on January 20th, and an attacker tried to add a new multifactor authentication account. That attempt was quickly stopped by Okta. Sitel then hired a forensic investigation firm to look into the incident.
Bradbury said Sitel received that report on March 10th, and forwarded a summary to Okta on March 17th. That summary didn’t include copies of the screenshots that the attacker had taken.
The attacker had been in the Sitel environment for five days starting January 16th. It wasn’t clear from Bradbury’s statement whether that information was included in the summary.
But, he said, it was only when the Lapsus$ group published screenshots on March 22nd that Okta realized they were from the January 20th incident. And it was only hours later that Okta got its hands on the full Sitel report.
“I’m greatly disappointed by the long period of time that transpired between our initial notification to Sitel in January and the issuance of the complete investigation report just hours ago,” Bradbury said. “Upon reflection, once we received the Sitel summary report last week we should have in fact moved more swiftly to understand its implications.”
For five days, between January 16-21, the threat actor had access through the compromised support engineer’s computer to the Sitel environment, and through it to some Okta customers’ accounts. “This device was owned and managed by Sitel,” said Bradbury. “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. 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.”
Knowing that, over the past 24 hours Okta analyzed more than 125,000 log entries to figure out what actions were performed through Sitel during that period. As a result, Okta has determined that, at the most, 366 customers’ support accounts were accessed.
However, he said, customer support agents are unable to create or delete users. download customer databases, or access Okta source code repositories. As a result Okta feels “the information and the actions [of the attacker] were constrained.”
Bradbury didn’t take questions after reading the statement. But he did say the company will send a report to affected customers that shows the actions performed on their Okta tenant by Sitel so they can assess the risks. He also said he is open to speaking to the affected customers.