# Sliver C2 Framework
Sliver is an open-source command-and-control (C2) framework developed by BishopFox, designed to support adversary emulation, red team operations, and penetration testing across Windows, Linux, and macOS environments. It was created to give security teams a capable, free alternative to expensive commercial frameworks such as Cobalt Strike, while producing operationally realistic simulations of the techniques real threat actors use. Written in Go, Sliver addresses a specific gap: most open-source C2 tools either lack mature capability sets or produce predictable binary signatures that defenders can trivially block. Sliver solves this by compiling unique, obfuscated implants per engagement, supporting multiple encrypted transport protocols, and offering an extensible plugin architecture. Its rapid adoption by both offensive security professionals and actual adversary groups makes it a critical subject for defenders to understand deeply.
---
Sliver is a cross-platform, open-source adversary simulation framework that provides operators with a server-client architecture for managing implants deployed on target systems. The server component runs on a Linux host and exposes a multiplayer console interface. Operators connect to the server, generate implants, and manage active sessions or beacons from that central console.
Sliver is not a vulnerability scanner, an exploitation framework, or a payload delivery mechanism in isolation. It is specifically a post-exploitation and command-and-control platform: it assumes the operator has already achieved initial code execution on a target and now needs to maintain access, move laterally, and conduct mission objectives. This distinguishes it from tools like Metasploit, which includes a full exploitation stack, or tools like Cobalt Strike, which is commercially licensed and includes a graphical interface. Sliver is entirely terminal-driven and open-source.
The framework has two primary implant operating modes. Session implants maintain a persistent interactive connection between the operator console and the compromised host, enabling real-time command execution. Beacon implants operate on a configurable sleep-and-callback cycle, contacting the C2 server at intervals and executing queued tasks, then going dormant. This beacon behavior closely mirrors how mature threat actors operate to reduce noise and evade behavioral detection.
Sliver is not the same as a remote access trojan (RAT) in the traditional malware sense. It is an operator-controlled framework that generates implants on demand. Each implant is uniquely compiled, not a static binary distributed broadly. The distinction matters for detection: defenders cannot rely on a fixed file hash to identify Sliver implants because every generated binary is structurally different.
Variants include Sliver v1 (session-only) and the current Sliver v2 architecture, which introduced the beacon mode, the armory system for third-party tool integration, and WireGuard-based transport.
---
Understanding Sliver's mechanics requires tracing the full operational workflow from server setup through active implant management.
Server Initialization and Operator Authentication
The Sliver server is compiled as a single Go binary and run on a Linux host accessible to the operator team. On first launch, it generates cryptographic material: a per-server certificate authority (CA), operator certificates, and configuration files. Operators authenticate to the server using mutual TLS client certificates. This design prevents unauthorized parties from connecting to the C2 infrastructure even if the server address is discovered. Each operator gets a named profile with corresponding certificate, which means all operator activity is logged and attributable within the team.
Implant Generation
When an operator runs the generate command, Sliver compiles a new Go binary from source on the server. Several obfuscation mechanisms apply during this compilation step. The garble tool, which Sliver incorporates by default, randomizes symbol names, strips debug information, and scrambles string literals in the resulting binary. This means two implants generated back-to-back for the same target will differ in byte content, file hash, and internal symbol layout. The operator specifies the target OS and architecture, the communication protocol (mutual TLS, HTTP/S, DNS, or WireGuard), the callback address, and whether the implant operates as a session or beacon.
For beacon implants, the operator sets a jitter value alongside the sleep interval. A beacon configured with a 60-second sleep and 30-second jitter will call back randomly between 30 and 90 seconds. This variability disrupts time-based detection rules that look for regular callback intervals, which is a common heuristic in network monitoring platforms.
Communication Channels
Sliver's transport flexibility is operationally significant. Mutual TLS provides an encrypted, certificate-authenticated channel over TCP. The WireGuard transport builds a full encrypted tunnel, routing implant traffic inside a VPN-like connection that appears as normal WireGuard UDP traffic. The HTTP/S listener accepts implant callbacks over standard web ports, with traffic structured to resemble benign web browsing if profiles are customized. DNS-based C2 encodes operator commands and implant responses inside DNS queries and responses, making it usable in environments where all TCP and UDP traffic except DNS is blocked at perimeter firewalls.
Post-Exploitation Capabilities
Once a session or beacon is active, operators have access to built-in commands covering the full post-exploitation lifecycle. Process injection allows the operator to inject shellcode into running processes, migrating the implant's execution context to avoid detection of the initially compromised process. The execute-assembly command loads .NET assemblies directly into memory without writing files to disk, which defeats many endpoint detection products that focus on file-based scanning. The socks5 command turns a compromised host into a SOCKS proxy, allowing the operator to route traffic through it to reach internal network segments.
Pivoting extends operator reach deeper into target networks. Sliver supports TCP and named-pipe based pivots, where one implant relays C2 traffic for another implant running on an internal host with no direct internet access. This mirrors how sophisticated threat actors traverse network segmentation boundaries without opening new external connections from each compromised machine.
Armory and Extensions
The Sliver armory is a package registry of community-developed tools that operators can install into the framework. These include BOFKIT (Beacon Object File support), SharpCollection integrations, and various in-memory execution tools. This extensibility means that a team can customize Sliver for specific environments without modifying the core framework.
Concrete Scenario: Internal Red Team Assessment
Consider a red team conducting an assumed-breach assessment against a financial services firm. The team generates a Windows beacon implant using HTTPS transport configured to callback to an operator-controlled domain. The implant is delivered through a phishing simulation. Once executed on the target workstation, it calls back over port 443 to the operator server. The operator queues tasks: enumerate running processes, dump credentials from LSASS memory using an in-memory tool loaded through execute-assembly, and establish a SOCKS proxy to reach the internal Active Directory environment. Because the beacon runs on a randomized sleep cycle and all traffic is encrypted over HTTPS, the activity is indistinguishable from normal browser traffic at the perimeter firewall. The operator then pivots to a domain controller by routing through the SOCKS proxy and completes the assessment objective. This scenario illustrates precisely why Sliver is effective for realistic simulation and why defenders need behavioral and network-level controls rather than signature-based detection alone.
---
Sliver's significance extends far beyond its role as a red team convenience tool. Its real-world adoption by threat actors changes the defensive calculus in meaningful ways.
Threat Actor Adoption
Multiple threat intelligence reports published by groups including Microsoft Threat Intelligence, Proofpoint, and CISA have documented Sliver in the hands of nation-state and financially motivated threat actors. In 2023, CISA issued advisory AA23-061A identifying Sliver as a tool used by threat actors in campaigns targeting critical infrastructure, noting specifically its use in post-exploitation phases following initial access through phishing or exploitation of public-facing applications. This is not a hypothetical risk: Sliver is actively present in real intrusions, not just authorized assessments.
Detection Complexity
A common misconception is that because Sliver is open-source and well-documented, it must be easy to detect. This is incorrect. The per-compilation obfuscation, multiple transport options, and in-memory execution capabilities make Sliver-based activity difficult to detect through conventional endpoint and network monitoring approaches. Organizations that rely primarily on antivirus file scanning will miss most Sliver implants. Effective detection requires behavioral analysis: monitoring for unusual parent-child process relationships, detecting LSASS memory access from unexpected processes, identifying anomalous DNS query patterns, and correlating network connections to known Sliver listener infrastructure.
Business Impact
Organizations that fail to account for Sliver in their threat models and detection engineering programs face a specific risk: their security controls may perform adequately against older, simpler tools in tabletop exercises, but fail completely when a real-world attacker uses a mature C2 framework like Sliver. Red teams that use Sliver in authorized assessments expose exactly this gap. When assessments reveal that a full beacon-based intrusion ran undetected for two weeks during a simulated engagement, that finding has direct implications for the organization's breach exposure time and its ability to contain real incidents.
Misconception: Open-Source Equals Low Sophistication
Some security teams dismiss Sliver because it is free and publicly available, associating cost with capability. Commercial frameworks are not categorically more powerful than Sliver. The framework has feature parity with Cobalt Strike in most post-exploitation scenarios and in some transport options exceeds it. The open-source nature of Sliver is actually an advantage for defenders because the source code is available for analysis, but only if defenders invest the time to read it and build detection logic from it.
---
CDA approaches Sliver through the Planetary Defense Model (PDM) under the Threat Intelligence Domain (TID), applying Predictive Defense Intelligence (PDI) to position client organizations ahead of Sliver-based threats before active intrusions occur.
The core PDI principle, "See the threat before it sees you," is directly applicable here because Sliver leaves predictable infrastructure traces even when the implants themselves are obfuscated. C2 servers require domain registration, TLS certificate issuance, and hosting. CDA's threat intelligence pipeline continuously monitors certificate transparency logs, passive DNS data, and hosting provider network ranges for infrastructure patterns consistent with Sliver deployments. Newly registered domains using common Sliver listener configurations, self-signed certificates with structural characteristics matching Sliver's default CA output, and hosting patterns associated with known offensive operators all become early warning indicators. Client organizations receive this intelligence before the infrastructure is used against them.
From the VSD (Vulnerability and Security Design) domain, CDA maps Sliver's capabilities directly to the control gaps present in client environments. Rather than generic recommendations, CDA produces specific detection engineering content: YARA rules targeting Sliver's in-memory artifacts, Sigma rules for process injection patterns consistent with Sliver's execution model, and network detection rules for Sliver's WireGuard and DNS transport behaviors. These rules are derived from analysis of Sliver's source code and known operator tradecraft, not from generic behavioral baselines.
CDA also incorporates Sliver into adversary emulation programs for clients. Using Sliver in authorized red team operations under CDA supervision allows organizations to test their detection and response capabilities against the same tool their adversaries use. Findings from these exercises feed directly into prioritized control improvements, closing the loop between intelligence collection and defensive action. This is what separates CDA's approach from generic red teaming: every finding is mapped back to a specific threat actor group known to use Sliver, giving the remediation work direct relevance to the client's actual risk profile.
---
---
---