Se il tuo sito WordPress è stato hackerato, la priorità non è installare altri plugin di sicurezza o cancellare il primo file che sembra sospetto. Devi prima limitare l’accesso dell’attaccante, conservare una copia dello stato compromesso, capire cosa è stato modificato e solo dopo procedere alla bonifica.
Il punto più importante è questo: rimuovere il malware non significa necessariamente aver risolto la compromissione. Se resta aperta la vulnerabilità utilizzata per entrare, una backdoor, un account amministratore nascosto o una credenziale rubata, il sito può essere compromesso di nuovo.
La stessa documentazione ufficiale di WordPress dedicata ai siti hackerati consiglia di partire dagli indicatori di compromissione, documentare ciò che sta accadendo e utilizzare metodi di scansione differenti invece di affidarsi a un unico controllo.
In questa guida vediamo quindi cosa fare con WordPress hackerato, come ripristinare il sito, come cercare malware e meccanismi di persistenza e, soprattutto, come verificare che il problema sia stato realmente chiuso.
WordPress hackerato: cosa fare subito
Quando scopri un sito compromesso, evita modifiche casuali. Ogni intervento può alterare file, log e informazioni utili a capire cosa è successo.
L’ordine delle operazioni dipende dalla gravità dell’incidente. Se il sito sta distribuendo malware, effettuando redirect verso pagine di phishing o mettendo a rischio i visitatori, il contenimento viene prima della normale operatività.
In una situazione tipica procederei così:
- annota i sintomi e quando li hai osservati;
- conserva una copia dei file e del database nello stato attuale;
- limita l’accesso pubblico se il sito costituisce un rischio;
- revoca o modifica gli accessi che potrebbero essere compromessi;
- controlla hosting, log, utenti, file e database;
- individua la causa e gli eventuali sistemi utilizzati dall’attaccante per mantenere l’accesso;
- ripristina o sostituisci i componenti compromessi;
- verifica la pulizia prima di considerare concluso l’incidente.
Non esiste però una sequenza rigida valida per ogni attacco. Un sito editoriale con una singola iniezione di spam e un ecommerce che sta reindirizzando i clienti verso un dominio esterno richiedono livelli di contenimento differenti.
Documenta i sintomi e conserva una copia del sito compromesso
Prima delle operazioni distruttive annota ciò che hai osservato.
I segnali più evidenti possono essere:
- pagine o contenuti che non hai creato;
- reindirizzamenti verso altri domini;
- nuovi utenti amministratori;
- impossibilità di accedere alla dashboard;
- file sconosciuti;
- email di spam inviate dal server;
- notifiche dell’hosting;
- avvisi di sicurezza del browser o di Google;
- modifiche anomale al sito.
Un improvviso rallentamento, invece, non dimostra da solo che WordPress sia stato hackerato. Può dipendere anche da database, hosting, traffico, errori PHP o plugin malfunzionanti.
Annota anche cosa è cambiato poco prima dell’incidente: aggiornamenti, nuovi plugin, modifiche al tema, cambio di hosting, nuovi account o credenziali condivise. Sono indizi, non prove della causa, ma aiutano a restringere l’indagine.
Conserva poi una copia completa di file e database.
Questa copia non va confusa con un backup da usare subito per il ripristino. È una fotografia dello stato compromesso, utile per recuperare informazioni, confrontare file e capire cosa è stato alterato.
Isola il sito se sta mettendo a rischio gli utenti
Se il sito mostra phishing, download indesiderati, redirect malevoli o altre attività pericolose, lasciarlo normalmente accessibile mentre lo analizzi può continuare a esporre gli utenti.
A seconda dell’infrastruttura puoi temporaneamente:
- sospendere l’accesso pubblico;
- limitare il sito tramite hosting, reverse proxy o firewall;
- utilizzare una modalità di manutenzione che non impedisca l’accesso amministrativo necessario alla bonifica.
La misura scelta deve consentirti di continuare a lavorare su file, database, SFTP/SSH o pannello hosting.
Se sullo stesso account sono presenti più installazioni WordPress, controllale tutte. Una compromissione può non essere limitata al dominio sul quale hai notato il primo sintomo.
Contatta il provider di hosting quando l’incidente può essere più ampio
Il provider può disporre di informazioni che WordPress da solo non mostra: log del web server, processi anomali, file modificati, malware rilevato a livello di account o compromissioni che coinvolgono più siti.
Se più installazioni presenti nello stesso spazio vengono violate nello stesso periodo, concentrarsi esclusivamente sul primo WordPress può portare a una bonifica incompleta.
L’origine può trovarsi nell’applicazione, nelle credenziali, nell’account hosting, in un’altra installazione o nell’ambiente dal quale vengono amministrati i siti.
Capire cosa è stato compromesso e cercare la causa dell’attacco
La domanda corretta non è soltanto:
“Dov’è il malware?”
È:
“Che cosa è stato modificato, come è riuscito l’attaccante a entrare e può ancora rientrare?”
Questa distinzione separa una semplice pulizia di file da un vero recupero post-compromissione.
Segnali e indicatori di compromissione
Gli indicatori possono essere evidenti oppure molto discreti.
Un redirect che manda tutti gli utenti su un dominio sconosciuto è facile da notare. Più difficile è individuare un’iniezione che appare soltanto agli utenti provenienti da Google, da mobile oppure a intervalli casuali.
Controlla quindi il sito da più prospettive.
Verifica front-end, pagine indicizzate, utenti amministratori, modifiche ai file, log e attività del server. Se Google ha rilevato un problema, confronta anche gli URL indicati nel report di Search Console con ciò che trovi nell’installazione.
Non partire invece dal presupposto che ogni file PHP poco familiare sia malware. Plugin, temi e personalizzazioni possono contenere codice che, osservato fuori contesto, sembra sospetto.
Nome del file, funzione PHP o data di modifica sono indizi: servono confronto e contesto prima di eliminare qualcosa.
Controlla log, file modificati e utenti amministratori
I log possono aiutarti a ricostruire cosa è accaduto prima e dopo la compromissione.
Cerca, quando disponibili:
- login amministrativi inattesi;
- richieste verso file o endpoint anomali;
- upload non riconosciuti;
- modifiche ripetute agli stessi file;
- nuovi account;
- attività proveniente da indirizzi o sessioni non riconosciute.
Sul filesystem presta particolare attenzione a:
wp-config.php
.htaccess
index.php
wp-admin/
wp-includes/
wp-content/plugins/
wp-content/themes/
wp-content/mu-plugins/
wp-content/uploads/
La presenza di un file PHP dentro uploads, per esempio, merita un controllo in molte installazioni, ma non autorizza automaticamente a eliminarlo senza verificare come è costruito il sito.
Lo stesso principio vale per mu-plugins: sono plugin caricati automaticamente da WordPress e proprio per questo vanno inclusi nell’inventario, anche quando non compaiono insieme ai normali plugin nella dashboard.
Scanner esterni e scanner WordPress non vedono necessariamente le stesse cose
Uno scanner remoto osserva il sito dall’esterno. Può individuare pagine alterate, script esposti pubblicamente, redirect e alcuni comportamenti malevoli.
Uno scanner che lavora dentro l’installazione può invece confrontare file, ispezionare directory o rilevare modifiche non visibili dal front-end.
Sono prospettive differenti.
Per questo un singolo risultato “nessun malware trovato” non equivale a una certificazione che il sito sia pulito. WordPress stesso suggerisce di combinare controlli diversi perché ciascun metodo ha limiti differenti.
Non trasformerei quindi la scelta del plugin di sicurezza nella parte centrale dell’intervento. Il tool è utile se produce evidenza; non sostituisce l’analisi della compromissione.
Come ripristinare WordPress hackerato in modo sicuro
Una volta delimitato il problema puoi decidere se conviene ripristinare un backup precedente oppure ricostruire le parti compromesse usando componenti puliti.
La scelta dipende soprattutto da tre cose:
- esistenza di un backup precedente all’attacco;
- capacità di individuare la causa;
- possibilità di verificare che il backup non contenga già la compromissione.
Ripristina un backup solo se hai ragione di considerarlo pulito
Un backup antecedente al momento in cui hai scoperto l’attacco non è automaticamente sicuro.
L’attaccante potrebbe essere entrato giorni o settimane prima e aver mantenuto un comportamento invisibile. Il momento della scoperta e il momento iniziale della compromissione possono essere differenti.
Se utilizzi un backup, scegli quindi una copia sufficientemente precedente agli indicatori osservati e verificala comunque dopo il ripristino.
Soprattutto, non rimettere semplicemente online il backup lasciando invariato il punto d’ingresso.
Se la causa era un plugin vulnerabile, una password rubata o un account amministratore compromesso, il ripristino ricrea il sito ma non elimina necessariamente la causa dell’incidente.
Reinstalla core, plugin e temi da sorgenti affidabili
Quando un componente standard può essere sostituito con una copia originale, in genere è più affidabile reinstallarlo che cercare di “riparare” manualmente ogni singola riga modificata.
Per il core utilizza distribuzioni ufficiali di WordPress.
Per plugin e temi usa il repository WordPress o i pacchetti originali del vendor. Evita copie provenienti da mirror, archivi recuperati casualmente o versioni “nulled”.
La situazione cambia per:
- plugin sviluppati internamente;
- temi personalizzati;
- child theme;
- modifiche custom;
- componenti premium non disponibili nel repository.
Questi elementi non possono essere sostituiti alla cieca. Vanno confrontati con una copia affidabile o revisionati manualmente.
Dopo aver riportato l’ambiente a uno stato noto, aggiorna i componenti alle versioni supportate e compatibili necessarie per chiudere eventuali vulnerabilità note.
Verifica i file del core con i checksum di WordPress
Se disponi di WP-CLI puoi aggiungere un controllo molto utile: confrontare i file installati con i checksum pubblicati da WordPress.org.
Il comando documentato ufficialmente è:
wp core verify-checksums
La documentazione WP-CLI di wp core verify-checksums spiega che il confronto viene eseguito sui file della versione WordPress installata.
Puoi estendere il controllo alla root:
wp core verify-checksums --include-root
Questo è particolarmente utile perché può segnalare anche elementi estranei presenti nella directory principale.
Per i plugin provenienti dal repository WordPress.org è disponibile inoltre:
wp plugin verify-checksums --all
La verifica dei checksum dei plugin tramite WP-CLI permette di confrontare i file installati con quelli attesi dal repository.
Il limite va però capito bene: un checksum valido dimostra che quel file corrisponde alla versione ufficiale verificata; non dimostra che l’intero sito sia privo di compromissioni.
Inoltre plugin premium, custom e altri componenti non presenti nel repository richiedono un confronto differente.
Rimuovere malware, backdoor e meccanismi di persistenza
La bonifica non deve cercare soltanto “il file infetto”.
Un attaccante può lasciare più modi per riprendere il controllo: file aggiuntivi, utenti amministratori, modifiche al database, task pianificati o credenziali ancora valide.
Questi elementi vengono spesso chiamati meccanismi di persistenza.
Controlla wp-content, uploads, temi, plugin e mu-plugins
wp-content è la parte dell’installazione che contiene gran parte del codice e dei contenuti specifici del sito.
Qui conviene confrontare ciò che esiste con un inventario noto.
Verifica:
- plugin che non riconosci;
- directory appartenenti a plugin già rimossi;
- file modificati dentro plugin e temi;
- codice aggiunto al tema attivo;
mu-pluginsnon previsti;- file eseguibili inattesi nelle directory di upload;
- file con nomi molto simili a file legittimi;
- modifiche sospette a configurazioni o bootstrap dell’applicazione.
Non limitarti però alla ricerca di stringhe come eval, base64_decode o funzioni simili. Anche codice perfettamente legittimo può utilizzarle.
Il criterio corretto è il confronto con la versione attesa del componente e con il comportamento normale del sito.
Controlla database, utenti e attività pianificate
Una compromissione può lasciare tracce anche senza modificare direttamente il core.
Nel database controlla almeno:
- account amministratori;
- indirizzi email degli account privilegiati;
- ruoli e capability;
- opzioni modificate;
- contenuti o script iniettati;
- configurazioni di plugin;
- attività pianificate inattese.
Se trovi un amministratore sconosciuto, non limitarti a cancellarlo. Chiediti come è stato creato.
Se l’attaccante dispone ancora della vulnerabilità o della credenziale che gli ha permesso di creare quell’utente, potrà ricrearlo.
Lo stesso vale per un redirect inserito nel database: eliminare la stringa malevola risolve l’effetto visibile, non necessariamente il problema originario.
Perché eliminare il file infetto spesso non basta
Immagina di trovare una backdoor, eliminarla e ripetere una scansione.
Il sito appare pulito.
Due giorni dopo la backdoor ritorna.
La prima bonifica ha eliminato l’effetto, ma non il meccanismo che permetteva di ricrearlo.
Le cause possibili includono, per esempio:
- una vulnerabilità ancora sfruttabile;
- un plugin o tema compromesso;
- credenziali WordPress rubate;
- accessi SFTP/SSH compromessi;
- credenziali del pannello hosting;
- malware sul computer utilizzato per amministrare il sito;
- un’altra installazione compromessa nello stesso ambiente.
La guida ufficiale all’hardening di WordPress ricorda infatti che la sicurezza non riguarda soltanto WordPress: entrano in gioco anche computer, server, rete, credenziali e configurazione dell’ambiente.
Recuperare gli accessi e revocare quelli compromessi
Pulire i file lasciando valide le vecchie sessioni amministrative è un errore.
Dopo una compromissione devi assumere che gli accessi privilegiati possano essere stati esposti, almeno finché l’analisi non dimostra il contrario.
Recupera l’account amministratore se non puoi più accedere
Se le credenziali non funzionano più, parti dal normale recupero password di WordPress quando l’email associata all’account è ancora sotto il tuo controllo.
WordPress documenta diversi metodi alternativi nella guida ufficiale per reimpostare una password WordPress.
Se non hai accesso all’email ma puoi gestire il database, puoi intervenire anche tramite phpMyAdmin. Su Creativemotions trovi una procedura dedicata per resettare la password WordPress da phpMyAdmin.
Dopo aver recuperato l’account, verifica immediatamente tutti gli utenti con privilegi elevati e gli indirizzi email associati.
Cambia tutte le credenziali che possono dare accesso al sito
Non fermarti alla password di /wp-admin.
Valuta almeno:
- account amministratori WordPress;
- pannello hosting;
- SFTP/FTP;
- SSH;
- database;
- account collegati a deploy o gestione del sito;
- application password e credenziali API rilevanti.
Se cambi la password dell’utente database, ricorda che la configurazione di WordPress deve essere aggiornata di conseguenza.
Usa credenziali uniche. Riutilizzare la stessa password su più servizi rende inutile bonificare WordPress se un altro account compromesso consente di rientrare.
Invalida le sessioni WordPress e rigenera key e salt
Modificare la password non è l’unico modo per revocare accessi già attivi.
WordPress utilizza secret key e salt definite in wp-config.php per la gestione dell’autenticazione. Rigenerarle invalida le sessioni esistenti.
Con WP-CLI puoi utilizzare:
wp config shuffle-salts
Il comando è documentato ufficialmente in wp config shuffle-salts.
Dopo la rigenerazione gli utenti dovranno autenticarsi nuovamente.
Quando la situazione è tornata sotto controllo, aggiungi un secondo fattore agli account privilegiati. La guida Creativemotions sull’autenticazione a due fattori per WordPress approfondisce configurazione e vantaggi del 2FA.
Come verificare che WordPress sia davvero pulito
La verifica finale dovrebbe cercare una combinazione di segnali coerenti, non un singolo bollino verde.
Ripeti i controlli dopo la bonifica e confronta il nuovo stato con ciò che avevi trovato prima.
Ripeti scansioni e controlli di integrità
Dopo il ripristino:
- ripeti scanner interni ed esterni;
- verifica nuovamente i checksum;
- controlla gli utenti amministratori;
- verifica file e directory che erano stati modificati;
- controlla le configurazioni ripristinate;
- cerca eventuali redirect o contenuti anomali;
- ricontrolla i log.
Se avevi individuato un indicatore concreto — per esempio un file che veniva ricreato o un redirect che compariva solo da mobile — verifica espressamente che quel comportamento non si ripresenti.
Una verifica generica della homepage potrebbe non essere sufficiente.
Monitora reinfezioni e modifiche inattese
La persistenza può emergere soltanto dopo che alcune condizioni si verificano: traffico, cron, login, aggiornamenti o chiamate verso particolari URL.
Per questo, dopo la riapertura del sito, monitora le modifiche.
Non esiste un numero universale di ore o giorni dopo il quale puoi dichiarare matematicamente il sito sicuro. L’intervallo deve essere sufficiente a osservare il normale funzionamento dell’installazione e i meccanismi che avevano causato il problema.
Una scansione pulita non è una prova assoluta
Qui c’è una distinzione importante.
SCANNER NON TROVA MALWARE
non significa automaticamente:
COMPROMISSIONE RISOLTA
Un risultato pulito aumenta la confidenza solo insieme ad altre verifiche:
FILE INTEGRI + ACCESSI REVOCATI + PERSISTENZA RIMOSSA + CAUSA CORRETTA + LOG COERENTI + MONITORAGGIO
Questo è il vero criterio con cui valuterei un ripristino.
Rimuovere gli avvisi di sicurezza da Google
Se Google ha identificato contenuti compromessi, malware, phishing o altri problemi di sicurezza, controlla il report Problemi di sicurezza di Search Console.
Non confonderlo con il report Azioni manuali: sono sistemi diversi.
Controlla il report Problemi di sicurezza in Search Console
Google descrive nel proprio Security Issues report le tipologie di problemi rilevabili e la procedura per richiedere una revisione.
Prima della richiesta:
- correggi tutte le istanze conosciute;
- elimina contenuti o file compromessi;
- chiudi il punto d’ingresso individuato;
- verifica che il sito non continui a produrre il comportamento malevolo.
Non inviare la revisione dopo aver semplicemente nascosto l’URL segnalato se la compromissione è ancora presente altrove.
Richiedi la revisione soltanto dopo la bonifica completa
Dal report Problemi di sicurezza puoi richiedere una nuova valutazione quando hai corretto il problema.
Nella richiesta descrivi in modo concreto:
- quale problema hai individuato;
- cosa hai rimosso;
- quale vulnerabilità o accesso hai corretto;
- quali controlli hai eseguito;
- quali misure hai adottato per impedire il ripetersi dell’incidente.
Evita promesse sui tempi.
Google indica che una revisione può richiedere da alcuni giorni a qualche settimana, a seconda del tipo di problema.
Un altro errore da evitare è trattare il disavow dei backlink come passaggio standard dopo un hack. La bonifica di malware o spam injection e la gestione di link innaturali sono problemi differenti: non usare il disavow senza una ragione specifica legata al profilo dei link.
Evitare che il sito venga compromesso di nuovo
Una volta chiuso l’incidente, la prevenzione deve partire da ciò che hai imparato durante l’analisi.
Se la causa era una credenziale rubata, installare un firewall senza correggere gli accessi non risolve il problema.
Se la causa era un plugin vulnerabile, cambiare soltanto le password lascia invece intatto il punto d’ingresso.
La strategia deve essere legata alla causa.
Mantieni aggiornati WordPress, temi e plugin
Utilizza versioni supportate e installa gli aggiornamenti di sicurezza.
Rimuovi inoltre i componenti che non utilizzi più. Un plugin disattivato ma ancora presente sul filesystem non diventa automaticamente irrilevante dal punto di vista della superficie di attacco.
Prima di aggiungere un nuovo componente valuta:
- provenienza;
- manutenzione;
- frequenza degli aggiornamenti;
- necessità reale;
- privilegi richiesti.
Per una visione più ampia puoi utilizzare la guida Creativemotions sulla sicurezza WordPress come riferimento per l’hardening ordinario.
Backup, accessi e monitoraggio devono essere parte del sistema
I backup servono realmente quando:
- sono disponibili anche se l’hosting principale è compromesso;
- coprono sia file sia database;
- esistono più punti di ripristino;
- sai come recuperarli;
- hai verificato almeno periodicamente che il restore funzioni.
Allo stesso tempo limita i privilegi amministrativi, usa password uniche, attiva il 2FA e conserva log sufficienti a ricostruire gli eventi importanti.
Il backup ti aiuta a recuperare.
Il logging ti aiuta a capire.
Il controllo degli accessi riduce le possibilità di ingresso.
Sono funzioni differenti e complementari.
Un WAF è uno strato di difesa, non una bonifica
Un Web Application Firewall può filtrare richieste indesiderate e ridurre l’esposizione a determinate categorie di attacco.
Non può però rendere innocua una backdoor già presente nel filesystem né sostituire la correzione di un componente vulnerabile.
Se vuoi approfondire questa distinzione, nella guida al Web Application Firewall trovi il funzionamento del WAF e i limiti del controllo a livello HTTP.
Il modello corretto resta:
PREVENZIONE + CONTENIMENTO + RILEVAMENTO + RECUPERO
non:
PLUGIN DI SICUREZZA = SITO SICURO
Anche i permessi dipendono dall’ambiente server
Evita guide che assegnano un unico valore di permessi a qualunque installazione WordPress senza considerare hosting e ownership dei processi.
La configurazione corretta dipende dal server, dall’utente che esegue PHP e dal modo in cui sono gestiti file e gruppi.
WordPress fornisce linee guida generali nel proprio documento di hardening, ma specifica anche che i permessi possono variare fra gli ambienti.
L’obiettivo è evitare scrittura più ampia del necessario, non copiare numeri senza capire come funziona il server.
Quando il recupero fai-da-te diventa troppo rischioso
Il recupero manuale ha senso se puoi controllare in modo affidabile filesystem, database, accessi e ambiente hosting.
Fermati invece se:
- il malware continua a ricomparire;
- più siti risultano compromessi;
- non riesci a individuare il punto d’ingresso;
- non hai una copia affidabile dei dati;
- non sai distinguere codice custom da codice malevolo;
- il sito svolge funzioni critiche e non puoi permetterti tentativi distruttivi.
In questi casi è più prudente passare a una bonifica controllata. Creativemotions offre anche un servizio specifico di rimozione malware WordPress per analizzare, ripulire e mettere nuovamente in sicurezza installazioni compromesse.
Conclusione
WordPress hackerato non può considerarsi realmente ripristinato nel momento in cui scompare il primo file malevolo.
Il recupero può considerarsi completo quando hai ricostruito una catena coerente:
COMPROMISSIONE → CONTENIMENTO → CAUSA → BONIFICA → REVOCA ACCESSI → VERIFICA → MONITORAGGIO
Se manca la causa, rischi una reinfezione.
Se non revochi gli accessi, l’attaccante potrebbe possedere ancora una sessione o una credenziale valida.
Se non verifichi il risultato, una scansione apparentemente pulita può darti una sicurezza che non hai realmente dimostrato.
Il principio da ricordare è quindi semplice: non limitarti a togliere il malware; riporta l’installazione a uno stato noto, chiudi il meccanismo che ha permesso la compromissione e verifica che non esistano altre strade per rientrare.
Solo a quel punto ha senso tornare alla normale manutenzione e rafforzare il sito per ridurre la probabilità che lo stesso incidente si ripeta.