TLS Protocol Manipulation: a (very) low throughput C2 channel

TLS Protocol Manipulation: a (very) low throughput C2 channel

Speakers: Andreea Iacob, Security Researcher

Conference: DefCamp

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

Overview

In this insightful talk from DefCamp, security researcher Andreea Iacob explores a novel method for establishing a Command and Control (C2) channel by subtly manipulating the Transport Layer Security (TLS) protocol. Titled "TLS Protocol Manipulation: a (very) low throughput C2 channel," the presentation delves into how specific, often overlooked, fields within the TLS handshake can be repurposed to exfiltrate data and relay commands. This research, born out of personal curiosity and a desire to "play" with network data, demonstrates that even seemingly innocuous protocol elements can be leveraged for covert communication, challenging conventional detection strategies.

The core of Iacob's work revolves around embedding information within the Client Hello and Server Hello negotiation packets, specifically utilizing the random, session ID, and GREASE (Generate Random Extensions And Sustain Extensibility) fields. This approach bypasses the encrypted data stream, making the C2 communication appear as legitimate TLS handshake traffic. While acknowledging that this method offers very low throughput, its stealth and ability to blend with normal network activity make it a compelling subject for defenders and red teamers alike, highlighting the importance of deep protocol understanding and behavioral analysis for effective security.

Background

▶ Watch: Introduction and motivation for TLS protocol manipulation (0:00)

The concept of a C2 channel is fundamental to post-exploitation phases in cybersecurity, enabling an attacker to maintain persistent control over a compromised system (the victim) and issue commands or exfiltrate data. Traditional C2 channels often rely on common protocols like HTTP, HTTPS, or DNS, which are well-understood and frequently monitored. More exotic methods, such as those leveraging Google Workspace or VirusTotal, typically still rely on underlying protocols like HTTPS. Iacob's research distinguishes itself by moving beyond application-layer manipulation to directly modify the protocol handshake itself, specifically within TLS.

TLS, the successor to SSL, is the cryptographic protocol designed to provide secure communication over a computer network. It operates by encrypting data transmitted between a client and a server after an initial negotiation phase. This negotiation, known as the TLS handshake, involves the exchange of Client Hello and Server Hello messages, where parameters like protocol version, cipher suites, and session IDs are agreed upon. Iacob's key insight is that the information exchanged during this negotiation, before the main encrypted data flow, can be covertly manipulated.

A significant inspiration for this research came from the GREASE mechanism, a concept introduced by Caleb U. GREASE, an acronym for "Generate Random Extensions And Sustain Extensibility," involves adding a set of reserved, ignored values to the TLS protocol. Its purpose is to prevent extensibility failures by ensuring that TLS implementations correctly ignore unknown or unexpected values, thus preventing ossification of the protocol. Iacob learned about GREASE through an advanced network threat hunting class and a challenging CTF, which sparked her curiosity about whether these "ignored" fields could be repurposed for data transfer. This led her to investigate whether other seemingly random or less critical fields within the Client Hello and Server Hello, such as the random bytes and session ID, could also be leveraged.

Key Findings

▶ Watch: Origin story: Research inspired by a CTF challenge (6:30)

Andreea Iacob's research demonstrates the feasibility of establishing a low-throughput C2 channel by manipulating the TLS handshake messages. The core findings highlight several critical aspects:

1. Protocol-Level Manipulation: Unlike many "exotic" C2 methods that leverage legitimate applications, this technique directly patches the OpenSSL library to inject data into the Client Hello and Server Hello packets. This means the C2 traffic is indistinguishable from standard TLS handshake negotiation at a superficial level, operating below the application layer and even before the main data encryption begins.
2. Utilizing Obscure and "Ignored" Fields: The method primarily relies on three specific fields within the Client Hello:

• The GREASE values (specifically within cipher supported groups and supported versions), which are designed to be ignored by compliant TLS implementations. A single byte of data can be split and embedded across these fields.
• The 32-byte client random.
• The 32-byte session ID.

The server responds by embedding commands within its 32-byte server random field in the Server Hello message.

