Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,064 detections
Filters
Last updated
All Time
Detection languages
597
173
103
71
51
Contributors
184
155
139
90
73
Categories
20,443
11,831
5,875
5,151
4,864
1,064
Platforms
575
266
228
223
118
Products / Services
498
220
130
118
86
MITRE Techniques
488
451
363
349
341
CVEs
10
5
4
3
2
IDS Classtypes
34
3
2
2
1
IDS Protocols
29
9
1
This rule detects suspicious activity where a new device is registered after a user browse or click on a Microsoft device login page. This could indicate an adversary attempting to register a new device to bypass multi-factor authentication or establish persistence.
This rule detects network connection events and Entra ID sign-in events originating from Iran. It aggregates these events hourly to identify potential suspicious activity from a geo-restricted or high-risk country.
This rule detects potential GraphRunner activity in Azure environments by identifying suspicious authentication attempts to Microsoft Graph using the 'deviceCode' authentication protocol, combined with specific user agent strings associated with the GraphRunner tool. It categorizes detections into high confidence (both device code and suspicious user agent), device code authentication only, or suspicious user agent only.
This rule detects impossible travel scenarios for user sign-ins that occur shortly after a device associated with that user has been wiped, retired, or deleted. It calculates the speed between consecutive sign-in locations for the same user and flags any travel exceeding 900 km/h, indicating a potential compromise or fraudulent activity.
This rule correlates an email URL click with a subsequent risky sign-in from the same user within a short timeframe (1 hour). This is a strong indicator of a successful Adversary-in-the-Middle (AiTM) phishing attack, such as those conducted with the Tycoon2FA kit, where a user is tricked into authenticating through a malicious site, allowing the attacker to capture their session.
This rule detects attempts to authenticate to SSH using GSSAPI (Generic Security Service Application Programming Interface). While GSSAPI can be used for legitimate authentication, its presence in logs might indicate an attacker attempting to use alternative authentication methods, potentially for lateral movement or privilege escalation, especially if unexpected in the environment.
This rule detects sign-in attempts originating from IP addresses associated with Starlink (Space Exploration Technologies) autonomous system. This could indicate an unusual access vector, especially if Starlink is not a common or expected internet service provider for the organization's users.
Correlates an email URL click with a subsequent risky sign-in from the same user within a short timeframe. This pattern is a strong indicator of a successful Adversary-in-the-Middle (AiTM) phishing attack, such as those conducted with the Tycoon2FA kit, where a user is tricked into authenticating through a malicious site, allowing the attacker to capture their session.
Azure Blob Anonymous Access
Cortex XDR
Detects unauthenticated or anonymous access attempts to Azure Blob Storage. This rule identifies successful operations where the identity is explicitly listed as 'anonymous', indicating potential misconfigurations or unauthorized access to sensitive data.
Detects when the same AWS IAM user ARN performs actions from more than one distinct source IP within a 1-hour window. Indicative of session hijacking, credential sharing, or AiTM compromise where attacker egress IP differs from the victim's IP. AssumedRole is excluded by default due to high noise from automation — add back with tuned ARN exclusions if needed.
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 rule detects network connections and user sign-ins originating from IP addresses identified as belonging to Iran. It also identifies sign-ins where the reported country is Iran, but the IP address is not found within the provided Iranian IP list, which could indicate IP geolocation discrepancies or obfuscation attempts.
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 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 suspicious sign-in activities by user in a specified timeframe
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.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google NetNTLMv1 Deprecation RainbowTables. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: a Windows logon event that explicitly shows LM or NTLMv1 as the package used. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/net-ntlmv1-deprecation-rainbow-tables) to document where the indicator came from and to support incident notes and reporting.
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 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.
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.
Page 34 of 51