Redirector Overview

Apache redirector design, three-layer security model, and connectivity testing.

The Apache redirector is the only lab component with a public IP address. It sits in its own isolated VPC (10.60.0.0/16) that simulates an external VPS provider — separate from the TeamServer VPC (172.31.0.0/16) where Mythic, Sliver, and Havoc live. Implants never contact C2 servers directly; they always reach the redirector first.

Security layers

Scanner blocking, header validation, and URI-based C2 routing in depth.

SSL certificate

Obtain a Let’s Encrypt certificate with Certbot after DNS propagates.

Logs

Monitor C2 callbacks, decoy page responses, and blocked scanner traffic.

Terraform variables

Customize URI prefixes, header name/value, and scanner blocking before deploying.

Network position

[ Target / Implant ]
        │
        │  HTTPS/HTTP (public internet)
        ▼
Redirector VPC (10.60.0.0/16)
  Apache :80/:443 ── Elastic IP (public)
  X-Request-ID header validation
  URI prefix routing
  Scanner/AV blocking (redirect.rules)
        │
        │  VPC peering
        ▼
TeamServer VPC (172.31.0.0/16)
  Mythic  (no public IP)
  Sliver  (no public IP)
  Havoc   (no public IP)

VPC peering between the Redirector VPC and the TeamServer VPC is created automatically by Terraform. Route tables in both VPCs are updated so the redirector can reach each C2 server’s private IP, and C2 servers can send responses back. No C2 server is directly reachable from the public internet.

Three-layer security model

Every inbound request passes through three sequential checks before Apache proxies it to a C2 backend. Requests that fail any check never reach the C2 servers.

1. Layer 1 — redirect.rules (scanner blocking)

   /etc/apache2/redirect.rules is downloaded from BaddKharma/redRules at boot. It matches requests from known AV vendor IP ranges, security scanner CIDRs, and TOR exit nodes and returns 403 Forbidden. AWS and Azure IP blocks are commented out so your own C2 callbacks are never blocked.

   Scanner blocking is enabled by default (enable_redirector_htaccess_filtering = true) and disabled in closed-environment mode.

2. Layer 2 — header validation

   Requests that pass the scanner check must include the X-Request-ID header with the correct token. The header name defaults to X-Request-ID and the token is auto-generated at deploy time — both are configurable via Terraform variables.

   Requests without a valid header receive the CloudEdge CDN decoy page (HTTP 200). Requests with a valid header proceed to URI routing.

3. Layer 3 — URI prefix routing

   The URI prefix determines which C2 backend receives the request. Each framework has its own path:

   URI prefix	Backend	How the path is forwarded
   /cdn/media/stream/	Mythic	Prefix stripped — Mythic receives the remainder
   /cloud/storage/objects/	Sliver	Prefix stripped — Sliver receives the remainder
   /edge/cache/assets/	Havoc	Full path preserved — Havoc validates the URI

   Requests with a valid header but a non-matching URI prefix fall through to the decoy page.

Havoc is the only backend that receives the full path including the URI prefix. This is required because Havoc’s listener validates that incoming URIs match the demon paths baked into the payload at generation time.

Apache modules

The setup script enables the following modules at boot:

Module	Purpose
mod_rewrite	URI matching and conditional rewrites for all three routing layers
mod_proxy / mod_proxy_http	Forward matched requests to C2 backends over plain HTTP
mod_headers	Inject X-Forwarded-For on proxied requests
mod_ssl	TLS termination on port 443
mod_deflate	Response compression
mod_proxy_balancer / mod_lbmethod_byrequests	Load balancing infrastructure (available for future use)

Directory listing (mod_autoindex) is disabled.

Decoy page

Requests that fail header validation receive a CloudEdge CDN maintenance page:

<div class="container">
  <h1>CloudEdge CDN</h1>
  <p>Content delivery service is currently undergoing scheduled maintenance.<br>
  All services will be restored shortly.</p>
  <div class="status">System Status: Maintenance Window Active</div>
  <p class="ref">Reference: CE-2024-MAINT-001</p>
</div>

The page returns HTTP 200 and is served from /var/www/html/decoy/. It is the DocumentRoot for both VirtualHosts, so any request that does not match a proxy rule falls through to it automatically.

Connectivity test

A pre-installed script verifies the full redirector stack in one command. Run it from the redirector after obtaining an SSL certificate:

sudo /home/admin/test_redirector.sh

Expected output after initial deployment (before configuring Sliver and Havoc listeners):

===== Redirector Connectivity Test =====

[*] Apache status:
● apache2.service - The Apache HTTP Server
     Active: active (running) ...

[*] Enabled Apache modules:
 deflate_module (shared)
 headers_module (shared)
 proxy_module (shared)
 proxy_http_module (shared)
 rewrite_module (shared)
 ssl_module (shared)

[*] Active VirtualHosts:
*:80                   yourdomain.tld (...redirector-http.conf:1)
*:443                  yourdomain.tld (...redirector-https.conf:1)

[*] Testing direct backend connectivity:
  Mythic: OK
  Sliver: FAILED
  Havoc:  FAILED

[*] Testing decoy page (no header - should get CloudEdge CDN page):
<!DOCTYPE html>
<html lang="en">
...

[*] Testing C2 routing WITH correct header:
< HTTP/1.1 404 Not Found

[*] Testing C2 routing WITHOUT header (should get decoy):
< HTTP/1.1 200 OK

[*] Header validation:
  Header:  X-Request-ID: <your-token>

[*] URI routing (requires correct header):
  /cdn/media/stream/ -> Mythic  (172.31.x.x)
  /cloud/storage/objects/ -> Sliver  (172.31.x.x)
  /edge/cache/assets/ -> Havoc   (172.31.x.x)

Sliver and Havoc show FAILED — is that a problem?

No. FAILED means the script could not reach those backends directly, which is expected because Sliver and Havoc have no listeners running yet. You configure listeners in Part 5 (Sliver) and Part 6 (Havoc). Re-run the test script after starting each listener to confirm the backend becomes reachable.

C2 routing WITH header returns 404 — is that correct?

Yes. The request was proxied to Mythic (header validation passed), but Mythic has no agent configured yet so it returns 404. If you receive the decoy page instead of a 404, the header value is wrong — retrieve the active token with terraform output deployment_info.

C2 routing WITHOUT header returns 200 — is that correct?

Yes. The decoy page returns HTTP 200. A request without a valid X-Request-ID header should always receive the decoy page, never be proxied to a C2 server.

Updating redirect.rules manually

The rules file is downloaded once at boot. To pull the latest version:

curl -sL "https://raw.githubusercontent.com/BaddKharma/redRules/main/redirect.rules" \
  -o /etc/apache2/redirect.rules
sudo systemctl reload apache2

Verify the rule count after updating:

grep -c 'RewriteCond' /etc/apache2/redirect.rules

Re-run sudo /home/admin/test_redirector.sh after updating rules to confirm Apache reloaded cleanly and all backends are still reachable.