Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,735 detections
Filters
Last updated
All Time
Detection languages
1,216
144
98
80
59
Contributors
496
324
298
171
55
Categories
20,437
11,828
5,871
5,150
4,864
1,735
Platforms
1,163
328
260
244
163
Products / Services
1,244
200
166
146
138
MITRE Techniques
983
923
765
247
245
CVEs
2
1
IDS Classtypes
68
33
19
10
8
IDS Protocols
90
24
15
15
Detects potential device code phishing activity by identifying a successful device code authentication event followed shortly (within 10 minutes) by an interactive or API sign-in from the same user utilizing a Python-requests user agent, which is commonly associated with adversary-in-the-middle phishing kits.
Detects inbound emails containing keywords associated with known ransomware extortion tactics (e.g., mention of specific ransomware names, data leaks, and payment demands). The rule filters for inbound traffic to identify external threats while excluding potential internal-generated traffic.
This rule monitors network connections, DNS resolutions, and email URLs to detect traffic communicating with a known adversary-in-the-middle (AiTM) phishing infrastructure panel. By correlating security logs, DNS events, and email URL data against this specific indicator of compromise, it identifies potential interaction with phishing sites designed to capture credentials or session tokens.
Detects interaction with known infrastructure associated with the PREY-0058 campaign, which utilizes Adversary-in-the-Middle (AiTM) phishing lures mimicking passkey or MFA registration pages to target Microsoft 365 and other SaaS applications.
This rule detects email activity involving DocuSign-themed messages that contain attachments and also coincide with URL click events that redirect users to Microsoft-related login portals (e.g., login.microsoftonline.com or teams.microsoft.com) containing 'redirect' or 'redirect_uri' parameters. This behavior is indicative of a phishing attempt designed to capture credentials or perform OAuth consent phishing by mimicking legitimate document-signing workflows.
Detects DNS queries, TLS SNI, and HTTP Host header traffic associated with the IronToll phishing campaign. The rule specifically monitors for government-impersonating domains and lookalike domains utilizing various non-standard top-level domains (TLDs).
Detects DNS queries, TLS SNI, and HTTP Host header traffic associated with the IronToll phishing campaign. The rule specifically monitors for government-impersonating domains and lookalike domains utilizing various non-standard top-level domains (TLDs).
Detects the Iron Man System phishing kit via its HTTP fingerprint: a request-header rule (ETag/Server/Via combo) checked on the external server's response, and three request-side rules checking for the kit's hashed asset paths and favicon when an internal host requests them from an external site. Fixed a direction bug on the three request-side rules that had source/destination reversed (they previously required an external host to request the path from an internal server, which would rarely if ever fire).
Detects active phishing threat-intelligence indicators whose domain name uses one of the disposable TLDs observed across IronToll's 73+ rotating lookalike domains (.cfd, .sbs, .icu, .buzz, etc.). Scoped to the structured ThreatType classification only — dropped the free-text 'Description has phishing' fallback, since KQL's 'has' is a substring/token match with no negation awareness (e.g. a description stating an indicator is 'not related to phishing' would still match), which could pull in indicators unrelated to actual phishing activity.
Detects emails delivering links to IronToll government-impersonation traffic-fine/payment portals (Egyptian and Moroccan justice-ministry lures), correlated with Safe Links click-through telemetry for the same URLs.
This rule identifies emails containing URLs associated with known suspicious or malicious domains (secboxes.com, msbenefit.com, attcdn.com, brianwilli.com). It filters for instances where the sender's domain is not one of the identified suspicious domains to reduce noise from potential email spoofing or miscategorized communications, flagging potential phishing attempts.
Detects the early-stage HTTP beaconing behavior of the CRPx0 ClickFix social engineering campaign. This rule monitors for specific request patterns to 'relay.php' that include session identifiers and indicators of the lure, such as 'WINUPDATE_TRACK' or 'CAPTCHA_WEB'. This signal represents the initial interaction with the malicious infrastructure before the victim is coerced into running commands.
This rule correlates successful Microsoft 365 sign-in events with preceding network events involving identified NovaCookies AiTM phishing infrastructure (specifically targeting .vu domains or specific URL patterns). It triggers when a user successfully authenticates using MFA shortly after accessing a known phishing link, which is a strong indicator of an active AiTM session hijacking attempt.
Detects anomalous authentication behavior indicative of an Adversary-in-the-Middle (AiTM) phishing kit. The rule identifies multiple password submission attempts (failures) followed by a successful authentication within a short period, consistent with an attacker testing multiple harvested credentials against an active session.
Detects incoming emails that impersonate DocuSign notifications, specifically looking for typical phishing lures involving 'Remittance Advice' and a call-to-action to 'Tap here to view document'. This rule identifies emails using common social engineering tactics to harvest credentials or distribute malware via fake document links.
This rule identifies potential phishing emails that impersonate OneDrive sharing notifications. It correlates email messages containing keywords typically associated with document sharing (e.g., 'OneDrive', 'shared', 'file') with subsequent user URL clicks. Crucially, the rule filters for clicks to domains that are not explicitly related to legitimate OneDrive, SharePoint, or 1drv.ms hosting, indicating a potential attempt to lure users to a malicious third-party site under the guise of file sharing.
This rule monitors for email events where the email is flagged for suspicious properties (SPF/DKIM/DMARC failure, threat categorization) and includes potentially malicious attachments or URLs. It then correlates these suspicious emails with subsequent process execution events on the recipient's endpoint within a 30-minute window, identifying a potential successful execution of a phishing payload.
Detects the RejectDirectSend bypass (null SMTP envelope sender + internal-domain spoof). Tightened to require Microsoft's composite auth verdict OR all of SPF/DKIM/DMARC failing (vs. any one), excludes known-approved Direct Send relay IPs, and excludes likely-legitimate bulk/newsletter traffic via BulkComplaintLevel.
Detects Direct Send bypass (null envelope + internal-domain spoof) using a file/document-sharing lure aimed at leadership. Tightened: added inbound-direction and auth-failure requirements (was previously missing any authentication check, so legitimate SharePoint/OneDrive-style sharing notifications from real internal senders could have matched), delivered-only filter, and case-insensitive recipient/job-title join.
Detects Direct Send spearphishing impersonating internal roles (IT/Finance/Procurement) with business-themed lures targeting leadership/finance titles. Rewritten: removed a non-functional sender/recipient substring check and a broken EmailPostDeliveryEvents join that made the rule rarely fire; anchored detection to the actual Direct Send signature (null envelope + domain match) and a direct IdentityInfo join; standardized auth-failure parsing to match the other rules in this set.
Detects SCL-9 (high-confidence phishing/spam) messages that still reach an inbox, indicating an allow-list or transport-rule override, and enriches with any recent tenant mail-flow admin changes. Rewritten: removed a no-op self-join on EmailEvents and a broken exact-match join against CloudAppEvents' raw audit blob (was comparing a sender address against a whole JSON record and would never match); now excludes messages later auto-remediated (e.g. ZAP-quarantined) via the native LatestDeliveryLocation field, and correlates admin rule/allow-list changes via substring match over a cross join.
Page 31 of 83