Analysis of Sliver C2 Tool Traffic Features and Detection Rules for Snort/Suricata

The article begins by noting the rapid emergence of penetration‑testing tools and the increasing difficulty for security products to detect them. While Cobalt Strike has become well‑studied, attackers are turning to less‑known frameworks such as Sliver to evade endpoint and traffic detection.

To keep up with evolving threats, the author’s team conducts research on malicious network traffic, focusing on new mining trojans, remote‑control tools, and scanners. Because most NIDS/IPS support Snort rule syntax, the paper presents a detailed analysis of Sliver’s traffic characteristics and provides practical Snort rules.

01 Sliver Basic Introduction

Sliver is a Go‑based C2 framework that supports multiple listeners, custom extensions, and payload generation for all OS architectures. It offers various callback protocols (DNS, mTLS, WireGuard, HTTP(S)) and can manage multiple sessions from a single server.

Key attacker‑oriented features include generating OS‑specific payloads, injecting malicious code into trusted processes (e.g., explorer.exe, regsvr32.exe, svchost.exe), and lateral movement via PsExec. Unlike Cobalt Strike, Sliver currently lacks a stager mechanism, resulting in larger HTTP beacon binaries (often >15 MB).

02 Cobalt Strike Feature Analysis

The paper compares Cobalt Strike’s detection signatures with Sliver. Basic signatures (e.g., specific HTTP paths, default certificates) are easy to bypass, while advanced signatures (e.g., NanoHTTPD empty byte, JA3/JA3S fingerprints) are harder to evade. Sliver does not exhibit the same NanoHTTPD artifact, and its TLS handshake can be fingerprinted similarly to Cobalt Strike.

03 Sliver HTTP Feature Extraction and Rule Validation

Sliver’s HTTP C2 traffic lacks obvious distinguishing fields, so the author examines URL structures, parameters, and cookies. Five message types are identified, each using a specific file extension (.woff, .js, .html, .php, .png). The most common messages are Key‑exchange (.html) and Long‑poll (.js).

Source‑code analysis (Httpclient.go) reveals that URIs contain 0‑4 random path segments followed by a randomly chosen filename with a fixed ".html" suffix. Cookie names are selected from a hard‑coded array of six common names, combined with a 32‑character random string. Session cookies are fixed 32‑byte values.

Parameters are built using a nonce generated as (rand(0,999999) * 101 + encoderID) , where encoderID selects one of several encoders (Base64, Hex, Gzip, etc.). Parameter names are 1‑2 characters drawn from "abcdefghijklmnopqrstuvwxyz_", and values are the processed nonce possibly mixed with random characters.

Based on these observations, the author crafts Snort rules. Example rule snippets are shown below:

POST /oauth2callback/php/samples.html?k=943u66167&wj=03222676 HTTP/1.1
Host: test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.2234.389 Safari/537.36
Content-Length: 134
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip
...........j.... .74Z;......`+.G.)!^...s .9.......NZ?.....e..d...,w^]B..(,........... .5..|.
C.....Y%...df.,m;:M .6x.ABu...........pj...HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Set-Cookie: PHPSESSID=bcbfd98683687a7ff7483d7971285979; HttpOnly
Date: Tue, 06 Sep 2022 10:51:21 GMT
Content-Length: 112
Content-Type: application/x-gzip

The rule set combines request‑side checks (POST method, specific path/filename patterns, .html suffix, nonce‑style parameters) with response‑side checks (Set‑Cookie header containing a 32‑character value). Validation on a WAF/IPS showed accurate detection of Sliver HTTP beacons with no false positives in the author’s environment.

04 Sliver HTTPS Feature Extraction and Rule Validation

Because many C2 tools now use HTTPS, the paper extracts JA3 fingerprints from Sliver’s TLS handshake. For Sliver v1.5.24 on Debian 8, the JA3 hash is 19e29534fd49dd27d09234e639c4057e and the JA3S hash is f4febc55ea12b31ae17cfb7e614afda8 . Suricata rules leveraging these hashes are provided:

#ja3指纹-sliver 1.5.24
Alert tls any any -> any any (msg:"Possible Sliver HTTPS C2 - Debian 8"; ja3.hash; content:"19e29534fd49dd27d09234e639c4057e"; classtype:misc-activity; sid:1001; rev:1)
Alert tls any any -> any any (msg:"Possible Sliver HTTPS C2 - CentOS 7"; ja3.hash; content:"473cd7cb9faa642487833865d516e578"; classtype:misc-activity; sid:1002; rev:1)
#ja3s指纹-sliver 1.5.24
Alert tls any any <- any any (msg:"Possible Sliver HTTPS C2"; ja3s.hash; content:"f4febc55ea12b31ae17cfb7e614afda8"; sid:1003)

Testing with a generated Sliver backdoor and Suricata confirmed detection of the HTTPS C2 traffic.

05 Conclusion

The research demonstrates a systematic approach to analyzing a new C2 framework (Sliver) and deriving both HTTP and HTTPS detection signatures. While HTTP‑based signatures may be evaded by modifying hard‑coded request logic, JA3/JA3S based HTTPS signatures are harder to bypass. The methodology can be extended to other malware frameworks, and future work will focus on deeper behavioral indicators such as process injection and inter‑process communication.