Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
4,311 detections
Filters
Last updated
All Time
Detection languages
2,035
733
398
299
243
Contributors
1,048
740
503
372
239
Categories
20,456
11,839
5,876
5,155
4,865
4,311
Platforms
2,572
793
615
382
319
Products / Services
767
740
659
513
348
MITRE Techniques
2,350
917
848
814
635
CVEs
9
6
6
6
5
IDS Classtypes
81
66
44
14
14
IDS Protocols
136
79
11
7
4
This rule detects potential brute force or credential stuffing attacks against Azure AD by identifying multiple failed sign-in attempts followed by a successful sign-in from the same user and IP address within a short time frame (1 minute). It specifically looks for scenarios where the successful sign-in occurs after the failed attempts and involves different applications, excluding common Office 365 services to reduce noise.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
Detects HTTP POST requests to "/api/get_challenge" or "/api/get_credentials" on port 5000. This is the initial communication pattern of the TunnesshClient backdoor, a component of the BoryptGrab campaign, to retrieve SSH credentials from its C2 server before establishing a reverse SSH tunnel.
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.
Page 155 of 206