Executive Briefing: Okta Breach
October 2023
Published: October 31, 2023
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.
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.
Data associated with around 200 customers (roughly 1% of Okta’s customer base) was compromised. Cloudflare, 1Password, and BeyondTrust have publicly acknowledged being targeted by the breach.
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. This attack has not been reliably attributed to a specific threat actor.
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.
According to the 1Password incident report:
“Corroborating with Okta support, it was established that this incident shares similarities of a known campaign where threat actors will compromise super admin accounts, then attempt to manipulate authentication flows and establish a secondary identity provider to impersonate users within the affected organization.”
The following actions were taken by the threat actors against certain Okta customers:
1. Session Hijacking: Admin sessions were hijacked via the authentication information obtained from stolen HAR files.
2. Administrative Actions via Proxy: Administrative actions were performed through a Proxy Server.
3. Reconnaissance Activities: Recon activities included obtaining password health reports directly via URL, bypassing the normal admin console flow.
4. Service Account Manipulation: There were attempts to create ambiguously named service accounts directly via the API.
5. Authentication Policy Alteration: The threat actors added new, and modified existing, authentication policies and settings
a. Specifically, they configured non-Okta Identify Providers (“IdPs”) for trusted access into configured applications
6. API Admin Access: The threat actors accessed Admin functionality via API when Admin Console access was denied due to policies.
7. VPN Usage: Extensive use of third-party VPNs from regions in Southeast Asia was observed.
1. Identification & Analysis
a. Determine whether any HAR files were uploaded to Okta
i. If so, analyze the content to understand the extent of information exposed (e.g.: passwords, session tokens, API keys, etc.)
2. Credential Reset
a. Promptly reset all credentials that were shared in the HAR files.
i. If any API keys or secrets were shared, regenerate them.
3. Audit & Monitoring
a. Review access logs to determine whether credentials shared in the HAR files were used without authorization.
4. Communicate with Third Parties
a. If any shared credentials were used to access third-party services, contact those services to inform them of the situation and inquire about any suspicious activity related to your accounts.
5. Preventive Measures
a. Sanitize log data before uploading it to vendors for troubleshooting purposes. Specifically, remove passwords, session tokens and other equally sensitive data.
b. Inform administrators about the potential risks associated with sharing HAR files and other sensitive information.
c. Provide guidelines on sanitizing HAR files before sharing them.
· Configure the “Maximum Okta Session lifetime” and “Idle Session Expiration” settings in the Okta Admin Panel to control session durations and idle timeouts.
· Use “Okta Device Trust” to ensure services can only be used from trusted devices.
· Enforce the use of “Hardware Protected” Multi-Factor Authentication (“MFA”) for administrators accessing sensitive areas such as the Okta Admin panel and Dashboard.
· Regularly assess and adjust authentication policies for all applications, keeping in mind the risks involved and the necessity for MFA.
· Closely monitor Okta admin activity – especially the following:
o New user creation
o User reactivation
o Permission changes
o MFA policy changes
o Changes to Identity Providers; these may indicate use of an attacker-controlled IdP
· Carefully review access to the Okta REST API
o Usually, these API calls are made by service accounts
§ Some actions, such as device enrollments and local password synchronization actions triggered by services like Jamf, are done via direct user access to the API
o Direct access to the API by individual users should be considered suspicious until proven otherwise
· Monitor activity against sensitive URLs and API endpoints such as password health reports
o Direct access to password health report URLs should be considered suspicious until proven otherwise