Building Stealthy C2 Infrastructure

Modern Red Teaming – Part 2

Introduction

In modern red team operations, payloads and exploits rarely fail first — infrastructure does. Security controls today are highly effective at detecting suspicious domains, exposed servers, and noisy communication patterns. As a result, attackers must invest heavily in stealthy, resilient Command-and-Control (C2) infrastructure.

This document provides a practical, high-level walkthrough of how modern red teams design layered C2 infrastructure that:

• Survives reputation-based blocking

• Avoids direct exposure of backend servers

• Blends into legitimate enterprise network traffic

• Minimizes forensic and attribution risk

This is a conceptual and educational rewrite, intended for understanding attacker tradecraft and improving defensive awareness.

---

Core Design Principles

A stealthy C2 infrastructure follows a few fundamental principles:

• Separation of roles – Domains, redirectors, and C2 servers should never be the same system.

• Reputation abuse – Infrastructure should leverage trusted providers and aged assets.

• Traffic normalization – C2 traffic must look like normal web or API traffic.

• Minimal exposure – Backend servers should never be directly reachable from the internet.

• Operational resilience – Any single layer should be disposable without losing the entire operation.

---

High-Level Architecture

A common layered design looks like this:

Victim Payload / Dropper
        ↓
   Cloudflare DNS + Proxy
        ↓
   Redirector VPS (NGINX)
        ↓
   Backend C2 Server (Sliver)

Why this works

• Cloudflare absorbs scanning, reputation checks, and IP exposure.

• Redirectors act as a sacrificial layer that can be destroyed or rotated quickly.

• Backend C2 remains hidden, stable, and locked down.

Each layer reduces detection probability and limits blast radius.

---

Step 1 – Domain and DNS Preparation

Domain Usage Strategy

Domains used for C2 should:

• Be aged or previously used for legitimate purposes

• Have clean reputation and DNS history

• Be capable of blending into enterprise allow-lists

Once acquired, domains are configured through Cloudflare to benefit from:

• Proxying and IP masking

• TLS termination

• Reputation shielding

DNS Setup

Create DNS records:

• example-domain.com

• www.example-domain.com

Point both to the redirector VPS IP and enable the Cloudflare proxy (orange cloud).

Verification:

nslookup example-domain.com

Expected: Cloudflare IP addresses, not the VPS IP.

Reference: https://developers.cloudflare.com/dns/

---

Step 2 – Redirector Deployment (NGINX)

Purpose of Redirectors

Redirectors ensure:

• The real C2 IP is never exposed

• Traffic can be shaped, filtered, or forwarded

• Infrastructure can be rapidly rotated

NGINX is commonly used due to:

• Performance

• Flexibility

• Familiarity in enterprise environments

Deployment Using Docker

Install Docker:

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable --now docker

Install Docker Compose:

curl -L https://github.com/docker/compose/releases/download/v2.29.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

Docker Compose configuration:

version: "3.8"
services:
  nginx:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "81:81"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Start the service:

docker compose up -d
docker ps

Admin UI:

http://<redirector-ip>:81

Reference: https://nginxproxymanager.com/

---

Step 3 – Backend C2 Server (Sliver)

Why Sliver

Sliver is a modern, open-source C2 framework designed for:

• Adversary simulations

• Red team engagements

• Secure, encrypted communications

It supports:

• HTTP(S), mTLS, and DNS transport

• Cross-platform implants

• Flexible traffic shaping

Installation

wget https://github.com/BishopFox/sliver/releases/latest/download/sliver-server_linux
chmod +x sliver-server_linux
sudo mkdir -p /opt/sliver
sudo mv sliver-server_linux /opt/sliver/
sudo /opt/sliver/sliver-server_linux

Reference: https://github.com/BishopFox/sliver

---

Step 4 – HTTP C2 Traffic Customization

Default C2 profiles are noisy and predictable. Modern operations always customize HTTP profiles.

Key areas to modify:

• URL paths

• HTTP headers

• User-Agent strings

• Request timing and jitter

• Cookie usage

Backup config:

cp ~/.sliver/configs/http-c2.json ~/.sliver/configs/http-c2.json.bak

Reference profiles: https://github.com/BishopFox/sliver/tree/master/configs

Goal: make C2 traffic indistinguishable from legitimate SaaS or API traffic.

---

Step 5 – Payload Hosting and Decoy Content

Payloads should never look like payloads.

Best practices:

• Use legitimate-looking paths (e.g., /updates, /api/v2/status)

• Serve decoy HTML or JSON alongside binaries

• Host content through the same domain used for C2

Example:

sudo apt install -y apache2
cp beacon.bin /var/www/html/microsoft-updates
chown -R www-data:www-data /var/www/html/

---

Step 6 – Firewall Isolation (Critical OPSEC)

The backend C2 server must never be internet-facing.

Only allow traffic from redirectors:

sudo iptables -A INPUT -p tcp -s <REDIRECTOR_IP> --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <REDIRECTOR_IP> --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j DROP
sudo iptables -A INPUT -p tcp --dport 443 -j DROP
sudo iptables -L -n -v

Testing:

curl http://<C2_IP>
curl https://<C2_IP>

---

Step 7 – Memory-Only Payload Execution

Disk-based payloads increase detection risk.

Memory-only execution:

• Reduces forensic artifacts

• Evades basic AV detections

• Limits post-incident evidence

Example C++ dropper: https://github.com/0xFFF-cmd/Sliver/blob/main/Dropper.cpp

Typical flow:

1. Download encrypted shellcode

2. Allocate executable memory

3. Execute without touching disk

---

OPSEC Hardening Techniques

• Rotate redirectors regularly

• Change URLs and filenames

• Serve legitimate content permanently

• Restrict Cloudflare access by country

• Monitor infrastructure reputation continuously

Stealth is achieved through consistency, not randomness.

---

Defensive Perspective

For defenders, this infrastructure demonstrates:

• Reputation alone is not a trust signal

• Proxy layers hide attacker intent

• Long-lived, low-noise traffic is dangerous

Effective defense requires:

• Behavioral analysis

• TLS inspection (where legal)

• Correlation across DNS, proxy, and endpoint telemetry

---

Key Takeaway

Modern red team infrastructure is engineered, layered, and maintained like real production systems.

Understanding these patterns enables:

• More realistic red team engagements

• Better purple team collaboration

• Stronger SOC detection strategies

---