Hunting the Phantom Host: Forensic Analysis of SNI-Proxy Covert Channels in Encrypted Client Hello (ECH) Environments

The Double-Edged Sword of Modern Encryption

As security practitioners, we have long championed the steady march toward total encryption. From the widespread adoption of TLS 1.3 to the virtualization of DNS via DNS-over-HTTPS (DoH), the internet is safer for consumer privacy than ever before. However, in the enterprise space, this shift has steadily eroded the defensive perimeter. The latest—and perhaps most challenging—evolution in this paradigm is Encrypted Client Hello (ECH).

Designed to fix the last major plaintext leak in the TLS handshake (the Server Name Indication, or SNI), ECH encrypts the target hostname before it leaves the client machine. While this stops ISPs and eavesdroppers from tracking user browsing habits, it also blinds security controls like Next-Generation Firewalls (NGFWs) and Secure Web Gateways (SWGs). Today, threat actors are actively exploiting this blindspot to construct resilient, untraceable command-and-control (C2) channels. In this post, we will dissect how ECH-enabled covert channels operate, analyze the forensic artifacts they leave behind, and outline a practical defense strategy.

Understanding the Mechanics: ECH vs. Classic Domain Fronting

To understand why ECH-enabled covert channels are so dangerous, we must first compare them to classic domain fronting. In traditional domain fronting, an attacker sent a plaintext TLS SNI pointing to a benign site (e.g., legitimate-shop.com) hosted on a Content Delivery Network (CDN), while the inner HTTP “Host” header pointed to a malicious destination (e.g., malicious-c2.com). CDNs eventually clamped down on this by matching the SNI and Host headers.

ECH renders this mitigation obsolete by handling the concealment entirely within the TLS layer. Here is how the handshake is structured:

1. The Outer ClientHello (OCH): Contains a generic, public-facing server name (the public_name, such as cloudflare.com or a benign enterprise customer’s domain) and an ECH extension containing encrypted data.
2. The Inner ClientHello (ICH): Contains the actual, sensitive destination (the private_name, such as the attacker’s C2 server). This entire inner handshake is encrypted using a public key retrieved via a DNS HTTPS/SVCB record.

“Because the Inner ClientHello is encrypted using Hybrid Public Key Encryption (HPKE), middleboxes and network firewalls only see the Outer ClientHello. To the defender, the traffic looks like a routine connection to a massive, trusted cloud provider.”

How Attackers Abuse ECH for Covert Communication

To establish an ECH-based covert channel, an adversary configures their C2 infrastructure behind a CDN or cloud provider that supports ECH. They then configure their malware payload with the target’s ECH public key and config identifier.

When the malware initiates a connection, it constructs an ECH-enabled ClientHello. The outer wrapper points to a highly popular, benign site hosted on the same CDN. The inner, encrypted payload points to the attacker’s actual server. The network firewall inspects the packet, sees a handshake destined for a trusted, white-listed domain, and allows it through. Once the packet reaches the CDN’s edge, the CDN decrypts the Inner ClientHello using its private key and routes the connection to the malicious backend.

This is a phantom host attack: the defender sees the destination, but they are looking at a phantom. The true endpoint is hidden inside a cryptographic vault.

Forensic Analysis: What Does the Traffic Look Like?

Let us look at a practical example of capturing and analyzing this traffic using Wireshark or tshark. If you capture a packet trace of an ECH connection, you will observe the following structure in the TLS Handshake client hello:

Handshake Protocol: Client Hello
  Version: TLS 1.3 (0x0304)
  Extension: server_name (len=22)
    Server Name Indication extension
      Server Name: public-gateway.cdn.com
  Extension: encrypted_client_hello (len=244)
    Encrypted Client Hello extension
      Client Outer Extension Tag: ...
      Cipher Suite: AEAD_AES_128_GCM_SHA256
      Config ID: 0x42
      Encapsulated Public Key: [Hex Payload]

