Executive Summary
Incident Overview
On October 19th, 2023, Okta identified and alerted the public to adversarial activity, highlighting a security breach where an unknown entity gained unauthorized access to a support site managed by a third party, integral to Okta's customer support operations.
Details of the Incident
An Okta employee saved Okta service account credentials in their personal Google account on a company laptop. A breach of their laptop or Google account exposed these credentials, enabling attackers to access and alter customer support cases in Okta's system.
The threat actor obtained several HTTP Archive ("HAR") files uploaded by Okta's customers for resolving support cases. These files, which contain logs of HTTP session activity, may inadvertently contain sensitive authentication credentials, such as cookies and access tokens, potentially exposing user accounts and systems to malicious access.
Affected Entities
Okta previously indicated that data associated with 134 customers (less than 1% of Okta's customer base) was compromised. The threat actor used session tokens obtained from this compromised data to hijack the legitimate Okta sessions of five customers. Cloudflare, 1Password, and BeyondTrust have publicly acknowledged being targeted by the breach.
Update (November 30, 2023)
On November 30th, 2023, Okta issued an updated communication further elaborating on the incident's impact. The threat actor acquired a comprehensive report listing all users of the Okta customer support systems. This report encompasses the full names and email addresses of customers who have engaged with the support system. The number of organizations affected by this aspect of the breach is much greater than the initially indicated ~1%. Warn personnel who've interacted with Okta's support system to expect phishing and other attacks.
Attribution and Motivation
The exact motivation behind the breach remains unclear. However, the fact that all the publicly acknowledged victims are Cloud Security-as-a-Service providers suggests a strategic targeting aimed at accessing downstream companies. This appears to be part of a larger, long-term effort to target Cloud Security-as-a-Service companies. We've expected to see an Okta breach since we saw the successful attack against LastPass and earlier indications of high-level threat actors targeting Okta in 2022.
Novel Aspects of the Breach
The threat actors added new Identity Providers (user databases) to some Okta customers' accounts. These users would be allowed trusted access to services authenticating against Okta.
Full Analysis
Threat Actor Actions
The following actions were taken by the threat actors against certain Okta customers:
- Session Hijacking: Admin sessions were hijacked via the authentication information obtained from stolen HAR files.
- Administrative Actions via Proxy: Administrative actions were performed through a Proxy Server.
- Reconnaissance Activities: Recon activities included obtaining password health reports directly via URL, bypassing the normal admin console flow.
- Service Account Manipulation: There were attempts to create ambiguously named service accounts directly via the API.
- Authentication Policy Alteration: The threat actors added new, and modified existing, authentication policies and settings. Specifically, they configured non-Okta Identity Providers ("IdPs") for trusted access into configured applications.
- API Admin Access: The threat actors accessed Admin functionality via API when Admin Console access was denied due to policies.
- VPN Usage: Extensive use of third-party VPNs from regions in Southeast Asia was observed.
Prioritized Response Actions
Operational Security
- Identification & Analysis: Determine whether any HAR files were uploaded to Okta. If so, analyze the content to understand the extent of information exposed (e.g., passwords, session tokens, API keys, etc.).
- Credential Reset: Promptly reset all credentials that were shared in the HAR files. If any API keys or secrets were shared, regenerate them.
- Audit & Monitoring: Review access logs to determine whether credentials shared in the HAR files were used without authorization.
- Communicate with Third Parties: If any shared credentials were used to access third-party services, contact those services to inform them and inquire about suspicious activity.
- Preventive Measures: Sanitize log data before uploading to vendors. Inform administrators about the risks of sharing HAR files. Implement MDM policies prohibiting non-company accounts on managed devices. Warn personnel who have used Okta's support system to expect phishing and other attacks.
Session Security
- Configure "Maximum Okta Session lifetime" and "Idle Session Expiration" settings to control session durations and idle timeouts
- Use "Okta Device Trust" to ensure services can only be used from trusted devices
- Enforce "Hardware Protected" Multi-Factor Authentication for administrators
- Regularly assess and adjust authentication policies for all applications
- Enable Okta's "Bind Admin Sessions to ASN" feature, which invalidates admin session tokens if a network change is detected
Monitoring & Response
- Closely monitor Okta admin activity — new user creation, user reactivation, permission changes, MFA policy changes, and changes to Identity Providers
- Carefully review access to the Okta REST API — direct access by individual users should be considered suspicious until proven otherwise
- Monitor activity against sensitive URLs and API endpoints such as password health reports
This briefing is part of Exposure Security's ongoing executive intelligence series. For questions about how this applies to your organization specifically, contact us.