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 sign-in attempts by 'Break Glass' accounts. Break Glass accounts are emergency access accounts typically used in situations where normal administrative access methods are unavailable. Monitoring their usage is critical due to the high privileges usually associated with these accounts. The rule joins sign-in logs with a watchlist of identities to specifically identify activity related to these designated accounts.
Detects a high volume of Kerberos pre-authentication failures (Event ID 4771, Status 0x18) against multiple distinct user accounts originating from a single source IP address within a short time window. This behavior is characteristic of password spraying attacks where an attacker attempts a small number of common passwords across many accounts to avoid lockouts and detection in a Windows Active Directory environment.
This rule detects successful SSH authentication attempts originating from IP addresses that are not classified as private (non-RFC1918). It specifically looks for log entries indicating 'Accepted password' or 'Accepted publickey' and then filters out source IP addresses that fall within common private IPv4 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16). The rule is designed to identify SSH access from external networks, which might be unusual in environments where SSH is expected to be primarily internal. It does not account for IPv6 private addresses.
This rule detects successful sign-ins to Azure Active Directory (AAD) from IP addresses outside of Australia and New Zealand, where the User-Agent string matches a list of known suspicious User-Agents. It filters out many legitimate User-Agents to reduce false positives, including those from Microsoft applications, mobile devices, and common tools.
Detects a successful user login from a country that is on a restricted or high-risk list. This can indicate account compromise or policy violation.
Detects Windows logon events where the account name starts with 'WAC_' and belongs to a domain outside of the organization's tenant. This pattern is a key indicator for CVE-2026-20965 exploitation, where an attacker uses a forged token from an external tenant to gain unauthorized access to a Windows Admin Center (WAC) managed machine.
Detects a user successfully logging in from multiple different countries within a short time frame (4 hours). This is a strong indicator of account takeover (T1078).
This rule detects successful sign-ins to Azure Active Directory (AAD) from IP addresses outside of New Zealand and Australia, where the User-Agent string matches a list of known suspicious User-Agents. It filters out many legitimate User-Agents to reduce false positives, including those from Microsoft applications, mobile devices, and common system services. The rule aims to identify potential unauthorized access attempts or compromised accounts leveraging unusual client software or scripts.
This rule detects the creation of scheduled tasks on remote systems using the 'schtasks.exe' utility. Specifically, it looks for instances where a scheduled task is created with high-privilege accounts such as 'Administrator', 'SYSTEM', or 'NT AUTHORITY'. The detection logic requires the presence of '/create', '/s' (specifying a remote system), '/tr' (task run), '/tn' (task name), and '/ru' (run as user) flags in the command line. It explicitly filters out tasks created on the local machine (localhost, 127.0.0.1, ::1). This activity is indicative of potential lateral movement or privilege escalation, as adversaries often use remote scheduled tasks to establish persistence or execute commands on other systems within a network with elevated privileges.
This rule detects successful user sign-ins to Azure AD from IP addresses located outside of New Zealand and Australia, where the User-Agent string matches a known list of suspicious user agents. It filters out common legitimate user agents to reduce false positives.
Detects authentication attempts (successful or failed) against designated canary user accounts. Any such attempt is highly suspicious as these accounts have no legitimate purpose and indicate credential theft or discovery activity. Creation of Canary Accounts with scripts and other strategies can be found here: https://github.com/fluffybunnies-h4x/CyberDeception?tab=readme-ov-file#canary-accounts
This rule detects a multi-stage attack chain starting with a high-confidence phishing email, followed by a risky sign-in from the recipient, and culminating in sensitive actions within Azure, specifically targeting IAM role assignments, storage account key access, or AKS cluster modifications. The detection correlates these events within a defined time window to identify potential compromise of cloud resources originating from a successful phishing attack.
Detects when a user flagged as 'high risk' by Azure AD Identity Protection lists storage account keys. This could indicate a compromised account is being used to access sensitive data or escalate privileges.
This detection identifies successful logon activity (Event ID 4624) on a device that has been reported as stolen or missing. Such activity is highly suspicious and could indicate unauthorized access. The rule enriches the alert with ISP IP information from Azure AD sign-in logs to aid in investigation.
This attack shares a lot of similarities with ClickFix/FileFix, AiTM phishing, and OAuth Consent Phishing. You can think of this as a browser-native ClickFix attack that phishes an OAuth token on a target app by getting the victim to copy and paste a URL containing OAuth key material into a phishing page.
This rule detects successful sign-ins that used single-factor authentication and were flagged by Azure AD Identity Protection for having unfamiliar properties, such as a new location, device, or ASN. Single-factor authentication is inherently weaker, and when combined with anomalous sign-in properties, it can be an indicator of a compromised account.
Detects HTTP POST requests to the Appsmith password reset endpoint where the 'Origin' header does not match the expected internal or legitimate application domain. This is indicative of an attempt to exploit CVE-2026-22794 to achieve account takeover.
This rule detects logon events from Windows Admin Center (WAC) virtual accounts where the associated user principal name (UPN) belongs to an external or unknown tenant. This activity is a key indicator of compromise for CVE-2026-20965, where an attacker uses a forged token from an external tenant to gain unauthorized access.
This rule detects successful administrative logins to Fortinet devices (FortiGate, FortiWeb, FortiProxy, FortiSwitchManager) that leverage the FortiCloud SSO mechanism from an IP address not on an allowlist. This could indicate exploitation of CVE-2025-59718 and CVE-2025-59719, which allow for an authentication bypass.
This alert finds sessions where a device-code flow produced multiple sign-in events (interactive + non-interactive), with mismatched user-agents or differing country/geolocation, for the same Session ID - a strong indicator of device-code phishing abuse.
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
Looks for Metadata IOCs as listed in the CISA report on BrickStorm C2 malware.
I don't recommend using this query on its own; rather, use it in conjunction with behavioural analysis to look for evidence of BrickStorm activity.
https://media.defense.gov/2025/Dec/04/2003834878/-1/-1/0/MALWARE-ANALYSIS-REPORT-BRICKSTORM-BACKDOOR.PDF
I don't recommend using this query on its own; rather, use it in conjunction with behavioural analysis to look for evidence of BrickStorm activity.
https://media.defense.gov/2025/Dec/04/2003834878/-1/-1/0/MALWARE-ANALYSIS-REPORT-BRICKSTORM-BACKDOOR.PDF
Page 41 of 59