Mitiga at RSAC 2025: Visit our booth, attend speaking sessions, and schedule a meeting with us!

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:

Make Cloud Attacks Yesterday’s Problem with Mitiga at RSA Conference 2025

Visit Mitiga at booth number N-4618 at RSA Conference 2025 to learn about cloud detection and response.

Uncovering Hidden Threats: Hunting Non-Human Identities in GitHub

In the last few days, two compromised GitHub Actions are actively leaking credentials, and a large-scale OAuth phishing campaign is exploiting developer trust.

Can vulnerabilities in on-prem resources reach my cloud environment?

What risk does this Zoho password manager vulnerability present, and could this on-prem vulnerability impact cloud environments as well?

Log4Shell - identify vulnerable external-facing workloads in AWS

Cloud-based systems should be thoroughly searched for the new Log4j vulnerability (CVE-2021-44228). But this is a daunting task, since you need to search each and every compute instance, from the biggest EC2 instance to the smallest Lambda function. This is where Mitiga can help.

How Transit Gateway VPC Flow Logs Help Incident & Response Readiness

In this blog, we will focus on the security and forensic aspects of Transit Gateway VPC flow logs and expand the way they can be used by organizations to respond to cloud incidents.

Uber Cybersecurity Incident: Which Logs Do IR Teams Need to Focus On?

On September the 16th, Uber announced they experienced a major breach in their organization in which malicious actor was able to log in and take over multiple services and internal tools used at Uber. What are some of the logs that IR teams should be focusing on in their investigation?