L’anatomia di un attacco di cloaking SEO su WordPress

Non tutti gli attacchi a WordPress sono rumorosi. Alcuni aggressori non vogliono deturpare il tuo sito né tenerlo in ostaggio per un riscatto. Vogliono dirottare silenziosamente l’autorità di ricerca del tuo dominio e usarla per posizionare i propri contenuti su Google. Questi attacchi si chiamano attacchi di cloaking SEO, e sono tra le compromissioni più dannose che un sito aziendale possa subire, perché spesso il proprietario non sa nemmeno che stanno avvenendo.

Questo articolo illustra esattamente come funziona un vero attacco di cloaking SEO, usando un recente caso di studio di un’agenzia di Sydney in cui ogni file e ogni dispatcher è stato identificato durante un audit forense. Se gestisci un sito WordPress, quello che segue è lo schema che dovresti saper riconoscere.

Cosa significa cloaking

Il cloaking è la pratica di servire contenuti diversi ai motori di ricerca rispetto ai visitatori umani. Una pagina può mostrare a Googlebot un lungo articolo pieno di parole chiave su temi commerciali non correlati, mentre mostra a un visitatore normale una landing page generica o un reindirizzamento. L’obiettivo è ingannare i motori di ricerca affinché posizionino il contenuto mascherato sotto l’autorità di un dominio affermato.

Google ha regole contro tutto questo. Il cloaking viola le linee guida per i webmaster e può procurare a un dominio penalizzazioni da azione manuale o un crollo totale del posizionamento se viene rilevato. All’aggressore non importa, perché il dominio non è suo.

Lo schema delle cinque directory

Il caso di Sydney usava una versione particolarmente pulita dell’attacco. L’aggressore aveva creato cinque nuove directory nella radice del sito, ciascuna nominata per imitare una vera pagina WordPress. Sul disco comparivano cartelle con nomi come about, contact, good-to-know, services e work. Ognuna conteneva esattamente tre file. Un dispatcher index.php. Un file HTML user.php. Un file HTML wp-log.php.

Il motivo per cui le cartelle erano nominate come pagine reali era semplice. Quando arrivava una richiesta per /about/ sul sito, il web server controllava prima il filesystem. Esisteva una cartella chiamata about, con un index.php all’interno. Il web server risolveva quel file prima che entrasse in gioco il routing degli URL di WordPress. Ogni richiesta a quegli URL colpiva il codice dell’aggressore invece della legittima pagina WordPress.

Il dispatcher

Il file index.php di ogni cartella era un piccolo pezzo di PHP che faceva una sola cosa. Ispezionava l’header User-Agent della richiesta in arrivo e instradava di conseguenza. Se lo User-Agent conteneva Googlebot, Googlebot-Mobile o Googlebot-News, serviva il contenuto di wp-log.php. Altrimenti includeva user.php e usciva.

Lo stesso file era distribuito in tutte e cinque le cartelle, identico byte per byte. L’aggressore usava un solo payload e una sola regola di decisione. Tutto il resto erano dati.

Il payload per Googlebot

I file wp-log.php, nonostante l’estensione .php, contenevano puro HTML. Erano enormi, da circa 1,3 MB a oltre 4 MB. Ognuno era una pagina HTML completa in una lingua straniera, in questo caso l’indonesiano, con contenuti spam su gioco d’azzardo, e-commerce e tracciamento di prodotti Samsung. Le pagine erano farcite di dati strutturati, script di tracciamento di terze parti incorporati e link progettati per superare il contenuto legittimo sulle parole chiave prese di mira.

Perché chiamarlo wp-log.php? Camuffamento. Per un proprietario che dà un’occhiata all’elenco dei file, sembra un file di log di WordPress, non un payload sospetto.

Il payload per gli umani

