Okta Breach by Lapsus$ – What We Know and What You Can Do

The authentication service provider, Okta, is investigating a breach in their application after both the Lapsus$ hacking group published screenshots, and a third party, Scytl, reported an attempt via a support engineer account earlier this year. The latest information we’ve received is that 366 Okta customers were impacted by the breach.

Background

Statement from Okta CEO: “In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. 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.”

Due to the potentially severe impact a compromise of an SSO provider could have on their customers, we recommend taking proactive measures to mitigate risk.

Attacker motivations 

Lapsus$ is known to use an “extortion and destruction model,” according to Microsoft, who have been following the hacker group’s tactics for some time now. In this sense, they do not incorporate a quiet ransomware protocol; instead, they seem to have no qualms about advertising their exploits in order to gain attention, grow their organization, and expand their exploits. The group has claimed responsibility for hacking Okta, Microsoft, Nvidia, Samsung, Electronic Arts, and Vodafone.

There is no doubt that getting access to an SSO provider is a significant achievement from an attacker perspective, be it nation-state or a criminal actor. In the Okta breach, the attackers chose to publish a screenshot that establishes their alleged access. A conservative estimation would be that the access was eventually lost and thus the group has nothing to lose and everything to gain by publishing the activity. It is also possible that the attack was coordinated by a teenage hacker.

The group’s reputation is likely a key factor in their ability to successfully extort funds (crypto or otherwise) and to attract collaborators to further enhance their reach. Lapsus$ has been actively recruiting online, so it would stand to reason that this is a part of their growth plan. 

As information continues to become available about the attack, we will most likely see more accounts of what kind of damage was done through the Okta intrusion and what their motivations may have been.

Potential implications to Okta customers

Any attacker that has gained access to Okta has many possible ways to leverage such access. 

On the lighter end of the scale, the attacker can use access rights that are normally available to legitimate users. When this is the case, there is a good chance that anything done by the attacker after initially obtaining access would be captured by the various security tools in a company’s security stack, which can serve as a way to spot the attacker behavior. The challenge will then be to single out the attacker activities from those of the legitimate user whose credentials are being used by the attacker.

In the middle of the scale, an attacker could provision a new user altogether to access your organization’s resources. This method could potentially cause more damage than the former, if a newly created user has high-level access to resources that normally don’t have that level. In such a case, focusing your investigation on your crown jewels or those the attacker considers to be their high prize, like your most critical data, will help.

On the far and heavier side of the scale is an attacker that manages to leverage their initial access to gain privileged access to any resource in the organization. The reward here is the highest by far in that attackers could obtain access to massive amounts of internal data. Lapsus$ is known to employ extensive social media practices both before and after obtaining higher levels of access in order to achieve their goals. If an attack of this magnitude is suspected, any anomalous access granted by the SSO should be carefully inspected.

How to respond

Okta is Hunters’ authentication service provider, so we took action immediately in order to mitigate this potential threat. 

Here are the steps we recommend taking if your SSO and Identity Management service provider is Okta:

• Examine the legitimacy of all existing accounts in Okta - admins as well as regular users
• Comprehensively analyze all access origins to Okta in past months to spot access from suspicious locations
• Verify that MFA is applied to all accounts on a mandatory basis
• Reset passwords of select accounts
• Disable Okta support access to the accounts
• Examine the legitimacy of Okta's support employees logged to your environment in the past three months (threat hunting query provided below)
• Examine the legitimacy of all password / token resets that were not performed by the user themselves (visible in the "Okta Visibility" Dashboard in Hunters)
• Rotate critical credentials managed in Okta solutions, including API keys, passwords, and Multi-Factor Authentication tokens.

It is also important to note that the alleged breach happened in the beginning of 2022, and therefore you should apply detection and mitigation efforts not only looking forward, but also in retrospect to spot potential compromise in the past few months. 

We assume that the publication of this attack by the threat actor signifies the end of the current campaign, and not its beginning. Given that the breach dates back three months, we recommend looking at your logs throughout that entire time frame. 

Remember that breaching an SSO provider grants the attacker Initial Access  (TA001) to your organization, and you should not only focus on that access point, but rather look for other activities the attacker might have carried out using that access.

Threat hunting queries

Intelligence resources revealed that the initial access was facilitated using a compromised RDP server of a customer support engineer working for a third-party provider. The following query will look for Okta logs associated with the compromised customer support engineer (denoted by the email christian.rojas@okta.com) since 2022-01-15 00:00:00, the date of the breach.