| name | building-c2-infrastructure-with-sliver-framework |
| description | Build and configure a resilient command-and-control infrastructure using BishopFox's Sliver C2 framework with redirectors, HTTPS listeners, and multi-operator support for authorized red team engagements. |
| domain | cybersecurity |
| subdomain | red-teaming |
| tags | ["red-team","c2-framework","sliver","command-and-control","adversary-simulation","infrastructure","post-exploitation"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| d3fend_techniques | ["File Metadata Consistency Validation","Certificate Analysis","Application Protocol Command Analysis","Content Format Conversion","File Content Analysis"] |
| nist_csf | ["ID.RA-01","GV.OV-02","DE.AE-07"] |
Building C2 Infrastructure with Sliver Framework
Overview
Sliver is an open-source, cross-platform adversary emulation framework developed by BishopFox, written in Go. It provides red teams with implant generation, multi-protocol C2 channels (mTLS, HTTP/S, DNS, WireGuard), multi-operator support, and extensive post-exploitation capabilities. Sliver supports beacon (asynchronous) and session (interactive) modes, making it suitable for both long-haul operations and interactive exploitation. A properly architected Sliver infrastructure uses redirectors, domain fronting, and HTTPS certificates to maintain operational resilience and avoid detection.
When to Use
- When deploying or configuring building c2 infrastructure with sliver framework capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Most Often Missed & How to Confirm
- Default C2 profile left intact. Operators ship implants on Sliver's stock HTTP C2 config (default URIs, headers, and poll paths) — fingerprintable. Customize the C2 profile (
profiles / c2profiles) and randomize URIs before generating.
- Unmodified TLS/JARM fingerprint. Sliver's default mTLS and HTTPS listeners have a known JARM hash. Front with a real cert + redirector and validate JARM differs from the published default.
- No kill date or canary. Implants without
--kill dates and DNS/file canaries linger and burn infra. Set them at generate time.
- Skipping egress-representative testing. Listener "works" from the operator box but dies behind proxy/TLS-inspection on the target egress.
- Redirector not dropping non-matching paths. Unmatched requests should 302 to a decoy, not proxy through.
- How to confirm: beacon actually checks in —
beacons shows the Last Check-in timestamp advancing, use <id> opens an interactive session, and ps/netstat return live data. OPSEC check: run jarm against your own listener and curl an unmatched path on the redirector to confirm the decoy response. Don't conclude the infrastructure is dead until you have detonated a test implant from a host on a representative egress network, not just the team server LAN.
Prerequisites
- Familiarity with red teaming concepts and tools
