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.
An individual user’s activity can be audited using this query.
User activity can be audited by session ID using this query.
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.
