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
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.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.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.Layer 3 — URI prefix routing
The URI prefix determines which C2 backend receives the request. Each framework has its own path:
Requests with a valid header but a non-matching URI prefix fall through to the decoy page.
| 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 |
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) |
mod_autoindex) is disabled.
Decoy page
Requests that fail header validation receive a CloudEdge CDN maintenance page:/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:Sliver and Havoc show FAILED — is that a problem?
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?
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?
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.