1. Not an OpenSSL Vulnerability: Iacob explicitly states that this is not an exploit or vulnerability in OpenSSL. Instead, it involves patching the OpenSSL source code (versions 1.1.1 and 3.5 were used) to alter its behavior. This means an attacker would need to compile a custom OpenSSL library to implement this C2.
2. Low Throughput, High Stealth: The channel is inherently low throughput due to the limited size of the available fields in each handshake. However, this limitation is offset by the stealthy nature of the communication, which blends seamlessly with legitimate TLS negotiation traffic, making it challenging for traditional network security monitoring to detect.
3. Behavioral Detection is Key: Given the encrypted nature of the data flow post-handshake and the protocol-compliant appearance of the handshake itself, effective detection relies heavily on behavioral analysis. Monitoring for unusual patterns in TLS connection frequency, connection duration, and byte counts, rather than content inspection, becomes paramount.

Technical Deep Dive

▶ Watch: Live Demo: TLS C2 channel in action (17:45)

The technical implementation of this C2 channel involves meticulous manipulation of the OpenSSL library at a granular level. The goal is to embed data into specific fields of the TLS Client Hello and Server Hello messages, which are exchanged before the main encrypted data channel is established.

Client-Side Exfiltration

On the client (victim) side, the system is patched with a custom OpenSSL 1.1.1 library. The client's role is to exfiltrate data, such as a file, or send command output back to the attacker. This is achieved by embedding data into the Client Hello message using three fields:

1. GREASE (Generate Random Extensions And Sustain Extensibility): This mechanism, originally designed to ensure protocol extensibility, is repurposed. Iacob uses one byte of data, splitting it across the cipher supported groups and supported versions fields. For example, a decimal value of 97 (hex 61) would be split into 6A6A and 1A1A in these fields, with a third GREASE field filled with random data. The server then reassembles these parts.
2. Client Random: This 32-byte field, normally containing random data, is used to transmit additional exfiltrated data.
3. Session ID: Similar to the client random, this 32-byte field is also utilized for data exfiltration.

The client's logic includes a beaconing mechanism. It periodically initiates a TLS handshake with the attacker's server. During this handshake, it checks the server's response for commands. If a command is received, it executes it and prepares the output for subsequent Client Hello messages.

Server-Side Command and Control

The attacker operates a server running a patched OpenSSL 3.5 (a development branch at the time of research). The server's primary function is to receive exfiltrated data and send commands to the client. Commands are embedded within the Server Random field of the Server Hello message.

The manipulation of the server_random field proved to be the most challenging aspect. Initially, Iacob attempted to introduce a custom server_random directly into the S3 structure (part of the connection context) and use a flag to switch between custom and default values. However, this approach failed because these structures are frequently reset during message formation, and crucially, the server_random is used for key derivation by the underlying cryptographic library. Directly tampering with it in a naive way would break the TLS handshake.

The revised approach involved a more surgical patch:

1. Custom Server Random Function: A new function was added to OpenSSL to specifically set the server_random in the S3 structure.
2. overwrite_marker Flag: A custom flag, overwrite_marker, was introduced into the OpenSSL structure. When this flag is set to 1, the custom function is invoked to insert the attacker's command into the server_random. When set to 0, OpenSSL's default random generation is used.
3. Command Encoding: To distinguish commands from default random data, a specific prefix is used. The server's default server_random starts with 16 bytes of FD (hexadecimal). A command is identified if the server_random does not start with FD. Commands are padded with zeros and trimmed by the client.
4. Dynamic Switching: A critical part of the server logic is to immediately reset the overwrite_marker flag to 0 after sending a command. This prevents the server from repeatedly sending the same command or overwhelming the client with commands, especially if the command output is lengthy and requires multiple Client Hello-Server Hello exchanges. A mutex lock is used to ensure thread safety during this switch.

Execution Evasion

For executing commands on the victim, Iacob notes the importance of EDR (Endpoint Detection and Response) evasion. Standard methods like popen or CreateProcess API calls, which create new processes and capture their output, are commonly flagged by EDR solutions (e.g., Elastic, Windows Defender). To circumvent this, the implementation uses the simpler system call, which sends output to standard out. While this might limit output capture capabilities compared to CreateProcess, it reduces the EDR footprint for the initial command execution.

