Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
104 detections
Filters
Last updated
All Time
Detection languages
76
9
3
3
3
Contributors
60
18
8
4
4
Categories
36
34
22
18
16
Platforms
57
39
18
11
5
Products / Services
10,670
9,758
6,693
4,421
3,749
MITRE Techniques
27
22
16
15
13
CVEs
2
1
1
1
1
IDS Classtypes
1
1
IDS Protocols
1
1
Detects network traffic within the internal network that matches the initial handshake phase of a SOCKS proxy connection. This is a common indicator of an attacker using an internal system to proxy command and control (C2) traffic or pivot within the network using tools like HTRAN, ZXProxy, or custom implementations.
Detects periodic, repetitive TLS network connections from internal hosts to external destinations using threshold-based analysis. This pattern is indicative of potential command-and-control (C2) beaconing, which may be used for exfiltrating stolen credentials or sensitive data from build or developer environments.
Detects periodic, low-variance network beaconing behavior indicative of the SnappyClient RAT, specifically monitoring for simultaneous connections to control (port 3333) and data (port 3334) ports. The detection utilizes statistical analysis of inter-arrival times (low coefficient of variation) and restricts alerts to rare destination IP addresses contacted by a limited number of internal hosts.
Detects SSH traffic originating from designated edge appliances (e.g., firewalls, NAS devices) directed towards internal network destinations. This pattern is often indicative of network pivoting, lateral movement, or unauthorized remote access from exposed or compromised perimeter assets.
Detects outbound network communication to ports 80 or 443 that lacks standard application-layer protocol signatures (HTTP/HTTPS/TLS). This behavior is characteristic of the Gh0stRAT malware, which uses a non-standard zlib-compressed protocol with a specific 'Gh0st' header, commonly observed in TA4922 operations.
This rule identifies potential BRICKSTORM command and control (C2) activity by detecting sustained beaconing patterns to known public DNS-over-HTTPS (DoH) providers (8.8.8.8, 1.1.1.1) over port 443. It buckets network connections into 10-minute windows and flags source devices exhibiting frequent, repetitive traffic patterns, enriched with asset context to prioritize alerts from edge appliances such as firewalls, NAS devices, or storage sync services.
This rule detects potential beaconing or re-registration activity associated with the JDY/KV-botnet by monitoring network connections to known Tor control/relay ports (9001 and 9050). The detection identifies endpoints making high-volume, multi-destination connections to external IPs over these specific ports, a pattern indicative of botnet nodes attempting to re-establish C2 communication after infrastructure disruption or actively recruiting new nodes.
This rule detects high-volume or repeated outbound connections to Mega cloud storage domains (mega.nz, mega.co.nz, etc.) by processes that are not identified as standard web browsers. Such activity may indicate data exfiltration, automated file staging, or unauthorized use of cloud storage services.
Detects high-volume outbound network scanning activity from a single internal source device. The rule identifies anomalous behavior characterized by rapid connection attempts to a large number of distinct destination IPs and ports, consistent with scanning patterns observed in botnets like JDY, which often target edge network infrastructure (Cisco, Ubiquiti, Draytek).
This rule detects a sequence of events where a host initiates a network connection on port 1313 (a common port associated with certain web-based C2 or exploitation frameworks) followed shortly by an outbound network connection initiated by PowerShell within a 5-minute window. This behavior is indicative of a post-exploitation phase where an initial entry point leverages a malicious script or shell to establish persistent communication.
Detects potential Command and Control (C2) infrastructure rotation and DNS exfiltration by correlating DNS-over-HTTPS (DoH) traffic to Google Public DNS (8.8.8.8) with concurrent outbound connections to a high count (>=5) of distinct external IP addresses within a one-hour window. This behavior is consistent with the Nightmare Eclipse/VerdantBamboo post-disclosure tactical shifts to obfuscate DNS queries and rotate C2 endpoints.
This rule detects anomalous spikes in inbound network connections to common edge device management ports (80, 443, 8080, 8443) by baselining the number of unique source IP addresses per destination over a 30-day window. It triggers an alert when the hourly count of unique source IPs deviates significantly (greater than 3 standard deviations) from the historical mean, which may indicate active network scanning or brute-force attempts.
Detects high-volume, multi-port connections from a single source to a domain controller, which is indicative of vulnerability scanning activity such as Nessus. The rule monitors for a large volume of connection attempts across multiple sensitive ports (e.g., 88, 135, 389, 445, 464, 636, 3268, 3269) within a short 5-minute window.
Latin American banking trojan using DLL side-loading and overlay attacks
Detects high-volume outbound network connection attempts from internal endpoints targeting a specific set of common SOHO/IoT management and service ports. This behavior is consistent with automated service enumeration, banner grabbing, and reconnaissance activity often associated with botnets like the JDY cluster, which target edge devices for potential exploitation.
Detects high-cardinality, multi-protocol network scanning behavior characteristic of the JDY botnet. The rule identifies internal hosts attempting to connect to a high volume of unique external destinations across multiple protocols with low average bytes per connection, indicative of automated discovery or probing activity.
This rule detects outbound network traffic from internal IP addresses to known Tor network entry or exit relay ports (9001, 9030, 9050, 9051). It specifically prioritizes alerts where the source host is identified as network infrastructure (routers, gateways, firewalls) or IoT devices, flagging potential unauthorized use of Tor for obfuscated communication or data exfiltration from within the network perimeter.
Detects anomalous network scanning behavior originating from internal hosts. The rule triggers when a host contacts a high number of distinct ports (greater than 50) or establishes a large number of connections (greater than 100) to a high number of distinct IP addresses (greater than 20), excluding common internal network segments. This behavior is indicative of network reconnaissance or service discovery activities typical of an adversary mapping the network.
This rule detects internal hosts initiating connections to known Tor ORPort or DirPort services, indicating potential C2 check-in, correlated with high-rate scanning behavior from the same source IP. This combination suggests a compromised host using an anonymity network for C2 communication while simultaneously performing internal reconnaissance.
This rule monitors network traffic for HTTP POST requests directed toward specific destination ports (443 or 8770) that return HTTP status codes in the 4xx range (client errors), excluding known legitimate URI paths. This pattern may indicate scanning activity, exploitation attempts, or unauthorized access attempts against internal services or misconfigured applications.
Detects network traffic associated with TrymeLocker malware, specifically targeting Telegram API communications containing hardcoded identifiers and geolocation lookups via ipinfo.io.
Page 2 of 5