Okta breach learned is that any vendor can be breached sooner or later. No one is immune. Okta is one of the stable vendors that we know cuz the Okta history was pretty good. This blog post will take you for a quick intro to what has been known, the way to investigate, and the remediation.

Note: The queries, scripts, and shared material are available on a GitHub profile – see the reference below

Summary

Adversaries hit authentication firm Okta, drawing concern across the security industry.

In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider. As part of our regular procedures, we alerted the provider to the situation, while simultaneously terminating the user’s active Okta sessions and suspending the individual’s account. Following those actions, we shared pertinent information (including suspicious IP addresses) to supplement their investigation, which was supported by a third-party forensics firm.

We are actively continuing our investigation, including identifying and contacting those customers that may have been impacted. There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers.

• On March 22nd, 2022, the LAPSUS$ group published potential evidence of a successful breach of Okta.
• This information was released in claims of successful attacks, potentially leveraging the initial Okta breach.
• This also means there is currently no indication of specific failures on the part of Okta or reason to rush into replacing identity providers before the dust settles and the complete picture is revealed.
• However, the recommendations are a preventive approach for organizations leveraging Okta solutions and taking several measures to mitigate potential risks.
• The #LAPSUS$ group had published a few screenshots about the Okta breach and another response for the okta statement.

Investigation

Like any other #breach, we need to investigate the okta system with all activities and to know what we’ve got in our hands. The investigation can be done by the okta console, your CASB solution, your SIEM, and any other security tools that can be helpful.

The investigation in this blog post will be focused on Microsoft Sentinel, Defender for Cloud Apps, and Okta.

Okta

The Okta System Log records system events related to your organization to provide an audit trail that can be used to understand platform activity and diagnose problems. The Okta System Log API provides near real-time, read-only access to your organization’s system log and is the programmatic counterpart of the System Log UI.

Note: Okta retains events for 90 days. Specifying a more extended range will result in an error.

To investigate the correct events and activities, we should know who is the event type filter for admin and user. The Okta system log API includes many event types and useful information for the investigation. The most important event type filter is the “eventType eq “core.user.impersonation.session.initiated” .

The impersonation event type is the primary event and the initial access for this breach from a customer side (okta tenant side). After this event appear we can continue the investigation to sub-event types such:

• eventType eq “core.user.admin_privilege.***
• user.account.privilege***
• system.api_token.***
• user.session.access_admin_app
• app.oauth2.as.key.rollover

There are more event types, but those are the main ones that we should know if we have a bad actor or not.

The event type “core.user.impersonation.session.” includes four values: Initiated, Grant, Extended, Revoked, Ended.

It’s depend if you’re taking legacy event type or event type. For Event Type it will be:

• user.session.impersonation.end
• user.session.impersonation.initiat
• user.session.impersonation.grant
• user.session.impersonation.extend
• user.session.impersonation.revoke

For more event types, go to the Microsoft Sentinel for Okta.

You will probably have some impersonation sessions on your logs because’ the Okta agent support is using this same session. So, how do you know if you’re compromised? You could see if you’re compromised based on the sub-event types (the ones I described above). If there are no sub-events, you are good to close the incident. Else you should continue.

For log investigation, you should look at the event and the values under the event such as AuthenticationContext, EventType, Outcome, SecurityContext, etc. Don’t look for Okta’s suspicious events because it does not provide you with the relevant information.

Once you’ve got any impersonation sessions, you must check the context cuz’ the impersonation sessions come in several ways. The two essential findings that belong to this incident are the following:

• Okta Provisioning Agent
• Okta Support

Note: Both of them work with policy, and for the Okta support, there are default policies for 24 hours. Make sure it is disabled and open by specific request.

Defender for Cloud Apps

If your Okta is connected to the Microsoft Defender for Cloud Apps, you can investigate this incident quickly, and if there are other connected apps such as Slack, AWS, etc. You will have the ability to investigate across all the applications.

Note: Slack, AWS, and others are part of Okta customers but didn’t hack.

The investigation is straightforward, and you create a simple query with:

