Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
222 detections
Filters
Last updated
All Time
Detection languages
74
58
57
20
7
Contributors
65
44
37
25
14
Categories
63
54
49
48
47
Platforms
199
35
13
8
8
Products / Services
10,650
9,755
6,688
4,418
3,745
222
MITRE Techniques
107
84
66
51
35
CVEs
1
1
1
This analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within an Okta tenant. It triggers when more than 10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests, a technique used by threat actors like Lapsus and APT29. If confirmed malicious, this could lead to unauthorized access, potentially compromising sensitive information and systems.
The analytic identifies discrepancies between the source and response events for Okta Verify Push requests, indicating potential suspicious behavior. It leverages Okta System Log events, specifically `system.push.send_factor_verify_push` and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection groups events by SessionID, calculates the ratio of successful sign-ins to push requests, and checks for session roaming and new device/IP usage. This activity is significant as it may indicate push spam or unauthorized access attempts. If confirmed malicious, attackers could bypass MFA, leading to unauthorized access to sensitive systems.
The following analytic identifies attempts by users to access Okta applications that have not been assigned to them. It leverages Okta Identity Management logs, specifically focusing on failed access attempts to unassigned applications. This activity is significant for a SOC as it may indicate potential unauthorized access attempts, which could lead to exposure of sensitive information or disruption of services. If confirmed malicious, such activity could result in data breaches, non-compliance with data protection laws, and overall compromise of the IT environment.
The analytic identifies failed user authentication attempts in Okta where FastPass explicitly declined a phishing attempt. This indicates that users are being targeted by real-time phishing proxies attempting to capture credentials. Successful exploitation could lead to unauthorized account access and further compromise.
This analytic detects the execution of the 'shred' command on a Linux machine, which is used to overwrite files to make them unrecoverable. It leverages data from Linux Auditd, focusing on process names and command-line arguments. This activity is significant because the 'shred' command can be used in destructive attacks, such as those seen in the Industroyer2 malware targeting energy facilities. If confirmed malicious, this activity could lead to the permanent destruction of critical files, severely impacting system integrity and data availability.
The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network.
The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment.
Detects when an Okta user's password is reset and MFA factor(s) are deactivated or reset within a 30-minute time window. This activity may indicate that the user account has been compromised, as an attacker might reset the password and then disable MFA to maintain access.
Detects when an Okta user's password is reset and MFA factor(s) are deactivated or reset within a 30 minute time window. This activity may indicate that the user account has been compromised.
Detects when an Okta user rejects more than 2 Push notifications in a 10 minute window. This behavior can indicate an attacker attempting to gain access to an account by repeatedly sending MFA push notifications, hoping the user will eventually accept one (MFA fatigue).
This rule detects a successful Okta login that occurs after multiple failed MFA push notifications within a 15-minute window. It correlates 'system.push.send_factor_verify_push' events (representing MFA push attempts) with a subsequent 'user.authentication.auth_via_mfa' event (representing a successful MFA authentication and login). The rule specifically looks for more than 4 MFA push attempts followed by a successful login, indicating a potential MFA brute-force or push fatigue attack.
Detects successfully authenticated user logins to Okta based on Okta's Behavior Detection pattern analysis, specifically looking for high-risk indicators such as new geo-location, new device, new IP, new city, new state, new country, or velocity anomalies. It also flags logins originating from unauthorized target geographies like Cuba, Iran, North Korea, Russia, and Syria. The rule only applies to existing users, not newly created ones.
This rule detects failed authentication attempts in Okta where the security result indicates a "FastPass declined phishing attempt." This specifically targets real-time Adversary-in-the-Middle (AiTM) phishing proxy attacks against users enrolled in Okta FastPass, which is designed to prevent such attacks by checking the origin of the authentication request.
Detects when a user's account in Okta is locked out or has reached the lockout limit, indicating potential brute-force attempts or suspicious login activity. The rule specifically looks for 'user.account.lock.limit' or 'user.account.lock' events where the security result action is 'BLOCK'.
This rule detects suspected brute force attacks against Okta accounts. It triggers when Okta ThreatInsight identifies multiple login failures from the same IP address across one or more Okta organizations. The rule also increases the risk score if the IP address is marked as suspicious by Okta ThreatInsight or if the login attempts originate from specific high-risk countries (Cuba, Iran, North Korea, Russia, Syria).
Detects multiple failed requests to access different applications within a short timeframe from the same network session. This could indicate an adversary attempting to bypass authentication mechanisms, potentially using stolen session cookies or brute-forcing access to various applications after an initial compromise. The rule also incorporates risk scoring based on behavioral anomalies (e.g., new geo-location, new device, new IP) and access attempts from high-risk countries.
This rule detects when an Okta user fails a number challenge during a push notification for multi-factor authentication. This specific failure occurs when the user provides an invalid response to the number challenge, leading to the authentication attempt being blocked. This could indicate an attacker attempting to gain access to an account by repeatedly sending MFA push notifications, hoping the user will eventually accept or incorrectly respond to the challenge.
This rule detects a potential Okta push fatigue attack or a mismatch between the source of an Okta Verify push request and the subsequent authentication response. It correlates an Okta push notification event (system.push.send_factor_verify_push) with an Okta authentication event (user.authentication.auth_via_mfa) where both events share the same parent session ID. The rule specifically looks for push requests that Okta has flagged with 'New Device=POSITIVE' and 'New IP=POSITIVE' in the security result description, indicating an unusual access attempt, followed by a successful MFA authentication via Okta Verify Push. The outcome section calculates a risk score based on various security result descriptions from Okta's behavior detection (e.g., New Geo-Location, New Device, New IP, Velocity) and attempts from unauthorized target geographies.
This rule detects suspicious Okta login attempts where a stolen web session cookie might be reused. It specifically looks for a single user (identified by `userid`) attempting to log in from multiple distinct IP addresses AND from multiple distinct browsers or operating systems within a one-hour window. This behavior is indicative of an adversary attempting to bypass authentication mechanisms by replaying a stolen session cookie from a different device or location.
This rule detects multiple login failures from the same IP address targeting unknown users, as identified by Okta's ThreatInsight. It specifically looks for Okta events categorized as 'USER_UNCATEGORIZED' and 'security.threat.detected' with a summary indicating 'Login failures with high unknown users count'. The rule also incorporates risk scoring based on whether the IP address is deemed suspicious by Okta ThreatInsight and if the login attempts originate from certain high-risk countries.
This rule detects multiple failed login attempts from different users originating from the same IP address within a one-hour window in Okta. It specifically looks for events where the login attempt was blocked due to invalid credentials. The rule also incorporates risk scoring based on Okta ThreatInsight detections and behavioral patterns like new geo-location, device, or IP, as well as logins from unauthorized geographies (Cuba, Iran, North Korea, Russia, Syria). The detection is triggered if more than 5 distinct user IDs attempt to log in with invalid credentials from the same IP within the specified timeframe.
Page 10 of 11