Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,832 detections
Filters
Last updated
All Time
Detection languages
1,375
495
363
281
175
Contributors
848
453
393
252
188
Categories
20,443
11,831
5,875
5,151
4,864
2,832
Platforms
1,449
916
693
670
264
Products / Services
994
701
613
469
216
MITRE Techniques
1,240
912
484
482
388
CVEs
6
5
2
1
1
IDS Classtypes
15
10
6
5
3
IDS Protocols
39
Detects modifications to Entra ID (Azure AD) cross-tenant access settings, including inbound/outbound trust settings and B2B collaboration configurations. This activity may indicate an adversary attempting to establish persistence or facilitate unauthorized access by creating a trust relationship with an external tenant they control.
Detects modifications to Entra ID (Azure AD) cross-tenant access settings, including inbound/outbound trust settings and B2B collaboration configurations. This activity may indicate an adversary attempting to establish persistence or facilitate unauthorized access by creating a trust relationship with an external tenant they control.
This rule detects when a user or admin grants consent to an unverified OAuth application that simultaneously requests sensitive delegated permissions across multiple categories (Mail, Files, Directory, and Contacts). This pattern is a strong indicator of consent phishing attacks, where adversaries trick users into granting broad permissions to a malicious application to harvest sensitive data or gain persistent access to a Microsoft 365 environment.
Detects anomalous Privileged Identity Management (PIM) role activations in Entra ID that deviate from standard patterns. This includes instances where roles are activated without required approvals, for unusually long durations, or when an account activates multiple distinct roles within a short time frame, potentially indicating account takeover or abuse of standing privileges.
Detects the registration of a new multi-tenant OAuth application in an enterprise cloud environment that requests high-risk scopes (e.g., mail access or directory write permissions). This behavior is often associated with OAuth-based consent phishing or the establishment of persistent backdoors in cloud environments.
Detects the registration of a new multi-tenant OAuth application in an enterprise cloud environment that requests high-risk scopes (e.g., mail access or directory write permissions). This behavior is often associated with OAuth-based consent phishing or the establishment of persistent backdoors in cloud environments.
Detects a mass influx of OAuth consent grant events for a single application from multiple users within a one-hour window. This behavior is indicative of a consent phishing campaign, where attackers lure users into granting excessive permissions to a malicious application to steal access tokens.
This rule detects when an OAuth application is granted sensitive Exchange Online permissions, such as 'full_access_as_app', 'Mail.Read', 'Mail.ReadWrite', or 'Mail.Send'. Granting these permissions allows an application to access mailboxes across the tenant without requiring a signed-in user context, which is a common persistence and data exfiltration technique used in Business Email Compromise (BEC) and espionage campaigns.
Detects modifications to Microsoft Entra ID (formerly Azure AD) Conditional Access policies that lower security posture. This includes disabling an active policy, removing users or groups from enforcement scopes, or removing MFA requirements. Such actions are typical of an adversary attempting to maintain persistent access or evade authentication controls.
This rule detects scenarios where an Azure application's permissions (scopes) are upgraded to high-risk levels after an initial period, a technique known as 'incremental consent'. This is often used by attackers to avoid triggering high-risk consent alerts during the initial application authorization process, subsequently escalating privileges over time.
Detects modifications to Microsoft Entra ID (formerly Azure AD) Conditional Access policies that lower security posture. This includes disabling an active policy, removing users or groups from enforcement scopes, or removing MFA requirements. Such actions are typical of an adversary attempting to maintain persistent access or evade authentication controls.
This rule detects scenarios where an Azure application's permissions (scopes) are upgraded to high-risk levels after an initial period, a technique known as 'incremental consent'. This is often used by attackers to avoid triggering high-risk consent alerts during the initial application authorization process, subsequently escalating privileges over time.
Detects the creation of a new application secret or credential in a cloud environment followed by an immediate authentication attempt using that credential from an IP address that has not been observed performing successful authentication within the specified lookback window. This behavior is indicative of potential unauthorized persistence or the use of compromised credentials by an adversary.
Detects malicious attempts to delete or modify the access control settings of centralized cloud audit log storage, such as S3 buckets, Azure Log Analytics workspaces, or GCP log buckets. These actions aim to impair visibility into an adversary's activities, a common step in anti-forensics and data destruction workflows.
Detects chained AWS STS AssumeRole/AssumeRoleWithSAML/AssumeRoleWithWebIdentity events where a principal assumes a role in a different account and then quickly performs another role assumption from that new context. This pattern, often referred to as 'role chaining' or 'role laundering', is frequently used to obfuscate identity tracking and facilitate lateral movement across AWS account boundaries.
Detects the use of iam:PassRole to attach a potentially highly privileged IAM role (e.g., Administrator, PowerUser, FullAccess) to newly created or modified compute or serverless resources (EC2 instances, Lambda functions, Launch Templates, or Auto Scaling Groups). This behavior is indicative of an attacker attempting to escalate privileges by granting a managed resource excessive permissions that the attacker can subsequently abuse.
Detects the creation of programmatic API credentials or service principal keys by highly privileged cloud identities across AWS, Azure, and GCP. Specifically monitors AWS Root, Azure AD Global/Company Administrators, and GCP Organization Owners, whose roles generally do not require long-term API access.
This rule detects the assignment of sensitive Microsoft Graph API application roles to a service principal, which can be an indicator of an adversary establishing a directory-wide backdoor in an Azure/Entra ID environment. This technique is often used to escalate privileges following an initial compromise of a low-privilege application registration.
Detects instances where a non-administrative user grants OAuth application permissions for high-risk Microsoft Graph delegated scopes. This activity is a common indicator of 'consent phishing' campaigns, where an attacker tricks a user into authorizing a malicious application, granting persistent access to the user's data and resources via API tokens, even after password resets.
Detects OAuth application consent events where an application is granted a combination of 'offline_access' (allowing refresh token issuance) and email-read permissions. This pattern is commonly used by adversaries to establish persistent, long-term access to user mailboxes for data exfiltration or Business Email Compromise (BEC) activities, surviving password changes until the consent is explicitly revoked.
Detects instances where an administrator has granted tenant-wide consent to an OAuth application requesting highly privileged Microsoft Graph permissions. This activity is a significant indicator of potential persistence or privilege escalation, as it allows the application to perform sensitive operations across the organization without requiring individual user interaction.
Page 18 of 135