Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,865 detections
Filters
Last updated
All Time
Detection languages
2,524
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
792
575
Platforms
39,934
7,265
6,535
3,865
3,645
Products / Services
1,755
1,449
1,121
438
406
MITRE Techniques
1,889
1,392
913
814
727
CVEs
12
5
4
3
2
IDS Classtypes
10
7
6
6
5
IDS Protocols
37
2
1
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.
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.
This can be used as an alert that can be sent when a severe vulnerability affects your onboarded devices.
Detects potential impossible travel activity by comparing location data
Kali365 PHaaS Device Code Detection
Cortex XDR
This rule detects potential device code phishing attempts by correlating a device code flow initiated from an unmanaged/non-compliant device with a suspicious user agent (e.g., 'python-requests' or '-live') and an 'unbound' signInTokenProtectionStatus, with a subsequent 'Cmsi:Cmsi' token replay event for the same user. This combination suggests a successful device code phishing attack where an adversary has obtained and is replaying a token after the victim has authenticated.
This rule detects authentication attempts to Microsoft 365 Azure AD from a list of known malicious IP addresses and CIDR ranges associated with the EvilToken phishing campaign. It specifically filters for 'Cmsi:Cmsi' request types, which are indicative of session replay signals used in device code phishing.
Detects possible MFA-approved session replay by identifying abnormal reuse of authenticated sessions across multiple IPs, browsers, and devices compared against a 14-day historical baseline. The rule prioritizes browser/device anomalies over geography since modern attackers often use same-country VPS/proxies.
Detects anomalous Microsoft Entra ID sign-in events where the application accessed is the Microsoft Authentication Broker (AppId 29d9ed98-a469-4536-ade2-f981bc1d605e) and the User-Agent indicates a Node.js automated backend ('node' or 'undici'). This combination strongly suggests Tycoon2FA operator polling for device-code token acquisition.
Azure VM RunCommand Activity
Cortex XDR
This rule detects activity related to Azure VM RunCommand, which allows execution of scripts on virtual machines without requiring RDP/SSH access. It specifically looks for 'WRITE', 'ACTION', 'DELETE', and 'READ' operations, filtering for successful or accepted statuses and valid identities. This activity can indicate an attacker executing commands or performing post-execution cleanup.
Tycoon2FA Known Infrastructure Detection
Cortex XDR
This rule detects suspicious sign-in attempts to Microsoft 365 accounts that originate from known Tycoon2FA infrastructure. It specifically looks for device code flow authentications from IP addresses and Autonomous System Numbers (ASNs) associated with Tycoon2FA, combined with indicators like unmanaged/non-compliant devices, specific user agent patterns (axios, node, undici), and particular application IDs, and an unbound sign-in token protection status. This combination of indicators suggests an attempt to hijack Microsoft 365 accounts using device code phishing.
Detects abnormal MFA session behavior by monitoring user sessions with multiple IPs or browsers over 24h. Note: KQL 14-day historical baseline and set_difference logic is approximated.
Tycoon2FA PHaaS User Agent Detection
Cortex XDR
Detects user agents associated with Tycoon2FA phishing-as-a-service (PHaaS) campaigns, specifically targeting Microsoft 365 accounts via device code phishing. The rule identifies user agents like 'axios/1.13.x' (credential relay variant) and 'node' or 'undici' (device code variant) in Azure AD sign-in logs where the original transfer method is 'deviceCodeFlow', and the device is neither managed nor compliant, and the sign-in token protection status is unbound.
Detects possible Adversary-in-the-Middle (AiTM) attacks, session cookie replay, MFA session hijacking, token theft, and stolen cloud session reuse by identifying abnormal SessionId reuse across multiple IPs, browsers, and devices. This detection compares current session activity against a 14-day historical user behavior baseline to identify new or abnormal behavior. It includes risk scoring and account classification, while reducing false positives from token refresh activity and common Microsoft Teams noise.
Detects network connections from Node.js or Bun runtime processes to common cloud instance metadata service IPs (AWS, Azure, GCP) or to the default HashiCorp Vault port (8200). This activity can indicate credential access attempts, especially in the context of a supply chain attack where malicious code might be injected into a Node.js/Bun application to exfiltrate sensitive information or gain further access. The rule correlates network connection events with process execution events to identify the specific runtime responsible.
Entra ID TAP Sign In
Cortex XDR
Looks for a Temporary Access Pass in Entra ID
Creating multiple detections without reviewing them over time to ensure they’re still effective can easily turn them into pure noise, adding nothing but fatigue to our day-to-day incident analysis.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
MC1293480: https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1293480
Identifies potential use of ROADtools for Azure AD reconnaissance by monitoring for Azure CLI/PowerShell App IDs coupled with a Python user agent in sign-in logs. This rule specifically looks for sign-ins to 'Windows Azure Active Directory' resource where the user agent string contains 'python' or the device detail string contains 'Python', and the App ID or App Display Name matches known Azure AD PowerShell or Azure CLI applications.
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 rule identifies "impossible travel" scenarios where a user logs in from two geographically distant locations within a short period (less than 2 hours). This can indicate a compromised account being used by an attacker, potentially leveraging VPNs or other proxy services to obscure their true location.
Page 133 of 185