Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,632 detections
Filters
Last updated
All Time
Detection languages
1,056
161
128
83
72
Contributors
427
386
258
93
93
Categories
923
331
312
289
237
Platforms
768
404
356
303
295
Products / Services
820
308
216
159
157
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
1,632
CVEs
3
2
1
1
1
IDS Classtypes
108
26
18
5
3
IDS Protocols
100
33
20
3
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.
This rule detects inbound emails containing a URL that initiates an OAuth 2.0 authorization flow for Microsoft Online, specifically looking for the 'prompt=none' parameter. This combination can be indicative of consent phishing attempts where an attacker tries to trick users into granting permissions to a malicious application without explicit interaction, often by pre-approving the prompt. The rule filters for inbound emails that were not blocked, suggesting they reached the user's inbox.
This rule detects suspicious sign-in links that exhibit characteristics of OAuth redirect abuse. Specifically, it looks for URLs that contain "oauth2", "prompt=none", and "scope=invalid". This pattern suggests an attempt to use a trusted sign-in service to redirect users to a malicious page, potentially for phishing or malware delivery, by manipulating OAuth parameters.
Detects OAuth authorization requests to Microsoft or Google that use the 'prompt=none' parameter in combination with an intentionally invalid or missing 'scope'. This combination is used to force a silent error redirect to an attacker-controlled URI, bypassing some security filters.
This query provides a 360-degree view of a phishing campaign's impact. Starting from a reported email's indicators (sender, subject), it finds all similar emails and correlates them with user actions like URL clicks, attachment interactions on endpoints, replies, and if the emails were zapped by Microsoft. This allows an analyst to quickly scope an incident and determine the extent of compromise.
This rule detects emails containing URLs that initiate OAuth 2.0 authorization flows for Microsoft or Google, and where the URL contains a known malicious OAuth ID. This is indicative of an OAuth phishing attempt, where attackers try to trick users into granting access to malicious applications.
Detects a file download where the referrer URL is a Microsoft Entra ID OAuth endpoint returning an error. This pattern is indicative of an attacker abusing OAuth's error-handling redirection mechanism to lead a user to a malicious payload on an attacker-controlled domain.
Detects URL click events or browser launches where the URL targets Microsoft or Google OAuth endpoints and contains the combination of 'prompt=none' and 'scope=invalid'. This specific combination is used by attackers to force a silent error redirect to a malicious URI.
Detects network connections to known command-and-control (C2) and distribution domains associated with the Coruna exploit kit campaigns. This includes the domain used in the Ukrainian campaign by UNC6353 and the larger set from the financially motivated UNC6691 group.
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.
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 activity related to the EmEditor watering hole attack, specifically looking for PowerShell execution making requests to known malicious lookalike domains and network connections to the associated infrastructure. A match suggests a potential download of malicious code during what appeared to be a legitimate install or update. Investigation should focus on identifying the host, user, source of activity, and legitimacy of the install source, followed by evidence preservation, credential reset, and a search for follow-up malicious activity.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
This rule detects phishing attempts related to a Booking.com campaign. It identifies suspicious URLs containing 'op_token' or 'tpo_token' parameters, often combined with paths like 'complaint' or 'reserv', on non-Booking.com domains. It specifically looks for punycode domains (e.g., 'xn--*'), lookalike domains (e.g., '*booklng*', '*mgmnt*', '*portal*'), and specific high-signal punycode domains identified in reports. The rule also includes a pattern for partner kit redirect URLs with 'tpo_token' on 'booklng' subdomains. Additionally, it suggests looking for specific email patterns from Gmail senders with subjects like 'Automatic reply', 'Availability', or 'Reservation' that contain embedded URLs matching 'complaint?op_token='.
This rule detects a potential quishing (QR code phishing) attack followed by a suspicious successful sign-in to Entra ID (formerly Azure AD). It correlates URL click events or device network events containing deep link indicators (like 'tg://login', 'wa.me/settings/linked_devices', 'signal://', 'line://') or '.apk' file downloads with a successful Entra ID sign-in by the same user within a 30-minute window. This behavior suggests a user may have scanned a malicious QR code, clicked a phishing link, or downloaded a malicious application, leading to a successful but potentially compromised authentication.
This rule detects various indicators associated with the Booking.com phishing campaign targeting hotels and customers. It identifies suspicious web requests to non-Booking.com domains containing 'op_token' and 'complaint' or 'reservation' keywords, especially when combined with punycode, 'booklng' typos, or management-related subdomains. It also looks for partner kit patterns involving 'sign-in/?tpo_token=' and 'booklng' in URLs. Additionally, it identifies suspicious emails from newly generated Gmail accounts with specific subjects ('Automatic reply', 'Availability', 'Reservation') containing 'op_token' in the subject or body.
Detects Booking.com partner phishing lures described by Bridewell by identifying complaint/reserv URLs with op_token hosted on punycode or lookalike domains, plus the booklng sign-in tpo_token pattern.
This rule detects network connections or email URLs that match a list of known Indicators of Compromise (IOCs) associated with Signal-targeted phishing infrastructure and explicit phishing destination domains. These IOCs were identified in Unit 42's research on QR code attack vectors. The rule queries email URL information, URL click events, device network events, and common security logs (proxy/firewall/WAF) to identify activity related to these malicious domains.
Detects Booking.com partner phishing kit artifacts described by Bridewell (op_token complaint lures, tpo_token sign-in flow, booklng subdomain, punycode homograph infra).
Page 64 of 78