What Is Cisco Mercury Fingerprinting?

Back to learning

Cisco Mercury is open-source software for capturing and analysing network metadata. It can read packets from an interface or a PCAP, recognise supported protocols, and write JSON records. Those records can include a fingerprint made from selected parts of a protocol message.

That short description hides an important boundary: Mercury is the collector and analysis software; Network Protocol Fingerprinting (NPF) is the format used to represent fingerprints. A fingerprint can be produced without asking Mercury to identify the process behind it.

Cisco's Mercury repository contains a C++ application and library, plus a portable Python implementation called pmercury. Cisco says the software is used in some production applications, but still asks users to consider it beta. That is a status statement about the software, not a claim that every fingerprint or classification it emits has the same confidence.

What does Mercury observe?

Mercury reads packet metadata rather than decrypting application payloads. For TLS, for example, it can inspect a ClientHello and select fields such as its legacy protocol-version field, cipher suites, and extensions. It then normalises those fields according to a named NPF rule and serialises them as a fingerprint.

The draft NPF specification defines formats for TLS, DTLS, QUIC, TCP/IP, HTTP/1.x, OpenVPN, STUN, and SSH. Mercury can parse additional protocols, but parser support and a documented NPF format are not the same thing. Protocol coverage also changes as the repository evolves, so deployments should pin and record the Mercury revision they use.

For the representation itself, see inside a Mercury NPF fingerprint.

Four parts that should not be confused

1. Collector: Mercury reads live traffic or a PCAP and extracts metadata.
2. Representation: NPF defines which protocol features are selected, how they are normalised, and how the resulting tree is written.
3. Knowledge base: labelled observations associate fingerprints and context with processes seen in a particular dataset.
4. Classifier: optional analysis uses that knowledge base and destination context to estimate which process produced a flow.

Only the first two are needed to generate a fingerprint. Mercury's command-line --analysis option adds the fourth step and reports its result separately from the fingerprint in the JSON output. This is a useful design choice: an observation remains distinct from an inference.

What can a Mercury fingerprint tell you?

It can describe a protocol implementation closely enough to group similar observations, compare captures, or look up prior labels. It cannot, by itself, prove which application, device, person, or intent produced the traffic. A shared TLS library can appear in many applications. One application can also produce several fingerprints after an update, configuration change, or change of network path.

Capture position matters too. A fingerprint observed before a TLS-terminating proxy describes the client-facing handshake. One observed behind that proxy may describe the proxy's own connection. Packet loss or truncation can leave too little of a message for an exact full match.

These limits are normal for TLS fingerprinting. They are why fingerprints work best as retained, reviewable evidence rather than identity. Mercury's destination-context research addresses part of the attribution problem, but it does so by adding a classifier, not by changing a fingerprint into proof. See destination context and TLS attribution for that distinction.

For a use-case comparison with portable TLS identifiers, see Mercury vs JA4 vs JA3.

For the project and product history, From Joy to Mercury and EVE traces the public code, published classifier research and Cisco firewall capability without treating them as interchangeable systems.