WordPress hackerato: guida completa al recupero del sito

Recuperare un sito WordPress hackerato richiede una sequenza precisa: prima blocchi l'emorragia, poi raccogli le prove, poi pulisci, poi chiudi il vettore, poi hai rimedi finali. Saltare un passo - soprattutto la chiusura del vettore di ingresso - porta quasi sempre alla recidiva. Questa guida copre l'intero percorso dall'inizio alla fine.

Un sito WordPress compromesso non si risolve con un click su "scansiona e pulisci" in un plugin di sicurezza. Non si risolve nemmeno ripristinando un backup senza prima capire come è entrato l'attaccante. Questa guida mappa l'intero processo di recupero, dalla scoperta del problema al ritorno online in condizioni di sicurezza verificata.

Se sei nelle primissime ore dopo la scoperta, inizia da cosa fare nella prima ora. Se vuoi capire il metodo che usiamo internamente su interventi professionali, leggi bonifica malware WordPress: il metodo.

---

Fase 1: conferma la compromissione

Prima di iniziare qualsiasi intervento, conferma che si tratti davvero di un hack e non di un malfunzionamento tecnico o di una configurazione sbagliata.

Controlli rapidi da fare subito:

• Apri il sito in modalità incognita da browser desktop e da browser mobile. Un redirect che compare solo da mobile o da Google è quasi sempre malware.
• Cerca su Google site:tuodominio.it e controlla i risultati. Pagine di scommesse, farmaci, contenuti in giapponese o cinese indicano spam SEO attivo.
• Controlla Google Search Console nella sezione "Sicurezza e azioni manuali". Google spesso rileva il malware prima del proprietario.
• Verifica su Google Safe Browsing: https://transparencyreport.google.com/safe-browsing/search?url=tuodominio.it
• Controlla la lista utenti admin in Bacheca > Utenti: utenti sconosciuti sono un segnale forte.

Se trovi più di uno di questi segnali, tratta il caso come compromissione attiva e vai alla fase successiva senza perdere tempo.

---

Fase 2: blocca l'accesso immediato

Prima di pulire, limita i danni in corso. Queste azioni non risolvono il problema ma lo contengono:

Metti il sito in modalità manutenzione: non cancellare il sito, non spegnerlo. Attiva una pagina di manutenzione per non esporre i visitatori al malware attivo. La maggior parte dei plugin di sicurezza e dei page builder ha questa funzione.

Cambia tutte le password amministrative subito: WordPress admin di tutti gli utenti, pannello hosting (cPanel/Plesk), FTP/SFTP, database. Se l'attaccante ha ancora credenziali valide, ogni altro intervento è inutile.

Rigenera i SALT di WordPress: da WP-CLI:

wp config shuffle-salts

Questo invalida tutte le sessioni attive, inclusa quella dell'attaccante se era loggato.

Sospendi i cron job: alcuni malware usano i cron WordPress per rieseguirsi a intervalli regolari. Sospenderli temporaneamente riduce l'attività malevola:

wp cron event list --format=table

Cerca eventi con nomi sospetti o non riconoscibili.

---

Fase 3: crea il backup come evidenza

Prima di toccare qualsiasi file, crea una copia completa dello stato attuale. Sembra controintuitivo fare il backup di un sito compromesso, ma serve per:

• avere le prove di cosa è successo (utile in caso di data breach e notifiche GDPR)
• poter confrontare file dopo la pulizia
• ricostruire lo storico delle modifiche

# Backup file system (escludi cache e tmp)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/uploads/cache' \
    -czf /tmp/backup-compromesso-$(date +%Y%m%d).tar.gz /home/sito/public_html/

# Dump database
mysqldump --single-transaction --quick --routines --triggers \
  nome_database > /tmp/db-compromessa-$(date +%Y%m%d).sql

Trasferisci questo backup su storage esterno, non sullo stesso server.

---

Fase 4: analizza i log

I log di accesso dicono dove è entrato l'attaccante e quando. Su Apache/Nginx, cerca:

