Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,064 detections
Filters
Last updated
All Time
Detection languages
597
173
103
71
51
Contributors
184
155
139
90
73
Categories
20,443
11,831
5,875
5,151
4,864
1,064
Platforms
575
266
228
223
118
Products / Services
498
220
130
118
86
MITRE Techniques
488
451
363
349
341
CVEs
10
5
4
3
2
IDS Classtypes
34
3
2
2
1
IDS Protocols
29
9
1
This rule detects login activity by Azure AD administrators to Microsoft cloud applications that are not part of a predefined list of common first-party applications. The rule specifically looks for successful logins where the application ID is not in the 'first_party_ms_cloud_apps' list and the user ID is present in the 'entra_id_admin_watchlist'. This helps identify potentially unusual or unauthorized access by administrators to less common or custom applications, which could indicate compromise or policy violation.
This rule detects Azure AD login activity to applications that are not part of a predefined list of first-party Microsoft Cloud Apps. This could indicate an attempt to access an unauthorized or unusual application within the Azure AD environment, potentially by a compromised account or an insider threat. The rule specifically excludes the 'On-Premises Directory Synchronization Service Account' to reduce false positives related to ADFS synchronization.
This rule detects persistent login activity to the Azure AD PowerShell application. Specifically, it looks for successful user logins to the application identified by the product object ID '1b730954-1685-4b74-9bfd-dac224a7b894' (which corresponds to Azure AD PowerShell) by the same user ID over a 24-hour period. The rule is designed to flag continuous access to this administrative tool, which is not considered a security best practice and warrants further investigation.
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).
Page 49 of 51