Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
170 detections
Filters
Last updated
All Time
Detection languages
64
46
20
18
12
Contributors
36
23
19
13
12
Categories
59
42
39
38
36
Platforms
74
43
24
22
18
Products / Services
42
36
33
13
10
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
CVEs
7
2
2
2
1
IDS Classtypes
4
4
3
3
1
IDS Protocols
7
5
Detects changes to "DsrmAdminLogonBehavior" registry value.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
Detects potential NetScaler administrative session hijacking by monitoring for the usage of SESSID or NITRO_SK administrative cookies from multiple source IPs. Attackers leverage CVE-2026-3055 to steal these specific session cookies to gain unauthorized administrative access.
Detects the creation of specific log files (`ldapd*.1.gz`, `ldapd*.2.gz`) in the `/var/log/` directory. This behavior is indicative of the UNC3886 threat actor utilizing backdoored SSH clients and daemons to harvest and store XOR-encrypted credentials.
This rule detects when multi-factor authentication (MFA) or strong authentication settings are disabled or removed for a user account. It specifically looks for successful audit log entries related to operations such as 'Disable Strong Authentication', 'Update user', 'Update StsRefreshTokensValidFrom', 'Admin registered security info', or 'Admin deleted security info'. This activity could indicate an adversary attempting to maintain persistent access to a compromised account by weakening its authentication requirements.
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.
Detects attempts to exploit an authentication bypass vulnerability in the Inetutils Telnet daemon. Attackers inject the '-f' flag into the 'USER' environment variable during Telnet negotiation to gain unauthorized shell access.
Detects attempts to modify Pluggable Authentication Modules (PAM) configuration files. Attackers may modify PAM configurations to bypass authentication, such as by adding `pam_permit.so` or changing module control flags from `required` to `sufficient` or `optional`.
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
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.
This detection identifies cases where a successful device registration event in Azure AD occurs shortly after a successful Resource Owner Password Credentials (ROPC) authentication to Microsoft Intune Enrollment via the Microsoft Authentication Broker.
Microsoft allows specific application and resource combinations access without a previously registered 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.
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.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
Microsoft allows specific application and resource combinations access without a previously registered 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.
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.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
This rule detects the creation or modification of files within specific macOS directories associated with LoginWindow hooks and Authorization Plugins. These locations are commonly abused by adversaries to establish persistence or elevate privileges by injecting malicious code that executes during the login process. The rule specifically looks for file events in '/Library/Security/SecurityAgentPlugins/', '/System/Library/CoreServices/SecurityAgentPlugins/', '/Library/Security/SecurityAgentPlugins.bundle', or any file activity within a 'loginwindow' path. It excludes activities initiated by legitimate installers and software updaters to reduce false positives. Additionally, it filters for files with low global prevalence, indicating potentially suspicious or custom binaries.
This rule detects when a user disables critical security features within a GitHub organization or repository. This includes disabling advanced security features, OAuth app access restrictions, or two-factor authentication requirements. Such actions can significantly weaken the security posture of a GitHub environment, potentially leading to unauthorized access or compromise.
This rule detects when multi-factor authentication (MFA) has been explicitly disabled for a user in Azure Active Directory. This activity could indicate an adversary attempting to bypass authentication mechanisms to gain unauthorized access or maintain persistence.
Detects the possible addition of shadow credentials to an Active Directory object by monitoring for Event ID 5136 (Directory Service Changes) where the 'msDS-KeyCredentialLink' attribute is modified. This attribute is used in shadow credential attacks to establish persistence and gain unauthorized access.
This rule detects when a Conditional Access (CA) policy is deleted in Azure Active Directory (now Microsoft Entra ID). This activity is critical to monitor as the removal of a CA policy can significantly weaken an organization's security posture by bypassing multi-factor authentication, device compliance checks, or other access controls. The rule specifically looks for the 'Delete conditional access policy' message in the Azure Audit Logs. While the rule's title suggests identifying actions by 'non-approved actors', the current detection logic only identifies the deletion event itself, not the actor's approval status. Further enrichment or correlation would be needed to determine if the actor is unauthorized.
This rule detects when a user is removed from a group that has Conditional Access (CA) policy modification access within Azure Active Directory. Such groups are critical for managing access to resources, and unauthorized removal of members could indicate an attempt to evade detection, disrupt security controls, or prepare for further malicious activity. Monitoring these removals helps identify potential privilege escalation, defense evasion, or persistence attempts.
This rule detects when a Conditional Access policy is updated within an Azure environment. It aims to identify unauthorized or suspicious modifications to these critical security policies, which could lead to privilege escalation, credential access, or defense evasion. The rule specifically looks for the message 'Update conditional access policy' in audit logs. Further investigation would involve checking if the actor initiating the change is approved and comparing the old versus new policy values.
Detects the addition of a new root certificate authority to an Azure AD tenant. This action can be performed by an attacker to establish persistence and enable certificate-based authentication for unauthorized access, potentially bypassing traditional password-based authentication mechanisms. This is a critical security event as it can lead to privilege escalation and persistent access within the Azure AD environment.
This rule detects when a user is added to a group that has permissions to modify Conditional Access (CA) policies within Azure Active Directory. Such an action could indicate an attempt to escalate privileges, bypass existing security controls, or establish persistence by altering authentication processes.
Detects when certificate-based authentication has been enabled in an Azure Active Directory tenant. This change can be an indicator of an adversary establishing a new authentication method for persistence or privilege escalation, or preparing for such activities.
Detects changes to the AWS Identity Center (formerly AWS SSO) identity provider configuration. Such changes, including associating, disassociating, enabling, or disabling an external identity provider, could be used by an attacker to establish persistent access or escalate privileges through user impersonation.
Page 6 of 9