La chiamata: cosa ci ha detto il cliente
A febbraio 2026 abbiamo ricevuto una chiamata da un'azienda di Casalnuovo di Napoli, Raicar.it, e-commerce di ricambi auto. Il sito aveva iniziato a comportarsi in modo strano: reindirizzamenti improvvisi verso siti esterni, pagine che non esistevano indicizzate su Google, e un avviso di sicurezza che era comparso nei risultati di ricerca.
La richiesta iniziale era semplice: "Ripristinate il sito su Aruba come era prima." Il cliente pensava bastasse un ripristino da backup per tornare alla normalità. Abbiamo dovuto spiegare perché quella non era una soluzione — era solo un cerotto su un problema più profondo.
Reindirizzamenti strani, pagine fantasma, avvisi di Google: questi sono sintomi visibili. Il problema reale è quasi sempre più profondo — file PHP modificati, backdoor nascoste, credenziali compromesse. Ripristinare l'aspetto del sito senza affrontare la causa significa ritrovarsi nello stesso problema entro giorni.
La diagnosi: cosa abbiamo trovato davvero
Prima di toccare qualsiasi file, abbiamo fatto un'analisi completa del sito e del server. Quello che abbiamo trovato era più grave di quanto il cliente immaginasse:
- Backdoor multiple attive — file PHP camuffati da file di sistema che permettevano accesso remoto non autorizzato, sparsi in diverse cartelle del sito
- Plugin obsoleti con vulnerabilità note — alcuni plugin non erano aggiornati da oltre un anno, con CVE (vulnerabilità documentate pubblicamente) già note e sfruttate
- Credenziali amministratore compromesse — probabile accesso diretto al pannello WordPress con credenziali deboli o rubate
- Codice malevolo iniettato nel database — script che generavano i reindirizzamenti automatici verso siti esterni
Questo livello di compromissione significava una cosa: il problema non era "il sito sembra rotto" — era "qualcuno ha accesso completo al sito da tempo indeterminato".
Perché un semplice ripristino non basta
Abbiamo spiegato al cliente perché ripristinare un backup, da solo, sarebbe stato inutile — anzi controproducente:
Il backup potrebbe già contenere la falla
Se le backdoor erano presenti da settimane o mesi, è probabile che siano presenti anche nei backup più recenti. Ripristinare significa semplicemente riportare online lo stesso problema.
Le credenziali compromesse restano compromesse
Un ripristino non cambia le password. Se l'attaccante ha le credenziali, può rientrare nel giro di ore — indipendentemente da quale versione del sito è online.
Il vecchio hosting Aruba aveva limiti di sicurezza
L'hosting condiviso del cliente non offriva strumenti avanzati di monitoraggio e protezione. Anche risolvendo il problema immediato, l'infrastruttura sottostante rimaneva vulnerabile a nuovi attacchi.
Una reinstallazione completa e pulita di WordPress, partendo da zero per il codice mentre recuperavamo solo i dati legittimi (prodotti, ordini, contenuti) dopo averli verificati e sanificati. Più una protezione perimetrale con Cloudflare per filtrare il traffico malevolo residuo.
L'intervento: bonifica in 20 giorni, zero downtime
Una volta ottenuto il via libera dal cliente, abbiamo lavorato in parallelo: mentre il vecchio sito (compromesso) restava online sul vecchio hosting per non interrompere le vendite, costruivamo la versione pulita su un ambiente separato e sicuro.
Il processo è durato 20 giorni e ha incluso:
- Reinstallazione completa di WordPress, tema e plugin da fonti ufficiali verificate
- Recupero e sanificazione del database — estrazione di prodotti, ordini e contenuti legittimi, verificando ogni riga di codice sospetto
- Aggiornamento di tutti i plugin alle versioni più recenti e sicure
- Implementazione di autenticazione a due fattori per l'accesso amministrativo
- Test completo di funzionalità e-commerce prima della messa online
- Switch DNS pianificato per evitare interruzioni del servizio
Il passaggio dal vecchio sito compromesso al nuovo sito pulito è avvenuto senza alcuna interruzione del servizio per i clienti di Raicar.it. Le vendite online non si sono mai fermate durante tutto il processo di bonifica.
Cloudflare: la protezione che mancava
Una volta online il sito pulito, abbiamo configurato Cloudflare come livello di protezione perimetrale. Questo serviva a due scopi: filtrare il traffico malevolo residuo che ancora tentava di raggiungere il vecchio indirizzo, e fornire una protezione DDoS e firewall applicativo per il futuro.
Cloudflare ha permesso di bloccare automaticamente i tentativi di accesso sospetti, le scansioni automatizzate di vulnerabilità e i bot malevoli — riducendo drasticamente la superficie di attacco del sito.
Il risultato e la decisione del cliente
Il cliente, soddisfatto del risultato, ha deciso di non tornare al vecchio hosting Aruba. Ha trasferito il sito sui server gestiti da Nexta Studio, con un contratto di assistenza mensile che include monitoraggio continuo, aggiornamenti regolari e backup automatici.
I numeri finali dell'intervento:
| Metrica | Risultato |
|---|---|
| Downtime durante la migrazione | 0 minuti |
| Dati recuperati | 100% (prodotti, ordini, contenuti) |
| Tempo di bonifica completa | 20 giorni |
| PageSpeed dopo l'intervento | 95+/100 |
Cosa fare se il tuo sito è stato hackerato
Se ti trovi nella stessa situazione del cliente di Raicar.it, ecco i passi corretti da seguire, in ordine:
- Metti il sito offline o in manutenzione per evitare ulteriori danni e blacklist da Google
- Cambia tutte le password immediatamente — hosting, WordPress, FTP, database, email collegate
- Non ripristinare subito un backup senza prima capire come è entrato l'attaccante
- Fai una diagnosi completa di file, database e plugin per identificare tutte le backdoor
- Valuta una reinstallazione pulita invece di una semplice pulizia, se la compromissione è estesa
- Richiedi la revisione a Google Search Console una volta bonificato, per rimuovere l'avviso di sicurezza
- Implementa un firewall applicativo come Cloudflare per il futuro
Come prevenire un attacco in futuro
La bonifica costa tempo e denaro. La prevenzione costa molto meno. Le misure essenziali per evitare di trovarsi nella stessa situazione:
- Aggiornamenti costanti di WordPress, tema e tutti i plugin — la maggior parte degli attacchi sfrutta vulnerabilità note già corrette nelle versioni più recenti
- Autenticazione a due fattori per tutti gli account amministrativi
- Backup automatici regolari salvati su un server diverso da quello principale
- Limitazione dei tentativi di login per bloccare gli attacchi brute force
- Rimozione di plugin e temi inutilizzati — ogni componente installato è una superficie di attacco potenziale
- Un piano di assistenza WordPress attivo con monitoraggio continuo, non solo intervento quando qualcosa va storto
Domande frequenti
Il mio sito WordPress è stato hackerato, cosa devo fare subito?
Per prima cosa, metti il sito in modalità manutenzione o offline temporaneamente per evitare ulteriori danni e blacklist da parte di Google. Poi cambia immediatamente tutte le password. Non limitarti a ripristinare un backup senza prima capire come è entrato l'attaccante.
Basta ripristinare un backup per risolvere un sito hackerato?
No, quasi mai. Se il backup risale a un periodo in cui la vulnerabilità era già presente, l'attaccante può rientrare nello stesso modo. È necessario identificare e chiudere la falla prima di ripristinare qualsiasi backup.
Quanto tempo ci vuole per bonificare un sito WordPress hackerato?
Dipende dalla gravità. Per interventi con backdoor multiple e necessità di reinstallazione completa, i tempi tipici sono 1-3 settimane. Il caso reale di Raicar.it a Casalnuovo di Napoli ha richiesto 20 giorni con zero downtime per il cliente.
Google penalizza un sito che è stato hackerato?
Sì, se Google rileva malware può inserire il sito in blacklist con un avviso di sicurezza nei risultati di ricerca, con impatto drastico sul traffico. È fondamentale richiedere una revisione tramite Google Search Console una volta completata la bonifica.
Siamo a Casalnuovo di Napoli.