Bonifica malware WordPress: il metodo che usiamo davvero

Cercando online "rimuovere malware WordPress" si trovano principalmente due categorie di consigli: installare un plugin di sicurezza e aspettare che pulisca tutto, oppure ripristinare un backup e sperare che vada bene. Entrambi gli approcci, in produzione, sono insufficienti nella maggior parte dei casi.

Una bonifica fatta bene è soprattutto un esercizio di rigore. Non ci sono scorciatoie: serve un metodo, log scritti, e la disciplina di non dichiarare chiuso un caso finché non si è davvero capito da dove è entrato l'attaccante. Questo articolo descrive il metodo che applichiamo internamente, semplificato per essere leggibile.

Per riconoscere i segnali prima di arrivare alla bonifica, leggi 10 segnali che il tuo sito WordPress è compromesso. Se sei nelle prime ore dopo aver scoperto il problema, inizia da cosa fare nella prima ora. Per una lettura meno tecnica dei sintomi, parti dalla guida malware WordPress. Se il problema è già attivo su un sito reale, il percorso principale è rimozione malware WordPress e la pagina di servizio è bonifica malware WordPress.

Fase 0: contatto e prima qualifica

Prima ancora di vedere il sito, raccogliamo informazioni. Ci servono:

• URL del sito
• da quanto tempo è il problema, e cosa ha fatto pensare alla compromissione
• chi ha accesso al sito, all'hosting, al dominio
• ultima modifica intenzionale (un aggiornamento di plugin? un trasloco?)
• se esistono backup recenti utilizzabili
• se il sito vende, raccoglie lead, fa newsletter; quanto traffico ha; quanto costa una giornata di down

L'ultimo punto è critico: la priorità di un intervento spot dipende da quanto costa al cliente avere il sito compromesso o offline.

Fase 1: congelamento ed evidenze

La tentazione di pulire subito è forte, ma è una pessima idea. Una volta sovrascritto il sito, perdi le evidenze e non saprai mai com'è entrato l'attaccante. Le compromissioni che ritornano sono quasi sempre quelle in cui non si è capito il vettore di ingresso.

Quello che facciamo in concreto:

• backup completo file system (tar da SSH, escludendo cache e tmp)
• dump completo del database con mysqldump --single-transaction --quick --routines --triggers
• snapshot dei log Apache/Nginx degli ultimi 30-60 giorni
• copia dei file wp-config.php, .htaccess, php.ini se presente
• export della tabella wp_options come baseline rapida
• export utenti via WP-CLI: wp user list --format=csv

Fase 2: lettura dei log

I log dicono molto, anche quando il sito sembra muto. Cerchiamo:

• richieste POST verso file PHP non standard
• pattern di scansione su path tipo /wp-content/plugins/<plugin>/readme.txt (ricognizione versioni)
• POST con payload molto grandi su xmlrpc.php, wp-login.php, admin-ajax.php
• IP che fanno migliaia di richieste in pochi minuti
• User-Agent palesemente falsi o automatici

Su Apache, un comando come questo elenca i 20 IP più attivi:

zcat /home/site/logs/site.it.access_log.* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Spesso spiccano subito. Una variante con grep mostra POST recenti verso percorsi sensibili.

Fase 3: confronto core, temi, plugin

WordPress è open source: la versione installata è disponibile pubblicamente. Scarichiamo la stessa versione da wordpress.org, la decomprimiamo in una cartella separata, e diffiamo:

diff -r /tmp/wordpress-x.y.z/ /home/site/public_html/ \
  --exclude=wp-content --exclude=wp-config.php

Tutto quello che è "differente" nei file core è sospetto. WordPress non si tocca. Se trovi un file modificato in wp-includes/ o wp-admin/, la modifica è quasi certamente malevola.

Stesso discorso per temi e plugin. Per i plugin scarichiamo dalla repo ufficiale la stessa versione installata. I plugin commerciali si confrontano con la versione fornita dal vendor.

Quello che troviamo più spesso:

• file index.php aggiunti in cartelle plugin
• modifiche minime a wp-includes/load.php o wp-includes/post.php
• backdoor in wp-content/themes/<theme>/functions.php
• aggiunte nascoste in fondo a wp-config.php con stringhe codificate in base64 e funzioni di esecuzione dinamica
• file mai esistiti nel core (tipo wp-includes/class-wp-utility.php, oppure file PHP randomici dentro wp-content/uploads/)