The total throughput for this channel is very low, as each Client Hello can carry 1 byte (GREASE) + 32 bytes (Random) + 32 bytes (Session ID) = 65 bytes, and each Server Hello can carry 32 bytes (Random). This makes it suitable for small commands and intermittent data exfiltration rather than bulk transfer.

Demo / Proof of Concept

▶ Watch: Mitigation: Breaking the C2 channel with TLS inspection (21:00)

Andreea Iacob provided a live demonstration of the TLS protocol manipulation C2 channel in action. The setup involved:

• Attacker Machine: A Debian server running the patched OpenSSL.
• Victim Machine: A Windows server running the patched OpenSSL client.

The demonstration showcased the following sequence of events:

1. Packet Capture Initiation: Wireshark was started on the server side to capture network traffic and observe the manipulated TLS handshake packets.
2. Server Activation: The attacker server was started, configured to listen for incoming connections from the client.
3. Client Beaconing: The Windows client initiated a TLS connection to the attacker server. Its logic dictated a beaconing interval of 3 seconds.
4. Command Issuance: The attacker, via their server, issued commands such as ipconfig and net local group administrators.
5. Execution and Exfiltration:

• The client, upon receiving a Server Hello message that did not start with the default FD bytes in its server_random field, identified it as a command.
• It executed the command locally using the system call.
• The output of the command was then embedded into subsequent Client Hello messages using the random and session ID fields, and sent back to the server.
• Crucially, after sending a command, the server immediately switched back to sending default server_random values to prevent re-execution or flooding the client.

1. Wire Observations:

• Client Hellos: Wireshark clearly showed the session ID and random fields containing portions of the command output being exfiltrated.
• Server Hellos: Initially, the server_random field contained the command (e.g., ipconfig). In subsequent Server Hellos, if no new command was issued, the server_random reverted to the default FD prefix, indicating no command. The session ID in the Server Hello was observed to mirror what the client sent, demonstrating its passive role in this specific C2 channel.
• GREASE: The demo also highlighted the GREASE values, showing how 0a0a and 0d0d in hex reassembled into a carriage return, illustrating the single-byte embedding.

A humorous anecdote from the demo included Wireshark misinterpreting some malformed packets as "Picture Transfer Protocol" (PTP), highlighting the challenges of low-level protocol manipulation and the potential for unexpected side effects. The demonstration effectively validated the proof-of-concept, showing a functional, albeit low-throughput, C2 channel operating entirely within the TLS handshake.

Defensive Implications

▶ Watch: Q&A: Encrypting C2 data and behavioral detection (31:00)

The stealthy nature of a C2 channel embedded within TLS handshakes presents significant challenges for defenders. However, as Iacob emphasizes, "there's no such thing as unhackable and there's no such thing as undetectable." Drawing on Locard's principle of exchange ("every contact leaves a trace"), she outlines several strategies for detection and mitigation.

1. TLS Inspection

The most direct and effective mitigation is TLS inspection (or SSL interception). This involves deploying a proxy (e.g., SSLsplit or man-in-the-middle proxy) in the network path between the client and the server.

• How it works: The proxy acts as an intermediary, decrypting the TLS communication from the client, inspecting it, and then establishing a new, separate TLS connection to the original server. For this to work, the client must trust the proxy's certificate.
• Impact on the C2: By decrypting the handshake, the proxy would either fail to re-encrypt and forward the manipulated fields correctly or, more likely, simply break the channel. As demonstrated, the client would then continuously receive "garbage" (non-default randoms from the proxy), leading it to endlessly attempt to execute non-existent commands, thus revealing the anomalous behavior.
• Considerations: TLS inspection requires careful implementation, especially in corporate environments, due to performance overhead, privacy concerns, and certificate management. It's not a universal control for all threat profiles, but highly effective where implemented.

2. TLS Metadata and Behavioral Analysis

For environments where full TLS inspection is not feasible or desired, focusing on TLS metadata and behavioral patterns is crucial.