In this capture, the server_name extension in the Outer ClientHello is completely visible and points to public-gateway.cdn.com. However, the presence of the encrypted_client_hello extension indicates that the true destination is masked. As a forensic analyst, you cannot decrypt this payload without the private key held by the CDN.

The DNS Forensic Trail

While the network payload is encrypted, the attacker’s client must perform a vital pre-requisite step to make ECH work: it must obtain the ECH configuration block (which contains the public key). This config is published in the DNS as an HTTPS (Type 65) or SVCB (Type 64) resource record.

For example, running a DNS query for an ECH-enabled host reveals this payload:

$ dig HTTPS malicious-c2.com +short
1 . alpn="h2,http/1.1" ech="AD7+CQB4BwAgACB6...[Base64 Encoded ECH Config]..."

This DNS query is the primary forensic artifact. If malware is hardcoded with the ECH configuration, it may skip this DNS resolution to avoid detection. However, doing so makes the malware brittle; if the CDN rotates its ECH keys, the malware’s handshake will fail, prompting a fallback mechanism or connection termination. Therefore, many advanced loaders will perform live DNS queries for Type 65 records before initiating connections.

Detection Strategies for Enterprise Defenders

Defending against ECH-enabled covert channels requires a shift in how we analyze TLS traffic. Because we cannot decrypt the SNI mid-flight, we must look for behavioral anomalies and leverage endpoint instrumentation.

1. Hunting via JA4+ Fingerprinting

Traditional JA3 signatures struggle with TLS 1.3 and ECH because of randomized extensions and padding. However, the newer JA4/S database fingerprinting standards help mitigate this. JA4 tracks whether ECH is present in the handshake. By profiling your network, you can identify anomalous binaries or processes initiating ECH handshakes (e.g., a custom PowerShell script or a random executable in AppData using ECH, when typically only modern web browsers should be doing so).

2. DNS SVCB/HTTPS Record Auditing

Monitor your active directory DNS logs or passive DNS (pDNS) databases for an unexpected spike in Type 65 (HTTPS) and Type 64 (SVCB) queries. Attackers seeking to blend in will query these records. Cross-correlate these queries with the reputation of the queried domains. A query for an HTTPS record on a newly registered domain (NRD) is a high-confidence indicator of compromise (IoC).

3. Forcing ECH Fallback (Network-Level Mitigation)

If your enterprise relies on SSL/TLS decryption (decryption proxies) to scan inbound and outbound traffic, ECH will break this capability. To regain visibility, you can force clients to fall back to standard TLS 1.3 (where the SNI is encrypted but can be negotiated down, or where you can intercept the certificate exchange).

You can achieve this by configuring your internal DNS servers to strip or block HTTPS (Type 65) and SVCB (Type 64) responses. When the client browser or malware fails to retrieve the ECH configuration via DNS, it will fall back to a standard TLS 1.3 handshake, exposing the SNI to your firewalls.

4. GPO and Endpoint Enforcement

For managed endpoints, the most robust defense is disabling ECH at the application layer. Major browsers allow administrators to disable ECH via group policies (GPOs) or configuration files:

• Chrome/Edge: Disable the EncryptedClientHelloEnabled policy.
• Firefox: Set network.dns.echconfig.enabled to false in the configuration.

By enforcing this across your fleet, you ensure that legitimate browser traffic remains visible to your security stack, making any remaining ECH traffic on your network stand out as highly suspicious.

Conclusion

Encrypted Client Hello is an excellent advancement for consumer privacy, but it represents a significant structural hurdle for enterprise security. Threat actors are quick to adapt, and the transition of domain fronting into the encrypted TLS layer via ECH is already a reality.

By understanding the mechanics of the Outer versus Inner ClientHello, monitoring DNS Type 65 records for anomalous lookups, and implementing selective ECH fallback mechanisms, security teams can maintain the visibility required to hunt down these phantom hosts. As network-level blindspots grow, the battle increasingly moves to the endpoint and the DNS layer—defenders must adapt accordingly.