WordPress hackerato senza backup: cosa si può recuperare?

Un WordPress hackerato senza backup pulito può essere recuperabile, ma non si può promettere il ripristino di dati che non esistono più. Se database, media e personalizzazioni sono ancora disponibili, si può valutare una ricostruzione con componenti originali e dati verificati. Occorre prima capire che cosa è rimasto integro.

Il passaggio iniziale è conservare lo stato attuale, anche se infetto. Reinstallare o ripristinare alla cieca può distruggere le ultime copie di contenuti, ordini ed evidenze.

Non confondere assenza di backup e assenza di dati

“Non ho un backup” può significare che non hai un plugin dedicato, che non sai dove siano le copie o che nessuna copia sia stata verificata. Prima di iniziare chiedi al provider:

• se esistono snapshot o backup dell'account e quali date coprono;
• se file e database appartengono allo stesso momento;
• se sono disponibili copie precedenti alla prima evidenza dell'incidente;
• se è possibile estrarle in un ambiente separato;
• quali verifiche di integrità e ripristino sono state eseguite.

Un backup recente potrebbe essere già compromesso. Una copia precedente al sintomo visibile non è automaticamente precedente all'ingresso dell'attaccante. La guida al ripristino dopo un hack affronta questa scelta; qui consideriamo il caso in cui non emerga una copia pulita utilizzabile.

1. Metti al sicuro quello che esiste oggi

Conserva una copia di file, database, configurazione e log disponibili. Verifica che gli archivi si aprano e che l'esportazione del database sia terminata correttamente. Tieni la copia fuori dall'area pubblica del sito e limitane l'accesso.

La documentazione WordPress sui backup distingue file e database: conservare soltanto uno dei due lascia scoperta una parte del sito.

Questa copia è una base per l'indagine e per tornare indietro da una modifica fallita. Non va riattivata in produzione come se fosse pulita. Prima di operazioni distruttive occorre sapere che cosa si sta conservando e come recuperarlo.

Se il sito è un negozio, annota anche l'ultimo ordine verificato e le operazioni ancora in corso. Non fare transazioni di prova con clienti reali.

2. Separa ciò che puoi riscaricare dai dati unici

Il core WordPress e i componenti commerciali o del repository possono spesso essere reperiti dai rispettivi distributori ufficiali. Contenuti aziendali, fotografie originali e codice personalizzato potrebbero invece non avere altre copie.

Prepara un inventario in tre gruppi:

1. Componenti riproducibili: core, plugin e temi con versione e sorgente ufficiale identificate.
2. Dati da preservare e verificare: database, media, configurazioni, ordini e integrazioni.
3. Personalizzazioni uniche: child theme, plugin sviluppati su misura e modifiche non versionate.

Registra per ogni elemento la sorgente disponibile e il livello di verifica. Non sovrascrivere un tema personalizzato con il pacchetto standard senza prima capire quali modifiche contenga.

Se trovi componenti senza licenza o scaricati da fonti non affidabili, procurati gli originali o valuta una sostituzione controllata. La guida ai plugin nulled spiega perché copiarli nel sito ricostruito conserva un rischio.

3. Ricostruisci in un ambiente separato

Prepara un ambiente non pubblico e isola email, pagamenti, webhook e credenziali di produzione. Importare un sito infetto in un normale staging può attivare codice e chiamate esterne: segui la procedura di staging per la bonifica.

Recupera i pacchetti originali dalle fonti autorizzate. Per quelli esistenti, i checksum del core e i checksum dei plugin del repository aiutano a individuare differenze rispetto alle versioni ufficiali. Non coprono tutti i componenti premium o personalizzati e non verificano il database.

Sostituire i file noti non equivale a eliminare file aggiuntivi: questi vanno inventariati e valutati. Controlla anche configurazione, regole del server, plugin obbligatori e cartelle dei media.

Scegli una versione supportata e verifica la compatibilità. Aggiornamenti che modificano lo schema del database richiedono una copia e un percorso di ritorno prima di essere provati.

4. Analizza il database senza cancellare la storia del sito

Il database può contenere sia dati aziendali validi sia contenuti o configurazioni alterati. Non è sufficiente eliminare gli articoli con un titolo strano.

Controlla utenti e privilegi, contenuti pubblicati e bozze, opzioni, snippet gestiti da plugin, URL delle integrazioni e attività pianificate. Per gli account consulta la guida agli admin sconosciuti.

Evita sostituzioni SQL globali non verificate. Alcuni valori sono serializzati e una modifica superficiale può renderli inutilizzabili. Lavora su copie, conserva un elenco delle modifiche e confronta i risultati.

Su WooCommerce gli ordini possono usare strutture differenti secondo la configurazione. Non presumere che sia sufficiente salvare soltanto la tabella dei post. Coinvolgi chi conosce il negozio e verifica ordini, clienti, inventario e integrazioni con il primo soccorso per WooCommerce compromesso.

5. Verifica media e personalizzazioni

Recupera i media necessari, controllandone contenuto e percorsi. La guida ai file PHP in uploads descrive la valutazione degli eseguibili inattesi. Non trasferire l'intera cartella senza verifiche e non cancellarla in blocco.

Per le personalizzazioni cerca repository Git, copie dell'agenzia e pacchetti consegnati dal precedente sviluppatore. Se l'unica copia è quella compromessa, serve una revisione del codice: chiamarla “originale” non la rende affidabile.

Le copie cache e i risultati di ricerca possono aiutare a ricostruire qualche testo pubblico, ma non sono backup completi. Non permettono di recuperare automaticamente dati privati, ordini cancellati o funzioni del sito.

Se un dato è stato eliminato e non esistono copie recuperabili, il limite va comunicato prima della pubblicazione. Distinguere recupero tecnico e ricostruzione manuale evita aspettative sbagliate.

6. Chiudi la causa e pianifica il ritorno online

Prima del passaggio in produzione correggi i punti d'ingresso verificati, rimuovi accessi non autorizzati e revoca i segreti esposti. Se il punto d'ingresso non è determinabile dai log disponibili, scrivilo nel report; non inventare un'attribuzione.

Concorda il momento del passaggio e la gestione delle modifiche intervenute nel frattempo. Per un negozio può essere necessario sospendere temporaneamente nuove operazioni e riconciliare gli ordini: pubblicare una copia vecchia senza questa verifica può perdere dati validi.

Il controllo finale dovrebbe includere:

• pagine e media rappresentativi, anche fuori dal login;
• accessi autorizzati, moduli e recapito delle notifiche;
• funzioni commerciali e integrazioni in ambiente di prova;
• assenza delle evidenze malevole individuate;
• percorsi spam eliminati, sitemap e risposte HTTP coerenti;
• backup del nuovo stato e prova di ripristino separata.

La FAQ ufficiale di WordPress sui siti hackerati offre il contesto generale di risposta all'incidente. Il nostro servizio di bonifica malware può valutare il recupero e documentare ciò che è stato verificato e ciò che resta incerto.