Leveraging CrowdStrike Falcon Against Attacks Targeting Okta Environments

As growing volumes of credential-based attacks put organizations at risk, CrowdStrike collaborates with Okta to build out detection capabilities in Falcon Next-Gen SIEM and Falcon Identity Threat Protection.

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:

FieldNotes
actor.alternateIdSource username for each event
authenticationContext.rootSessionIdHelps tie an entire authentication sequence together via a single key
AuthenticatorEnrollment.detailEntry.methodTypeUsedType of multifactor authentication (MFA) used (push notification, SMS, etc.)
AuthenticatorEnrollment.idAuthenticator ID registered per account
client.ipAddressIP address for the action taken
debugContext.debugData.behaviorsOkta-provided historical traits for the user account
debugContext.debugData.dtHashHash-based identifier
debugContext.debugData.keyTypeUsedForAuthenticationAuthentication method used, such as biometric authentication, PIN or proof of possession
debugContext.debugData.logOnlySecurityDataOkta-provided historical traits for the user account
debugContext.debugData.requestUriURL of request to Okta API minus any URI parameters (*debugContext.debugData.url* includes the URL and parameters)
debugContext.debugData.riskOkta's first-party associated risk level for the current eventType
debugContext.debugData.threatDetectionsOkta first-party alerts described
debugContext.debugData.tunnelsIf 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.urlURL of request to Okta API
displayMessageDescription of the eventType
eventTypeThe name of the event that occurred
outcome.reasonReason for the outcome of the event
outcome.resultWhether the operation was successful or not
securityContext.ispInternet service provider (ISP) for the recorded IP address
target.alternateIdList 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.

Figure 1. Successful phish against an Okta user within a test environment, demonstrating the theft of the username, password and session tokens. Figure 1. Successful phish against an Okta user within a test environment, demonstrating the theft of the username, password and session tokens

Detecting Evilginx

As always, it’s worth starting simple. A stolen session is always going to be identified by a New Device and New IP in the behaviors objects. Additionally, phishing kits may return the session token to the user, which allows for detections that identify multiple IPs for the same rootSessionId, or even for multiple concurrent IPs attributed to a user. These are relatively simple detections for a session roaming event.

While Evilginx awaits the completion of the user’s second authentication factor, we noticed an unusual spike in the event type called policy.evaluate_sign_on during testing in our lab environment. This event type is recorded when Okta evaluates the user's current session against a tenant's policies to determine if further authentication challenges are required.

During the malicious session, this event type appeared roughly every second, and it can be leveraged for a novel detection opportunity. The following detection logic takes attributes from the entire user session into account (as identified by the Vendor.authenticationContext.externalSessionId field). 

Our detection rule looks only for the three Okta event types commonly seen with new authentication sessions. Across the entire session, it recognizes if Okta has identified an anomalous device and counts the number of policy.evaluate_sign_on records in conjunction with the number of user.authentication.auth_via_mfa and user.session.start events. We count these non-policy events to create an arbitrary threshold to see when the ratio of policy evaluation events is higher.

 

#Vendor="okta" #event.kind="event" #event.module="sso"
| in(field="event.action", values=["policy.evaluate_sign_on", "user.authentication.auth_via_mfa", "user.session.start"])
| Vendor.authenticationContext.externalSessionId!="unknown" user.name!="system@okta.com"
| case {
      event.action="policy.evaluate_sign_on" | policy := "true";
      event.action="user.authentication.auth_via_mfa" | mfa := "true";
      event.action="user.session.start" | sess := "true";
}
| case {
      Vendor.debugContext.debugData.risk=/Anomalous\s+Device/i or Vendor.debugContext.debugData.logOnlySecurityData=/Anomalous\s+Device/i | anomDevice := "true";
      * | anomDevice := "false";
}
| groupBy([Vendor.authenticationContext.rootSessionId],
    function=[
        count(field=policy, distinct=false, as=policyCount),
        count(field=mfa, distinct=false, as=mfaCount),
        count(field=sess, distinct=false, as=sessionCount),
        collect([event.action, anomDevice])
        ]
    )
| policyCount > 15 sessionCount < 3 mfaCount < 3 anomDevice=/true/mis

Additionally, a rule may be created to identify replayed session cookies. It’s typical for the initial proxied user authentication IP address and ISP to be logged as the AITM server. After successful authentication, we would typically expect the adversary to transfer that cookie to another device outside of the AITM server for reuse. In this scenario, the device and source address properties should be different from the initial login via the AITM server and the adversary's new device for the cookie replay. By counting the dtHash and IP in a session, we can detect that scenario, since both of these values will inherently be different from the start to the end of the session.  

