TrustedSec's Incident Response Team sent urgent communications to all IR retainer clients after the discovery of the compromise of Okta. Below are the recommendations provided with additional updates after reviewing more information on 03/23/2022.

On March 22, 2022, the threat group LAPSUS$ announced a successful compromise of Okta, a heavily used identity and access management (IAM) platform. Although LAPSUS$ has released similar notifications identifying other high-profile victims, including Microsoft, Samsung, and Nvidia, there is no evidence to support a direct link between the Okta compromise and other victims. That said, any compromise of an IAM provider should be cause for concern and could allow initial access into any organizations that employ this platform. Many organizations have begun taking precautionary measures in case their Okta deployment was compromised.

While few details have been released regarding what happened within the Okta network, the screenshots released by the attacker indicate they leveraged a compromised vendor’s legitimate remote access. Based on this, the TrustedSec Incident Response team has created a checklist of suggested steps to examine your Okta and remote access systems for signs of compromise. TrustedSec will provide additional recommendations as new information is released.

What to look for?

Based on the information that has been released, organizations should export and analyze the following information:

• Okta System Logs contain information on users that are utilizing Okta multi-factor authentication (MFA), including their location.
  • Note: By default, Okta system logs are only stored for 90 days. TrustedSec recommends centralized storage and retention for these logs.
• Remote access authentication logs record who in your environment is authenticating remotely to your organization.

Analyzing

Once logs have been exported, perform the following analysis and actions:

• Examine geographic locations of IP addresses using Okta or remote access to ensure they are coming from known-good locations. Suspicious locations could include foreign countries or known third-party anonymization services (e.g., VPNs, tor, etc.).
• Ensure “impossible travel” authentications did not occur. This happens when a user logs in from multiple locations and travel between those locations in the time between the logons is impossible (e.g., user logs in from Chicago and five (5) minutes later from the UK).
• Examine unusual logon activity for users. For example, did a user log in at a time they never have before?
• Audit all registered MFA devices to ensure that no suspicious devices have been added to any accounts, especially Okta administrators.
• Search for any unauthorized Okta hardware token changes.
• Rotate Okta administrator passwords as a precaution.
• Validate all Okta password changes were legitimate.
• Verify that Okta support access is disabled.
• Validate that “Directory Debugger” access to Okta support is disabled.

I found something! Now what?

If you find something that is indicative of a potential compromise, TrustedSec recommends the following:

• Disable the user account and reset their password.
• Disable all MFA devices for the user.
• Kill all active sessions for the user (e.g., VPN, Microsoft 365, etc.).
• Investigate user activity to determine lateral movement, evidence of data exfiltration, etc.

Additional Resources

The following resources may assist with internal investigation or detection efforts. As always, TrustedSec recommends performing internal testing prior to deploying new rules or detections to production environments.

• Sigma rule repository
• Elastic detection integrations
• Okta Incident Statement
• Microsoft LAPSUS$ information and TTPs
• Cloudflare investigation information

If you need assistance, please feel free to contact us and we will help in any way possible.