Hunting Sliver without betting on defaults

The premise

Sliver supports multiple implant modes and C2 transports, including mTLS, WireGuard, HTTP(S), and DNS. Builds can also change across releases and operator profiles. This makes lists of default file extensions, strings, or packet shapes useful for initial triage but unreliable as a long-term detection strategy.

The objective is not to recognize every possible Sliver binary. It is to construct an evidence chain that survives operator customization: execution → process behavior → communication → task-driven activity.

Build evidence, not a demo

A useful lab reproduces the telemetry available in production. It should not begin with a YARA rule that already knows the answer. Generate more than one implant and vary the transport, mode, symbol treatment, and launch method. Then capture the same sources your analysts would receive during a real escalation.

• Endpoint: process creation, image loads, network ownership, memory regions, file metadata, and authentication activity.
• Network: DNS, TLS, HTTP metadata, flow records, and full packet capture where permitted.
• Server-side: listener logs and build metadata for ground truth.
• Time: synchronized clocks and a record of each operator action.

Host-side evidence

Begin with provenance. Where did the executable or injected region come from? Which process created it? Which user and integrity level executed it? Is the file signed, common in the environment, and consistent with the host’s role? A rare binary with a plausible Go toolchain fingerprint is only a lead until behavior gives it context.

Useful joins

• A newly written or user-writable executable followed by an outbound connection.
• A process with no expected network role maintaining a long-lived or recurring external channel.
• Command interpreters, credential access, process injection, or remote-service activity temporally linked to that channel.
• Executable private memory or anomalous threads inside a process whose disk image does not explain them.
• Repeated implant behavior across Windows, Linux, or macOS hosts that shares infrastructure or task timing.

String-based rules can still help triage unmodified builds. Write them around several independent implementation artifacts and test them against a large benign Go corpus. Do not make one repository path or project name the entire rule.

Network and DNS evidence

HTTP and HTTPS

The current Sliver documentation describes procedurally generated HTTP(S) behavior and proxy-aware connection attempts. Historical write-ups often emphasize extensions such as .woff, .html,.php, or .png. Those observations may identify a specific generation profile, but they should not be promoted to a universal protocol signature.

For a suspected HTTP(S) channel, compare:

• the owning process and its expected network behavior;
• request sequencing, method changes, response sizes, and idle intervals;
• proxy versus direct connection attempts;
• domain age, hosting history, certificate relationships, and adjacent infrastructure;
• task execution on the host immediately after responses arrive.

DNS

DNS C2 places encoded data into queries and reconstructs messages over a transport that has no session in the TCP sense. Detection should focus on the behavior this creates: label length and character distribution, query volume, authoritative-domain concentration, record-type patterns, response behavior, and the process responsible for the lookups.

# Useful per-host, per-domain features for DNS triage
query_count
unique_leftmost_label_count
median_and_max_label_length
character_distribution
record_type_distribution
NXDOMAIN_ratio
bytes_estimated_in_queries_and_answers
time_between_queries

None of these features is malicious by itself. The high-value finding is a DNS pattern that is rare for the environment, owned by a suspicious process, and followed by task-consistent host activity.

Memory and decryption

Memory can provide the executable image, configuration material, runtime state, plaintext task data, or cryptographic material that is absent from disk. Capture it early. A terminated implant may remove the only artifact that can tie an encrypted channel to a specific process.

Decrypting Sliver traffic is possible in some investigations, but it is a version-sensitive engineering task, not a universal recipe. The analyst must identify the Sliver release and transport implementation, retain the complete handshake and message stream, and obtain the corresponding runtime or server-side material. Protocol descriptions from an older wiki revision should be checked against the source code for the version under analysis.

What success looks like

1. The implant or memory image is linked to the captured flow.
2. The protocol parser reproduces message boundaries from the capture.
3. Recovered key material is tied to that process and session.
4. Decrypted messages authenticate or parse correctly under the matching implementation.
5. Decoded commands align with endpoint activity at the same timestamps.

A hunting workflow that scales

1. Start from a case-derived seed. A process, domain, file, alert, or memory match should define the first scope.
2. Inventory the host evidence. Build process ancestry, file provenance, user context, persistence, and network ownership.
3. Characterize the channel. Measure behavior before assigning a framework name.
4. Recover implementation evidence. Inspect the binary and memory for build, protocol, and configuration artifacts.
5. Test against benign peers. Compare to Go applications, DNS-heavy software, and management agents in the same environment.
6. Expand on stable joins. Pivot on infrastructure, signer, file lineage, and behavior that the case actually supports.

Claims to avoid

• “The file is larger than 10 MB, therefore Sliver.” Size is triage metadata.
• “The URI ends in .woff, therefore Sliver.” A mutable default is not attribution.
• “The DNS label is long, therefore tunneling.” Quantify the full behavior and compare it to local baselines.
• “We found a 32-byte value in memory, therefore it is the session key.” Demonstrate that it successfully explains authenticated protocol data.
• “No public rule matched, therefore the implant is clean.” Absence of a static signature says little about a configurable build.

Sliver is detectable. The durable detections are simply less dramatic than a magic byte pattern. They are joins between provenance, execution, runtime state, and communication.