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
Detects the use of common command-line tools (curl, wget, python, etc.) to interact with known cloud provider metadata service IP addresses or URL paths, often performed by shell processes. This behavior is frequently associated with initial reconnaissance or attempts to steal identity tokens from cloud-based virtual machines.
Detects sign-in activity using the OAuth 2.0 device code flow, followed by subsequent authentication attempts from the same account originating from anomalous, previously unseen geographic locations or using unfamiliar applications. This pattern is indicative of a device code phishing attack where an adversary lures a user into authorizing a malicious device or application and subsequently hijacks the resulting session to access resources from a different location.
Detects repeated MFA authentication failures for specific Microsoft applications (like OfficeHome, My Apps, My Sign-Ins) from the same user and source IP, typically indicative of an MFA fatigue (prompt bombing) attack. The rule identifies multiple authentication failures or interruptions (ErrorCode 50074 or 50140) from unmanaged or unregistered devices, which suggests an adversary attempting to force a user to approve an MFA request.
This rule detects potentially malicious reconnaissance or enumeration activity by tracking high volumes of read-only API calls (LIST/read operations) across multiple Azure resource providers (e.g., VMs, Subscriptions, Web sites, Storage, Recovery Services) performed by a single identity within a 30-minute window.
Detects a single identity listing access keys for a high volume (20+) of Azure Storage Accounts within a 15-minute window. This behavior is indicative of credential harvesting, reconnaissance, or automated exfiltration attempts targeting storage resources.
This rule detects scenarios where a device registration event occurs within 15 minutes of a device-code authentication sign-in for the same user. This pattern is indicative of potential account manipulation where an adversary registers their own device to an existing account to maintain persistent access or bypass multi-factor authentication (MFA).
This rule detects potential OAuth token theft resulting from device code phishing (e.g., N0va phishkit). It monitors for a successful OAuth device-code authentication followed within 5 minutes by a secondary successful sign-in for the same user from a different IP address, different browser client, or different user agent, which is a common indicator of an adversary-in-the-middle (AiTM) session hijacking attempt.
Detects potential device code phishing activity by identifying users who successfully perform a device code authentication flow shortly before registering a new device in Azure AD. This pattern is indicative of an adversary tricking a user into authenticating a malicious device to the victim's account.
Detects anomalous activity associated with the OAuth 2.0 device code grant flow in Azure AD. By aggregating authentication requests within 15-minute windows, the rule identifies potential device code phishing or abuse, specifically flagging users exhibiting high-frequency polling (5 or more requests) or attempts from multiple distinct source IP addresses for a single session.
Detects phishing emails containing lures that direct users to the Microsoft device login portal to enter an attacker-supplied code. The rule correlates the delivery of these emails with subsequent successful device-code based authentication events, identifying potential token theft via the OAuth device code flow.
Detects when an Azure account user creates a new Cognitive Services or Azure OpenAI resource, specifically when that user has no record of creating such resources in the previous 30 days. This behavior is often indicative of automated resource abuse, unauthorized infrastructure deployment, or attempts to leverage GPU/compute quotas in a newly compromised environment.
This rule detects anomalous spikes in API request volume for Azure Cognitive Services resources by comparing the current hourly request count against a 7-day historical baseline for the same hour-of-day. Significant increases (defined by a spike ratio threshold of 3.0 and a minimum call count of 20) may indicate potential misuse, automated scraping, unauthorized resource consumption, or potential denial-of-service activity targeting the API endpoints.
Detects when a namespace-scoped identity creates, updates, or patches AWS or Azure IAM-related custom resources in Kubernetes. This pattern monitors for a 'confused deputy' scenario where a user might attempt to leverage high-privilege cloud operators (like ACK or ASO v2) that operate with a shared high-privilege identity to modify cloud IAM configurations.
Detects when a namespace-scoped identity creates, updates, or patches AWS or Azure IAM-related custom resources in Kubernetes. This pattern monitors for a 'confused deputy' scenario where a user might attempt to leverage high-privilege cloud operators (like ACK or ASO v2) that operate with a shared high-privilege identity to modify cloud IAM configurations.
Detects when a namespace-scoped identity creates, updates, or patches AWS or Azure IAM-related custom resources in Kubernetes. This pattern monitors for a 'confused deputy' scenario where a user might attempt to leverage high-privilege cloud operators (like ACK or ASO v2) that operate with a shared high-privilege identity to modify cloud IAM configurations.
Detects anomalous activity associated with AI and LLM service providers by identifying accounts that are either interacting with these services for the first time or exhibiting a significant spike in API call volume compared to their 14-day historical baseline. This pattern may indicate unauthorized use of enterprise AI resources, potential persistence mechanisms, or exfiltration activities abusing legitimate LLM orchestration APIs.
Detects high-volume outbound network scanning activity from a single compute resource, characterized by a significant number of distinct destination IP addresses and ports within a short timeframe. This behavior is indicative of automated service discovery and reconnaissance, often associated with adversary-orchestrated exploitation pipelines or botnet activity.
Detects device registration events where the device name does not conform to the expected organizational naming convention. This may indicate an attempt to register unauthorized or rogue devices in the environment.
Detects a suspicious correlation between the registration of new authentication methods or application integrations and the subsequent modification of Conditional Access policies within a 2-hour window. This behavior is indicative of the activation phase of a TrustSink attack, where an adversary sets up a malicious MFA provider and forces its use by expanding Conditional Access policy scope.
Detects Azure AD sign-in events where Multi-Factor Authentication (MFA) was reportedly satisfied by an External Authentication Method (EAM) claim without evidence of a traditional secondary authentication challenge. This behavior is indicative of a 'TrustSink' technique where a rogue or compromised OIDC provider injects a spoofed assertion of MFA success into the authentication token.
This rule detects potential Adversary-in-the-Middle (AiTM) activity by identifying a sequence where a user experiences a sign-in interruption (ResultType 50199) followed by a successful sign-in with the same SessionId but from a different, anomalous User-Agent (typically associated with automated tools like Axios). This pattern indicates the reuse of intercepted session tokens to bypass multi-factor authentication.
Page 50 of 185