Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,235 detections
Filters
Last updated
All Time
Detection languages
734
214
105
78
51
Contributors
206
187
159
111
90
Categories
396
296
264
260
247
Platforms
492
314
281
204
110
Products / Services
379
234
152
109
106
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
1,235
CVEs
9
9
4
4
4
IDS Classtypes
11
6
4
2
1
IDS Protocols
10
5
3
This rule detects potential 'impossible travel' scenarios within Azure AD sign-in logs. It identifies users who successfully sign in to Office 365 from two geographically distant IP addresses within a one-hour window, suggesting a potential compromise or an attempt to bypass security controls.
Detects when the same SessionId is used to sign in from more than one location across interactive and non-interactive sign-ins.
The detection looks for Entra ID sign-in events where both the source country and user agent string are new for the authenticating account(e.g., neither value has been seen during the 14-day training window (days 14–2 prior to now)). This can be changed easily in the let variable
The double signal requirement is intentional. A new country alone is relatively common (VPN usage, business travel, Microsoft service IPs), and a new user agent alone is low signal (browser updates, new devices). Requiring both to be new on the same sign-in increases fidelity, while still capturing the pattern typically associated with credential compromise or account takeover.
Sign-in events are collapsed to a single row per user per country, with EventStartTime and EventEndTime showing the first and last sign-in seen within the defined detection window.
A dynamic risk score is applied on top of the core detection to drive alert severity so you can set noise for your environment to 'informational' and reduce SOC alert fatigue.
Set the `HighRiskCountries` array to suit your risk profile
The double signal requirement is intentional. A new country alone is relatively common (VPN usage, business travel, Microsoft service IPs), and a new user agent alone is low signal (browser updates, new devices). Requiring both to be new on the same sign-in increases fidelity, while still capturing the pattern typically associated with credential compromise or account takeover.
Sign-in events are collapsed to a single row per user per country, with EventStartTime and EventEndTime showing the first and last sign-in seen within the defined detection window.
A dynamic risk score is applied on top of the core detection to drive alert severity so you can set noise for your environment to 'informational' and reduce SOC alert fatigue.
Set the `HighRiskCountries` array to suit your risk profile
This rule detects an unusually high volume (5 or more within an hour) of successful logons by 'SYSTEM' or 'LOCAL SERVICE' accounts. While these are legitimate system accounts, a sudden surge in their logon activity could indicate unusual system behavior, potential compromise, or misconfiguration leading to excessive system account usage.
This rule detects potential lateral movement activity by identifying a single user account attempting to log on to five or more distinct computers with at least ten logon attempts within a five-minute window. It specifically looks for successful logons (EventID 4624) with network, remote interactive, or remote desktop logon types (LogonType 3, 9, 10) and excludes machine accounts (TargetUserName not ending with '$'). This pattern can indicate an adversary attempting to spread across the network using compromised credentials.
This rule detects suspicious activity where a user successfully performs a multi-factor authentication (MFA) device login to Microsoft Office 365 via a browser, and within a 15-minute window, the same user either creates a new inbox rule or adds a new device. This combination of events could indicate an adversary gaining initial access and then setting up persistence (e.g., forwarding emails) or further device enrollment.
This rule detects potential GitHub token theft or abuse activity by identifying GitHub tokens that are used from an unusually high number of distinct IP addresses or for an unusually high number of uses within a one-hour window. Specifically, it looks for tokens with more than 5 uses and more than 2 distinct IP addresses in an hour. This behavior could indicate that a compromised token is being used by an attacker from multiple locations or in an automated fashion.
This rule detects suspicious activity involving the creation or update of managed identities and the assignment of highly privileged roles (Contributor, Owner, User Access Administrator) to them. It specifically looks for multiple such assignments within a one-hour window to managed identities associated with automation, runbook, or function resources, indicating potential privilege escalation or malicious access.
This rule detects an account performing multiple interactive logons (LogonType 2) from at least 3 unique IP addresses within a 5-minute window. This behavior can indicate credential compromise or an adversary attempting to move laterally or access multiple systems using stolen credentials.
This rule detects when a single user principal name (UPN) attempts five or more sign-ins from the same IP address within a one-hour window, and each sign-in is flagged with a 'RiskDetail' other than 'none' but still results in a 'Success' status. This could indicate an attacker attempting to bypass security controls or an account compromise where the attacker is repeatedly trying to access the account from a consistent location, possibly with different credentials or methods, until successful.
This rule detects multiple successful RDP logons (LogonType 10) within a one-hour window by accounts containing '$' (often machine accounts) or 'admin' (privileged accounts). This behavior can be indicative of an adversary attempting to gain remote access and potentially deploy ransomware or other malicious payloads, especially if multiple source IPs are observed.
This rule detects potential lateral movement activity by identifying a single user account attempting to log on to five or more distinct computers with at least ten logon attempts within a five-minute window. It specifically looks for successful logons (EventID 4624) with network, remote interactive, or remote desktop logon types (LogonType 3, 9, 10) and excludes machine accounts (TargetUserName not ending with '$'). This pattern can indicate an adversary attempting to spread across the network using compromised credentials.
This rule detects suspicious Azure AD sign-in activity where a user successfully signs in from multiple unusual cities within a 24-hour period. It specifically looks for sign-ins that are not from a trusted network and are not from a compliant device, aggregating successful sign-ins by UserPrincipalName and IpAddress, and flagging if there are 5 or more distinct cities.
This rule detects potential 'impossible travel' scenarios within Azure AD sign-in logs. It identifies users who successfully sign in to Office 365 from two geographically distant IP addresses within a one-hour window, suggesting a potential compromise or an attempt to bypass security controls.
This rule detects multiple successful RDP logons (LogonType 10) within a one-hour window by accounts containing '$' (often machine accounts) or 'admin' (privileged accounts). This behavior can be indicative of an adversary attempting to gain remote access and potentially deploy ransomware or other malicious payloads, especially if multiple source IPs are observed.
Detects a successful login from a non-compliant, unmanaged device followed by an inbox rule creation or modification within 10 minutes. This sequence aligns with post-compromise evasion tactics observed in device code phishing campaigns like Kali365, where attackers quickly suppress security alerts after gaining access.
Detects the execution of the zenity dialog tool spawned by unusual parents (like IDEs or bash scripts) to create fake password prompts on Linux. The Linux variant of UNK_DeadDrop utilizes this to trick developers into providing their system passwords, enabling root access and GNOME Keyring extraction.
This rule detects a suspicious sequence of events in Okta that could indicate a help-desk social engineering attack or account takeover. Specifically, it looks for a user's password being reset, followed by the enrollment of a new MFA factor or device for that same user, all occurring within a short time frame (1 hour) and potentially from distinct session IDs or device hashes. This pattern suggests an attacker has gained initial access (e.g., via social engineering the help desk) and is immediately attempting to establish persistence by enrolling their own MFA device.
This rule detects suspicious Azure AD sign-in activity where a user successfully signs in from multiple unusual cities within a 24-hour period. It specifically looks for sign-ins that are not from a trusted network and are not from a compliant device, aggregating successful sign-ins by UserPrincipalName and IpAddress, and flagging if there are 5 or more distinct cities.
This rule detects an SSH brute force attack by monitoring TCP connections to port 22 (SSH) on the home network. It triggers an alert if more than 20 TCP SYN packets are observed from a single source IP address within a 60-second window, indicating a high volume of connection attempts characteristic of a brute force.
Cortex Policy or Rule Modification
Cortex XDR
This rule detects modifications to Cortex prevention policies or detection rules. Specifically, it looks for creation, editing, or deletion of policy profiles, and editing, reordering, or reverting of prevention policy rules. Authorized personnel can be added to the email filter and this rule can serve as a detection for unauthorized tampering.
Page 35 of 59