This article is more than 1 year old
Okta says Lapsus$ incident was actually a brilliant zero trust demonstration
Once former supplier Sitel coughed up its logs, it became apparent the attacker was hemmed in
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.
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 support engineer at Sitel – Okta's (former) outsourced customer service provider – attempted to reset a password to Okta's systems but did so from outside the expected network range and did not attempt to fulfil a multifactor authentication challenge. That request sent the reset email to a Sitel email address managed under Microsoft 365 and was made with the attacker's own kit. That last item was highly unusual. Okta can see authentication requests made using the VMs Sitel used to provide support services. But Okta cannot see inside Sitel's MS365.
Okta therefore suspended the user and inquired 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 there was more to the incident than had first been apparent.
In Winterford's telling, further analysis revealed that after the attacker failed with their attempt to compromise a Sitel worker with the password reset attempt , 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 able to covertly monitor the remote sessions of site or staff and potentially use the remote control capability of that tool."
- British cops arrest seven in Lapsus$ crime gang probe
- Microsoft investigates Lapsus$'s boasts of Bing, Cortana code heist
- Devil-may-care Lapsus$ gang is not the aspirational brand infosec needs
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 Okta. 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."
Lapsus$ extortionists dump Samsung data online, chaebol confirms security breachREAD MORE
Winterford asserted that the event shows that zero trust security – and Okta's implementation of it – worked.
Multifactor authentication repelled the attack and prevented takeover of the Sitel engineer's Okta account, 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 viewed. 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, but does not blame Sitel for 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 situation.
On the contrary, Winterford said, Okta's position is "we 100 percent own this, irrespective of any commercial relationships with our suppliers." ®