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
Detects potential JSON Web Token (JWT) authentication bypass attempts where the algorithm in the token header is explicitly set to "none". A vulnerable server might skip signature validation for such tokens, allowing an attacker to forge arbitrary claims and potentially gain unauthorized access or escalate privileges.
This rule detects 'impossible travel' scenarios where a user successfully signs in from two geographically distant locations within an implausibly short time frame (less than 120 minutes). It specifically looks for sign-ins where the country of origin changes between consecutive successful login events for the same user.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google NetNTLMv1 Deprecation RainbowTables. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: a Windows logon event that explicitly shows LM or NTLMv1 as the package used. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/net-ntlmv1-deprecation-rainbow-tables) to document where the indicator came from and to support incident notes and reporting.
Multi-layered detection rule that identifies anomalous behavior on privileged accounts across six independent detection layers: absolute rule violations ("never actions"), self-calibrating ratio-based thresholds, behavioral technique substitution (e.g., WMI drop-off while other lateral movement continues), time-series statistical anomaly detection via series_decompose_anomalies(), reconnaissance burst detection on LDAP/directory queries, and MFA gap analysis. All layers roll up into a composite risk score for analyst prioritization. Originally derived from diffpatterns() analysis of real penetration test data vs. normal operations, this community edition replaces environment-specific hardcoded thresholds with self-calibrating statistical baselines. Requires Microsoft Defender for Identity and Entra ID Sign-in Logs.
This rule detects suspicious activity where an 'unfamiliar sign-in properties' alert occurs shortly after an administrator has changed a user's Multi-Factor Authentication (MFA) method. It correlates security alerts for unfamiliar sign-ins with audit logs indicating MFA method changes for the same user within a short timeframe. The rule then checks if the user's sign-in activity shows multiple IP addresses or locations, indicating a potential compromise or MFA bypass after the change.
This rule detects sign-ins by Azure Managed Identities where the token was likely obtained via the Instance Metadata Service (IMDS). It identifies these sign-ins by looking for 'ImdsIdentityProvider' in the UserAgent or 'Imds' in the ClientCredentialType within AADManagedIdentitySignInLogs. This activity could indicate lateral movement through abuse of managed identities attached to virtual machines.
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.
Identifies successful Entra ID sign-ins using the Device Code Flow from a geographic location not seen for that user in the last 30 days. The device code flow involves two separate interactions (the attacker's device and the victim's browser), so a mismatch between the sign-in location and the user's established locations is a strong indicator of a session hijacking attempt.
This rule detects inbound SSH connections originating from external IP addresses to systems running SSH services. It specifically looks for successful incoming network connections where the destination port is commonly associated with SSH (22, 222, 2222, 8022) or the source process name is an SSH daemon (sshd, dropbear). The rule explicitly excludes connections from private IP ranges and certain common web server processes on standard web ports to reduce false positives. The threat model includes unauthorized external SSH access, brute-force/credential-stuffing attacks, backdoor SSH daemons, compromised servers accepting attacker sessions, and reverse shell callbacks.
This rule detects a correlated attack chain involving LDAP Service Principal Name (SPN) enumeration followed by Kerberoasting activity. It identifies an actor performing LDAP queries for SPNs, then links that actor to subsequent Kerberos Ticket-Granting Service (TGS) requests for those service accounts within a defined time window. The rule specifically looks for a minimum number of unique service accounts targeted to trigger an alert, indicating a potential Kerberoasting attack.
Detects when a user authorizes the 'ToogleBox Recall' Google Workspace add-on. This tool has been observed being used by threat actors like UNC6661 (associated with ShinyHunters) to automate the deletion of MFA enrollment notifications, hiding unauthorized device registrations.
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.
This query detects suspicious sign-in activity from a user who has recently clicked on a phishing link. It correlates email click events with sign-in logs, identifying sign-ins from new or infrequent IP addresses after a user has interacted with a suspicious email. The rule uses configurable parameters for sender email addresses, sender domains, and subject keywords to identify phishing emails.
This rule detects suspicious activity where an Azure CLI session, initially interactive, is followed by non-interactive access from a different IP address. This could indicate an attacker using a stolen token or session from a legitimate user's interactive login to perform automated actions. The rule specifically looks for a pivot from interactive to non-interactive access where the non-interactive access occurs after the interactive access and from a different IP address, within a 30-day lookback window.
Azure Device Code OAuth Consent
Cortex XDR
This rule detects suspicious activity related to Microsoft 365 Device Code OAuth consent flows. It specifically looks for device code authentications that are single-factor or lack MFA, and then groups these by IP address and client application. The rule identifies suspicious patterns such as a high number of logins, unique users, or unique applications from a single IP address, or rapid login attempts within a short timeframe, which could indicate enumeration or phishing attempts.
Spot rogue or compromised endpoints attempting brute force attacks across your MDE fleet.
Author: Steven Lim
Author: Steven Lim
Identifies JSON Web Tokens (JWTs) where the signing algorithm in the header ('alg') is set to 'none'. A server that incorrectly trusts this header may skip signature validation, allowing an attacker to create arbitrary tokens and bypass authentication controls.
Detects anomalous Okta sign-on policy evaluations originating from Cloudflare, which could indicate an Adversary-in-the-Middle (AiTM) phishing attempt. The associated campaign uses Cloudflare to host its phishing infrastructure.
Detects when an AWS IAM role is assumed by an identity that has not used that specific role within a historical 7-day window. This behavior can indicate lateral movement, privilege escalation, compromised credentials, or a deviation from normal workload patterns. The rule excludes AWS internal service identities to focus on human and workload actors.
This detection correlates suspicious device code authentication behaviour in Azure AD with a successful creation of a Windows Hello for Business (WHfB) credential within the same 24 hours.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
Page 35 of 51