Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
81 detections
Filters
Last updated
All Time
Detection languages
52
11
6
4
3
Contributors
24
18
6
5
3
Categories
61
34
26
19
14
Platforms
57
49
38
6
2
Products / Services
52
29
15
8
7
MITRE Techniques
18,116
15,638
12,586
8,396
6,226
IDS Classtypes
2
1
IDS Protocols
3
Detects instances where a non-administrative user grants an OAuth application consent to access high-privilege Microsoft Graph scopes, such as 'Mail.Read', 'Directory.ReadWrite.All', or 'offline_access'. This pattern is frequently used in consent phishing attacks to maintain persistent access to sensitive cloud resources.
Detects instances where a user grants consent to an unverified OAuth application requesting high-privilege scopes (e.g., Mail.Read, Files.ReadWrite.All). This behavior is characteristic of consent phishing attacks aimed at obtaining persistent access to sensitive data and mailbox contents.
Detects the creation of an application or service principal followed quickly (within 1 hour) by a tenant-wide delegated permission grant scoped to 'AllPrincipals' with 'openid' and 'profile' permissions. This sequence is a known indicator of automated rogue Enterprise Application setup, often used in consent phishing or persistence campaigns.
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 when a user grants OAuth application permissions for high-risk scopes (e.g., Mail, Files) to an application that was registered within the last 7 days. It correlates this event with subsequent suspicious actions performed by the same user, specifically mailbox rule modifications or file download activity, which are common indicators of post-compromise activity following OAuth consent phishing.
Detects anomalous mass consent grants to OAuth applications by users within the environment. This rule monitors for high-risk permissions such as Mail.Read and Files.ReadWrite.All, which are commonly used in consent phishing and application-based persistence campaigns to gain unauthorized access to mailbox and file resources.
Detects instances of OAuth device code flow authentication from suspicious sources (e.g., unfamiliar devices, non-compliant/unmanaged devices, or unusual geographic locations) that are followed closely by an OAuth application consent event. This behavior is indicative of potential consent phishing or device code phishing attacks attempting to gain persistent access to cloud resources.
This rule detects potentially malicious OAuth application consent grants in Microsoft Entra ID (formerly Azure AD). It monitors for consent events involving high-risk scopes by non-verified publishers, instances of admins attempting to bypass consent requirements, and follows up by checking for unusually high activity (sign-ins or resource access) from the newly consented application within a short timeframe.
Detects invocations of the 'grafana_api_request' tool that lack a preceding valid bearer-token authentication event for the same session. This indicates a potential scenario where a server or service account token is being used on behalf of an unauthenticated caller, bypassing normal authentication requirements for the Grafana API.
Detects invocations of the 'grafana_api_request' tool that lack a preceding valid bearer-token authentication event for the same session. This indicates a potential scenario where a server or service account token is being used on behalf of an unauthenticated caller, bypassing normal authentication requirements for the Grafana API.
Detects invocations of the 'grafana_api_request' tool that lack a preceding valid bearer-token authentication event for the same session. This indicates a potential scenario where a server or service account token is being used on behalf of an unauthenticated caller, bypassing normal authentication requirements for the Grafana API.
Detects invocations of the 'grafana_api_request' tool that lack a preceding valid bearer-token authentication event for the same session. This indicates a potential scenario where a server or service account token is being used on behalf of an unauthenticated caller, bypassing normal authentication requirements for the Grafana API.
Detects newly granted or consented Microsoft Entra ID application permissions exceeding baseline, a weakness CISA's red team exploited to escalate privileges and reach cloud resources.
Detects invocations of the 'grafana_api_request' tool that lack a preceding valid bearer-token authentication event for the same session. This indicates a potential scenario where a server or service account token is being used on behalf of an unauthenticated caller, bypassing normal authentication requirements for the Grafana API.
This rule monitors for suspicious persistence activity in Microsoft 365 environments by correlating the creation of email forwarding or transport rules (such as 'ForwardTo', 'RedirectTo', or 'DeleteMessage' operations) with the granting of OAuth application permissions (application consent or app role assignments) for the same user within a one-hour window. This combination of actions is often indicative of an adversary establishing both persistent mail access and broad application-level access to a user account.
This rule monitors for suspicious persistence activity in Microsoft 365 environments by correlating the creation of email forwarding or transport rules (such as 'ForwardTo', 'RedirectTo', or 'DeleteMessage' operations) with the granting of OAuth application permissions (application consent or app role assignments) for the same user within a one-hour window. This combination of actions is often indicative of an adversary establishing both persistent mail access and broad application-level access to a user account.
This rule identifies Service Principals in Microsoft Entra ID that have successfully authenticated after a long period of dormancy (defined as 90 days or more). Reactivation of dormant service principals may indicate that an adversary is attempting to revive a persistent access method or abuse credentials that were previously set aside.
Detects the creation of a new Service Principal followed by an immediate application of an app role assignment within one hour. The rule specifically targets service principals with names suggestive of automation, AI, or assistant-related roles (e.g., 'copilot', 'llm', 'bot'), which may indicate the use of newly created service principals for potential persistence or unauthorized access.
This rule identifies Service Principals in Microsoft Entra ID that have successfully authenticated after a long period of dormancy (defined as 90 days or more). Reactivation of dormant service principals may indicate that an adversary is attempting to revive a persistent access method or abuse credentials that were previously set aside.
Detects the creation of a new Service Principal followed by an immediate application of an app role assignment within one hour. The rule specifically targets service principals with names suggestive of automation, AI, or assistant-related roles (e.g., 'copilot', 'llm', 'bot'), which may indicate the use of newly created service principals for potential persistence or unauthorized access.
Proofpoint has observed OAuth client ID spoofing emerging as a novel technique, increasingly leveraged in cloud campaigns. Microsoft Entra ID returns different responses depending on whether a supplied OAuth client ID is valid and whether it corresponds to a registered application. This behavior enables account enumeration without a registered OAuth application and allows attackers to infer password validity or account state without generating a successful sign‑in event. Researchers observed multiple campaigns at scale abusing spoofed OAuth application identifiers, with distinct tooling, infrastructure, and execution patterns indicating independent adoption by multiple threat actors.
To detect similar activity, defenders should monitor sign-in logs for events without an application name, which may indicate spoofed client IDs.
To detect similar activity, defenders should monitor sign-in logs for events without an application name, which may indicate spoofed client IDs.
Page 2 of 4