Domain Fronting#

The DomainFronting class routes C2 traffic through CDN edge nodes by exploiting the split between TLS SNI and the HTTP Host header. The TLS handshake connects to a high-reputation CDN domain (the “front”), while the Host header carries the real C2 domain. The CDN edge decrypts TLS, reads the Host header, and forwards to the origin.

CDN providers actively detect and block domain fronting. AWS and Azure deployed mitigations in 2018/2022. Use this as a secondary transport with fallback, not as your primary C2 channel.

Supported CDNs#

Configuration#

fronting:
  rules:
    - domain: "c2.internal.com"          # real C2 domain (goes in Host header)
      front_domain: "d1234.cloudfront.net"  # CDN domain (goes in TLS SNI)
      cdn: "cloudfront"
      enabled: true
      timeout_seconds: 30
      ssl_verify: true
      health_probe_url: "https://d1234.cloudfront.net/health"
      custom_headers:                      # optional extra headers
        X-Custom: "value"

How Requests Flow#

Implant                CDN Edge               InfraGuard (origin)
  |                       |                        |
  |-- TLS SNI: d1234 --->|                        |
  |   Host: c2.internal  |                        |
  |                       |-- Host: c2.internal -->|
  |                       |   (decrypted)          |
  |                       |                        |-- upstream C2
  |<-- response ----------|<-- response -----------|

The implant connects to the CDN front domain at the TLS layer. The CDN sees the Host header and routes to the InfraGuard origin, which then forwards to the upstream C2 server.

CDN Header Stripping#

CDN providers inject headers that identify the edge node and can fingerprint the fronting technique. InfraGuard strips these from responses before they reach the client:

• CloudFront: X-Amz-CF-Pop, X-Amz-CF-Id, X-Cache, Via
• Azure CDN: X-Azure-Ref, X-MS-Request-Id, X-MSEdge-Ref
• Google Cloud: X-Cloud-Trace-Context, X-Goog-Request-Id, Server-Timing
• Fastly: X-Served-By, X-Cache-Hits, X-Timer, Fastly-Restarts
• Generic: X-CDN, X-Edge-Location, Age

Content-Encoding and Transfer-Encoding headers are also stripped since httpx auto-decompresses responses.

SSRF Protection#

Path values that look like absolute URLs (http://, https://, //) are blocked to prevent SSRF through the fronting proxy. Blocked requests return 400 Bad Request.

Health Checks#

Each fronting rule can be health-checked individually or as a batch:

# Check all fronted domains
curl -H "Authorization: Bearer $TOKEN" https://ig:8080/api/fronting/health

# Start background health monitor (runs every 300s by default)
# Configured in YAML or started programmatically

Health probes hit a well-known URL on the CDN (configurable per rule, or falls back to a CDN-specific default like d1.awsstatic.com/0x0.png for CloudFront). A response under HTTP 400 counts as healthy.

HTTP/1.1 Enforcement#

Fronted connections use HTTP/1.1 only. Some CDN edges handle HTTP/2 streams differently for fronted vs. direct traffic, which can create subtle fingerprinting differences. HTTP/1.1 keeps the profile consistent with typical CDN client behavior.