GQUIC Protocol Analysis and Fingerprinting in Zeek

What if 10–20% of the traffic in an environment was invisible to network security monitors? What if that percentage was only going to increase as time went on?

In environments that make heavy use of Google products, between 10–20% of network traffic could be communicating over GQUIC. Since Chrome began using the GQUIC transport protocol to speed up web traffic, a large portion of web traffic now uses GQUIC rather than the traditional HTTP/TLS framework. While GQUIC is not inherently bad in itself, many network and security tools do not support GQUIC traffic, resulting in a large portion of web traffic being neither inspected nor logged. To address this gap, Salesforce’s detection team built a GQUIC protocol analyzer for use on the Zeek (formerly known as Bro) network security monitor. This powerful new tool allows security teams to perform inspection, logging, and fingerprinting on web traffic communicating over GQUIC.

We have open sourced the GQUIC Protocol Analyzer for Zeek here: https://github.com/salesforce/GQUIC_Protocol_Analyzer

Overview:

The GQUIC Protocol Analyzer for Zeek is a plugin which can be added to any Zeek sensor. Developed using BinPAC, the protocol analyzer can extract information out of the two main unencrypted GQUIC packets — the client hello packet and the server rejection packet. Almost any tag and value found in these two packets, including cryptographic algorithms, certificates, and user agent IDs, can be extracted by a simple Zeek script. Additionally, a fingerprinting method called “CYU” for client connections was built into the GQUIC protocol analyzer scripts so that anomalous GQUIC traffic can be quickly identified and alerted on. This is particularly useful when trying to detect beacons communicating over GQUIC on a network, such as those generated by the Merlin command and control post-exploitation framework.

Few tools have the ability to examine GQUIC packets at this time. As a result, detection teams without the tools to inspect GQUIC traffic end up with generic UDP logs which provide few insights into the web traffic that occurred. For example, Wireshark (v 3.0.3) cannot yet analyze GQUIC version Q046, which makes up the majority of GQUIC traffic today. As a result, what is actually GQUIC Q046 traffic appears as plain, undissected UDP packets. Thus, tools must be updated to the latest versions of GQUIC. Additionally, while some work has been done to analyze and detect GQUIC traffic, such as the Zeek protocol analyzer the Corelight team created for GQUIC versions Q039-Q043, these tools are not yet able to examine GQUIC packets on a deep enough level that one has visibility into the specifics of the web traffic. This protocol analyzer therefore aims to accomplish two goals: (1) support the current standard of GQUIC, version Q046 and (2) inspect packets to the extent that specific information can be extracted from packets.

How it works:

Most GQUIC packets are encrypted, but the initial handshake between the client and server is not.
In a GQUIC handshake, a client sends a hello packet to the server.
The server will promptly send a rejection packet with important encryption, server configurations, and certificate values.
After this, the client will send a second hello packet using the values that the server provided it and establishing an encrypted communication channel.
If the client has cached the information the server requires, then only a single client hello is needed to establish communication.

Within the GQUIC client hello are a number of tag-value pairs containing various pieces of information. Almost any of these tag-value pairs can be extracted because of the custom data types defined by the protocol analyzer. The first, the PublicHeader type, records information in the unencrypted GQUIC header. Second, the HelloInfo type is capable of referencing 28 different tags in the GQUIC client hello packet. Two particularly valuable tags which are extracted and logged from the client hello are the client’s user agent ID and the domain name of the server. If the domain to which a user was connecting was a phishing site operating with GQUIC, it would be nearly impossible to detect using only the connection logs. However, thanks to the insight provided by the GQUIC log, the server name can be clearly seen and logged.

In addition, the server rejection packet has its own set of tags and values. These tags can also be extracted and analyzed by Zeek scripts. Just like the client hello has a special data type for it, the server rejection packet has the RejInfo type which can reference 17 different possible tags. Using these tools, almost all unencrypted GQUIC traffic going through the network can be dissected rather than merely generating generic UDP logs that only display IP addresses.

Below is a comparison of the information found in the connection log generated in Zeek by default and the GQUIC log generated by the protocol analyzer.

CYU:

In addition to logging the server and user agent, the protocol analyzer includes a fingerprinting system for GQUIC named CYU. Much like JA3 and HASSH, CYU creates an additional signature to aid with the detection of malicious activity in an environment. CYU fingerprints client hello packets by gathering the version and tags of a client hello packet and then MD5 hashing their values. (Here’s our reasoning for using MD5.) First, the version of the packet is extracted, immediately followed by a comma. After this, each tag in the client hello packet is gathered and concatenated together with hyphens to delimit each tag. For example, the most common format of client hello packets (making up the vast majority GQUIC traffic) is 46,PAD-SNI-STK-VER-CCS-NONC-AEAD-UAID-SCID-TCID-PDMD-SMHL-ICSL-NONP-PUBS-MIDS-SCLS-KEXS-XLCT-CSCT-COPT-CCRT-IRTT-CFCW-SFCW. Because this is not easily shared between security teams, it is then MD5 hashed for a value of a46560d4548108cf99308319b3b85346. The CYU hash can be used to identify odd user agents; for example, the canary version of Chrome on Mac OS typically has the rather unique value of 9a0ba9a10d979e1df60a0c1923e28866. (At the time of writing this, canary uses version Q044 of GQUIC). Thus, CYU acts as a method of anomaly detection for the network security analyst.

Use Case: Mitigating the Magic of Merlin

The GQUIC protocol analyzer and CYU hash are particularly useful when detecting beacons communicating over GQUIC, such as the Merlin command and control framework. Merlin C2 is a post-exploitation tool that specifically communicates over GQUIC to evade detection. Indeed, without the GQUIC protocol analyzer, the beacons and the server would be able to communicate completely undetected by network security monitors and all that would remain once the exploitation was complete would be generic UDP logs. However, with the GQUIC protocol analyzer, the IP and domain name of the command and control server that the beacon would be communicating with would be captured in the security team’s logs and that IP could be blocked. Moreover, Merlin C2 uses a unique combination of tags in its client hello packets. Rather than using the typical 25 tags found in most GQUIC traffic, Merlin C2 client hello packets use significantly fewer.

From our own internal testing, here are the CYU signatures belonging to Merlin C2 clients:

e030dea1f2eea44ac7db5fe4de792acd (43,PAD-SNI-VER-CCS-PDMD-ICSL-MIDS-CFCW-SFCW)
0811fab28e41e8c8a33e220a15b964d9 (43,PAD-SNI-STK-VER-CCS-SCID-PDMD-ICSL-MIDS-CFCW-SFCW)
d8b208b236d176c89407500dbefb04c2 (43,PAD-SNI-STK-VER-CCS-NONC-AEAD-SCID-PDMD-ICSL-PUBS-MIDS-KEXS-XLCT-CFCW-SFCW)

Now that these fingerprints have been identified, they can be easily used to detect malicious beacons in an environment.

Conclusion:

Ultimately, we are no longer blind to malicious activity occurring over GQUIC. With the GQUIC protocol analyzer, the current version (Q046) of GQUIC will be logged and monitored. Because the domains can now be extracted from the client hello packets, security analysts can see when end users visit malicious domains over GQUIC. Through CYU fingerprinting, unique traffic would be easier to spot which could help identify specific beaconing traffic. Now that this tool is open sourced, security teams can have greater visibility into GQUIC traffic which can lead to detecting threats over GQUIC. We hope that as GQUIC continues to evolve, this protocol analyzer and the state of network security will too.