Stealth over TLS: the emergence of ECH-based C&C in ECHidna malware

Stealth over TLS: the emergence of ECH-based C&C in ECHidna malware

Speakers: Yuta Sawabe (Security Researcher, Entity Security Holdings); Rintaro Koike (NTT Security Japan)

Conference: Virus Bulletin

YouTube: https://www.youtube.com/watch?v=Mo3TEv7Wdn4

Overview

In this insightful talk from Virus Bulletin, Yuta Sawabe, a security researcher at Entity Security Holdings, unveiled ECHidna, a novel piece of malware leveraging the cutting-edge Encrypted Client Hello (ECH) TLS extension for its command-and-control (C2) communications. Co-authored with Rintaro Koike of NTT Security Japan, the research highlights a significant shift in adversary tactics, demonstrating how attackers are already exploiting advanced privacy features to evade detection. Discovered in April 2024 during a targeted attack on a Japanese research institute, ECHidna represents an emerging threat that masks its true C2 traffic, making it indistinguishable from legitimate network flows to popular Content Delivery Networks (CDNs) like Cloudflare.

The core innovation of ECHidna lies in its ability to hide the real server name (SNI) within the ECH handshake. This renders traditional network-based filtering ineffective, as the C2 traffic masquerades as routine, privacy-enhanced web browsing to cloudflare-ech.com. Sawabe's presentation meticulously detailed the malware's intricate infection chain, its custom communication mechanisms, and, crucially, the remaining signals defenders can use to detect such stealthy threats. This research underscores the critical need for a multi-layered defense strategy that combines network, endpoint, and process memory monitoring to combat the evolving landscape of C2 obfuscation.

Background

▶ Watch: Introduction to ECH and ECHidna malware (0:00)

The evolution of internet privacy protocols has, intentionally or not, provided new avenues for attackers to conceal their malicious activities. Historically, the Server Name Indication (SNI) field in the TLS handshake has been a plaintext indicator of the destination hostname, allowing network defenders to inspect and block traffic to known malicious domains. However, privacy advocates have long pushed for the encryption of this sensitive information. This led to the development of Encrypted SNI (ESNI), first introduced in 2018, which aimed to encrypt the hostname. While a step forward, ESNI proved insufficient, prompting a redesign and the eventual emergence of Encrypted Client Hello (ECH).

ECH represents a more comprehensive approach, encrypting almost the entire Client Hello message, not just the SNI. This ensures that the true hostname remains private from any passive observer on the network path. Its adoption has accelerated rapidly, with Chromium 117 (and all browsers built upon it) and Firefox 119 shipping with ECH enabled by default since late 2023. On the server side, major CDNs like Cloudflare have enabled ECH for all their clients, solidifying its place as a proposed standard (expected to become a full RFC soon). While a boon for user privacy, ECH simultaneously creates a significant blind spot for network defenders, as the critical C2 hostname signal effectively disappears. ECHidna malware is among the first observed instances to actively exploit this new privacy feature, highlighting a proactive adaptation by adversaries to the evolving internet infrastructure. The initial attack vector for ECHidna is typical: a spear-phishing email containing an ISO file, which, when opened, executes a PowerShell script via a malicious shortcut (.lnk), ultimately leading to the loading of a malicious DLL. However, the network stage of this attack sets it apart, leveraging ECH to blend seamlessly with legitimate Cloudflare traffic.

Key Findings

▶ Watch: ECHidna's anti-analysis techniques: custom B64, BoringSSL (8:00)

The discovery of ECHidna malware in April 2024 marked a pivotal moment in understanding advanced C2 obfuscation techniques. The primary finding is ECHidna's innovative use of the Encrypted Client Hello (ECH) TLS extension to conceal its C2 communications, making it extremely difficult for traditional network security tools to detect. By encrypting the Server Name Indication (SNI) within the TLS handshake, ECHidna's C2 traffic masquerades as legitimate connections to cloudflare-ech.com, effectively rendering it invisible to SNI-based filtering.

Beyond its ECH implementation, the research uncovered several critical technical aspects of ECHidna:

