Detections

Explore public detection logic contributed by the community across SIEM and rule languages.

172 detections

The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0038
The following analytic identifies the provisioning of a new MFA device shortly after a password reset. It detects this activity by correlating Windows Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating device pairing. This behavior is significant as it may indicate a social engineering attack where a threat actor impersonates a valid user to reset credentials and add a new MFA device. If confirmed malicious, this activity could allow an attacker to gain persistent access to the compromised account, bypassing traditional security measures.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0038
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.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0037
The analytic identifies multiple failed multi-factor authentication (MFA) requests for a single user within a PingID environment. It triggers when 10 or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity is significant as it may indicate an adversary attempting to bypass MFA by bombarding the user with repeated authentication requests. If confirmed malicious, this could lead to unauthorized access, as the user might eventually accept the fraudulent request, compromising the security of the account and potentially the entire network.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0037
This analytic identifies failed authentication attempts during the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It specifically looks for events where the authentication signature is `user.authentication.auth_via_mfa` and the action is `failure`. This activity is significant as it may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled, potentially suggesting an ongoing attempt to bypass MFA protections and gain unauthorized access.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0036
The analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on `security.threat.detected` events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0036
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.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0036
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.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
1035
The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0035
The following analytic identifies when an associate reports a login attempt as suspicious via an email from Okta. It leverages Okta Identity Management logs, specifically the `user.account.report_suspicious_activity_by_enduser` event type. This activity is significant as it indicates potential unauthorized access attempts, warranting immediate investigation to prevent possible security breaches. If confirmed malicious, the attacker could gain unauthorized access to sensitive systems and data, leading to data theft, privilege escalation, or further compromise of the environment.
Splunk Security@SplunkSecurity
avatar
Splunk Security Content
1 year ago
0033
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
3057
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
000
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).
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
10114
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
0084
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
2082
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
0079
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'.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
1075
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).
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
6050
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
0050
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
0047
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.
avatar
Google SecOps@GoogleSecOps
avatar
Google SecOps Detection Rules
2 years ago
0044
Page 7 of 9