Skip to content
Recon InfoSec is AICPA SOC 2® Type II Certified
Recon™InfoSec

Insights

Okta + LAPSUS$ Security Incident

Eric Capuano ·

Archived article. Published in 2022; some details may be out of date.

As many in the industry are now aware, Okta experienced a form of security breach back in January which the wider industry was unaware of until screenshots obtained by the LAPSUS$ group were posted on Twitter on March 21st, at 10:15pm CDT.

The LAPSUS$ ransomware group has claimed to breach Okta sharing the following images from internal systems. pic.twitter.com/eTtpgRzer7

— Bill Demirkapi (@BillDemirkapi) March 22, 2022

What We Know So Far, and What You Can Do Now

What followed this storm on Twitter was a very vague statement from Okta posted on March 22 at 4:15am CDT, contents below.

Okta’s first statement: a January 2022 attempt on a support engineer’s account was contained, with no ongoing activity

This left many wondering, what were the results of the “investigation to date” and why were customers not notified sooner?

In a follow-up statement from Okta on March 22 at 2pm CDT, additional information was given, but without answering these key questions.

Okta’s follow-up statement describing a five-day window in January 2022 when an attacker accessed a support laptop

There are conflicting statements made such as “The Okta service has not been breached and remains fully operational” yet “there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop…” While an attempt is made to down-play the implications of this access, “The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases.” it is also clearly stated that “engineers are also able to facilitate the resetting of passwords and Multi Factor Authentication for users” which is quite enough access to do damage to an Okta customer environment. This is echoed in alleged refutations by LAPSUS$ to Okta’s statements.

Seems we weren’t the only ones left scratching our heads with these vague and contradicting statements…

There’s a lot in Okta’s statement that frankly doesn’t add up.

Meanwhile, Cloudflare (which uses Okta for its internal network, just like thousands of other orgs) says it found out just like everyone else — in the middle of the night from a tweet. https://t.co/rmewNxaDN2

— Zack Whittaker (@zackwhittaker) March 22, 2022

Like many other concerned organizations using Okta, we ignored the claim that “There are no corrective actions that need to be taken by our customers.” and began our own internal hunting and investigation. We are sharing the steps we took in hopes that it arms other organizations with the means to do the same.

What can we look for?

Ideally, you are ingesting Okta logs into a SIEM or log aggregation tool, which makes this an easy task. Even if you are not, you can query Okta logs directly in the admin console. Here are some things that you can look for in your Okta system logs to identify suspicious activity.

Some events of interest include:

  • user.session.impersonation.initiate - Look for unexpected impersonation sessions from Okta support engineers.
  • user.mfa.factor.deactivate - Look for unexpected deactivation of MFA on user accounts.
  • user.mfa.factor.activate - Look for unexpected user MFA enrollments, which is similar to what triggered the first detection during Okta’s breach
  • user.mfa.factor.reset_all - Provides org admins with audit log and oversight utility for the change in MFA factor lifecycle statuses when all MFA factors for a user are permanently deactivated.
  • user.account.privilege.grant - This can be used to audit the provisioning of admin privileges for users.
  • user.account.reset_password - Fired when the user’s Okta password is reset.
  • user.account.update_password - User update password for Okta.
  • group.privilege.grant - This can be used to audit the provisioning of admin privileges for groups.
  • security.authenticator.lifecycle.deactivate - Fired when an admin deactivates an authenticator for the org.
  • system.mfa.factor.deactivate - Can be used to identify when an admin has disabled a factor for MFA.
  • system.mfa.factor.activate - Can be used to identify when an admin has enabled a new factor for MFA. Look for unexpected admin MFA enrollments, which is similar to what triggered the first detection during Okta’s breach
  • user.session.access_admin_app - User accessing Okta admin app. Deconflict with known-authorized admin activity.
  • security.threat.detected - Request from an IP identified as malicious by Okta ThreatInsight.

If you are familiar with the Sigma project, there are a collection of Sigma format rules specifically for Okta.

What additional steps can we take?

Some of the best guidance we’ve seen is compiled in this writeup from Cloudflare, but we’ll share a few additional thoughts.

  • While MFA alone cannot protect from a “superuser impersonation” threat, it is still a basic hygiene step that must be taken. Double-check that your Okta tenant enforces MFA for all user groups.

  • Ensure you are enforcing complex passwords for all users.

  • Consider password resets for any accounts that experienced a password change or MFA status change in the last ~3 months

  • Ensure that you are ingesting Okta logs to a SIEM or log aggregation tool that you control to ensure your retention reaches as far back as possible. For low-volume, high-value logs such as Okta authentication logs, it is not unreasonable to retain these for several years.

    • Craft detection queries and alert logic around some of the event types outline above. Retroactively searching for bad behavior means you are always a few steps behind the incident. Proactive alerting is the bare minimum orgs should hope to achieve.

  • Leverage Okta’s HealthInsight tasks and recommendations to improve your Okta security.

  • Ensure that you have disabled Support access

    • Admin Panel > Settings > Account > Give Access to Okta Support = Disabled

  • Consider leveraging Okta’s Workflows feature to design notification webhooks around certain privileged activities.

    • An example of one such workflow we implemented:

      • Periodically audit all Okta users with Admin privileges and compare to the previous list
      • Store every version of the list in a secure location for archival purposes
      • If the list changes from one workflow execution to the next, send all information about the new admin to a Slack channel monitored by the SOC
      • SOC will deconflict changes with internal Okta admins

    • With this example and several other workflows we’ve implemented, not only are these activities logged to our SIEM, but instant notification provided to the SOC as these events occur.

UPDATE - March 22, 2022 / 9:17pm CDT

Okta has just made an updated statement about this incident which adds further clarity around what has happened.

Okta’s updated statement that approximately 2.5% of customers were potentially impacted

What is most concerning about this update is that it confirms there was, in fact, a breach involving Okta customer tenants.

we have concluded that a small percentage of customers – approximately 2.5% – have potentially been impacted and whose data may have been viewed or acted upon

According to public information, 2.5% of Okta’s user base could be nearly 400 organizations. This is a very different situation than was originally implied in the earlier statements from Okta, therefore our guidance above is even more important than before we knew the true scope of this.

UPDATE - March 22, 2022 / 10:59pm CDT

Okta has finally posted a proper timeline of events providing more detail about what happened and when.

Okta’s UTC timeline of the Sitel incident, from the January 20 MFA alert to the March 22 report

The primary takeaways:

  • Confirmation that as many as 366 organizations may be affected.
  • The threat actor had access to Okta backend admin tools for 5 days, between January 16-21. Okta was not aware of this until an additional MFA factor was attempted to be added to a third-party support engineer account on January 20th.
  • Okta knew there was a security related incident on January 20th, but took no further action beyond notifying their third-party support agency (Sitel) until March 22nd (61 days).
  • Okta has not addressed why it took 2+ months to notify customers of a security incident, but instead expresses disappointment with Sitel for taking so long to submit a report to them.

References

Tags

All articles

Related articles