JA4+ network fingerprinting

In this blog post, I look at new JA4+ network fingerprinting methods and examples of what they can detect.

JA4+ provides a suite of modular network fingerprints that are easy to use and easy to share, replacing the JA3 TLS fingerprinting standard from 2017. These methods are both human and machine-readable to facilitate more effective threat-hunting and analysis. The use cases for these fingerprints include scanning for threat actors, malware detection, session hijacking prevention, compliance automation, location tracking, DDoS detection, grouping of threat actors, reverse shell detection, and many more.

JA4	TLS client
JA4S	TLS server response
JA4H	HTTP client
JA4L	Light distance / location
JA4X	X509 TLS certificate
JA4SSH	SSH traffic

More fingerprints are in development and will be added to the JA4+ family as they are released.

Examples are shown in Tables 2 and 3.

Application	JA4+ fingerprints
Chrome	JA4=t13d1516h2_8daaf6152771_e5627efa2ab1 (TCP) JA4=q13d0310h3_55b375c5d22e_cd85d2d88918 (QUIC) JA4=t13d1516h2_8daaf6152771_02713d6af862 (ECH)
IcedID Malware Dropper	JA4H=ge11cn020000_9ed1ff1f7b03_cd8dafe26982
IcedID Malware	JA4=t13d201100_2b729b4bf6f3_9e7b989ebec8 JA4S=t120300_c030_5e2616a54c73
Sliver Malware	JA4=t13d190900_9dc949149365_97f8aa674fd9 JA4S=t130200_1301_a56c5b993250 JA4X=000000000000_4f24da86fad6_bf0f0589fc03 JA4X=000000000000_7c32fa18c13e_bf0f0589fc03
Cobalt Strike	JA4H=ge11cn060000_4e59edc1297a_4da5efaf0cbd JA4X=2166164053c1_2166164053c1_30d204a01551
SoftEther VPN	JA4=t13d880900_fcb5b95cb75a_b0d3b4ac2a14 (client) JA4S=t130200_1302_a56c5b993250 JA4X=d55f458d5a6c_d55f458d5a6c_0fc8c171b6ae
Qakbot	JA4X=2bab15409345_af684594efb4_000000000000
Pikabot	JA4X=1a59268f55e5_1a59268f55e5_795797892f9c
Darkgate	JA4H=po10nn060000_cdb958d032b0
LummaC2	JA4H=po11nn050000_d253db9d024b
Evilginx	JA4=t13d191000_9dc949149365_e7c285222651
Reverse SSH Shell	JA4SSH=c76s76_c71s59_c0s70

IP Address	Domain
81.200.149.183	1293195-ci21745.tw1.ru
99.79.189.27	mobile-atrf.com
64.225.109.152	staging.cupid.blunun.com
46.148.26.88	microsoft.com.updatenetworksinfo.com
45.32.120.18	hlakgabiugalibafnafadsfapian.micsoft.org

What is JA4+?

JA4+ is a set of simple yet powerful network fingerprints for multiple protocols that are both human and machine-readable, facilitating improved threat-hunting and security analysis. If you are unfamiliar with network fingerprinting, I encourage you to read my posts releasing JA3 here, JARM, and this excellent blog by Fastly on the State of TLS Fingerprinting, which outlines the history of the aforementioned along with their problems. JA4+ brings dedicated support, keeping the methods up to date as the industry changes. Additionally, and by popular demand, an official JA4+ database of fingerprints, associated applications and recommended detection logic is in the process of being built.

All JA4+ fingerprints have an a_b_c format, delimiting the different sections that make up the fingerprint. This allows for hunting and detection using just ab or ac or c only. If you wanted to just do an analysis on incoming cookies into their app, you would look at JA4H_c only. This new locality-preserving format facilitates deeper and richer analysis while remaining simple, easy to use, and allowing for extensibility.

In this post, we are releasing JA4/S/H/L/X/SSH, or JA4+ for short. More fingerprints are in development and will be added to the JA4+ family as they are released.

JA4: TLS client fingerprint

TLS is used to encrypt the vast majority of traffic on the Internet, from web browsing to streaming to IoT usage analytics. Even malware uses TLS to hide its malicious communications. At the beginning of a TLS connection, the client sends a TLS Client Hello packet, which is sent in the clear, before encrypted communication. This packet, generated by the client application, informs the server of what ciphers it supports as well as its preferred method of communication. As such, the TLS Client Hello packet is unique per application or its underlying TLS library.

JA4 looks at this TLS Client Hello packet and builds out an easily understandable and shareable fingerprint. The format is shown in Figure 2.

