Blog

Okta and LAPSUS$: Investigation Resources and How Panther Can Help

Panther Labs

Mar 23, 2022

6 min read

Written by Kyle Bailey and Ben Sebastian

The recent Okta incident highlights the need for modern security tooling that can validate both security controls and access to your SaaS applications. This blog post details the latest learnings from this incident, including:

Known details published by Okta around the incident impact and timeline.
Specific Okta system log event types that can be used to identify potential compromise, for this recent incident or for future investigations
Detection and investigation content released by Panther’s Detection Team.

Known details around the Okta and LAPSUS$ incident

The Threat Actor group LAPSUS$ published multiple screenshots indicating they gained access into Okta’s corporate systems, specifically into Okta’s customer support environment through internal admin access.

Okta has since posted a response which indicates a support engineer’s endpoint was compromised for five days between January 16 and January 21, 2022. The full timeline of the compromise can be found here. The known details include:

Okta support engineers have access to Jira tickets and user lists associated with customer accounts.
Okta support engineers have the ability to reset both passwords and MFA factors for customer accounts, but do not have the ability to view passwords.
Okta support engineers do not have access to create or delete user accounts or download customer databases.

According to Okta, the compromise was contained on January 21, and Okta says this assessment has been supported by a third-party forensics firm.

How many organizations are impacted?

Note: Panther Labs leverages Okta as an identity provider. The Panther Security Team has investigated all known indicators of compromise in our environment with no findings and was not notified by Okta. We are continuing to monitor and respond to the situation as additional information is released.

Many organizations use Okta as their identity provider. In Okta’s updated statement on March 22, Okta Chief Security Officer David Bradbury indicated that approximately 2.5% of their customers “have potentially been impacted” and those customers’ “data may have been viewed or acted upon.” Bradbury further stated that Okta has contacted the potentially impacted customers. At this time there has not been public confirmation of any organizations compromised as a result of this incident.

What should I look for in my Okta logs?

You can use Okta’s system log to determine if your environment may have been impacted by the compromise.

Okta investigation and detection

We previously highlighted the actions that an Okta Support Engineer can take on a customer account:

Reset passwords
Reset MFA factors
Access to troubleshoot customer accounts if support access was enabled by a super administrator

You can use Okta’s system log events to look for these activities.

Password reset

When a password reset occurs, a system log with an event type of user.account.reset_password is created. If you identify a password reset that was unauthorized, further investigation is warranted.

MFA reset

Multi-factor authentication (MFA) resets can be found by searching for event types of user.mfa.factor.deactivate, user.mfa.factor.update, user.mfa.factor.suspend, and user.mfa.attempt_bypass. If you identify an MFA reset that was unauthorized, further investigation is warranted.

Okta support access

An Okta Support engineer can access your Okta tenant if a super administrator enables the “Okta Support access” setting, which is off by default and often enabled for troubleshooting purposes. When enabled, access is defaultly granted for 8 hours and can be extended for up to 24 hours.

In order to determine if this access has ever been enabled in your tenant, you can search for the user.session.impersonation.grant event type. If the access was used by Okta support a user.session.impersonation.initiate event type would have occurred. Finally, events for revoking this access are captured as user.session.impersonation.end and user.session.impersonation.revoke.

How can I detect a potential Okta compromise with Panther?

Panther’s Detection Team has released multiple detection rules and investigative queries for our product in response to this incident. Our existing Okta integration also allows teams to quickly onboard their Okta system logs into Panther. The following sections go over the near real-time detection and built-in queries available in Panther that can be leveraged for this incident or future Okta investigations your teams need to conduct

Okta log source integration

To ingest Okta audit logs into Panther, follow this guide to gain visibility into actions performed in your Okta tenant.

New detections

New investigation queries

These queries can be used to investigate historical log data and are represented below in Snowflake SQL syntax. Athena customers can find their specific query syntax in the latest Panther Analysis release.

Password resets and MFA resets, suspensions and events can be investigated in Panther using this built-in query.

SELECT 
  p_event_time,
  actor:alternateId as actor_user,
  target[0]:alternateId as target_user,
  eventType,
  client:ipAddress as ip_address
FROM 
  panther_logs.public.okta_systemlog
WHERE 
  eventType IN 
    ( 'user.mfa.factor.reset_all',
      'user.mfa.factor.deactivate', 
      'user.mfa.factor.suspend', 
      'user.account.reset_password',
      'user.account.update_password',
      'User.mfa.factor.update'
    )
  AND 
    p_occurs_since('7 days')
    -- If you wish to investigate a single user, uncomment and add their email here
    -- and actor:alternateId = '<EMAIL_GOES_HERE>'
ORDER BY 
  p_event_time DESCCode language: SQL (Structured Query Language) (sql)

An individual user’s activity can be audited using this query.

SELECT 
  actor:displayName AS actor_name,
  actor:alternateId AS actor_email, 
  eventType, COUNT(*) AS activity_count
FROM 
  panther_logs.public.okta_systemlog
WHERE 
    p_occurs_since('7 days')
  AND 
    actor:type = 'User'
    -- Uncomment lines below to filter by user email and/or eventType
    -- and actor_email = '<EMAIL_GOES_HERE>'
    -- and eventType = '<EVENTTYPE_GOES_HERE>'
GROUP BY 
  actor:displayName, 
  actor:alternateId, 
  eventType
ORDER BY  
  actor_name, 
  activity_count DESCCode language: SQL (Structured Query Language) (sql)

User activity can be audited by session ID using this query.

SELECT  
  p_event_time as event_time,
  actor:alternateId as actor_email,
  actor:displayName as actor_name,
  authenticationContext:externalSessionId as sessionId,
  displayMessage,
  eventType,
  client:ipAddress as src_ip,
  client:geographicalContext:city as city,
  client:geographicalContext:country as country,
  client:userAgent:rawUserAgent as user_agent
FROM 
  panther_logs.public.okta_systemlog
WHERE 
  p_occurs_since('7 days')
  -- Uncomment the line below and replace 'sessionId' with the sessionId you are investigating
  -- and authenticationContext:externalSessionId = '<SESSIONID_GOES_HERE>'Code language: SQL (Structured Query Language) (sql)

Previously released investigation queries (March 22)

All of Panther’s available near real-time detection and built-in queries for Okta can be viewed in our latest Panther Analysis release. You can see more examples in our Okta Detections and Queries documentation.

Conclusion

With any new threat, it is critical for security teams to take action quickly to understand their exposure, assess mitigation options, and monitor for signs of exploitation. It has been amazing to see security teams, vendors, and individuals across the globe contributing indicators of compromise, detection ideas, and analysis to the broader community.

The security team at Panther will continue to monitor the Okta/LAPSUS$ situation and provide updates to the detections available to our customers as new information and insights warrant.