Traffic Blending with CDN Redirectors: Hiding C2 in Legitimate Cloud Infrastructure

The traditional C2 redirector model puts nginx or Apache on a VPS between the implant and the C2 server. The redirector handles TLS, filters probe traffic, and forwards valid C2 requests to the backend. This model works, but it has a structural weakness: the redirector’s IP address is visible to the target network, and that IP resolves to a VPS provider. A defender who runs a reverse DNS lookup or IP reputation check sees a recently provisioned Linode, DigitalOcean, or AWS EC2 instance with no web presence. That’s suspicious before the traffic analysis even starts.

CDN redirectors solve this by placing the C2 traffic behind a content delivery network. The implant connects to a CDN-owned domain with a CDN-issued TLS certificate, over CDN IP ranges. The C2 server’s actual IP address never appears in the target’s network logs.

How It Works

The architecture adds a CDN layer between the implant and the redirector:

Agent → CDN edge (HTTPS, cloud TLS cert) → Origin server (HTTP) → nginx → Krait

The agent’s configured callback address is a CDN hostname — a CloudFront distribution or an Azure Front Door endpoint. The TLS handshake uses a certificate issued by the CDN provider (Amazon or Microsoft), presenting the CDN’s own domain. The connection terminates at the CDN’s nearest edge location, which forwards the request over HTTP to the origin server. Nginx on the origin server receives the forwarded request and proxies it to Krait’s HTTPS listener.

From the target network’s perspective, the outbound connection goes to a cloud provider’s IP range, uses a cloud provider’s TLS certificate, and resolves to a cloud provider’s domain. The only metadata visible to the defender is an HTTPS connection to d1234abcd.cloudfront.net or krait-xyz.azurefd.net — indistinguishable from any other CDN-hosted service.

Not Domain Fronting

This is worth clarifying because the technique is often confused with domain fronting. Domain fronting exploits the gap between the SNI hostname (visible in cleartext during the TLS handshake) and the HTTP Host header (encrypted inside the TLS tunnel). The client connects with SNI pointing to a benign domain, then sends the real destination in the Host header. CDN providers patched this — AWS CloudFront started rejecting mismatched SNI/Host headers in 2018. Azure followed.

CDN redirectors don’t exploit this gap. The SNI, Host header, and DNS all point to the same CDN endpoint. The CDN is genuinely routing traffic to the configured origin server — it’s functioning exactly as designed. There’s nothing to patch because nothing is being abused. The technique works because CDN infrastructure is legitimate infrastructure, and C2 traffic through it is architecturally identical to any other web application traffic through a CDN.

The distinction matters operationally. Domain fronting can be detected by inspecting TLS metadata. CDN redirectors can’t be detected by any single network signal — the traffic is real CDN traffic.

What the Defender Sees

A network security team investigating the connection finds:

DNS resolution. The callback hostname resolves to CDN edge IPs that rotate across the provider’s global anycast ranges. These IPs are shared by millions of legitimate sites. Blocking them means blocking the CDN.

TLS certificate. The certificate is issued by Amazon (for CloudFront) or Microsoft (for Front Door). Certificate chain is valid. Certificate transparency logs show a legitimate CDN-issued certificate — not a Let’s Encrypt cert on a VPS.

IP reputation. The destination IP belongs to a cloud provider’s published IP ranges. Every threat intelligence feed categorizes these ranges as legitimate cloud infrastructure, not as VPS hosting.

Traffic volume. CDN edge servers handle enormous traffic volumes. The C2 beacon — a few kilobytes every 30-60 seconds — is invisible in the aggregate.

Category. Web proxies and SWGs categorize CDN domains under the CDN provider’s category (cloud infrastructure, CDN, technology). Unless the organization blocks all CDN traffic (which would break most of the internet), the connection passes content filtering.

The C2 server’s real IP address appears only in the CDN provider’s origin configuration — a setting visible to the CDN account owner, not to the target network.

Operational Considerations

Client IP visibility. The CDN terminates the agent’s TLS connection at the edge. The origin server sees the CDN edge’s IP address, not the agent’s. Krait reads the forwarded-for header to recover the agent’s real IP, but this IP is the CDN edge location — useful for geolocation, but not the agent’s actual network address. Operators should be aware that session metadata shows CDN edge IPs rather than the target’s real IP.

Request limits. CloudFront allows POST request bodies up to 20GB with chunked transfer encoding — no blocker for C2 traffic, file transfers, or BOF output. Front Door has similar limits. Neither CDN imposes request-rate limits that would interfere with normal beacon intervals.

Latency. Adding a CDN hop adds 10-50ms of latency depending on geographic proximity to the nearest edge location. For a C2 framework with poll intervals measured in seconds, this is imperceptible.

Cost. CloudFront charges per-request and per-GB transferred. A single implant beaconing every 60 seconds generates roughly 44,000 requests per month. At CloudFront’s standard pricing, this costs approximately $0.50/month for requests and a few cents for data transfer. An engagement with dozens of implants stays under $20/month. Azure Front Door Standard is similarly priced.

Forensic trail. The CDN account used to create the distribution is a forensic link between the infrastructure and the operator. Use purpose-built cloud accounts with no connection to other infrastructure. CDN distributions can be torn down instantly at engagement end.

Setup

Krait generates the complete redirector configuration from the operator CLI or Web UI. The redirector cloudfront command produces an nginx reverse proxy config and a step-by-step CloudFront setup guide tailored to the operator’s origin server hostname and Krait port. The Web UI’s Redirector page offers the same functionality with a form interface.

The output includes the nginx config for the origin server, the CloudFront distribution parameters, managed cache and origin request policy IDs, and an AWS CLI command to create the distribution in one shot. Azure Front Door follows the same pattern — Terraform modules handle the provisioning, or the operator can set it up manually from the generated config.

For lab testing, Krait ships Terraform modules that deploy the full CDN redirector infrastructure with a single command and tear it down just as quickly.

When to Use CDN Redirectors

CDN redirectors make sense for any engagement where the target has network visibility — which is most engagements. The cost is negligible, the setup takes minutes, and the defensive uplift required to detect CDN-routed C2 traffic is substantial. A SOC that blocks VPS IP ranges, flags unknown domains, or inspects TLS certificates for anomalies won’t catch traffic that uses a major cloud provider’s own infrastructure.

The technique composes with Krait’s traffic profiles. An agent using the Slack profile through a CloudFront redirector appears as Slack API traffic to a CDN domain — multiple layers of legitimacy that each require independent investigation to see through.

The tradeoff is attribution risk. CDN accounts leave a paper trail that VPS hosting doesn’t (cloud providers verify payment methods and enforce terms of service). Operational security around the CDN account itself — purpose-built accounts, clean payment methods, no cross-contamination with other infrastructure — is essential.