• Stealthy Execution Chain: The malware initiates through a sophisticated, multi-stage infection process involving a spear-phishing email, an ISO image, a malicious shortcut (.lnk) file, PowerShell execution, and a DLL loader (rundll32.exe) that unpacks the main ECHidna payload directly into memory. This "fileless" approach minimizes disk artifacts.
• Custom Communication Stack: ECHidna does not rely on standard Windows TLS libraries. Instead, it statically links BoringSSL, Google's fork of OpenSSL, allowing the attackers full control over the handshake process and enabling custom modifications without dropping additional DLLs.
• Anti-Analysis Techniques: The malware employs several tricks to hinder analysis, including a custom Base64 alphabet, hand-building JSON-like messages (avoiding standard JSON libraries), and using raw Winsock to bypass Windows HTTP/network APIs and associated hooks or proxy configurations.
• Remote Access Tool (RAT) Capabilities: Once active, ECHidna functions as a simple RAT, supporting four core commands: setting (to update its configuration), download, upload, and share (for remote code execution and file transfer). These commands are executed within the ECH-encrypted stream.
• Unique Host Identification: Each victim is assigned an 8-character hexadecimal host ID, generated by combining the victim's MAC address, the process flow (e.g., rundll32.exe), and a fixed campaign string embedded within the binary. This ID is included in the URL path of C2 requests to tag victims.
• Dynamic Configuration Management: ECHidna stores its C2 domain, port, HTTP path, and ping interval in an encrypted file within the user's profile folder, allowing for persistent and potentially updated configurations.

These findings collectively paint a picture of a sophisticated and adaptable adversary, leveraging cutting-edge privacy features and custom implementations to maintain persistence and evade detection in modern network environments.

Technical Deep Dive

▶ Watch: Understanding Encrypted Client Hello (ECH) and its adoption (10:00)

ECHidna's operational flow is a meticulously crafted sequence designed for stealth and persistence, starting from initial compromise and extending through its ECH-based C2 communications.

The attack begins with a spear-phishing email delivering an ISO image. Windows natively mounts ISOs, bypassing typical security warnings. Inside the ISO, the victim encounters what appears to be a normal folder but is, in fact, a malicious shortcut (.lnk) file. Double-clicking this shortcut triggers a short PowerShell script. This script copies a malicious DLL, named desktop.dll (a deceptive name to appear harmless), into the user's temp folder. It then uses rundll32.exe to load this DLL, specifically calling an exported function named ssl_version. This initial DLL acts as a loader, unpacking the main ECHidna payload directly into memory, ensuring no persistent artifacts are written to disk for the core RAT component. The main ECHidna program is identified by a unique marker: four occurrences of bf (eight hex digits) within the code, followed by a second hidden PE file that is decompressed and executed in memory.

Once active, ECHidna establishes its C2 channel using Encrypted Client Hello (ECH). This process involves several steps:

1. ECH Config Acquisition: Before initiating an ECH handshake, the client needs an ECH configuration. ECHidna uses DNS over HTTPS (DoH) to query for the HTTPS record of cloudflare-ech.com. It contains six hardcoded DoH resolvers and tries them sequentially, doubling the wait time if a resolver fails. Crucially, it queries for cloudflare-ech.com rather than its own C2 domain, as Cloudflare reuses a single ECH config across many customer zones. The JSON response contains a base64-encoded ECH= field, which is the encrypted configuration blob. This blob is decoded and cached, with a Time-To-Live (TTL) of 300 seconds, requiring the malware to fetch a fresh config periodically. The ECH config contains vital information, including a public_key (used to encrypt the inner ClientHello), a public_name (the cover SNI, typically cloudflare-ech.com), and various version, config ID, and cipher suite parameters.
2. Building the Encrypted Client Hello: With the ECH config, ECHidna constructs two ClientHello messages: an inner ClientHello and an outer ClientHello. The inner message contains the attacker's true C2 domain as the real SNI. This inner message is then encrypted using the public_key obtained from the ECH config. The outer ClientHello, visible on the wire, contains the public_name (e.g., cloudflare-ech.com) as its SNI. The encrypted inner ClientHello is then embedded within the outer message as an extension.
3. TLS Handshake: ECHidna then resolves the cloudflare-ech.com hostname and sends this composite ECH ClientHello packet through its statically linked BoringSSL library. Cloudflare's edge server receives the outer ClientHello, uses its corresponding private key to decrypt the inner ClientHello, and discovers the true C2 domain. The server then proceeds with a normal TLS handshake (ServerHello, Certificate, Finished). To any passive observer, the entire process appears as a standard HTTPS connection to cloudflare-ech.com, with the real C2 domain remaining hidden.

