Building C2 Infra with Sliver in an Isolated Lab for Defensive Research

Every time a SOC analyst opens a ticket for a suspicious beacon, there is a real chance nobody on the team has ever watched a command-and-control channel operate with their own eyes. Red-team operators run Sliver, Mythic and Havoc every day, yet most defenders only know those frameworks from Mandiant report screenshots. That gap is dangerous: you cannot reliably detect a behaviour you have never observed. This guide walks through building an isolated, internet-less Sliver lab whose only purpose is to generate realistic, controlled, documented telemetry so a Blue Team can write and validate detection rules against indicators it produced itself. Everything below happens inside an air-gapped VLAN and carries zero legal risk, because the lab talks to nobody outside 10.50.0.0/16.

What a C2 is, and why Sliver for a defensive lab

A command-and-control (C2) framework is the operator side of post-exploitation: a server that receives check-ins from implants (also called beacons or agents) running on compromised hosts, and a tasking channel that pushes commands back. Sliver, maintained by BishopFox, is written in Go and ships cross-platform implants for Windows, Linux and macOS over mTLS, WireGuard, HTTP(S) and DNS. For a defensive lab it beats the alternatives on three axes: unlike Cobalt Strike it is free and its source is auditable, so you can read exactly what an implant does; unlike Mythic it needs far less infrastructure to stand up. That auditability matters because you are trying to map behaviour to detections, and a black box teaches you nothing you can generalise.

Threat model: why defenders must run the attacker's tooling

Detection engineering fails when it is built on theory. Vendors publish generic rules, teams import them, and the first real incident reveals the rule fired on a field that the operator never touches, or missed the one that mattered. Running the offensive tooling yourself closes that loop. You learn Sliver's default named pipes, its process-injection patterns, the exact API calls behind execute-assembly, and the network cadence of an mTLS beacon. You also learn its evasion knobs, so when a rule stops firing you understand which knob the adversary turned. The lab is not about attacking anyone; it is a telemetry factory whose output is Sigma rules, IOCs and hunting hypotheses you can trust because you generated the ground truth.

Lab architecture: VLANs, pfSense and full egress isolation

The topology is deliberately simple and strictly segmented. A Debian 12 VM acts as the teamserver with 4 vCPU and 8 GB RAM. It sits on a C2 VLAN, 10.50.10.0/24. The targets live on a separate victim VLAN, 10.50.20.0/24. Between them sits a pfSense firewall whose ruleset permits traffic only between those two subnets and applies zero NAT outbound: the lab has no route to the internet, by design. This matters for two reasons. First, an implant that cannot phone home to a real address cannot leak to a third party if you make a mistake. Second, it forces you to model the network the way a segmented enterprise actually looks. If you have not built a base lab yet, Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite is a solid foundation to reuse here.

Installing the teamserver, step by step

The quick path is curl https://sliver.sh/install | sudo bash, but in an isolated environment you never pipe a remote script to root. Instead, download the signed release binary on a connected machine, verify it with cosign verify-blob against BishopFox's published key, compute its SHA-256, and carry it in on a dedicated USB stick. On the Debian VM, place the binary in /usr/local/bin/sliver-server, create a non-root sliver service account, and run the server under systemd with a hardened unit (NoNewPrivileges, ProtectSystem=strict, a private WorkingDirectory). Start the console with sliver-server and generate an operator config with new-operator --name analyst --lhost 10.50.10.5. Keeping the operator profile scoped to the C2 VLAN address means a stray implant can never reach a management interface it should not.

Generating implants and tuning profiles

Generate a first implant with generate --mtls 10.50.10.5:8443 --os windows --arch amd64 --skip-symbols --save ./payloads. The --skip-symbols flag strips Go symbol tables, shrinking the binary by roughly 40% and slowing quick reverse engineering, while leaving enough to debug your own lab. Drop this unobfuscated implant on a Windows 11 21H2 VM with Defender real-time protection on and it typically dies within about 12 seconds. That is not a failure; it is a measurement. You now have a clean signal for what Defender catches and a baseline to compare against when you deliberately add evasion. To study the delivery chain that precedes the beacon, pair this with Simulated Initial Access: Macros, LNK and ISO in an Isolated Windows 11 Lab.

From beacon check-in to detection rules

