Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
564 detections
Filters
Last updated
All Time
Detection languages
464
49
14
12
11
Contributors
217
119
88
54
41
Categories
20,443
11,831
5,872
5,155
4,866
564
Platforms
494
55
21
17
14
Products / Services
467
195
64
23
14
MITRE Techniques
180
93
65
63
59
CVEs
4
4
4
4
3
IDS Classtypes
303
37
23
23
21
IDS Protocols
449
3
This rule detects the download of potentially trojanized software updates. It specifically looks for HTTP traffic flowing to the client, where the URI contains "update" (case-insensitive), the HTTP host contains "update.", "cdn.", or "download." (case-insensitive), and the file data starts with "MZ" (indicating a Windows executable) within the first 2 bytes. Additionally, the downloaded file size must be greater than 500,000 bytes.
This rule detects a potential watering hole attack where a legitimate website has been injected with a script that attempts to load content from an IP address. Specifically, it looks for HTTP responses (flow:to_client) containing '<script src=' followed by a URL where the source is an IP address (e.g., 'src="http://1.2.3.4/script.js"'). This technique is often used by attackers to compromise visitors of a trusted site by redirecting them to malicious content or exploiting vulnerabilities.
This rule detects potential drive-by exploit kit landing pages by inspecting HTTP response data for the presence of both "exploit" and "shellcode" (case-insensitive). It specifically looks for these keywords in the data flowing from the server to the client over an established HTTP connection. The rule is categorized as an exploit-kit detection and is associated with MITRE ATT&CK technique T1189 (Drive-by Compromise) and tactic Initial Access.
This rule detects potential rogue captive portal credential harvesting pages by inspecting HTTP responses for the presence of keywords like 'captive', 'password', and 'connect' within the file data. These keywords, when found together in a client-bound HTTP response, suggest an attempt to mimic a legitimate captive portal to steal user credentials.
This rule detects HTTP responses from a server to a client that contain specific keywords ('remote', 'support', 'download') within the file data, indicating a potential fake IT support page attempting to deliver a remote access tool. The rule also checks for a minimum file size to reduce false positives.
This rule detects HTTP responses that appear to be a phishing kit landing page. It looks for specific keywords in the HTTP response body, such as 'img', 'logo', 'password', and 'Submit', indicating a page designed to collect credentials. Additionally, it checks if the HTTP host is an IP address, which is often used in phishing campaigns to bypass domain-based reputation checks or to host pages directly on compromised servers.
This rule detects HTTP responses that contain content indicative of a survey lure page used for information gathering. It specifically looks for the presence of keywords such as 'survey', 'name', 'email', and 'company' within the HTTP response body, suggesting an attempt to collect personal or organizational information.
This rule detects potential credential phishing pages served to a user over HTTP. It looks for HTTP responses containing both "Enter your password" and "Sign in" (case-insensitive) in the file data, and where the HTTP host is an IP address rather than a domain name. This combination of indicators suggests a generic phishing attempt designed to trick users into providing their credentials.
This rule detects web pages served to clients that contain characteristics commonly associated with tech support scams. Specifically, it looks for HTTP responses containing the words "call", "1-800", and "virus" (case-insensitive) in the file data. This combination of keywords suggests an attempt to trick users into calling a fake support number due to a fabricated "virus" infection.
This rule detects the delivery of shellcode via HTTP that contains a NOP sled pattern. The rule specifically looks for a sequence of eight or more '90' (hexadecimal) bytes in the HTTP response body, which is a common indicator of a NOP sled used to prepare for shellcode execution. The detection is focused on traffic flowing from the server to the client over an established HTTP connection.
This rule detects the download of a potential bootkit payload designed to overwrite the Master Boot Record (MBR). It specifically looks for HTTP traffic where the file data contains the byte sequence '|55 AA|' (which corresponds to the MBR signature) within the first 512 bytes and has a total size greater than 500 bytes. This pattern is indicative of malicious software attempting to modify the MBR for persistence or system control.
This rule detects potential JavaScript obfuscation within HTTP responses by looking for the presence of both 'eval(' and 'unescape(' within the first 500 bytes of file data in a client-bound HTTP flow. This combination of functions is often used in malicious JavaScript to hide its true intent and evade detection.
This rule detects the download of a file that appears to be an Office document template designed for remote template injection. It specifically looks for HTTP responses containing the strings "[Content_Types].xml" and "attachedTemplate" (case-insensitive) within the file data, which are indicators of a malicious Office document attempting to load a remote template.
This rule detects potential phishing landing pages by looking for HTTP responses that contain both 'login' and 'microsoft' in the URI, and where the HTTP host is an IP address. This combination suggests an attempt to mimic a Microsoft login page hosted on an IP address rather than a legitimate domain, which is a common tactic in phishing attacks.
Identifies potentially malicious client-side redirects or forced OAuth flows initiating from the Outlook Web Access (OWA) interface, characterized by 302 statuses and redirect parameters. This activity may indicate post-exploitation actions related to CVE-2026-42897.
Detects C2 communication from Boggy Serpens (MuddyWater) backdoors like Nuso and BlackBeard, which use non-standard HTTP status codes (201, 202, 418) to receive commands from known C2 servers.
Detects the JavaScript XOR-based string reconstruction pattern used by the Coruna iOS exploit kit. This pattern maps an array of integers through String.fromCharCode with XOR to reconstruct code at runtime. Coruna contained 23 iOS exploits targeting iOS 13.0 through 17.2.1 and was used by UNC6353 (Russian espionage) and UNC6691 (Chinese financially motivated).
Intellexa PREYHUNTER - HTTP
Suricata
Intellexa PREYHUNTER - HTTP response contains distinctive iOS build/artifact strings
UNC5142 CLEARSHORT - injected Web3 + BSC contract addresses in HTTP response
Detects a potential attempt to downgrade a password manager client's encryption to a legacy, non-authenticated mode (e.g., AES-CBC). A malicious or compromised server can send a specially crafted response during login or synchronization that forces the client to use weaker cryptography. This can compromise the integrity and confidentiality of the user's vault, enabling further attacks like vault modification or padding oracles.
Detects HTTP C2 beaconing patterns based on burst request counts with small response bodies (1-499 bytes). This rule correlates multiple HTTP requests to the same destination within a short timespan, where each response has a small body size. This pattern is indicative of command and control (C2) communication.
Page 24 of 27