Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
667 detections
Filters
Last updated
All Time
Detection languages
304
127
82
42
35
Contributors
151
83
80
37
31
Categories
442
354
165
142
112
Platforms
398
212
86
70
20
Products / Services
184
122
103
93
65
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
CVEs
5
3
3
1
1
IDS Classtypes
74
35
7
6
3
IDS Protocols
71
22
17
7
2
Remote Monitoring and Management (RMM) programs are IT to manage remote endpoints. Attackers have begun to abuse these programs to persist or provide C2 channels.
https://github.com/jischell-msft/RemoteManagementMonitoringTools
https://github.com/jischell-msft/RemoteManagementMonitoringTools
Remote Monitoring and Management (RMM) programs are IT to manage remote endpoints. Attackers have begun to abuse these programs to persist or provide C2 channels.
https://github.com/jischell-msft/RemoteManagementMonitoringTools
https://github.com/jischell-msft/RemoteManagementMonitoringTools
This rule detects outbound network connections to IP addresses that have been observed for the first time within the last 24 hours. It specifically excludes connections to private IP address ranges (RFC1918). The detection relies on correlating current network connection events with historical 'first seen' data for IP addresses from an entity graph.
This analytic detects Lumma Stealer download attempts using Cisco Secure Firewall Intrusion Events. It leverages Cisco Secure Firewall Threat Defense IntrusionEvent logs to identify cases where Snort signatures with specific IDs have been triggered. If confirmed malicious, this behavior could indicate an active infection of Lumma Stealer.
This analytic detects Lumma Stealer outbound connection attempts using Cisco Secure Firewall Intrusion Events. It leverages Cisco Secure Firewall Threat Defense IntrusionEvent logs to identify cases where Snort signatures with specific IDs have been triggered. If confirmed malicious, this behavior could indicate an active infection of Lumma Stealer.
This analytic detects potentially suspicious large outbound data transfers from internal to external networks using Cisco Secure Firewall Threat Defense logs. It calculates the total volume of data exchanged per connection by summing InitiatorBytes and ResponderBytes. Connections exceeding 100 MB are flagged, as these may indicate unauthorized data exfiltration, especially if initiated by unusual users, hosts, or processes. The detection is scoped to inside-to-outside network flows. If confirmed malicious, this behavior may reflect data staging and exfiltration over an encrypted or stealthy transport.
The analytic identifies spikes in blocked outbound network connections originating from within an AWS environment. It uses VPC Flow Logs data from CloudWatch, specifically looking for 'blocked' actions from internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to external destinations. A spike is determined by comparing the current number of blocked connections against a calculated baseline (average and standard deviation) over time. This detection is significant as it can indicate potential exfiltration attempts or misconfigurations leading to data leakage. If confirmed malicious, such activity could allow attackers to bypass network defenses, leading to unauthorized data transfer or communication with malicious external entities.
This analytic detects network connections flagged by Cisco Secure Firewall's Encrypted Visibility Engine (EVE) with a high threat confidence score (80% or greater). This indicates that the encrypted traffic is highly likely to be malicious, potentially associated with malware command and control (C2), remote access tools, or suspicious tunneling behavior. Such activity could signify covert communication from compromised hosts.
The following analytic identifies high inbound or outbound network I/O anomalies in Kubernetes containers. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. A lookup table with average and standard deviation values for network I/O is used to detect anomalies persisting over a 1-hour period. This activity is significant as it may indicate data exfiltration, command and control communication, or unauthorized data transfers. If confirmed malicious, it could lead to data breaches, service outages, financial losses, and reputational damage.
This analytic identifies significant changes in network communication behavior within Kubernetes containers by examining the inbound to outbound network IO ratios. It leverages process metrics from an OTEL collector and Kubelet Stats Receiver, along with data from Splunk Observability Cloud. Anomalies are detected using a lookup table containing average and standard deviation values for network IO, triggering an event if the anomaly persists for over an hour. This activity is significant as it may indicate data exfiltration, command and control communication, or compromised container behavior. If confirmed malicious, it could lead to data breaches, service outages, and unauthorized access within the Kubernetes cluster.
The analytic identifies the use of SNICat tool commands within the TLS SNI field, indicating potential data exfiltration attempts. It leverages Zeek SSL data to detect specific SNICat commands such as LIST, LS, SIZE, LD, CB, EX, ALIVE, EXIT, WHERE, and finito in the server_name field. This activity is significant as SNICat is a known tool for covert data exfiltration using TLS. If confirmed malicious, this could allow attackers to exfiltrate sensitive data undetected, posing a severe threat to data confidentiality and integrity.
Detects network communication initiated to the 'portmap.io' domain. This domain is often associated with port forwarding services that can be abused by malicious actors for command and control (C2) communication or data exfiltration, potentially masking the true destination of the traffic.
This rule detects when a Python process initiates an outbound network connection. While this activity can be legitimate for tasks like package installation or updates, it can also be indicative of malicious behavior, such as a Python-based script establishing communication with a command and control (C2) server or performing network reconnaissance. The rule includes filters to reduce false positives from common activities like Anaconda updates, Jupyter Notebook local communication, and 'pip install' commands.
Detects an executable accessing the portmap.io domain, which could be a sign of forbidden C2 traffic or data exfiltration by malicious actors
Detects command line patterns associated with the use of Pnscan for sending and receiving binary data across the network. This behavior has been identified in a Linux malware campaign targeting Docker, Apache Hadoop, Redis, and Confluence and was previously used by the threat actor known as TeamTNT.
Detects instances where a TFTP service on an OpenCanary node has had a request.
This rule detects the Voldemort backdoor by identifying specific byte patterns related to its configuration decryption, general decryption algorithm, access token request mechanism, network communication routines, and data download functions from its command and control (C2) server. The rule looks for a combination of these distinct code segments within a Windows executable (MZ header).
Yara rule that detects Voldemort backdoor.
This YARA rule detects the NoodRAT backdoor by identifying specific byte sequences (patterns) associated with its core functionalities. These functionalities include changing the system name, decrypting configuration data, encrypting and sending data, and receiving and decrypting data. The rule specifically targets Linux ELF executables, indicated by the magic byte `0x464C457F` at offset 0.
Detects potential command and control (C2) beaconing activity to domains identified as being used in the 'Operation Triangulation' campaign, which targeted iOS devices with 0-day exploits. This rule specifically looks for connections to a list of known malicious domains via proxy logs.
Detects the execution of 'openssl' with specific command-line arguments to connect to an IP address on ports 443 or 8080. This activity has been observed in campaigns by UNC4841 for SSL certificate exfiltration and as a C2 channel using named pipes. Further investigation of commands executed in the temporal vicinity of this activity is recommended.
Page 31 of 32