> ## Content Index > Fetch the complete content index at: https://yokai.hakaisecurity.io/llms.txt > Use this file to discover other available public pages before exploring further. # [PT-BR] Understanding Client Fingerprinting: Bot Detection Evasion Using Fingerprint Multilayer Spoofing - URL: https://yokai.hakaisecurity.io/understanding-client-fingerprinting-bot-detection-evasion-using-fingerprint-multilayer-spoofing/ - Published: 2026-02-04T11:59:45.000Z - Updated: 2026-09-08T16:36:24.000Z - Author: pedro cruz - Tags: Research Blog, #wp, pt-br, #pair-fingerprint-spoofing Seu script de automação ou ferramenta de *pentest* funciona perfeitamente no laboratório. As requisições fluem, os dados retornam. Mas no momento em que você toca o alvo real, o WAF (*Web Application Firewall*) corta o sinal. Você rotaciona o IP, elimina *cookies*, compra *proxies* residenciais caros, e ainda assim... “**403 Forbidden”** ou **Captchas demorados**. Por que isso acontece? A resposta curta é: **Identidade**. Os *WAFs* modernos pararam de olhar apenas para "quem" você é (seu endereço IP) e começaram a analisar "o que" você é. Eles examinam a impressão digital (*fingerprint*) intrínseca do seu cliente. Neste artigo, vamos dissecar a evolução do *Client Fingerprinting*, desmistificar o onipresente padrão JA4+ e revelar como construímos a **RedProxy**, uma engine automatizada que combina rotação de IP com *spoofing* *multiprotocols* para evadir as defesas mais sofisticadas. --- ## O Fim dos Indicadores Estáticos A era de bloquear ataques baseando-se apenas em reputação de IP ou assinaturas estáticas de `User-Agent` acabou. Hoje, o bloqueio é comportamental e ocorre em nível de protocolo. Quando um cliente (seja um navegador Chrome ou um *script* Python `requests`) inicia uma conexão, ele negocia dezenas de parâmetros. Se o seu *script* diz "Sou o Google Chrome v120" no *header* HTTP, mas o aperto de mão (*handshake*) TLS grita "Sou uma biblioteca OpenSSL padrão", o *WAF* detecta a incongruência imediatamente. --- ## A Anatomia do Fingerprint: A Era do JA4+ Durante anos, o **JA3** (criado em 2017) foi o padrão da indústria. Ele gerava um hash MD5 baseando-se na versão TLS, cifras e extensões. Porém, com a evolução da *web*, o JA3 tornou-se limitado e propenso a colisões de *hash*, onde clientes diferentes geravam a mesma assinatura. O jogo mudou radicalmente com a chegada do **JA4+**. Diferente do seu antecessor, o JA4+ não olha apenas para o TLS; ele é um conjunto de métodos que faz o *fingerprint* de **diversos protocolos** simultaneamente. Mesmo focando apenas no componente TLS, o JA4 é tecnicamente superior ao JA3: ele foi desenhado para ser mais "humano-legível" e preciso, **reduzindo drasticamente os falsos positivos** e aumentando a eficácia na distinção entre tráfego legítimo e malicioso. Essa robustez o tornou o padrão *de facto* em soluções como Cloudflare, Akamai e AWS WAF. Para um *bypass* efetivo, é preciso controlar quatro vetores principais: ### 1\. JA4 (TLS Fingerprint) ![](https://hakaisecurity.io/wp-content/uploads/2026/02/image.png) [https://foxio.io/ja4](https://foxio.io/ja4?ref=yokai.hakaisecurity.io) O JA4 analisa o protocolo de transporte (TCP ou QUIC), a versão do TLS, a presença de SNI, a contagem e ordem de *Ciphers*, Extensões e o ALPN. Mas como o WAF enxerga isso antes de descriptografar o tráfego? **O segredo está no "Client Hello".** Toda a análise de *fingerprint* ocorre na fase embrionária da conexão. Quando seu cliente inicia o *handshake* TLS, ele envia um pacote inicial chamado **Client Hello**. O detalhe crítico é que este pacote é transmitido em **texto claro (cleartext)**, sem criptografia. É aqui que o *WAF* atua: ele intercepta esse pacote "na porta de entrada" e lê os metadados da sua ferramenta (quais cifras ela suporta, quais extensões ela pede e em qual ordem) antes mesmo de qualquer dado real ser trocado. Isso se aplica inclusive ao **QUIC (HTTP/3)**. Embora o QUIC utilize **UDP** para transporte (ao invés de TCP) e prometa maior privacidade, a negociação dos parâmetros de criptografia ainda precisa ocorrer. O JA4 é capaz de extrair os mesmos metadados desse *handshake* inicial no fluxo UDP. Ou seja, mudar o protocolo de transporte não esconde sua identidade; se o **Client Hello** tiver a "assinatura" de um *script*, o *WAF* o identificará. - **O cenário real:** O Chrome gera uma assinatura legítima como `t13d1517h2_8daaf6152771_b0da82dd1658`. Ferramentas de ataque padrão ou *proxies* (como o Burp Suite) geram assinaturas distintas (`t13d361300_c014a34ff1af_588fa7aed259`). Como o **Client Hello** expõe isso abertamente, essas ferramentas são sinalizadas e bloqueadas instantaneamente, independentemente da reputação do seu IP. Apesar de amplamente utilizado, esse mecanismo pode ser evadido por meio do uso de ferramentas capazes de realizar a personificação (*impersonation*) de navegadores modernos reais, reproduzindo com fidelidade o pacote Client Hello do TLS: - [https://github.com/lexiforest/curl\_cffi](https://github.com/lexiforest/curl%5Fcffi?ref=yokai.hakaisecurity.io) - [https://github.com/sleeyax/burp-awesome-tls](https://github.com/sleeyax/burp-awesome-tls?ref=yokai.hakaisecurity.io) ### 2\. JA4H (HTTP Fingerprint) ![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/02/image-1.png) [https://foxio.io/ja4](https://foxio.io/ja4?ref=yokai.hakaisecurity.io) Enquanto o JA4 cuida da conexão criptografada, o JA4H disseca a requisição HTTP pura (após a descriptografia no WAF). Ele não é um *hash* único, mas composto: o **JA4H\_ab** analisa métodos e *headers* vitais (a simples ausência de um `Accept-Language` é um sinal claro de que não há um humano do outro lado), enquanto o **JA4H\_c** valida se a estrutura dos *cookies* corresponde ao esperado pela aplicação. *Frameworks* populares como o Cobalt Strike, se utilizados com perfis padrão (*default profiles*), **geram impressões digitais JA4H estáticas e conhecidas**. *WAFs* modernos mantêm *blacklists* dessas assinaturas; assim, no momento em que a "gramática" da sua requisição HTTP coincide com o padrão de uma ferramenta de ataque — mesmo que o *payload* esteja ofuscado, o bloqueio é acionado imediatamente. ### 3\. JA4T (TCP Fingerprint) ![](https://hakaisecurity.io/wp-content/uploads/2026/02/image-2.png) [https://blog.foxio.io/ja4t-tcp-fingerprinting](https://blog.foxio.io/ja4t-tcp-fingerprinting?ref=yokai.hakaisecurity.io) Descendo para a camada de transporte, o tamanho da janela TCP (*Window Size*) e as opções TCP (MSS, Window Scale) revelam o Sistema Operacional subjacente. Se você simula um Chrome no Windows, mas seu pacote TCP tem características do kernel Linux (onde seu *script* está rodando), o JA4T expõe a incongruência. ### 4\. JA4X (X.509 Certificate Fingerprint) ![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/02/image-3.png) [https://foxio.io/ja4](https://foxio.io/ja4?ref=yokai.hakaisecurity.io) O JA4X analisa os certificados trocados. Em ataques que envolvem interceptação ou *Man-in-the-Middle*, a natureza do certificado apresentado pode ser o vetor de detecção. > Nota: Embora o JA4+ seja o padrão dominante, vale lembrar que existem outras técnicas proprietárias e algoritmos de *fingerprinting* baseados em entropia e análise estatística de pacotes. --- ## JavaScript e o Navegador Hostil Atualmente, o mecanismo mais utilizado e eficaz por *WAFs* é a **execução de desafios em *JavaScript* no lado do cliente (*client-side*)**, com o objetivo de validar a integridade do ambiente de execução. *Bots* imaturos **falham aqui** por deixarem rastros: - **Vazamento do WebDriver:** Propriedades como `window.navigator.webdriver = true` são as mais clássicas, frequentemente verificadas. - **Viewport:** Browsers *headless* usam resoluções padrão ou incomuns, facilmente detectáveis via `window` e `screen`. - **Hardware Gráfico (WebGL):** Servidores *headless* geralmente reportam renderizadores de software (ex: "Google SwiftShader"). Um usuário legítimo teria uma GPU real ("Intel Iris", "NVIDIA"). - **Canvas Fingerprinting:** Trata-se de uma técnica avançada de identificação em que um *script* desenha uma imagem invisível em um elemento `*canvas*` e, em seguida, lê os valores dos *pixels* gerados. Pequenas variações na renderização de fontes, no *antialiasing* (suavização de bordas), no *subpixel rendering* e até na GPU fazem com que o resultado seja ligeiramente diferente entre sistemas. Essas diferenças são especialmente evidentes ao comparar um sistema operacional real com ambientes automatizados, permitindo detectar sinais de automação. --- ## A Solução: Arquitetura RedProxy Para vencer essas defesas em profundidade, não basta uma ferramenta; é necessária uma arquitetura. Desenvolvemos o **RedProxy**, uma fusão de técnicas de evasão de defesas em ambientes *web*. A *stack* utiliza uma combinação modificada de [**Thermoptic**](https://github.com/mandatoryprogrammer/thermoptic?ref=yokai.hakaisecurity.io) (para *spoofing* TLS) e a lógica de rotação do [**Git-Rotate**](https://github.com/dunderhay/git-rotate/tree/main?ref=yokai.hakaisecurity.io), rodando sobre a infraestrutura efêmera do GitHub Actions. ### Os Três Pilares da Evasão: ### 1\. Sincronia Total de Fingerprint Utilizamos o [**Thermoptic**](https://github.com/mandatoryprogrammer/thermoptic?ref=yokai.hakaisecurity.io) como *proxy upstream*. Ao operar via *Chrome DevTools Protocol* (CDP), ele simula uma instância real do Chromium para processar requisições de qualquer cliente HTTP. Isso garante que o *fingerprint* JA4+ seja indistinguível de um usuário legítimo, "*spoofando*" toda a pilha de conexão através de um navegador real. ### 2\. Infraestrutura Descartável (IP Rotation) Ao invés de *proxies* comerciais (que muitas vezes já estão em *blocklists*), utilizamos a técnica de "Sprayer" via **GitHub Actions**. - Cada execução do workflow sobe um container Ubuntu em um IP do GitHub Actions. - Isso gera IPs diferentes a cada execução. ### 3\. Runtime Patching e Evasão JS O *script* de inicialização do [RedProxy](https://github.com/g4nkd/redproxy?ref=yokai.hakaisecurity.io) aplica *patches* nas *flags* do *Chrome DevTools Protocol* (CDP): - **Remoção de Flags de Automação:** Injetamos a *flag* `-disable-blink-features=AutomationControlled` para remover o sinalizador do WebDriver. - **Normalização de Janela:** Forçamos `-window-size=1920,1080` para evitar a detecção via *viewport* típico de *bots* *headless*. Embora funcional, a eficácia da ferramenta em todos os cenários exige um processo contínuo de *patching*. O foco deve residir na customização granular e na aplicação de *patches* diretamente no protocolo CDP e *hooks* JavaScript, eliminando rastros de automação e garantindo que a telemetria do navegador mimetize, o comportamento de um usuário orgânico. ### O Fluxo de Ataque A arquitetura final opera no seguinte modelo: ![](https://hakaisecurity.io/wp-content/uploads/2026/02/image-4.png) [RedProxy repository](https://github.com/g4nkd/redproxy?ref=yokai.hakaisecurity.io) Para o WAF do alvo, o tráfego não se parece com um ataque de força bruta vindo de um servidor único, com uma ferramenta conhecida (como o “Python requests”); parece tráfego legítimo de dezenas de usuários corporativos usando Chrome. ### Execução Ao iniciar um *kicker* com uma lista de e-mails inexistentes para teste, é possível acompanhar toda a execução do *workflow* na aba **Actions** do repositório configurado no GitHub. ![](https://hakaisecurity.io/wp-content/uploads/2026/02/image-5.png) Execução do [kicker](http://kicker.py/?ref=yokai.hakaisecurity.io) ![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/02/image-6.png) Execução do workflow no GitHub Durante a execução, o servidor **catcher** recebe as requisições enviadas pelo *workflow* e, com base na configuração do **sprayer** para *password spray* da Microsoft, indica se as credenciais testadas são válidas ou inválidas. ![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/02/image-7.png) Catcher recebendo requisições