WordPress hackerato: guida al recupero del sito in 11 fasi

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

Niente panico: un sito compromesso è una situazione comune e si recupera. Quello che NON funziona è cliccare "scansiona e pulisci" in un plugin di sicurezza o ripristinare un backup senza capire come è entrato l'attaccante. Questa guida mappa l'intero processo, 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 o dalla sintesi sito WordPress hackerato. Se vuoi capire il metodo che usiamo internamente su interventi professionali, leggi bonifica malware WordPress: il metodo e la pagina pillar su rimozione malware WordPress.

---

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 inatteso solo da mobile o da Google richiede di controllare codice, regole di redirect e script esterni; conserva la prova prima di attribuirne la causa.
• Cerca su Google site:tuodominio.it e controlla i risultati. Pagine non autorizzate di scommesse, farmaci o contenuti in altre lingue sono un segnale di possibile spam SEO. Verifica se gli URL restituiscono ancora quei contenuti: il risultato Google può essere rimasto da prima della pulizia.
• Controlla Google Search Console nella sezione "Sicurezza e azioni manuali". Google spesso rileva il malware prima del proprietario.
• Verifica su Google Safe Browsing: strumento di verifica Safe Browsing
• Controlla la lista utenti admin in Bacheca > Utenti: utenti sconosciuti sono un segnale forte. Vedi utenti admin sconosciuti.

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:

Contieni il comportamento dannoso: chiedi al provider una pagina statica temporanea o una limitazione mirata dell’accesso al sito coinvolto. Un plugin di manutenzione dentro WordPress compromesso può non intercettare tutti i percorsi. Su hosting condiviso, limita l’intervento al tuo sito senza interrompere servizi usati da altri.

Conserva le prove prima delle modifiche: raccogli timestamp, avvisi del provider e una copia verificata come nella fase 3. Se un accesso rubato è usato in quel momento, il contenimento urgente ha precedenza: registra quale account hai revocato e quando. Coordina i cambi di password con le integrazioni per non interromperle.

Invalida le sessioni quando necessario: dopo la copia di wp-config.php, la rotazione dei SALT disconnette le sessioni basate sui cookie di WordPress. Il comando modifica la configurazione:

wp config shuffle-salts

Questa azione non revoca da sola password applicative, accessi SFTP o token di altri servizi, che vanno verificati separatamente.

Elenca gli eventi pianificati: questo comando legge gli eventi WP-Cron, senza sospenderli. Se sospetti che il codice sia compromesso, preferisci l’analisi su una copia isolata: WP-CLI può caricare componenti del sito.

wp cron event list --format=table

Attribuisci gli hook ai componenti che li registrano; un nome sconosciuto non prova che sia malware. Controlla anche i cron del pannello hosting. Prima di sospendere un evento verifica le conseguenze su ordini, email e backup. Riferimento WP-CLI: cron event list.

---

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 i file dopo la pulizia
• ricostruire lo storico delle modifiche

# Esempio: adatta percorso e database, usa autenticazione già configurata.
# La cartella privata è esterna alla document root.
umask 077
incident_backup=$(mktemp -d /tmp/wp-incident.XXXXXX)
tar -czf "$incident_backup/files.tar.gz" /srv/www/example.com/
gzip -t "$incident_backup/files.tar.gz"
tar -tzf "$incident_backup/files.tar.gz" >/dev/null

mysqldump --single-transaction --quick --routines --triggers \
  nome_database > "$incident_backup/database.sql"
# Verifica exit code 0 del dump e presenza del marcatore finale:
grep -- '-- Dump completed' "$incident_backup/database.sql"

Controlla che tutti i comandi abbiano completato senza errori prima di procedere. Il marcatore finale e il controllo gzip non sostituiscono una prova di ripristino su ambiente isolato. Conserva anche log, file nascosti e configurazioni esterne alla document root. Trasferisci la copia su storage protetto con accessi separati; contiene dati e credenziali del sito e non deve essere pubblicamente scaricabile.

---

Fase 4: analizza i log

I log di accesso aiutano a ricostruire richieste e tempi. Possono essere incompleti o già ruotati: il vettore di ingresso può restare non determinabile. 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

Una POST verso un file in wp-content/uploads/ è una pista da verificare insieme al contenuto del file, alla risposta HTTP e al componente che lo ha creato. Da sola non dimostra una webshell né identifica la vulnerabilità iniziale.

---

Fase 5: trova e rimuovi il malware

File system

Inizia dai punti più frequenti:

File PHP in wp-content/uploads (da attribuire e analizzare; alcuni plugin creano file legittimi):

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:

wp core verify-checksums

Questo comando confronta i file core con i checksum ufficiali e segnala differenze. Una differenza richiede analisi; un esito corretto non verifica plugin, database e configurazioni. Puoi interpretare i nomi delle rilevazioni nel catalogo delle firme malware.

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: su copia verificata o staging, confronta e sostituisci i file compromessi con il pacchetto ufficiale della versione corretta. Il seguente comando sovrascrive file: richiede backup verificato e controllo delle personalizzazioni. Non elimina automaticamente file aggiunti dall’attaccante:

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

Plugin: conserva versione, impostazioni e personalizzazioni prima di sostituire un componente compromesso. Usa pacchetti verificati dal repository ufficiale o dal produttore per i plugin premium. Prova la versione corretta su staging e verifica le funzioni del sito; una cancellazione indiscriminata può interrompere integrazioni e dati.

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

wp-config.php: conserva una copia e confronta riga per riga con la configurazione documentata. Attribuisci costanti e include a hosting o componenti autorizzati. Rimuovi soltanto codice accertato come malevolo: non riconoscere una direttiva non è una prova.

.htaccess: conserva e verifica redirect e regole prima di modificarli. Mantieni le direttive legittime del provider, cache e autenticazione; verifica la risposta HTTP dopo ogni modifica mirata.

wp-content/uploads: inventaria i file PHP e verifica origine e contenuto. Quarantena e rimozione riguardano i payload confermati, dopo il backup; non tutti i file PHP sono automaticamente malware. Controlla anche file nascosti ed estensioni inattese.

---