LAPSUS$ Impact on Okta

“Caution is the eldest child of wisdom.”

There is a fine line between what may seem like a minor, contained event and the actual damage LAPSUS$ could have inflicted when they had access to the right tools via the support engineer’s laptop.

Enigma encryption-machine
Enigma encryption machine - Photo by Mauro Sbicego / Unsplash

First, let’s take a look at an interesting piece from Okta’s statement:

“It’s important to understand that the access that a support engineer has is limited to basic duties in handling inbound support queries. Support engineers use a number of customer support tools to get their job done including Okta’s instances of Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce.”
Okta’s Investigation of the January 2022 Compromise
This update was posted at 8:50 AM, Pacific Time. ++ On March 22, 2022, nearly 24 hours ago, a number of screenshots were published online that were tak...
Okta's Investigation of the January 2022 Compromise

If you are familiar with Okta, the pathway to lateral movement is self-evident:

  1. Having access to support tickets and Splunk means that the attacker can filter through tickets and system events to discover customer tenants where Okta Support access was enabled
  2. Using the Support access combined with SuperUser privilege, they could bypass authentication policies and reset MFA, and then perform operations such as creating a new Super Admin, disabling or changing policies, editing the app assignment username to gain access to 3rd party apps (email, CRM, HR systems, etc.)
Okta Support access toggle, found in the Okta Admin UI
Okta Support access toggle, found in the Okta Admin UI

Okta claims that:

In trying to scope the blast radius for this incident, our team assumed the worst-case scenario and examined all of the access performed by all Sitel employees to the SuperUser application for the five-day period in question. Over the past 24 hours we have analyzed more than 125,000 log entries to ascertain what actions were performed by Sitel during the relevant period. We have determined that the maximum potential impact is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel.

What now?

This is Okta's latest update on the matter:

Updated Okta Statement on LAPSUS$
This update was posted at 6:31 PM, Pacific Time. ++ As we shared earlier today, we are conducting a thorough investigation into the recent LAPSUS$ clai...
Updated Okta Statement on LAPSUS$

Any Okta customer that had Support interactions in January 2022 should pay attention to those two events in their Okta System Log:

eventType eq "user.session.impersonation.grant"

Followed by any of the following:

eventType eq "user.account.privilege.grant"
eventType eq "user.mfa.factor.deactivate"
eventType eq "user.mfa.factor.reset_all"
eventType eq "application.user_membership.change_username"
eventType eq "zone.update"
eventType eq "system.api_token.create"

I hope this helps any Okta customer mitigate and discover any malicious actions against their organization.

Stay safe!