Okta will also normally indicate when a new anomalous device is observed for the user. Additionally, Okta logs may indicate a specific elevated risk within the user’s authentication session, but the risk level may vary between LOW, MEDIUM and HIGH throughout the session. 

This rule takes data across the entire session into account, so we can check to see if at some point there was a risk level of MEDIUM or HIGH present. 

 

#Vendor="okta" #event.kind="event" #event.module="sso"
| in(field="event.action", values=["policy.evaluate_sign_on", "user.authentication.auth_via_mfa", "user.session.start"])
| Vendor.authenticationContext.rootSessionId!="unknown" user.name!="system@okta.com"
| case {
        Vendor.debugContext.debugData.logOnlySecurityData=/level\"\:\"high\"/i or Vendor.debugContext.debugData.risk=/"level=high"/i | risk := "high";
        Vendor.debugContext.debugData.logOnlySecurityData=/level\"\:\"medium\"/i or Vendor.debugContext.debugData.risk=/level=medium/i | risk := "medium";
        Vendor.debugContext.debugData.logOnlySecurityData=/level\"\:\"low\"/i or Vendor.debugContext.debugData.risk=/level=low/i | risk := "low";
        risk!=* | risk := "none";
}
| case {
        Vendor.debugContext.debugData.risk=/Anomalous Device/i or  Vendor.debugContext.debugData.logOnlySecurityData=/Anomalous Device/i | anomDevice := "true";
        * | anomDevice := "none"
}
| groupby([Vendor.authenticationContext.rootSessionId, user.name],
    function=[
        count(client.ip, distinct=true, as=dcIP),
        count(Vendor.debugContext.debugData.dtHash, distinct=true, as=dcDtHash),
        count(Vendor.securityContext.isp, distinct=true, as=dcIsp),
        collect([risk, anomDevice, Vendor.debugContext.debugData.logOnlySecurityData, event.action, Vendor.outcome.result, Vendor.securityContext.isp, user_agent.original])
        ]
    )
| dcIP > 1 dcDtHash > 1 dcIsp > 1 anomDevice=/true/m risk=/(?:medium|high)/m Vendor.outcome.result=/SUCCESS/mi 

 

It is worth noting that the logic has also been updated in Falcon Identity Threat Protection to provide a native detection for account takeovers using these techniques called “Suspicious Web Based Activity.” This detection covers multiple cloud IDP/SSO platforms including Okta, Entra ID and PingFederate. Either the native “Suspicious Web Based Activity” detection or the Falcon Next-Gen SIEM detection rule can also be used as triggers for automation to create an active response to revoke sessions and refresh tokens among other actions for automated remediation.

Password Spraying Attacks

Password spraying is a common adversary tactic where the adversary takes a single password and attempts logins against many users, allowing them to minimize the number of locked out accounts. Adversaries may also potentially uncover the password for many accounts in cases where organizations have a default password for new accounts or password reuse is being utilized.

Figure 2. Successful password spraying attack against a user within a test Okta environment. Figure 2. Successful password spraying attack against a user within a test Okta environment

Detecting Password Spraying

The following CRT leverages the product’s ability to count the number of successful and failed login attempts within the Okta product. By leveraging these counts, we can then build out metrics of successful logins, failed logins, number of targeted users and the number of originating IP addresses. Organizations can then set thresholds and tune them to ultimately identify this threat vector within their environment. In addition, if using Falcon Identity Threat Protection, this is another detection that is native that can also be used across many SSO/IDP platforms to reduce the work of creating individual rules.

