Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,142 detections
Filters
Last updated
All Time
Detection languages
2,293
246
196
179
104
Contributors
738
670
569
284
148
Categories
1,164
747
693
623
440
Platforms
39,960
7,270
6,537
3,867
3,651
3,142
Products / Services
2,850
742
269
187
182
MITRE Techniques
872
857
778
768
738
CVEs
13
5
2
1
1
IDS Classtypes
3
2
2
2
1
IDS Protocols
9
1
1
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.
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.
KQL Query from file: OauthMSPhish Detection
This rule detects potential phishing attempts targeting Docusign users. It identifies emails containing URLs or network connections to specific domains (page-docusign-[a-z0-9]+\.workers\.dev) which are commonly used in phishing campaigns to mimic legitimate Docusign login pages or related services. The use of 'workers.dev' subdomains often indicates malicious infrastructure.
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 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.
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.
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 the legitimate 'steam_monitor.exe' loading 'crashhandler.dll' from a non-standard directory like ProgramData. This side-loading technique was observed in campaigns delivering Korplug/GreedyRobin malware, often following initial access via OAuth redirection abuse.
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.
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 detects instances where Microsoft Copilot accesses external resources, specifically identifying events where 'XPIADetected' is true. This indicates Copilot interacting with resources outside its immediate environment, which could be a security concern if the accessed resources are sensitive or untrusted.
This rule detects successful sign-ins to Microsoft 365 services that occur via legacy authentication protocols. These protocols (e.g., Exchange ActiveSync, IMAP4, POP3, SMTP AUTH) do not support modern authentication methods like Multi-Factor Authentication (MFA) or Conditional Access policies, making them a potential bypass vector for adversaries who have compromised user credentials. The rule identifies the user, the specific legacy client application used, and provides details on the source IP address and country.
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 Microsoft Teams chat or call activity initiated by external users whose domains are not present in a pre-defined whitelist. It specifically looks for 'ChatCreated' or 'CallParticipantDetail' actions from external users and filters out activity from known, whitelisted external domains. This can help identify potentially unauthorized or suspicious communication with external entities.
Page 116 of 150