Okta, a provider of centralized authentication services to thousands of organizations around the world, has now admitted that one of its corporate laptops was hacked in January 2022 and that an attacker (Lapsus$) had access to Okta’s internal network and support tools for five days. Okta’s claim is “that its service remains secure and fully operational”, however, this raises larger questions about how Okta got here and how centralized service providers can create large amounts of systemic risk.
Who is Lapsus$?
Lapsus$ is a moniker for a criminal group whose primary objective is to gain access to and steal sensitive data for future extortion demands. This represents an evolution from the “hit-encrypt-and-run” tactics we’ve observed from other ransomware groups and has the potential to be much more damaging in terms of the loss of confidential and proprietary information.
Lapsus$ has claimed responsibility for a number of high-profile hacking attacks against Nvidia, Samsung, Microsoft, and Ubisoft, in some cases stealing hundreds of gigabytes of sensitive data, including sensitive materials like code signing certificates which have later been used to facilitate other attacks.
Lapsus$ posted screenshots on its Telegram channel showing what they claim to be Okta’s internal systems, including screenshots of Slack channels and Cloudflare features.
Any hack of Okta could have severe ramifications for the thousands of corporations, universities, and governmental agencies that rely on Okta for authenticating user access to internal systems.
The latest information we have:
According to a statement released by Okta on Tuesday, an attacker only had limited access during that five-day period – limited enough that Okta claims that customers should not take any corrective action.
David Bradbury, Okta’s chief security officer, explains what is and isn’t at stake when one of the company’s support engineers is compromised:
“The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data – for example, Jira tickets and lists of users – that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users but are unable to obtain those passwords.”
The Lapsus$ hacking group claims that it had been using its “Superuser/Admin” credentials to log into Okta’s systems for two months, not just five days, and claimed that it used that access to gain access to the company’s customers. An article in the Wall Street Journal reports that Okta reported over 15,000 customers around the world in a recent filing. According to its website, Peloton, Sonos, T-Mobile, and the FCC are among its customers.
Okta spokesperson Chris Hollis told The Verge earlier this week that the company has not found evidence of an ongoing attack. “In late January 2022, Okta detected an attempt to compromise the account of a third-party customer support engineer working for one of our sub processors. The matter was investigated and contained by the sub processor.” Hollis said. “We believe the screenshots shared online are connected to this January event.”
“Based on our investigation to date, there is no evidence of ongoing malicious activity beyond the activity detected in January,” Hollis continued. It appears, however, that Lapsus$ had access for a few months, as it claimed in their Telegram channel.
In January, Okta allegedly terminated its support engineer’s sessions with Okta and suspended the account but said it has only now received a final report from its forensics firm.
What to do if you are an Okta customer?
If you are also an Okta customer, you should reach out to them for further information. Here are some recommendations:
Enable MFA for all user accounts. Passwords alone do not offer the necessary level of protection against attacks. We strongly recommend the usage of hard keys, as other methods of MFA can be vulnerable to phishing attacks.
Investigate and respond:
a. Check all password and MFA changes for your Okta instances.
b. Pay special attention to support initiated events.
c. Make sure all password resets are valid or just assume they are all under suspicion and force a new password reset.
d. If you find any suspicious MFA-related events, make sure only valid MFA keys are present in the user’s account configuration.
Make sure you have other security layers to provide extra security in case one of them fails.
OKTA Sub Processors Information: Click Here
Conclusion
Measured’s security and IT teams are still investigating this compromise. Should further information become available that indicates compromise beyond the January timeline, we will publish a second posting summarizing our findings.
Additionally, we have requested additional logs and information from Okta. In the event that new information emerges that changes our assessment of the situation, we will update this blog or write further posts.
For more information, please contact us at [email protected]
