Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
254 detections
Filters
Last updated
All Time
Detection languages
167
41
16
14
10
Contributors
61
60
42
18
13
Categories
20,443
11,831
5,872
5,155
4,866
Platforms
133
108
85
38
34
Products / Services
112
83
65
30
30
MITRE Techniques
75
74
36
36
35
CVEs
7
6
6
6
6
This rule detects potential exploitation activity related to CVE-2026-45657 involving the Windows Kernel tcpip.sys driver. It monitors for a combination of system crashes (Kernel-Power 41 or EventLog 6008) correlated with Windows Error Reporting (WER) events referencing 'tcpip.sys', or significant spikes in external authentication attempts occurring shortly before a system crash. The rule aims to identify potential remote code execution attempts manifesting as kernel instability.
This rule detects potential automated credential stuffing attempts followed by successful authentication and subsequent access to sensitive/privileged APIs within Azure/Entra ID environments. It correlates multiple failed login attempts for service-oriented account names (e.g., svc, api, bot) with a successful login from the same user shortly thereafter, followed by privileged API operations (e.g., KeyVault secret access, user management) within a short time window.
Detects high-frequency failed logon attempts (Event ID 4625) from a single IP address within a short time window, indicating potential brute force or password spraying activity targeting Windows systems.
This rule detects unauthorized or suspicious modifications to Microsoft Sentinel alert rules. It specifically monitors for the deletion of alert rules or the disabling of existing rules via the Azure activity logs. Such actions may indicate an attempt by an adversary to impair security monitoring and defensive capabilities.
This rule monitors for security alerts related to Azure AI services, specifically detecting credential theft attempts and LLM jailbreak attempts that have been blocked or detected by Azure's built-in content filtering mechanisms.
This rule monitors Cisco SD-WAN environment logs for indicators of unauthorized or suspicious control plane activity, including rogue peering attempts, unexpected NETCONF interactions, certificate mismatches, and unauthorized vBond/vSmart connections. It filters out known local management subnets and utilizes a threat intelligence lookup to identify potentially malicious infrastructure attempting to interface with the SD-WAN fabric.
Detects potential unauthorized or rogue peer connections within a Cisco SD-WAN infrastructure. The rule monitors certificate-based authentication events for indicators of rogue peers (e.g., certificate mismatches, invalid common names) or connections originating from known malicious IP addresses associated with rogue SD-WAN activity.
Detects automated Microsoft Graph API requests indicative of the 'Payroll Pirate' campaign, specifically targeting payroll and HR personnel after initial access via AiTM session token theft. The rule identifies two malicious patterns: bulk user directory harvesting using '?$top=999' and keyword-targeted enumeration (payroll, human, compensation) using OR-chained search queries and pagination markers ($skiptoken).
Detects anomalous Primary Refresh Token (PRT) issuance for non-compliant, non-hybrid joined devices that do not utilize TPM attestation, followed by immediate access to high-value Microsoft resources like Microsoft Graph, Exchange, or SharePoint. This activity is indicative of the Storm-2372 Conditional Access bypass technique, where attackers register 'phantom' devices to circumvent security policies.
Detects anomalous authentication failure patterns against Azure AD Service Principals from a single IP address. The rule identifies potential brute force attacks (high volume of failures) or service principal enumeration (multiple distinct service principals targeted).
This rule detects potential automated credential stuffing attempts followed by successful authentication and subsequent access to sensitive/privileged APIs within Azure/Entra ID environments. It correlates multiple failed login attempts for service-oriented account names (e.g., svc, api, bot) with a successful login from the same user shortly thereafter, followed by privileged API operations (e.g., KeyVault secret access, user management) within a short time window.
This rule processes Microsoft Graph Security Alerts, aggregating evidence from various Microsoft Defender products (MDE, MDI, MDCA, MDO, Entra ID Protection). It extracts and normalizes detailed evidence related to devices, users, IP addresses, processes, files, URLs, emails, mailboxes, network connections, and Azure resources, providing a comprehensive view of security incidents across the Microsoft ecosystem.
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.
Detects when a Microsoft Cloud App Security reported a risky sign-in attempt due to a login associated with an impossible travel.
Detects anomalies in data connector log volumes by comparing current log counts to 30-day averages, identifying significant deviations.
This query monitors the health and performance of data connectors feeding into Microsoft Sentinel by analyzing log volumes from various sources over the past 30 days. It calculates hourly averages to establish a baseline and compares these to logs from the last hour to identify significant deviations.
Specifically, the query detects "No Logs" (indicating a complete halt in log transmission), "Critical Spike" and "Elevated Spike" (indicating significantly higher log volumes, suggesting potential security incidents or increased activity), and "Critical Drop" and "Elevated Drop" (indicating significantly lower log volumes, which could point to misconfigurations or data source issues). The query provides detailed alerts for these anomalies, helping administrators proactively address potential issues with data connectors.
This query monitors the health and performance of data connectors feeding into Microsoft Sentinel by analyzing log volumes from various sources over the past 30 days. It calculates hourly averages to establish a baseline and compares these to logs from the last hour to identify significant deviations.
Specifically, the query detects "No Logs" (indicating a complete halt in log transmission), "Critical Spike" and "Elevated Spike" (indicating significantly higher log volumes, suggesting potential security incidents or increased activity), and "Critical Drop" and "Elevated Drop" (indicating significantly lower log volumes, which could point to misconfigurations or data source issues). The query provides detailed alerts for these anomalies, helping administrators proactively address potential issues with data connectors.
Behavior is tied to enumeration of network services, relating to the discovery tactic.
Where "network_connection_discovery`"is a lookup table of “ifconfig.me” and related services
Where "network_connection_discovery`"is a lookup table of “ifconfig.me” and related services
Detects medium severity correlation events generated by Palo Alto Networks firewall's automated correlation engine. The correlation engine connects isolated network events and looks for patterns that indicate a more significant event. This helps identify suspicious traffic patterns and network anomalies which, when correlated, indicate with a high probability that a host on the network has been compromised.
Detects network connections using DNS over TLS (DoT) on port 853 or DNS over HTTPS (DoH) to known public resolvers from non-browser processes. This activity can indicate an attempt to bypass network security controls and monitoring by hiding DNS queries within encrypted traffic.
KQL Query from file: Threat Intelligence Data from Sentinel UEBA
KQL Query from file: Sentinel Alerts & MITRE ATT&CK Analysis
'This detection identifies high-severity alerts across various Microsoft security products, including Microsoft Defender XDR and Microsoft Entra ID, and correlates them with instances of Google Cloud VM creation. It focuses on instances where VMs were created within a short timeframe of high-severity alerts, potentially indicating suspicious activity.'
Page 11 of 13