{"id":114,"date":"2026-01-13T00:00:00","date_gmt":"2026-01-12T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/pt\/cloaking-avancado-wordpress-malware-googlebot-validacao-ip-asn-cidr\/"},"modified":"2026-01-20T06:32:52","modified_gmt":"2026-01-20T05:32:52","slug":"cloaking-avancado-wordpress-malware-googlebot-validacao-ip-asn-cidr","status":"publish","type":"post","link":"https:\/\/helloblog.io\/pt\/cloaking-avancado-wordpress-malware-googlebot-validacao-ip-asn-cidr\/","title":{"rendered":"Cloaking avan\u00e7ado em WordPress: malware que s\u00f3 \u201cmostra a cara\u201d ao Googlebot com valida\u00e7\u00e3o por IP (ASN\/CIDR)"},"content":{"rendered":"\n

Nos incidentes de seguran\u00e7a em WordPress, h\u00e1 um padr\u00e3o que se repete: quando a infe\u00e7\u00e3o \u00e9 \u201cbarulhenta\u201d (popups, redirecionamentos, scripts estranhos), algu\u00e9m acaba por notar rapidamente. O problema \u00e9 que os atacantes est\u00e3o a apostar cada vez mais no oposto: malware seletivo, que entrega a carga maliciosa apenas a quem interessa \u2014 tipicamente crawlers de motores de busca \u2014 e mant\u00e9m o site aparentemente normal para visitantes humanos e para o pr\u00f3prio dono.<\/p>\n\n\n\n

Um caso recente analisado pela Sucuri mostrou exatamente isso: uma modifica\u00e7\u00e3o no index.php<\/code> do WordPress que atua como um gatekeeper (porteiro) e decide, request a request, se vai carregar o WordPress \u201climpo\u201d ou se vai injetar conte\u00fado remoto especificamente para o Googlebot, com verifica\u00e7\u00e3o forte baseada em IP.<\/p>\n\n\n\n

\"Diagrama
Exemplo de cloaking com l\u00f3gica condicional baseada em IP. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

O que foi encontrado: inje\u00e7\u00e3o seletiva no index.php<\/h2>\n\n\n\n

Durante a investiga\u00e7\u00e3o, o ponto de entrada principal estava no index.php<\/code> (ficheiro raiz t\u00edpico de instala\u00e7\u00f5es WordPress). Em vez de fazer o fluxo normal \u2014 bootstrap do WordPress e render do tema \u2014 o ficheiro foi adulterado para avaliar a \u201cidentidade\u201d do visitante.<\/p>\n\n\n\n

Na pr\u00e1tica, o index.php<\/code> comprometido tinha dois caminhos:<\/p>\n\n\n\n

    \n\n
  • Se o visitante aparentar ser infraestrutura do Google (n\u00e3o s\u00f3 pelo User-Agent, mas tamb\u00e9m pelo IP), o script busca um payload remoto e imprime esse conte\u00fado na resposta.<\/li>\n\n\n
  • Para utilizadores normais, o site continua a servir a vers\u00e3o leg\u00edtima, reduzindo drasticamente a probabilidade de dete\u00e7\u00e3o manual.<\/li>\n\n<\/ul>\n\n\n\n
    \"Captura
    O site parecia normal para visitantes, mas o Google via conte\u00fado injetado. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

    O \u201ctwist\u201d t\u00e9cnico: n\u00e3o \u00e9 s\u00f3 User-Agent \u2014 \u00e9 ASN + CIDR + bitwise (com IPv6)<\/h2>\n\n\n\n

    Cloaking via HTTP_USER_AGENT<\/code> (a string que o browser\/crawler envia em cada pedido) \u00e9 uma t\u00e9cnica antiga. O que chama a aten\u00e7\u00e3o aqui \u00e9 o n\u00edvel de rigor: o malware n\u00e3o confiava apenas em \u201ccont\u00e9m Googlebot\u201d. Ele carregava uma lista grande (hardcoded) de ranges de IP associados ao Google, identificados via ASN (Autonomous System Number) e expressos em CIDR.<\/p>\n\n\n\n

    ASN do Google: o que significa na pr\u00e1tica<\/h3>\n\n\n\n

    Um ASN (Autonomous System Number) funciona como uma \u201cidentidade\u201d de rede na Internet: agrupa blocos de IP sob controlo de uma organiza\u00e7\u00e3o. Ao validar que o IP de origem pertence a ranges associados ao ASN do Google, o atacante reduz falsos positivos e evita que algu\u00e9m a testar manualmente (ou um scanner simples) consiga ver o conte\u00fado escondido apenas falsificando o User-Agent.<\/p>\n\n\n\n

    CIDR: a forma compacta de representar ranges de IP<\/h3>\n\n\n\n

    CIDR (Classless Inter-Domain Routing) \u00e9 uma nota\u00e7\u00e3o para descrever blocos de endere\u00e7os IP sem listar IP a IP. Por exemplo, 192.168.1.0\/24<\/code> cobre 192.168.1.0<\/code> at\u00e9 192.168.1.255<\/code>, sendo que o \/24<\/code> define o tamanho do bloco.<\/p>\n\n\n\n

    \"Exemplo
    Representa\u00e7\u00e3o de ranges em CIDR. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

    Valida\u00e7\u00e3o com opera\u00e7\u00f5es bitwise e suporte IPv6<\/h3>\n\n\n\n

    Em vez de fazer compara\u00e7\u00f5es por strings ou listas fr\u00e1geis, o script fazia valida\u00e7\u00e3o matem\u00e1tica para confirmar se um IP \u201ccai\u201d dentro de um bloco CIDR \u2014 e ainda tinha suporte expl\u00edcito para IPv6, que muitos scripts de cloaking mais antigos ignoram.<\/p>\n\n\n\n

    A l\u00f3gica central para IPv4 descrita na an\u00e1lise usa uma opera\u00e7\u00e3o bitwise AND com a netmask do bloco para comparar o IP do visitante com o range:<\/p>\n\n\n\n

    <\/circle><\/circle><\/circle><\/g><\/svg><\/span>