--- title: "Cloaking avançado em WordPress: malware que só “mostra a cara” ao Googlebot com validação por IP (ASN/CIDR)" url: "https://helloblog.io/pt/cloaking-avancado-wordpress-malware-googlebot-validacao-ip-asn-cidr/" date: "2026-01-13" modified: "2026-01-20" author: "Inês Silva" language: "pt_PT" categories: ["Segurança"] tags: ["Googlebot", "Malware", "SEO", "WAF", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/9/2026/01/featured-3-1024x572.jpg" excerpt: "Nem todo o spam de SEO vem com redirecionamentos óbvios. Há campanhas que injetam conteúdo apenas para crawlers do Google — e validam o IP com lógica em CIDR e operações bitwise para passarem despercebidas." --- # 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. ![Diagrama de lógica condicional com verificação de IP para servir conteúdo diferente ao Googlebot](https://helloblog.io/app/uploads/sites/9/2026/01/IP-Verified-Conditional-Logic.png) *Exemplo de cloaking com lógica condicional baseada em IP. — *Forrás: Sucuri Blog** ## 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. ![Captura de ecrã a mostrar conteúdo diferente indexado pelo Google em comparação com o site normal](https://helloblog.io/app/uploads/sites/9/2026/01/What-Google-sees.png) *O site parecia normal para visitantes, mas o Google via conteúdo injetado. — *Forrás: Sucuri Blog** ## 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. ![Exemplo ilustrado de um range em CIDR e a explicação do prefixo](https://helloblog.io/app/uploads/sites/9/2026/01/CIDR-format.png) *Representação de ranges em CIDR. — *Forrás: Sucuri Blog** ### 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); ``` ![Diagrama a explicar a validação de IP por operações bitwise para corresponder a blocos CIDR](https://helloblog.io/app/uploads/sites/9/2026/01/Bitwise-IP-Range-Validation.png) *Validação de IP por bitwise para garantir match exato com a rede. — *Forrás: Sucuri Blog** ## 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). #### Indicador observado na campanha Na análise, o domínio malicioso usado para servir o payload remoto foi `amp-samaresmanor[.]pages[.]dev` (apresentado como hxxps na documentação para evitar cliques acidentais). ## 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. ![Fluxo de verificação de identidade combinando User-Agent e validação de IP](https://helloblog.io/app/uploads/sites/9/2026/01/Multi-Layer-Identity-Verification.png) *O script valida primeiro o User-Agent e depois confirma o IP por rede. — *Forrás: Sucuri Blog** ### 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. ![Trecho ilustrativo de filtragem de User-Agent com vários identificadores relacionados ao Google](https://helloblog.io/app/uploads/sites/9/2026/01/User-Agent-Filtering.png) *Filtragem de User-Agent com múltiplos identificadores do Google. — *Forrás: Sucuri Blog** ### 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 ``` ![Diagrama mostrando o malware a buscar conteúdo remoto via cURL e a imprimir na página](https://helloblog.io/app/uploads/sites/9/2026/01/Remote-Payload-Execution-via-cURL.png) *O payload é carregado remotamente e devolvido ao crawler. — *Forrás: Sucuri Blog** ### 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. ![Fluxograma com decisões: bot legítimo, bot falso e utilizador normal, com redirecionamentos e logging](https://helloblog.io/app/uploads/sites/9/2026/01/Conditional-Logic-and-Error-Logging.png) *Motor de decisão do malware: valida, serve payload, redireciona e regista eventos. — *Forrás: Sucuri Blog** ## 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. #### Controlo que faz diferença neste tipo de caso File Integrity Monitoring (monitorização de integridade de ficheiros) ajuda a detetar alterações não autorizadas em ficheiros core como `index.php`, onde este tipo de campanha costuma viver sem chamar atenção. ## 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. ## Referências / Fontes - [Malware Intercepts Googlebot via IP-Verified Conditional Logic](https://blog.sucuri.net/2026/01/malware-intercepts-googlebot-via-ip-verified-conditional-logic.html) - [Google Sees Spam, You See Your Site: A Cloaked SEO Spam Attack](https://blog.sucuri.net/2026/01/google-sees-spam-you-see-your-site-a-cloaked-seo-spam-attack.html) - [VirusTotal URL report (amp-samaresmanor.pages.dev)](https://www.virustotal.com/gui/url/5a006beedf563c6215a31746d011d13fd4f2561a1bf3b557484c4532b13e1ec6?nocache=1) - [publicwww results for amp-samaresmanor.pages](https://publicwww.com/websites/amp-samaresmanor.pages/) - [Web Application Firewall](https://sucuri.net/website-firewall/) - [File Integrity Monitoring / malware detection scanning](https://sucuri.net/malware-detection-scanning/)