Jarm: A Solid Fingerprinting Tool for Detecting Malicious Servers

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version. The literature on defensive security unanimously recognizes one fact: every so often, a tool comes out that provides blue teamers with an important advantage over their adversaries. This ever-elusive quest features essential requirements and commonalities, such as the ability to proactively seek and detect malicious hosts, or the capacity to swiftly respond to targeted network threats. And with a sharp rise in the number of incidents involving some form of malware or command and control (C2) activity resulting in data theft, vendors are in a tight race to gain their customers' trust—by leveraging newer alternatives to legacy solutions amidst shrinking budgets. In the spirit of searching and identifying malicious servers anywhere they can be found, the folks at Salesforce Engineering have recently released an open-source application called Jarm, which pivots on knowledge of Transport Layer Security (TLS) mechanisms to accomplish just that. This blog post will take you on a brief tour of Jarm to show you why we consider it a worthy addition to your Osint tools. TLS and Jarm TLS is the next evolutionary step from its early SSL (Secure Sockets Layer) ancestor. As its predecessor, the TLS assembly introduces its own version of a handshake process (Figure 1) by which cryptographic primitives, also known as cipher suites, are agreed to between client and server prior to any data exchange. It is precisely this cryptographic agility that gives TLS its multifaceted quality; covering a wide range of applications (e.g., web traffic) and providing critical services such as confidentiality and integrity. To understand how Jarm leverages certain TLS attributes, let's take a closer look at the protocol's initial connection sequence. Immediately following the TCP 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—the packet is also formulated with the server's own version of the connection parameters used by the client. Subsequently, server and client proceed to verify each other's authenticity via digital certificates, after which both parties compute the premaster and master secrets used to derive session keys, any wrapper messages, and the remaining traffic tunneling structures. The TLS parameters offered in the *ClientHello* message contain several identifying properties that are directly related to the client application. These features include OS builds, packages, libraries, and even process attributions. This level of granularity is particularly helpful in building **fingerprints** with a high degree of accuracy that can be leveraged to identify the same application during future sessions. Similarly, TLS servers construct their *ServerHello* packets based on the *ClientHello* ones as well as their own subset of built-in identifiers such as: Operating system name and version. Server-side libraries. Other custom configurations. Once again, this symbiotic relationship between client and server *Hello* packets dictates the way in which servers uniquely respond to a specific application, providing an excellent opportunity for quick identification via fingerprinting. And this is where Jarm comes in. What is Jarm? As previously mentioned, Jarm is a **TLS server fingerprinting application** recently released as an open source project by the engineering group at Salesforce. The tool shares some similarities with a previous method of profiling TLS clients using JA3 signatures, released by the same team, which passively examines network traffic collecting fingerprints fro...