Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,868 detections
Filters
Last updated
All Time
Detection languages
2,527
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,092
793
576
Platforms
39,960
7,270
6,537
3,868
3,651
Products / Services
1,757
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 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 is a credential after-hours logon activity automation, whenever an employee that's not supposed to log on to the core banking system after hours do so, this will trigger and alert the SOC team.
This is for when we need to investigate user navigation through proxy logs to understand if visit was intentional or if it was a sideload (redirect/iframe/malvertising) causing the navigation.
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.
Page 144 of 185