[EN] Understanding Client Fingerprinting: Bot Detection Evasion Using Fingerprint Multilayer Spoofing

Escrito por Pedro Cruz

Your automation script or pentest tool works perfectly in the lab. Requests flow, data returns. But the moment you hit the real target, the WAF (Web Application Firewall) drops the connection. You rotate the IP, delete cookies, buy expensive residential proxies, and still…“403 Forbidden” or time-consuming Captchas.

Why does this happen? The short answer is: Identity.

Modern WAFs have stopped looking only at “who” you are (your IP address) and started analyzing “what” you are. They examine your client’s intrinsic fingerprint.

In this article, we’ll dissect the evolution of Client Fingerprinting, demystify the ubiquitous JA4+ standard, and reveal how we built RedProxy, an automated engine that combines IP rotation with multi-protocol spoofing to evade the most sophisticated defenses.

The End of Static Indicators

The era of blocking attacks based solely on IP reputation or static User-Agent signatures is over. Today, blocking is behavioral and occurs at the protocol level.

When a client (whether a Chrome browser or a Python requests script ) initiates a connection, it negotiates dozens of parameters. If your script says “I am Google Chrome v120” in the HTTP header, but the TLS handshake screams “I am a standard OpenSSL library,” the WAF detects the inconsistency immediately.

The Anatomy of Fingerprinting: The JA4+ Era

For years, JA3 (created in 2017) was the industry standard. It generated an MD5 hash based on the TLS version, ciphers, and extensions. However, as the web evolved, JA3 became limited and prone to hash collisions, where different clients generated the same signature.

The game changed radically with the arrival of JA4+. Unlike its predecessor, JA4+ does not just look at TLS; it is a set of methods that fingerprints multiple protocols simultaneously. Even focusing only on the TLS component, JA4 is technically superior to JA3: it was designed to be more “human-readable” and accurate, drastically reducing false positives and increasing effectiveness in distinguishing between legitimate and malicious traffic. This robustness has made it the de facto standard in solutions such as Cloudflare, Akamai, and AWS WAF.

For an effective bypass, four main vectors must be controlled:

1. JA4 (TLS Fingerprint)

JA4 analyzes the transport protocol (TCP or QUIC), the TLS version, the presence of SNI, the count and order of Ciphers, Extensions, and ALPN.

But how does the WAF see this before decrypting the traffic? The secret lies in the “Client Hello.”

All fingerprint analysis occurs in the embryonic phase of the connection. When your client initiates the TLS handshake, it sends an initial packet called Client Hello. The critical detail is that this packet is transmitted in cleartext, without encryption. This is where the WAF comes in: it intercepts this packet “at the gateway” and reads the metadata of your tool (which ciphers it supports, which extensions it requests, and in what order) before any actual data is exchanged.

This even applies to QUIC (HTTP/3). Although QUIC uses UDP for transport (instead of TCP) and promises greater privacy, the negotiation of encryption parameters still needs to take place. JA4 is able to extract the same metadata from this initial handshake in the UDP stream. In other words, changing the transport protocol does not hide your identity; if the Client Hello has the “signature” of a script, the WAF will identify it.

The real scenario: Chrome generates a legitimate signature such as t13d1517h2_8daaf6152771_b0da82dd1658. Standard attack tools or proxies (such as Burp Suite) generate distinct signatures (t13d361300_c014a34ff1af_588fa7aed259). Since the Client Hello openly exposes this, these tools are instantly flagged and blocked, regardless of your IP’s reputation.

Although widely used, this mechanism can be evaded through the use of tools capable of impersonating real modern browsers, faithfully reproducing the TLS Client Hello packet:

2. JA4H (HTTP Fingerprint)

While JA4 takes care of the encrypted connection, JA4H dissects the pure HTTP request (after decryption in the WAF). It is not a single hash, but a composite one: JA4H_ab analyzes vital methods and headers (the simple absence of an Accept-Language is a clear sign that there is no human on the other side), while JA4H_c validates whether the cookie structure matches what the application expects.

