Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
597 detections
Filters
Last updated
All Time
Detection languages
285
97
95
69
31
Contributors
186
88
47
47
44
Categories
20,417
11,806
5,870
5,145
4,864
597
Platforms
300
161
158
103
25
Products / Services
221
148
147
132
88
MITRE Techniques
536
265
233
226
98
CVEs
5
5
5
5
4
IDS Classtypes
1
IDS Protocols
1
Detects anomalous device registration in Azure AD where a device code flow is used to authenticate to the Device Registration Service (DRS) and the resulting device is registered with an 'Unknown' or 'Linux' operating system. This behavior is indicative of an adversary, such as Storm-2372, using tools like AADInternals to perform phantom device registration to bypass conditional access policies by simulating a device without TPM attestation.
Detects the registration of a new device or MFA authentication method in Microsoft Entra ID from an IP address geolocated to Morocco. This is a persistence tactic used by the Jingle Thief group (also tracked as Atlas Lion and STORM-0539).
Detects successful Device Code authentication followed immediately by a new device registration, a tactic used to extend access via PRT generation.
Detects unauthorized modifications to the vmanage-admin password on Cisco SD-WAN Manager. This rule is designed to identify suspicious credential changes that deviate from standard administrative practices, potentially indicating an actor modifying the default admin credentials for persistence or unauthorized access before attempting to revert the changes to evade detection.
This rule detects the suspicious creation or modification of high-privileged accounts (Domain Admins, Enterprise Admins, Administrators) using net.exe or net1.exe. It triggers when these commands are executed via PowerShell or cmd.exe, originating from suspect parent processes (WmiPrvSE.exe, mstsc.exe, etc.), and specifically monitors for a pattern of creating the same new account across multiple distinct hosts within a short 30-minute window, excluding accounts that existed in the prior 24-hour baseline.
This rule detects the modification of the SID History attribute on Active Directory accounts (Event ID 4765) or failed attempts to do so (Event ID 4766). The SID History attribute can be abused to gain unauthorized access and escalate privileges across domain boundaries by injecting well-known or administrative SIDs, a technique known as SID-History Injection.
This rule detects the configuration of 'Trusted for Delegation' on a computer or user account, followed by a modification to the Active Directory nTDSDSA object on the same host. This combination is a classic indicator of setting up an account for Kerberos delegation attacks, often related to the creation of rogue domain controllers or setting up pivot points for lateral movement.
This rule detects suspicious activity on high blast radius accounts, specifically correlating failed authentication attempts, password resets, and successful logons outside business hours.
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
Detects instances where an interactive user initiates a password change attempt as captured by Windows Security Event ID 4723. The rule filters out non-interactive accounts (ending with '$') and common service account naming patterns to focus on human-driven account modifications.
This rule detects attempts to manipulate user or service principal names (SPN/UPN) in Active Directory by adding non-ASCII or zero-width characters. Such modifications can be used by adversaries for obfuscation, to bypass detection mechanisms, or to create stealthy persistence. The rule specifically looks for Event IDs 4738 (User Account Changed) and 5136 (Directory Service Object Modified) where the 'servicePrincipalName' or 'userPrincipalName' attributes contain characters outside the standard ASCII range or zero-width characters like U+200B, U+200C, U+200D.
This rule detects when a single user makes multiple changes to security groups within a short timeframe (binned hourly). Specifically, it looks for Event IDs 4752 (A security-enabled global group was changed), 4753 (A security-enabled local group was changed), or 4754 (A security-enabled universal group was changed). This could indicate an attempt to manipulate group memberships for privilege escalation or lateral movement.
Detects when a user account's 'UserAccountControl' attribute is modified to include the 'Not Delegated' flag (EventID 4738). This change can be an indicator of an attacker attempting to alter account behavior for persistence or to evade detection, or it could be a legitimate administrative action.
Detects successful Device Code authentication followed immediately by a new device registration, a tactic used to extend access via PRT generation. This behavior is indicative of an attacker using a stolen device code to register a new device, thereby gaining persistent access to the user's account.
Detects the use of 'net.exe' to create or modify user accounts, specifically looking for commands that include 'user', 'admin', and '/add'. This could indicate an adversary establishing persistence or escalating privileges by creating new administrative accounts.
Detects unauthorized changes to the admin or vmanage-admin user credentials on Cisco SD-WAN Manager. The rule monitors for 'usermod', 'passwd', or AAA password commit commands within the 'vmanage-admin' user context. It specifically identifies a 'change-and-revert' pattern, where the attacker changes a password to gain access and immediately reverts it to evade detection, elevating the risk to critical.
Detects device registration or join activity by an account shortly after a risky sign-in or policy-lure interaction, indicating potential compromise of the account.
This rule detects successful additions or updates to service principal credentials or application certificates/secrets within Azure AD. This activity can indicate persistence establishment by an attacker who has compromised an account with sufficient permissions to manipulate application identities.
Detects modifications to Active Directory user accounts by monitoring Security Event ID 4738. The rule filters out service accounts (those ending with '$') and ensures the target username is populated.
Detects modifications to Active Directory user accounts by monitoring Security Event ID 4738. The rule filters out service accounts (those ending with '$') and ensures the target username is populated.
Detects changes to the attributes of the AdminSDHolder object in Active Directory. The AdminSDHolder object is a template used by the Active Directory security descriptor propagator (SDProp) to enforce permissions on protected administrative groups. Modification of this object is a highly suspicious activity that can be used to establish persistence or grant excessive privileges by poisoning the security descriptors of all protected objects within the domain.
Correlates a successful AAD sign-in from a new IP address immediately followed by the registration of a new FIDO2 or Authenticator device, a hallmark of AiTM persistence.
Page 18 of 29