JA4 fingerprints the client, no matter if the traffic is over TCP or QUIC. QUIC is the protocol used by the new HTTP/3 standard that encapsulates TLS 1.3 into UDP packets. As QUIC was developed by Google, if an organization heavily uses Google products, QUIC could make up half of their network traffic, so this is important to capture.

JA4 also clearly shows the Application-Layer Protocol Negotiation (ALPN). This represents the protocol that the application wants to communicate in after the TLS negotiation is complete. ‘h2’ = HTTP/2, ‘h1’ = HTTP/1.1, ‘dt’ = DNS-over-TLS, and so on. A full list of possible ALPNs is available. A ’00’ here denotes the lack of ALPN. Note that the presence of ALPN ‘h2’ does not indicate a browser as many IoT devices communicate over HTTP/2. However, the lack of an ALPN may indicate that the client is not a web browser.

More technical details for implementation and what the raw (unhashed) fingerprint looks like are available on GitHub.

Application	JA4 (client)
Chrome	t13d1518h2_8daaf6152771_e5627efa2ab1 (TCP initial)
	t13d1518h2_8daaf6152771_9b887d9acb53 (TCP reconnect)
	q13d0310h3_55b375c5d22e_cd85d2d88918 (QUIC initial)
	q13d0311h3_55b375c5d22e_3512bcbbc9ec (QUIC reconnect)
SoftEther VPN Client	t13d880900_fcb5b95cb75a_b0d3b4ac2a14 (88 ciphers!?)
IcedID Malware	t13d201100_2b729b4bf6f3_9e7b989ebec8
Evilginx	t13d191000_9dc949149365_e7c285222651
Sliver Malware	t13d190900_9dc949149365_97f8aa674fd9 (GoLang)

Even though the traffic is encrypted over TLS 1.3, we are still able to gain a huge amount of valuable information about the client application. Remember that most custom applications will have the fingerprint of their underlying TLS libraries. So, a program written in Go will likely have a JA4 that matches other Go programs. The same is true for Python, Java, and so on, while custom programs like VPN clients, Steam, Slack, and Windows functions will be unique.

JA4 can be extremely valuable in production networks where applications are largely static. If you are running an all-Linux infrastructure, then a Windows JA4 fingerprint would be worth looking into. If you’re running only Exchange servers, then a sudden Python JA4 fingerprint would be worth investigating. JA4 makes for a great pivot point in analysis when trying to understand network traffic and the a_b_c format allows for deeper analysis.

For example, GreyNoise is an Internet listener that identifies Internet scanners and is implementing JA4+ into their product. They have an actor who scans the Internet with a constantly changing single TLS cipher. This generates a massive amount of completely different JA3 fingerprints but with JA4, only the b part of the JA4 fingerprint changes, parts a and c remain the same. As such, GreyNoise can track the actor by looking at the JA4_ac fingerprint (joining a+c, dropping b).

JA4S: TLS server/session fingerprint

After a client sends its TLS Client Hello packet, the server will respond with its TLS Server Hello packet. This packet, also sent in the clear, is formulated based on the server’s selection of available options in the Client Hello. This includes the one cipher chosen out of the list of available options and any extensions the server wishes to set.

As such, the Server Hello is unique to both the server application and the Client Hello that was sent to it. A different Client Hello may cause a different Server Hello, and therefore a different JA4S, from the same server. However, the same Client Hello will always produce the same Server Hello from that server application. For example, if the client sends JA4=a_b_c and the server responds with JA4S=d_b_e, that server will always respond to a_b_c with d_b_e. But if another application sends a different Client Hello to that same server, say JA4=x_y_z, the server will respond with a different server hello, JA4S=t_y_v. So, it’s a different response to different applications but always the same response to the same application. I go into more detail on this in my JA3S blog post.

Application	JA4 (client)	JA4S (server response)
IcedID Malware	t13d201100_2b729b4bf6f3_9e7b989ebec8	t120300_c030_5e2616a54c73
SoftEther VPN	t13d880900_fcb5b95cb75a_b0d3b4ac2a14	t130200_1302_a56c5b993250
Sliver Malware	t13d190900_9dc949149365_97f8aa674fd9 (GoLang)	t130200_1301_a56c5b993250 (Sliver Server)
Addigy (Apple device management)	t13d190900_9dc949149365_97f8aa674fd9 (GoLang)	t130200_1301_234ea6891581 (Addigy Server)

