Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
4,308 detections
Filters
Last updated
All Time
Detection languages
2,033
733
398
298
243
Contributors
1,048
740
503
372
239
Categories
20,443
11,831
5,875
5,151
4,864
4,308
Platforms
2,570
792
615
382
319
Products / Services
767
739
659
512
348
MITRE Techniques
2,347
917
847
814
635
CVEs
9
6
6
6
5
IDS Classtypes
81
66
44
14
14
IDS Protocols
136
79
11
7
4
Detects successful Entra ID sign-ins that exhibit characteristics of an Adversary-in-the-Middle (AiTM) session cookie hijack.
This activity is often associated with AiTM phishing kits like Tycoon2FA, where attackers replay stolen session cookies from unmanaged devices to bypass MFA.
This activity is often associated with AiTM phishing kits like Tycoon2FA, where attackers replay stolen session cookies from unmanaged devices to bypass MFA.
This rule detects potentially risky browser sign-ins from unmanaged devices, which aligns with account access patterns observed in AiTM (Adversary-in-the-Middle) phishing campaigns like those discussed in the Tycoon2FA report. It identifies sign-ins where the risk level is elevated (50 or 100), the client application used is a browser, and device trust type and device name information are empty, suggesting an unknown or untrusted device. This serves as a lead to investigate suspicious browser-based sign-ins that might indicate an AiTM compromise.
This detection identifies when a user clicks a URL in an email and shortly after, a risky sign-in is detected for the same user account. This pattern is indicative of a successful phishing attack, where a user is lured to a malicious site, enters their credentials, and the attacker uses those credentials or the session token to log in from a different location.
Azure Impossible Travel Detection
Cortex XDR
Detects an identity signing in from two or more distinct geolocations within a one-hour window in Azure, indicating potential impossible travel activity.
This query identifies users exhibiting unusual authentication behavior by combining Behavior Analytics with recent sign-in activity. It highlights high‑risk sign-ins originating from previously unseen IP addresses where the user agent or operating system has changed compared to historical patterns. The query enriches findings with historical sign-in context and Identity Info to support investigation of potentially compromised accounts.
This rule detects the presence of a specific browser credential extraction module associated with the StealC information stealer, as used in the FakeGit campaign. The detection is based on the module's SHA256 hash. The rule looks for the presence of this hash in DeviceFileEvents (file creation on disk) or DeviceImageLoadEvents (module loaded into a process). This indicates an attempt to steal credentials from web browsers or web session cookies.
This rule detects unusual access patterns to Azure resources where a single identity (user or service principal) accesses resources from multiple distinct IP addresses and/or geographic locations within a 7-day timeframe. This behavior can indicate compromised credentials, session hijacking, or an adversary attempting to evade detection by frequently changing their apparent origin.
Detects a single Azure identity accessing three or more distinct Azure resource types within a short time window. This behavior can indicate an attacker attempting to enumerate or pivot through an environment after compromising an identity.
This rule detects the presence of a specific browser credential extraction module associated with the StealC information stealer, as used in the FakeGit campaign. The detection is based on the module's SHA256 hash.
Detects non-browser processes accessing sensitive files within web browser profiles, such as credential stores (Login Data), cookies, or local storage databases (LevelDB). This behavior is indicative of credential theft and was observed in multiple modules of the StegaBin infostealer toolkit, which targeted browser-stored credentials and cryptocurrency wallet extensions.
Detects a high volume of network connections from a browser process to a high port on the local host (127.0.0.1 or ::1). This pattern can indicate a malicious website attempting to brute-force credentials for a local service, such as the OpenClaw AI agent, by abusing the browser's permission to establish WebSocket connections to localhost. The vulnerable service may not rate-limit these local connections, allowing for rapid password guessing.
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.
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.
Detects network connections from the Claude Code CLI ('claude' or 'claude.exe') to a destination other than the official 'api.anthropic.com' endpoint. This indicates that the 'ANTHROPIC_BASE_URL' environment variable has likely been overridden by a malicious '.claude/settings.json' configuration file in an attempt to intercept and exfiltrate API keys, as described in CVE-2026-21852.
Detects attempts to disable Windows Credential Guard by modifying the 'LsaCfgFlags' registry value. Credential Guard uses virtualization-based security to isolate secrets, and disabling it is a common defense evasion technique used by adversaries to access credentials for lateral movement.
This rule detects activity associated with a developer-targeting campaign leveraging malicious Next.js repositories. It identifies suspicious network connections to known Vercel staging domains and C2 IPs/ports/paths, as well as suspicious process execution patterns involving Node.js or VS Code related processes, and file events related to specific repository artifacts or sensitive file access by developer-adjacent processes. The detection logic covers network communication, process execution, and file system activities indicative of this specific threat.
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 the creation of an unusual lock file at `/usr/share/nano/.lock`. This specific path is used by a backdoored Go module (impersonating golang.org/x/crypto) to temporarily store harvested plaintext passwords before exfiltration. The rule specifically looks for file creation events at this highly specific path.
Page 155 of 206