Cobalt Strike is a commercial red-team tool whose cracked and pirated versions have become one of the most common command-and-control frameworks behind ransomware intrusions and nation-state operations alike. A Cobalt Strike team server is a TLS endpoint, and TLS endpoints can be fingerprinted. JARM is the tool most associated with doing that at scale.

[INFO]
This article summarises Salesforce's own JARM documentation and public coverage of its use against C2 infrastructure. An earlier version of this article included four "observed" JARM hashes as original findings; three were the wrong length for a real JARM hash (JARM is always 62 characters) and none could be verified, so all four have been removed.

//What JARM Actually Measures

John Althouse and Salesforce's security team released JARM in November 2020, as a follow-up to JA3/JA3S, the passive TLS client/server fingerprinting method Salesforce published in 2017. Where JA3/JA3S is passive - it reads fingerprints out of traffic that already happened - JARM is active: it sends ten specially crafted TLS Client Hello packets at a target and hashes the resulting set of responses into a single fingerprint.

Because the fingerprint depends on how the TLS stack is configured - supported cipher suites, TLS versions, extensions, and the order a server offers them in - two servers running identical software with identical configuration tend to produce the same JARM hash, even across different IP addresses. That is what makes it useful for finding more instances of the same infrastructure once one is known.

Cobalt Strike and other frameworks

Salesforce's original announcement specifically calls out Cobalt Strike as a common offensive tool whose team servers JARM can help identify, alongside other malware and C2 frameworks such as Trickbot, AsyncRAT, Metasploit and Merlin. Salesforce published an initial signature list alongside the tool.

//What JARM Does Not See

JARM fingerprints the TLS stack answering the connection, not necessarily the software behind it. A write-up from Advania reported that a Cobalt Strike team server sitting behind a transparent forwarder - socat or an iptables redirect, which just pass traffic through without touching it - still produced the team server's normal JARM hash, because the forwarder never terminates TLS. Put a reverse proxy such as HAProxy in front of the same server instead, so that the proxy terminates TLS and the operator's TLS stack is what JARM actually talks to, and the hash changes. A CDN in front of the team server would likely do the same.

The practical implication: a JARM match is evidence about the TLS implementation a connection reached, which is often but not always the team server itself. An operator who fronts their infrastructure with a reverse proxy or CDN can change their JARM fingerprint without touching Cobalt Strike at all.

//Using It

For actual detection work, Salesforce's own repository (github.com/salesforce/jarm) and a current signature list are the right starting point, not a hash list copied into an article. Infrastructure gets reconfigured, fronted and retired constantly; a JARM value that matched Cobalt Strike's defaults last year may not match an operator who has since changed their Malleable C2 profile or added a proxy in front of the team server.

[WARNING]
No dataset, scan result or sample-size figure here is this site's own research. The withdrawn version of this article claimed scanning results across observed IP space; that scan was never run from this site and has been removed along with the claim.