From Joy to Mercury and EVE: Following Cisco's Network Fingerprinting Work

2026-08-02T09:00:00+10:00

Cisco's network fingerprinting work is often compressed into a neat product story: Joy became Mercury, and Mercury became the Encrypted Visibility Engine. There is a real lineage here, but that sentence hides more than it explains.

Joy and Mercury are public software projects. Network Protocol Fingerprinting is a representation. The 2020 destination-context paper describes a classification system and the data needed to support it. EVE is a Cisco Secure Firewall capability backed by Cisco's operational data and machine-learning systems.

Those pieces share ideas, authors and engineering history. They are not four names for the same thing.

Joy started with flow records, then looked inside them

Cisco released Joy as a BSD-licensed tool for collecting network flow and intraflow data from live traffic or PCAP files. Its basic unit was recognisable to anyone who had worked with NetFlow or IPFIX: a flow with addresses, ports and counters. Joy then added observations from within that flow.

Those observations included packet lengths and arrival times, byte distributions, TLS record sequences, visible TLS handshake fields, DNS data and selected HTTP fields. It wrote the results as JSON so researchers could feed them into analysis tools without building a packet parser first.

That breadth matters. Joy was not originally just a ClientHello hash generator. It was a network-research instrument for asking what could still be learned from traffic when the application payload was encrypted.

The research around Joy shows how Cisco used it. The 2016 paper Deciphering Malware's Use of TLS (without Decryption) combined conventional flow measurements, packet-length and timing sequences, byte distributions and visible TLS handshake features. Its authors were interested in malware detection and family attribution, but they were also explicit about dataset bias. A sandbox operating system or its default TLS library could become an accidental shortcut for the classifier.

In 2017, OS Fingerprinting: New Techniques and a Study of Information Gain and Obfuscation used an extended Joy collector to record features from TCP SYN packets, TLS ClientHello messages and HTTP requests. The study combined evidence across protocols and sessions rather than expecting one handshake to provide a definitive operating-system label.

The enduring idea was broader than any one model: retain useful network observations, join them to trustworthy labels where possible, and test what the combined evidence can support.

Mercury narrowed and hardened the collection path

The Joy repository now directs readers to Mercury for Cisco's more recent fingerprinting tools and data. Mercury carries forward the packet-metadata and JSON-output model, but it is a separate implementation with a stronger focus on fast capture, protocol fingerprints and online analysis.

The public repository contains a C++ application and library, along with the portable Python implementation pmercury. Mercury can read PCAPs or live traffic, identify supported protocols and emit selected metadata. On Linux, its native collector uses the kernel's AF_PACKET TPACKETv3 path and multiple workers. The repository describes use in some production applications, while still asking users to treat the open software as beta.

Mercury also makes a useful boundary visible in its JSON:

packet
  -> protocol metadata
  -> fingerprint object
  -> optional destination-context analysis
  -> analysis object

The fingerprint is an observation. The analysis is an inference made from that observation and other data. They should not be collapsed into one label.

NPF is the representation, not the classifier

Mercury's fingerprints use Cisco's Network Protocol Fingerprinting format. NPF selects characteristic fields from an initial protocol message, normalises values that should not distinguish implementations, and writes the retained structure as a tree of hexadecimal byte strings.

A full TLS fingerprint can therefore be inspected. Its tls/2 prefix identifies the protocol and rule version; parentheses and brackets preserve the selected tree structure and sorting decisions. Mercury can also use a compact hash nickname when fixed-length storage is more useful than inspection.

The draft NPF specification covers more than TLS. It documents rules for protocols including QUIC, TCP, HTTP, SSH, STUN and OpenVPN. This is one point at which the Joy heritage remains visible: the project treats protocol evidence as a network-wide problem, not solely as a way to name TLS clients.

Our guide to Cisco Mercury fingerprinting separates the collector, NPF representation, knowledge base and classifier in more detail. Inside a Mercury NPF fingerprint works through the full notation.

The 2020 paper made the attribution problem explicit

A fingerprint is useful for grouping similar protocol implementations. It is often a poor application name.

