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,402
11,796
5,865
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
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.
This rule detects suspicious changes to account delegation settings by monitoring Security Event ID 5136 for modifications to the 'msDS-AllowedToDelegateTo' attribute. It specifically looks for instances where an account's delegation settings are changed two or more times within an hour, which could indicate an adversary attempting to establish persistence or elevate privileges through constrained delegation.
This rule detects a high volume of account changes (creation or modification) within a one-hour window by a single user. Specifically, it looks for 10 or more instances of EventID 4720 (A user account was created) or EventID 4722 (A user account was enabled) originating from the same SubjectUserName within an hour.
This rule detects the creation or modification of user accounts on Windows systems by monitoring Security Event IDs 4741 (A security-enabled local group was created) and 4742 (A computer account was changed). It summarizes the count of such changes per hour by the subject user name, which can help identify unusual or excessive account management activities.
This rule detects suspicious activity involving Azure AD device registration followed by a sign-in from the same user and IP address, particularly when the user agent strings are indicative of non-standard clients (e.g., 'node', 'axios', 'undici', 'node-fetch'). This pattern can indicate an adversary attempting to establish persistence or bypass multi-factor authentication by registering a new device and then immediately using it for access.
This rule detects attempts to modify user accounts via LDAP. It specifically looks for TCP traffic on port 389 (LDAP) containing the hexadecimal representation of '0' (likely part of an LDAP message structure) and the case-insensitive string 'modify'. A threshold of 5 such events within 60 seconds from the same source IP triggers the alert, indicating potential malicious activity related to account manipulation.
This rule detects when an 'Agent ID Administrator' role adds an owner to a service principal in Azure Active Directory. This activity could indicate an attempt to escalate privileges or maintain persistence within the Azure environment by granting control over service principals to potentially unauthorized entities.
This rule detects a highly suspicious sequence of events in Microsoft Entra ID (formerly Azure AD) audit logs: a self-service password reset, followed by the registration of new security information, and then the deletion of existing security information, all performed by the same user within a short time window. This pattern is indicative of an attacker taking over an account, resetting the password, establishing their own MFA/security info, and then removing the legitimate user's security info to lock them out. This behavior has been observed in campaigns like Storm-2949.
Smartcard Disabled and Not Re-enabled
Cortex XDR
Similar to my previous rule, this detects when a user accounts smartcard is disabled (change code 2060) but not subsequently re-enabled (change code 2092) within the observed timeframe. This could indicate malicious activity such as an attacker disabling accounts to bypass multi-factor authentication or other security controls.
This version of the rule is designed to run as a scheduled correlation based on your time acceptance of a users smartcard being disabled. This will suppress the quick helpdesk troubleshooting of accounts since it only fires if the smartcard remains disabled, however the detection will be slower since it does not fire on the real time event.
This version of the rule is designed to run as a scheduled correlation based on your time acceptance of a users smartcard being disabled. This will suppress the quick helpdesk troubleshooting of accounts since it only fires if the smartcard remains disabled, however the detection will be slower since it does not fire on the real time event.
Detects Okta Multi-Factor Authentication (MFA) factor enrollment, activation, update, and reset events. These events may indicate an attacker adding their own MFA factor post-compromise to maintain access or removing an existing factor to weaken account security and facilitate unauthorized access.
Detects modifications to the msDS-GroupMSAMembership attribute on Delegated Managed Service Account (dMSA) objects. Attackers may write the dMSA's own SID into this attribute to self-authorize credential extraction, establishing a self-sustaining Ouroboros loop.
Smartcard Disabled and Not Re-enabled
Cortex XDR
Similar to my previous rule, this detects when a user accounts smartcard is disabled (change code 2060) but not subsequently re-enabled (change code 2092) within the observed timeframe. This could indicate malicious activity such as an attacker disabling accounts to bypass multi-factor authentication or other security controls.
This version of the rule is designed to run as a scheduled correlation based on your time acceptance of a users smartcard being disabled. This will suppress the quick helpdesk troubleshooting of accounts since it only fires if the smartcard remains disabled, however the detection will be slower since it does not fire on the real time event.
This version of the rule is designed to run as a scheduled correlation based on your time acceptance of a users smartcard being disabled. This will suppress the quick helpdesk troubleshooting of accounts since it only fires if the smartcard remains disabled, however the detection will be slower since it does not fire on the real time event.
Detects the specific usage of the 'net.exe' or 'net1.exe' command to lock out user accounts by setting them to inactive and restricting login times. This behavior was observed in the Lotus Wiper destructive campaign to prevent remediation before wiping the system.
This rule detects when an 'Agent ID Administrator' role adds an owner to a service principal in Azure Active Directory. This activity could indicate an attempt to escalate privileges or maintain persistence within the Azure environment by granting control over service principals to potentially unauthorized entities.
Detects suspicious modifications to Power Automate flow permissions, including sharing flows or changing role assignments. This could indicate a compromised account attempting to gain unauthorized access or persistence within the Power Platform environment.
Detects scenario where weak encryption is enabled for a user profile which could be used for hash/password cracking.
Detects when an Google Workspace user is granted admin privileges.
Detects when a temporary access pass (TAP) is added to an account. TAPs added to priv accounts should be investigated
Detects rapid password change (Event ID 4724) or attempt (Event ID 4723) events on local administrator accounts within a short timeframe. This behavior is indicative of the BlueHammer zero-day local privilege escalation (LPE), where an attacker temporarily overwrites a local admin's password to spawn a SYSTEM shell and immediately restores the original hash to evade detection.
Detects when an the Administrator role is assigned to an user or group.
Change to authentication method could be an indicator of an attacker adding an auth method to the account so they can have continued access.
Page 20 of 29