SecurityScorecard’s STRIKE Threat Intelligence Team built GFMX, a new fingerprinting technique for X.509 certificates. It links certificates by the software that generated them, even when every name, key, and hash differs.
Attackers regenerate certificates in seconds, but rarely the software that makes them. SecurityScorecard’s GFMX technique fingerprints that software on any X.509 certificate. Our STRIKE Threat Intelligence Team built the technique with post-quantum calibration in mind. The new fingerprinting method will soon be available on SecurityScorecard’s Driftnet engine.

Introducing GFMX: A New Way to Fingerprint Certificates
GFMX is a new technique for fingerprinting X.509 certificates, the digital ID cards websites and software use to prove who they are. Attackers can generate new certificates in seconds, but they usually build them with the same software. SecurityScorecard created GFMX to fingerprint that software, so it can link certificates even when each one looks brand new.
A command-and-control (C2) framework generates a fresh certificate for every listener. A malware builder signs each sample with a new key. As a result, a hash matches only one server or one sample, never the rest of the family. The template, meaning the fixed pattern of choices a piece of software repeats every time it generates a certificate, stays the same. GFMX fingerprints that template instead. This allows defenders to better identify malicious threat actor infrastructure.
Tested on nearly one million certificates, GFMX identifies issuers, devices, and even Android malware families by the tools that created their certificates. It is also built for the post-quantum era. The fingerprint accounts for certificates built with the post-quantum encryption protocols that are just now starting to be implemented. GFMX will be available on Driftnet, and it will be shared with the community on our GitHub page for non-commercial use.
JA4X, part of FoxIO’s JA4+ suite, showed that how a certificate was generated is worth fingerprinting. GFMX takes its own approach, independent of where a certificate was found. Thanks to that, the same value works across internet scans, packet captures, Certificate Transparency (CT) logs, code signatures, Android Package Kits (APKs), and firmware.

Figure 1: Three certificates from one generator. Their names, serials, dates, keys, and hashes all differ, and they all get the same GFMX value.
Ready for Post-Quantum Certificates
Most certificate fingerprints describe a key as “size plus hash,” which only works for RSA and Elliptic Curve Digital Signature Algorithm (ECDSA) cryptographic algorithms. Module-Lattice-Based Digital Signature Algorithm (ML-DSA) has no separate hash, hybrid certificates carry two key pairs, and Merkle Tree (MTC) certificates have no Certificate Authority (CA) signature at all. GFMX describes keys by their algorithm identifiers instead, so a new algorithm shows up as a new value, and the format stays the same.
- ML-DSA and Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) parameter sets get different values, and GFMX checks ML-DSA self-signatures instead of trusting them.
- A hybrid certificate records both of its key pairs, so a classical certificate that also carries a post-quantum key is easy to identify.
- An MTC certificate keeps one value across every log and index it appears in.
- Draft-era Object IDs (OIDs) and the encoding habits of early libraries produce their own values, which points back to the toolchain that built the certificate.

Figure 2: These examples come from the GFMX conformance vectors. The three ML-DSA parameter sets differ only in KEY, an early library’s encoding habit changes only MAKER, and MTC certificates keep one value across logs.
Post-quantum is still rare. Of the nearly one million certificates in the study below, not one used ML-DSA, ML-KEM, or an MTC proof. For the next few years, a post-quantum certificate somewhere unexpected deserves a closer look on its own, and GFMX already records it.

Anatomy of a GFMX Value
A GFMX value has five segments: key, span, maker, audience, and names. Each one answers a question about the certificate and is hashed on its own. Names, serials, keys, and exact dates stay out of the value. Every segment can also be expanded back into the readable text it was built from, so an analyst can see exactly why two certificates match.

Figure 3: A self-signed RSA-2048 certificate made by openssl req -x509. Each segment is the first eight hex characters of a SHA-256 hash over readable text.
Because each segment stands alone, a hunt can match on the segments it trusts and wildcard the rest. KEY:*:MAKER:AUDIENCE:NAMES catches a builder that randomizes validity, and *:*:MAKER:*:* finds the same code path regardless of the certificate’s key or purpose.
Nearly One Million Certificates
We fingerprinted a sample of Driftnet’s internet scan from October 14, 2026: 999,866 distinct certificates served by 1.65 million hosts. It’s the same data GFMX will run on in Driftnet.
As seen in Figure 4, for nearly 1 million unique values, each one of the five segments produced between 156 and 6,323 unique strings, but put together, there are a total of 35,623 unique combinations of those strings. In practice, the segments reinforce one another. Each is only moderately specific alone, but combined they produce a far more precise fingerprint than any one could provide. The fingerprint is more discriminating than any of its individual segments.
| 999,866certificatesone scan day | 100%fingerprintedno certificate failed to parse | 35,623templatesdistinct GFMX values | 0collisionsin any segment |

Figure 4: Distinct values per segment across 999,866 certificates. Each segment splits the population differently, which is why wildcards are useful.
The segments also show how the internet behaves in practice: the validity span, for example, reveals which certificate lifetimes CAs and device makers choose most often. The validity spans alone tell you how CAs and device makers operate.
Figure 5 shows the habits of certificate span policies. For example, 30% of all tested certs (approximately 333,000) came with a 90-day expiration date.