ECHidna's C2 communication leverages a custom JSON-like message format for its commands and replies. Each C2 request carries an 8-character hexadecimal host ID, embedded directly in the URL path. This ID is generated by a custom routine that combines the victim's MAC address, the process flow (e.g., rundll32.exe), and a fixed campaign string from the binary, then squeezes this data down to 8 hex characters. This ensures a persistent, unique identifier for each compromised host, even across reboots or re-infections.

The malware also employs several anti-analysis and stealth techniques:

• Custom Base64 Alphabet: Data encoding uses a modified Base64 character set, breaking standard decoders.
• Hand-built JSON: Instead of using standard JSON libraries, ECHidna constructs its JSON-like messages manually, making reverse engineering more cumbersome and avoiding common function signatures.
• Raw Winsock: By directly using raw Winsock APIs, ECHidna bypasses higher-level Windows networking APIs (like WinHTTP or WinINet), effectively circumventing proxy configurations and many network hooks.
• Static BoringSSL: The inclusion of a static copy of BoringSSL means all cryptographic operations occur within the malware's process, avoiding calls to standard Windows cryptographic APIs (e.g., CryptoAPI, CNG) that might be monitored.

ECHidna's configuration, including the C2 domain, port, HTTP path, and ping interval, is initially hardcoded. Upon receiving a setting command from the operator, these values are written to an encrypted file in the user's profile folder, ensuring persistence across reboots. The malware prioritizes this saved configuration if found, falling back to defaults otherwise. While the setting command saves the current config, the mechanism for updating the C2 domain itself is assumed to involve the attacker dropping a fresh encrypted config file using the download command.

Demo / Proof of Concept

▶ Watch: How ECHidna leverages ECH for stealthy C2 (20:00)

The talk focused on the detailed analysis of the ECHidna malware sample and its operational mechanisms, rather than a live demonstration of the malware in action. The speakers explicitly stated, "Please note we analyzed only the malware sample itself. We have not yet seen an attacker use these commands live. So their exact purpose may still change." This indicates that while the capabilities and technical workings were thoroughly dissected from the binary, a real-time, attacker-controlled execution or a simulated proof of concept was not part of the presentation.

Defensive Implications

▶ Watch: Multi-layered detection strategies for ECHidna malware (22:00)

The emergence of ECHidna malware highlights a significant challenge for defenders: the erosion of traditional network-based detection capabilities due to enhanced privacy protocols like ECH. With the true C2 hostname encrypted, relying solely on SNI filtering or passive network monitoring for malicious domains becomes increasingly ineffective. However, the research provides actionable insights into the remaining signals that, when combined, can form a robust detection strategy.

Defenders must adopt a multi-layered approach, correlating events across DNS, TLS handshake, and endpoint telemetry:

1. DNS Traffic Monitoring:

• Flag HTTPS Records with ECH Field: ECHidna, like legitimate ECH clients, must fetch an ECH config via a DNS HTTPS record query. Defenders should flag any HTTPS record response containing an ECH= field that points to cloudflare-ech.com (or similar public ECH providers). While this is a common pattern for legitimate ECH users, its presence warrants closer inspection, especially when correlated with other indicators.
• DNS over HTTPS (DoH/DoT) Visibility: If an organization employs DoH or DoT, the DNS messages themselves are encrypted. Security solutions capable of decrypting TLS traffic (e.g., SSL/TLS inspection proxies) should be configured to inspect DoH/DoT traffic for the same ECH= field. If TLS decryption is not feasible, other detection layers become even more critical.
• High Frequency of ECH Config Lookups: The ECH config has a TTL of 300 seconds. Frequent, repeated lookups for cloudflare-ech.com's HTTPS record from a single host could be an anomalous signal, as legitimate clients might not query this as frequently or consistently.

