Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,868 detections
Filters
Last updated
All Time
Detection languages
2,527
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,092
793
576
Platforms
39,960
7,270
6,537
3,868
3,651
Products / Services
1,757
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 the consent or addition of an OAuth application that may be impersonating a legitimate, well-known brand. The logic flags applications whose names mimic major brands (e.g., Adobe, Microsoft, DocuSign) and use a reply URL hosted on a shared or free platform, a common tactic in consent phishing campaigns.
Identifies consent grants to OAuth applications with Application IDs matching known malicious campaigns. The IOCs are sourced from Wiz Research on campaigns from 2019-2025 involving brand impersonation and consent phishing.
Detects configuration changes on firewall devices via CommonSecurityLog.
Specifically looks for CONFIG activity that is not an audit-commit,
indicating an actual configuration change was made rather than a
read-only audit operation.
Note: Field aliasing (Client, Administrator, Host_IP, Command, Result,
Configuration_Path, Before_Change, After_Change) via extend,
fixed date window via datetime_local_to_utc, and project-reorder
are handled natively in KQL post-conversion. See third item of the
reference. Original query was scoped to a fixed date window, which is
(2026-02-09 to 2026-02-10 PST) suggesting threat hunting intent.
However, it's worthnoting that Sigma version uses a rolling 24h window
for continuous detection. This is the detection version of my KQL script.
Specifically looks for CONFIG activity that is not an audit-commit,
indicating an actual configuration change was made rather than a
read-only audit operation.
Note: Field aliasing (Client, Administrator, Host_IP, Command, Result,
Configuration_Path, Before_Change, After_Change) via extend,
fixed date window via datetime_local_to_utc, and project-reorder
are handled natively in KQL post-conversion. See third item of the
reference. Original query was scoped to a fixed date window, which is
(2026-02-09 to 2026-02-10 PST) suggesting threat hunting intent.
However, it's worthnoting that Sigma version uses a rolling 24h window
for continuous detection. This is the detection version of my KQL script.
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.
Page 141 of 185