Close Menu
  • Home
  • News
  • Security
  • Privacy
  • Cybercrime
    • Threat Groups
    • Ransomware
    • Explainers
    • Stealer Logs
  • AI
  • OSINT
  • Tools
    • Ransomtracker
    • Stealercheck
    • FortiBleed Checker
  • Reviews
    • Best antivirus software for 2026: independent picks from Ransomnews
    • Best ransomware-resistant backup for 2026: cloud, hybrid, and immutable picks reviewed
    • Best ransomware protection for business 2026: Alerts.bar, ESET PROTECT and 6 alternatives reviewed
  • About Us
Facebook X (Twitter) Instagram Threads
Ransomnews
  • Home
  • News
  • Security
  • Privacy
  • Cybercrime
    • Threat Groups
    • Ransomware
    • Explainers
    • Stealer Logs
  • AI
  • OSINT
  • Tools
    • Ransomtracker
    • Stealercheck
    • FortiBleed Checker
  • Reviews
    • Best antivirus software for 2026: independent picks from Ransomnews
    • Best ransomware-resistant backup for 2026: cloud, hybrid, and immutable picks reviewed
    • Best ransomware protection for business 2026: Alerts.bar, ESET PROTECT and 6 alternatives reviewed
  • About Us
Facebook X (Twitter) LinkedIn
Ransomnews
OSINT

Hunting C2 infrastructure: favicon, JARM, cert logs

Jesse William McGrawBy Jesse William McGrawJune 24, 2026Updated:June 24, 2026No Comments7 Mins Read160 Views
Share Facebook Twitter Pinterest LinkedIn Tumblr Email Copy Link
Hunting C2 infrastructure synthwave cover, favicon JARM cert logs, ransomnews.com
Share
Facebook Twitter LinkedIn Pinterest Email Copy Link

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

// PIVOT CHAIN · ONE IOC TO A CLUSTER 1 known-bad IP from a log/alert fingerprint it favicon + JARM + cert query the engines Shodan/Censys/FOFA cross-confirm with 2+ signals, drop benign matches result: validated cluster of related adversary hosts

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.
Share. Facebook Twitter Pinterest LinkedIn Tumblr Telegram Email Copy Link
Previous ArticleDeepfake vishing 2026: voice-clone fraud explained
Next Article ESXi ransomware in 2026: one host, the whole datacenter
Jesse William McGraw

Jesse William McGraw, also known as GhostExodus, is a former insider threat and threat actor. He became the first person in recent U.S. history to be convicted of corrupting industrial control systems. Today he focuses on threat intelligence, OSINT, and public speaking, using his knowledge to bring awareness to the security risks that organisations and individuals face.

Related Posts

Ransomware leak-site OSINT: 2026 investigation walkthrough

May 16, 2026

Audit your digital footprint 2026: Sherlock, Holehe, Whoxy

May 10, 2026

Attack-surface mapping 2026: Shodan, Censys, FOFA, Nuclei

May 10, 2026

Comments are closed.

Facebook X (Twitter) LinkedIn
© 2026 Ransomnews.com

Type above and press Enter to search. Press Esc to cancel.

Cookies on Ransomnews

We use strictly-necessary cookies to run the site and may use first-party analytics to understand which articles are read. Some pages contain affiliate links — when you click one, the affiliate network sets cookies on the merchant's domain to attribute the referral. See the Cookie Policy and Affiliate Disclosure for detail.

RANSOMNEWS.COM

Tracking the criminal infrastructure of the internet.

Independent coverage of ransomware, breach economics, threat actors, privacy, AI security, and the open-source investigation toolkit.

// Topics

  • News
  • Security
  • Privacy
  • Cybercrime
  • AI
  • OSINT
  • Reviews
  • Threat Groups
  • Stealer Logs
  • Ransomtracker
  • Stealercheck
  • FortiBleed Checker

// Site

  • About Us
  • Editorial Team
  • Contact
  • Tip Line
  • Editorial

// Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Affiliate Disclosure
  • RSS Feed
© 2026 Ransomnews.com · Tracking the criminal infrastructure of the internet.