Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
461 detections
Filters
Last updated
All Time
Detection languages
276
67
44
26
23
Contributors
167
111
62
17
9
Categories
238
219
140
83
78
Platforms
338
217
143
29
23
Products / Services
286
157
50
38
27
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
CVEs
13
5
3
2
1
IDS Classtypes
5
3
2
IDS Protocols
9
Detects successful sign-ins using the device code authentication flow that are infrequent for a specific user and location. This flow is often targeted by attackers attempting to bypass MFA or perform device phishing, as it requires the user to manually authorize the device on a separate platform.
Detects OAuth application authorization events where the granted scopes include highly sensitive access such as Gmail, Drive, or Admin APIs. This rule identifies potential consent phishing attacks where users are tricked into granting malicious third-party applications broad, unauthorized access to their Google Workspace account. The rule excludes common, expected applications like Google Cloud SDK or standard Google services.
Detects suspicious OAuth consent or connected app authorization followed by SaaS query, export, download, or bulk API activity from the same account within 24 hours, indicating possible OAuth token abuse or SaaS data exfiltration.
This rule identifies non-Microsoft processes (based on file name, file company name, and process signer) that initiate network connections to known Microsoft authentication endpoints. This behavior is often indicative of an adversary-controlled process attempting to leverage cloud services or perform authentication-related activities outside of expected system or productivity software.
Detects OAuth applications receiving permissions to the tenant, used for persistence and data theft. A consented app holds its own token and survives password resets and MFA, which is why consent phishing and post-compromise app registration are favored by both commodity BEC actors and nation-state (PerfectData is linked to Midnight Blizzard / APT29). Tiered: a hardcoded list of known-abused app IDs (PerfectData, eM Client, rclone, Supermailer, and others), layered over a scope-characteristic tier that catches bespoke apps by the permissions they request (Mail/EWS, Files/Sites, Directory, Application, offline_access), with admin/AllPrincipals consent escalating blast radius. Parses all three consent event shapes and resolves app identity across them.
Detects a single Entra ID session (SessionId) being used from two different countries within one hour at a travel velocity no physical journey could achieve. This is a signature of a stolen session/refresh token being replayed by an actor from a different location than the legitimate user.
Detects successful sign-ins using the device code authentication flow that are infrequent for a specific user and location. This flow is often targeted by attackers attempting to bypass MFA or perform device phishing, as it requires the user to manually authorize the device on a separate platform.
Detects non-interactive sign-ins (refresh-token usage) for Microsoft Purview Communication Compliance reviewer accounts (Administrator, Analyst, or Investigator roles) that originate from IP addresses not observed for the user in the previous 21 days. This behavior is indicative of potential token theft or session hijacking attempting to bypass multi-factor authentication.
Detects non-interactive sign-ins (refresh-token usage) for Microsoft Purview Communication Compliance reviewer accounts (Administrator, Analyst, or Investigator roles) that originate from IP addresses not observed for the user in the previous 21 days. This behavior is indicative of potential token theft or session hijacking attempting to bypass multi-factor authentication.
Detects OAuth applications receiving permissions to the tenant, used for persistence and data theft. A consented app holds its own token and survives password resets and MFA, which is why consent phishing and post-compromise app registration are favored by both commodity BEC actors and nation-state (PerfectData is linked to Midnight Blizzard / APT29). Tiered: a hardcoded list of known-abused app IDs (PerfectData, eM Client, rclone, Supermailer, and others), layered over a scope-characteristic tier that catches bespoke apps by the permissions they request (Mail/EWS, Files/Sites, Directory, Application, offline_access), with admin/AllPrincipals consent escalating blast radius. Parses all three consent event shapes and resolves app identity across them.
This rule identifies non-Microsoft processes (based on file name, file company name, and process signer) that initiate network connections to known Microsoft authentication endpoints. This behavior is often indicative of an adversary-controlled process attempting to leverage cloud services or perform authentication-related activities outside of expected system or productivity software.
Detects non-interactive token refreshes occurring at anomalously consistent short intervals or from previously unseen IPs/devices, consistent with AiTM stolen session token replay used to maintain persistent access.
Detects anomalous access to the Azure Portal Single Page Application (SPA) by monitoring sign-in logs. The rule flags users accessing this specific application from multiple devices or over an unusually long time span (exceeding 24 hours), which may indicate session hijacking, token theft, or unauthorized access attempts via stolen session tokens.
Detects Microsoft 365 service principals using application-only (client-credentials) authentication to access the Microsoft Graph API, specifically targeting the calendarView endpoint of user mailboxes. This behavior matches the HOLLOWGRAPH attack technique, which leverages M365 calendars as a covert command-and-control (C2) channel.
This rule detects potentially malicious attempts to leverage different Microsoft cloud applications (FOCI family) in a short time frame following a conditional access block (AADSTS53003). The rule identifies scenarios where a single user account, within a 10-minute window, generates a 53003 failure while attempting to use multiple different client applications (such as Teams, O365, or Azure Portal), which may indicate an adversary attempting to bypass or probe security controls or testing token validity across multiple services.
This rule detects potentially malicious attempts to leverage different Microsoft cloud applications (FOCI family) in a short time frame following a conditional access block (AADSTS53003). The rule identifies scenarios where a single user account, within a 10-minute window, generates a 53003 failure while attempting to use multiple different client applications (such as Teams, O365, or Azure Portal), which may indicate an adversary attempting to bypass or probe security controls or testing token validity across multiple services.
This rule detects potential credential abuse by monitoring for a burst of GCP access or ID token generation requests by a single user across five or more distinct resource targets within a single project. Such behavior is often indicative of an adversary enumerating resources or performing reconnaissance to identify reachable services or systems after successfully assuming a principal's identity.
Detects OAuth2 token requests scoped to Google's secureidentity.action, used for passkey/security-domain-secret operations. Chrome's own sync/passkey process routinely requests this scope from the browser, so those requests (identified by a Chrome User-Agent) are excluded. Remaining matches indicate the token request did not originate from the legitimate Chrome browser process (e.g. a non-browser client, script, or tool crafting the request directly), which is anomalous and warrants investigation for possible passkey/security-domain-secret abuse or token reuse across devices.
Detects anomalous access to the Azure Portal Single Page Application (SPA) by monitoring sign-in logs. The rule flags users accessing this specific application from multiple devices or over an unusually long time span (exceeding 24 hours), which may indicate session hijacking, token theft, or unauthorized access attempts via stolen session tokens.
attackers are continuously abusing Device Code phishing, convincing victims to authenticate using the legitimate Microsoft login page. The victim completes the password and MFA correctly, but the resulting tokens are delivered to the attacker.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
Detects OAuth2 token requests scoped to Google's secureidentity.action, used for passkey/security-domain-secret operations. Chrome's own sync/passkey process routinely requests this scope from the browser, so those requests (identified by a Chrome User-Agent) are excluded. Remaining matches indicate the token request did not originate from the legitimate Chrome browser process (e.g. a non-browser client, script, or tool crafting the request directly), which is anomalous and warrants investigation for possible passkey/security-domain-secret abuse or token reuse across devices.
Page 15 of 22