• Know Your Normal: Defenders must establish a baseline of "normal" TLS traffic behavior within their networks. This involves understanding typical connection frequencies, byte counts, and handshake characteristics.
• Default Client Hello Analysis: The speaker noted that a default OpenSSL Client Hello often has a random field filled with FC bytes and a session ID of all zeros. Deviations from these defaults can be indicators.
• Signature-Based Detection (Brittle):
• Suricata/Snort Rules: It is possible to write rules for intrusion detection systems (IDS) like Suricata or Snort to detect specific byte patterns in the Client Hello (e.g., looking for non-FC bytes in the first four bytes of the random field or non-zero session IDs, combined with the TLS client hello type).
• Limitation: This approach is brittle. An attacker can easily change these specific byte patterns (e.g., use a different prefix instead of FD or FC), rendering the signature useless.
• Zeek (Bro) for Longitudinal Analysis:
• Initial Observation: When looking at individual Zeek logs, there might not seem to be much relevant information (only agreed version and cipher, not the raw randoms or session IDs).
• Power of Zeek: The real power of Zeek lies in its ability to aggregate and analyze data over longer time frames. The demo showed that over 14 hours, even with beaconing every 3 seconds and only a few commands, Zeek recorded a significant number of full TLS connections. This pattern of high connection frequency with very low data transfer (especially for the initial handshakes) is highly anomalous for typical TLS traffic and is a strong indicator of beaconing C2 activity.
• Rita for Beaconing Detection:
• Rita is an open-source framework designed for network traffic analysis, particularly useful for detecting beaconing C2.
• While the default show beacons command might not immediately flag this specific low-throughput C2 due to its unique characteristics, adjusting show strobes thresholds for the number of connections over time could be effective. Rita's open-source nature allows for customization to better suit this detection scenario.

3. The "Great Equalizer" - The Wire

Ultimately, the talk reinforces that "the wire is the great equalizer." Everything that traverses the network leaves a trace. Defenders should:

• Actively Monitor Traffic: Continuously monitor network traffic for anomalies.
• Perform Network Threat Hunting: Proactively search for suspicious patterns, even seemingly minor deviations from normal.
• Focus on Behavioral Signatures: Prioritize detection methods that look at connection patterns, frequency, duration, and byte counts rather than relying solely on content-based signatures, which are easily evaded by protocol manipulation or encryption.

In summary, while protocol manipulation offers a stealthy C2 channel, it leaves a distinct behavioral footprint. By combining TLS inspection where appropriate with robust network telemetry analysis (especially using tools like Zeek for longitudinal behavioral patterns), defenders can uncover such covert communications.

Key Takeaways

• TLS Handshake for C2: The TLS Client Hello and Server Hello messages, specifically their random, session ID, and GREASE fields, can be repurposed for a low-throughput C2 channel.
• OpenSSL Patching, Not Vulnerability: This C2 method is achieved by patching the OpenSSL library, not by exploiting an existing vulnerability, requiring an attacker to compile custom binaries.
• Stealthy but Low Throughput: The channel is highly stealthy as it blends with legitimate TLS negotiation traffic, but its throughput is very limited (approximately 65 bytes per Client Hello, 32 bytes per Server Hello).
• Behavioral Detection is Paramount: Due to the protocol-level manipulation and encryption, traditional content-based detections are ineffective. Defenders must focus on behavioral anomalies like high connection frequency, short connection durations, and unusual byte counts over time.
• Effective Defenses: TLS inspection (e.g., SSLsplit, mitmproxy) can break the channel. Tools like Zeek and Rita, when properly configured and used for longitudinal analysis, are effective for identifying beaconing patterns.
• Know Your Network: Understanding baseline "normal" network traffic and proactive threat hunting are essential to detect subtle deviations indicative of such covert channels.

About the Speaker(s)

Andreea Iacob is a Security Researcher with a passion for playing, creating, inventing, and discovering in the realm of cybersecurity. She describes herself as someone who "just does things" and learns through experimentation and failure. Beyond her research, Andreea is dedicated to giving back to the community, teaching at security summer schools. Her work, including the OpenSSL patches and C2 code demonstrated in this talk, is often shared on her GitHub and other platforms like LinkedIn, where she engages with the community on topics related to networking and security. Her approach underscores the value of curiosity-driven research in uncovering novel attack and defense techniques.