Popular frameworks such as Cobalt Strike, when used with default profiles, generate static and known JA4H fingerprints. Modern WAFs maintain blacklists of these signatures; thus, when the “grammar” of your HTTP request matches the pattern of an attack tool—even if the payload is obfuscated—the block is triggered immediately.

3. JA4T (TCP Fingerprint)

https://blog.foxio.io/ja4t-tcp-fingerprinting

Moving down to the transport layer, the TCP window size and TCP options (MSS, Window Scale) reveal the underlying operating system.

If you spoof Chrome on Windows, but your TCP packet has characteristics of the Linux kernel (where your script is running), JA4T exposes the inconsistency.

4. JA4X (X.509 Certificate Fingerprint)

JA4X analyzes the certificates exchanged. In attacks involving interception or Man-in-the-Middle, the nature of the certificate presented can be the detection vector.

Note: Although JA4+ is the dominant standard, it is worth remembering that there are other proprietary techniques and fingerprinting algorithms based on entropy and statistical packet analysis.

JavaScript and the Hostile Browser

Currently, the most widely used and effective mechanism by WAFs is the execution of JavaScript challenges on the client side, with the aim of validating the integrity of the execution environment.

Immature bots fail here because they leave traces:

WebDriver Leak: Properties such as window.navigator.webdriver = true are the most classic and frequently checked.
Viewport: Headless browsers use standard or unusual resolutions, easily detectable via window and screen.
Graphics Hardware (WebGL): Headless servers usually report software renderers (e.g., “Google SwiftShader”). A legitimate user would have a real GPU (“Intel Iris,” “NVIDIA”).
Canvas Fingerprinting: This is an advanced identification technique in which a script draws an invisible image on a *canvas* element and then reads the values of the generated pixels. Small variations in font rendering, antialiasing (edge smoothing), sub pixel rendering, and even the GPU cause the result to be slightly different between systems. These differences are especially evident when comparing a real operating system with automated environments, allowing signs of automation to be detected.

The Solution: RedProxy Architecture

To overcome these deep defenses, a tool is not enough; an architecture is needed. We developed RedProxy, a fusion of defense evasion techniques in web environments.

The stack uses a modified combination of Thermoptic (for TLS spoofing ) and Git-Rotate rotation logic, running on the ephemeral infrastructure of GitHub Actions.

The Three Pillars of Evasion:

1. Total Fingerprint Synchronization

We use Thermoptic as an upstream proxy. Operating via the Chrome DevTools Protocol (CDP), it simulates a real Chromium instance to process requests from any HTTP client. This ensures that the JA4+ fingerprint is indistinguishable from a legitimate user, “spoofing” the entire connection stack through a real browser.

2. Disposable Infrastructure (IP Rotation)

Instead of commercial proxies (which are often already on blocklists), we use the “Sprayer” technique via GitHub Actions.

Each workflow execution launches an Ubuntu container on a GitHub Actions IP.
This generates different IPs with each execution.

3. Runtime Patching and JS Evasion

The RedProxy startup script applies patches to the Chrome DevTools Protocol (CDP) flags:

Removal of Automation Flags: We inject the -disable-blink-features=AutomationControlled flag to remove the WebDriver flag.
Window Normalization: We force -window-size=1920,1080 to avoid detection via the typical viewport of headless bots.

Although functional, the tool’s effectiveness in all scenarios requires a continuous patching process. The focus should be on granular customization and applying patches directly to the CDP protocol and JavaScript hooks, eliminating traces of automation and ensuring that browser telemetry mimics the behavior of an organic user.

The Attack Flow

The final architecture operates on the following model:

To the target’s WAF, the traffic does not look like a brute-force attack coming from a single server with a known tool (such as “Python requests”); it looks like legitimate traffic from dozens of corporate users using Chrome.

Execution

When starting a kicker with a list of non-existent emails for testing, it is possible to follow the entire workflow execution in the Actions tab of the repository configured in GitHub.

Kicker execution

During execution, the catcher server receives the requests sent by the workflow and, based on the Microsoft password spray sprayer configuration, indicates whether the tested credentials are valid or invalid.