Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,153 detections
Filters
Last updated
All Time
Detection languages
694
181
114
75
54
Contributors
328
252
122
76
71
Categories
726
700
220
196
148
Platforms
1,120
187
161
59
51
Products / Services
10,660
9,755
6,689
4,418
3,748
1,153
MITRE Techniques
699
428
360
209
197
CVEs
2
2
1
1
1
IDS Classtypes
4
3
1
1
IDS Protocols
8
This rule detects Azure DevOps activities originating from new or rarely seen IP addresses outside of defined business hours. It establishes a baseline of historical IP addresses and flags activities from IPs that have been seen for fewer than a specified number of days, indicating potentially suspicious access.
This rule detects when public or anonymous access is enabled for an Azure Storage Account. This configuration change can lead to potential data exposure, as it allows unauthenticated users to access blobs within the storage account. The rule specifically looks for 'STORAGEACCOUNTS/WRITE' or 'STORAGEACCOUNTS/BLOBSERVICES/WRITE' operations that successfully modify the storage account configuration to allow public access.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
This rule detects a high volume of Azure resource deletions by a single user within a short timeframe (30 minutes). This behavior is indicative of a destructive attack or wiper activity, where an adversary attempts to delete critical cloud infrastructure to disrupt operations or cause data loss. The rule specifically looks for 'delete' operations that were successful and counts them per caller and IP address, triggering an alert if the count exceeds a defined threshold.
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.
This rule detects high-volume access to Azure Key Vault secrets, keys, or certificates within a one-hour window. It specifically looks for successful read operations on secrets, keys, and certificates, as well as modifications to access policies. A high volume (more than 10 accesses) from a single caller within an hour is flagged as potential credential harvesting.
This rule detects when a high-privilege role is assigned to a user in Azure Active Directory. It specifically looks for 'Add member to role', 'Add eligible member to role', or 'Add scoped member to role' operations that successfully assign one of a predefined list of privileged roles (e.g., Global Administrator, Security Administrator, Application Administrator) to a user. This activity can indicate privilege escalation or unauthorized access within an Azure AD environment.
This rule identifies the creation or deletion of user accounts in Azure AD (Entra ID) by principals not on an approved list. It relies on a customized list of approved administrators/service principals to reduce false positives.
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 potential lateral movement within Azure by identifying instances where a Managed Identity of one Virtual Machine (VM) is used to execute commands on another VM. It specifically looks for Azure Activity logs where the caller is a Service Principal, the 'InitiatedBy' field (xms_mirid) contains 'resourcegroups', and the operation name indicates a 'runCommand' or a 'Microsoft.Compute' action. This combination suggests that a Managed Identity is being leveraged to perform actions across VMs, which could be indicative of an attacker moving laterally after compromising a VM with an attached Managed Identity.
This rule detects modifications to properties of 'break glass' accounts. It joins a watchlist of identity categories containing 'Break Glass' accounts with Azure Audit Logs to identify specific operations performed on these accounts. The rule focuses on changes to user principal names, operation names, activity display names, results, and AAD operation types.
This rule detects when a guest user from a common public email domain (e.g., gmail.com, outlook.com) is invited to an Azure Active Directory (AAD) tenant and subsequently added to an AAD security group. This could indicate an attempt to grant unauthorized access to an external account or a misconfiguration allowing guest users to be added to sensitive groups.
This rule detects when an external user is invited to Azure Active Directory (AAD) from a common, publicly available email domain (e.g., gmail.com, outlook.com, yahoo.com). This can be an indicator of an attacker attempting to establish persistence or gain initial access by inviting an external account they control, or it could be a legitimate business process for collaboration with external parties using personal email addresses.
This rule detects suspicious user-agent strings in Microsoft Graph activity logs that are commonly associated with reconnaissance and attack tools targeting Azure AD and Microsoft 365 environments. These tools include BloodHound, ROADtools, AADInternals, and various other utilities used for enumeration, credential spraying, and other malicious activities.
Detects when a Managed Identity successfully authenticates via the Azure Instance Metadata Service (IMDS) and subsequently performs administrative or enumeration actions within a short timeframe. This pattern can indicate an attacker has compromised a resource (e.g., a Virtual Machine) and is using its Managed Identity to move laterally or access other resources within the Azure environment. The rule correlates successful IMDS-based sign-ins with subsequent activities such as running commands on virtual machines, or listing/getting secrets and keys from Key Vaults, or other general administrative/alert-generating activities.
Detects when a VM Run Command is executed successfully, followed by the VM's Managed Identity authenticating to Azure Resource Manager. This pattern may indicate an attacker using Run Command to steal MI tokens for lateral movement.
This detection identifies when a Managed Identity (Service Principal) successfully executes a 'RunCommand' on an Azure virtual machine. This activity is a key indicator of lateral movement, where an attacker, having compromised a resource with a Managed Identity, uses that identity's permissions to execute code on another VM.
Detects potential lateral movement attempts within Azure by a Service Principal (Managed Identity) executing 'runCommand' or other compute operations on virtual machines. This activity could indicate an attacker abusing a compromised Managed Identity to gain access to and control other resources.
This rule detects suspicious resource access patterns in Azure. Specifically, it flags instances where an 'Account' type actor (identified by a username) accesses resources that are not explicitly allowed for security monitoring (SecMon) or security orchestration, automation, and response (SecSoar) purposes. The rule also filters out activities from 'Microsoft-WindowsAzure-Frontdoor' and specific 'Microsoft.Resources' actions to reduce false positives. The primary goal is to identify unauthorized or unusual access to Azure resources by user accounts that fall outside defined security operational scopes.
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.
Detects when a user flagged as 'high risk' by Azure AD Identity Protection lists storage account keys. This could indicate a compromised account is being used to access sensitive data or escalate privileges.
Page 39 of 55