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

emergency incident response contact form

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

LAST UPDATED:

January 23, 2025

Don't miss these stories:

Frost & Sullivan’s Latest 2025 Frost Radar: The Need for Runtime Cloud Security in a Cloud-First World

Cloud breaches rose 35% year over year in 2024, and legacy security tools are failing to keep up. The rapid sprawl of multi-cloud and SaaS has shattered the assumptions baked into legacy, on-prem, and endpoint-focused security stacks, which can’t keep pace with today’s dynamic attack surfaces.

The Remote Worker Scam: Understanding the North Korean Insider Threat

Recent investigations have uncovered a sophisticated scheme by North Korean operatives to exploit remote work policies in the U.S. tech industry.

Who Touched My GCP Project? Understanding the Principal Part in Cloud Audit Logs – Part 2

This second part of the blog series continues the path to understanding principals and identities in Google Cloud Platform (GCP) Audit Logs. Part one introduced core concepts around GCP logging, the different identity types, service accounts, authentication methods, and impersonation.

Mitiga Security Advisory: Lack of Forensic Visibility with the Basic License in Google Drive

Mitiga's advisory highlights critical gaps in forensic visibility with Google Drive's Basic license, affecting security and incident investigations. Read on.

Cloud Detection vs Cloud Threat Hunting: Insights for Cyber Leaders

As cyber threats evolve, security teams need to detect and mitigate cloud attacks. Learn why cloud detection and threat hunting are key defense strategies.

Oops, I Leaked It Again — How Mitiga Found PII in Exposed Amazon RDS Snapshots

A recent Mitiga Research Team investigation found the well-regarded Amazon Relational Database Service is leaking PII via exposed RDS Snapshots.