• App: Okta
• Activity Type: impersonation > choose the impersonation type.

The big difference between Okta system log and Defender for Cloud Apps (MDA) is how MDA provides us with the activities, the sub-event that belong to each session, the information inside each specific activity, and raw logs. With MDA, you can know from a quick investigation if the session is legit or malicious action.

The investigation with MDA provides the following information:

• User
• Device
• IP
• Browser agent
• Type
• User groups
• Activity objects
• Location
• Actor and sub information
• AauthenticationContext and sub information
• LegacyEventType and sub information
• Outcome and sub information

Microsoft Sentinel

Microsoft Sentinel gives the best story as one who has the eyes on Okta and any other top platforms that are part of Okta customers, such as Slack, Zoom, ServiceNow, AWS, etc.,

We can connect Okta system logs to Microsoft Sentinel and receive detailed information. The information is below and much more.

• User
• Device
• IP
• Browser agent
• Type
• User groups
• Activity objects
• Location
• Actor and sub information
• AauthenticationContext and sub information
• LegacyEventType and sub information
• Outcome and sub information

So, what can you do with Microsoft Sneintl for Okta?

• Create Analytics Rules
• Create Proactive Hunting
• Run Playbook for unfamiliar activities
• Create detection rules for all the relevant systems.
• Make sure MITRE covers identity attacks and supply chain attack

Detection Rules

First, let’s create detection rules for impersonation and admin roles privilege granted.

It’s depend if you’re taking legacy event type or event type. For Event Type it will be:

• user.session.impersonation.end
• user.session.impersonation.initiat
• user.session.impersonation.grant
• user.session.impersonation.extend
• user.session.impersonation.revoke

Note: You can create a rule based on those queries and the available queries on Microsoft Sentinel for SecOps. Link below.

Remediation

Okta side

Disable Okta Support Agent

If for some reason, the Okta support agent isn’t disabled by default, you should make sure it’s disabled, and only the super admin can open this option or allow it by the policy.

Check your #Okta Admin Console under Settings -> Account -> Give Access to Okta Support.

Password Reset for Okta Administrator Roles

For any okta with the highest permissions, you must reset the password as soon as possible by the instructions below:

1. In the Admin Console, go to Directory > People.
2. Click Reset Passwords.
3. Optional. Filter the list by selecting Locked out, Expired token, or All.
4. Select a user and click Reset Password.
5. Click Reset Passwords in the Reset Password dialog box.

The table below is the Okta administrator roles and permissions – you should reset the password for Super Admin, Org Admin, or any admin with custom permissions for Okta Support and the one who can run Provisioning Agent.

Defender for Cloud Policy

Now that you have been created a search query, you can run a policy from this query by choosing the New policy from the search and then continue with the Activity policy.

Microsoft Sentinel

With Microsoft Sentinel, you can create a detection rule based on the following parameters.

Others

You should investigate any related systems, but it depends, and if you don’t have bad sessions activities, the following scenarios are optional:

External Admin – Must. If you’ve got any external admin in Okta (contractors) with privilege permissions, you should remove them and provide access by demand only.

Critical Asset – An optional. If you don’t have bad sessions and impersonation, you don’t need to investigate additional platforms.

Key Rotation – An optional. Okta Key rotation is when a signing key is retired and replaced by generating a new cryptographic key. Rotating keys regularly is an industry standard and follows cryptographic best practices. New keys usually are generated a few weeks before the rotation occurs to ensure that downstream customer caching mechanisms are updated before the rotation occurs. The current Okta key rotation schedule is four times a year but can change without notice.

Password Reset to All Users – An optional. Reset password to all Okta users needs to be done if your Okta is affected by malicious activities.

Device Trust – An optional. You can connect the device to Okta as part of the Device Trust option, and if you’ve got an Apple device, you should reset the device secret key, Based on the Okta client-based and including scenario with Jamf integration.

References

Microsoft Sentinel for Okta

Updated Okta Statement on LAPSUS$

Official Okta Statement on LAPSUS$ Claims

Okta System Log

System Log filters and search

Standard administrator roles and permissions