Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
771 detections
Filters
Last updated
All Time
Detection languages
392
128
66
49
47
Contributors
296
150
91
39
27
Categories
388
258
255
124
110
Platforms
523
344
285
121
72
Products / Services
370
328
112
51
43
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
771
CVEs
2
1
IDS Classtypes
15
11
3
1
1
IDS Protocols
29
This rule detects successful sign-ins using OAuth from residential IP addresses. It joins `SigninLogs` with `IdentityLogonEvents` to correlate successful OAuth authentications with user logon events. The intent is to identify potentially suspicious access, possibly indicating credential abuse or unauthorized access attempts from non-corporate or unexpected locations.
This rule detects successful OAuth logins originating from IP addresses identified as residential proxies. This behavior can indicate an adversary attempting to bypass geo-restrictions or obscure their true location, potentially as part of a credential stuffing attack, account takeover, or to evade detection.
Detects unauthorized or non-standard processes attempting to create, modify, or access sensitive cloud configuration and credential files, such as AWS credentials, Azure CLI token caches, or GCP application default credentials. This behavior is indicative of potential credential theft or unauthorized access to cloud environment tokens.
Detects new app installations, expansions of OAuth scopes, or the addition of collaborators to Slack applications. These activities can indicate an adversary attempting to gain persistent access, escalate privileges, or exfiltrate data from Slack by leveraging malicious or compromised applications.
This rule detects successful OAuth sign-ins originating from a residential proxy IP address, correlated with a successful identity logon event for the same user. This pattern can indicate an adversary using residential proxies to bypass geo-restrictions or blend in with legitimate user traffic while attempting to access accounts via OAuth.
This rule detects suspicious activities related to OAuth application consent and service principal operations originating from IP addresses identified as proxy infrastructure. Specifically, it looks for actions such as adding service principal credentials, granting OAuth2Permission, consenting to applications, adding delegated permission grants, and adding service principals or applications, when these actions are performed from a proxy IP address. This combination of activities and source IP can indicate an adversary attempting to establish persistence or escalate privileges within an Azure AD environment.
Detects indicators of the IronWorm malware performing self-propagation by abusing npm Trusted Publishing (OIDC) token exchange, executing suspicious npm publish commands, and unauthorized access to ~/.npmrc configuration files. The rule monitors for network requests to npm OIDC endpoints from non-standard processes, npm publish operations originating from non-interactive shell or script environments, and file access to credential files by suspicious parent processes.
This rule detects processes other than standard web browsers performing network connections that coincide with OAuth token acquisition activities (POST requests containing 'access_token' in the response body). This behavior is indicative of potential token theft or unauthorized programmatic access to OAuth-protected resources.
Detects application consent by a user shortly after the same account clicked a code-of-conduct or compliance-themed message. This behavior can indicate a multi-stage phishing campaign where a user is lured into clicking a malicious link (e.g., a fake policy document) and subsequently grants OAuth permissions to a malicious application.
Detects the use of Azure VM Run Command to execute PowerShell scripts that attempt to retrieve workload identity tokens from the Azure Instance Metadata Service (IMDS) endpoint. This activity could indicate an attacker attempting to steal credentials or escalate privileges within the Azure environment.
This rule detects when an application role assignment or delegated permission grant is successfully added to a service principal in Azure Active Directory, specifically looking for highly privileged permissions such as 'RoleManagement.ReadWrite.Directory', 'UserAuthenticationMethod.ReadWrite.All', 'UserAuthMethod-TAP.ReadWrite.All', or 'User.Read.All'. This could indicate an adversary attempting to gain elevated access or persistence within the Azure AD environment.
This rule detects successful sign-ins using the OAuth 2.0 Device Code Flow. This flow is often abused in phishing attacks (device code phishing) where an attacker tricks a user into authenticating a malicious application. A successful sign-in using this method could indicate a compromised account or a successful phishing attempt.
Detects unauthorized access, creation, or modification of sensitive credential and token files (e.g., OAuth tokens, AWS credentials, gcloud tokens) in common user directories like AppData or .config by processes other than established browsers or legitimate cloud CLI tools. This behavior is indicative of credential theft or SaaS pivot attacks.
Detects unauthorized or non-standard processes attempting to create, modify, or access sensitive cloud configuration and credential files, such as AWS credentials, Azure CLI token caches, or GCP application default credentials. This behavior is indicative of potential credential theft or unauthorized access to cloud environment tokens.
Detects application consent by a user shortly after the same account clicked a code-of-conduct or compliance-themed message. This behavior can indicate a multi-stage phishing campaign where a user is lured into clicking a malicious link (e.g., a fake policy document) and subsequently grants OAuth permissions to a malicious application.
This rule detects potential OAuth token abuse by correlating credential consent grants with subsequent unusual cloud access patterns from different geographic locations. It looks for activities like adding a service principal, adding OAuth2 permission grants, or consenting to an application, followed by access to specific cloud applications (Salesforce, Drift, Slack, Microsoft 365, Workday) from an IP address that does not match the IP address from which the consent was granted. The rule aggregates these events and triggers if there are at least 4 related events within a 6-hour window.
This rule detects suspicious WebSocket upgrade attempts targeted at Microsoft authentication endpoints, typically used by 'Bluekit' or similar Phishing-as-a-Service (PhaaS) platforms to establish a persistent connection or tunnel for credential harvesting via adversary-in-the-middle attacks. It flags traffic from non-private IP addresses that exhibit specific patterns associated with proxy usage or automated tooling (e.g., Python/curl) combined with WebSocket upgrade headers.
This rule detects suspicious WebSocket upgrade attempts targeted at Microsoft authentication endpoints, typically used by 'Bluekit' or similar Phishing-as-a-Service (PhaaS) platforms to establish a persistent connection or tunnel for credential harvesting via adversary-in-the-middle attacks. It flags traffic from non-private IP addresses that exhibit specific patterns associated with proxy usage or automated tooling (e.g., Python/curl) combined with WebSocket upgrade headers.
Detects successful OAuth application consent events where the requested permissions include sensitive scopes such as Mail, Files, or User profile access. This is a common indicator of OAuth application-based phishing or persistence attempts, often referred to as 'Illicit Consent Grant' attacks.
This rule detects EvilTokens device code OAuth phishing by identifying rapid, repeated POST requests to the /common/oauth2/token endpoint with a device_code grant and authorization_pending responses, followed by a successful token issuance and sign-in without an MFA claim. This pattern is consistent with EvilTokens session harvesting.
Detects suspicious OAuth application or service principal registration, or permission consent, performed by users who are not part of designated IT administrator groups. This rule flags high-privilege permission grants (e.g., Mail.Read, Directory.ReadWrite.All) or application consent events, which are common methods for establishing long-term persistence in cloud environments.
Page 30 of 37