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
Detects anomalous network polling patterns consistent with 'EvilTokens' or similar adversary-in-the-middle (AiTM) OAuth phishing kits. The rule identifies web browsers performing high-frequency, low-interval polling (3-6s) against non-reputable/unseen domains (the attacker-controlled status endpoint) immediately preceding or following successful Microsoft OAuth device-code authentication sequences.
This rule monitors authentication activity within Microsoft Entra ID (formerly Azure AD) involving the Device Code flow. This flow is often abused by attackers through phishing to obtain access tokens. The rule detects and lists occurrences of authentication attempts leveraging the device code grant, facilitating the investigation of potentially malicious token acquisition or replay attacks.
Detects potential device-code phishing abuse where a successful device code authentication is followed by scripted API activity using common automation user agents within a short time window (10 minutes). This behavior is indicative of an attacker who has successfully phished a user's device code and is immediately leveraging the stolen token to interact with Microsoft Graph, Azure, or Intune services.
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 Azure AD sign-in events using the device code authorization flow where only single-factor authentication was performed. This pattern is indicative of potential device code phishing attacks where users are tricked into entering codes on attacker-controlled pages to grant access tokens, bypassing standard MFA requirements.
Detects a sequence of suspicious activities associated with EvilTokens-style session hijacking. This includes the identification of non-interactive sign-in events involving the redemption of a refresh token without secondary MFA, followed by the creation or modification of Exchange Online mailbox rules to facilitate unauthorized email forwarding or exfiltration.
Detects high-privilege OAuth application consent grants occurring shortly after a user identity recovery event (e.g., password or MFA reset). This pattern is indicative of a help-desk social engineering attack where an adversary uses an identity reset to gain access to an account and subsequently establishes persistent access via a malicious OAuth application.
Detects instances where the device code authentication protocol is utilized. This protocol is commonly used for headless devices, but is also frequently abused by adversaries for phishing and device code flow abuse to acquire unauthorized access tokens.
Detects high-privilege OAuth application consent grants occurring shortly after a user identity recovery event (e.g., password or MFA reset). This pattern is indicative of a help-desk social engineering attack where an adversary uses an identity reset to gain access to an account and subsequently establishes persistent access via a malicious OAuth application.
This rule detects successful user logins that utilize the 'deviceCode' authentication protocol in conjunction with suspicious network indicators, specifically traffic originating from residential proxies. This combination is highly indicative of potential phishing or unauthorized access attempts using stolen session tokens or bypassed MFA mechanisms.
Detects instances where a user performs sensitive privilege escalation or administrative modifications (e.g., adding roles, consent to applications) within two hours of authenticating via the Entra ID device-code flow. This correlation is often indicative of OAuth application device-code phishing or token abuse, where an attacker tricks a user into granting permissions to a malicious application.
This rule detects successful user logins utilizing the OAuth 2.0 device authorization grant flow where Multi-Factor Authentication (MFA) was bypassed, not applied, or not performed. The device code flow is a common vector for phishing attacks where users are tricked into entering a device code on a malicious site, potentially leading to unauthorized token acquisition.
This rule detects non-interactive authentication attempts to key development and collaboration platforms (e.g., GitHub, GitLab, Slack, Azure DevOps) from IP addresses or locations that have not been observed in the user's interactive sign-in history over the past 14 days. This behavior is indicative of potential session or refresh token theft, where an adversary replays stolen browser cookies from a different infrastructure to bypass traditional authentication.
Detects successful device code authentication flows involving applications that are not part of a known list of standard Microsoft and Azure client applications. Device code flows are frequently abused in phishing attacks to bypass traditional credential-based authentication.
This rule detects successful or attempted sign-ins to Microsoft Entra ID using the OAuth 2.0 device authorization grant flow. This specific authentication flow is increasingly leveraged by adversaries in passkey-themed phishing campaigns to obtain valid access and refresh tokens without requiring direct credential or cookie theft. By monitoring for this protocol usage, security teams can identify potential attempts to bypass traditional authentication mechanisms.
Detects the use of the device code authentication protocol in Azure Sign-in logs, which is a common vector used in Adversary-in-the-Middle (AiTM) phishing attacks to hijack OAuth tokens.
Detects instances where a user grants high-privilege permissions (Mail.Read, Files.ReadWrite.All, offline_access) to an OAuth application within 24 hours of a risky sign-in event. This pattern is commonly observed in AiTM (Adversary-in-the-Middle) or consent-phishing attacks designed to establish persistent access to cloud resources.
The following analytic detects when a user in an Azure AD environment grants consent to an OAuth application. It leverages Azure AD audit logs to identify events where users approve application consents.
This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access.
If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks.
This activity is significant as it can expose organizational data to third-party applications, a common tactic used by malicious actors to gain unauthorized access.
If confirmed malicious, this could lead to unauthorized access to sensitive information and resources. Immediate investigation is required to validate the application's legitimacy, review permissions, and mitigate potential risks.
Correlates new OAuth application consent grants with a preceding helpdesk-driven password/MFA reset on the same user, catching attacker-installed OAuth persistence — echoes the 2026 Vercel/Context.ai OAuth-abuse incident that followed a similar trust-granting pattern.
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 potential Adversary-in-the-Middle (AiTM) phishing attacks by identifying an initial legitimate sign-in followed by a second sign-in from a different IP address within a short timeframe (indicative of session token replay), immediately succeeded by high-risk post-compromise actions such as OAuth application consent or the creation of malicious mailbox rules.
Page 14 of 37