{ "id": "b73c9a9a-8d45-402e-b863-8e257876d182", "created_at": "2026-04-06T00:13:53.087027Z", "updated_at": "2026-04-10T13:12:04.539771Z", "deleted_at": null, "sha1_hash": "0ce540c2d1bd86cd34a82fe8bde1d282e4d51957", "title": "Easily Identify Malicious Servers on the Internet with JARM - Salesforce Engineering Blog", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1330993, "plain_text": "Easily Identify Malicious Servers on the Internet with JARM -\r\nSalesforce Engineering Blog\r\nBy John Althouse, Laura Lindeman\r\nPublished: 2020-11-17 · Archived: 2026-04-05 17:17:40 UTC\r\nTL;DR\r\nJARM is an active Transport Layer Security (TLS) server fingerprinting tool.\r\nScanning with JARM provides the ability to identify and group malicious servers on the Internet.\r\nJARM is available here: https://github.com/salesforce/jarm\r\nJARM fingerprints can be used to:\r\nQuickly verify that all servers in a group have the same TLS configuration.\r\nGroup disparate servers on the internet by configuration, identifying that a server may belong to Google vs.\r\nSalesforce vs. Apple, for example.\r\nIdentify default applications or infrastructure.\r\nIdentify malware command and control infrastructure and other malicious servers on the Internet.\r\nIn this blog post you will learn:\r\nHow JARM works.\r\nHow JARM can be used to identify malicious servers.\r\nMoving from reactive to proactive cybersecurity blocklists.\r\nHow to deploy JARM into your detection and response pipeline.\r\nHow JARM can be used for configuration validation and application identification.\r\nHow JARM Works\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 1 of 10\n\nBefore learning how JARM works, it’s important to understand how TLS works. TLS and its predecessor, SSL,\r\nare used to encrypt communication for both common applications like Internet browsers, to keep your data secure,\r\nand malware, so it can hide in the noise. To initiate a TLS session, a client will send a TLS Client Hello message\r\nfollowing the TCP 3-way handshake. This packet and the way in which it is generated is dependent on packages\r\nand methods used when building the client application. The server, if accepting TLS connections, will respond\r\nwith a TLS Server Hello packet.\r\nThis exquisite mouse-drawn network diagram shows how TLS works, for the most part, basically.\r\nTLS servers formulate their Server Hello packet based on the details received in the TLS Client Hello packet. The\r\nmanner in which the Server Hello is formulated for any given Client Hello can vary based on how the application\r\nor server was built, including:\r\nOperating system\r\nOperating system version\r\nLibraries used\r\nVersions of those libraries used\r\nThe order in which the libraries were called\r\nCustom configuration\r\nAll of these factors lead to each TLS Server responding in a unique way. The combinations of factors make it\r\nunlikely that servers deployed by different organizations will have the same response.\r\nBelow is an example of a TLS Client Hello and the Server Hello response as viewed in Wireshark.\r\nExample TLS Client Hello packet (left) and Server Hello response (right)\r\nJARM works by actively sending 10 TLS Client Hello packets to a target TLS server and capturing specific\r\nattributes of the TLS Server Hello responses. The aggregated TLS server responses are then hashed in a specific\r\nway to produce the JARM fingerprint.\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 2 of 10\n\nThis is not the first time we’ve worked with TLS fingerprinting. In 2017 we developed JA3/S, a passive TLS\r\nclient/server fingerprinting method now found on most network security tools. But where JA3/S is passive,\r\nfingerprinting clients and servers by listening to network traffic, JARM is an active server fingerprinting scanner.\r\nYou can find out more about TLS negotiation and JA3/S passive fingerprinting here.\r\nThe 10 TLS Client Hello packets in JARM have been specially crafted to pull out unique responses in TLS\r\nservers. JARM sends different TLS versions, ciphers, and extensions in varying orders to gather unique responses.\r\nDoes the server support TLS 1.3? Will it negotiate TLS 1.3 with 1.2 ciphers? If we order ciphers from weakest to\r\nstrongest, which cipher will it pick? These are the types of unusual questions JARM is essentially asking the\r\nserver to draw out the most unique responses. The 10 responses are then hashed to produce the JARM fingerprint.\r\nThe JARM fingerprint hash is a hybrid fuzzy hash, it uses the combination of a reversible and non-reversible hash\r\nalgorithm to produce a 62 character fingerprint. The first 30 characters are made up of the cipher and TLS version\r\nchosen by the server for each of the 10 client hello’s sent. A “000” denotes that the server refused to negotiate with\r\nthat client hello. The remaining 32 characters are a truncated SHA256 hash of the cumulative extensions sent by\r\nthe server, ignoring x509 certificate data. When comparing JARM fingerprints, if the first 30 characters are the\r\nsame but the last 32 are different, this would mean that the servers have very similar configurations, accepting the\r\nsame versions and ciphers, though not exactly the same given the extensions are different.\r\nThe different parts that make up the reversible 1st part of the fingerprint\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 3 of 10\n\nThe extensions that are hashed to make the 2nd part of the fingerprint\r\nAfter receiving each TLS server hello message, JARM closes the connection gracefully with a FIN as to not leave\r\nthe sockets open.\r\nJARM examples:\r\nIt is important to note that JARM is a high-performance fingerprint function and should not be considered, or\r\nconfused with, a secure crypto function. We designed the JARM fingerprint to be human consumable as much as\r\nmachine consumable. This means it is small enough to eyeball, share, and tweet with enough room for contextual\r\ndetails.\r\nHow JARM Can Be Used to Identify Malicious Servers\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 4 of 10\n\nThis reference to the 1980 arcade game Missile Command really has nothing to do with anything,\r\nhonestly.\r\nMalware command and control (C2) and malicious servers are configured by their creators like any other server\r\nand then deployed across their fleet. These therefore tend to produce unique JARM fingerprints. For example,\r\nwhen scanning Trickbot Malware C2s from a list compiled by abuse.ch, 80% of the live IPs on the list produced\r\nthe same JARM fingerprint. When comparing this JARM fingerprint against the Alexa Top 1 Million websites,\r\nthere was no overlap.\r\nContinuing to test JARM against common malware and offensive tools found the following:\r\nWith little to no overlap of the Alexa Top 1M Websites, it should be extremely unlikely for a host within an\r\norganization to connect to a server with these JARM fingerprints. We wanted to dive further, so our friends\r\nat SecurityTrails scanned the entire Internet, billions of IPs, over port 443 with JARM and found the following:\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 5 of 10\n\nWhen taking a closer look at Cobalt Strike, a common offensive security tool used by red teams and threat actors\r\nalike, we found obvious indicators that most of the results were indeed Cobalt Strike, with server names including\r\nthings like “redteam.server” “cobaltstrike” “totslegit,” as well as some of them having the default Cobalt Strike\r\nmanagement port of 50050 open with the same JARM fingerprint. We believe that this scan found most, if not\r\nall, Cobalt Strike C2’s listening on the Internet on port 443 at the time of scan.\r\nWe did, however, find false positives in the list. It’s inevitable that in the sea of billions of IPs that some legitimate\r\nservers somewhere just happen to be configured in exactly the same way as Cobalt Strike. In the list we identified\r\nthat the JARM also matches Burp Collaborator, another security tool used by red teams and threat actors alike, as\r\nwell as miscellaneous legitimate servers, and a point of sale system. (Point of sale systems listening on the\r\nInternet is a subject for another blog post…) So while we believe JARM identified most, if not all, Cobalt Strike\r\nC2s listening on the Internet, we also had some legitimate servers caught in the net. This is like using a large\r\nmagnet to pull all needles out of a haystack but getting some pieces of hay with them.\r\nIn order to use this as a potential blocklist, we need to filter out the false positives. One easy way to differentiate\r\nlikely legitimate results with malicious ones is just by looking at the server’s history. Malicious C2s are generally\r\nephemeral; they’re coming and going quite frequently, while legitimate servers tend to stay the same for long\r\nperiods of time. This is where vendors with Internet historical data really come in handy. If the server matching\r\nthe Cobalt Strike JARM has had its attributes unchanged for over a year, it’s more likely a legitimate false\r\npositive, while a server matching the Cobalt Strike JARM that didn’t exist 2 months ago is much more likely to be\r\na malicious true positive. Combine that with other server attributes like name, hosting provider, certificate\r\nauthority, etc. and we have ourselves a high quality Proactive Blocklist.\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 6 of 10\n\nProactive Blocklists\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 7 of 10\n\nEmergency Meeting\r\nHistorically, the cybersecurity industry has been focused on reactive blocklists of atomic indicators of compromise\r\n(IOCs). That is, the industry waits until a malware campaign is observed in the wild, analyzes it, then takes the\r\nobserved IOCs and publishes them for blocklists. The problem is that, by the time the IOCs are published, the\r\nmalware has already been distributed and security engineers are automatically on the defensive, playing damage\r\ncontrol.\r\nJARM Internet scanning, coupled with other metadata and historical analysis, allows for the possibility of\r\nproactive IOC identification for new campaigns using existing malware. For example, a cybersecurity researcher\r\nor company could scan the Internet with JARM, correlate known JARM results with the domain and IP history\r\nand reputation along with certificate details to build a high fidelity blocklist. This allows the cybersecurity\r\nindustry to move towards the possibility of programmatically building out high fidelity blocklists before the first\r\npiece of malware is even distributed, placing threat actors on the defensive for the first time in a long time.\r\nDeployment into Detection and Response\r\nOne could utilize JARM for detection and response by automatically scanning all destination hosts observed on\r\ntheir network for event enrichment, utilizing a summary table so as to not scan the same hosts multiple times in a\r\ngiven timeframe. They could then run queries of known-bad against the JARM list or utilize the list for correlation\r\nin response scenarios.\r\nTo simplify the process, one could utilize a security vendor, like SecurityTrails or Shodan, and query their API for\r\ndestination JARM enrichment. Security researchers and vendors are likely to be better suited to maintain historical\r\nanalysis of TLS servers and can therefore provide greater levels of metadata to utilize in measuring a host’s risk\r\nscore.\r\nThere is also a lot of potential for security researchers and vendors to utilize JARM with correlation and historical\r\nanalysis to identify and track malicious servers. This data could then be used to build high fidelity proactive\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 8 of 10\n\nblocklists for easy consumption. But please note that extra care should be put into these blocklists to ensure\r\nminimal false positives.\r\nHow JARM Can Be Used For Configuration Validation and Application Identification\r\nA fleet of application servers that are all running the same TLS configuration should have the same JARM\r\nfingerprint. One could regularly scan the fleet with JARM to confirm that they are the same. If a server in the fleet\r\nproduces a different JARM fingerprint than the rest, then it is not running the same configuration. One major\r\nfinancial institution is already planning to use this capability to identify servers that are not running their latest\r\nTLS standard.\r\nFor example, if we use JARM to scan all Tor nodes maintained by [username] we find the following:\r\nThis shows that of the 100 Tor nodes the user maintains, 100 of them have the same JARM fingerprint. We\r\nessentially just ran a configuration drift check on this user’s Tor node deployment and found that they indeed have\r\na well-maintained fleet. However, if one host had a different JARM than the others, then it would mean it’s not\r\nrunning the same configuration and may warrant investigation. To simulate this, I’ll throw a random IP into the list\r\nand run it again:\r\nJARM fingerprints appear to also be unique to default configurations and patch levels for certain servers and\r\nappliances. Because of this, it may be possible to associate a JARM fingerprint with a specific version of Apache,\r\nfor example. There has yet to be exhaustive research put into this, but here are some preliminary findings:\r\nThere are certainly a lot of research possibilities with JARM that have yet to be explored so I encourage you to\r\ndive in and share what you find!\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 9 of 10\n\nJARM has been open sourced and is available here: https://github.com/salesforce/jarm\r\nJARM was created by:\r\nJohn Althouse\r\nAndrew Smart\r\nRJ Nunnally\r\nMike Brady\r\nWith special thanks to Caleb Yu for re-writing JARM in Python for operational use.\r\nIf you have any questions or feedback on JARM, please reach out to me (John Althouse) via LinkedIn or on\r\nTwitter @4A4133.\r\nSource: https://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nhttps://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a" ], "report_names": [ "easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434433, "ts_updated_at": 1775826724, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0ce540c2d1bd86cd34a82fe8bde1d282e4d51957.pdf", "text": "https://archive.orkl.eu/0ce540c2d1bd86cd34a82fe8bde1d282e4d51957.txt", "img": "https://archive.orkl.eu/0ce540c2d1bd86cd34a82fe8bde1d282e4d51957.jpg" } }