Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
839 detections
Filters
Last updated
All Time
Detection languages
438
190
77
62
40
Contributors
120
114
72
71
68
Categories
464
233
193
152
122
Platforms
288
274
154
88
56
Products / Services
220
169
162
90
76
MITRE Techniques
18,127
15,648
12,596
8,407
6,231
839
CVEs
6
5
5
5
5
IDS Classtypes
4
2
IDS Protocols
1
This rule detects when a user account assigns a 'Global Administrator' or 'Owner' role from multiple distinct IP addresses within a one-hour window. This behavior can indicate a compromised account being used to escalate privileges or establish persistence from different locations.
This rule detects the creation of new service principals or the assignment of new role assignments to existing service principals in Azure Active Directory. It specifically looks for assignments that grant high-privilege roles such as "Contributor", "Owner", or "Global Admin". The rule aggregates these changes by target and time, highlighting instances where multiple changes or distinct initiators are involved.
This rule detects anomalous mass device wipe or deletion activity in Microsoft Intune by comparing current activity against an actor's historical behavior. It identifies four patterns: first-time wipers with high volume, known actors statistically far above their norm (Z-score), thin-history actors exceeding their personal peak, and time-compressed bursts of wipes. The rule calculates a severity based on the volume and rate of wipes.
This rule detects suspicious device enrollment attempts via Microsoft Intune Company Portal from a country not previously observed in a user's 7-day sign-in history. It identifies two primary patterns: sustained successful sign-ins from a new country, indicating a potential active session and successful device enrollment (High Severity), or Conditional Access Policy (CAP) blocked attempts from a new country, suggesting an attacker probing with stolen credentials (Medium Severity). The detection aims to identify identity theft leading to unauthorized device enrollment.
Detects suspicious Kubernetes Role-Based Access Control (RBAC) changes that grant elevated privileges, such as 'cluster-admin' roles, wildcard permissions for verbs, resources, or API groups, or direct access to secrets or service accounts. This rule monitors 'create', 'update', and 'patch' operations on roles, clusterroles, rolebindings, and clusterrolebindings within Kubernetes audit logs.
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.
This rule detects the assignment of highly privileged roles such as 'Global Administrator', 'Intune Administrator', or 'Cloud Device Administrator' within Azure Active Directory. This activity is often a precursor to significant malicious actions, including mass device wipes, as highlighted by the referenced threat intelligence. Monitoring these assignments helps identify potential privilege escalation or unauthorized administrative access.
This rule detects the use of Azure Managed Identity tokens originating from non-Azure IP spaces. This scenario is indicative of token theft, likely via the Instance Metadata Service (IMDS) endpoint (169.254.169.254), followed by an external replay of the stolen token from an attacker's infrastructure. Legitimate Managed Identity calls are expected to originate from Azure infrastructure IPs. The rule filters out legitimate Microsoft/Azure ASNs and RFC1918 private IP ranges to reduce false positives. It also categorizes the potential attack stage based on the operation name, including Key Vault access, Storage access, VM Code Execution, Privilege Escalation, and Directory Enumeration.
Suspicious Azure VM Extension Deployment
Cortex XDR
This rule detects the deployment of suspicious or potentially malicious extensions on Azure Virtual Machines. These extensions, such as CustomScriptExtension, RunCommandHandler, DSCExtension, AADLoginForWindows, and NetworkWatcherAgent, can be abused by adversaries for various purposes including remote code execution, account manipulation, and network reconnaissance. Monitoring their deployment can help identify unauthorized activity within an Azure environment.
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.
Okta Sensitive OAuth Activity Detection
Cortex XDR
This rule detects sensitive OAuth activities within Okta, specifically focusing on OAuth client secret access, token revocation requests, and implicit flow requests. These activities can indicate potential compromise of OAuth clients, attempts to invalidate legitimate tokens, or the use of less secure OAuth flows that could be exploited.
Detects when users are added to groups or applications within Okta, which could potentially grant them elevated privileges. This rule monitors for events indicating changes in user membership for both groups and applications.
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-KeyCredentialLink attribute on Delegated Managed Service Account (dMSA) objects, indicating a potential Shadow Credential (X.509 certificate) planting. This allows an attacker to bypass managed password rotation and maintain permanent PKINIT access, as seen in the dMSA Ouroboros attack chain. The rule also monitors Event 4768 (PKINIT TGT requests with pre-authentication type 17) and Event 4662 (S4U2Self Object Access) for dMSA objects, which are key indicators of this attack.
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 changes to Microsoft.ManagedServices resources (registration definitions and assignments) where the affected resource group matches your known Sentinel resource group. In other words: someone touched your delegation.
This covers both expected changes (your own team onboarding or offboarding a customer) and unexpected ones (a customer admin making unauthorised modifications). The rule fires on both write and delete operations with a successful status.
This covers both expected changes (your own team onboarding or offboarding a customer) and unexpected ones (a customer admin making unauthorised modifications). The rule fires on both write and delete operations with a successful status.
Detects when an administrator grants consent to an application on behalf of all users in an Azure AD tenant. This can be a legitimate administrative action but can also be abused by attackers to gain broad access to resources and data within the organization.
This detection highlights potential privilege escalation through misuse of the Agent ID Administrator role. In the past, this role has been exploited to bypass restrictions by granting the actor ownership of sensitive Service Principals, enabling them to add unauthorized credentials.
This rule detects the creation, patching, or updating of Kubernetes ClusterRoleBindings, RoleBindings, or Roles within the 'prod', 'production', or 'default' namespaces. It specifically excludes actions performed by the 'system:clusterrole-aggregation-controller' to reduce noise from legitimate system operations. This activity can indicate an attempt to manipulate access controls within the Kubernetes cluster, potentially for privilege escalation or persistence.
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.
Page 23 of 40