Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,982 detections
Filters
Last updated
All Time
Detection languages
1,486
513
403
239
167
Contributors
986
658
304
198
109
Categories
916
822
673
590
452
Platforms
39,931
7,261
6,535
3,864
3,642
2,982
Products / Services
1,229
703
443
309
200
MITRE Techniques
1,053
824
459
384
348
CVEs
17
16
16
10
10
IDS Classtypes
24
7
7
4
3
IDS Protocols
49
1
This rule generates alerts based on Google Workspace Alerts Center data and aggregates them by severity. It processes events from 'Google Workspace Alerts' and assigns a risk score based on the severity of the alert (LOW, MEDIUM, HIGH). The rule also extracts various details from the alerts such as event count, event type, product event type, security category details, security category, security investigation tool link, security summary, and alert severity.
This rule identifies when a user shares a file from Google Drive with an email address belonging to a common free email domain (e.g., gmail.com, aol.com, hotmail.com, outlook.com, icloud.com). This activity is flagged as it may indicate an attempt at data exfiltration, where sensitive information is moved outside the organization's controlled environment to personal or untracked accounts.
This rule identifies when multi-factor authentication (MFA) is disabled for a Google Workspace organization. This change can weaken the organization's security posture by removing an important layer of defense against unauthorized access. Security teams should monitor for such changes to prevent potential account compromise.
This rule identifies when the password policy configuration is changed within Google Workspace. Monitoring these changes is crucial for security teams to detect potential weakening of the organization's security posture, which could be exploited by adversaries to maintain or elevate access.
Identifies when a user deletes multiple files from Google Drive within a one-hour period. This activity may indicate an attempt at data destruction or an insider threat activity.
This rule identifies when a Google Workspace user shares a file on Google Drive shortly after a suspicious login event has occurred. It correlates a successful login event flagged as suspicious with subsequent Google Drive file sharing activities (changing user access, document visibility, access scope, or ACL editors) by the same user within a one-hour window. This behavior could indicate an attacker gaining access to an account and then exfiltrating data.
This rule identifies when a user account is unsuspended within Google Workspace. Unsuspending an account can be a legitimate administrative action, but it can also indicate an adversary reactivating a previously disabled account to regain access or enable further malicious activity. Monitoring this activity is crucial for detecting potential account takeover or persistence mechanisms.
This rule identifies when a single user copies a large number of files from Google Drive within a one-hour period. This behavior can be indicative of data exfiltration attempts, where an attacker or malicious insider is trying to move sensitive data out of the organization's control. The rule specifically looks for 'copy' or 'source_copy' events within Google Workspace Drive logs and triggers if more than 10 distinct documents are copied by the same user in an hour.
This rule identifies when a Google Workspace user transfers the ownership of a file within Google Drive. This activity is logged as a 'CREATE_DATA_TRANSFER_REQUEST' event in the Google Workspace admin logs, specifically categorized under 'USER_SETTINGS'. This could indicate an attempt to move sensitive data to a different account, potentially for exfiltration or to obscure ownership.
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 identifies when the Google Workspace Marketplace allowlist is configured to allow users to install and run any applications from the Marketplace. This configuration may increase an organization's risk of data exfiltration/leakage and expand its attack surface by permitting the use of potentially malicious or unapproved third-party applications.
Identifies when an administrator role is assigned to a user account in Google Workspace. Security teams can monitor for the malicious or accidental assignment of administrator privileges to prevent unauthorized access to data. The rule specifically looks for `USER_RESOURCE_UPDATE_PERMISSIONS` events with `ASSIGN_ROLE` as the product event type and `DELEGATED_ADMIN_SETTINGS` in the security result category details. It also calculates a higher risk score if the assigned role is `_SEED_ADMIN_ROLE`.
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.
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 multiple failed login attempts from different users originating from the same IP address within a one-hour window in OneLogin. It specifically looks for 'USER_LOGIN' events with a 'BLOCK' security result and a product event type of '6' (user failed authentication). The rule also calculates a risk score, which is increased if the originating IP address is from certain unauthorized geographies (Cuba, Iran, North Korea, Russia, Syria). This behavior is indicative of potential brute-force attacks or credential stuffing attempts against multiple user accounts from a single source.
Page 139 of 142