Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,866 detections
Filters
Last updated
All Time
Detection languages
2,525
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
792
575
Platforms
39,936
7,266
6,537
3,866
3,647
Products / Services
1,755
1,449
1,121
438
406
MITRE Techniques
1,889
1,392
913
814
727
CVEs
12
5
4
3
2
IDS Classtypes
10
7
6
6
5
IDS Protocols
37
2
1
This rule detects when a user or administrator grants consent to an Azure AD or Office 365 application for permissions that provide significant access to mail, files, contacts, or directory data. This activity is a common vector for illicit OAuth consent attacks, where adversaries gain persistent access to sensitive data without requiring direct user credentials.
Identifies anomalous session cookie replays where a user token is suddenly used from an entirely different geographic location or ISP within minutes. This rule specifically looks for non-interactive sign-ins (indicating session cookie reuse) where a single AccountUpn shows sign-ins from at least two different IP addresses and two different geographic locations within a 10-minute window.
Detects attempts to exploit the Zerologon vulnerability (CVE-2020-1472) for privilege escalation and domain compromise. This rule monitors for a high volume of Netlogon secure channel failures (Event ID 5805), machine account password resets to a zeroed/blank state (Event ID 4742 for computer accounts with specific password indicators), anomalous Netlogon service restarts (Event ID 7036), and Azure AD Identity Protection risk events referencing Zerologon or Netlogon anomalies. These indicators collectively suggest an active exploitation attempt of the Zerologon vulnerability.
Detects execution of Azure Automation runbook jobs by managed identities that have recently been assigned high-privilege roles (Owner, Contributor, or User Access Administrator). This behavior is indicative of potential privilege escalation or abuse of existing high-privilege identities to execute unauthorized automation tasks.
This rule detects potentially compromised accounts by correlating successful device code authentication events that exhibit anomalous characteristics (such as first-time usage, high/medium risk scores, or non-compliant/unmanaged device status) with highly sensitive Azure AD/Graph API administrative operations occurring within 30 minutes of the sign-in.
Detects execution of Azure Automation runbook jobs by managed identities that have recently been assigned high-privilege roles (Owner, Contributor, or User Access Administrator). This behavior is indicative of potential privilege escalation or abuse of existing high-privilege identities to execute unauthorized automation tasks.
Detects MFA fatigue attacks where a user receives more than 10 MFA push denials within a 10-minute window, followed immediately by a successful authentication from a different IP address. This behavior is indicative of an adversary bombarding a user with push notifications until they are approved, followed by account takeover.
This rule detects potentially compromised accounts by correlating successful device code authentication events that exhibit anomalous characteristics (such as first-time usage, high/medium risk scores, or non-compliant/unmanaged device status) with highly sensitive Azure AD/Graph API administrative operations occurring within 30 minutes of the sign-in.
Detects Entra ID guest (B2B) users performing a sign-in from a previously unseen IP address or country (observed over the last 30 days), followed within a 4-hour window by sensitive file operations in SharePoint, OneDrive, or Teams (e.g., file downloads, exports, or sensitivity label changes). This pattern is indicative of potential account takeover or unauthorized access to sensitive corporate data.
This rule detects the addition of new certificates or client secrets to Azure App Registrations or Service Principals by a user who is not recorded as an owner of that application in the last 90 days. This behavior is a common persistence and privilege escalation technique used by attackers to maintain access to cloud environments.
Detects successful sign-ins using legacy authentication protocols (e.g., IMAP, POP3, SMTP AUTH, ROPC) for user accounts that are in scope of a Conditional Access policy requiring multi-factor authentication (MFA). Legacy protocols do not support modern authentication flows, effectively bypassing configured MFA requirements and increasing the risk of credential-based attacks.
Detects a sequence of events within a 30-minute window for a single user, specifically capturing MFA configuration changes (reset/enrollment), authentication, and device registration, occurring outside of typical business hours (20:00 - 06:00). This behavioral pattern is often indicative of an adversary establishing persistence or account takeover after gaining access to a valid account.
This rule detects potentially malicious OAuth activity in Azure AD where a user performs a device code authentication flow, followed by a refresh token request from a different, anomalous IP address or geographical location. This behavior is indicative of an attacker who has successfully phished a device code from a user and is now attempting to maintain persistent access to the account via a stolen refresh token.
Detects sign-in events where Conditional Access was not applied for Microsoft Graph access using low-privileged client IDs known to trigger hidden CA exclusions. Tokens issued with only single-factor authentication to Graph indicate exploitation of the hidden scope exclusion behavior introduced when any exclusion is added to an 'All resources' CA policy (CVE-2025-0309). Additionally, this rule identifies audit log events for Conditional Access policy modifications that add exclusions.
Detects Microsoft Entra ID (formerly Azure AD) sign-in logs where a single user account authenticates from two different countries within a 10-minute window, which is indicative of potential account compromise or credential sharing.
Detects inbound emails originating from 'azure-noreply@microsoft.com' with subjects that typically indicate financial transactions (e.g., 'Invoice Paid', 'Payment Reference') or system alerts (e.g., 'MemorySpike', 'DiskFull'). This pattern could be indicative of phishing attempts leveraging a seemingly legitimate sender to trick recipients.
Flags Intune assignments to “All Devices” or “All Users,” which attackers may abuse for mass deployment.
This rule detects suspicious Azure AD sign-in activity where a user successfully signs in from multiple unusual cities within a 24-hour period. It specifically looks for sign-ins that are not from a trusted network and are not from a compliant device, aggregating successful sign-ins by UserPrincipalName and IpAddress, and flagging if there are 5 or more distinct cities.
Detects suspicious activity involving multiple password resets for different users initiated by a single user within a one-hour timeframe in Azure AD. This could indicate an attacker attempting to gain control over multiple accounts.
This rule detects potential Server-Side Request Forgery (SSRF) probing attempts against web applications where unauthenticated requests contain a URL parameter used to request external or internal resources. It flags high-volume probing activity and correlates the source IP with concurrent anomalous Azure Active Directory (Azure AD) sign-in events from the same source, such as failed logins or high-risk sign-in attempts.
This rule detects potential Server-Side Request Forgery (SSRF) activity by identifying suspicious patterns in web application access logs. It monitors for high-diversity parameter values within URL query strings (e.g., 'url', 'path', 'target', 'file', 'src', 'dest', 'uri', 'redirect') that deviate from normal behavior, combined with indicators like mixed HTTP response codes (2xx and 4xx) and high request volumes from a single source IP to a specific request path. Such behavior is characteristic of an adversary iteratively probing or brute-forcing internal paths or resources via an application-level vulnerability.
Page 107 of 185