JA-3 Fingerprinting. Functionality, Pitfalls, and Future Outlook

With challenges as complex as the myriad of technologies involved, the need for accurate representation regarding all things cyber remains an elusive endeavour. Consequently, if there's one resounding principle actionable intelligence via internet scanning has taught us, it is that adopting a proactive attitude towards accurate threat identification and correlation is the necessary first step if we are serious (or even care) about evidence-based knowledge and contextualization dictating the flow of any successful investigation. This is particularly true of information delivered in the form of IoCs (Indicators of Compromise) which, for years, have been the cornerstone of many security products based on forensic artifacts and similar intrusion detection mechanisms. Sharing these IoCs in a tokenized and consumable fashion has also ensured that the cyber community at large stays visibly engaged with the latest attack patterns, whatever their origin or level of sophistication may be. At the heart of this blog post lies yet another attempt, this time by Salesforce researchers John Althouse, Jeff Atkinson, and Josh Atkins, to collect threat information into a new Io-C variant by fingerprinting the initial conditions that dominate TL-S client and server responses regardless of the underlying platform. In fact, JA-3, a fortuitous amalgam of the authors' names, has now been incorporated into a multitude of security tools as a method to detect malicious applications, especially those deployed at mass scale and without regard for trivial detection. We'll begin our journey by briefly examining the determining conditions surrounding TLS's handshake process as it pertains to the set of extensions used by JA-3 to fingerprint associated traffic between client and server, extending our focus to encompass relevant aspects of the hashing and tagging capabilities associated with JA-3 in identifying malware platforms and C2 agents. Finally, we'll explore some of the shortcomings associated with JA-3 in light of circumventing attempts aimed at the core of its very functionality. A TL-S, SS-L primer Sensitive data requires the strongest of protection mechanisms. For a number of years, premier standards and protocols, like Secure Sockets Layer (SS-L), dominated the secure tunneling scene by achieving a suitable interplay between performance and confidentiality, providing secure communications over untrusted media such as the internet. Despite its early success, SS-L progressively eroded under a plethora of cryptographic weaknesses and statistical biases marked by protocol design flaws that signaled the potential for brute-force attacks, in particular, the AE-S, CB-C and RC-4 implementations were notorious for leaking sensitive cipher material in the presence of weak keys leading up to full plaintext recovery scenarios. Subsequently, as explained in JARM: A Solid Fingerprinting Tool for Detecting Malicious Servers, Transport Level Security (TL-S) became the next evolutionary variant after a long chain of revisions and improvements that entailed adopting newer forms of cryptographic primitives and cipher suites, the negotiation of session keys in lieu of early distributed approaches, and better computation costs. It was precisely this cryptographic agility that gave TL-S its multifaceted quality, covering a wider range of network applications and providing critical services such as confidentiality and integrity. To understand how JA-3 leverages certain TL-S attributes, let's take a closer look at the protocol's initial connection sequence. Immediately following the TC-P handshake, the client side sends a ClientHello message containing combinations of cryptographic algorithms supported (and preferred) by the caller, versioning details, extensions, a list of compression methods, and other session parameters in blocks of application data. In response, the server sends its own ServerHello message when a satisfactory set of algorithms has been confirmed—t...