Detecting & Decrypting Sliver C2 – A Threat Hunter's Guide

Sliver, created by the Bishop Fox team, is a powerful and open-source Golang-based Command & Control (C2) framework. While it aids ethical red teams in adversary simulations, Sliver’s flexibility, speed, and cross-platform support have also made it popular among threat actors. Understanding Sliver’s capabilities and detection strategies is becoming an essential skill for defenders and incident responders.

Infrastructure Setup for Analysis

To replicate realistic conditions, defenders typically prepare a range or lab that includes host-based logging, EDR solutions, and full packet capture. A sample setup:

Target Host: A Windows, Linux, or macOS endpoint with Sysmon or similar event logging.
Central Logging: A SIEM (e.g., Splunk, ELK) capturing DNS, TLS, and process events.
EDR Tool: For memory dumps, process hunts, and file integrity monitoring.
Attacker Infrastructure: Sliver server hosted externally, with DNS or HTTP(S) listeners. Use a public IP address or cloud instance to simulate a real threat scenario.

By combining these elements, you can gather high-fidelity data on Sliver’s behavior and replays of network traffic in a controlled environment.

Implant Analysis & Yara Rules

Sliver generates implants (“slivers”) for multiple operating systems—often large, statically compiled Golang binaries. This can be advantageous to defenders:

Large PE or ELF Files: The size alone (commonly 10MB+ on Windows) can stand out from typical system binaries.
Readable Strings & Golang Symbols: Golang function names (like main.main or github.com/bishopfox/sliver) can be evident.

A basic Yara rule can detect suspicious Golang references or unique Sliver markers. For memory scanning, use a variant that accounts for common offsets or embedded strings to reduce false positives. You might also detect canary domains compiled into certain Sliver implants, which remain in clear text inside the binary.

C2 Communication: DNS & HTTP(S)

Sliver supports multiple protocols such as DNS, mTLS, WireGuard, and HTTP(S). Understanding these channels is key to detection:

DNS Tunneling

Sliver can encapsulate commands and responses in DNS queries and replies, often using Base58 or Base32 with custom alphabets. Because DNS isn’t session-based, Sliver employs protobuf sequences to ensure packets arrive in order.

Detection can hinge on high-volume DNS queries with random subdomains or unusual lengths. Security teams can:

Monitor subdomain counts: Tunneling generates more DNS requests than typical usage.
Look for unusual alphabets: Base58 with custom characters can show up as odd subdomain patterns.
Analyze DNS logs: Filter for subdomains well over 60–70 bytes or suspicious query frequency.

HTTP & HTTPS Channels

Similar to DNS, Sliver’s HTTP traffic is encrypted and can be obfuscated via Base32, Base58, Hex, or even English word encoding. Each request might carry a nonce parameter specifying which encoder was used, and data is compressed or masked to avoid detection.

Default Sliver HTTP implants also produce file extensions like:

.woff (used for stagers)
.html (key exchange messages)
.php (session messages)
.png (closing session)

These can be changed by the operator, so signature-based detection may require known default rules or strong heuristics (e.g., Snort rules searching for Sliver patterns).

Decrypting Sliver Traffic

All Sliver messages are individually encrypted with a per-session key. To decrypt captured traffic, defenders can:

Dump Process Memory: Using an EDR or live forensic approach (e.g., Velociraptor, ProcDump) to capture memory from the running Sliver implant.
Locate the Session Key: Sliver’s session key (derived from SHA256 of random bytes) often appears in memory. Patterns like 00 00 [32-byte-key] 00 C0... can narrow down the candidate keys.
Extract & Decode Payloads: If you have DNS or HTTP traffic, parse the encoded data (base32, base58, or English words). Then apply the candidate keys until decryption is successful. This yields the raw protobuf or Sliver commands.

In many cases, capturing the session key requires timely memory analysis, as new sessions generate new keys. Tools like Volatility or custom Python scripts can automate searching for potential keys and attempting decryption.

Example Workflow

Imagine you’ve identified random DNS subdomains or suspicious .woff requests from an internal host. You suspect Sliver. You then:

Obtain a memory dump of the suspicious process via EDR or live response.
Run a Yara rule that flags Golang strings related to Sliver. Confirm you’ve got an implant.
Parse DNS or HTTP traffic logs, extracting any encoded data. Each snippet is likely a Sliver command or response.
Locate potential 32-byte session keys in the dump. Test each key with your parsed data. Decrypt successful messages, revealing Sliver’s internal commands or payload details.

Conclusion & Further Study

Sliver’s open-source nature, cross-platform binaries, and flexible encoding make it a favorite for both offensive security and malicious operations. Effective detection requires combining log analysis, memory forensics, custom Yara rules, and network telemetry. By capturing session keys from memory and correlating them with DNS or HTTP data, defenders can decrypt and fully understand Sliver’s activity.

For a deeper dive, consider building your own lab to test different Sliver payloads (obfuscated vs. plain) and communication protocols (DNS, HTTP, mTLS). This hands-on approach ensures you can adapt detection strategies to Sliver’s evolving capabilities.