Il tuo sito WordPress reindirizza a un casinò, mostra una pagina di rivendicazione dell’attaccante o Google lo segnala come pericoloso? La cosa più urgente non è cancellare file a caso. È contenere l’attacco, conservare una copia dello stato compromesso e poi riprendere il controllo degli accessi prima di riparare. Questa guida mette in ordine le decisioni dalle prime ore ai trenta giorni successivi, con i comandi utili e gli obblighi da non dimenticare (tra cui il termine di 72 ore del GDPR).
Non sei ancora sicuro di essere stato hackerato? Parti dalle verifiche per capire se il tuo sito WordPress è hackerato. Cerchi il dettaglio tecnico della pulizia, file per file? Lo trovi nella nostra procedura passo passo per ripulire un sito WordPress hackerato. Questo articolo è il tuo piano di risposta: chi fa cosa, in quale ordine e come evitare una nuova infezione.
I primi dieci minuti: contenere senza cancellare
Finché il codice malevolo è attivo, può rubare dati, inviare spam o infettare i tuoi visitatori. Ma cancellare tutto subito distrugge le tracce che permetteranno di trovare il punto di ingresso. Il giusto compromesso:
- Metti il sito offline per i visitatori: pagina di manutenzione a livello di server (una regola
.htaccessche restituisce una pagina statica con codice 503, o l’opzione del provider), non con un plugin WordPress che dipende dal codice compromesso. - Avvisa il provider di hosting con un ticket: a volte ha già rilevato l’infezione, può bloccare l’invio di email e dispone di log che tu non vedi.
- Apri un registro dell’incidente fuori dal server: ora, constatazione, azione, autore. Servirà per l’assicurazione, per un tecnico esterno, per una denuncia o per il Garante.
- Non ripristinare ancora un backup: non sai da quando il sito è compromesso, né se il backup è pulito.
Valutare la gravità per scegliere il ritmo giusto
Non tutti gli attacchi richiedono la stessa urgenza. La tabella seguente ti aiuta a decidere chi coinvolgere e cosa viene prima.
| Cosa noti | Rischio principale | Priorità | Chi coinvolgere |
|---|---|---|---|
| Reindirizzamenti verso siti sospetti, avviso di Google | Visitatori infettati, deindicizzazione | Offline subito | Provider, tu o un tecnico esterno |
| Pagine di spam indicizzate (farmaci, casinò) | Posizionamento, reputazione | In giornata | Tu, poi Search Console |
| Home page deturpata | Immagine del marchio | Offline subito | Provider, tecnico esterno |
| Account clienti, moduli o ordini esposti | Violazione di dati personali | Immediata, il termine del GDPR è già partito | Responsabile della protezione dei dati, Garante, tecnico esterno |
| Modulo di pagamento modificato (negozio) | Furto di carte di pagamento | Immediata | Gestore dei pagamenti, banca, tecnico esterno |
| Riscatto o file cifrati | Perdita di dati | Immediata, non pagare | Provider, Polizia Postale, denuncia |
Conservare una copia dello stato compromesso
Prima di qualsiasi riparazione, scarica una copia completa: file (via SFTP o con un archivio creato dal provider), database (esportazione SQL) e, se possibile, i log di accesso del server degli ultimi 30 giorni. Conservala fuori dal server, separata dai backup puliti, ed etichettala chiaramente come «infetta» per non ripristinarla mai per errore. È questa copia che ti permetterà di datare l’intrusione, e quindi di scegliere un backup precedente.
Per datare l’intrusione, cerca in questa copia i file PHP modificati di recente e la data di creazione degli account sconosciuti. Qui la regola dei backup 3-2-1 fa tutta la differenza: senza una copia esterna più vecchia, non resta che la pulizia.
Riprendere gli accessi, dal più ampio al più ristretto
Cambia le password da un computer pulito, cominciando da ciò che dà più potere: un attaccante che conserva l’accesso alla tua casella email o all’area clienti del provider può ricominciare da capo.
- La casella email che riceve i link di reimpostazione, poi l’area clienti del provider e il registrar del dominio (attiva l’autenticazione a due fattori).
- Account SFTP e SSH, pannello di controllo (cPanel, Plesk) e utente del database, poi aggiorna
wp-config.php. - Chiavi e salt di WordPress, operazione che chiude tutte le sessioni aperte, compresa quella dell’attaccante.
- Tutti gli account amministratore, poi le password per le applicazioni e le chiavi API dei plugin (pagamenti, invio email, backup remoto).
Con WP-CLI, le verifiche di base stanno in pochi comandi:
# Nuove chiavi e salt: tutte le sessioni vengono chiuse
wp config shuffle-salts
# Account amministratore: individua quelli che non conosci
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Attività pianificate: un'attività sconosciuta può reinfettare il sito
wp cron event list --fields=hook,next_run_relative,recurrence
# Indirizzi del sito: qui può nascondersi un reindirizzamento
wp option get siteurl
wp option get home
Riparare: cosa sostituire, cosa ispezionare
Il principio: tutto ciò che si può reinstallare da una fonte ufficiale va sostituito, non ripulito riga per riga. Solo ciò che è tuo (contenuti, media, impostazioni, tema su misura) si ispeziona a mano.
| Elemento | Azione | Comando o metodo |
|---|---|---|
| Core di WordPress | Reinstallare identico | wp core verify-checksums poi wp core download --force --skip-content |
| Plugin e temi | Eliminare, poi reinstallare da wordpress.org o dallo sviluppatore | wp plugin verify-checksums --all, mai versioni «nulled» |
| Cartella uploads | Non deve contenere alcun file PHP | find wp-content/uploads -name "*.php" |
| mu-plugins e drop-in | Controllare ogni file | wp-content/mu-plugins, object-cache.php, advanced-cache.php |
| .htaccess e wp-config.php | Confrontare con una versione pulita | Reindirizzamenti, auto_prepend_file, inclusioni sconosciute |
| Database | Cercare script iniettati | Tabelle wp_options e wp_posts: tag <script>, eval, base64 |
| Utenti | Eliminare gli account sconosciuti | Riassegnare i loro contenuti, controllare i ruoli modificati |
I nascondigli classici di una backdoor sono proprio dove nessuno guarda: un file dal nome innocuo in uploads, un mu-plugin che non compare nell’elenco dei plugin, un’attività cron che ricrea il file eliminato. Se non scopri come è entrato l’attaccante (plugin vulnerabile, password riutilizzata, accesso FTP rubato), il sito verrà violato di nuovo nel giro di pochi giorni: è il momento di rivolgerti a un professionista.
Il piano di risposta, passo dopo passo
Uscire dalle blacklist e dall’avviso di Google
Una volta che il sito è pulito, e solo allora, rimettilo online e fai rimuovere le segnalazioni:
- Google Search Console: il rapporto «Problemi di sicurezza» elenca ciò che Google ha rilevato. Correggi tutto, su tutte le pagine, poi fai clic su «Richiedi una revisione» descrivendo il problema, cosa hai fatto e il risultato. Google indica che una revisione per malware o contenuti compromessi richiede da qualche giorno a qualche settimana: non inviare un’altra richiesta finché la prima è in corso. Dettagli nella nostra guida sull’avviso «sito pericoloso».
- Pagine di spam indicizzate: lascia che rispondano 404 o 410 e usa lo strumento di rimozione temporanea per le più visibili. Il metodo completo è nel nostro articolo sullo spam SEO e la deindicizzazione.
- Altre liste: verifica il dominio su servizi di analisi come VirusTotal o Sucuri SiteCheck, e l’indirizzo IP da cui partono le tue email sulle blacklist antispam se i tuoi messaggi finiscono nella posta indesiderata. Ogni lista ha la propria procedura di rimozione.
Notificare: Garante, interessati, denuncia
Se l’attaccante ha potuto accedere a dati personali (account clienti, moduli di contatto, ordini, elenco degli iscritti), si tratta di una violazione di dati personali ai sensi del GDPR. L’articolo 33 impone di notificarla al Garante per la protezione dei dati personali entro 72 ore dal momento in cui ne sei venuto a conoscenza, salvo che sia improbabile che presenti un rischio per le persone. In caso di rischio elevato (password, dati bancari, dati sensibili), l’articolo 34 impone anche di informare gli interessati. In ogni caso, documenta la violazione nel tuo registro interno. Il nostro articolo su GDPR, log e sicurezza di WordPress spiega cosa conservare.
- Notifica incompleta: puoi notificare entro 72 ore con ciò che sai e integrare in seguito. Meglio una notifica parziale in tempo che una perfetta in ritardo.
- Negozio online: avvisa il tuo gestore dei pagamenti se il processo di acquisto può essere stato modificato. Ti dirà cosa fare per le carte.
- Aiuto e denuncia: la Polizia Postale raccoglie le segnalazioni di reati informatici e riceve le denunce, che spesso l’assicurazione richiede.
I trenta giorni successivi: non farsi hackerare di nuovo
Un sito ripulito senza correggere la causa viene spesso reinfettato. Nel mese successivo:
- Aggiorna tutto ciò che resta, elimina i plugin inutilizzati e sostituisci i plugin abbandonati.
- Attiva l’autenticazione a due fattori per tutti gli account che possono pubblicare o amministrare.
- Ripeti i controlli di integrità ogni settimana e tieni d’occhio la comparsa di nuovi amministratori.
- Prova un ripristino da backup, sul serio, in un ambiente di staging.
- Scrivi un breve resoconto post-incidente: causa, durata, costo, cosa è mancato.
Cosa può fare WP Masquerade, e cosa non fa
Siamo chiari: WP Masquerade non è uno strumento di pulizia. Non cerca malware, non filtra il traffico come un firewall e non fa il backup del tuo sito. Per la riparazione, usa uno scanner (Wordfence, MalCare, Sucuri) o un professionista, e lo strumento di backup che preferisci.
Interviene dopo, per ridurre le probabilità di un nuovo incidente e avvisarti prima. La versione gratuita sposta la pagina di accesso, blocca XML-RPC e rimuove le tracce che rivelano WordPress ai bot. WP Masquerade Pro aggiunge l’autenticazione a due fattori obbligatoria per ruolo, la limitazione dei tentativi di accesso, il controllo di integrità del core, il registro attività degli amministratori e gli avvisi sui plugin vulnerabili, che spesso avrebbero permesso di correggere la falla prima dell’attacco.
Dopo la pulizia, chiudi le porte
Inizia con la versione gratuita, poi passa a Pro per l’autenticazione a due fattori, l’integrità del core e gli avvisi sulle vulnerabilità: da 59 € + IVA all’anno per un sito, 149 € + IVA per 10 siti.
Domande frequenti
Meglio ripristinare un backup o ripulire il sito?
Ripristina se hai un backup precedente all’intrusione e conosci la data di quest’ultima. Altrimenti ripulisci o ricostruisci. In entrambi i casi, correggi il punto di ingresso e cambia tutti gli accessi, altrimenti l’attaccante tornerà.
Quanto tempo impiega Google a rimuovere l’avviso?
Dopo una richiesta di revisione in Search Console, Google indica da qualche giorno a qualche settimana per malware e contenuti compromessi. I tempi dipendono dalla qualità della pulizia: qualsiasi problema residuo fa fallire la revisione.
Devo avvisare il Garante per un semplice spam SEO?
No, se nessun dato personale ha potuto essere consultato o copiato. Ma un attaccante che ha potuto aggiungere pagine ha spesso avuto accesso al database: verifica cosa contiene (account, ordini, moduli) prima di concludere, e annota la tua analisi nel registro delle violazioni.
Basta cambiare chiavi e salt di WordPress?
No. Così si chiudono le sessioni aperte, ma un attaccante che conosce una password, dispone di un account amministratore nascosto o di una backdoor rientra subito. I salt sono una parte di un insieme: password, account, file e attività pianificate.
Quando rivolgersi a un professionista?
Quando non trovi il punto di ingresso, quando il sito si reinfetta dopo la pulizia, quando sono in gioco dati di clienti o di pagamento, o quando il sito genera il tuo fatturato. Chiedi un rapporto scritto: causa, file coinvolti, misure adottate.
Da ricordare
- Prima contenere (sito offline a livello di server), poi cancellare.
- Conserva una copia dello stato compromesso, fuori dal server, per datare l’intrusione.
- Cambia gli accessi dal più ampio (email, provider) al più ristretto (account WordPress), poi i salt.
- Reinstalla core, plugin e temi dalla fonte; ispeziona uploads, mu-plugins, cron, .htaccess e il database.
- Dati personali coinvolti: notifica al Garante entro 72 ore.
- Senza correggere la causa, una nuova infezione è probabile.
Fonti
- WordPress.org: FAQ My site was hacked (link esterno, si apre in una nuova scheda)
- Google: rapporto Problemi di sicurezza (link esterno, si apre in una nuova scheda)
- GDPR, articolo 33: notifica di una violazione dei dati personali all’autorità di controllo (in inglese) (link esterno, si apre in una nuova scheda)
- WP-CLI: wp config shuffle-salts (link esterno, si apre in una nuova scheda)