I file user.php erano pagine HTML più piccole servite ai veri visitatori umani. Erano pagine doorway provenienti da siti di terze parti non correlati, anch’esse mascherate con un’estensione .php pur non contenendo alcun codice PHP. Chiunque arrivasse a uno di quegli URL da un risultato di ricerca, o navigasse verso /about/ sul sito, vedeva contenuti che non avevano nulla a che fare con l’agenzia.

Questa è la parte di cloaking. Google vede lo spam sul gioco d’azzardo nel contenuto di wp-log.php, lo posiziona sotto l’autorità di dominio dell’agenzia e invia gli utenti reali a user.php, che offre un’esperienza doorway completamente diversa. L’inganno funziona in entrambe le direzioni.

Come è entrato l’aggressore

L’audit forense non è riuscito a individuare l’esatto vettore d’ingresso dai dati disponibili, ma il sospetto più probabile era un plugin di gestione file obsoleto ancora installato e attivo. La famiglia di plugin in questione ha una lunga storia di vulnerabilità di esecuzione di codice da remoto, con diversi avvisi pubblicati negli anni passati. Con accesso in scrittura tramite quel plugin, un aggressore può depositare file arbitrari ovunque nella radice del documento.

Aspetto cruciale: l’audit ha confermato che il core di WordPress, wp-config.php, il database e il tema attivo erano tutti puliti. Nessuna backdoor nell’applicazione, nessun utente amministratore fraudolento, nessun eval PHP offuscato. La compromissione era interamente in quelle cinque cartelle. È questo che la rendeva così silenziosa. La maggior parte degli scanner di sicurezza guarda ai file di WordPress, non alla radice del documento in cerca di directory inattese.

Perché questo tipo di attacco è così dannoso

Gli attacchi di cloaking SEO fanno male in tre modi. Primo, il contenuto spam viene indicizzato sotto il tuo dominio, spingendo le tue pagine reali in basso o fuori dai risultati di ricerca. Secondo, Google può applicare penalizzazioni da azione manuale o un declassamento algoritmico quando rileva il cloaking, dai quali spesso ci vogliono settimane o mesi per riprendersi anche dopo che i file dannosi sono stati rimossi. Terzo, gli script di terze parti e i pixel di tracciamento incorporati nelle pagine spam possono esporre i tuoi visitatori al rischio di malware o phishing.

Il proprietario di un sito sottoposto a cloaking spesso non nota nulla finché il traffico non crolla o un cliente non menziona di aver visto contenuti strani cliccando su un risultato di ricerca. A quel punto, sono già stati arrecati settimane o mesi di danni.

Come rilevarlo sul tuo sito

Alcuni controlli rapidi intercettano la maggior parte delle varianti di questo attacco. Visita la tua home page come un utente normale. Poi esegui una richiesta curl da un server con un header User-Agent di Googlebot e confronta. Se vedi contenuti diversi, qualcosa non va.

Controlla i report Copertura e Prestazioni in Google Search Console per URL indicizzati che non riconosci, soprattutto quelli con query in lingue straniere. Guarda la radice del documento via SFTP per cartelle o file che non sai spiegare. Esegui una scansione malware completa con un plugin di sicurezza affidabile e leggi il report invece di limitarti a cancellare gli avvisi.

Come prevenirlo

La prevenzione è lo stesso insieme di abitudini che previene la maggior parte delle compromissioni di WordPress. Tieni aggiornati core, temi, plugin e PHP. Rimuovi i plugin che non usi attivamente, soprattutto i gestori di file e gli strumenti di accesso shell. Blocca l’esecuzione di PHP nelle directory che non dovrebbero mai contenere PHP. Verifica la radice del documento ogni mese. Usa un plugin di sicurezza che monitori la comparsa di nuovi file in posizioni inattese e avvisi quando ne appare uno.

Hai bisogno di una mano?

Se temi che il tuo sito WordPress possa ospitare contenuti mascherati a tua insaputa, Defyn può eseguire un audit forense e dirti esattamente cosa c’è sul tuo server. Mettiti in contatto e ci assicureremo che il tuo dominio si posizioni solo per ciò che deve.