Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,831 detections
Filters
Last updated
All Time
Detection languages
1,374
495
363
281
175
Contributors
848
453
393
252
188
Categories
20,440
11,814
5,871
5,145
4,864
2,831
Platforms
1,448
916
693
670
264
Products / Services
994
700
613
469
216
MITRE Techniques
1,239
911
484
481
388
CVEs
6
5
2
1
1
IDS Classtypes
15
10
6
5
3
IDS Protocols
39
Detects login attempts to source code repositories and developer tooling (GitHub, GitLab, Bitbucket, Azure DevOps, Slack, Visual Studio Code) originating from unmanaged or non-compliant devices, excluding traffic originating from known corporate network ranges.
Detects bulk read operations on AWS Secrets Manager or similar cloud secret stores where the accessed resources contain keywords related to cryptocurrency custody, private keys, or wallet material. This pattern is indicative of unauthorized exfiltration attempts by threat actors such as Slim Spider targeting digital asset infrastructure.
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.
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).
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.
This rule detects a user account performing its first-ever GitHub OAuth or repository access within a short timeframe (30 minutes) after authenticating to a designated low-trust OpenAI community forum. This pattern is designed to identify potential adversary activity where a compromised or newly created account is used to pivot from a low-trust environment to corporate repository access.
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.
Detects the granting of OAuth application permissions, specifically targeting applications with names containing terms like 'ai', 'copilot', or 'chatbot'. The rule looks for high-privilege scopes such as Mail, Files, or Directory access, which are common indicators of consent phishing or the use of malicious AI-branded applications to gain persistent access to sensitive data in the M365 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.
This rule detects a suspicious sequence of AWS CloudTrail events where a single identity performs a burst of discovery and enumeration activities (reconnaissance) followed shortly by requests to access sensitive secrets, credentials, or sensitive files (e.g., .env files). This pattern is indicative of an attacker who has gained initial access and is pivoting to identify and exfiltrate credentials.
Detects anomalous bursts of cloud secret or parameter retrieval API calls followed shortly by administrative actions that expose data or credentials (such as bucket policy changes or new key creation). This behavior is consistent with an adversary staging compromised credentials to exfiltrate data or maintain persistence.
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 unauthorized or suspicious use of Google Cloud Config Connector (KCC) service accounts to apply high-privilege IAM roles ('roles/owner' or 'roles/resourcemanager.organizationAdmin') at the Organization or Folder scope. This rule monitors for 'SetIamPolicy' API calls where the principal is identified as a KCC-related service account, flagging potential exploitation of KCC's authority to grant excessive permissions.
This rule detects unauthorized attempts by non-automation Kubernetes users to create or update IAM policies for Google Cloud resources via Config Connector (KCC). It specifically monitors for actions that assign high-privilege roles (e.g., Organization Owner, Organization Admin) to Organization-scoped resources, excluding authorized platform service accounts and KCC reconciliation traffic.
This rule detects unauthorized attempts by non-automation Kubernetes users to create or update IAM policies for Google Cloud resources via Config Connector (KCC). It specifically monitors for actions that assign high-privilege roles (e.g., Organization Owner, Organization Admin) to Organization-scoped resources, excluding authorized platform service accounts and KCC reconciliation traffic.
This rule detects unauthorized attempts by non-automation Kubernetes users to create or update IAM policies for Google Cloud resources via Config Connector (KCC). It specifically monitors for actions that assign high-privilege roles (e.g., Organization Owner, Organization Admin) to Organization-scoped resources, excluding authorized platform service accounts and KCC reconciliation traffic.
Page 40 of 135