Lapsus$ Threat Actor Demonstrates Access to Backend Okta Tooling

Security Advisory, Vulnerability Notification Leave a comment

Summary


Okta is one of the premier identity providers in the World and is trusted by thousands of customers. The recently known Lapsus$ threat actor group, that has been very active lately targeting Microsoft and Nvidia, has allegedly breached Okta’s customers environments. The group published screenshots of environments that they were able to access. The threat actor claims that they have acquired full admin access to Okta.com and they also claim that “our focus was ONLY on Okta customers”.


While Okta has confirmed that an attempt to breach Okta in late January 2022 was investigated and contained at the time, Okta has now acknowledged that after thorough investigation they have currently identified approximately 2.5% of their customers who have been impacted thus far.


Only customers of the “core” Okta product are possibly impacted, there is no impact to Auth0
customers, nor to customers leverage their HIPAA and FedRAMP certified platforms. Okta said that the impacted customers have already been contacted by email.


Finally, Okta’s investigation showed that during a five-day window of time (Jan 16-21, 2022) the threat actor had access to a third party (contractor) support engineer’s laptop. The impact is limited to the access of the support engineer. Support engineers have access to limited data like Jira tickets or list of users and can reset passwords, multi-factor authentication (MFA). But Okta confirmed that they are unable to create and delete users, neither are they able obtain those passwords or download customers databases.


What the CFC recommends


If your organization is using Okta and has been notified by Okta that you are impacted, the CFC
strongly recommends contacting your incident response partner to help understand the potential extent of the attack campaign.


We also recommend quickly suspending accounts that may have had their credentials or MFA
devices reset by the threat actors prior to validating that such access has not been abused by the
threat actor.


Even if Okta has not identified that you are an impacted customer, the CFC strongly recommends
that all Okta customers take the following actions:

  • Search the Okta system logs for signs of compromise since January 16, either in a SIEM or directly in Okta logs. This can include things like password change or MFA device or token updates.
    • The MDR Detection Engineering and IR teams recommend searching for the following event types:
      • user.account.reset_password
      • user.mfa.factor.update
      • system.mfa.factor.deactivate
      • user.mfa.attempt_bypass
      • user.session.impersonation.initiate
  • Compile a list of accounts that were found in Okta since the beginning of 2022 and review with the owners of the accounts whether those changes are legitimate
  • Follow best practices regarding identity management with a specific focus to MFA

What is the CFC doing?

The CFC leverages Auth0 as a Multi-Factor and Authorization provider. Due to these events the CFC is closely working with Auth0 to ensure our internal users are not impacted. The Kudelski Security DevOps and Security Engineering team has worked with Okta to confirm that this time Auth0 platform is not known to be impacted by these events.

However, although Okta has not yet identified any suspicious activity with regards to the Auth0 platform, the Kudelski Security has worked to ensure no suspicious activity was identified with regards to user MFA devices.

Additionally, it’s important to note that the CFC does not leverage Auth0 to store internal user credentials. Auth0 is used to provide Multi-Factor Authentication and Authorization to provide access to internal CFC systems and infrastructure. This dual vendor strategy ensures that no single vendor is a single point of failure. Successful compromise of the CFC’s environment would require that a threat actor compromise both the CFC’s identity and credential provider (Azure Active Directory) and Auth0 in order to gain access to internal CFC systems or that threat actors active a “single vendor” break the glass scenario that would notify the Kudelski Security DevOps team. No such activity has been identified.

The CFC will continue to monitor the situation and will provide updates to clients as more information is available. At this time, there is no indication that the CFC’s Auth0 deployment has been affected and no indication that a threat actor has been able to reset MFA devices.

Sources

Leave a Reply