![[PT-BR] Understanding Client Fingerprinting: Bot Detection Evasion Using Fingerprint Multilayer Spoofing](/content/images/size/w2000/hakaisecurity-io/wp-content/uploads/2026/02/artigo-pedro26.jpg)
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)
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:
2. JA4H (HTTP Fingerprint)
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)
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)
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 = truesão as mais clássicas, frequentemente verificadas. - Viewport: Browsers headless usam resoluções padrão ou incomuns, facilmente detectáveis via
windowescreen. - 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 (para spoofing TLS) e a lógica de rotação do Git-Rotate, rodando sobre a infraestrutura efêmera do GitHub Actions.
Os Três Pilares da Evasão:
1. Sincronia Total de Fingerprint
Utilizamos o Thermoptic 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 aplica patches nas flags do Chrome DevTools Protocol (CDP):
- Remoção de Flags de Automação: Injetamos a flag
-disable-blink-features=AutomationControlledpara remover o sinalizador do WebDriver. - Normalização de Janela: Forçamos
-window-size=1920,1080para 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:
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.
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.
