Netsec is Dead(?): Modern Network Fingerprinting for the Darknet

Netsec is Dead(?): Modern Network Fingerprinting for the Darknet

Speaker: Vlad Iliushin

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~8 minutes

TL;DR

Network fingerprinting — characterizing clients, servers, and connections from TCP/IP and TLS handshake data — is a practical, passive, non-noisy technique for detecting mass scanners, identifying threat actors, and enriching detections without touching Wireshark or dumping a pcap. Vlad Iliushin, who helped found Avast's IoT lab and now works in cyber deception at Elio, walked through the current fingerprinting algorithm landscape (JA3, JA3N, JA4, p0f, and MONFP), showed how specific fingerprints identify Zmap, Masscan, and Shodan, and presented concrete detection and blocking strategies any security team can start using today.

Introduction

TCP has been around since 1981's first RFC — longer than many security practitioners have been alive. Across the decades of standards, extensions, and amendments layered onto networking protocols, the idiosyncratic ways that different operating systems and network stacks implement those standards have created a fingerprinting opportunity: the characteristics of a connection can reveal who — or what — is on the other end, without the noise and visibility of active scanning.

Iliushin, whose background spans Samsung Electronics, Avast's IoT security lab, and now cyber deception work with honeypots and honeynets, opened by making the case for passive fingerprinting specifically: it requires no new connections, introduces no traffic, and can be deployed across an enterprise network without disrupting anything. "You can go back home into your company, into your enterprise network, and start fingerprinting all the things without introducing any noise or changing your network stack."

Fingerprinting Taxonomy: Four Ways to Classify

▶ Watch: Fingerprinting taxonomy and algorithm overview (04:00)

Iliushin organized the fingerprinting landscape along two axes:

Active vs. passive: Active fingerprinting creates new connections and inspects replies (Nmap's OS detection being the canonical example). Passive fingerprinting observes existing traffic without introducing new packets. This talk focused exclusively on passive fingerprinting.

Start-of-connection vs. continuous: Start-of-connection fingerprints are taken from handshakes (TCP SYN, TLS Client Hello) and are highly deterministic and stable. Continuous fingerprinting analyzes flow behavior over the lifetime of a connection. This talk focused on start-of-connection.

OSI layer: TCP/IP fingerprints operate at layers 3–4. TLS and application-layer fingerprints (JA3, JA4) operate at layers 6–7.

The current algorithm landscape:

• p0f / MONFP — TCP/IP fingerprinting
• JA3 / JA3N / JA4 — TLS fingerprinting
• JA4+ — extended suite covering HTTP, SSH, and other protocols (proprietary Fox.io license)

TLS Fingerprinting: JA3, JA3N, and JA4

▶ Watch: JA3 and its limitations, JA3N, and JA4 (09:00)

JA3 was the original TLS fingerprinting algorithm: an MD5 hash of a string composed of the TLS version, cipher suites, extensions, elliptic curves, and elliptic curve point formats extracted from the Client Hello. The hash is compact and easy to match against threat intelligence databases.

The problem Iliushin demonstrated concretely: loading the same website in Chrome three times produced three different JA3 hashes. The root cause is TLS extension shuffling, a feature Google Chrome introduced specifically to defeat fingerprinting by randomizing the order of TLS extensions in each connection. Since JA3 is order-sensitive, any TLS extension shuffle produces a different hash — and attackers can implement their own randomization to evade any JA3-based detection.

Iliushin's practical lesson: always store the raw JA3 string alongside the hash. If extension ordering changes — whether from a browser update or attacker evasion — you can re-sort your historical raw strings and recover continuity. Without the raw string, your entire IOC database becomes stale.

JA3N addresses the Chrome problem by sorting TLS extensions before hashing, making the fingerprint extension-order-independent. This was a targeted fix for the specific Chrome shuffling behavior.

JA4, released by John Alhouse in 2023, is a more comprehensive redesign with three parts:

• A human-readable prefix encoding connection type (T=TLS, Q=QUIC, D=DTLS), TLS version (e.g., "13" for TLS 1.3), SNI type (D=domain, I=IP), cipher count, extension count, and first ALPN value (e.g., h2 for HTTP/2).
• A truncated SHA-256 hash of sorted cipher suites.
• A truncated SHA-256 hash of sorted extensions and signature algorithms.

JA4 also exposes a raw value (the JA4r) composed of human-readable components plus the sorted cipher suites, extensions, and signature algorithms — enabling retrospective analysis of what ciphers and extensions are most common across a fleet of clients.

The human-readable prefix is immediately actionable: seeing t13dXXX vs. t13iXXX lets an analyst instantly distinguish domain-based connections from IP-based connections, which can indicate clients that are not legitimate browser users.

Iliushin showed two known-malicious JA4/JA3 hash pairs linked to Cobalt Strike C2 communication, Trickbot, and Windows HTTPS Meterpreter traffic — demonstrating direct threat detection value.

TCP/IP Fingerprinting: p0f and MONFP

▶ Watch: p0f and MONFP TCP fingerprinting (22:00)

p0f (passive OS fingerprinting, where the "0" is stylized as zero) was created by Michał Zalewski in 2000. Its signature format captures IP version, TTL (actual and estimated original), IP option length, Maximum Segment Size (MSS), window size, window scale, TCP options in order, and payload size class. During a TCP 3-way handshake, payload should be zero — a nonzero payload in the SYN packet is a red flag.

p0f was historically oriented toward identifying operating systems from their TCP behavior, but that use case has eroded as HTTP headers, cookies, and other application-layer signals have become more reliable OS indicators. Despite this, Cloudflare deployed a BPF-compiled version of p0f in 2016 to drop traffic from devices with anomalous TCP signatures, using it as part of their anti-DDoS protection — demonstrating that the fingerprints retain operational value even if OS attribution is less reliable.

MONFP, created by Ken Webster in 2024, is a leaner, more modern TCP fingerprint with only four values: window size, TCP options as kind numbers, MSS, and window scale — all human-readable. Iliushin demonstrated its precision with live examples:

• A signature without TCP option 8 (timestamp) and with a window size that is a multiple of MSS → Windows 10
• Window size 65535 with TCP option 8 present → Ubuntu Linux
• Same Linux machine connecting through Verizon's mobile network → slightly smaller MSS (Verizon adds ~72 bytes of overhead)
• Windows machine through OpenVPN → overhead of 61 bytes visible in the MSS reduction
• Same machine through WireGuard → 80 bytes of overhead; through IKEv2 → 100 bytes

These VPN overhead signatures mean that MONFP can distinguish clients connecting through different VPN protocols — useful for detecting unauthorized VPN usage or for identifying when an attacker's infrastructure is using a specific tunnel type.

A critical insight from the TCP fingerprinting examples: when fingerprinting at the server side, a connection through a proxy reveals the proxy's fingerprint, not the client's. Practitioners must always track where in the network path they are fingerprinting.

Identifying Scanners and Attackers in the Wild

▶ Watch: Scanner fingerprints and the reconnaissance kill chain (30:00)

Iliushin walked through the fingerprints of the internet's most prominent mass scanners. Both Zmap and Masscan generate highly distinctive MONFP signatures because they implement custom TCP stack routines optimized for speed rather than compliance — this results in very few TCP options, since these tools have no expectation of completing a full TCP session from a port scan SYN.

Shodan is more sophisticated: it splits port scanning (stage one) and service enumeration (stage two) across different IP addresses, with different fingerprints for each stage — the fast-scan fingerprint and the service-discovery fingerprint can both be recognized. Shodan also randomizes window sizes in its scanning stack, which produces a distinctive spread of roughly 38,000 to 60,000 unique fingerprints across its scanning IPs.

The recon kill chain implication is direct: attackers who cannot afford or do not want to run their own scanning infrastructure use public scanners like Shodan and Censys as free attack surface management tools. Any internet-facing server that does not block Shodan and Censys is exposing its attack surface to anyone willing to query those platforms.

Iliushin proposed a combined blocking strategy: IP-based blocking for known scanner ranges (Censys publishes its IP ranges; blocking is straightforward) combined with fingerprint-based blocking for fast-scanning patterns (blocking based on the TCP/TLS fingerprint rather than the IP address, so that benign traffic from the same IP ranges is unaffected).

Detection examples included a Sigma rule for identifying fast-scanner signatures and an ELK rule for "zero first-packet detection" — automatically pushing a detected scanning IP to router block lists across the entire infrastructure so that when the scanner pivots to a new network range, it is already blocked.

Notable Quotes

"Fingerprints are just another tool in your arsenal — and it is up to you to extract the most value. You can start detecting things, you can write detections, you can use them for IOCs, you can use them for blocking. The security of your network perimeter is in your hands." — Vlad Iliushin (42:00)

"If you have a public IP address, I can guarantee you that you receive connections with those two fingerprints every hour of every day." — Vlad Iliushin, on Zmap and Masscan (31:00)

"Always store the raw JA3 string. If a small new shuffle changes all the values of your fingerprints, without those raw strings you are kind of out of luck." — Vlad Iliushin (13:00)

Key Takeaways

• Passive fingerprinting is non-noisy and deployable today on any enterprise network without changing network topology or introducing new traffic. Tools like MONFP (Rust standalone binary) and Zeek/ntop plugins for JA4 can be deployed immediately.
• JA3 is vulnerable to TLS extension shuffling. Always retain raw JA3 strings alongside hashes; migrate toward JA3N or JA4 for new deployments.
• JA4's human-readable prefix provides immediate triage value — distinguishing domain-based from IP-based TLS connections, counting supported ciphers and extensions, and identifying ALPN protocols at a glance.
• Zmap, Masscan, and Shodan all produce recognizable TCP/TLS fingerprints. Adding fingerprint-based blocking rules for these tools is a low-cost, high-coverage defensive measure.
• Combine IP blocking and fingerprint blocking — block known scanner IP ranges by address, and block fast-scanning behavior by fingerprint. Fingerprint-based blocking avoids collateral damage to benign traffic sharing an IP range.