Figure 5: The 10 most common validity spans. You can read CA policy straight off it: 90-day automation, the old 397-day limit, the new 200-day limit, and firmware that runs its certificates to the end of 32-bit time. “cal” marks a calendar-based span, where the expiry was set by calendar units (such as one month or one year, which vary in length) rather than an exact number of seconds.
SecurityScorecard’s Driftnet labels hosts by software, hardware, device class, protocol, and issuing CA. For each label, we looked for the GFMX pattern, full or wildcarded, that best identifies its hosts. For software and hardware labels, we used only certificates the product generated itself.

Figure 6: Median result per label across eight kinds of label. Precision is the share of hosts a GFMX pattern matches that actually carry the label; it measures how often a match is correct. Coverage is the share of the label’s hosts that the pattern catches; it measures how many of them the pattern finds. F1 combines the two into a single score.
Certificate issuers came out best, with a median precision score of 1.00 across 392 CAs. The automated certificate authority Let’s Encrypt, which is on 374,650 hosts, received a precision score of 1.00 with 96% coverage. Appliances were close behind, because a vendor’s default certificate is a template. Freebox, WatchGuard, Sophos, and Supermicro IPMI score an F1 of 0.99 to 1.00, Synology 0.97, and DrayTek Vigor 0.96. Software that generates its own certificate does well too, with Traefik at 0.99, OpenLDAP at 0.98, Kubernetes at 0.96, and Windows RDP at 0.98 across 28,094 hosts.

Figure 7: Every appliance label, placed by the precision and coverage of its best GFMX pattern, with dot size following the number of hosts. The biggest brands sit near the top because a vendor’s default certificate is a template.
GFMX works best when a product creates its own certificates from a fixed template. Where there’s no template, its results get less predictive. A general purpose web server runs whatever certificate its administrator installed, and a network operator has no template of its own. Where GFMX does isolate a group of hosts, it is usually accurate.
From Fingerprint to Label
Search finds what you already know. To see whether GFMX can also name what’s behind a certificate it has never seen, we trained a simple regression model (a multinomial logistic regression on the five segments) on 70% of the certificates and tested it on the other 30%, three times over. Between 2% and 12% of the test hosts carried a GFMX value the model had never seen, and it still answered for every one because the segments themselves were familiar. It named the right issuer for 96% of hosts, the right device class for 89%, and the right appliance for 85% (96% within its top three guesses), versus 19% to 41% for an educated guess always assuming the most common result.

Figure 8: Share of held-out hosts whose label the model named correctly on its first guess, on certificates it never saw in training (70/30 split by certificate, three runs). The baseline always guesses each test’s most common label.
An Anecdote from Android Malware
We also fingerprinted the signing certificates of 9,531 malicious APKs from 87 families. Most of them are signed with keys that several families share, which tells you about the tooling rather than the actor. Where a builder generates a new key for every sample, GFMX found the family when the certificate hash couldn’t. For 12 families, one pattern finds at least 75% of the family’s certificates, and at least 75% of what it finds belongs to that family. All 97 MobileTracker certificates share a template that no other family uses.
The strongest result came from a held-out test. (A held-out test sets aside a portion of your data, untouched by training or the campaign, so you can fairly measure how well a model performs.) We took a Metasploit pattern from a first batch of 30 families and ran it against a second batch of 60 families it had never seen. It matched 150 certificates in the second batch, each with a different key. Every one was Metasploit, and none came from any other family.

Figure 9: The strongest GFMX pattern for the eight best-matched families that have at least nine certificates of their own, counting each certificate once. Precision is the share of the pattern’s certificates that belong to the family, and coverage is the share of the family’s certificates it holds.

Where to Use GFMX
- Infrastructure hunting, going from one C2 or phishing certificate to every server built from the same kit.
- Malware triage, grouping executables, drivers, and APKs by the builder that signed them.
- Exposure inventory, recognizing an appliance or its firmware from its default certificate.
- Post-quantum tracking, seeing where ML-DSA, ML-KEM, and hybrid certificates appear.
A good starting point is the full value of a certificate you’ve already confirmed. Wildcard only the segments that differ between related samples, and run the pattern over benign data before you alert on it.
GFMX Will Soon Be Available on Driftnet
Every certificate in Driftnet’s internet scans will soon carryits GFMX value. You can start from one malicious certificate and pivot to every server built from the same template, using the full value or wildcarding any segment, across the whole scan.
- Find a certificate on a C2, phishing, or exposed host.
- Take its GFMX value.
- Pivot to every host that shares the template.
Open to Everyone and Free for Non-Commercial Use
GFMX will also be released as an independent project under the Sustainable Use License v1.0 . The specification and conformance vectors will be public for non-commercial use. Commercial implementations require a license from SecurityScorecard.
GFMX is patent pending.
- Fingerprint anywhere. A fast Go command-line tool for certificates, signed executables, APKs, CMS/PKCS#7 bundles, live hosts, and binaries, plus a Python library with no dependencies and a C library for plugins.
- In your network tools. Enrichers for Suricata and Zeek, and a tshark PCAP-to-JSON/CSV script. Passive tools see certificates from TLS 1.2 and earlier only, since TLS 1.3 and QUIC encrypt the server certificate. Active scanning and file sources are unaffected.
- In your CTI workflow. A MISP object template for sharing patterns, and a Ghidra script that finds certificates inside samples.
GFMX will soon be available on Driftnet. Start with one malicious certificate and pivot to every server built from the same template across the entire internet scan. Be among the first to try it.
To learn more or inquire about commercial licensing, contact Gilad Friedenriech Maizles, SecurityScorecard’s Manager of Security and Threat Intelligence.
Explore the GitHub repository here.