JA4S, when combined with JA4, significantly increases detection fidelity. Going from merely identifying the underlying libraries of a client to identifying the client or malware family. Beyond application identification, one could look at just JA4S_b to understand what ciphers are being used on any given network to ensure it is meeting compliance requirements. All of this is possible without breaking encryption.

JA4H: HTTP client fingerprint

JA4H fingerprints the HTTP client based on each HTTP request. As most traffic is encrypted, JA4H is best used on servers, proxies, Web Application Firewalls (WAFs), TLS-terminating load balancers, and environments where TLS is decrypted. However, JA4H is still valuable even in environments where TLS is not decrypted because several devices and programs, including malware, still communicate over HTTP. The IcedID malware dropper, for example, doesn’t use TLS. These malware programs are very easy to fingerprint.

JA4H_ab is a fingerprint of the application for the given HTTP method used. The lack of an Accept-Language is a clear indication that the application is not human interactive and, therefore a bot.

JA4H_c is a fingerprint of the cookie and will be different for each website visited but will be the same for that website or application. For example, every Plex server or Okta server will produce the same JA4H_c.

JA4H_d is a fingerprint of the user and will be different per user. This allows for tracking of a user through a website without logging SPII, thereby keeping the logging system General Data Protection Regulation (GDPR) compliant.

More details on the technical implementation can be found on our GitHub.

Table 6 — JA4H examples.

On the server side, one could use JA4H_c as a hunting method. As the server is specifying which cookie fields the client should use, all clients should have the same JA4H_c. Discrepancies here merit investigation. One could also track a user with JA4H_d and their client application with JA4H_ab or identify bots with just JA4H_ab.

On the client side (proxy, NDR, zero trust), JA4H combined with JA4 and JA4S allow for extremely high-fidelity application and malware detection.

There are several use cases for JA4H, especially when combined with the rest of JA4+. I’ll cover all of them in more detail in a later blog post.

JA4L: Light distance locality

JA4L measures the distance between a client and a server by looking at the latency between the first few packets in a connection. We use the first few packets because these are low-level machine-generated, so there is nearly zero processing delay in creating and sending these packets. Time is measured in microseconds (µs), 1ms = 1000µs, as microseconds are a standard unit of time measurement in packet captures.

If JA4L is running server side, this will measure the distance of the client from the server and if this is running client side, this will measure the distance of the server from the client. If this is running on a network tap, it will measure the distance of each from the network tap location.

JA4L is split up into two measurements, client and server. For TCP, these are determined by looking at the TCP 3-way handshake. For UDP, we’re looking at the QUIC handshake.

JA4L-C = {(C-B)/2}_Client TTL
JA4L-S = {(B-A)/2}_Server TTL

In Figure 6:
JA4L-C = 11_128
JA4L-S = 1759_42

JA4L-C = {(D-C)/2}_Client TTL
JA4L-S = {(B-A)/2}_Server TTL

In Figure 7:
JA4L-C = 37_128
JA4L-S = 2449_42

Distance measurement

With JA4L we can determine the distance between the client and server using this formula:

D = jc/p

• D = Distance
• j = JA4L_a
• c = Speed of light per µs in fibre (0.128 miles/µs or 0.206km/µs)
• p = Propagation delay factor

Typical propagation delay depends on the terrain and how many networks are involved.

• Poor terrain factor = 2 (around mountains, water)
• Good terrain factor = 1.5 (along highway, undersea cables)
• SpaceX factor = … needs to be tested

We can use the TTL to calculate the hop count, which can help inform the propagation delay factor (Table 6 is a good starting point but more testing needs to be done).

Hop count	Propagation delay factor
<=21	1.5
22	1.6
23	1.7
24	1.8
25	1.9
>=26	2.0

To calculate the number of hops a connection went through, subtract the TTL from its estimated initial TTL.

• Cisco, F5, and most networking devices use a TTL of 255
• Windows uses a TTL of 128
• Mac, Linux, phones, and IoT devices use a TTL of 64

Most routes on the Internet have less than 64 hops. Therefore, if the observed TTL, JA4L_b, is <64, the estimated initial TTL is 64. Within 65-128, the estimated initial TTL is 128. And if the TTL is >128 then the estimated initial TTL is 255.

With a JA4L-S of 2449_42, the observed TTL of 42 means the initial TTL was likely 64, a Linux server. 64-42 gives us a hop count of 22.

• 2449×0.128/1.6=195

We can conclude that this server is within 195 miles of the client. The server may be closer than this, but it is physically impossible for it to be farther away as the speed of light is constant. If there are multiple JA4Ls for the same host, the lowest value should be taken as the most accurate.