1. TLS Handshake Analysis:

• Outer SNI and ECH Extension: Network sensors should look for TLS handshakes where the outer SNI is cloudflare-ech.com (or other ECH cover names) and the encrypted_client_hello extension is present. This confirms ECH is being used.
• Contextual Filtering: While this pattern is normal for legitimate ECH-enabled web browsing, it becomes suspicious in environments where ECH traffic is unusual or unexpected, such as on enterprise servers or specific internal segments where ECH might be blocked or not typically used. In such contexts, any ECH traffic can be a strong indicator of compromise.

1. Endpoint Process Monitoring: This layer provides the most distinct and high-fidelity signals for ECHidna:

• Suspicious Process Chain: Monitor for the specific process lineage: explorer.exe spawning powershell.exe, which then spawns rundll32.exe to load a DLL.
• DLL from Temp Directory: Pay close attention to rundll32.exe loading DLLs from atypical locations, especially the user's temp folder. ECHidna's use of desktop.dll in this context is a strong indicator.
• Unsigned/Non-Microsoft DLLs: Flag DLLs loaded from suspicious locations that are unsigned or not legitimate Microsoft binaries. Most endpoint detection and response (EDR) solutions can be configured with rules to detect these attributes.
• Absence of Parent Browser Process: The explorer.exe -> powershell.exe chain is unusual, as legitimate PowerShell execution often originates from other processes or user interaction that would involve a browser or other application.

Correlation for High-Fidelity Alerts: The most effective defense involves correlating these signals across the three layers within a short time window. An alert combining:

• An ECH= DNS response pointing to cloudflare-ech.com,
• A TLS handshake with cloudflare-ech.com as the outer SNI and an ECH extension,
• And the explorer.exe -> powershell.exe -> rundll32.exe loading a random, unsigned DLL from the temp directory on the same host,

provides a strong, low-false-positive indicator of an ECHidna infection or similar ECH-abusing malware. This multi-faceted approach ensures that even as adversaries adapt to new privacy features, defenders can still leverage the remaining forensic artifacts to detect and respond to threats.

Key Takeaways

• ECH Hides C2 Traffic: ECHidna malware leverages the Encrypted Client Hello (ECH) TLS extension to encrypt its true C2 hostname, making its traffic indistinguishable from legitimate connections to CDNs like Cloudflare (cloudflare-ech.com) on the network wire.
• Multi-Stage Stealthy Infection: The malware employs a sophisticated infection chain: spear-phishing -> ISO image -> malicious shortcut (.lnk) -> PowerShell script -> rundll32.exe loading a DLL from temp -> in-memory unpacking of the main ECHidna payload.
• Custom Communication Stack: ECHidna uses a statically linked BoringSSL library, a custom Base64 alphabet, hand-built JSON-like messages, and raw Winsock to avoid standard Windows APIs and common detection points.
• Endpoint Visibility is Crucial: Traditional network-based SNI filtering is ineffective. Defenders must prioritize endpoint monitoring for suspicious process chains (explorer.exe -> powershell.exe -> rundll32.exe loading unsigned DLLs from temp).
• Multi-Layered Detection: Effective detection requires correlating signals from DNS (HTTPS record with ECH=), TLS handshakes (outer SNI cloudflare-ech.com with ECH extension), and endpoint telemetry for a robust, low-false-positive alert.
• Proactive Threat Adaptation: ECHidna demonstrates that adversaries are quickly adopting and weaponizing new internet privacy standards, necessitating continuous adaptation of defensive strategies.

About the Speaker(s)

Yuta Sawabe is a Security Researcher on the SOC team at Entity Security Holdings in Tokyo. He presented this research on ECHidna malware, highlighting his expertise in malware analysis and threat research. His work focuses on dissecting new attack techniques and understanding how adversaries leverage emerging technologies.

Rintaro Koike is associated with NTT Security Japan. He is a colleague of Yuta Sawabe and contributed to the joint research project on ECHidna malware, focusing on malware analysis and threat research. While Yuta Sawabe was the sole presenter on stage, the research presented was a collaborative effort.