Okta admits 366 customers may have been impacted by LAPSUS$ breach
Credit to Author: Malwarebytes Labs| Date: Wed, 23 Mar 2022 16:42:34 +0000
Through its usual means of communication, its Telegram channel, the LAPSUS$ group has posted screenshots of what appears to be superuser access to the Okta management console. As such, the group claims to have acquired “superuser/admin” access to Okta.com and gained access to Okta’s customer data, saying on Telegram:
BEFORE PEOPLE START ASKING: WE DID NOT ACCESS/STEAL ANY DATABASES FROM OKTA – our focus was ONLY on okta customers.
Yesterday morning, an Okta spokesperson said the company was investigating the matter, and admitted an attempted breach in late January 2022 in which customers were exposed for five days. The date visible in the LAPSU$ screenshots is 21 January, 2022. Okta provided a more detailed update later in the day, which we have summarised below.
Importantly, neither Okta nor LAPSU$ are claiming that Okta’s software has been compromised. Both are saying that the criminal hacking group acquired access to a user account with access to some customer data.
Okta
Okta is an access management company based in San Francisco. According to its own website, Okta serves over 15,000 organizations. Essentially, Okta software allows employees to log in using single sign-on—a central platform where employees can log in once in order to access resources that have been assigned to them by an organization’s IT staff. The kind of indentity-first approach to security is seen by some as an important underpinning of a Zero Trust security model.
LAPSUS$
LAPSUS$ is a relative newcomer to the cybercrime scene that first appeared in the summer of 2021. It has made a name for itself by leaking sensitive information from some big targets. The group is believed to hail from South America, based on its earliest targets and the near-native use of Spanish and Portuguese.
In recent events, LAPSUS$ claims to have hacked:
- Samsung (source code has been leaked)
- Nvidia (at least limited access has been proven)
- Mercado Libre (confirmed)
- Microsoft (under investigation)
- Okta (under investigation)
Okta’s statement
In an article on Okta’s website, CSO David Bradbury provided a timeline of the incidents which took place in January. According to Bradbury, a forensic examination identified a five-day window between January 16 and January 21 when a threat actor “had access to the Sitel environment”. Sitel is what Okta calls a “sub-processor”—a company that provides contract workers for Okta’s Customer Support Organization.
According to that post, the intruder “obtained remote access using RDP” to a Sitel-owned machine that was logged into Okta. The company says the access permissions of the user were limited, and that the tools support engineers have access to include Jira, Slack, Splunk, RingCentral, Salesforce, and an internally-built application called SuperUser.
The group has not explained how it got access to an RDP session. Brute-force attacks against RDP are common, as is phishing, but LAPSU$ is also known to bribe insiders for access. For example, on 10 March, it said it was looking to recruit tech company “employees/insiders” who were prepared to provide remote access, such as VPN or Citrix access.
To understand the scope of the breach, Bradbury says Okta examined all of the access performed by all Sitel employees to the SuperUser application for the five-day period in question. His conclusion was that the maximum potential impact of the breach is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel. Affected customers are promised “…a report that shows the actions performed on their Okta tenant by Sitel during that period of time”, so they can perform their own analysis.
In what is fast becoming a bizarre back-and-forth, LAPSU$ took to Telegram to respond to Okta’s assertions. Although the group doesn’t dispute that support engineers are limited to the applications Bradbury listed, it does take issue with whether that access is as benign as he suggests, commenting that it’s “…rather a bad security practice to store AWS keys in Slack channels”, and “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”.
Advice for Okta customers
What Okta customers can do to keep any damage contained is hard to say while we are still waiting for details. But here are a few pointers:
- Keep an extra pair of eyes on your access logs.
- Same for threat hunting and other logs.
- Change the privileged Okta passwords.
- Wait for more information.
- Inform your customers that you are on the case.
The post Okta admits 366 customers may have been impacted by LAPSUS$ breach appeared first on Malwarebytes Labs.