{"id":98,"date":"2026-01-13T00:00:00","date_gmt":"2026-01-12T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/it\/wordpress-cloaking-selettivo-googlebot-verifica-ip-asn-cidr\/"},"modified":"2026-01-20T06:32:45","modified_gmt":"2026-01-20T05:32:45","slug":"wordpress-cloaking-selettivo-googlebot-verifica-ip-asn-cidr","status":"publish","type":"post","link":"https:\/\/helloblog.io\/it\/wordpress-cloaking-selettivo-googlebot-verifica-ip-asn-cidr\/","title":{"rendered":"WordPress e cloaking \u201cselettivo\u201d: quando il malware serve contenuti solo a Googlebot verificando l\u2019IP"},"content":{"rendered":"\n

Negli ultimi mesi sta diventando sempre pi\u00f9 comune un approccio silenzioso e selettivo: niente redirect a raffica per tutti, ma contenuti malevoli consegnati solo ai crawler dei motori di ricerca. Il vantaggio per l\u2019attaccante \u00e8 evidente: il proprietario del sito naviga e \u201csembra tutto a posto\u201d, mentre Googlebot riceve una pagina diversa che finisce in SERP (Search Engine Results Pages).<\/p>\n\n\n\n

In un caso analizzato da Sucuri, l\u2019infezione era particolarmente interessante dal punto di vista tecnico perch\u00e9 non si limitava a controllare l\u2019header User-Agent<\/code> (facile da falsificare), ma verificava anche che l\u2019indirizzo IP del visitatore appartenesse realmente ai range di Google, usando una libreria hardcoded di ASN e calcoli bitwise su range CIDR, con supporto anche a IPv6.<\/p>\n\n\n\n

\"Schema
L\u2019idea: mostrare contenuti diversi a seconda dell\u2019identit\u00e0 del visitatore, verificata su pi\u00f9 livelli. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

Che cosa \u00e8 stato compromesso (e perch\u00e9 \u00e8 insidioso)<\/h2>\n\n\n\n

L\u2019iniezione non era in un plugin \u201cstrano\u201d, ma direttamente nel file principale index.php<\/code> di WordPress. In pratica, quel file diventava un gatekeeper: invece di avviare sempre WordPress e rendere il tema, decideva prima chi stava visitando la pagina e, solo in certi casi, caricava contenuti da una sorgente esterna.<\/p>\n\n\n\n

\u00c8 una variante di cloaking SEO: Google \u201cvede\u201d qualcosa che l\u2019utente umano non vede. In questi scenari il danno non \u00e8 solo reputazionale; pu\u00f2 portare a deindicizzazione, blacklisting, e pi\u00f9 in generale a perdita di fiducia del motore di ricerca verso il dominio.<\/p>\n\n\n\n

\"Esempio
Esempio di discrepanza: i visitatori vedono il sito normale, Googlebot riceve contenuti differenti. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

La novit\u00e0: non solo User-Agent, ma verifica IP via ASN + CIDR<\/h2>\n\n\n\n

Molti script di cloaking si appoggiano a una regola fragile: \u201cse User-Agent<\/code> contiene Googlebot allora\u2026\u201d. Qui invece l\u2019attaccante ha aggiunto un secondo fattore: una lista corposa di range IP associati agli ASN (Autonomous System Number) di Google, espressi in formato CIDR. Questo riduce la possibilit\u00e0 di smascherare l\u2019attacco con un semplice spoof del User-Agent<\/code>.<\/p>\n\n\n\n

ASN (Autonomous System Number) in due righe<\/h3>\n\n\n\n

Un ASN \u00e8 l\u2019identit\u00e0 di rete di un\u2019organizzazione su Internet: raggruppa blocchi di IP sotto un\u2019unica \u201cpropriet\u00e0\u201d amministrativa. Nel caso di Google, gli ASN coprono l\u2019infrastruttura usata da servizi come Search, Gmail e Google Cloud. Se una richiesta arriva da un IP dentro quei blocchi, \u00e8 molto pi\u00f9 probabile che sia davvero Google e non un crawler fasullo.<\/p>\n\n\n\n

CIDR: perch\u00e9 viene usato negli attacchi (e nella difesa)<\/h3>\n\n\n\n

Il formato CIDR (Classless Inter-Domain Routing) serve per descrivere intervalli di IP in modo compatto, ad esempio 192.168.1.0\/24<\/code>. Il suffisso \/24<\/code> indica quanti bit della rete sono fissi, definendo la dimensione del blocco. \u00c8 comodo per whitelist\/blacklist e, in questo caso, per fare matching matematico sul range senza elencare singoli IP.<\/p>\n\n\n\n

\"Esempio
Il CIDR consente di definire blocchi di IP in modo compatto. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

Come funziona il malware: anatomia di un \u201cinterceptor\u201d per crawler<\/h2>\n\n\n\n

Il flusso, semplificato, \u00e8 questo: il codice in index.php<\/code> controlla prima segnali di \u201cidentit\u00e0 Google\u201d, poi valida l\u2019IP contro range ASN, e solo dopo esegue il caricamento remoto del payload (contenuti esterni stampati a schermo come se fossero locali). Il tutto con logging ed error handling per non mostrare pagine rotte a Google.<\/p>\n\n\n\n

1) Verifica a pi\u00f9 livelli (User-Agent + IP)<\/h3>\n\n\n\n

Il primo controllo \u00e8 sullo User-Agent<\/code> (stringa inviata in ogni richiesta HTTP che identifica browser\/crawler e piattaforma). Lo script cerca non solo \u201cGooglebot\u201d, ma anche stringhe tipiche di strumenti di verifica e ispezione, cos\u00ec da aumentare la probabilit\u00e0 che il contenuto malevolo venga effettivamente scansionato e validato dai sistemi Google.<\/p>\n\n\n\n

\"Schema
Due step: filtraggio User-Agent e validazione IP per evitare crawler spoofati. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

2) Validazione del range con operazioni bitwise<\/h3>\n\n\n\n

La parte pi\u00f9 \u201ctecnica\u201d \u00e8 il matching del range: invece di confrontare stringhe, usa operazioni bitwise per verificare che un IP cada esattamente dentro un blocco di rete (CIDR). Per IPv4, la logica indicata \u00e8 basata su AND tra IP e netmask, confrontata con network address e netmask.<\/p>\n\n\n\n

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