Configuring JA3 with Bro for Splunk

Back in September, my esteemed colleague Ryan Kovar and I gave a .conf2017 talk about using SSL/TLS data in Splunk to find nefarious activity. A large part of what we covered is made possible by three gentlemen at Salesforce—John B. Althouse, Jeff Atkinson, and Josh Atkins. As you can see, they all share the initials "JA" (along with an interest in SSL/TLS and threat intelligence). They developed JA3, a technique for creating SSL client fingerprints from the pre-encryption handshakes of the SSL protocol. At this time, you can generate JA3 fingerprints with either a Bro JA3 script or customizing an instance of Suricata. For our test set, we reprocessed PCAPS we collected at DEFCON25 with Bro JA3 scripts AND Suricata.

This blog post is going to go over how to create JA3 signatures with Bro and then how you could ingest those signatures into Splunk!

Why should you care?

Ryan recently wrote a blog post talking about how to track adversaries in Splunk using values in SSL certificates. These SSL certificate values are often selected or created by the malicious actor themselves; they can be changed and morphed. What makes JA3 signatures so interesting is that they are a mathematical hash of the SSL handshake before encryption. These values are often much more difficult to modify because they depend upon the software and libraries installed on the machine that generates the SSL certificate.

This may not be that interesting for certificates from large issuers like Thawte or Verisign, but often times malicious actors create self-signed SSL certificates. Those “self-signed” certificates are the ones that wil have unique JA3 fingerprint values. By bringing those values INTO Splunk, you can begin doing analysis to find unusual JA3 fingerprints or even match them against a threat list of known-bad JA3 fingerprints.

If you would like more information on this, please make sure to read the JA3 blog post by John Althouse, "Open Sourcing JA3." He goes over it in way more detail than we do here.

Okay, but I still have no clue what this JA3 signature actually is…

Right. Since wire data tools like Bro can’t make any sense of the encrypted data, Bro can only make metadata off of unencrypted data that is communicated during the SSL handshake. In the image below you can see the type of data that is passed during the SSL/TLS negotiation.

SSL data transmission sample

Attentive readers may notice that I have highlighted several fields. Those fields are what Bro (and Suricata) use to create the JA3 signature hashes. After these tools work their magic and convert the network data to JA3 compliant metadata it looks something like this :






SSL Version



SSL Cipher(s)



SSL Extension



SSL Elliptic Curve



SSL Elliptic Curve PointFormat



The JA3 Bro script then takes those fields and concatenates them with fields separated by a comma and values within the field, separated by a hyphen. It might look something like this: "57-56-51-50-22-19-53-47-10-255,0,0,0-35,769".

That string is hashed with md5 which results in the ja3 SSL client fingerprint. The results are output to the bro_ssl log file, where they can be monitored by Splunk.

Once we have that fingerprint, you can start using it to detect malicious things in Splunk!

Where to find the JA3 goodness

The JA3 code is hosted on github, where you can also find instructions on how to use it with Bro or standalone, with a python script. If you want to have some fun with JA3 signatures against known software, play around with JA3 lookups. There is a list of JA3 hashes and clients that they've been associated with, available on github.

Identifying the clients is a community effort, so if you're of a mind, please share information that you uncover back to the list so others can benefit from your work.

Bro Configuration

Utilizing the JA3 Bro config is reasonably straightforward. Provided you've got an out of the box Bro installation (if you don't, then you probably already know what to do), place the ja3 bro files file in /bro/share/bro/site/ja3. Then modify your local.bro config file (/opt/bro/share/bro/site/local.bro for me), adding the following line:

@load .ja3

For my testing, I also uncommented the additional log field values in ja3.bro:



However, if you want to save yourself a few bytes, just the ja3 (enabled by default) field works.

Just one more thing about Bro…

While we're on the subject of Bro configuration, there is one additional change that I like to make. I prefer json output, as opposed to the default of tab separated. The primary reason is that if the logging format changes (because of a plugin or a new version), you won't have to modify the parsing in the Splunk TA. You may have to add or modify an alias but that's easy enough.

The secondary reason is that Splunk has display formatting for JSON, making it much prettier. The downside is that it uses additional storage, so it's up to you. To make the change, go to your ascii.bro file (located at /opt/bro/share/bro/base/frameworks/logging/writers/ for me), which is the configuration file that defines various aspects of the log output, and modify the following line from:

const use_json = F &redef;


const use_json = T &redef;

There are a few TAs floating around that handle the Bro JSON output format, including CIM aliases for the "out of the box" fields. I have one that's a modified version of the supported Splunk Bro TA, which you can find on github.

As always, feedback is encouraged.


If you've followed the Hunting the Known Unknowns talks that Ryan and I have given at .conf for the past 3 years, you're probably familiar with:

In the spirit of Bonus Round, I've added a few things that didn't make it into the talk.
I mentioned it earlier, but the JA3 repository also contains a python script that is used to pull the required fields for a JA3 fingerprint and calculate that fingerprint using a PCAP file as input. I made a few changes to the script here.

I modified the json output to include the timestamp from the original transaction. I also modified some of the field names in the output, so they are Splunk Common Information Model compliant. Now, you can bring those logs in by themselves and discover useful information.

I've posted a simple TA online to work with the json output, located here.


Thank you to those who have developed the ja3 fingerprinting technique and everyone contributing to the effort.

Steve Brant

Posted by