Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
408 detections
Filters
Last updated
All Time
Detection languages
405
2
1
Contributors
144
114
48
39
36
Categories
281
276
132
105
60
Platforms
381
25
16
7
5
Products / Services
388
318
30
5
4
MITRE Techniques
174
103
44
30
28
CVEs
4
1
1
IDS Classtypes
201
121
21
19
14
IDS Protocols
2,431
868
408
324
97
Detects outbound network traffic established to an *.ngrok.io domain, which is frequently used by adversaries to create secure tunnels for command and control (C2) or unauthorized data exfiltration.
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 repeated outbound HTTPS connections to api.github.com from a single source within a 60-second window. This pattern may indicate automated data exfiltration using the GitHub Contents API, as attackers often leverage legitimate code repository services to mask data exfiltration traffic.
Detects established TLS traffic over WebSockets where the certificate subject field lacks a common name (CN), often indicative of non-standard, self-signed, or improperly generated TLS certificates used by command-and-control (C2) agents to bypass standard certificate validation or hide within encrypted channels.
This rule detects outbound TLS 1.2 traffic communicating over TCP port 99, which is a non-standard port for TLS/HTTPS traffic. This behavior is indicative of potential command-and-control (C2) communication where an adversary is attempting to hide traffic using encryption on an unconventional port.
Detects established TLS connections to external networks where the server certificate subject contains a Common Name (CN) but lacks Organization (O) or Organizational Unit (OU) fields. This pattern is characteristic of basic, potentially malicious self-signed certificates used by command-and-control (C2) frameworks to mask communication.
Detects established TLS traffic originating from the internal network to external destinations on TCP port 99. This port is commonly used in legacy or non-standard configurations and, when combined with TLS, may indicate C2 relay infrastructure or unauthorized exfiltration channels.
Detects outbound network traffic from internal hosts to the domain 'avenger-sync.live' over TLS port 443, which is associated with PamStealer stage-two command and control communication.
Detects outbound HTTPS traffic on non-standard ports that matches a specific JA3 fingerprint associated with the Sliver command and control framework. This indicates potential beaconing or C2 communication from a compromised host.
Detects network traffic consistent with the Metasploit Meterpreter reverse HTTPS payload, specifically looking for the default 'CN=metasploit' certificate subject name used by the framework in SSL/TLS handshakes, or connections targeting default Meterpreter ports like 4444.
Detects network activity (DNS queries, TLS SNI, and HTTP requests) directed towards known attacker-controlled command-and-control domains associated with AsyncRAT and ScreenConnect abuse.
Detects frequent, persistent outbound TLS connections to api.telegram.org. This behavior is indicative of a malware sample or backdoor polling the Telegram Bot API for command and control (C2) instructions, effectively using the legitimate Telegram infrastructure to tunnel malicious communication.
Detects outbound HTTPS traffic on high ports where the TLS SNI header consists of a 8-20 character random alphanumeric string. This pattern is indicative of default configurations for Metasploit Meterpreter Reverse HTTPS payloads attempting to establish a Command and Control connection.
Detects outbound HTTPS traffic containing TLS certificates with common names associated with known command-and-control (C2) frameworks like Metasploit and Empire. These frameworks often use self-signed certificates with default or easily identifiable issuer names when establishing C2 communication.
Detects high-volume, established TLS connections to common public DNS-over-HTTPS (DoH) providers (Google, Cloudflare, OpenDNS). Persistent high-frequency connections to these resolvers can be indicative of DNS tunneling, where an adversary encapsulates command-and-control or data exfiltration traffic within encrypted DNS queries to bypass network monitoring.
Detects outbound network traffic established by a client using the default self-signed TLS certificate generated by Metasploit for Meterpreter Reverse HTTPS sessions. The rule looks for the common default subject fields 'CN=metasploit' and 'O=msf' within the TLS handshake.
This rule detects network activity associated with the easy-day-js Mastra npm supply chain attack. Specifically, it identifies data exfiltration over TLS to a secondary C2 server (23.254.164.123:443) and the download of a stage-2 payload from a primary C2 server (23.254.164.92:8000) via HTTP, looking for the URI '/update/49890878'.
Detects outbound HTTPS traffic on high ports where the TLS SNI header consists of a 8-20 character random alphanumeric string. This pattern is indicative of default configurations for Metasploit Meterpreter Reverse HTTPS payloads attempting to establish a Command and Control connection.
Detects outbound HTTPS traffic on non-standard ports that matches a specific JA3 fingerprint associated with the Sliver command and control framework. This indicates potential beaconing or C2 communication from a compromised host.
Detects network traffic (DNS, TLS/HTTPS) communicating with the secondary hosting domain 'fileget.loseyourip.com' specifically attempting to retrieve potential payloads mimicking legitimate software (e.g., OBS Studio installer).
This rule detects potential command and control (C2) activity related to the Qakbot malware. It specifically monitors for established outbound TLS traffic over non-standard ports (ports other than 443) where the Server Name Indication (SNI) field contains a numeric IPv4 address instead of a domain name, which is a characteristic behavior of Qakbot C2 infrastructure.
Page 16 of 20