Sito WordPress hackerato: 12 segnali e come verificarli

I segnali più evidenti di un sito WordPress hackerato sono account amministratore che nessuno ha creato, file PHP dove dovrebbero esserci solo immagini e pagine di spam o reindirizzamenti che sul proprio schermo non compaiono mai. Quasi tutti questi segnali sono silenziosi per scelta: chi attacca vuole che il sito continui a funzionare, quindi si nasconde agli amministratori collegati e mostra i contenuti malevoli solo ai motori di ricerca o a visitatori selezionati.

Ecco 12 segnali, raggruppati in base a dove si notano, ciascuno con un modo concreto per verificarlo. Diversi controlli usano WP-CLI, la riga di comando di WordPress. Il file manager e lo strumento per il database offerti dall'hosting vanno bene lo stesso, solo che richiedono più tempo.

WordPress hackerato? I segnali che notano i visitatori

1. Reindirizzamenti solo da mobile o da Google

Molte infezioni reindirizzano soltanto una parte dei visitatori: chi naviga da smartphone o chi arriva da una ricerca su Google. Le norme di Google relative allo spam descrivono entrambi i trucchi: il cloaking (contenuti diversi per motori di ricerca e utenti) e il reindirizzamento degli utenti mobile verso un dominio di spam. Chi digita l'indirizzo del proprio sito dal computer vede un sito normale e non si accorge di nulla.

Come verificare: dallo smartphone, con la rete dati mobile e senza aver effettuato l'accesso, cercare il sito su Google e toccare il risultato. Da terminale, confrontare una richiesta semplice con quella di un «visitatore mobile proveniente da Google»:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' \
  -e 'https://www.google.com/' https://example.com/

Un 301 o un 302 verso un dominio estraneo, presente solo nel secondo risultato, è un forte campanello d'allarme. I reindirizzamenti via JavaScript non emergono in questo modo: conviene quindi cercare anche script sconosciuti nel codice sorgente della pagina.

2. Avvisi del browser o dell'antivirus

Un avviso del browser a tutto schermo come «Sito ingannevole in vista», oppure clienti che segnalano che il loro antivirus blocca il sito, di solito significano che una blocklist ha già rilevato malware o phishing sul dominio. Come verificare: cercare il dominio nella pagina Stato del sito di Navigazione sicura di Google e farsi inviare uno screenshot dell'avviso esatto.

Segnali nei risultati di ricerca di Google

3. Pagine di spam nei risultati site:

Le pagine iniettate su casinò, farmaci o merce contraffatta compaiono spesso su Google prima che le si noti altrove. Come verificare: cercare site:example.com e scorrere i risultati alla ricerca di titoli in lingue straniere o di argomenti mai pubblicati. Aggiungendo parole come casino, viagra o loan si restringe il campo.

4. Problemi di sicurezza in Search Console

Se il sito è verificato in Google Search Console, aprire Sicurezza e azioni manuali → Problemi di sicurezza. Lì Google elenca i problemi che ha rilevato, per esempio contenuti compromessi o malware. Come verificare: assicurarsi che la proprietà sia verificata e che i messaggi arrivino a qualcuno che li legge davvero. Un rapporto vuoto è una buona notizia, non una prova.

Segnali sul server e nell'account di hosting

5. Sospensione dell'hosting o CPU sotto sforzo

I provider di hosting sospendono gli account che inviano spam, ospitano pagine di phishing o sovraccaricano il server. Un picco di CPU senza un aumento dei visitatori può indicare che sull'account gira un cryptominer o uno script di spam. Come verificare: leggere per intero il messaggio dell'hosting (spesso indica i file coinvolti) e controllare i grafici delle risorse nel pannello di controllo. Con accesso SSH, ps aux --sort=-%cpu | head mostra i processi più attivi.

6. Spam in uscita e IP in blacklist

Se le proprie email cominciano a tornare indietro, o arrivano notifiche di mancato recapito per messaggi mai inviati, è possibile che uno script stia usando il server per spedire spam. Come verificare: chiedere all'hosting se il volume della posta in uscita è cambiato e controllare l'indirizzo IP del server con un servizio pubblico di verifica delle blacklist.

7. File PHP in wp-content/uploads

La cartella degli upload dovrebbe contenere immagini e documenti, non codice. Un file PHP lì dentro è spesso una web shell, cioè una backdoor che consente all'attaccante di eseguire comandi. Come verificare:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

Alcuni plugin inseriscono un index.php vuoto nelle proprie cartelle per impedire che se ne possa elencare il contenuto. Ogni risultato va aperto per vedere che cosa contiene davvero.

8. File del core modificati

Chi attacca nasconde volentieri il proprio codice nei file del core di WordPress, perché nessuno li legge. Come verificare: wp core verify-checksums confronta i file del core con i checksum ufficiali di WordPress.org e segnala ogni file che non corrisponde (documentazione del comando). wp plugin verify-checksums --all fa lo stesso per i plugin, ma solo per quelli ospitati su WordPress.org.

9. Modifiche inattese a .htaccess o wp-config.php

Bastano poche righe aggiunte a .htaccess per reindirizzare i visitatori in base al referrer o al browser. Una riga in wp-config.php, o un'impostazione auto_prepend_file in .user.ini, può caricare malware prima ancora che WordPress si avvii. Come verificare: confrontare entrambi i file con l'ultimo backup sicuramente pulito, poi cercare i tipici trucchi di offuscamento e di prepend:

