Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,598 detections
Filters
Last updated
All Time
Detection languages
1,151
134
65
63
53
Contributors
368
274
239
197
70
Categories
983
375
271
227
140
Platforms
871
506
164
160
149
Products / Services
949
298
133
113
108
MITRE Techniques
18,116
15,638
12,587
8,397
6,227
1,598
CVEs
2
1
1
1
1
IDS Classtypes
18
5
4
1
1
IDS Protocols
15
8
4
3
Marketing emails use Emojis all the time… but attackers use them too because they catch attention and increase the chance someone clicks:
- ⚠️ Urgent messages
- 📦 Delivery notifications
- 📄 Fake invoices
- 🔐 Password resets
Identify and classify cases on Email Subjects can be converted in useful detections. It query identify:
- Emails received with icons in the subject
- Where the URL was clicked
- Excluding cases where the sender is added as allowed either in the organization or user level
- Summarise by number of Emails, number of distinct recipients and also identify if the messages were delivered into Inbox Folders
- ⚠️ Urgent messages
- 📦 Delivery notifications
- 📄 Fake invoices
- 🔐 Password resets
Identify and classify cases on Email Subjects can be converted in useful detections. It query identify:
- Emails received with icons in the subject
- Where the URL was clicked
- Excluding cases where the sender is added as allowed either in the organization or user level
- Summarise by number of Emails, number of distinct recipients and also identify if the messages were delivered into Inbox Folders
Attackers do not only use emojis in the subject. Sometimes they also use them in the file name itself to make the file look more attractive or legitimate. Based on my experience, I am not expecting legitimate files names with icons so it can be an interesting case to easily convert the hunting into a detection. For example:
📄Invoice.pdf
🔐Reset_Password.html
📦Delivery_Document.zip
This can help find:
- Suspicious files dropped on disk
- Files downloaded from phishing emails
- User-downloaded scam files
- Payloads with social engineering names
📄Invoice.pdf
🔐Reset_Password.html
📦Delivery_Document.zip
This can help find:
- Suspicious files dropped on disk
- Files downloaded from phishing emails
- User-downloaded scam files
- Payloads with social engineering names
This query detects multiple TTPs associated with the Storm-2561 campaign that uses SEO poisoning to distribute fake VPN clients for credential theft. It looks for known file hashes, a specific code-signing certificate, malicious DLL side-loading and C2 communication patterns.
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.
KQL Query from file: OauthMSPhish Detection
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.
Page 52 of 77