Modified the original ESA rule (ja3context.txt) with additional/better logic to match destination port numbers between the Endpoint and Network sessions. Additionally, I recommend disabling the "Alert" option in the rule, as this can be a noisy alert and might unnecessarily clutter your incident and alert queues; please note that disabling this will NOT prevent the script notification output, it will only stop an alert from being sent to Respond.
Also added a different ESA rule (ja3window.txt) that does the same thing, but instead of relying on a script to produce a finalized list, the results with the linked JA3 fingerprint and application information are held in a Named Window - ja3curated; this approach might be better if a Feed is not a desired outcome, but you still want to be able to use the JA3/Application context for other ESA alerting.
A couple years ago, a few smart folks over at salesforce came up with the idea of fingerprinting certain characteristics of the "Client Hello" of the SSL/TLS handshake, with the goal to more accurately identify the client application initiating TLS-encrypted sessions.
- GitHub - salesforce/ja3: JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.
This concept certainly has potential to provide invaluable insight during incident response, though there are some significant operational limitations that (my opinion) have so far prevented JA3 fingerprinting from gaining more widespread adoption and use. Perhaps the biggest of these limitations is the need for some kind of known JA3 fingerprint library or repository, where the thousands (?potentially millions?) of client applications that might initiate a TLS handshake can be reliably matched with their JA3 fingerprint. There are a couple sites building out these repositories
...but their content is limited (after all, fingerprinting a client requires installing it, running it, capturing the PCAP, running a JA3 parser or script against the PCAP, and then adding that fingerprint to the library; that process simply does not scale) and the fidelity/accuracy/timeliness of these libraries is a pretty large question mark.
However, with NetWitness 11.3.1, which has a native option to enable JA3 and JA3S fingerprinting, and NetWitness Endpoint 11.3 we can bridge this gap and create our own JA3 libraries.
The concept is fairly simple
- use NetWitness Endpoint to identify applications making outbound network connections
- use NetWitness Network to identify outbound HTTPS traffic
- link these events and sessions by their common characteristics
- once we have that link
- extract the filename and sha256 hash of the application from the NetWitness Endpoint event
- along with the JA3 fingerprint from the network session
- and then create a feed of that information that the NetWitness Platform can use for additional context
In order to ensure this process scales, we can make use of the ESA's rule engine to identify the sessions we want and it's script output functionality to create the feed for us. The ESA rule and python script output are attached to this blog.
Prior to enabling these, you'll want to make sure the "netwitness" user has either read/write access to the "/var/netwitness/common/repo" directory on the Admin Server, a.k.a Node0, or at least read/write access to the "ja3Context.csv" file in that directory that the ja3context.py script will update.
A good guide for setting ACLs in CentOS is here: https://www.tecmint.com/give-read-write-access-to-directory-in-linux/ and the result:
Once the appropriate permissions are set and you've enabled the ESA rule and its script output, your last step will be to turn that CSV output into a feed (A list two ways - Feeds and Context Hub - many thanks again to the SE formerly known as Eric Partington for this blog):
...and choose your meta keys:
And voila! We have an automatically generated and constantly updating library of applications for our JA3 fingerprints: