Okta revises LAPSUS$ impact upwards to potentially 2.5% of customers

Company says a 'small percentage' of customers could have had their data viewed or acted on, and simple maths turns that number into 375 customers.
Written by Chris Duckett, Contributor

Okta has again updated its blog post related to the LAPSUS$ intrusion from January first revealed by the hacking gang on Tuesday.

"After a thorough analysis of these claims, we have concluded that a small percentage of customers -- approximately 2.5% -- have potentially been impacted and whose data may have been viewed or acted upon. We have identified those customers and are contacting them directly," Okta CSO David Bradbury said.

"If you are an Okta customer and were impacted, we have already reached out directly by email."

Earlier this month in its fourth-quarter results, the company said it had 15,000 customers, of which 2.5% is 375.

The company said it would be conducting a pair of technical webinars on the event on Wednesday.

See also: Okta: Lapsus$ attackers had access to support engineer's laptop

For its part, LAPSUS$ said it gained access to a superuser portal that could reset the password and multifactor authentication of 95% of clients.

"For a company that supports zero-trust, support engineers seem to have excessive access to Slack? 8.6k channels?" the group said.

"The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems."

The group called on Okta to hire a cybersecurity firm and to publish any report they complete. It also claimed Okta was storing AWS keys within Slack.

LAPSUS$ also added that many of its members were on holidays for the rest of the month.

"We might be quiet for some times," the group said.

"Thanks for understand us -- we will try to leak stuff ASAP."

Meanwhile at Redmond: Microsoft confirms LAPSUS$ hit account with limited access after gang released alleged Bing and Cortana source

Speaking to ZDNet last week, Cisco advisory CISO Helen Patton said CISOs were separating themselves operationally from breach reporting requirements.

"So now we've got lawyers who are making a decision about whether something is material enough to require a report, which is not really the spirit of the regulation. But I've seen it in Australia, and I'm seeing it overseas as well," she said.

"This is a coping mechanism because the reporting requirements are sort of vague."

Patton said due to legal folk wanting to contain events as much as possible, they would start low and escalate the impact of events rather than starting high and walking back.

"That puts the rest of the rest of us at risk, actually," the advosry CISO said.

"So the question is, what is the right level to go with? Do you oversell it or undersell it, in order to not only protect yourself, but protect the ecosystem that you're working in?"

"We are rewarded by underselling ... in a lot of ways reputationally, legally, but from a risk perspective, we might want to actually oversell it because that gets more people on alert faster and hopefully gives you a faster response."

Patton said companies that issued multiple upwards revisions could appear as though they did not know what they were doing.

"It's not until you've had a certain amount of time to explore the incident, respond to the incident, learn from the incident that you really have good quality information," she said.

"But our regulators want us to tell them immediately when something looks funny. And there's lots of things that look funny in our environments, because our environments they're inherently odd.

"They're going to get a lot of really bad signals early on, and we're going to have to work out how do you talk about that publicly when the information is really asymmetrical in terms of what you know, and what's actually happening. It's a problem."

Updated at 01:35pm AEDT, 23 March 2022: Added further information on LAPSUS$.

Related Coverage

Editorial standards