Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
472 detections
Filters
Last updated
All Time
Detection languages
342
74
19
16
7
Contributors
91
90
77
52
35
Categories
182
148
81
66
60
Platforms
406
68
63
58
26
Products / Services
10,680
9,761
6,694
4,418
3,744
472
MITRE Techniques
180
121
96
78
71
CVEs
6
5
5
5
2
IDS Classtypes
2
1
1
1
1
IDS Protocols
6
Detects unauthorized processes attempting to access or interact with the dynamically generated Azure Arc identity token .key files. These files reside in a protected directory and are limited to SYSTEM-level ARC agent processes
(CVE-2026-26117)
(CVE-2026-26117)
This rule identifies potential network scanning or high-volume communication by detecting a large number of connections (50 or more) between a single source IP and a single destination IP within a 5-minute time window. It aggregates connection details such as total connections, sent bytes, and received bytes from the CommonSecurityLog.
This rule detects the presence of newly exposed risky web components, such as administrative panels or development tools, that have been discovered by Microsoft Defender External Attack Surface Management (EASM). The rule identifies components from a predefined list of 'risky_components' that have been seen for the first time within the last 7 days, indicating a recent exposure that could increase the attack surface.
Detects unauthorized processes attempting to access or interact with the dynamically generated Azure Arc identity token .key files. These files reside in a protected directory and are limited to SYSTEM-level ARC agent processes
Detects attempts to exploit CVE-2026-21962, a header spoofing vulnerability in Oracle WebLogic Server. The rule identifies suspicious requests where 'wl-proxy-client-ip' or 'x-forwarded-for' headers contain localhost/loopback addresses or command injection keywords, combined with URI paths related to 'weblogic' or 'proxy'.
This rule detects attempts to exploit CVE-2026-21962, a vulnerability in Oracle WebLogic Server. It specifically looks for requests to Application Gateway or Frontdoor logs that contain 'weblogic' in the URI, along with path traversal indicators ('..;', '%2e%2e') or specific proxy paths ('/_proxy/', '/wl_proxy/'), and keywords like 'proxyservlet' or 'bea_wls_internal'. These patterns are indicative of attempts to bypass security controls and access internal resources within a WebLogic environment.
Detects attempts by non-Azure Arc agent processes to access '.key' files within the Azure Arc Tokens directory. This activity could indicate an attempt to exploit CVE-2026-26117 or other credential access techniques targeting Azure Arc service principal tokens.
Detects the creation or manipulation of the specific archive file (tpcp.tar.gz) used by TeamPCP to bundle stolen credentials. This rule monitors command line activity, cloud process execution, and file system events for references to 'tpcp.tar.gz'.
This rule detects privilege escalation events associated with Azure Arc agent processes. It monitors for specific Windows Security Event IDs (4672, 4673, 4674, 4688) where the involved process or its parent is an Azure Arc agent process (himds.exe, azcmagent.exe, gc_worker.exe, gc_service.exe) and the SubjectUserName is not a standard system account. This helps identify potential attempts to elevate privileges using or targeting the Azure Arc agent.
Detects attempts by non-Azure Arc agent processes to access '.key' files within the Azure Arc Tokens directory. This activity could indicate an attempt to exploit CVE-2026-26117 or other credential access techniques targeting Azure Arc service principal tokens.
Detects command line executions from non-standard applications attempting to query the local Azure Arc metadata endpoints (ports 40341/40342), which may indicate an attacker enumerating or exploiting the HIMDS token service (CVE-2026-26117).
KQL Query
This query identifies potential post-exploitation behavior on Linux systems by monitoring for clusters of discovery and enumeration commands. Instead of alerting on single, potentially benign commands, it utilizes a behavioral scoring engine that categorizes activities such as credential hunting, privilege escalation, and network scanning.
By implementing extensive allowlists for common administrative tools (e.g., Ansible, Zabbix, Monitoring Agents) and requiring a minimum threshold of unique activity categories, the query effectively filters out "noise." It calculates a dynamic Risk Score and assigns a Severity level based on the criticality of the commands and the speed of execution (Burst Detection), making it a highly reliable tool for SOC analysts to detect active hands-on-keyboard attacks.
By implementing extensive allowlists for common administrative tools (e.g., Ansible, Zabbix, Monitoring Agents) and requiring a minimum threshold of unique activity categories, the query effectively filters out "noise." It calculates a dynamic Risk Score and assigns a Severity level based on the criticality of the commands and the speed of execution (Burst Detection), making it a highly reliable tool for SOC analysts to detect active hands-on-keyboard attacks.
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 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.
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 the use of the GNU Debugger (GDB) to dump memory from a live process. This technique is used by frameworks like ShadowHS to extract credentials and other secrets directly from memory, bypassing file-based security controls.
Detects successful POST requests to better-auth API key creation or update endpoints that appear to be unauthenticated. This pattern is indicative of exploitation of CVE-2025-61928, where an attacker can create or modify API keys for any user without a valid session.
This rule detects suspicious enumeration of Azure Blob, File, Table, Queue, or DFS storage accounts by internal users. It identifies devices making network connections to public Azure storage URLs using potentially suspicious processes (e.g., PowerShell, Python, AzCopy, curl, wget, WinSCP, FileZilla, Storage Explorer). The rule then analyzes the distinct storage accounts accessed and uses a Jaccard index to identify unusual naming conventions among the accessed storage accounts, potentially indicating an insider attempting to discover or exfiltrate data from unfamiliar storage resources.
This rule identifies user accounts that have one or more roles assigned to them. It queries the 'IdentityInfo' table, filters for entries where the 'AssignedRoles' field is not empty, and then projects relevant account details such as UPN, display name, assigned roles, and object ID. Finally, it summarizes the data to retrieve the most recent record for each unique account object ID.
Page 17 of 23