Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,831 detections
Filters
Last updated
All Time
Detection languages
1,374
495
363
281
175
Contributors
848
453
393
252
188
Categories
20,440
11,814
5,871
5,145
4,864
2,831
Platforms
1,448
916
693
670
264
Products / Services
994
700
613
469
216
MITRE Techniques
1,239
911
484
481
388
CVEs
6
5
2
1
1
IDS Classtypes
15
10
6
5
3
IDS Protocols
39
Detects a single Azure identity accessing three or more distinct Azure resource types within a short time window. This behavior can indicate an attacker attempting to enumerate or pivot through an environment after compromising an identity.
This rule detects instances where Microsoft Copilot accesses external resources, specifically identifying events where 'XPIADetected' is true. This indicates Copilot interacting with resources outside its immediate environment, which could be a security concern if the accessed resources are sensitive or untrusted.
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 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.
Detects programmatic GitHub data exfiltration by identifying non-interactive repository exports, clones, artifact downloads, or gist staging performed using tokens, OAuth applications, or GitHub Apps. The detection focuses on bursty or multi-repository activity within a short time window, which can indicate automated source code collection, misuse of programmatic credentials, or post-compromise data extraction.
Rule to detect where there are role bindings and high-risk actions (verbs) applied within production or default namespaces. This rule specifically looks for these high-risk actions (verbs), excluding actions by the 'system:clusterrole-aggregation-controller' user, which is a legitimate system process.
Detects when a new AWS IAM Principal (User, Role, or Group) is created and then has a policy attached to it by the same actor within a 10-minute time frame. This sequence is a suspicious TTP often used by attackers to provision a new, privileged "shadow" account or role for persistence and lateral movement, bypassing existing accounts or role assumption paths.
Detects a sequence of events where an AWS IAM Policy is modified or created and then immediately attached to a principal (user, role, or group) within a short time window (10 minutes). This behavior is highly suspicious and often indicates a rapid privilege escalation attempt or a lateral movement step where an attacker grants themselves new permissions for immediate use.
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 sign-ins by Azure Managed Identities where the token was likely obtained via the Instance Metadata Service (IMDS). It identifies these sign-ins by looking for 'ImdsIdentityProvider' in the UserAgent or 'Imds' in the ClientCredentialType within AADManagedIdentitySignInLogs. This activity could indicate lateral movement through abuse of managed identities attached to virtual machines.
Detects the creation or modification of repository webhooks in GitHub. Attackers can use webhooks for real-time data exfiltration of code pushes, pull request comments, and workflow data. Once a webhook is established, it operates independently of the creating user; revoking the creator's credentials will NOT stop the data flow. Only deleting the webhook itself terminates the exfiltration.
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.
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 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 TruffleHog credential validation via sts:GetCallerIdentity - initial access indicator for AWS WorkMail phishing campaigns
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.
Page 106 of 135