Okta has completed its analysis of the March 2022 incident that saw The Lapsus$ extortion crew get a glimpse at some customer information, and concluded that its implementation of zero trust techniques foiled the attack – and that its (former) outsourced customer service provider Sitel was largely to blame for the confusion surrounding the incident.
So said Brett Winterford, Asia-Pacific and Japan chief security officer of the identity-management-as-a-service vendor, at the Gartner Risk and Security Summit in Sydney today.
Winterford explained that the incident started in January when an Okta analyst observed a Sitel support engineer attempting to reset a password – but did so from outside the expected network range, did not attempt to fulfil a multifactor authentication challenge, and requested the new login details be sent to a Sitel email address managed under Microsoft 365 rather than the expected Okta address managed under Google Workspaces. Okta can see what happens in the virtual desktops it provides to Sitel engineers, and in the Workspaces it provides to those engineers. But Okta cannot see Sitel’s MS365.
That combination saw Okta suspend the user and inquire about any issues at Sitel, which admitted to compromise of an Active Directory account.
“We initially took their word that this compromised account had been contained very quickly, and that there was zero impact to Okta or its customers,” Winterford recalled.
Once Lapsus$ published its screenshots, Okta came to feel that Sitel had not told the whole story.
In Winterford’s telling, the AD issue and subsequent attack on a virtual desktop Sitel admitted to were not the full extent of the matter, because the attackers got nowhere with that approach.
But they kept trying and found a thin client solution on Sitel’s network.
“This thin client solution had been configured to allow remote sessions to be monitored by administrators on that network, to the degree that they could also interact with the mouse and keyboard of that remote session if they chose,” Winterford explained, adding that the screenshots Lapsus$ published showed the thin client environment. “We now assess that the threat actor must have compromised this thin client environment in some way and was unable to covertly monitor the remote sessions of site or staff and potentially use the remote control capability of that tool.”
The actor was able to view and interact with apps that the legitimate support engineer had already authenticated to – but couldn’t just take over, as that would be an obvious red flag.
We took Sitel’s word the compromised account had been contained very quickly.
Okta’s assessment is that when a support engineer stepped away from their desk, leaving the session connected to Okta’s support environment accessible, the threat actor took the screenshots Lapsus$ published.
“They were able to view and interact with that [thin client] session for about 25 minutes,” Winterford explained. “During those 25 minutes, they ran searches in our customer support tool that returned results to your customers. And we can see from our logs that the threat actor clicked on a few features in the customer support tool, none of which really furthered their position.”
“They tried to access the admin console of one customer, but that would have required the consent in the admin console of that customer from their administrator, so that was unsuccessful,” he added.
“They could potentially have done password and MFA resets, but they would have had to have access to the target inbox of the user that they were resetting.”
“They also tried to open other applications from the Okta dashboard, but that didn’t work for them either.”
“So basically, you’ve got a threat on the site or network for five or six days undetected until they tried to leverage that position to compromise. And then in a bit of a last ditch scramble they’ve found a workaround and they’ve tried for 25 minutes to abuse that position and not been particularly successful.”
Winterford asserted that the event shows that zero trust security – and Okta’s implementation of it – worked.
Multifactor authentication repelled the attach on the VM, then the customer support tool required extra authentication to access tools that would have allowed the attacker to work with more privileges than those afforded to an outsourced support engineer.
“The threat actor couldn’t really successfully perform any configuration changes or MFA or password resets and finally, when the threat actor opened the Okta dashboard to try and access more applications, they were presented with a step up authentication they were unable to bypass.”
“Within a few hours of those screenshots, we double- and triple-checked our authentication logs,” Winterford said. “There’d been no password or MFA recent events” or other activity Okta felt indicated the attack had gone any further than shoulder surfing the thin client session.
Okta shared its own logs with customers that the support engineer could conceivably have controlled. Winterford said customers were satisfied they had been safe.
Sitel took “about two weeks” to produce its logs of the thin client environment.
“With those logs in hand, we could very quickly wrap up the investigation,” Winterford said.
Okta was not satisfied with Sitel’s actions and has parted ways with the company over the incident.
The identity management vendor has made other changes, too. Its new support crew uses Okta-managed devices – an arrangement Winterford said is expensive but necessary. It’s intended to give the company confidence that it has the observability needed to detect and prevent future incidents – and to do so inside eight hours, rather than the two to three weeks it took to unpick the Lapsus$ incident.
Changes to incident response are also in the works. Winterford said Okta acknowledges its initial response to Lapsus$’s allegations made it possible to conclude Okta was not taking responsibility for the compromise at Sitel.
On the contrary, Winterford said, Okta’s position is “we 100 percent own this, irrespective of any commercial relationships with our suppliers.” ®