As more organizations move to software-as-a-service (SaaS), remote access to applications and data is concentrated among a smaller set of identity providers. These identity providers, such as Okta, must absorb growing volumes of credential-based attacks.
Okta consistently reports high volumes of credential stuffing, password spraying and phishing attacks against its customers. Additionally, red teams are discovering new patterns of abuse relevant to Okta products. Though these attacks pose a serious threat to Okta customers, streaming Okta's rich log data to CrowdStrike Falcon® Identity Threat Protection and CrowdStrike Falcon® Next-Gen SIEM provides defenders the visibility needed to respond.
Researching these attacks has allowed CrowdStrike, in collaboration with Okta, to build out additional correlation rule templates (CRTs) within Falcon Next-Gen SIEM and refine native detection available within Falcon Identity Threat Protection.
Detection Engineering Primer
Okta logs provide rich information about authorization and authentication taking place within an organization. Almost every aspect of a login, change or modification is emitted, generating a significant amount of data to handle when developing detection content. We utilized a purple team approach to the attack scenarios to develop the detection opportunities below. Every step of the attack, whether it was performed by the victim or the attacker, was recorded with a timestamp. Tying a specific user action back to a specific log is essential because it helps the defender make educated assessments of each recorded log during each step of an attack.
A time frame for the start of each attack is initially identified for log analysis. All logs within the time frame are subsequently inspected, even if they are associated with the victim user. In some cases when filtering data on just the victim user, you may miss actions taken by Okta. Token issuance events are a good example of this, since the Okta system user account issues tokens and not the victim. When the token is issued, the logs will make note of the user to whom the token was issued (in this case, our victim).
After identifying the attack time frame, all of the fields are aggregated within a table, sorted by time and leveraged to identify patterns or anomalies. As is the case with detection engineering, an initial hypothesis was created, but it failed to meet the expected outcomes when tested against real-world datasets due to false positives. The queries listed throughout this blog post were meaningfully developed to target the behaviors we identified that were unique to each attack scenario within our lab environment.
On average, Okta provides around 55 different fields in each log. To help narrow this down for a more approachable set of fields to examine, a sample list we found valuable for this research includes the following:
Field | Notes |
actor.alternateId | Source username for each event |
authenticationContext.rootSessionId | Helps tie an entire authentication sequence together via a single key |
AuthenticatorEnrollment.detailEntry.methodTypeUsed | Type of multifactor authentication (MFA) used (push notification, SMS, etc.) |
AuthenticatorEnrollment.id | Authenticator ID registered per account |
client.ipAddress | IP address for the action taken |
debugContext.debugData.behaviors | Okta-provided historical traits for the user account |
debugContext.debugData.dtHash | Hash-based identifier |
debugContext.debugData.keyTypeUsedForAuthentication | Authentication method used, such as biometric authentication, PIN or proof of possession |
debugContext.debugData.logOnlySecurityData | Okta-provided historical traits for the user account |
debugContext.debugData.requestUri | URL of request to Okta API minus any URI parameters (*debugContext.debugData.url* includes the URL and parameters) |
debugContext.debugData.risk | Okta's first-party associated risk level for the current eventType |
debugContext.debugData.threatDetections | Okta first-party alerts described |
debugContext.debugData.tunnels | If a proxy IP address is detected, this field may include some additional details about the proxy and show whether it is acting as a VPN |
debugContext.debugData.url | URL of request to Okta API |
displayMessage | Description of the eventType |
eventType | The name of the event that occurred |
outcome.reason | Reason for the outcome of the event |
outcome.result | Whether the operation was successful or not |
securityContext.isp | Internet service provider (ISP) for the recorded IP address |
target.alternateId | List of objects of the event |
Initial Access Attack Vectors
Adversaries use initial access attack vectors to gain a foothold into an organization. Examples of these include adversary-in-the-middle (AITM) phishing attacks using tools like Evilginx, password spraying attacks and MFA fatigue.
Evilginx Used to Steal Credentials
Evilginx is an AITM attack framework used for phishing login credentials and session cookies. Session cookies allow attackers to bypass several MFA methods, including those that rely on push notifications or one-time passwords (OTPs).
The adversary configures the Evilginx server with “phishlets,” or small YAML files, which dictate the business portal to be impersonated (Okta, Azure, etc.), the text fields to be stolen (username, password) and session tokens to be stolen after authentication. After configuring the phishlet, the adversary generates a “lure” to be used within their phishing campaign. The lure is sent to the victim user, who opens the lure and is presented with an Okta login page. The user enters their username and password, submits their MFA tokens and seemingly logs in to their Okta portal. Meanwhile, the username, password and session tokens are stolen from the user’s browser and sent to the Evilginx server under the adversary’s control.
Okta mitigates Evilginx attacks with a granular Cross-Origin Resource Sharing (CORS) policy, which is a deny-all policy by default and requires the addition of third-party domains within the policy itself by an Okta admin. CORS is a series of policies that dictate what resources can be shared across the internet. Web applications are controlled by the same-origin policy, which means a resource from domain A can only be accessed by other resources within the same domain. CORS is a mechanism to share resources across disparate domains. If an adversary with a malicious domain — such as login.evil.site — were to attempt to use an Evilginx phishing attack against an out-of-the-box Okta environment, the attack would fail because login.evil.site is not allowed to access resources inside of <org>.okta.com due to the default deny-all CORS policy.
Okta also offers a range of phishing-resistant MFA methods — such as Okta FastPass, FIDO2 and PIV smart cards — that mitigate Evilginx attacks. Okta sign-on policies can be configured to require phishing-resistant authenticators for access to any given application or resource. For the purposes of this blog post, we are going to assume an Okta customer continues to use passwords and basic MFA (OTPs) as their authentication methods.
An organization may be vulnerable if there is a wildcard domain included within the CORS policy. Okta also mitigates Evilginx attacks by enforcing "Device Binding for Creating Sessions." This setting ensures authentication redirects stay within the browser they were initiated from by comparing the device identifier provided in the requests. If the values do not match, access to any app will be denied, and no new identity provider (IdP) session will be permitted. In some Okta deployments, such as the use of third-party proxies, incompatibilities require this function to be disabled. To effectively phish Okta users with Evilginx, a CORS policy with a wildcard domain and Device Binding must be disabled.
If all of these conditions are met, the following screenshot demonstrates an executed Evilginx attack against the Okta environment, resulting in the theft of credentials and session tokens from a test user. These credentials and session tokens are then used to access that user's single sign-on (SSO) panels within the Okta portal.