Redirect hack WordPress: trovare e rimuovere i redirect spam

Un redirect hack di WordPress è progettato per non farsi vedere da chi gestisce il sito. Il codice malevolo controlla chi sta visitando e reindirizza solo una parte degli utenti: chi naviga da mobile, chi arriva da Google o dai social e, spesso, ciascun visitatore una volta soltanto. Di norma esclude di proposito gli utenti connessi e gli amministratori.

Se un cliente scrive «il vostro sito mi ha mandato su una pagina di premi falsi» e dal vostro portatile tutto appare normale, credete al cliente. Le destinazioni tipiche sono pagine truffa, finti giveaway, reti pubblicitarie aggressive o download di malware. Google può segnalare il sito e i visitatori smettono di fidarsi. I redirect sono solo uno dei sintomi; gli altri sono descritti in 12 segnali che il sito WordPress è stato hackerato.

Perché il titolare non vede mai il redirect hack di WordPress

Le condizioni sono semplici ed efficaci. Il codice legge l'header User-Agent per riconoscere gli smartphone e l'header Referer per riconoscere il traffico dai motori di ricerca. Controlla inoltre la presenza del cookie di accesso di WordPress. Dopo il primo redirect imposta un proprio cookie oppure registra l'indirizzo IP, così la stessa persona non viene reindirizzata una seconda volta.

Questa combinazione spiega gran parte delle segnalazioni del tipo «non riesco a riprodurlo». Siete connessi, state lavorando da desktop, digitate l'indirizzo direttamente e magari siete già stati reindirizzati una volta. Basta una qualsiasi di queste condizioni per disattivare il redirect.

Riprodurre il redirect in sicurezza

Prima di cercare nei file, bisogna capire che tipo di redirect si ha davanti. Il tipo di risposta indica il livello in cui cercare.

Si parte dal browser. Aprite una finestra privata e verificate di non essere connessi. Aprite gli strumenti per sviluppatori (F12 in Chrome, Edge e Firefox) e attivate la barra dei dispositivi (Ctrl+Maiusc+M) per emulare uno smartphone. Nella scheda Network spuntate Preserve log (in Firefox: Persist Logs nel menu delle impostazioni di Network), così le voci restano visibili dopo il cambio di pagina. Per ottenere un vero referrer di Google, cercate il vostro dominio su Google e cliccate sul risultato.

Ora osservate la prima voce nella scheda Network:

• **Stato 301, 302, 307 o 308 con una Location esterna**: il redirect avviene sul server. Ne fanno parte la CDN, le regole del web server, PHP e WordPress stesso.
• Stato 200, poi una richiesta verso un dominio esterno: la pagina si è caricata normalmente e poi JavaScript (o un meta tag refresh) ha portato il browser altrove. Occorre cercare uno script iniettato.

Confermate poi il risultato con curl. Curl non esegue JavaScript e non segue i redirect se non glielo si chiede. Il comando seguente esegue una normale richiesta GET e stampa solo gli header della risposta; evitate curl -I, perché alcuni codici iniettati ignorano le richieste HEAD:

curl -s -o /dev/null -D - \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1" \
  -e https://www.google.com/ \
  https://example.com/

