We're proud to be named a 2024 Publisher's Choice winner!

We're an RSA Conference 2024 Innovation Sandbox Finalist!

Security leaders around the world woke up recently to a potential nightmare resulting from the recent Okta incident. A known threat group named LAPSUS$ claims that they breached Okta, an industry leader in identity and access management.

The potential scale of this breach can be seen in the screenshots shared by the threat group in a dedicated Telegram channel showing that the compromise may go back as far as January 21st, 2022. These images also show the threat actor’s access to privileged Okta users as well as Okta’s Slack and Jira.

But it doesn’t stop there. There is initial unverified information that LAPSUS$ was also able to use their access to compromise a Cloudflare tenant (Cloudflare uses Okta as an identity provider). Potentially, every company in the world that uses Okta for access management may be at risk.

 While at this stage we cannot completely verify the integrity of this notification, the potential impact is very high, so this calls for immediate action.

Here's what you need to do:

1. Acquire and Retain Logs

This is a good time to acquire all relevant SaaS, authentication, audit, and resource logs. In this case, you need to focus on Okta System Logs. Logs document actions done on a system and can help trace the activity of an attacker, so collecting and storing forensic data will help you determine what happened.

Also, as default retention time can be short, you should make sure existing historical logs are retained for a longer period and prevent log rotation (particularly if log files are deleted to make room for incoming log data). We recommend storing logs for long periods of time than is typical. (Mitiga stores log data for 1,000 days for our customers.) The lack of forensic data makes incident investigation much more chaotic and challenging, resulting in prolonged response and recovery times.

2. Proactively Hunt

Even before you get notified of any potential Okta breach, you should be proactively hunt for anomalies and malicious behavior in logs. Focus on Okta System Log and systems that use Okta and search for Okta system access. Pay close attention to any actions conducted by the system@okta.com actor and check for privileged accounts created in the last several months.

Want to better understand Okta logs? Here is a good resource for expert advice and investigation know-how.

3. Reset Passwords

If you're using Okta, you should probably reset user passwords. Prioritize administrative and privileged users. Before doing that, make sure you keep an audit record that includes:who performed the password reset, time, IP address, and a list of users.

If it's a good idea for Cloudflare, it's probably a good idea for you.

CloudFlare Tweet about Okta breach

Prioritize privileged users and service accounts and those that are authenticated with Okta. We recommend following the NIST password guidelines.

4. Review MFA Enrollment Status

Confirm that all Okta users are enrolled in multi-factor authentication (MFA) and make sure it is enforced. Additionally, confirm that multi-factor authentication is turned on for your office suite (Google Workspace, Microsoft 365). This will help prevent unauthorized password reset attempts.

5. Measure 3rd Party Risk

Contact organizations that are part of your supply chain and check whether they are impacted by this breach. Additionally, verify your policies and 3rd party procedures and make sure you get notified if and when an incident happens.

6. Share Intel

Share intelligence and information. Make sure relevant teams are notified internally.

7. Monitor Communication from Okta

Monitor any inbox that may receive communication from Okta and make sure you have a designated security resource who is notified if or when Okta tries to reach you.

 (All these unread messages in your security mail inbox might be important.)

8. Contact Your Managed Service Providers

Make sure you have established direct communications with your IR vendor as well as your managed detection and response (MDR) vendor, your managed security service provider (MSSP), and your managed security operation center (SOC). Make sure they are thoroughly checking Okta events and logs in the upcoming weeks.

 If you have an IR partner that is dedicated to cloud and SaaS, now is a good time to contact them. If you don't have one yet, now may be your last chance to subscribe as they're quickly getting overbooked.

9. Assess Incident Readiness and Business Continuity Capabilities

Dust off your Business Continuity Plan and your Incident Response Plan and make sure your Disaster Recovery and Incident Response (IR) teams are on high alert.

10. Prepare Breach Notification Messages

Knocking on wood is important but preparing breach notification communication is even better. Here is a good example of notification about a recent security incident by HubSpot:

Information about HubSpot's March 18, 2022 Security Incident
Read about the HubSpot incident.

Images indicating compromise shared by LAPSUS$

Lapsus$ screenshot in Okta

LapsusS in Slack

Lapsus$ in Jira

Lapsus$ Okta Supervisor

Lapsus$ superuser in Organizations
Lapsus$ screenshot Cloudflare
Lapsus$ reset password screenshot

Lapsus$ system log event log threshold

If you have more specific recommendations for handling this potential Okta breach, please let us know so that we can add them to this list.

If you are currently being impacted by the Okta breach or are seeking guidance on what to look for, please reach out to our emergency services:

  • United States: +1 (888) 598-4654
  • United Kingdom: +44 (20) 3974 1616
  • Israel: +972-3-978-6654
  • Singapore: +65-3138-3094
  • Email: emergency@mitiga.io

Or fill out our emergency incident response contact form. We're here to help if you need us (but we hope you don't.)

This post was originally published on LinkedIn on March 22 and has been updated.

Understanding Your Okta Logs to Hunt for Evidence of an Okta Breach


May 4, 2024

Don't miss these stories:

Mitiga Wins Global InfoSec Award for Cloud Threat Detection Investigation & Response (TDIR)

We’re proud to report that at the open of today’s RSAC24, Mitiga was awarded the Publisher's Choice Cloud Threat Detection Investigation & Response (TDIR) from Cyber Defense Magazine (CDM), the industry’s leading electronic information security magazine.

Here's Why Traditional Incident Response Doesn’t Work in the Cloud

Traditional incident response (IR) learned from on-premises investigations doesn’t work in the cloud. Today's threat actors are finding misconfigurations and vulnerabilities to allow them to penetrate cloud environments.

Why Did AWS Replace My Role’s ARN with a Unique ID in My Policy?

After several years of working with AWS, IAM remains one of the most frequently used services in my daily routine. Yet, despite my familiarity with it, a recent production incident taught me that there’s always more to learn.