Quando un sito WordPress hackerato smette di funzionare, mostra contenuti strani, reindirizza verso pagine sospette o viene segnalato da Google come non sicuro, la prima reazione è spesso una: ripristinare un backup.
Il backup è uno strumento fondamentale. In molti casi permette di recuperare file, database e configurazioni precedenti al problema. Ma non sempre basta per risolvere davvero una compromissione.
Il motivo è semplice: se non si capisce come il sito è stato violato, cosa è stato modificato e quale vulnerabilità è stata sfruttata, il sito può tornare online ma restare esposto. In alcuni casi, dopo poche ore o pochi giorni, il problema può ripresentarsi.
Ripristinare un backup può essere una parte della soluzione, ma dovrebbe essere accompagnato da analisi, pulizia, aggiornamenti, controllo degli accessi, verifica dei log e messa in sicurezza dell’ambiente.
In questa guida vediamo perché il backup non basta sempre, cosa controllare dopo un attacco e come rimettere online un sito WordPress in modo più sicuro.
Cosa fare quando un sito WordPress viene hackerato
Quando un sito WordPress viene compromesso, la priorità è evitare interventi affrettati. Spegnere tutto, cancellare file o ripristinare una copia senza analizzare il problema può far perdere informazioni utili per capire cosa sia successo.
Prima di intervenire conviene raccogliere alcune informazioni:
- quando è stato rilevato il problema;
- quali pagine risultano compromesse;
- quali messaggi di errore compaiono;
- se il sito reindirizza verso domini esterni;
- se Google Search Console mostra avvisi di sicurezza;
- se ci sono utenti amministratori sospetti;
- se sono stati installati plugin o temi non riconosciuti;
- se i file sono stati modificati di recente;
- se i log mostrano accessi o richieste anomale;
- se il problema riguarda solo il sito o anche email, hosting e database.
Queste informazioni servono per distinguere un semplice errore tecnico da una compromissione reale. Un errore 500, per esempio, può dipendere da un plugin, da un aggiornamento o da una configurazione PHP. Un redirect verso siti sospetti, pagine spam indicizzate o file sconosciuti sono invece segnali più vicini a un problema di sicurezza.
Se non sai ancora se il sito sia stato realmente compromesso, può essere utile partire dalla guida sui segnali che indicano che un sito è stato hackerato.
Perché ripristinare un backup può non bastare
Il backup permette di tornare a una versione precedente del sito, ma non spiega da solo perché il sito sia stato compromesso.
Se l’attacco è avvenuto tramite un plugin vulnerabile, un tema non aggiornato, una password debole, un account amministratore compromesso o una configurazione errata, ripristinare il backup senza correggere la causa lascia il problema aperto.
In pratica, il sito può tornare apparentemente pulito ma essere ancora vulnerabile.
Questo può succedere quando:
- il backup contiene già file malevoli;
- il backup è stato creato dopo la compromissione;
- la vulnerabilità del plugin è ancora presente;
- gli utenti amministratori sospetti non vengono rimossi;
- le password non vengono cambiate;
- le chiavi di sicurezza WordPress non vengono rigenerate;
- restano backdoor nei file;
- restano script malevoli nel database;
- i permessi di file e cartelle sono troppo permissivi;
- non vengono controllati log, cron job e file modificati.
Per questo motivo il backup va considerato uno strumento di recupero, non una garanzia automatica di bonifica.
Backup pulito o backup già compromesso: come capire la differenza
Uno dei problemi più delicati riguarda la data del backup. Per essere davvero utile, una copia deve essere precedente alla compromissione. Ma non sempre è facile stabilire quando l’attacco sia iniziato.
Un sito può essere stato compromesso giorni o settimane prima che il problema diventi evidente. Per esempio, un file malevolo può restare nascosto per un periodo, oppure alcune pagine spam possono essere create senza che il proprietario del sito se ne accorga subito.
Prima di ripristinare è utile chiedersi:
- quando sono comparsi i primi sintomi;
- quando sono stati modificati i file sospetti;
- quando Google ha rilevato eventuali problemi di sicurezza;
- quando sono stati creati utenti o plugin sospetti;
- quali backup sono disponibili;
- se il database contiene contenuti spam o link sospetti;
- se i log mostrano accessi anomali prima della data del backup.
Se si ripristina un backup già infetto, il sito può sembrare recuperato solo in parte. Alcuni file possono tornare al loro posto, ma la backdoor o il codice malevolo possono essere ancora presenti.
Per questo è importante non ragionare solo in termini di “backup più recente”, ma di “backup sicuramente pulito”.
Malware nei file, nel database e negli utenti admin
Un sito WordPress hackerato non viene sempre compromesso nello stesso punto. Il problema può trovarsi nei file, nel database, negli utenti, nei plugin, nei temi o nella configurazione del server.
Nei file possono comparire:
- script PHP sconosciuti;
- file caricati in cartelle insolite;
- codice offuscato;
- modifiche a file di tema o plugin;
- alterazioni del file .htaccess;
- file con nomi simili a quelli legittimi;
- backdoor pensate per rientrare nel sito dopo la pulizia.
Nel database possono invece comparire:
- link spam nei contenuti;
- script inseriti in post, pagine o widget;
- opzioni WordPress alterate;
- redirect salvati in tabelle del sito;
- utenti amministratori non riconosciuti;
- contenuti generati automaticamente;
- record sospetti creati da plugin compromessi.
Anche gli utenti amministratori vanno controllati con attenzione. Un account admin creato dall’attaccante può permettere di modificare di nuovo il sito anche dopo il ripristino dei file.
Questa è una delle ragioni per cui la bonifica non dovrebbe limitarsi al caricamento di una vecchia copia del sito.
Plugin vulnerabili, temi obsoleti e accessi compromessi
WordPress è un ecosistema composto da core, plugin, temi, configurazioni e account. Una compromissione può dipendere da uno qualunque di questi elementi.
Le cause più comuni includono:
- plugin non aggiornati;
- temi obsoleti;
- plugin abbandonati dallo sviluppatore;
- estensioni scaricate da fonti non affidabili;
- password deboli;
- account amministratori condivisi;
- accessi FTP o hosting compromessi;
- mancanza di autenticazione a due fattori;
- permessi errati su file e cartelle;
- versioni obsolete di PHP o WordPress.
Se il problema nasce da un plugin vulnerabile, ripristinare un backup ma lasciare installata la stessa versione del plugin significa esporre di nuovo il sito allo stesso rischio.
Lo stesso vale per temi non aggiornati, credenziali rubate o account amministratori mai rimossi.
Dopo il ripristino è quindi necessario aggiornare WordPress, plugin e temi, eliminare ciò che non serve, verificare gli utenti e controllare che le credenziali siano state sostituite.
Perché il sito può essere infettato di nuovo dopo il ripristino
Un sito può essere infettato di nuovo quando la causa dell’attacco non viene rimossa. Questo è uno dei casi più frustranti: il sito torna online, sembra funzionare, poi dopo qualche tempo mostra di nuovo gli stessi sintomi.
Le cause possono essere diverse:
- backdoor ancora presenti nei file;
- plugin vulnerabile non aggiornato;
- tema compromesso;
- utente admin sospetto ancora attivo;
- password non cambiate;
- chiavi di sicurezza WordPress non rigenerate;
- file .htaccess modificato;
- script malevoli nel database;
- cron job o attività programmate alterate;
- accessi FTP o pannello hosting compromessi.
In questi casi il backup ha risolto solo il sintomo visibile, non la causa tecnica.
Per evitare una nuova infezione bisogna trattare il ripristino come una fase del processo, non come la fine del lavoro.
Log del server e controlli tecnici dopo un attacco
I log del server possono essere molto utili per capire cosa sia successo. Non sempre permettono di ricostruire tutto, ma possono mostrare accessi sospetti, richieste anomale, errori ripetuti o tentativi di esecuzione di file insoliti.
Dopo una compromissione conviene controllare:
- access log;
- error log;
- log PHP;
- log del pannello hosting;
- log FTP o SFTP, se disponibili;
- log del database;
- eventuali log del plugin di sicurezza;
- modifiche recenti ai file;
- richieste verso file sconosciuti;
- tentativi ripetuti verso wp-login.php o XML-RPC.
Questi controlli aiutano a capire se l’attacco è avvenuto tramite login, upload, plugin vulnerabile, file modificato, richiesta automatizzata o altra via.
Se vuoi approfondire questo aspetto, puoi leggere anche la guida sui log del server.
Google, blacklist e avvisi di sicurezza
Un sito compromesso può avere conseguenze anche sulla visibilità e sulla reputazione. Se Google rileva contenuti dannosi, pagine spam, phishing o comportamenti sospetti, può mostrare avvisi agli utenti o segnalare problemi in Search Console.
In questi casi non basta rimuovere il malware dal sito. Bisogna anche verificare quali URL sono state coinvolte, controllare eventuali pagine indicizzate, correggere il problema e richiedere una revisione quando necessario.
Gli elementi da controllare includono:
- se Search Console mostra problemi di sicurezza;
- quali URL risultano compromesse;
- se esistono pagine spam create dall’attaccante;
- se ci sono redirect sospetti;
- se la sitemap contiene URL anomale;
- se Google ha indicizzato pagine non riconosciute;
- se il sito mostra avvisi nel browser;
- se sono presenti file o script dannosi;
- se il problema è stato corretto su tutte le pagine coinvolte;
- se è necessario richiedere una validazione.
La documentazione Google Search Console sui problemi di sicurezza indica che il report può mostrare problemi come contenuti compromessi, malware o social engineering e può essere usato per verificare gli interventi dopo la correzione.
Backup off-site e copie separate dal server principale
Un altro punto importante riguarda dove vengono conservati i backup. Salvare tutte le copie nello stesso server o nello stesso spazio hosting può essere comodo, ma non sempre è sufficiente.
Se il server viene compromesso, se lo spazio si riempie o se i backup locali vengono cancellati o alterati, avere copie separate può fare la differenza.
Una strategia più ordinata dovrebbe prevedere:
- backup regolari;
- più punti di ripristino;
- copie conservate fuori dal server principale;
- verifica periodica del ripristino;
- separazione tra ambiente di produzione e copie di sicurezza;
- controllo dello spazio disponibile;
- regole di conservazione chiare;
- protezione degli accessi al sistema di backup.
Per questo motivo, in alcuni casi può avere senso usare uno storage remoto per conservare le copie di sicurezza. Uno spazio separato, come un Cloud Object Storage compatibile S3, può essere usato come destinazione esterna per backup, archivi e file importanti.
Non basta però avere un backup: bisogna anche sapere da quando è disponibile, cosa contiene, se è pulito e come ripristinarlo correttamente.
Come rimettere online il sito in modo più sicuro
Rimettere online un sito WordPress dopo un attacco richiede ordine. Ogni caso è diverso, ma una procedura corretta dovrebbe includere almeno alcune verifiche di base.
Un possibile flusso di lavoro è:
- mettere il sito in manutenzione o limitarne l’accesso, se necessario;
- raccogliere informazioni su sintomi, date e pagine coinvolte;
- verificare file modificati, utenti, plugin e database;
- controllare log del server e accessi sospetti;
- identificare un backup precedente alla compromissione;
- ripristinare file e database solo da copie affidabili;
- aggiornare WordPress, plugin, temi e versione PHP;
- rimuovere plugin, temi e utenti non necessari;
- cambiare password di WordPress, hosting, FTP, database e pannelli collegati;
- rigenerare le chiavi di sicurezza WordPress;
- verificare il file .htaccess e altri file di configurazione;
- controllare eventuali cron job o automazioni sospette;
- scansionare file e database;
- verificare Search Console e richiedere eventuale validazione;
- monitorare il sito nei giorni successivi.
Questo approccio richiede più tempo rispetto a un semplice ripristino, ma riduce il rischio di rimettere online un sito ancora vulnerabile.
Per rafforzare il sito dopo la bonifica, può essere utile approfondire anche il tema dell’hardening WordPress.
Quando chiedere supporto tecnico
Un sito hackerato non è sempre semplice da gestire in autonomia. Se il sito è aziendale, riceve ordini, genera lead, gestisce dati dei clienti o ha impatto sulla reputazione del brand, conviene evitare interventi casuali.
È consigliabile chiedere supporto tecnico quando:
- non sai da quando il sito è compromesso;
- non sai quale backup sia pulito;
- il sito viene reinfettato dopo il ripristino;
- compaiono redirect o pagine spam;
- Google segnala problemi di sicurezza;
- non riesci ad accedere alla dashboard WordPress;
- ci sono file PHP sospetti;
- il database contiene codice o link anomali;
- gli utenti amministratori non sono chiari;
- hai bisogno di ripristinare il sito senza perdere dati recenti.
In questi casi il lavoro non riguarda solo WordPress, ma anche hosting, backup, log, DNS, posta, database e sicurezza degli accessi.
Conclusioni
Un sito WordPress hackerato non si risolve sempre con un semplice ripristino del backup. Il backup è importante, ma deve essere inserito in una procedura più ampia: capire cosa è successo, scegliere una copia pulita, rimuovere eventuali backdoor, aggiornare componenti vulnerabili e mettere in sicurezza gli accessi.
Se la causa della compromissione resta presente, il sito può essere infettato di nuovo anche dopo il ripristino.
La soluzione corretta è combinare recupero, analisi tecnica, hardening, controllo dei log e strategia di backup più ordinata. Solo così il sito può tornare online con maggiore affidabilità.
Se il tuo sito WordPress è stato compromesso o vuoi verificare backup, log, plugin, accessi e configurazioni di sicurezza, HostingPerTe può aiutarti ad analizzare il problema e scegliere la soluzione più adatta.