Una riga Location: che punta a un dominio sconosciuto conferma un redirect lato server. Se la riga di stato riporta 200, scaricate il corpo della pagina e cercate codice di redirect e offuscamento:

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)" \
  -e https://www.google.com/ https://example.com/ \
  | grep -Eio 'window\.location|location\.href|location\.replace|http-equiv=.?refresh|atob\(|eval\(|fromCharCode|script[^>]+src="[^"]+"'

Ripetete il test senza -A e -e e confrontate i risultati. Provate poi più URL, per esempio un articolo del blog, una scheda prodotto e la pagina dei contatti: molte iniezioni colpiscono solo alcuni template.

Un risultato pulito non dimostra che il sito lo sia. Se il codice reindirizza ogni IP una sola volta o colpisce solo determinati Paesi, il test può non rilevarlo. Ripetete la prova da un'altra rete, per esempio da uno smartphone con dati mobili.

Redirect lato server: .htaccess, configurazione del server e PHP eseguito per primo

Se curl mostra un 3xx verso un dominio esterno, la ricerca va fatta sul server e nel codice che viene eseguito prima che WordPress generi la pagina.

Con Apache controllate tutti i file .htaccess, non solo quello nella radice del sito. Cercate condizioni di riscrittura su user agent o referrer e la direttiva auto_prepend_file, che fa caricare a PHP un file dell'attaccante prima di ogni richiesta:

grep -rn --include=.htaccess -E "HTTP_(USER_AGENT|REFERER)|auto_prepend_file" .
grep -rn --include=.user.ini --include=php.ini "auto_prepend_file" .

Righe RewriteCond %{HTTP_USER_AGENT} legittime esistono, per esempio in alcuni plugin di cache. Una regola che manda il traffico mobile o proveniente da Google verso un dominio sconosciuto, invece, non lo è.

Elencate poi i file PHP e di configurazione modificati di recente. Gli attaccanti possono reimpostare i timestamp dei file, quindi considerate questo elenco un punto di partenza, non una prova. Eseguite il comando dalla radice di WordPress:

find . -type f \( -name "*.php" -o -name ".htaccess" -o -name ".user.ini" \) -mtime -14 -print

Esaminate con attenzione tutto ciò che compare all'inizio o alla fine di wp-config.php e ogni file in wp-content/mu-plugins. I must-use plugin si caricano automaticamente e non compaiono nell'elenco normale dei plugin. Controllate anche il functions.php del tema attivo. Poi eseguite wp core verify-checksums per individuare file del core modificati. Per interpretarne l'output e reinstallare il core in modo sicuro, vedere la nostra guida alla verifica dei checksum di WordPress.

Su nginx le regole stanno nella configurazione del server, non in .htaccess. Con un hosting gestito potrebbe non essere possibile consultarle. In entrambi i casi, chiedete al provider di verificare a livello di server la presenza di regole di redirect e di impostazioni prepend.

Le opzioni siteurl e home

Una variante più rozza modifica le opzioni siteurl e home. WordPress reindirizza allora tutti i visitatori al dominio dell'attaccante, voi compresi. Controllate entrambi i valori:

wp option get siteurl
wp option get home

Senza WP-CLI, aprite phpMyAdmin e guardate la tabella wp_options. Il prefisso delle tabelle può essere diverso da wp_: verificate $table_prefix in wp-config.php. Per correggere i valori:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Eseguite anche grep -n "WP_HOME\|WP_SITEURL" wp-config.php. Se queste costanti sono definite, sovrascrivono i valori del database. Un attaccante può inserirle lì e la correzione nel database sembrerà non avere alcun effetto.

Redirect JavaScript in articoli, widget, file del tema e script nell'header

Una risposta 200 seguita da un salto verso un altro dominio indica che nella pagina è in esecuzione uno script. Può provenire da più punti:

• Contenuto degli articoli: tag script iniettati in post_content, spesso in decine di articoli contemporaneamente.
• Opzioni: righe dei widget (widget_*), opzioni del tema e impostazioni dei page builder in wp_options.
• Impostazioni «Insert headers and footers»: plugin per snippet di codice e page builder vi memorizzano gli script validi per tutto il sito. A chi ha accesso come amministratore basta incollare una riga.
• File di temi e plugin: header.php, footer.php e file JavaScript accodati.

Una rapida ricerca nel database (adattate wp_posts se il prefisso delle tabelle è diverso):

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%script%src=%';"
wp db search 'fromCharCode' --all-tables
wp option list --search='widget_*' --fields=option_name

Aspettatevi codice offuscato: il codice iniettato raramente contiene l'URL di destinazione in chiaro. Cercate atob(, lunghe stringhe base64, String.fromCharCode e sorgenti di script che imitano domini noti di CDN o di analytics con una grafia leggermente diversa. La tecnica di ricerca nel database e la pulizia sono approfondite in spam SEO su WordPress.

Copie in cache: plugin di cache, cache del server e CDN

Si può ripulire completamente l'origine e vedere comunque i visitatori reindirizzati, perché la pagina infetta è ancora memorizzata da qualche parte. Le copie possono sopravvivere nei file della cache di pagina (wp-content/cache), in una cache degli oggetti come Redis o Memcached, nella cache del server del provider e sui nodi edge della CDN.

Svuotate le cache nell'ordine in cui passa la richiesta, dall'origine verso l'esterno:

1. Terminate la pulizia di file e database sull'origine.
2. Svuotate la cache di pagina del plugin di cache.
3. Svuotate la cache degli oggetti con wp cache flush.
4. Svuotate la cache del server dal pannello dell'hosting.
5. Eseguite il purge completo sulla CDN.
6. Ripetete il test con i comandi curl sopra, con e senza lo user agent mobile e il referrer di Google.

Considerate anche il caso opposto: il redirect è stato impostato sulla CDN o a livello DNS. Chiunque abbia accesso all'account della CDN può creare una regola di redirect senza toccare WordPress. Controllate le regole di redirect e di pagina nella dashboard della CDN e i record DNS. Verificate chi dispone di credenziali per questi account e revocate gli accessi non più necessari.

Individuare il punto d'ingresso, altrimenti il redirect ritorna

Il redirect è il payload, non la falla. Se si elimina solo il payload, di solito torna nel giro di pochi giorni, perché la via d'accesso è ancora aperta. I punti d'ingresso più comuni sono plugin vulnerabili o «nulled», credenziali di amministratore o di hosting rubate, web shell in wp-content/uploads e backdoor residue che reiniettano il codice tramite un cron job o un'opzione del database.

Un breve primo controllo:

• Amministratori sconosciuti: wp user list --role=administrator
• Password per le applicazioni che non avete creato (Utenti > Profilo)
• Eventi pianificati sconosciuti: wp cron event list
• File PHP nella cartella uploads: find wp-content/uploads -name "*.php"
• Plugin e temi obsoleti o «nulled»

Una volta chiusa la falla, cambiate le password di amministratore, hosting, database, SFTP e CDN. Poi ruotate i salt con wp config shuffle-salts: tutti gli utenti verranno disconnessi. Seguite il piano completo di rimozione del malware da WordPress per la conservazione delle prove e per la scelta tra pulizia e ripristino.

L'attaccante potrebbe inoltre aver avuto accesso a dati dei clienti, a voci dei moduli di contatto o a ordini. In tal caso l'incidente va valutato come possibile violazione dei dati personali. Vedere la notifica di una violazione entro 72 ore secondo il GDPR.

FAQ

Perché vengono reindirizzati solo gli utenti mobile?

Chi naviga da smartphone nota meno facilmente un indirizzo strano nella barra e ha maggiori probabilità di toccare le pagine truffa. I titolari, inoltre, controllano di solito il proprio sito da desktop e da connessi. La condizione «solo mobile» serve a nascondere il redirect proprio a voi.

Google mostra «Questo sito potrebbe essere stato hackerato». Che fare?

Prima si ripulisce il sito, si chiude il punto d'ingresso e si svuotano tutte le cache. Poi si richiede un riesame in Google Search Console. La procedura è descritta in spam SEO su WordPress. Se il riesame viene richiesto prima che il redirect sia davvero scomparso, tende a essere respinto.

Un plugin di sicurezza può rimuovere il redirect al posto mio?

Gli scanner aiutano a trovarlo, ma non sostituiscono la pulizia manuale né la ricerca del punto d'ingresso. Il plugin di audit secaudit.eu controlla l'integrità dei file rispetto a una baseline e segnala indicatori di compromissione come amministratori nascosti, eventi cron sospetti e spam nel database. Cerca inoltre spam SEO nascosto. Rileva e segnala: rimuovere il codice e chiudere la falla spetta a voi o a un professionista incaricato.