Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,865 detections
Filters
Last updated
All Time
Detection languages
2,524
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
792
575
Platforms
39,932
7,263
6,535
3,865
3,643
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 detection identifies instances where a user grants consent to an OAuth application that has very low prevalence within the tenant and requests high-risk permissions. This pattern is a strong indicator of a targeted consent phishing attack, as malicious apps often target a small number of users to gain initial access.
Detects potential password spray activity by identifying a single IP address generating failed sign-ins across multiple distinct user accounts within a short window. This rule specifically looks for '50126' result type, indicating an invalid username or password, from a single IP address attempting to authenticate against at least 5 distinct user accounts within a 10-minute window.
With OAuth 2.0 Device Code Flow phishing campaigns actively targeting M365 environments in financial services and beyond, I built a cross-phase KQL detection rule that moves beyond the obvious deviceCode protocol filter — because the real damage happens in tables most hunts never look at.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
This rule detects instances where a 'jailbreak' attempt is identified within a Microsoft Copilot interaction. It specifically looks for CopilotInteraction events where the 'JailbreakDetected' flag is set to true in the message data.
This rule detects instances where Microsoft Copilot accesses external resources, specifically identifying events where 'XPIADetected' is true. This indicates Copilot interacting with resources outside its immediate environment, which could be a security concern if the accessed resources are sensitive or untrusted.
This detection identifies JSON Web Tokens (JWTs) with an expiration time ("exp" claim) that is set unusually far in the future. Attackers may forge tokens with long lifespans to maintain persistent access after an initial compromise.
Detects attempts to inject path traversal or SQL-like syntax into the 'kid' (Key ID) parameter of a JSON Web Token (JWT) header. This may indicate an attempt to manipulate the server's key retrieval process to force signature validation with an improper key, potentially leading to an authentication bypass.
This query detect when a AD user end up becoming Risky for some reason.
Detects potential JSON Web Token (JWT) algorithm confusion attacks. This occurs when an attacker sends a token signed with a symmetric algorithm (e.g., HS256) to a server expecting an asymmetric one (e.g., RS256). If the server is misconfigured, it may use its public key as the HMAC secret, allowing the attacker to forge valid tokens. The rule specifically looks for JWTs with symmetric HMAC-based algorithms (HS256, HS384, HS512) being sent to applications configured to exclusively use asymmetric key algorithms.
Detects critical permission changes in Azure DevOps, specifically focusing on 'allow' changes to sensitive permissions like 'Edit build pipeline', 'Manage permissions', 'Queue builds', 'Administer build', and 'Bypass policies when completing' within key namespaces such as 'Git Repositories', 'ReleaseManagement', 'PipelinesPrivileges', and 'Project-level Permissions'. This rule aims to identify potential privilege escalation or unauthorized access attempts within Azure DevOps environments.
This rule detects suspicious code search queries within Azure DevOps audit logs that may indicate an adversary is attempting to find sensitive information such as passwords, API keys, tokens, or private keys. It specifically looks for keywords like 'password', 'secret', 'token', 'apikey', 'api_key', 'connectionstring', 'connstring', 'credential', 'private key', and 'BEGIN RSA PRIVATE KEY' in code search queries.
Detects actions performed on RiskyUsers in Azure Entra ID by unauthorized
members. Specifically looks for CA or GA accounts performing IdentityProtection
actions where the admin is not from the Information Security department.
Note: String parsing (AdminLocalPart, AdminLastName, StrippedAdminName),
fallback identity matching, summarize arg_max, and project are handled
natively in KQL post-conversion.
members. Specifically looks for CA or GA accounts performing IdentityProtection
actions where the admin is not from the Information Security department.
Note: String parsing (AdminLocalPart, AdminLastName, StrippedAdminName),
fallback identity matching, summarize arg_max, and project are handled
natively in KQL post-conversion.
This rule detects Azure DevOps activities originating from new or rarely seen IP addresses outside of defined business hours. It establishes a baseline of historical IP addresses and flags activities from IPs that have been seen for fewer than a specified number of days, indicating potentially suspicious access.
This rule detects when public or anonymous access is enabled for an Azure Storage Account. This configuration change can lead to potential data exposure, as it allows unauthenticated users to access blobs within the storage account. The rule specifically looks for 'STORAGEACCOUNTS/WRITE' or 'STORAGEACCOUNTS/BLOBSERVICES/WRITE' operations that successfully modify the storage account configuration to allow public access.
Detects when a user grants consent to an application that has not been seen in the environment before. This rule baselines known applications over a 30-day period and alerts on any new application consent grants or service principal additions within the last day that are not part of the baseline or an explicit allow list.
Detects potential JSON Web Token (JWT) authentication bypass attempts where the algorithm in the token header is explicitly set to "none". A vulnerable server might skip signature validation for such tokens, allowing an attacker to forge arbitrary claims and potentially gain unauthorized access or escalate privileges.
This KQL script detects if end user interacted with a PDF attachment in a potential phishing/BEC incident
This rule detects 'impossible travel' scenarios where a user successfully signs in from two geographically distant locations within an implausibly short time frame (less than 120 minutes). It specifically looks for sign-ins where the country of origin changes between consecutive successful login events for the same user.
This query detects network traffic and file events associated with the "AiFrame" malicious browser extension campaign. These extensions pose as AI assistants but exfiltrate user data via remotely controlled iframes.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
This rule detects a high volume of Azure resource deletions by a single user within a short timeframe (30 minutes). This behavior is indicative of a destructive attack or wiper activity, where an adversary attempts to delete critical cloud infrastructure to disrupt operations or cause data loss. The rule specifically looks for 'delete' operations that were successful and counts them per caller and IP address, triggering an alert if the count exceeds a defined threshold.
Page 141 of 185