T1090.004 Google Chronicle · YARA-L

Detect Domain Fronting in Google Chronicle

Adversaries may take advantage of routing schemes in Content Delivery Networks (CDNs) and other services which host multiple domains to obfuscate the intended destination of HTTPS traffic or traffic tunneled through HTTPS. Domain fronting involves using different domain names in the SNI field of the TLS header and the Host field of the HTTP header. If both domains are served from the same CDN, the CDN may route to the address specified in the HTTP header after unwrapping the TLS header. A variation, 'domainless' fronting, utilizes a blank SNI field. Real-world actors including APT29 and tools like Cobalt Strike, Mythic, and SMOKEDHAM have leveraged domain fronting to hide C2 traffic behind legitimate CDN infrastructure.

MITRE ATT&CK

Tactic
Command and Control
Technique
T1090 Proxy
Sub-technique
T1090.004 Domain Fronting
Canonical reference
https://attack.mitre.org/techniques/T1090/004/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule domain_fronting_sni_host_mismatch_t1090_004 {
  meta:
    author          = "Detection Engineering"
    description     = "Detects domain fronting (T1090.004) via mismatch between the TLS SNI extension and the HTTP Host header in HTTPS connections traversing known CDN providers. Technique used by APT29 and tooling including Cobalt Strike, Mythic, and SMOKEDHAM to hide C2 traffic behind legitimate CDN certificate chains."
    mitre_attack_tactic    = "Command and Control"
    mitre_attack_technique = "T1090.004"
    severity        = "HIGH"
    confidence      = "MEDIUM"
    platforms       = "Windows, Linux, macOS"
    data_sources    = "Network proxy logs, TLS inspection logs forwarded to Chronicle"
    version         = "1.0"

  events:
    $e.metadata.event_type = "NETWORK_HTTP"
    $e.network.application_protocol = "HTTPS"

    // Bind SNI and HTTP Host to variables for comparison
    $sni  = $e.network.tls.client.server_name
    $host = $e.target.hostname

    // Both fields must be populated and differ from each other
    $sni  != ""
    $host != ""
    $sni  != $host

    // At least one of the two must be a known CDN domain
    (
      re.regex($sni,  `(?i)(azureedge\.net|cloudfront\.net|akamaiedge\.net|fastly\.net|cloudflare\.com|msecnd\.net|azurefd\.net|amazonaws\.com|googleusercontent\.com)`) or
      re.regex($host, `(?i)(azureedge\.net|cloudfront\.net|akamaiedge\.net|fastly\.net|cloudflare\.com|msecnd\.net|azurefd\.net|amazonaws\.com|googleusercontent\.com)`)
    )

  condition:
    $e
}
high severity medium confidence

Chronicle YARA-L 2.0 detection rule for domain fronting (T1090.004), comparing the TLS SNI field (network.tls.client.server_name) against the HTTP Host header value (target.hostname) in NETWORK_HTTP UDM events. The rule fires when a mismatch exists between these two fields and at least one matches a known CDN provider domain suffix — the definitive behavioral signature of domain fronting. Requires Chronicle ingestion of proxy or network-layer logs that populate both UDM TLS and HTTP fields, typically via the Chronicle forwarder with parsers for Bluecoat, Zscaler, Palo Alto, or Squid. The domainless fronting variant (blank SNI) is captured implicitly because an empty SNI would never equal a non-empty HTTP Host value from a CDN domain.

Data Sources

Google Chronicle UDM — NETWORK_HTTP events from proxy/firewall log feedsWeb proxy logs ingested via Chronicle forwarder with TLS+HTTP parser (Blue Coat, Zscaler, Squid)Palo Alto Networks URL Filtering and Threat logs forwarded to Chronicle with TLS inspection fieldsZeek network sensor logs ingested via Chronicle with ssl.log + http.log correlation

Required Tables

Chronicle UDM event type: NETWORK_HTTPUDM fields required: network.tls.client.server_name, target.hostname, network.application_protocol

False Positives & Tuning

  • Google Cloud CDN, Firebase Hosting, and Google APIs use infrastructure where TLS SNI may reference a googleapis.com or googleusercontent.com edge domain while the HTTP Host header reflects a customer-specific bucket or API endpoint — high-volume false positives expected from Google Workspace and GCP workloads
  • Microsoft Azure Front Door serves enterprise tenants with wildcard TLS certificates presenting azurefd.net or azureedge.net in the SNI while routing requests to customer Origin Host headers — expected for any org with Azure Front Door-fronted applications
  • Akamai SureRoute and NetSession technologies used by software vendors (Adobe, Microsoft, Autodesk) for large file delivery legitimately produce SNI/Host mismatches as part of Akamai's internal CDN routing between edge and parent cache nodes
Download portable Sigma rule (.yml)

Other platforms for T1090.004


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Domain Fronting HTTP Request with curl

    Expected signal: Sysmon Event ID 3 (Network Connection): connection to azureedge.net IP. Network proxy logs (if TLS inspection enabled): SNI=legitimate-front.azureedge.net, Host header=different-domain.azureedge.net — mismatch detected. DNS query for legitimate-front.azureedge.net logged in Sysmon Event ID 22.

  2. Test 2Install and Run meek-client (Tor Domain Fronting Plugin)

    Expected signal: Sysmon Event ID 1: meek-client.exe process creation with -WindowStyle Hidden equivalent arguments including --front=ajax.aspnetcdn.com and --url=https://meek.azureedge.net/. Sysmon Event ID 3: meek-client.exe connecting to azureedge.net on port 443. Sysmon Event ID 22: DNS queries for ajax.aspnetcdn.com and meek.azureedge.net. PowerShell Event ID 4104 from the Invoke-WebRequest download cradle.

  3. Test 3Cobalt Strike-style Domain Fronting HTTP Request via PowerShell

    Expected signal: Sysmon Event ID 3: powershell.exe network connection to ajax.aspnetcdn.com (IP of CDN). Sysmon Event ID 22: DNS query for ajax.aspnetcdn.com. Process Event ID 1 for PowerShell with above CommandLine. Proxy logs (with TLS inspection): Host header value 'c2.attacker-domain.example.com' visible separately from SNI 'ajax.aspnetcdn.com' — mismatch triggers alert.

  4. Test 4Detect Domainless Fronting via Blank SNI Field

    Expected signal: Network logs: TLS ClientHello packet with no SNI extension (empty server_name field in TLS handshake). Proxy logs: destination hostname blank or '-' in the SNI field, while HTTP Host header contains 'target-domain.cloudfront.net'. Sysmon Event ID 3: connection to cloudfront.net IP without associated hostname from DNS.

Unlock Pro Content

Get the full detection package for T1090.004 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections