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 TLS/SSL traffic patterns characteristic of Metasploit Meterpreter reverse HTTPS command-and-control communication, specifically targeting the use of default, self-signed certificates with a subject line containing a bare wildcard (CN=*) in the common name field, a common artifact of unconfigured Metasploit payloads.
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.
This rule detects network communication to a known command and control (C2) server (23.254.164.123:443) associated with the 'protocal.cjs' backdoor, which is part of the 'easy-day-js' npm supply chain compromise. The detection specifically looks for TLS traffic with a Server Name Indication (SNI) and general IP traffic to this C2 address.
Detects outbound HTTPS traffic from a web server to api.telegram.org. This pattern is indicative of the Montana Empire phishing kit using the Telegram Bot API for command and control (C2) communication, allowing the adversary to exfiltrate stolen data or receive instructions.
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.
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 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.
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.
Detects TLS/SSL traffic patterns characteristic of Metasploit Meterpreter reverse HTTPS command-and-control communication, specifically targeting the use of default, self-signed certificates with a subject line containing a bare wildcard (CN=*) in the common name field, a common artifact of unconfigured Metasploit payloads.
This rule detects outbound TLS connections to identified C2 infrastructure associated with the UAC-0226 threat actor and the GIFTEDCROOK malware, specifically by monitoring the certificate subject name 'NextGen Fusion'.
This rule detects network communication associated with the 'easy-day-js Mastra npm Supply Chain' compromise. The first alert identifies C2 exfiltration attempts over TLS to a specific IP address (23.254.164.123) on port 443. The second alert identifies a stage-2 payload download from another specific IP address (23.254.164.92) on port 8000, specifically looking for the URI '/update/49890878'. These indicators are linked to the 'protocal.cjs' and 'setup.cjs' malware, respectively, and are part of a supply chain attack.
This rule detects the use of self-signed TLS certificates where both the issuer and subject Common Name (CN) match a suspicious pattern. The pattern specifically looks for CNs that are 5 to 20 alphanumeric characters or hyphens, followed by one of several top-level domains (TLDs) commonly associated with malicious activity: .xyz, .top, .club, .icu, or .pw. This combination of self-signed certificates and suspicious TLDs is often indicative of command and control (C2) communication from malware.
This rule detects network traffic where a TLS certificate is presented with an issuer's common name (CN) containing at least 8 alphanumeric characters and a subject organization (O) that includes common company suffixes like 'LLC', 'Ltd', or 'Inc'. This combination, especially with an unusually formatted issuer CN, could indicate an invalid or suspicious code signing certificate used for executables, potentially associated with trojan activity or defense evasion tactics.
This rule detects the use of a suspicious wildcard certificate in the TLS handshake where the certificate subject contains a wildcard character followed by a domain name with a specific pattern (6 to 12 alphanumeric characters) and a top-level domain (TLD) from a list associated with malicious activities (xyz, top, club, icu). This pattern is often observed in attack infrastructure, particularly for phishing or command and control (C2) servers, to make them appear more legitimate or to facilitate rapid domain generation. The rule specifically looks for '*.domain.tld' where 'domain' is 6-12 chars and 'tld' is one of the specified suspicious TLDs.
This rule detects the use of the Sliver C2 Framework based on a specific pattern in the TLS certificate subject. It looks for the common name (CN) 'multiplayer' within the TLS certificate subject, which is a known indicator for Sliver C2 communications.
This rule detects suspicious TLS certificates that are self-signed and potentially used for Command and Control (C2) communication. Specifically, it looks for TLS certificates where both the issuer and subject country codes are 'US' and the common name (CN) in the subject field consists of 8 or more hexadecimal characters. This pattern is often observed in malware using dynamically generated self-signed certificates for C2.
This rule detects the installation of a new self-signed TLS certificate that might be used by a Command and Control (C2) server. It specifically looks for TLS certificates where both the issuer and subject Common Name (CN) are at least 5 alphanumeric characters long and the 'not before' date is in the current or future years (2024-2029). This combination of characteristics can indicate a newly generated, potentially malicious self-signed certificate.
This rule detects suspicious TLS certificates that are valid for only one day and have a common name (CN) consisting of 6 or more alphanumeric characters. This pattern is often associated with malware or command and control (C2) activity, where certificates are generated on the fly with short validity periods to evade detection.
This rule detects the use of self-signed TLS certificates on newly registered domains, specifically those ending in .xyz, .top, .club, .online, or .site. It looks for certificates where both the issuer and subject Common Name (CN) fields are present, and the subject CN matches a pattern indicative of a newly registered domain (5 to 20 alphanumeric characters followed by one of the specified TLDs). This pattern is often associated with malicious infrastructure setup.
This rule detects network traffic that uses a TLS certificate with the common name (CN) 'Major Cobalt Strike'. This specific CN is a known default value used by the Cobalt Strike command and control (C2) framework. Detection of this certificate indicates potential Cobalt Strike C2 communication within the network.
TLS Certificate Harvesting Sweep
Suricata
This rule detects a TLS certificate harvesting sweep, characterized by a high volume of TLS Server Name Indication (SNI) requests from a single source within a short period. This behavior is indicative of reconnaissance activities where an attacker is attempting to collect information about services running on various hosts by observing their TLS certificates.
Page 17 of 20