Infrastructure pivoting is the OSINT practice of taking one known-bad host and using its technical fingerprints to discover the rest of an adversary’s servers before they are used against you. The three pivots that do most of the work in 2026 are favicon hashes, JARM TLS fingerprints, and certificate transparency logs. Each turns a single indicator into a search query, and together they convert one IP address into a cluster. This is a hands-on walkthrough of how the three fit together, and how to avoid the false positives that wreck a pivot.
What is infrastructure pivoting?
Pivoting starts from the observation that attackers reuse things. The same panel, the same TLS stack, the same self-signed certificate, the same favicon copied from a phishing kit. Defenders see one indicator (an IP in a proxy log, a domain in an alert) and want the other ninety they have not seen yet. Pivoting is the disciplined jump from that one indicator to related hosts using a shared, queryable artifact. Done well, it sits alongside the broader infrastructure-tracking methodology we use for ransomware leak sites, and it complements attack-surface mapping, which points the same engines at your own estate.
Pivot one: favicon hashes
A favicon is the little icon a site serves at /favicon.ico. Operators copy them wholesale from phishing kits, admin panels, and command-and-control frameworks, and they rarely bother to change them. Shodan computes a MurmurHash3 of the base64-encoded favicon and exposes it as a searchable field. That makes the icon a fingerprint.
The workflow is simple. Pull the favicon from a known host, compute the hash, then search for every other host serving the identical icon:
// Shodan dork
http.favicon.hash:-1234567890
// compute it yourself (python, mmh3)
import mmh3, requests, codecs
fav = requests.get("https://target/favicon.ico").content
print(mmh3.hash(codecs.encode(fav, "base64")))
Censys and FOFA expose the same concept under their own field names (FOFA uses icon_hash). The favicon pivot is fast and cheap, but it is also noisy: a default framework favicon will return thousands of benign installs. Treat a favicon match as a candidate, not a conclusion, and confirm it with a second signal.
Pivot two: JARM and JA3S TLS fingerprints
JARM is an active TLS server fingerprint developed by Salesforce. The scanner sends a server ten deliberately varied TLS Client Hello packets and hashes how the server responds. Two servers running the same software, configured the same way, return the same JARM. That is what makes it useful for clustering: a malicious framework with an unusual or default TLS stack stands out from the general population.
The classic example is the default Cobalt Strike team server, whose JARM has been catalogued for years. Hunting that fingerprint on Shodan or Censys surfaces candidate C2 servers in bulk. The catch is the same as favicon: JARM alone is too coarse, because many legitimate servers share a TLS stack. The discipline is to use JARM as a filter, then narrow with HTTP response headers, page titles, certificate fields, or body hashes. JA3S, the server-side response fingerprint, is a useful companion signal when you have packet captures rather than just scan data.
Pivot three: certificate transparency and TLS cert fields
Every publicly trusted TLS certificate is logged to certificate transparency (CT), and those logs are searchable at crt.sh and through Censys. CT is a gift for OSINT because it leaks subdomains and naming conventions before the infrastructure is fully live. Search an organisation or a known phishing domain and you frequently find sibling hostnames the operator registered in the same batch.
Self-signed and reused certificates are even stronger pivots. Attackers who stand up many servers often reuse a certificate’s common name, serial, or SHA-256 fingerprint across the fleet. Pivot on that certificate hash in Censys or Shodan and the cluster falls out. A distinctive common name (the kind a careless operator leaves on a default install) can be the single best pivot you get all day.
Putting it together: a worked pivot chain
The method is always the same shape. Start with one indicator. Fingerprint it three ways. Run each fingerprint through the scan engines. Then, and this is the step amateurs skip, require at least two independent signals to agree before you call a host part of the cluster. A favicon match plus a matching certificate is a finding. A favicon match alone is a lead.
Avoiding false positives and staying clean
Two failure modes ruin pivots. The first is over-trusting a single noisy signal and pulling in thousands of innocent servers, which is how analysts end up reporting a hosting provider’s entire range as malicious. Layer your indicators. The second is contaminating the investigation by touching live infrastructure from an attributable address. Pull your data from passive scan engines (Shodan, Censys, FOFA, Netlas, ZoomEye) and CT logs rather than connecting directly, and if you must interact, do it from segregated infrastructure. Our OPSEC guide for OSINT investigators covers the discipline in depth.
The 2026 tooling at a glance
| Pivot | Where to query | Field or method |
|---|---|---|
| Favicon hash | Shodan, FOFA, Censys | http.favicon.hash, icon_hash (MurmurHash3) |
| TLS server fingerprint | Shodan, Censys | JARM, JA3S |
| Certificate / subdomains | crt.sh, Censys | CT logs, cert SHA-256, common name |
| HTTP body / title | Shodan, Netlas, ZoomEye | response hash, page title, headers |
For analysts who want to turn these pivots into repeatable graphs, our Maltego workflows for ransomware research show how to wire the same signals into transforms.
What this means for investigators
Infrastructure pivoting is the difference between reacting to indicators and pre-empting them. The favicon, JARM, and certificate pivots are not new, but in 2026 they are productised across half a dozen scan engines, which means a defender with a single bad IP and an afternoon can map an operator’s fleet before it finishes deploying. The skill is not running the dorks. It is the discipline of cross-confirmation that keeps your cluster honest. Build the habit, document every pivot, and treat single-signal matches as leads, not facts. More tradecraft on the OSINT desk.
FAQ
What is infrastructure pivoting in OSINT?
It is the practice of taking one known malicious host and using shared technical fingerprints, such as favicon hashes, TLS fingerprints, and certificates, to discover related adversary infrastructure. One indicator becomes a search query that surfaces the rest of the cluster.
How does a favicon hash help find C2 servers?
Operators frequently reuse the same favicon across phishing kits and C2 panels. Search engines like Shodan compute a hash of that icon, so searching the hash returns every host serving the identical favicon. It is a fast lead that needs a second signal to confirm.
Is JARM enough to identify malicious infrastructure?
No. JARM clusters servers by TLS configuration, but many legitimate servers share a stack, so JARM alone is noisy. Use it as a filter and confirm with HTTP headers, certificates, or body hashes before attributing a host.
What is certificate transparency useful for?
Certificate transparency logs record publicly trusted certificates, which leaks subdomains and naming conventions, sometimes before infrastructure goes live. Reused or self-signed certificates also let you pivot on a certificate fingerprint across an operator’s fleet.
Which tools do I need?
Shodan, Censys, FOFA, Netlas, and ZoomEye for scan data, and crt.sh for certificate transparency. Most pivots can be run from the free or low-cost tiers of these services.
How do I avoid false positives?
Require at least two independent signals to agree before adding a host to a cluster, and avoid attributing entire hosting ranges from a single noisy match such as a default favicon or common JARM.
Sources and further reading
- JARM TLS fingerprinting: Salesforce Engineering.
- Favicon-hash and TLS pivoting techniques: Netlas, Kraven Security, and the CTI Wiki.
- Certificate transparency: crt.sh and Censys documentation.
- Related on Ransomnews: Attack-surface mapping with Shodan, Censys, FOFA, Nuclei, Tracking ransomware infrastructure, OPSEC for OSINT investigators.
