On October 19, 2023, Okta notified its customers of a security breach involving unauthorized access to their support system. This incident occurred when an external party obtained and misused Okta’s support service account credentials.
The investigation by Okta pinpointed the origin of the breach to a security lapse involving an Okta-managed laptop. An employee, using this laptop, logged into their personal Google account, where the Okta service account credentials were stored. It appears these credentials were subsequently accessed and misappropriated following the compromise of the employee’s personal account.
Okta’s analysis confirmed that the intruder could access and potentially download files associated with 134 customers’ support inquiries. This data included HAR Files, which were part of the materials submitted for support purposes.
The attacker searched to obtain the contact details of Okta’s support customers. This query encompassed a range of fields, including:
- Date of Account Creation
- Most Recent Login
- Full Name
- Username
- Email Address
- Company Name
- User Type
- Residential Address
- Date of Last Password Modification or Reset
- Role Title
- Role Description
- Telephone Number
- Mobile Number
- Time Zone
- SAML Federation Identifier
Although 99.6% of Okta’s support system users have only their full name and email address registered, the attacker successfully compiled a comprehensive list of all Okta support customers who had filed a support ticket before September 28, 2023, at 15:06 UTC.
Timeline of the HAR File and Data Exfiltration Breach based on Okta’s investigation:
| Date | Event |
| 2023-09-29 | 1Password, an Okta client, reports about suspicious activity. Okta security team starts an investigation. |
| 2023-10-02 | BeyondTrust, another Okta client, also reports suspicious Okta activity. |
| 2023-10-12 | A third customer reports suspicious activity. |
| 2023-10-13 | BeyondTrust shares an IOC (IP address) with Okta. |
| 2023-10-16 | Okta identifies an activity of a service account originating from a suspicious IP address. |
| 2023-10-17 | Okta took initial remediation steps:Disabling the compromised service account and revoke its’ sessionsRevoke sessions embedded in HAR files found to be downloaded by the threat actor. |
| 2023-10-18 | Okta Security notifies a fourth Okta customer targeted by the adversary. |
| 2023-10-19 | Okta identifies more threat actor activity and revokes additional sessions embedded in HAR files downloaded by the adversary. |
| 2023-10-19 | Okta alerts all its customers with registered security contacts, confirming if the security incident impacted them or not. |
| 2023-10-20 | Okta released the first public blog regarding the incident. |
As Okta’s investigation continued, attention shifted to a particular type of file involved in the incident, a HAR file. HAR files, or HTTP Archive format files, are not just relevant to the Okta incident but hold significant importance in broader ITDR and cybersecurity contexts.
What is HAR?
A HAR file, short for HTTP Archive, is a file format used to capture and store detailed HTTP requests and responses between a web browser and a web page. This file can be exported using the browser’s developer tools and used primarily for debugging and troubleshooting purposes of HTTP traffic. For example, among other data points, the HAR file contains information regarding the client’s requested URLs and their responses, URL parameters, headers, and cookies.
The exporting process is simple and detailed across the internet by many companies, including Okta.
The risk behind sharing HAR files
Although designed for diagnostics, sharing HAR files outside a secure context poses significant risks, particularly concerning leaking sensitive information and the danger of session hijacking.
These files may contain passwords, session cookies, or tokens, which are like digital keys to your online sessions. Specifically, when capturing traffic for Okta, the HAR files might contain active cookies, session IDs, SAML tokens, and other authentication data that can be reused for session hijacking or other types of attacks.
In short, and as simple as it sounds, an adversary with a cookie, that was extracted from a HAR file, can hijack the session without authenticating or presenting a factor.
For this exact reason, customers are advised to sanitize the archives before sharing them with anyone. The HAR sanitation process protects the users from exposing authentication parameters or other sensitive information from their recordings. Sanitization and ITDR preparation is possible with open-source projects (such as CloudFlare or Google) and online tools.
For example, let’s quickly review Google’s online HAR analyzer. Start by uploading a file:
As we can see, each HTTP request and response that was recorded in the HAR can be clicked to view which headers and parameters were passed as part of the request.
Abusing non-sanitized Okta HAR file (Demo)
In this demo, we recorded a sign-in of an Okta administrator and exported the logs into a HAR file. We used the HAR file to hijack the administrative session without re-authenticating. To do so, we must find the correct HTTP request for the Okta tenant.
When administrators log in to the Okta admin dashboard, they are redirected to a page with the URL ‘admin/getting-started’. If we search for this string in our recorded session, we get the following requests:
We can see that the administrator logged in successfully since the HTTP response to the admin welcome page is ‘200’.
If we click on this specific response, we can examine the corresponding request and its headers:
All we need to do now is to replay that exact HTTP request. We open a new browser, with a local web proxy (Burp) that will intercept the requests. We then changed the original request headers to match those from the HAR file:
When we forward the request, our browser sends the exact request, and the result is successful. At this point, we have an active session in the Okta admin dashboard, and we have full control of the tenant as long as additional authentication is not required:
Does the HAR File and Data Exfiltration breach impact me?
The adversary accessed support files related to 134 Okta customers.Okta has already contacted you to inform you about the incident if you are one of these customers.
In this case, you can use Okta’s IOCs (Appendix A) to hunt for suspicious activity in your organization.
According to Okta, the adversary also downloaded a report containing the contact information of all Okta support users. In 99.6% of the users in the list, the only contact information is their full name and email address. This information can be used for social engineering campaigns like phishing that target the contacts in that list.
Your contact information was leaked if you created an Okta support ticket before September 28, 2023, at 15:06 UTC.
Okta Mitigations to prevent hijacking
Though the Okta HAR breach is recent, the concept of session hijacking is not, and there are a few Okta configurations that can be set to minimize the risk of your session being hijacked.
Configure The Global Session Policy to Limit Session Lifetime
With proper global session policy, all sessions will have a time limit of a few hours. It means that even if a valid session cookie is stolen from your environment, it will be revoked after the set time limit.
To configure, follow these steps:
- In the admin dashboard, navigate to Security > Global Session Policy.
- Edit your rules and enforce the following configuration:
- Maximum Okta global session lifetime should be limited to a few hours
- Maximum Okta global session idle time should be limited to a few hours
- Okta global session cookies do not persist across browser sessions
Configure Admin Session Binding
An early access feature by Okta, that requires administrators to re-authenticate if their session is being reused from a different ASN, and reduces the chances for session hijacking.
To configure, follow these steps:
- In the admin dashboard, navigate to Settings > Features.
- Under the Early Access section, search for a feature called “Bind Admin Sessions to ASN” and toggle it on.
With the above feature turned on, every session of an Okta administrator is bound to the origin of the initial administrative login. In case the session is hijacked from a different geographic location, the adversary will be prompted for login even if the session is still valid.
Note: VPN services might also affect this feature. An administrator with an active session who logged in to a VPN service must re-authenticate.
Configure Best Practices for Authentication Policies
Even though it would not prevent the initial access, it will reduce the adversary’s ability to perform lateral movement and reduce the risk of compromising additional identities.
- Enforce MFA
- Enable Phishing Awareness
Detection of Hijacked Session
Rezonate can use Okta’s audit logs to look for indications of session theft, as they have a field named authenticationContext.externalSessionId that can be used for aggregating activity by a user session. Using this field, Rezonate can hunt for an externalSessionId that is being used from two different geographic locations. If one of these geographic locations is anomalous, you should take immediate action and revoke the user sessions from the Okta admin console. Discover how Reazonate can assist you with Hijacking detection and overall ITDR today.