The educational payoff starts the moment the beacon checks in. Every operator command produces a distinct footprint: getsystem touches token duplication, execute-assembly spawns a sacrificial process and loads the CLR, sideload maps an unbacked DLL. Instrument the victim hosts with Sysmon using the SwiftOnSecurity configuration, ship events with an Elastic Agent into a local cluster, and correlate against Sigma rules. Across three focused sprints a small team can map dozens of new detections, from Sliver's default named-pipe names to rundll32 spawns with no command line. The full pipeline of turning an IOC into a maintainable rule is documented in Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule, which pairs directly with the events this lab emits.

Lateral movement inside a mini Active Directory

Lateral movement is where the lab earns its keep. Stand up a mini-AD with two domain controllers, four workstations and a file server, mirroring a mid-size customer topology. With the initial Sliver implant on a low-privilege host, use Rubeus for Kerberoasting, then pivot over a WireGuard tunnel to reach a domain controller without ever touching it directly from the teamserver. The techniques in Active Directory Pentest: Step-by-Step Kerberoasting in a GOAD Lab and Pivoting with Chisel and Ligolo-ng: Segmented Networks in a Pentest Lab are the same logic with different tooling. Every hop leaves traces: 4624 type 3 logons, 4769 tickets with weak RC4 encryption, anomalous WMI connections. Each of those becomes hunting training material with a known-good and a known-bad sample.

Hardening the detections and closing the loop

A lab without a feedback loop is a demo. After each run, treat every detection you wrote as a hypothesis and try to bypass it. Turn on Sliver's evasion features one at a time (traffic reshaping, jitter, alternative transports) and watch which rules survive. Rules that only match a default string are brittle; rules anchored on behaviour (an unbacked memory region executing, a parent-child chain that should never occur) survive tuning. Version your Sigma rules in git, tag each with the ATT&CK technique it covers, and record the exact implant profile that generated the source events so a teammate can reproduce the signal. That reproducibility is the difference between a rule you trust in production and a rule you hope works.

Pitfalls and lab OPSEC

Lab OPSEC matters more than people assume. Even air-gapped, VM snapshots containing live implants have leaked to public repositories when someone uploaded them by accident. The rule set is simple: lab VMs live on a LUKS-encrypted datastore, snapshots never leave the host, and any artefact that must exit (a Sigma rule, an IOC, a demo video) passes manual review first. This connects to the discipline in OPSEC for Security Researchers: Building a Personal Threat Model and Metadata Hygiene: Stripping EXIF, PDF and Office Before You Publish. The classic self-inflicted wound is publishing a report PDF whose metadata hands an adversary the researcher's username, hostname and the file path on a personal laptop.

Deployment checklist

Before you call the lab ready, confirm each item: pfSense enforces subnet-only rules with zero outbound NAT; the teamserver binary was cosign-verified and runs under a hardened non-root systemd unit; operator configs are scoped to the C2 VLAN; Windows targets run Sysmon (SwiftOnSecurity config) shipping to a local Elastic cluster; the mini-AD mirrors a realistic topology; every Sigma rule is versioned with an ATT&CK tag and a reproducible source profile; snapshots sit on LUKS and never leave the host; and every exported artefact went through metadata review. If any line is unchecked, the telemetry you collect is not yet trustworthy ground truth.

FAQ: Is running a C2 framework in a lab legal?

Yes, provided the C2 server and every implant stay inside infrastructure you own and control, with no route to third-party systems. The legal exposure in offensive tooling comes from touching machines you are not authorised to touch. An air-gapped VLAN with zero outbound NAT removes that exposure entirely: the implant literally has nowhere to go. Keep written scope for the lab, label the VMs, and never attach a real production credential or a real customer's data to the environment.

FAQ: Sliver, Mythic or Cobalt Strike for a defensive lab?

For a defensive telemetry lab, Sliver is usually the best starting point: it is free, open source and auditable, so you can trace every behaviour to source and generalise your detections. Mythic is excellent when you want to model a diverse agent ecosystem but costs more setup effort. Cobalt Strike represents a large share of real intrusions, so mature teams eventually add it to broaden coverage, but its licensing and closed nature make it a poor first tool for learning. Start with Sliver, understand the fundamentals, then expand.

Conclusion

If you defend an organisation and have never watched a Sliver beacon on a screen you control, your detection is theoretical. Block out a full day, assemble the lab with pfSense plus Debian plus two Windows targets, generate an unobfuscated implant, let it run commands for thirty minutes, and open Sysmon. You will walk away with more concrete hunting material than several paid courses combined, and with zero legal risk because everything happens inside the 10.50.0.0/16 VLAN that talks to nobody outside. The point is not to become an attacker; it is to make your defence empirical instead of aspirational.