Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,061 detections
Filters
Last updated
All Time
Detection languages
594
173
103
71
51
Contributors
184
155
139
90
73
Categories
20,443
11,831
5,872
5,155
4,866
1,061
Platforms
576
267
228
221
116
Products / Services
499
220
129
118
86
MITRE Techniques
487
451
362
349
339
CVEs
10
5
4
3
2
IDS Classtypes
34
3
2
2
1
IDS Protocols
29
9
1
Detects when a GitHub Personal Access Token (PAT) is created from an IP address identified as a Tor exit node. This activity is suspicious because adversaries often use Tor to anonymize their network traffic when performing malicious actions, such as establishing persistence or exfiltrating data. The creation of a PAT from a Tor IP could indicate an attacker attempting to gain persistent access to a GitHub account or repository before carrying out further actions like cloning repositories to steal data.
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 instances where a MySQL service on an OpenCanary honeypot has had a login attempt. This indicates an adversary is attempting to gain unauthorized access to the honeypot's emulated MySQL service, which can be a sign of reconnaissance or credential stuffing activities.
Detects instances where an MSSQL service on an OpenCanary honeypot node has had a login attempt using Windows Authentication. This indicates an adversary is attempting to authenticate against a honeypot, which is highly suspicious.
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.
This rule detects HTTP POST login attempts against an OpenCanary honeypot. OpenCanary is a honeypot designed to mimic various services to detect unauthorized access attempts. A 'logtype' of 3001 specifically indicates an HTTP service login attempt via a form POST, suggesting an adversary is trying to gain initial access or credentials by interacting with the emulated service.
This rule detects successful logins to the AWS console where Multi-Factor Authentication (MFA) was not used. It specifically looks for 'ConsoleLogin' events from AWS CloudTrail with an 'ALLOW' action and where 'MFAUsed' is explicitly set to 'No'. The rule also increases the risk score if the login is performed by a 'Root' user.
This rule detects successful AWS API calls originating from an IP address identified as a Tor exit node. It leverages a GCTI Feed for Tor exit node IP listings and also calculates a risk score based on the geographical location of the originating IP, specifically increasing the score for connections from Cuba, Iran, North Korea, Russia, and 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 potential lateral movement within an AWS environment where an IAM session token, obtained via `GetSessionToken`, is subsequently used from a different IP address than where it was initially requested. This behavior can indicate an attacker has compromised credentials and is attempting to use them from a new location.
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 brute force activity targeting Amazon EC2 or Amazon RDS instances, as reported by AWS GuardDuty. It specifically looks for GuardDuty findings where the product event type contains 'BruteForce' and filters out sample findings.
This rule detects when an Okta end-user reports suspicious activity on their account. This could indicate that the user's account has been compromised or is being targeted by an attacker. The rule specifically looks for the 'user.account.report_suspicious_activity_by_enduser' event type in Okta logs. The risk score is increased if the suspicious activity event type is related to an MFA enrollment notification being sent, suggesting a potential attempt to enroll an unauthorized MFA device.
Detects when a single user successfully logs into Okta from multiple distinct cities within a 24-hour period. This behavior can indicate a compromised account being used by an attacker from a different geographical location than the legitimate user, or a user traveling rapidly between distant locations. The rule also incorporates risk scoring based on Okta ThreatInsight and logins from suspicious countries.
This rule detects a successful OneLogin login event that is preceded by multiple failed One-Time Password (OTP) attempts within a 15-minute window for the same user. Specifically, it looks for at least four failed OTP challenges followed by a successful OTP verification and then a successful user login. This pattern is indicative of an OTP brute-force attack where an attacker is attempting to guess the correct OTP.
This rule detects when a single user account (principal) assumes the identity of multiple other user accounts (targets) within the OneLogin SSO system. Specifically, it triggers if a user, identified by their `userid`, performs "USER_RESOURCE_ACCESS" events as more than 3 distinct target users within a one-hour window. This behavior can indicate an attacker attempting to gain access to multiple accounts after compromising a single set of credentials, or an insider abusing their privileges.
This rule detects suspicious user login activity where a single user attempts to log in from multiple distinct countries within a 24-hour period. This behavior can indicate a compromised account being used by an attacker from a different geographic location than the legitimate user, or a user attempting to bypass security controls. The rule also assigns a higher risk score if the login originates from specific high-risk countries (Cuba, Iran, North Korea, Russia, Syria).
Okta ThreatInsight detects access requests from known malicious IPs targeting a specific org.
Detects user logins for same user from different cities within 24 hours.
Okta Mismatch Between Source and Response for Verify Push Request
Page 49 of 51