grep -rnE --include='*.php' 'eval\(|base64_decode\(|gzinflate\(|str_rot13\(' . | head -50
grep -rn 'auto_prepend_file' --include='.htaccess' --include='.user.ini' --include='php.ini' .

Anche i plugin legittimi usano alcune di queste funzioni: i risultati vanno trattati come indizi, non come verdetti.

Segnali nella bacheca di WordPress

10. Amministratori sconosciuti

Creare un nuovo account amministratore è il metodo classico per mantenere l'accesso, e alcuni malware nascondono il proprio account nella schermata Utenti. Come verificare:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

I due flag --skip impediscono al codice di plugin e temi, compreso il malware che vi si nasconde, di filtrare l'elenco. I plugin must-use e wp-config.php vengono comunque caricati, quindi vanno controllati a parte (segnali 9 e 11). Se WP-CLI mostra più amministratori della schermata Utenti, qualcosa sta nascondendo un account. Va controllato anche, nel profilo di ogni amministratore, che non esistano password per le applicazioni (Application Passwords) che nessuno del team ha creato.

11. Plugin che nessuno ha installato

Attenzione ai plugin con nomi generici, senza autore o senza descrizione, che nessuno nel team ricorda di aver installato. I plugin must-use in wp-content/mu-plugins si caricano automaticamente e sfuggono facilmente. Come verificare: wp plugin list mostra i plugin normali insieme ai plugin must-use e ai drop-in come object-cache.php; wp plugin list --status=must-use,dropin mostra solo questi ultimi due gruppi.

12. Cron job sospetti

Spesso il malware si pianifica da solo, così da ricomparire dopo essere stato cancellato. Come verificare:

wp cron event list --fields=hook,next_run_relative,recurrence

Ogni hook che non si riesce a ricondurre a un plugin in uso va approfondito. Contano anche i cron job a livello di server: li mostrano crontab -l o la sezione cron del pannello di hosting.

Cosa fare nella prima ora

Se uno o più di questi segnali fanno pensare a un attacco, l'ora successiva decide quanto si potrà ancora ricostruire. Conviene procedere con calma, in quest'ordine:

1. Non cancellare d'impulso. Eliminare il file sospetto o l'amministratore sconosciuto distrugge le prove e raramente rimuove l'intera infezione, perché chi attacca lascia spesso più di una porta aperta per rientrare.
2. Conservare le prove. Eseguire uno snapshot o un backup completo di file e database nello stato compromesso e scaricare i log di accesso e di errore del web server, che molti hosting conservano solo per un periodo limitato. Archiviare la copia offline ed etichettarla come infetta.
3. Cambiare le password da un dispositivo pulito. Partire dall'account di hosting, poi SFTP/SSH, database e tutti gli amministratori WordPress. Se il proprio computer potrebbe essere compromesso, usarne un altro, e attivare l'autenticazione a due fattori per ogni amministratore.
4. Contattare l'hosting. Il provider vede i log del server, gli altri siti sullo stesso account e la posta in uscita, e spesso riesce a isolare il sito in tempi brevi.
5. Annotare l'orario. Registrare il momento in cui si è venuti a conoscenza dell'attacco e quanto osservato fino a quel punto.

L'ultimo punto conta ai fini del GDPR, il Regolamento generale sulla protezione dei dati. Se l'attaccante poteva raggiungere dati dei clienti, messaggi inviati tramite moduli di contatto, account utente od ordini, l'attacco costituisce di norma una violazione dei dati personali. L'articolo 33 del GDPR impone di notificarla all'autorità di controllo (in Italia il Garante per la protezione dei dati personali) senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui se ne è venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio. La nostra guida alla notifica delle violazioni entro 72 ore prevista dal GDPR spiega come fare questa valutazione.

Messe al sicuro le prove, si prosegue con il nostro piano passo per passo per rimuovere il malware da WordPress: isolare il sito, trovare il punto d'ingresso, ripulire partendo da fonti affidabili e cambiare tutte le credenziali.

Security Audit & Compliance, il plugin WordPress di secaudit.eu, controlla diversi di questi segnali, tra cui account amministratore nascosti, eventi cron sospetti, checksum del core, modifiche ai file rispetto a una baseline e spam SEO nascosto. Rileva e segnala; la rimozione del malware resta un lavoro da svolgere in proprio o da affidare a un professionista.

Domande frequenti

Un sito può essere hackerato senza alcun segnale visibile?

Sì. Molte infezioni sono progettate per restare invisibili al proprietario: ignorano gli utenti collegati, prendono di mira solo i motori di ricerca o agiscono soltanto sul server. Per questo i controlli descritti sopra vanno oltre un'occhiata alla home page.

Ogni attacco è una violazione dei dati ai sensi del GDPR?

Non sempre, ma spesso sì. Se dati personali sono stati consultati, modificati, persi o resi indisponibili, si tratta di una violazione dei dati personali. In ogni caso la valutazione va documentata: l'articolo 33, paragrafo 5, richiede di registrare ogni violazione, comprese quelle non notificate.

Conviene ripristinare subito il backup di ieri?

Solo dopo aver salvato lo stato infetto e aver capito, almeno a grandi linee, quando è iniziato l'attacco. Un backup eseguito dopo l'intrusione contiene anch'esso la backdoor, e ripristinarlo senza chiudere il punto d'ingresso significa riaprire subito la porta all'attaccante.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.