#3 - Sliver C2: Fingerprinting and Hunting

The preceding post in this series detailed methodologies for concealing Sliver Command and Control (C2) infrastructure on the public internet. Cloudflare tunnels were demonstrated as an effective implementation to encapsulate implant traffic through Cloudflare’s edge network. The primary advantage of this architecture is that the C2 backend is shielded from direct exposure to the public internet, and Cloudflare automatically provisions and presents a valid TLS certificate for the entry domain.

Given the inherent volatility of adversarial infrastructure, traditional Indicators of Compromise (IOCs)—such as IP addresses, domain names, and TLS certificates—are frequently cycled and therefore subject to change. Consequently, this post explores advanced techniques for fingerprinting and identifying C2 backends, such as Sliver, across the broader internet.

Defensive teams are continuously developing methodologies to detect malicious infrastructure and enhance their threat hunting capabilities. A notable historical example is the identification of Cobalt Strike team servers in 2018 based on unexpected whitespace in HTTP responses. Specifically, an anomalous space present in responses from servers prior to version 3.12 served as a reliable fingerprint:

One of Fox-IT’s InTELL analysts, with a trained eye for HTTP header anomalies, spotted an unusual space in the response of a Cobalt Strike team server in one of our global investigations into malicious activity. Though this might seem irrelevant to a casual observer, details such as these can make a substantial difference in combating malicious activity, and warranted additional research into the set-up of the team servers.

CobaltStrike: Additional Whitespace

Additional research detailing similar fingerprinting techniques has been published by Heige of the KnownSec 404 Team:

JA3 and JARM Fingerprinting

JARM is an active TLS server fingerprinting tool developed by Salesforce Engineering. It provides the capability to profile TLS servers with the following operational objectives:

Rapidly verifying that all servers within a cluster share an identical TLS configuration.
Grouping disparate internet-facing servers by their configuration to identify organizational ownership (e.g., distinguishing infrastructure belonging to Google, Salesforce, or Apple).
Identifying default applications or standard infrastructure setups.
Identifying and tracking malware Command and Control infrastructure alongside other malicious internet-facing servers.

Re-evaluating the TLS Handshake

Transport Layer Security (TLS) ensures authenticated and encrypted communications. To establish a session, a client transmits a TLS Client Hello message immediately following the TCP three-way handshake. The structure of this packet is inherently dependent on the underlying libraries and methods utilized during the client application’s compilation. The server subsequently replies with a TLS Server Hello packet, formulated based on the parameters specified in the initial client request.

The standard message flow for a complete handshake is documented in RFC 5246:

                    [Client]                                            [Server]
                    ClientHello   ------------------------>
                                                                    ServerHello
                                                                    Certificate*
                                                              ServerKeyExchange*
                                                             CertificateRequest*
                                    <------------------------    ServerHelloDone
                    Certificate*
                    ClientKeyExchange
                    CertificateVerify*
                    [ChangeCipherSpec]
                    Finished      ------------------------>
                                                              [ChangeCipherSpec]
                                    <------------------------           Finished
                                    
                    Application Data    <---------------->     Application Data

The specific composition of the Server Hello response varies significantly based on factors intrinsic to the server’s environment:

The underlying Operating System
The specific version of the Operating System
The cryptographic libraries utilized
The specific versions of those libraries
The precise initialization and invocation order of the libraries
Custom administrative configurations

JARM operates by actively transmitting 10 distinct TLS Client Hello packets to a target server and recording specific attributes from the resulting TLS Server Hello responses. These aggregated responses are subsequently hashed using a proprietary algorithm to generate the final JARM fingerprint.

┌──(kali㉿redstar-os)-[~/jarm]
└─$ python jarm.py sliverc2.port9.org
[...]
JARM: "3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910"

┌──(kali㉿redstar-os)-[~/jarm]
└─$ python jarm.py entry.random-malware-domain.com
[...]
JARM: "27d3ed3ed0003ed1dc42d43d00041d6183ff1bfae51ebd88d70384363d525c"

Detecting Sliver Signatures in the Wild

JARM integration is now standard across major internet scanning and mapping services, including Shodan and Censys. Furthermore, independent researchers like Silas Cutler have conducted comprehensive scans of the IPv4 address space on port 443, compiling JARM values into publicly accessible SQLite databases.

Shodan search result

The Shodan Command Line Interface (CLI) application provides a streamlined method for querying and exporting these datasets:

┌──(kali㉿redstar-os)-[~/]                 
└─$  shodan init <SHODAN API KEY>
┌──(kali㉿redstar-os)-[~/jarm]
└─$ shodan download search ssl.jarm:"3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910" 
Search query:                   ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910
Total number of results:        1782
Query credits left:             97
Output file:                    search.json.gz
  [#############################################################]   99%  00:00:00
Saved 1000 results into file search.json.gz

In this specific survey, Shodan identified 1,792 instances matching the target JARM hash. This dataset can be further refined by introducing specific constraints related to the HTTP response characteristics typical of the Sliver web server framework. For instance:

┌──(kali㉿redstar-os)-[~/1]
└─$ shodan download search ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910 "HTTP/1.1 404 Not Found" "Cache-Control: no-store, no-cache, must-revalidate" "Content-Length: 0"
Search query:                   ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910 HTTP/1.1 404 Not Found Cache-Control: no-store, no-cache, must-revalidate Content-Length: 0
Total number of results:        67
Query credits left:             95
Output file:                    search.json.gz
  [###################################-]   98%  00:00:02
Saved 67 results into file search.json.gz

It is worth noting that the Sliver development team recently introduced functionality to optionally randomize the server’s JARM fingerprint, effectively mitigating this specific detection vector.

Because modern C2 frameworks like Sliver are open-source, these baseline signatures are trivial to modify—either by the primary maintainers in subsequent releases or by independent operators deploying customized forks. The primary objective of this documentation is to articulate concrete methodologies for fingerprinting Sliver deployments, thereby equipping defensive practitioners with the conceptual foundation required to discover and classify novel C2 infrastructure variations.

#3 - Sliver C2: Fingerprinting and Hunting

JA3 and JARM Fingerprinting

Re-evaluating the TLS Handshake

Detecting Sliver Signatures in the Wild

Resources