• richieste POST verso file PHP non standard (specialmente in wp-content/uploads/)
• pattern di scansione su path di plugin specifici
• IP che hanno fatto molte richieste in breve tempo
• User-Agent automatici o palesemente falsi

# IP più attivi nelle ultime settimane
cat /home/sito/logs/*.access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# POST verso path sospetti
grep "POST" /home/sito/logs/*.access_log | grep "uploads\|xmlrpc\|wp-login" | tail -50

Se il log mostra richieste POST verso un file in wp-content/uploads/, quel file è quasi certamente una webshell: è il punto di ingresso principale.

---

Fase 5: trova e rimuovi il malware

File system

Inizia dai punti più frequenti:

File PHP in wp-content/uploads (non ci dovrebbero essere):

find wp-content/uploads -name "*.php" -type f

File modificati di recente nel core (WordPress core non si modifica):

find wp-admin wp-includes -name "*.php" -newer wp-login.php -type f

File PHP con nomi casuali in tutta l'installazione:

find . -name "*.php" -type f -mtime -30 \
  -not -path "./wp-content/cache/*" \
  -not -path "./.git/*" | head -30

Per confrontare il core con la versione pulita:

# Scarica la stessa versione di WordPress
wp core verify-checksums

Questo comando confronta i file core con i checksum ufficiali e segnala differenze.

Database

Cerca nelle tabelle principali:

-- Codice base64 in wp_options (tipica tecnica di offuscamento)
SELECT option_name, LENGTH(option_value) as len
FROM wp_options
WHERE option_value LIKE '%base64_decode%'
OR option_value LIKE '%gzinflate%'
OR option_value LIKE '%str_rot13%'
ORDER BY len DESC;

-- URL sospetti in wp_options
SELECT option_name, option_value FROM wp_options
WHERE option_value LIKE '%http%'
AND option_name NOT IN ('siteurl','home','blogdescription','blogname')
AND option_value LIKE '%<script%';

-- Articoli pubblicati con slug sospetti (spam SEO)
SELECT post_title, post_name, post_status, post_date
FROM wp_posts
WHERE post_status = 'publish'
AND post_date > DATE_SUB(NOW(), INTERVAL 90 DAY)
ORDER BY post_date DESC;

---

Fase 6: pulizia sistematica

La pulizia non è cancellare file a caso. È sostituire i componenti compromessi con versioni pulite verificate.

Core WordPress: sostituisci l'intero core con la versione pulita. Da WP-CLI:

wp core download --version=$(wp core version) --force

Plugin: rimuovi e reinstalla ogni plugin dalla repo ufficiale. Per i plugin premium, scarica dal sito del vendor:

wp plugin delete nome-plugin
wp plugin install nome-plugin --activate

Temi: sostituisci con versioni pulite. Attenzione ai child theme: possono contenere codice legittimo personalizzato che va preservato - esaminalo prima di sovrascrivere.

wp-config.php: controlla riga per riga. Rimuovi qualsiasi define() non riconosciuto, qualsiasi include di file sconosciuto, qualsiasi blocco di codice che non ricordi di aver messo.

.htaccess: sostituisci con la versione standard di WordPress, aggiungendo solo regole legittime documentate.

wp-content/uploads: rimuovi tutti i file .php. Controlla i file caricati di recente per payload nascosti in immagini.

---

Fase 7: identifica e chiudi il vettore di ingresso

Questo è il passo più critico. Se non capisci come è entrato l'attaccante, il sito verrà ricompromesso.

Vettori più comuni:

Plugin vulnerabile: controlla la versione di ogni plugin installato contro il database delle vulnerabilità note su WPScan o Patchstack. Se trovi un plugin con CVE che permette accesso non autorizzato, aggiornalo o rimuovilo.

Credenziali rubate: se i log mostrano login riusciti da IP stranieri con credenziali esistenti, le password erano deboli o rubate. Tutte le credenziali vanno ruotate (vedi fase 8).

Plugin o tema nulled: un plugin nulled contiene backdoor by design. Rimuovilo completamente e acquista la licenza originale. La guida plugin nulled: cosa rischi descrive i rischi in dettaglio.

Hosting condiviso: a volte la compromissione arriva da un altro sito sullo stesso account o sullo stesso server. Chiedi al tuo provider se ci sono stati incidenti sull'infrastruttura.

File rimasti da installazioni precedenti: plugin o temi rimossi ma con file residui sul file system possono essere usati come punto di ingresso.

---

Fase 8: rotazione credenziali completa

Dopo la pulizia, tratta tutte le credenziali come compromesse:

• Cambia password di tutti gli utenti WordPress admin
• Cambia password FTP/SFTP
• Cambia password database
• Cambia password cPanel/pannello hosting
• Rigenera chiavi API di servizi connessi: SMTP, gateway pagamento, Cloudflare, S3, CDN
• Rigenera i SALT WordPress se non lo hai già fatto nella fase 2

Se hai usato un client potenzialmente compromesso per accedere al sito, fai una scansione antimalware del computer.

---

Fase 9: hardening prima di tornare online

Prima di togliere la pagina di manutenzione e dichiarare il sito operativo:

• Aggiorna WordPress, tutti i plugin e i temi all'ultima versione compatibile
• Rimuovi plugin e temi non utilizzati (anche solo installati)
• Disabilita l'editor file da Bacheca (aggiunge define('DISALLOW_FILE_EDIT', true) a wp-config.php)
• Abilita 2FA per tutti gli admin (plugin WP 2FA gratuito)
• Imposta permessi corretti: file 644, cartelle 755, wp-config.php 600
• Verifica che i backup automatici siano attivi e configurati su storage esterno
• Controlla gli header HTTP di sicurezza

Per una checklist completa dell'hardening, leggi hardening WordPress essenziale.

---

Fase 10: ripristino reputazione

Dopo la bonifica tecnica, ci sono passi esterni da completare:

Google Search Console: se Google aveva rilevato malware, vai nella sezione "Sicurezza e azioni manuali" e richiedi una revisione. Inviala solo dopo che la bonifica e completa: Google ri-scansiona il sito e se trova ancora problemi nega la revisione.

Google Safe Browsing: dopo la revisione approvata, l'avviso scompare tipicamente entro 24-72 ore. Il processo non è automatico: serve la richiesta da Search Console.

Blacklist email: se il dominio e finito in blacklist per spam, usa MXToolbox per verificare in quali liste sei presente. Alcune richiedono una richiesta manuale di rimozione, altre si aggiornano automaticamente.

SEO spam: se sono state create pagine spam indicizzate, rimuovile dal server e usa lo strumento "Rimozione URL" di Search Console per accelerare la deindicizzazione. Poi invia una nuova sitemap.

---

Fase 11: monitoraggio post-bonifica

Il rischio di recidiva nelle prime due settimane e alto. Monitora:

• Modifiche ai file con WP-CLI: wp core verify-checksums && wp plugin verify-checksums --all
• Lista utenti admin ogni giorno per la prima settimana
• Log di accesso WordPress per login da IP sconosciuti
• Uptime e risposta del sito (UptimeRobot o simile)
• Google Search Console per nuovi problemi di sicurezza

Se nei primi 30 giorni il problema ritorna, c'è ancora una backdoor attiva che non è stata trovata. In quel caso serve un'analisi più approfondita.

---

Quando affidarsi a un tecnico

Questo percorso e fattibile in autonomia su casi semplici con buon accesso SSH. In questi casi il consiglio e affidarsi a uno specialista:

• Il sito è un WooCommerce con ordini e dati cliente
• La bonifica e stata fatta ma il problema è tornato
• L'hosting e sospeso e serve un report per la riattivazione
• Google ha attivato un'azione manuale sul sito
• Non hai accesso SSH o non sei sicuro di cosa stai guardando

WPsec.it gestisce interventi di bonifica con analisi root cause, staging, garanzia 30 giorni e coordinamento con hosting e Google. Richiedi una valutazione.

---