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.

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

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 continuativa è automatico. Per gli interventi spot lo offriamo come finestra di 30 giorni inclusa nel pacchetto Bonifica & Hardening.

Riepilogo onesto

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

Se hai un sito compromesso, scrivici. 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.