#Vendor="okta"
| event.category[0]=/^(authentication|session)$/
| #event.outcome match {
	success => success_count := 1;
	failure => failure_count := 1;
}
| user.name="*"
| asn("client.ip")
| groupby(field=[#repo,client.ip.org],
    function=[
        sum(success_count, as="total_success"),
        sum(failure_count, as="total_failure"),
        count(as="total"),
        count(client.ip, as="total_ips", distinct="true"),
        count(user.name, as="total_users", distinct="true")
        ]
    ) 
| percent_fail := total_failure/total*100
| percent_success := total_success/total*100
//Adjust thresholds below as appropriate
| total_failure>1000
| percent_fail>90
| total_users>50
| total_ips>1
| percent_success>0 

Okta also provides its own proprietary password spray alerting, which can be surfaced with the following detection rule.

#Vendor=okta
| event.action="security.threat.detected"
| Vendor.debugContext.debugData.threatDetections=/Password Spray/i or event.reason=/Password Spray/i 

Okta also provides alerts for failed authentication attempts for high numbers of users that may not exist. These alerts can serve as a potential precursor for future password spraying attacks as adversaries gain access and enumerate valid user account names.

 

#Vendor=okta
| event.action=security.threat.detected
| event.reason=/Login failures with high unknown users count/i

 

MFA Fatigue Attacks

MFA fatigue is a technique that adversaries use to annoy compromised users into accepting an MFA push notification so the attacker can gain access to a given resource. To demonstrate this, CrowdStrike performed an MFA fatigue attack against a compromised user inside of a test Okta tenant, where the adversary sent a push notification 15 times before the compromised user accepted the push notification and gave the adversary access to the user’s Okta tiles.

Figure 3. MFA fatigue attempt against a test user. Multiple push notifications are sent until a user finally accepts. Figure 3. MFA fatigue attempt against a test user — multiple push notifications are sent until a user finally accepts

Detecting MFA Fatigue

The following rule looks for instances where multiple MFA push notifications are sent to a given user and identifies scenarios where multiple failed push notifications are sent and a successful push notification followed. Note that when a push notification is sent, it’s also transmitted to each registered device, which may result in a slightly skewed threshold used below.

#Vendor="okta" #event.kind="event" #event.module="sso"
| event.action=~in(values=["system.push.send_factor_verify_push", "user.mfa.okta_verify.deny_push", "user.authentication.auth_via_mfa"])
| case {
    Vendor.outcome.result=/fail|deny/i 
    | mfa_failure_time := @timestamp; 
    * | mfa_success_time := @timestamp;
}
| case{
    Vendor.debugContext.debugData.threatSuspected="true";
    Vendor.securityContext.isProxy="true";
    Vendor.debugContext.debugData.behaviors=/(New\sDevice|Device\sEval)\=POSITIVE\,\s(New\sIP|IP\sEval)\=POSITIVE/;
    Vendor.debugContext.debugData.logOnlySecurityData=/reasons\"\:\"[^\"]+|level\"\:\"(?:high|medium|crit)|(?:(?:velocity|new\s+(?:geo\-location|city|device|ip|state|country))\"\:\"(?:POSITIVE|UNKNOWN))/i;
    Vendor.debugContext.debugData.behaviors!=*;
}
| groupBy([user.name, Vendor.authenticationContext.externalSessionId],
    function=[
        count(mfa_failure_time, as="fail_count"),
        count(mfa_success_time, as="success_count"),
        selectLast(mfa_failure_time),
        selectLast(mfa_success_time)
        ]
    )
| fail_count >= 5 success_count >= 1 
| test(mfa_success_time > mfa_failure_time)
| test(fail_count > success_count)

Post-Compromise Attack Vectors

Adversaries employ post-compromise attack vectors after they obtain an initial foothold in the organization. Though we aim to stop breaches at the perimeter of organizations, being able to detect attacks anywhere within the kill chain is vital for defense-in-depth and identifying breaches that may have slipped past perimeter defenses. 

The following section will cover persistence mechanisms related to Okta Terrify and lateral movement techniques that abuse Okta's delegate authority configurations.

Okta Terrify

Okta Terrify is a tool designed to enable persistence to a compromised user’s Okta account. An adversary achieves this persistence by first stealing the compromised user’s DataStore.db database from %LocalAppData%\Okta\OktaVerify\DataStore.db.

The adversary will need to run Okta Terrify on their attack host and run OktaInk.exe from the compromised user’s workstation. Okta Terrify works by dumping information from the stolen DataStore.db database and performing the functionality of Okta Verify from the adversary’s attack host.

The adversary steals sensitive data from the compromised user’s workstation and passes that information to Okta Terrify on the attack host. When executed, Okta Terrify will launch a browser session pointing to the compromised user’s Okta user portal, where the adversary logs in as the compromised user. Okta Terrify will then siphon out data from the interaction. The data is passed to OktaInk.exe — a helper tool for the Okta Terrify toolkit used to sign JSON Web Tokens (JWTs) and steal encryption keys from the compromised user’s workstation — on the compromised user’s host. The adversary uses OktaInk to sign Device Bind JWTs, which are passed back to the attack host with Okta Terrify. Okta Terrify then facilitates the rest of the compromised user’s login session.

Because Okta Terrify has been used to create a fake device bind key with Okta, the adversary’s attack host can be used to continuously log in to the compromised user’s account without the need to maintain access to the compromised user’s workstation.

Identifying Okta Terrify in Use

When executing Okta Terrify, we typically noticed that two user.authentication.auth_via_mfa events were recorded, with different APIs being hit: One to grab a nonce and another to collect the crypto challenge information needed to be imported into OktaInk. Once the OktaInk phase is executed on the victim host, the adversary will have a signed JWT created from the database key and DataStore.db details stored on the victim system. This second request to submit the JWT is an abnormal step in the Okta Verify sequence, offering defenders a detection opportunity. 

The following CRT identifies the two distinct user.authentication.auth_via_mfa events that occur within the same session with the corresponding properties. Since Okta Terrify creates a fake Okta Verify instance, there will be two different enrollment IDs during its authentication steps. The rule accounts for this by counting the number of enrollment IDs within a given session.

#Vendor="okta" #event.module="sso" #event.kind="event"
| array:contains(array="event.category[]", value="authentication")
| event.action="user.authentication.auth_via_mfa"
| groupBy([Vendor.authenticationContext.externalSessionId, user.name],
    function=[
        count(Vendor.AuthenticatorEnrollment.id, as=enrollmentIdCount, distinct=true),
        collect(Vendor.debugContext.debugData.url),
        collect(user_agent.original),
        collect(Vendor.debugContext.debugData.keyTypeUsedForAuthentication),
        collect(Vendor.AuthenticatorEnrollment.detailEntry.methodTypeUsed),
        collect(Vendor.AuthenticatorEnrollment.id)
        ]
    )
| Vendor.debugContext.debugData.url = /^\/idp\/authenticators\//mi Vendor.debugContext.debugData.url=/^\/idp\/idx\/identify\?/mi
| Vendor.AuthenticatorEnrollment.detailEntry.methodTypeUsed=/Use Okta FastPass/mi
| Vendor.debugContext.debugData.keyTypeUsedForAuthentication=/PROOF_OF_POSSESSION/mi
| enrollmentIdCount > 1

A lower-fidelity detection opportunity may also lie in the fact that Okta Terrify has a static user agent. The tool’s author does modify the user agent and has been observed changing it in the past to avoid detection, so we suggest monitoring the repo for the new user agent in case the author’s pattern changes. The rule shown below looks for instances where historically default user agents have been observed within your environment.

#event.module="sso" #Vendor="okta"
| case {
   user_agent.original=/OktaVerify/ user_agent.original=/WPFDeviceSD/i user_agent.original=/Windows/i user_agent.original=/Microsoft_Corporation\/Virtual_Machine/i;
       user_agent.original="OktaVerify/5.1.3.0 WPFDeviceSDK/1.8.0.30 Windows/10.0.22621.3155 Microsoft_Corporation/Virtual_Machine";
}

Account Compromise via Delegate Authority

Some Okta configurations utilize delegate authority to facilitate SSO. Another name for this type of seamless authentication is DesktopSSO. In a completely configured state, a user would log in to their workstation and open a browser to https://org.okta.com. The browser would then trigger a Kerberos request with a local domain controller. The domain controller would verify the user’s credentials and issue a Kerberos ticket to the user’s browser for https://org.okta.com. The browser would take this Kerberos ticket and pass it to https://org.kerberos.okta.com, where Okta would validate the ticket and the user. Once validated, the user would be logged in to their Okta portal.

Compromising an account via delegate authority requires the organization to be enrolled in delegate authority within the Okta admin portal and requires this enrollment to be active. Additionally, a service principal name (SPN) must be configured to handle the authentication.

To outline an example attack, we can hypothesize that a user logs in to their workstation and browses to their organization’s Okta portal, such as https://org.okta.com. The browser, which is configured to utilize integrated Windows authentication, makes a request to the network's key distribution center (KDC) and obtains a Kerberos ticket for org.kerberos.okta.com. The browser sends this ticket to the *.kerberos.okta.com endpoint over HTTPS, which is received and validated, and the user is redirected to https://org.okta.com to be logged in. If the user has MFA methods enabled on their account, the user will be required to submit the MFA token or push notification to log in to their Okta portal. This is an important distinction because the attack described here will fail if the adversary does not have access to the user’s MFA method.

The next step for an adversary is to request a Kerberos service ticket using common attack tools like those from Impacket. This is one area where Falcon Identity Threat Protection could provide attack detection and tool/technique identification as an early warning of the attack in addition to blocking or challenging for access. Going unnoticed or unchallenged, an adversary can obtain a foothold within an organization using tools like Impacket's GetST.py or ticketer.py to obtain a Kerberos ticket for a compromised user:

 

$ getST.py -spn HTTP/org.kerberos.okta.com -dc-ip 1.2.3.4 LAB/testuser

 

With the user’s Okta Kerberos ticket, the adversary can leverage Mimikatz to load the user’s ticket into memory on the compromised user’s workstation. This is another area that can be detected in Identity Threat Protection with the adversary passing the ticket, as shown in the image below.

Figure 4. Test user Jsmith’s stolen Kerberos ticket is loaded into memory with Mimikatz. Figure 4. Test user Jsmith’s stolen Kerberos ticket is loaded into memory with Mimikatz

With the stolen Kerberos ticket in memory on the adversary’s attack host, the adversary would need to ensure that the https://<org>.kerberos.okta.com URL was present within the Local Intranet Sites within the device’s Internet Options and the adversary’s browser was configured for integrated Windows authentication. With these configurations in place, the adversary would simply browse to https://<org>.okta.com to log in to the compromised user’s Okta portal. 

If the compromised user has an MFA method required for their Okta portal, the adversary will need to bypass that factor. But if the compromised user does not require MFA on their account, the adversary can register their own MFA method and use it to maintain a level of persistence within the account.

Detecting Account Compromise

When an organization has DesktopSSO configured, there is a distinct field within the logs that indicates how authentication was initiated. When an attacker steals a Kerberos ticket, they often export it to a device under their control. This device is typically connected to the internet through an anonymized proxy or VPN. There is a native detection for “Access from an IP with a Bad Reputation" in Identity Threat Protection when the attacker uses this device.  In addition, the following CRT identifies suspicious source IPs utilizing DesktopSSO logins within Falcon Next-Gen SIEM. To avoid false positives, organizations may want to consider excluding certain IP ranges, Autonomous System Number (ASNs) or ISPs from this rule. This can be particularly useful if checking for proxies is too restrictive. By excluding approved IP ranges, organizations can reduce the noise and focus on more suspicious activity.

#Vendor="okta" #event.module="sso"
| array:contains(array="event.category[]", value="configuration")
| event.action="policy.evaluate_sign_on"
| Vendor.debugContext.debugData.authMethodFirstType="SSO_SP_INIT" Vendor.debugContext.debugData.authMethodFirstEnrollment="DSSO"
| Vendor.securityContext.isProxy="true"
/* Exclude commonly used ISP's or proxies
| Vendor.securityContext.isp = /(?:netscope|zscaler)/i
| Vendor.debugContext.debugData.tunnels=/ICLOUD_RELAY_PROXY/i
*/

Visualizing Okta Data Within Falcon Next-Gen SIEM

As a part of this research, CrowdStrike developed a custom Falcon Next-Gen SIEM Okta dashboard, enabling organizations to monitor Okta deployments and detect security events in real time. The dashboard features a world map displaying successful logins by location, providing visibility into account activity worldwide. Additionally, the dashboard includes:

  • An Okta alert tracker
  • Risk level distribution analysis
  • Successful events by ISP and country
  • Top accessed applications by count
  • A time-based chart of login events
  • VPN and proxy activity monitoring

All of these widgets can aid in the investigation of potential security issues in real time.

Figure 5. Okta dashboard within Falcon Next-Gen SIEM. Figure 5. Okta dashboard within Falcon Next-Gen SIEM

Conclusion

In this post, we have highlighted the rise of identity-based attacks targeting enterprise environments. By combining the advanced threat detection capabilities of Falcon Next-Gen SIEM and Falcon Identity Threat Protection with Okta’s rich identity data, defenders can rapidly and accurately identify common attacks such as phishing, credential stuffing and privilege escalation. This integrated solution enables defenders to take swift action to neutralize threats.

To further aid defenders in their pursuit of robust identity security, we have provided a set of CRTs that can be used in conjunction with the Falcon Next-Gen SIEM dashboard and native cross-platform detections within Falcon Identity Threat Protection. The CRT templates are designed to help defenders detect and respond to identity-based attacks, and organizations can customize them to meet their unique needs.

By leveraging the Falcon Next-Gen SIEM, Falcon Identity Threat Protection and Okta solutions, defenders can:

  • Rapidly detect and respond to identity-based attacks
  • Accurately identify and mitigate threats
  • Protect their organizations from devastating breaches
  • Stay ahead of emerging threats with advanced threat intelligence

The following CRTs were generated as a result of this research:

  • Okta - SSO - Suspicious Spike Policy Evaluation During Login
  • Okta - SSO - Suspicious Session Properties
  • Okta - SSO - Okta Terrify Execution
  • Okta - SSO - Suspicious Kerberos Authentication Location

The following dashboard has been created and is available for all NG-SIEM customers:

  • Okta - SSO - User Activity

Additional Resources

Breaches Stop Here