In this example, the actual distance was 194 miles. Utilizing multiple locations, one can passively triangulate the physical location of any client or server down to a city area (more on this in a later blog post…).

Additionally, JA4L_b (TTL) passively facilitates the identification of source operating systems, which is an excellent data point to have when performing forensic analysis. Also, because JA4L is looking at Layer 3 data, it works on encrypted and unencrypted traffic.

Combining JA4 with JA4H and JA4L on the server side makes it possible for the server application to identify session hijacking or MiTM attacks. If a session cookie (JA4H_d) were to suddenly change locations, operating systems (JA4L), and application (JA4 and JA4H_ab), then it would make sense to revoke the session token, asking the user to log back in with MFA. With this type of logic, special care should be taken to not allowlist particular fingerprints as applications will change over time, but instead to look for dramatic changes. Session hijacking detection with JA4+ is something darksail.ai is working on right now.

JA4X: X509 TLS Certificate Fingerprinting

Credit: W.

JA4X fingerprints how TLS certificates are generated — not the values within the certificate. This can identify applications and settings used to create the certificate, which can be extremely useful in threat hunting as threat actors will create different certificates but tend to use the same methods to create said certificates, thereby having the same JA4X fingerprint.

Server Application	JA4X
SoftEther VPN	d55f458d5a6c_d55f458d5a6c_0fc8c171b6ae
Metasploit	2bab15409345_2bab15409345_75f1b0fafedd
Qakbot	2bab15409345_af684594efb4_e3b0c44298fc
Async, Quasar, BitRAT	7022c563de38_7022c563de38_0147df7a0c11
Sliver Malware / Havoc C2	000000000000_7c32fa18c13e_bf0f0589fc03 000000000000_4f24da86fad6_bf0f0589fc03

SoftEther VPN was heavily used by Chinese APT actors, Flax Typhoon, to compromise Taiwan infrastructure, and Storm-0558 in the hacking of US government email accounts. According to Microsoft, it is very difficult to differentiate these connections from legitimate HTTPS traffic. However, because of the programmatic way that SoftEther generates its certificates, the JA4X is unique to SoftEther. If JA4X were to be implemented into a firewall, blocking traffic to SoftEther VPNs would be trivial. By using a JA4X feed, blocking inbound traffic from SoftEther VPNs would be trivial as well.

Most certificate-issuing organizations will use the same underlying program to generate and sign all of their certificates. Using Internet scan data enriched with JA4X from our friends at Hunt.io, we can examine Issuer Organization = “Microsoft Corporation” as an example.

In Figure 10, you can see that 99.8% of observed certificates have the same JA4X. The next one down is very similar, but the third one looks completely different. Let’s pivot on this anomaly.

Threat hunting with JA4X on Internet scan data is extremely powerful because rather than looking at the values within a certificate, which, in the case of malware, are usually randomly generated, JA4X looks at how the certificate was generated.

One final example is Sliver C2, which is a newer pentesting framework that is replacing Cobalt Strike in popularity. Like most good pentesting frameworks, Sliver is also heavily used by threat actors as it is designed to be difficult to detect.

Sliver has over 400 lines of code dedicated to randomly generating TLS certificates. As such, each certificate is unique and pivoting on a certificate hash will yield no results.

However, each certificate is also generated by the same application and therefore has the same JA4X. Havoc C2 uses most of the Sliver code so it too has the same JA4X, but can be differentiated by looking at the Org Name and Postal Code length. In either case, both are malware and the JA4X is unique on the Internet. Our friends at driftnet.io offer a JA4X feed and, with it, were able to quickly identify all default Sliver C2s listening on the Internet.

Table 8 — Sliver C2 List Identified from JA4X Internet Scan 9 September 2023 (this is not a full list just a small excerpt for example purposes). Source: driftnet.io‘s JA4X feed.

These examples show how JA4X can be used to detect and block traffic to SoftEther, Tor, Metasploit, Sliver, Havoc, RAT C2s, and more. Note that TLS certificates are sent in the clear in TLS 1.2 but are encrypted in TLS 1.3 so JA4X is best utilized on proxy servers, firewalls, MDR, NDR and Zero Trust applications that have that level of inspection. JA4X, when combined with JA4, JA4S, JA4H and JA4L provides an unparalleled level of visibility and detection capability. When used in Internet scanning, JA4X is an excellent tool for pivot analysis and hunting down malicious servers, especially when combined with JARM data.

JA4SSH: SSH traffic fingerprinting

