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
This rule correlates multiple telemetry sources to detect a sophisticated cloud identity compromise chain. It identifies suspicious MFA-satisfied logins (potentially via Adversary-in-the-Middle) followed by the granting of high-risk OAuth application consents, the creation of persistent mailbox rules for hiding or forwarding communications, and finally mass data access or exfiltration from the user's account.
Detects unauthorized modification or deletion of AWS Bedrock model invocation logging configurations. Adversaries may use this technique to disable visibility into LLM usage or redirect logs to an attacker-controlled storage location to hide subsequent malicious activity.
Detects anomalous, high-volume automated API querying or bulk data exports within SaaS environments that target keywords associated with sensitive information, such as passwords, tokens, or configuration secrets. This pattern is characteristic of automated reconnaissance and unauthorized data harvesting, often observed in campaigns like those attributed to UNC6395.
Detects anomalous OAuth application consent activity by identifying a surge in unique users granting permissions to a single OAuth application within a short timeframe. This behavior is indicative of consent phishing campaigns where attackers lure users to grant application access to malicious apps, effectively stealing application access tokens and gaining persistent access to resources without requiring the victim's password.
Detects when high-privilege application permissions (e.g., Directory.ReadWrite.All, Application.ReadWrite.All) are granted to a service principal via admin consent. This behavior can be used by attackers to gain persistent, stealthy administrative access to a Microsoft Entra ID tenant.
Detects anomalous use of an OAuth2/OIDC refresh token or Primary Refresh Token (PRT) where the originating device, IP, ASN, or country differs from the initial interactive sign-in within a short timeframe. This behavior is a strong indicator of adversary-in-the-middle (AiTM) attacks, such as Evilginx or Modlishka, where session cookies and tokens are stolen to bypass MFA.
This rule detects when a user registers or adds a new device in Entra ID within a short timeframe (two hours) of experiencing a risky sign-in or a password reset. It specifically flags registrations involving potentially unmanaged, non-compliant, or unusually trusted devices, which may indicate an attempt to establish persistent access or bypass Conditional Access policies.
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 the addition of service principal credentials by a user who is not explicitly listed as an owner of the application. This activity is monitored to identify potential persistence or privilege escalation attempts where an unauthorized account adds its own authentication method to an existing cloud application or service principal.
Detects instances where an administrator or user grants an application consent with highly sensitive permissions in Azure AD (Microsoft Entra ID). This activity is often associated with OAuth application phishing, where an adversary lures a user into granting excessive permissions to a malicious application, potentially leading to long-term persistence or unauthorized access to directory data and conditional access policies.
This rule detects when a non-privileged user adds a new owner to an Azure AD Application or Service Principal, followed by a suspicious modification (such as adding credentials or permissions) to that same application within 30 minutes. This behavior is indicative of an adversary attempting to gain persistent, elevated access to an application's service principal to manipulate its configuration or permissions.
This rule detects when a non-privileged user adds a new owner to an Azure AD Application or Service Principal, followed by a suspicious modification (such as adding credentials or permissions) to that same application within 30 minutes. This behavior is indicative of an adversary attempting to gain persistent, elevated access to an application's service principal to manipulate its configuration or permissions.
Detects instances where a non-administrative user grants OAuth application permissions that include high-risk delegated scopes. This activity is a primary indicator of illicit consent grant phishing attacks, where an adversary lures users into authorizing malicious applications to access sensitive data (such as emails or files) without administrator approval.
Detects the addition of new service principal credentials (passwords or certificates) to Azure AD applications occurring outside of typical business hours. This behavior may indicate an attacker attempting to establish persistence or maintain unauthorized access to cloud resources through an existing application identity.
Detects anomalous sign-in behavior using the OAuth 2.0 device code authorization flow. The rule identifies sign-ins from previously unseen geographic locations or IP ranges (ASN) for a specific user, or detects a potential tenant-wide phishing campaign where multiple users are performing device-code authentications in a short timeframe, which is characteristic of 'device code phishing' (a form of OAuth consent phishing).
Detects anomalous sign-in behavior using the OAuth 2.0 device code authorization flow. The rule identifies sign-ins from previously unseen geographic locations or IP ranges (ASN) for a specific user, or detects a potential tenant-wide phishing campaign where multiple users are performing device-code authentications in a short timeframe, which is characteristic of 'device code phishing' (a form of OAuth consent phishing).
Detects modifications to Microsoft Entra ID (formerly Azure AD) cross-tenant access settings where a new partner is added or inbound trust settings (such as MFA or device compliance) are enabled for an external tenant. This activity may indicate an attempt to establish a persistent backdoor or facilitate initial access into the environment via a compromised or malicious external identity provider.
This rule detects anomalous activity involving cloud-based shell services (AWS CloudShell, Azure Cloud Shell, GCP Cloud Shell). It triggers on two main conditions: (1) First-time usage of these shell environments by a principal within the detection window, and (2) The execution of commands associated with data staging, ingress tool transfer, or exfiltration (e.g., curl, wget, storage copy commands).
Detects unauthorized sharing, copying, or exporting of EBS, disk, or database snapshots to external cloud accounts, subscriptions, or projects that are not present in the defined trusted allow-list for AWS, Azure, or GCP environments.
Detects the creation of new programmatic credentials (AWS access keys, Azure AD service principal credentials, or GCP service account keys) where the identity creating the credential differs from the identity for which the credential is being issued. This behavior is often indicative of persistence mechanisms or credential abuse where an attacker with sufficient permissions creates secondary credentials for other accounts.
This rule detects the creation or modification of recurring cloud automation tasks (AWS EventBridge rules, Azure Automation Runbooks/Logic Apps, and GCP Cloud Scheduler jobs). Adversaries leverage these features to establish persistent access to a cloud environment by ensuring malicious code or scripts execute automatically, even after initial compromised credentials have been revoked.
Page 10 of 135