Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,593 detections
Filters
Last updated
All Time
Detection languages
1,146
134
65
63
53
Contributors
368
274
239
197
70
Categories
980
373
271
227
139
Platforms
866
505
164
158
149
Products / Services
944
297
133
113
108
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
1,593
CVEs
2
1
1
1
1
IDS Classtypes
18
5
4
1
1
IDS Protocols
15
8
4
3
This rule detects processes where an executable file (.exe) attempts to masquerade as a common document, image, or archive file type by including extensions like .pdf, .doc, .zip, .jpg, etc., within its filename, followed by the .exe extension. It specifically excludes executables originating from Microsoft Office root directories to reduce false positives.
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 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.
This rule is based on a phishing method that abuses normal sign-in links instead of relying on an obviously fake website at the start. The trick works by sending a person to a real sign-in service with settings that force an error and then pass the browser along to the attacker’s page. The rule stays narrow by looking for both the hidden sign-in setting and the clearly bad scope value together. That matters because silent sign-in by itself can appear in normal environments, but the bad scope value changes the story and makes the pattern much more suspicious. In plain language, this rule is trying to spot a link that pretends to be a normal sign-in step but is really being used as a doorway to a phishing or malware page after the trusted service does the redirect. Keeping both parts together helps the rule stay tied to the abusive redirect trick instead of ordinary sign-in traffic.
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.
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.
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 indicators associated with the RenEngine campaign, which involves the deployment of HijackLoader, Lumma Stealer, and ACR Stealer. Detection is based on specific MD5 hashes of known malicious files, filenames used in the campaign, and command and control (C2) domains identified as part of the infrastructure.
Detects Office applications spawning scripting engines or LOLBINs often used in multi stage delivery chains associated with Agent Tesla style campaigns.
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).
Detects access to Huorong typosquat and intermediary redirector domains reported by Malwarebytes as part of a ValleyRAT distribution campaign.
This rule detects network connections or DNS queries to a list of domains identified as phishing campaign infrastructure. These domains are associated with a 'Signal Phishing Campaign' and are likely used for malicious purposes such as credential harvesting or malware distribution. The rule checks for these domains in `RemoteUrl` or `DestinationHost` fields across various network-related logs.
Detects the execution of osascript to display a deceptive dialog box mimicking 'System Preferences' to harvest user passwords. This technique was observed being used by the Atomic Stealer (AMOS) malware.
Detects network connections to phishing domains mimicking Windows 11 download pages used to distribute infostealer malware.
Detects high-impact phishing campaigns identified by Microsoft Defender for Office 365. Alerts when a campaign (CampaignName, CampaignId) targets 25 or more recipients (RecipientEmailAddress) within 48 hours, providing timestamp and message details (NetworkMessageId) for investigation.
Identifies network connections or DNS queries to known phishing domains mimicking Windows 11 update sites, which are used to distribute infostealer malware. These domains are highly specific to this campaign.
Page 52 of 76