JA4SSH fingerprints SSH sessions by looking at SSH packets and providing a small, simple, easy-to-read fingerprint of the session on a configurable rolling basis, every 200 packets by default. With this, we can determine what is happening within the SSH connection, even though the traffic is encrypted, and provide an analyst with a simple set of fingerprints for their analysis.

Note that JA4SSH fingerprints the SSH session, not the SSH applications. For SSH application fingerprinting, I recommend you take a look at HASSH, by my good friend Ben Reardon.

Type of SSH session	JA4SSH
Interactive shell (normal)	c36s36_c51s80_c69s0
Interactive reverse shell	c76s76_c71s59_c0s70
SCP file transfer to client	c112s1460_c0s179_c21s0

To understand how SSH traffic works and how to identify tunnels using traffic analysis, I recommend you read these excellent blogs on the subject by Trisul here and here.

In short, SSH packets are padded out to a particular length depending on the cipher algorithm and HMAC used. With chacha20-poly1305, that ends up being 36 bytes. When the client types a character into the SSH terminal, that character is encrypted with the packet padded to 36 bytes and then sent to the server. The server will respond with the same character in a 36-byte packet and that’s when the character is displayed in the terminal window. The client will then send a TCP ACK packet to tell the server that they’re done with the previous transaction. Because of this, a client typing in a terminal will look like Figure 14.

In Figure 14, notice that the TCP ACKs are coming from the side doing the SSH requests (client) and the server returns the output of the command at the bottom. The JA4SSH for this looks like c36s36_c51s80_c69s0. So, you see 36/36 and all the ACKs are from the client, the server has sent none, so from these we can easily see that it is an interactive forward SSH session.

In a reverse SSH shell, it’s SSH over SSH so the packets are double padded + HMAC (Figure 15).

The JA4SSH for this looks like c76s76_c71s59_c0s70. We can clearly see a common packet length of 76/76, double padded, and all of the ACKs are coming from the server, meaning it is the server side that is doing the typing. It’s important to note that SSH provides encrypted messages, not an encrypted tunnel, so Layer 4 packets, the TCP ACK packets, are sent in the clear. It is with these that we can determine which side is initiating the requests. By using JA4SSH, it is now trivial to detect reverse SSH shells.

Licensing

JA4: TLS Client Fingerprinting is open source, BSD 3-Clause, the same as JA3. This allows any company or tool currently utilizing JA3 to immediately upgrade to JA4 without delay.

JA4S, JA4L, JA4H, JA4X, JA4SSH, and all future additions (collectively referred to as JA4+), are licensed under the FoxIO License 1.1. This license is permissive for most use cases, including for academic and internal business purposes, but is not permissive for monetization. If, for example, a company would like to use JA4+ internally to help secure their own company, that is permitted. If, for example, a vendor would like to sell JA4+ fingerprinting as part of their product offering, they would need to request an OEM license from us.

JA4+ can and is being implemented into open source tools, see the License FAQ for details.

This licensing allows us to provide JA4+ to the world in a way that is open and immediately usable, but also provides us with a way to fund continued support, research into new methods, and the development of the upcoming JA4+ Database. We want everyone to have the ability to utilize JA4+ and are happy to work with vendors and open source projects to help make that happen.

Conclusion

JA4+ provides a suite of modular network fingerprints that are easy to use and easy to share. The use cases for these fingerprints include scanning for threat actors, malware detection, session hijacking prevention, compliance automation, location tracking, DDoS detection, grouping of threat actors, reverse shell detection, and many more. JA4 (TLS Client Fingerprinting), is licensed under BSD 3-Clause, allowing tools running JA3 to immediately upgrade, while JA4+ (JA4S/L/H/X/SSH) is under the FoxIO License, which is permissive for most use cases except monetization. For that the vendor would need to purchase an OEM license, which funds further research and the development of the JA4 database (coming soon). We plan to release a new JA4 method about once per quarter so stay tuned.

JA4+ is available on GitHub. For licensing or questions, reach out to us at FoxIO. You can reach me directly on LinkedIn or Twitter/X.

JA4+ was created by John Althouse with feedback from Josh Atkins, Jeff Atkinson, Joshua Alexander, W., Joe Martin, Ben Higgins, Andrew Morris, Chris Ueland, Ben Schofield, Matthias Vallentin, Valeriy Vorotyntsev, Timothy Noel, Gary Lipsky, and engineers working at GreyNoise, Hunt, Google, ExtraHop, F5, Driftnet, and others.

John Althouse is the Founder of FoxIO and a serial inventor in cyber security.

This post is adapted from the original at FoxIO’s blog.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.