“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.
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.”
If you are familiar with Okta, the pathway to lateral movement is self-evident:
- 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
- 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 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.
This is Okta's latest update on the matter:
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.