Fase 4: pulizia iterativa, non distruttiva

La logica di pulizia deve essere sistematica, non pirotecnica. In ordine:

1. Sostituzione del core: cancelliamo tutto in wp-admin/, wp-includes/ e i file PHP della root (tranne wp-config.php), quindi copiamo i file dalla versione pulita.
2. Pulizia plugin: per i plugin presenti nella repo ufficiale, eliminiamo la cartella e reinstalliamo. Per i premium, sostituiamo con il pacchetto del vendor. Plugin che non si trovano da nessuna parte vanno disabilitati e analizzati.
3. Pulizia temi: lo stesso, considerando le child theme: lì potrebbe esserci codice legittimo del cliente da preservare.
4. wp-config.php: rigeneriamo la sezione SALT chiamando https://api.wordpress.org/secret-key/1.1/salt/. Riveriamo le variabili custom. Cancelliamo qualsiasi define() che non riconosciamo, dopo averne preso nota.
5. .htaccess: lo sostituiamo con la versione standard di WordPress, o lo riscriviamo manualmente preservando solo regole legittime documentate.
6. wp-content/uploads/: rimuoviamo tutti i file .php, che lì non hanno motivo di esistere. Verifichiamo a campione i file caricati di recente: a volte i file immagine contengono payload PHP nel binario.

Fase 5: pulizia del database

Il database va trattato con la stessa attenzione del file system. Operazioni tipiche:

• esportare la tabella wp_users e wp_usermeta, diffare con la baseline pre-compromissione se esiste; eliminare utenti chiaramente non legittimi
• cercare in wp_options opzioni con valori serializzati che includono codice eseguibile, decoder base64, URL sospetti, JavaScript esterno
• controllare la tabella wp_posts per articoli pubblicati con stato publish ma slug strano (spesso pagine SEO spam pubblicate massivamente)
• analizzare meta _transient_* molto pesanti che alcune backdoor usano come canali di persistenza

Fase 6: rotazione credenziali e contromisure

Una volta che il sito è pulito a livello di file e database, ruotiamo:

• password di tutti gli utenti admin
• password FTP, SSH, hosting cPanel/Plesk, database
• chiavi API di plugin che hanno accesso a servizi esterni (SMTP, Stripe, gateway pagamento, sincronizzazioni)
• token di servizi connessi (Cloudflare, S3, CDN)

Se qualcuna di queste credenziali era custodita su una macchina sospetta o in un manager non sicuro, vale la pena anche una scansione antimalware del client.

Fase 7: hardening minimo prima di rimettere online

Prima di togliere eventuali maintenance e considerare il sito di nuovo "a regime":

• aggiornare WordPress, temi e plugin all'ultima versione compatibile
• rimuovere temi e plugin non utilizzati
• disabilitare l'editor file da Bacheca
• limitare i tentativi di login
• applicare 2FA a tutti gli admin
• impostare permessi corretti (644 file, 755 cartelle, wp-config.php a 600)
• configurare alert sui log di accesso
• riattivare backup automatici verificati

Per una checklist completa delle contromisure post-bonifica, leggi hardening WordPress essenziale.

Fase 8: monitoraggio post-intervento

La fase più trascurata. Il rischio di reinfezione nelle prime due settimane è alto: spesso restano dropper minori o credenziali compromesse di cui non sapevamo. Per questo:

• monitor giornaliero su modifiche file con tool tipo aide o WP-CLI checksum
• scansione DNS/blacklist (Google Safe Browsing, MXToolbox, Spamhaus)
• verifica indicizzazione SEO via Search Console
• check periodico della lista utenti

Per i clienti in Manutenzione WordPress è automatico. Nel percorso Urgenza lo offriamo come finestra di 30 giorni inclusa quando il caso è una bonifica malware.

Riepilogo onesto

Una bonifica fatta seriamente è un lavoro di ore o giorni, non di minuti. Non è una scansione automatica né un click su "rimuovi malware". Per questo costa, e per questo dura.

Se hai un sito compromesso, richiedici una valutazione. Diamo una valutazione iniziale prima di accettare l'intervento e siamo trasparenti quando il caso è troppo grosso o troppo piccolo per il nostro intervento standard. Per capire i costi prima di contattarci, leggi quanto costa rimuovere malware da WordPress.