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,932
7,263
6,535
3,865
3,643
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 alert generates a log when a device onboarded is seen connecting to a known malicious domain within the ThreatIntelIndicators table. The TimeGenerated field should not be changed as the table refreshes every ~10 days.
This rule detects successful user sign-ins to Azure AD from IP addresses located outside of New Zealand and Australia, where the User-Agent string matches a known list of suspicious user agents. It filters out common legitimate user agents to reduce false positives.
This rule detects large volumes of outbound network traffic originating from Azure Kubernetes Service (AKS) clusters to external destinations over non-standard ports. It specifically looks for traffic allowed by Palo Alto firewalls, excluding common ports like 80 and 443, and flags transfers exceeding a defined data threshold (e.g., 100MB). This behavior can indicate data exfiltration attempts where adversaries use alternative protocols to bypass standard monitoring.
This rule detects anomalous logon activity for accounts containing 'your admin service account name' by comparing actual logon volumes against a dynamically generated machine learning baseline. It focuses on identifying deviations from expected behavior for these administrative service accounts over a 14-day lookback period, with a sensitivity threshold of 2.5.
This query is better used in a workbook for automation.
This query looks for any emails containing N8N webhooks linked to malicious Screen Connect installers
Detects when a new Multi-Factor Authentication (MFA) method is registered shortly after a successful sign-in from an unfamiliar or risky location. This pattern is a strong indicator of an Adversary-in-the-Middle (AiTM) attack where the threat actor, having bypassed MFA to gain initial access, immediately adds their own authentication method to establish persistence on the account.
This detection identifies when a user or service principal executes a command inside an AKS pod ('kubectl exec') and then, using the same identity, accesses data in a sensitive Azure Blob Storage container within a short time frame. This pattern can indicate an attacker, having gained initial access to the Kubernetes API, is using a pod as a pivot point to discover and exfiltrate sensitive data.
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.
This rule will alert when a pending action is required by a Security Administrator in Defender XDR. XDR lacks integrations with common ITSM applications and can only natively email for notifications. This will allow you to create a Sentinel Incident which then you can use a logic app to alert to whatever platform you would like.
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.
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.
Detects interactive administration commands (exec, attach, port-forward) within a sensitive Kubernetes namespace. Such activity can be legitimate but warrants scrutiny in high-value environments as it allows direct interaction with containerized applications and data.
This query will generate an alert for any emails that Defender AIR identifies as malicious but has taken no AIR actions.
Detects when an Azure Kubernetes Service (AKS) worker node initiates an outbound connection to a public IP address over a non-standard or unexpected port. This could indicate data exfiltration using custom tools or protocols.
This analytics rule measures Mean Time to Detect (MTTD) for alerts generated by Sentinel analytics rules. It correlates rule execution data from SentinelHealth with corresponding alerts in SecurityAlert and incidents in SecurityIncident to determine how long it took for an analytics rule to detect malicious or suspicious activity after the first related event occurred.
The query retrieves all successful analytics rule executions within the specified time window, joins them to alerts using the CorrelationId, and then maps those alerts to incidents through AlertIds. For each alert–incident pair, the rule calculates MTTD as the difference between the rule run time and the first activity time associated with the incident. Results are aggregated by alert name and severity to provide counts and average detection times, enabling visibility into detection performance and rule efficacy.
The query retrieves all successful analytics rule executions within the specified time window, joins them to alerts using the CorrelationId, and then maps those alerts to incidents through AlertIds. For each alert–incident pair, the rule calculates MTTD as the difference between the rule run time and the first activity time associated with the incident. Results are aggregated by alert name and severity to provide counts and average detection times, enabling visibility into detection performance and rule efficacy.
There are simpler versions of this when investigating manually, this is not for manual use on your day to day activities, this is for automation.
This simple query helps detect whether a user interacted with the URL within the email message or not.
This detection identifies successful logon activity (Event ID 4624) on a device that has been reported as stolen or missing. Such activity is highly suspicious and could indicate unauthorized access. The rule enriches the alert with ISP IP information from Azure AD sign-in logs to aid in investigation.
This query detects suspicious sign-in activity from a user who has recently clicked on a phishing link. It correlates email click events with sign-in logs, identifying sign-ins from new or infrequent IP addresses after a user has interacted with a suspicious email. The rule uses configurable parameters for sender email addresses, sender domains, and subject keywords to identify phishing emails.
This rule detects successful sign-ins that used single-factor authentication and were flagged by Azure AD Identity Protection for having unfamiliar properties, such as a new location, device, or ASN. Single-factor authentication is inherently weaker, and when combined with anomalous sign-in properties, it can be an indicator of a compromised account.
Page 144 of 185