Understanding Client Fingerprinting: Bot Detection Evasion Using Fingerprint Multilayer Spoofing
Escrito por Pedro Cruz
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.
