Examining an x509 Covert Channel

Jason Reaves gave a talk titled
Malware C2 over x509 certificate exchange
at BSides Springfield 2017, where he demonstrated that the SSL handshake can be abused by malware
as a covert command-and-control (C2) channel.

Jason Reaves presenting at BSides Springfield 2017

He got the idea while analyzing the Vawtrak malware after discovering that it
read multiple fields in the X.509 certificate
provided by the server before proceeding. Jason initially thought these fields were used as a C2 channel,
but then realized that Vawtrak performed a variant of certificate pinning in order to discover SSL man-in-the-middle attempts.

Nevertheless, Jason decided to actually implement a proof-of-concept (PoC) that uses the X.509 certificate as a
C2 channel. Jason’s code is now available on
GitHub along with a
PCAP file
demonstrating this covert C2 channel.
Of course I couldn’t resist having a little look at this PCAP file in NetworkMiner.

The first thing I noticed was that the proof-of-concept PCAP ran the SSL session on TCP 4433,
which prevented NetworkMiner from parsing the traffic as SSL.
However, I was able to parse the SSL traffic with
NetworkMiner Professional just fine thanks to the
port-independent-protocol-identification feature (a.k.a Dynamic Port Detection),
which made the Pro-version parse TCP 4433 as SSL/TLS.

X.509 certificates extracted from PCAP with NetworkMiner
Image: X.509 certificates extracted from PCAP with NetworkMiner

A “normal” x509 certificate size is usually around 1kB, so certificates that are 11kB should be considered as anomalies.
Also, opening one of these .cer files reveals an extremely large value in the Subject Key Identifier field.

X.509 certificate with MZ header in the Subject Key Identifier field

Not only is this field very large, it also starts with the familiar “4D 5A”
MZ header sequence.

NetworkMiner additionally parses details from the certificates that it extracts from PCAP files,
so the Subject Key Identifier field is actually accessible from within NetworkMiner, as shown in the screenshot below.

Parameters tab in NetworkMiner showing X.509 certificate details

You can also see that NetworkMiner validates the certificate using the local trusted root certificates.
Not surprisingly, this certificates is not trusted (certificate valid = FALSE).
It would be most unlikely that anyone would manage to include arbitrary data like this in a signed certificate.

Extracting the MZ Binary from the Covert X.509 Channel

Even though NetworkMiner excels at pulling out files from PCAPs, this is definitively an occasion where manual handling is required.
Jason’s PoC implementation actually uses a whopping 79 individual certificates in order to transfer
this Mimikatz binary, which is 785 kB.

Here’s a tshark oneliner you can use to extract the Mimicatz binary from Jason’s
example PCAP file.

tshark -r mimikatz_sent.pcap -Y ‘ssl.handshake.certificate_length gt 2000’ -T fields -e x509ce.SubjectKeyIdentifier -d tcp.port==4433,ssl | tr -d ‘:\n’ | xxd -r -p > mimikatz.exe

Detecting x509 Anomalies

Even though covert channels using x509 certificates isn’t a “thing” (yet?) it’s still a good idea to think about how this type of
covert signaling can be detected. Just looking for large Subject Key Identifier fields is probably too specific,
since there are other fields and extensions in X.509 that could also be used to transmit data.
A better approach would be to alert on certificates larger than, let’s say, 3kB. Multiple certificates can also be
chained together in a single TLS handshake certificate record, so it would also make sense to look for handshake records larger than 8kB
(rough estimate).

Bro IDS logo

This type of anomaly-centric intrusion detection is typically best done using the
Bro IDS,
which provides easy
programmatic access to the X.509 certificate and SSL handshake.

There will be false positives when alerting on large certificates in this manner, which is why I recommend to also
check if the certificates have been signed by a trusted root or not.
A certificate that is signed by a trusted root is very unlikely to contain malicious data.

Facebook Share on Facebook  Twitter Tweet  Reddit Submit to reddit.com

This is a Security Bloggers Network syndicated blog post authored by Erik Hjelmvik. Read the original post at: NETRESEC Network Security Blog