Ripristinare un backup dopo un hack: quando è la scelta sbagliata
Il ripristino del backup è il primo consiglio che ricevi dopo un hack. Nella maggior parte dei casi reali è la decisione più costosa. Ecco quando funziona, quando no, e come farlo senza reinfettare il sito.
Dopo aver scoperto un sito WordPress infetto, il consiglio più diffuso online è anche il più pericoloso: "ripristina un backup pulito e sei a posto". Sembra logico. È quasi sempre sbagliato come primo passo.
La frase che riassume il problema è questa: il backup riporta il sito al passato, ma non dice nulla sul presente. Se l'attaccante ha ancora una porta aperta, il sito appena ripristinato viene ricompromesso in ore o giorni, e tu non saprai mai né come né quando.
Perché il ripristino sembra funzionare e poi non funziona
Un sito WordPress compromesso raramente ha un solo file malevole. Ha quasi sempre:
- una backdoor persistente: un file PHP nascosto (o un utente amministratore, o un task pianificato) che permette di rientrare anche dopo la pulizia visibile
- più punti di iniezione: plugin vulnerabile, tema obsoleto, credenziali rubate, un account FTP compromesso
- contaminazione del database: link spam nelle tabelle, utenti admin sconosciuti, script iniettati negli option value
Se ripristini un backup di due settimane prima, elimini i file infetti che vedi oggi. Non elimini la causa. Tre scenari tipici che vediamo ogni settimana:
| Scenario | Cosa succede dopo il ripristino |
|---|---|
| Backup posteriore all'ingresso dell'attaccante | Reinfezione immediata o entro pochi giorni, spesso con lo stesso malware |
| Vettore d'ingresso ancora attivo (plugin vulnerabile non aggiornato) | Reinfette cicliche, ogni volta tramite lo stesso buco |
| Password e chiavi non ruotate dopo il ripristino | L'attaccante rientra con le credenziali rubate, anche senza backdoor |
Nel terzo scenario c'è un dettaglio che quasi tutti dimenticano: le salt keys di wp-config.php. Se un attaccante ha letto il tuo wp-config, possiede i cookie di sessione firmati con quelle chiavi. Ripristinare il database senza rigenerare le salt keys significa lasciare valide le sessioni autenticate dell'attaccante.
I costi nascosti del ripristino
Il secondo problema è meno tecnico e più economico. Un ripristino riporta il sito indietro nel tempo:
- ordini e iscrizioni persi: su un WooCommerce, tutto ciò che è accaduto dopo il punto di backup sparisce
- articoli e pagine cancellati: il lavoro editoriale degli ultimi giorni o settimane va rifatto
- SEO danneggiata: se Google aveva già indicizzato pagine spam create dall'attaccante, il ripristino lascia errori 404 o, peggio, redirect residui
- evidenze forensi distrutte: sovrascrivendo il sito, non saprai mai da dove è entrato l'attaccante. E un vettore non identificato è un vettore ancora aperto
Quest'ultimo punto merita una precisazione: una compromissione che ritorna è quasi sempre una compromissione di cui non si è mai capito il vettore d'ingresso. Il ripristino senza analisi trasforma un incidente in un ciclo infinito.
Quando invece il ripristino è la scelta giusta
Non stiamo dicendo che il backup sia inutile: è l'asset più importante che hai. Il punto è l'ordine delle operazioni. Il ripristino è corretto quando:
- hai la certezza documentata che il backup è anteriore all'ingresso dell'attaccante (lo deduci dai log, dalla data della prima modifica sospetta, dalla data di creazione dei file infetti)
- hai chiuso il vettore: aggiornato o disattivato il plugin/tema responsabile, corretto la configurazione, isolato l'account compromesso
- hai preparato il post-ripristino: nuove salt keys, tutte le password ruotate (database, admin WordPress, FTP, SSH), utenti amministratori verificati uno a uno
In questo ordine, il ripristino è l'operazione di bonifica più rapida ed efficace che esista. Fuori da questo ordine, è una lotteria.
La procedura corretta, passo per passo
Se vuoi fare le cose per bene da solo, la sequenza è questa:
- Congela e documenta prima di toccare nulla: backup completo di file e database dello stato attuale (infetto), copia dei log di accesso degli ultimi 30-60 giorni. Questo materiale serve a capire l'ingresso e a proteggerti in caso di contestazioni.
- Identifica il vettore: cerca nei log richieste POST anomale verso file PHP non standard, controlla gli utenti admin, confronta il core con
wp core verify-checksums. - Prepara l'ambiente pulito: preferibilmente su staging, aggiorna core, plugin e temi all'ultima versione disponibile.
- Ripristina il backup, poi applica immediatamente: nuove salt keys in wp-config, revisione di ogni utente amministratore, verifica checksum del core.
- Ruota ogni credenziale: database, amministratori WordPress, FTP/SFTP, API keys dei servizi collegati (payment gateway, SMTP, CDN).
- Monitoraggio intensivo per 30 giorni: file integrity check giornaliero e lettura settimanale dei log. Una reinfezione intercettata al giorno 3 costa poco; intercettata al giorno 60 costa la seconda bonifica.
La domanda giusta non è "ho un backup?"
La domanda giusta è: so con certezza da quando sono infetto, e ho chiuso il buco?
Se la risposta è sì, il ripristino è la strada più veloce. Se è no, il ripristino è una scommessa in cui giochi contro un avversario che conosce il tuo sito meglio di te, almeno finché non hai letto i suoi stessi movimenti nei log.
Per il metodo completo che applichiamo, con le fasi di congelamento, analisi log e sostituzione del core, leggi la guida sulla bonifica malware WordPress passo per passo. Se il sito è già infetto e devi agire ora, la pagina di servizio dedicata è rimozione malware WordPress, mentre qui trovi cosa fare nella prima ora dopo aver scoperto il problema e come riconoscere i segnali di un sito compromesso.
Posso ripristinare un backup se non so quando è avvenuta la compromissione?
Tecnicamente sì, ma è un azzardo. Senza una data certa di ingresso non puoi sapere se il backup è pulito. La data di modifica dei file infetti aiuta, ma gli attaccanti falsificano i timestamp. I log di accesso restano la fonte più affidabile.
Il mio hosting mi ha detto di ripristinare il backup automatico. Lo faccio?
I backup giornalieri automatici degli hosting coprono in genere solo le ultime 24-48 ore: se la compromissione è più vecchia, quel backup contiene il malware. Inoltre il ripristino dell'hosting non include l'analisi del vettore. Valutalo solo insieme a un'analisi dei log.
Devo tenere il backup infetto dopo la bonifica?
Sì, almeno 90 giorni, in un storage separato dal sito. Serve come riferimento per capire cosa è stato modificato, per confronti forensi e come evidenza in caso di contestazioni legali o richieste dell'hosting.
Quanto tempo passa prima che un sito si reinfetti dopo un ripristino sbagliato?
Nei casi che gestiamo, da poche ore a due settimane. Le reinfezioni immediate indicano backdoor nel database o cron compromessi; quelle ritardate indicano credenziali rubate usate manualmente dall'attaccante.
Scritto dal team WPsec.it
Team WPsec.it
Bonifica malware, hardening, performance e manutenzione WordPress.
Guide per sintomo
Il tuo sito ha un sintomo preciso? Parti dalla guida giusta.
Ogni compromissione WordPress lascia segnali diversi. Queste guide spiegano cosa fare nelle prime ore, cosa non toccare e quando serve una bonifica con analisi del vettore d'ingresso.
- Sito WordPress hackerato
- Malware WordPress: sintomi e cause
- Rimozione malware WordPress
- Redirect spam da mobile
- Pharma hack
- Japanese keyword hack
- Hosting sospeso per malware
- Google segnala sito ingannevole
- Google Ads blocca il sito
- Protezione DDoS
- Audit di sicurezza
- Servizio bonifica malware
- Analisi forense
- Prezzi e garanzia
Continua a leggere
Articoli correlati.
Sito WordPress hackerato: cosa fare nella prima ora
Guida tecnica per la prima ora dopo una compromissione WordPress: cosa documentare, come creare un backup utile per l'analisi, quali accessi raccogliere e gli errori che rendono la bonifica impossibile.
WordPress hackerato: guida al recupero del sito in 11 fasi
Recuperare un sito WordPress hackerato in 11 fasi: dalla conferma alla bonifica, dalla chiusura del vettore all'hardening finale. Sequenza operativa con comandi e checklist.
Sito pulito non è sito sicuro: la differenza tra rimozione e bonifica
Togliere i file infetti e bonificare un sito sono due operazioni diverse, con esiti opposti nel tempo. Come funziona la catena ingresso-persistenza-obiettivo di un attacco WordPress, e perché solo la visione completa evita le reinfette.