This New Covert Channel Uses SSL/TLS Handshakes

A new and insidious covert channel mechanism was revealed this week, which uses only SSL/TLS certificate exchanges to exfiltrate data or deposit malicious payloads. This method uses fields in both client and server certificates to encode the data to be transferred, and thus does not even need an SSL session to be established for a bidirectional covert channel to be established.

For their proof of concept, researchers used the X.509 SubjectKeyIdentifier extension field of numerous SSL client/server certificates to encode and transfer a Mimikatz binary from one asset to another using just TLS handshakes. This is extremely difficult to detect unless a solution is in place which is continuously inspecting every TLS handshake to the layer 7 transaction level in both the north-south and east-west directions. Because this is generally not the case, SSL/TLS handshakes are rarely monitored and even more rarely logged, and this type of covert channel sails right through traditional detection mechanisms.

This proof of concept is but the latest addition to the class of malicious behavior which leverages the misuse of protocol characteristics themselves. We have seen DNS and ICMP tunneling for years, and in a recent report, even NTP tunneling demonstrated a 63.1% effective exfiltration success rate. These are all very common network protocols, yet are often not monitored, both due to the volume of traffic generated and to the fact that few solutions can monitor these protocols at the transaction level directly from the network.

A closer inspection of the proof of concept traffic shows that it is not indicated as TLS traffic in Wireshark by default, since this it is running over non-standard ports, further obfuscating this method from observation:

• New SSL/TLS servers in an enterprise or new encrypted services transacting between known assets
• Anomalous levels of SSL/TLS handshakes, especially between systems which have not interacted in this way before
• Anomalous content within client/server certificate fields like SubjectKeyIdentifier, Issuer, Subject, and more
• Unusual use of client certificates in the enterprise (generally, client certificates are only used with smartcard user authentication—or CAC/PIV in the US Federal government—and mutual authentication between web services)

ExtraHop natively recognizes TLS on all ports, and immediately surfaces this traffic. Note the unusual use of client certificates and absent subject and host fields:

A dashboard also reveals this behavior, as well as unusual spikes in TLS handshake volumes:

This class of malicious behavior will only continue to grow, since as we get better at detecting more obvious methodologies, bad actors will need to keep refining their craft to stay out of sight.

ExtraHop's unique ability to surface anomalies in network traffic in an easily understandable manner at massive scale provides our customers with a solid security posture and the confidence that these methods can be revealed before damage is done.