Blake Anderson and David McGrew quantified that problem in Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases. TLS libraries are shared. Common fingerprints can map to tens or hundreds of processes. A dictionary that assigns one process name to one fingerprint will therefore produce convincing-looking false positives.

The paper added three destination features to the TLS fingerprint: destination address, destination port and the TLS server name, when present. A weighted naive Bayes classifier used those features and prevalence counts from a labelled knowledge base to rank candidate processes.

The knowledge base was the difficult part. The researchers joined network observations to endpoint process data, generated fresh knowledge bases daily and merged them into an operational view. They also used malware-sandbox observations. The paper describes billions of connections, a changing population of fingerprints and destinations, and the need to discard stale data.

Its reported results were strong, including a process-family F1 score above 0.99 and high precision and recall for the malware task. Those figures belong to the paper's datasets and evaluation. They are not an accuracy guarantee for a Mercury installation downloaded from GitHub.

The authors also documented important limits: their endpoint data was dominated by desktop Windows and macOS systems, mobile and IoT coverage was absent, and most data came from one enterprise. They wrote that a site could build a custom knowledge base if it had suitable endpoint ground truth and network monitoring, but acknowledged the significant initial investment.

That is the operational lesson. A classifier is not made current by having a good fingerprint format. It stays current through labelled collection, joining, curation, expiry and evaluation.

For a closer reading, see how destination context changes TLS attribution.

EVE puts the research into a firewall product

Cisco describes its Encrypted Visibility Engine as work based on that earlier destination-context research. EVE first appeared in Secure Firewall 7.1 as a disabled-by-default experimental beta for visibility only; it did not enforce actions and Cisco warned that it could produce false positives. The 7.2 release notes say EVE began working with QUIC and allowed high-confidence process assignments to feed application policy. Version 7.3 specifically added HTTP/3 and SMB-over-QUIC detection, along with indication-of-compromise events for unsafe applications.

In Cisco's account of how EVE detects malicious use of trustworthy cloud services, the runtime inputs have the same recognisable shape:

an NPF representing client-side protocol characteristics; and
server context such as address, port and domain name.

EVE uses machine learning over Cisco's labelled data to estimate the client process and detect suspicious encrypted traffic without decrypting its payload. Cisco says its training data is refreshed daily with network samples joined to endpoint ground truth, with additional malicious observations from Cisco Secure Malware Analytics.

This is the clearest public link from NPF and the 2020 paper to the commercial system. It is also where careful wording matters most.

The public Mercury repository is not a source release of the complete EVE service. Building Mercury does not provide Cisco's continuously collected production dataset, its current models, Secure Firewall integration, Talos context or product policy behaviour. Conversely, the fact that EVE uses NPF does not mean every detail of its current implementation is present in the open repository or frozen at the method described in the 2020 paper.

Open code, published research and a maintained security product have different release cycles and different evidence behind them.

What the lineage actually establishes

There is a coherent progression:

Joy
  broad flow and intraflow metadata for research

Mercury + NPF
  faster collection and versioned, multi-protocol fingerprints

2020 destination-context system
  fingerprints joined to destinations and endpoint labels

EVE
  Cisco-maintained classification in Secure Firewall

This is a lineage of ideas and systems, not a promise that each box is a drop-in edition of the next one.

Joy established a practical way to collect visible evidence around encrypted flows. Mercury made protocol fingerprinting a more explicit and efficient part of that collection. NPF gave those fingerprints a structured, versioned form. The destination-context work showed why labelled, continuously refreshed context was necessary for process attribution. EVE operationalised those ideas inside a commercial firewall environment with data and integrations that do not ship with the public collector.

That history also explains why Cisco's branch of fingerprinting developed differently from JA3 and JA4. A portable hash is useful for logging and exchange. Cisco's work kept returning to a harder question: what additional evidence, labels and maintenance are required before a network observation can support a process assessment?

Neither approach turns a handshake into identity. Our two lineages of TLS fingerprinting article places Cisco's work alongside JA3 and JA4. The reproducible one ClientHello, three fingerprints lab shows the format differences without relying on any vendor classification database.