Cloaking avançado em WordPress: malware que só “mostra a cara” ao Googlebot com validação por IP (ASN/CIDR)

Nos incidentes de segurança em WordPress, há um padrão que se repete: quando a infeção é “barulhenta” (popups, redirecionamentos, scripts estranhos), alguém acaba por notar rapidamente. O problema é que os atacantes estão a apostar cada vez mais no oposto: malware seletivo, que entrega a carga maliciosa apenas a quem interessa — tipicamente crawlers de motores de busca — e mantém o site aparentemente normal para visitantes humanos e para o próprio dono.

Um caso recente analisado pela Sucuri mostrou exatamente isso: uma modificação no index.php do WordPress que atua como um gatekeeper (porteiro) e decide, request a request, se vai carregar o WordPress “limpo” ou se vai injetar conteúdo remoto especificamente para o Googlebot, com verificação forte baseada em IP.

O que foi encontrado: injeção seletiva no index.php

Durante a investigação, o ponto de entrada principal estava no index.php (ficheiro raiz típico de instalações WordPress). Em vez de fazer o fluxo normal — bootstrap do WordPress e render do tema — o ficheiro foi adulterado para avaliar a “identidade” do visitante.

Na prática, o index.php comprometido tinha dois caminhos:

• Se o visitante aparentar ser infraestrutura do Google (não só pelo User-Agent, mas também pelo IP), o script busca um payload remoto e imprime esse conteúdo na resposta.
• Para utilizadores normais, o site continua a servir a versão legítima, reduzindo drasticamente a probabilidade de deteção manual.

O “twist” técnico: não é só User-Agent — é ASN + CIDR + bitwise (com IPv6)

Cloaking via HTTP_USER_AGENT (a string que o browser/crawler envia em cada pedido) é uma técnica antiga. O que chama a atenção aqui é o nível de rigor: o malware não confiava apenas em “contém Googlebot”. Ele carregava uma lista grande (hardcoded) de ranges de IP associados ao Google, identificados via ASN (Autonomous System Number) e expressos em CIDR.

ASN do Google: o que significa na prática

Um ASN (Autonomous System Number) funciona como uma “identidade” de rede na Internet: agrupa blocos de IP sob controlo de uma organização. Ao validar que o IP de origem pertence a ranges associados ao ASN do Google, o atacante reduz falsos positivos e evita que alguém a testar manualmente (ou um scanner simples) consiga ver o conteúdo escondido apenas falsificando o User-Agent.

CIDR: a forma compacta de representar ranges de IP

CIDR (Classless Inter-Domain Routing) é uma notação para descrever blocos de endereços IP sem listar IP a IP. Por exemplo, 192.168.1.0/24 cobre 192.168.1.0 até 192.168.1.255, sendo que o /24 define o tamanho do bloco.

Validação com operações bitwise e suporte IPv6

Em vez de fazer comparações por strings ou listas frágeis, o script fazia validação matemática para confirmar se um IP “cai” dentro de um bloco CIDR — e ainda tinha suporte explícito para IPv6, que muitos scripts de cloaking mais antigos ignoram.

A lógica central para IPv4 descrita na análise usa uma operação bitwise AND com a netmask do bloco para comparar o IP do visitante com o range:

// Conceito ilustrativo do match por rede (IPv4)
// Se (IP & netmask) == (range & netmask) então o IP pertence ao bloco.
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Conceito ilustrativo do match por rede (IPv4)
// Se (IP & netmask) == (range & netmask) então o IP pertence ao bloco.
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Porque isto é perigoso: impacto direto em SEO e reputação

Este tipo de infeção é menos sobre roubo direto (ex.: skimmers) e mais sobre abuso de confiança do motor de busca. O site passa a servir conteúdos que não existem para humanos, e o Google pode indexar páginas/payloads que o proprietário nunca publicou.

• Blacklisting e queda de reputação do domínio.
• Deindexação ou perda significativa de rankings por spam/cloaking.
• “Resource hijacking”: o teu domínio vira veículo para conteúdo remoto de terceiros.
• Deteção tardia, porque a navegação normal não revela o problema.

Sinais práticos de alerta (especialmente para equipas técnicas)

Se estiveres a investigar um WordPress que “parece normal”, mas há suspeitas de SEO spam/cloaking, estes sinais tendem a aparecer mais cedo ou mais tarde:

• Resultados estranhos no Google (títulos/snippets que não correspondem ao site).
• Ficheiros core ou de entrada recentemente alterados (especialmente index.php).
• URLs suspeitos em código, logs ou histórico de deploy.
• Logs inesperados (incluindo mensagens de erro criadas pelo próprio malware para medir sucesso/falhas).

Como o malware decide o que servir: a cadeia de decisão

O comportamento descrito segue uma sequência em camadas, desenhada para minimizar exposição e maximizar indexação:

1) Verificação em múltiplas camadas (User-Agent + IP real)

Primeiro, o script inspeciona o HTTP_USER_AGENT. Como isto é fácil de falsificar, entra a segunda camada: validação do IP contra ranges do Google (ASN em CIDR) com bitwise.

2) Filtragem abrangente de User-Agents do ecossistema Google

Outro detalhe interessante: não é um filtro inocente por “Googlebot”. O malware inclui vários identificadores associados a ferramentas de verificação/inspeção e crawlers de APIs do Google, para aumentar as hipóteses de o conteúdo malicioso ser visto e confirmado por diferentes serviços.

3) Execução de payload remoto via cURL (injeção na resposta)

Quando o visitante passa nas verificações, o script usa cURL para fazer fetch de conteúdo remoto e imprime diretamente na resposta do site. Para o crawler, aquilo parece conteúdo “nativo” do domínio.

// Comportamento descrito na análise:
// após validar bot + IP, faz fetch remoto e imprime na resposta
// hxxps://amp-samaresmanor[.]pages[.]dev

// Comportamento descrito na análise:
// após validar bot + IP, faz fetch remoto e imprime na resposta
// hxxps://amp-samaresmanor[.]pages[.]dev

4) Lógica condicional com logging e “failsafes”

O script também inclui tratamento de erro e logging (registo) para monitorizar se o payload remoto está a carregar. Se falhar, em vez de devolver uma página quebrada ao Google, pode redirecionar para /home/ para manter a aparência de normalidade.

E quando alguém tenta fazer spoof do Googlebot (User-Agent falso), mas o IP não bate certo, o malware regista algo do género “Fake GoogleBot detected” e redireciona para a home legítima.

Porque mexer em ficheiros core do WordPress ajuda o atacante

Alterar o index.php dá ao atacante uma vantagem: é um ponto de entrada garantido e executado em praticamente todos os requests na raiz. A análise também descreve como o malware tira proveito de ficheiros do core para manter o site funcional enquanto injeta o comportamento malicioso.

• wp-load.php: ao fazer require_once __DIR__ . '/wp-load.php', o script inicializa (bootstraps) o ambiente WordPress, incluindo acesso à config e base de dados.
• wp-blog-header.php: faz parte do fluxo normal do index.php legítimo, normalmente requerido no final do ficheiro. O atacante pode manter este comportamento para não “partir” o site para utilizadores comuns.

Remediação: o que vale a pena fazer numa limpeza a sério

Como em qualquer caso de malware em WordPress, a limpeza não é só apagar uma linha. O objetivo é remover o payload, fechar o vetor de entrada e reduzir a probabilidade de reinfeção.

• Remover ficheiros/pastas desconhecidos (qualquer coisa que não reconheças tu ou a tua equipa).
• Auditar utilizadores WordPress e remover contas “de apoio”/admins suspeitos.
• Trocar credenciais (admin, FTP/SFTP, hosting/painel, base de dados).
• Verificar o teu próprio computador (scan completo de malware), para evitar reinfeções por credenciais roubadas.
• Atualizar WordPress core, temas e plugins (e remover componentes abandonados).
• Colocar um WAF (Web Application Firewall) para bloquear tráfego malicioso e dificultar uploads/exploits e comunicação com infraestruturas conhecidas.

O takeaway para quem gere WordPress em produção

O aspeto mais desconfortável deste caso é que ele explora um “ponto cego” operacional: o site pode parecer perfeito para humanos, enquanto o motor de busca indexa conteúdo completamente diferente. Ao combinar filtro de User-Agent com validação rigorosa por ASN/CIDR (incluindo IPv6) e bitwise, o atacante eleva a fasquia da deteção manual.

Na prática, além de hardening e updates, vale a pena tratar o index.php (e outros ficheiros core) como superfície crítica: monitorização de alterações, auditoria regular e revisão do que o Google está efetivamente a indexar via Search Console são medidas que reduzem muito o tempo entre infeção e descoberta.