toggler

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.

SELECT PUBLISHED  EVENT_TIME,
              EVENT_TYPE  EVENT_TYPE,
              ACTOR_DISPLAY_NAME  DISPLAY_NAME,
              ACTOR_ALTERNATE_ID ACTOR_ALTERNATE_ID,
              TARGET_USER_ALTERNATE_ID  TARGET_USER_ALTERNATE_ID,
              CLIENT_IP_ADDRESS  CLIENT_IP_ADDRESS,
              CLIENT_USER_AGENT_RAW_USER_AGENT  CLIENT_UA
FROM RAW.OKTA_LOGS
WHERE EVENT_TIME > '2022-01-15 00:00:00'
             AND ACTOR_ALTERNATE_ID='christian.rojas@okta.com'
             OR   TARGET_USER_ALTERNATE_ID='christian.rojas@okta.com'

Additionally, it is advised to take note of any Okta technical support access to your Okta tenant. If this option is enabled by your organization (configurable through the Okta administration interface), it is possible that your account was accessed by Okta’s technical support. While some results may be found, it’s not necessarily a smoking gun, and should be investigated further. The following queries will surface any activity in your tenant by an Okta support engineer, and indicate the nature of their activity.

SELECT DISTINCT ACTOR_ALTERNATE_ID,
              EVENT_TYPE,
              COUNT(DISTINCT TARGET_USER_ALTERNATE_ID) AS COUNT_OF_AFFECTED_USERS,
              ARRAY_AGG(DISTINCT TARGET_USER_ALTERNATE_ID),
              ARRAY_AGG(DISTINCT DISPLAY_MESSAGE),
FROM RAW.OKTA_LOGS
WHERE ACTOR_ALTERNATE_ID LIKE '%@okta.com'
             AND NOT ACTOR_ALTERNATE_ID= 'system@okta.com'
             AND   PUBLISHED > '2022-01-15 00:00:00'
GROUP BY ACTOR_ALTERNATE_ID, EVENT_TYPE

Using Hunters’ lifetime log retention policy, we can take advantage of historical login activity we have and compare it with the last 2 months of the breach. The following query will search for new IPs that have been seen since 2022-01-15, but not in the whole year before. 

(NOTE: Those that haven't been ingesting Okta logs for at least a 6-month period don’t need to run this query.)

WITH DISTINCT_IP AS (
              SELECT DISTINCT CLIENT_IP_ADDRESS
              FROM RAW.OKTA_LOGS
               -- look for a distinct list of ip addresses in the last year
              WHERE PUBLISHED < '2022-01-15 00:00:00' and PUBLISHED > '2021-01-15 00:00:00')
SELECT PUBLISHED  EVENT_TIME,
              EVENT_TYPE  EVENT_TYPE,
              ACTOR_DISPLAY_NAME  DISPLAY_NAME,
              ACTOR_ALTERNATE_ID  ACTOR_ALTERNATE_ID,
              TARGET_USER_ALTERNATE_ID  TARGET_USER_ALTERNATE_ID,
              CLIENT_IP_ADDRESS  CLIENT_IP_ADDRESS,
              CLIENT_USER_AGENT_RAW_USER_AGENT  CLIENT_UA
FROM RAW.OKTA_LOGS
WHERE CLIENT_IP_ADDRESSES NOT IN (
               SELECT * FROM DISTINCT_IP)
               -- look for logins of ip addresses that weren't seen in the last year but after 2022-01-15 00:00:00, reported data of compromised

             AND PUBLISHED > '2022-01-15 00:00:00'

It is recommended to review all password and token resets that occurred during the reported breach time. The following query will aggregate all the granter users and exclude any self-resetting operations. 

SELECT ACTOR_ALTERNATE_ID,
              CASE 
                        WHEN EVENT_TYPE=
'user.account.reset_password' THEN 'Password Reset'
                        WHEN EVENT_TYPE='user.mfa.factor.deactivate' THEN 'Factor Deactivation'
                        ELSE 'Full MFA Reset'
              END AS EVENT_TYPE,
              LEGACY_EVENT_TYPE,
              OUTCOME_RESULT,
              COUNT ( DISTINCT TARGET_USER_ALTERNATE_ID ) AS COUNT_AFFECTED_USERS,
              ARRAY_AGG ( DISTINCT TARGET_USER_ALTERNATE_ID ) AFFECTED_USERS,
              ARRAY_AGG ( DISTINCT CLIENT_USER_AGENT_RAW_USER_AGENT)
FROM RAW.OKTA_LOGS
WHERE EVENT_TYPE LIKE ANY ('user.account.reset_password', 'user.mfa.factor.deactivate', 'user.mfa.factor.reset_all')
               -- exclude instances where user resets their own password
AND NOT (ACTOR_ALTERNATE_ID = TARGET_USER_ALTERNATE_ID OR LEGACY_EVENT_TYPE LIKE '%user_auth.self%')
               AND PUBLISHED > '2022-01-15 00:00:00'
GROUP BY ACTOR_ALTERNATE_ID,
                    EVENT_TYPE,
                    LEGACY_EVENT_TYPE,
                    OUTCOME_RESULT
ORDER BY COUNT_AFFECTED_USERS

How the Hunters Platform Can Help

Hunters provides several out-of-the-box detection capabilities that can identify suspicious activities from compromised accounts. These will help detect past attacks and stop potential future attacks. We are constantly adding detectors to the Hunters SOC Platform in order to identify more potential threats.

In order to complement this, Hunters is revisiting historical customer data and looking for patterns that might leverage hindsight to better pinpoint suspicious activity that has happened in the past, using thresholds that normally would create a lot of false positives and noise, such as monitoring account access from abnormal locations or access from new or unsupervised devices.

For Hunters customers, we have created visibility dashboards in our platform for Okta Alerts, Account Activities, Privileges Granting, and Factor Deactivation and Password Settings.

Hunters SOC Platform supports different detectors based on the Okta Zero Trust approach:

Okta Administrative Access from Host Without an EDR Agent

Detects a login event to the Okta administration interface from a host which is suspected to not have an EDR agent installed. Usually such an event takes place when an unmanaged host is used to connect to the Okta administration interface, whereby such a host might be either a corporate endpoint without an EDR agent, a personal device of the user accessing the Okta administration interface, or an attacker's machine resulting from a compromise of a user's credentials.

Okta Admin Privilege Granted

Detects the granting of administrative privileges within Okta to a user which previously did not exhibit such privileges. When performed in a malicious context, this behavior may indicate an attacker attempting to escalate privileges within the organization's Okta environment.

Staying Vigilant

In addition, Team Axon is conducting a proactive hunt on relevant customer environments and will notify customers in case of suspicious activity. We have no reason to believe that anyone in our existing network has been breached, but we continue to monitor aggressively.

We also recommend following reputable security news organizations for further developments as further information about this breach continues to become available.