Sito WordPress hackerato: cosa fare nella prima ora

Se scopri che il tuo sito WordPress è hackerato, la prima mossa non è cancellare file sospetti né installare un plugin di sicurezza. È documentare, creare una copia di tutto e capire cosa è successo prima di toccare qualsiasi cosa. Le azioni sbagliate nella prima ora possono cancellare prove, rendere impossibile trovare il vettore di ingresso e aumentare il rischio di reinfezione entro giorni.

Quando scopri che un sito WordPress è hackerato, la tentazione è agire subito: cancellare file strani, disattivare plugin, ripristinare un backup. Tutte operazioni che sembrano risolutive ma che spesso peggiorano la situazione o la rimandano.

La prima ora non serve a risolvere. Serve a non fare danni e a raccogliere tutto quello che serve per risolverlo correttamente.

Se ti serve una sintesi operativa prima di seguire la checklist completa, usa la pagina sito WordPress hackerato. Quando i sintomi sono confermati, il percorso tecnico passa dalla rimozione malware WordPress.

Cosa stai vedendo? Riconosci il tipo di attacco

Prima di qualsiasi azione, cerca di capire con cosa hai a che fare. I sintomi cambiano in base al tipo di compromissione, e il tipo di attacco determina dove cercare e cosa prioritizzare.

Redirect verso siti esterni (casinò, farmaci, pagine adult, phishing): il codice malevolo può essere in .htaccess, in un plugin, nel tema, in wp-config.php, nelle mu-plugins o direttamente nel database. Spesso il redirect è condizionato: appare solo da mobile, solo per chi arriva da Google, solo per utenti non loggati. L'amministratore non lo vede. Per verificarlo dall'esterno:

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -L https://example.com | head -50
curl -s -e "https://www.google.com" -L https://example.com | head -50

Se il primo o il secondo comando mostra una risposta diversa dal sito normale, il redirect è confermato. Leggi l'approfondimento su WordPress redirect spam: cosa fare quando il sito reindirizza altrove.

Pagine spam indicizzate su Google (farmaci, scommesse, contenuti irrilevanti): il database è quasi certamente coinvolto. Cerca su Google site:tuodominio.it e analizza le pagine indicizzate. Questo tipo di attacco, noto come WordPress pharma hack, inietta contenuto nel database e nelle opzioni WordPress.

Avviso Google Safe Browsing ("sito ingannevole" o "software dannoso"): Google ha rilevato malware o contenuti di phishing nelle ultime scansioni. Il sito è già segnalato. Dopo la bonifica serve inviare una richiesta di revisione a Google Search Console. Approfondisci la rimozione della blacklist Google per WordPress.

Admin sconosciuti o utenti con ruoli modificati: le credenziali di accesso admin sono quasi certamente compromesse. Può essere avvenuta una SQL injection, un accesso tramite credenziali rubate o un plugin vulnerabile che ha creato utenti automaticamente.

File PHP in cartelle impreviste: webshell o backdoor. Le trovi spesso in wp-content/uploads/, wp-content/cache/ o come file con nomi randomici nella root. Questi file permettono all'attaccante di eseguire comandi sul server anche dopo che hai rimosso il malware visibile.

Sospensione dell'hosting: il provider ha rilevato malware, spam o abuso di risorse e ha bloccato l'account. Leggi hosting sospeso per malware WordPress: cosa fare prima di chiedere la riattivazione.

Puoi avere più sintomi insieme. Un sito può avere redirect, backdoor nel database e file PHP iniettati contemporaneamente - spesso sono il risultato dello stesso vettore di ingresso sfruttato in momenti diversi.

Per un elenco completo dei segnali da monitorare, leggi 10 segnali che il tuo sito WordPress è compromesso.

---

Passo 1: documenta tutto prima di toccare qualcosa

Prima di fare qualsiasi modifica al sito, raccogli evidenze. Questa fase richiede 10-15 minuti e può fare la differenza tra trovare la causa e lavorare al buio.

Screenshot e URL: cattura schermate di ogni anomalia visibile. Annota gli URL esatti delle pagine problematiche, i messaggi di errore, i redirect che vedi (anche parziali). Se hai accesso alla Search Console, fai screenshot delle coperture e degli avvisi.

Log di accesso del server: i log Apache o Nginx registrano ogni richiesta al server con IP, user-agent, timestamp e URL richiesto. Sono la fonte primaria per ricostruire come e quando è avvenuto l'attacco. Se hai SSH:

# Log Apache (percorso tipico su hosting cPanel)
tail -200 /home/tuoaccount/access-logs/tuodominio.it
grep -i "POST\|\.php" /home/tuoaccount/access-logs/tuodominio.it | tail -100

# Log Nginx
tail -200 /var/log/nginx/access.log
grep "POST" /var/log/nginx/access.log | tail -100

Se non hai SSH, chiedi al provider di inviarti i log degli ultimi 30 giorni prima di fare qualsiasi intervento. Alcuni provider li cancellano dopo la sospensione.

Email dal provider: se hai ricevuto email dall'hosting con segnalazioni di abuso o malware, conservale e leggile attentamente. Spesso indicano il file specifico o il tipo di problema rilevato.

Verifica Search Console: controlla le sezioni "Sicurezza e azioni manuali" e "Copertura". Se Google ha già rilevato il problema, troverai indicazioni utili sul tipo di contenuto o codice malevolo.

---

Passo 2: crea una copia completa prima di tutto il resto

Non toccare nulla fino a quando non hai una copia completa del sito, sia file che database. Anche se il sito è infetto, quella copia è essenziale per:

• Analizzare il malware senza rischiare di rimuovere prove utili
• Confrontare file attuali con versioni precedenti
• Avere un punto di ripristino se qualcosa va storto durante la bonifica

Da SSH (il metodo più affidabile):

# Copia completa dei file in un archivio datato
tar -czf /tmp/backup-$(date +%Y%m%d-%H%M).tar.gz /home/tuoaccount/public_html/

# Export del database
mysqldump -u utente_db -p nome_database > /tmp/db-backup-$(date +%Y%m%d-%H%M).sql

# Comprimi anche il database
gzip /tmp/db-backup-*.sql

Scarica subito questi file tramite SFTP o SCP. Non lasciarli solo sul server.

Da cPanel senza SSH: usa la funzione "Backup" o "JetBackup" per generare un backup completo di file e database. Scaricalo prima di procedere.

Senza accesso al pannello (hosting sospeso): contatta il provider e chiedi esplicitamente l'accesso temporaneo per scaricare i file, anche solo in lettura. Molti provider lo concedono per permettere la bonifica. Se non è possibile, chiedi almeno il database e i log.

Un punto importante: se hai già un backup recente pre-compromissione (da ieri, da 3 giorni fa), tienilo separato e non sovrascriverlo. Potresti averne bisogno per il confronto.

---

Passo 3: raccogli tutti gli accessi necessari

La bonifica richiede accessi multipli. Non avere uno di questi rallenta o blocca l'intervento.

Accesso	Perché serve
Admin WordPress	Verificare utenti, plugin, impostazioni
Pannello hosting (cPanel, Plesk)	File manager, log, database, email
FTP o SFTP	Accesso diretto ai file quando WP è rotto
SSH	Comandi, log, backup, analisi forense
phpMyAdmin o MySQL CLI	Database: opzioni, utenti, contenuto iniettato
Google Search Console	Avvisi sicurezza, copertura, richiesta revisione
Cloudflare o DNS provider	Verificare redirect a livello DNS, WAF

Se non hai le credenziali SSH o FTP, cercale in email passate, nel pannello hosting, o chiedi a chi ha configurato il server. Senza accesso ai file via SSH o SFTP non si può fare una bonifica seria.

Importante: se sospetti che le credenziali siano state compromesse (admin WordPress non funziona, FTP cambiato, email di reset che non arrivano), non ruotare le password finché non hai creato il backup. Una password cambiata può bloccare l'accesso dell'attaccante ma anche impedire di vedere cosa sta succedendo in quel momento. Dopo il backup, ruota tutto: credenziali WordPress, FTP, database, e aggiorna i SALT in wp-config.php.

---

Passo 4: decidi se mettere il sito in manutenzione

Non tutti i casi richiedono di spegnere il sito subito. La decisione dipende dal tipo di attacco e dal contesto.

Metti offline immediatamente se:

• Il sito serve malware attivo verso i visitatori (rilevato da Safe Browsing o scanner esterno)
• Il sito reindirizza gli utenti a phishing o pagine di raccolta dati
• Il sito è usato per inviare spam (il provider ti ha segnalato abuso SMTP)
• Il sito è un WooCommerce con dati di pagamento potenzialmente esposti

Puoi continuare a lavorare con il sito live se:

• Il problema è spam SEO nel database (non visibile ai visitatori normali)
• I file malevoli sono stati isolati e non sono in esecuzione
• Il sito non serve dati sensibili

Per WooCommerce: la valutazione va fatta caso per caso. Spegnere il sito ferma gli ordini e può avere un impatto economico immediato. Ma lasciare online un WooCommerce con dati clienti esposti o checkout compromesso è peggio. Se hai dubbi, la modalità manutenzione con una pagina statica è la soluzione di compromesso: il sito non serve traffico, ma l'URL è raggiungibile per le verifiche.

Per attivare la manutenzione senza plugin da SSH:

# Crea file .maintenance nella root WordPress
echo '<?php $upgrading = time(); ?>' > /home/tuoaccount/public_html/.maintenance

WordPress mostrerà automaticamente la pagina di manutenzione. Rimuovi il file quando hai finito.

---

Passo 5: lavora su staging, non sul live

Se il sito è ancora accessibile e non stai servendo malware attivo, la pratica migliore è spostare l'intervento su una copia isolata: staging o ambiente di test.

Perché lo staging è importante:

• Puoi analizzare e pulire senza toccare l'unico ambiente live
• Puoi testare ogni modifica prima di applicarla in produzione
• Se qualcosa va storto durante la bonifica (un plugin rotto, un update che rompe il layout), non impatti il sito reale
• Preservi evidenze forensi: sul live potresti cancellare accidentalmente file utili all'analisi
• Per WooCommerce, puoi verificare che il checkout funzioni correttamente prima del ritorno live

Come creare uno staging veloce:

Se il provider ha strumenti integrati (WP Engine, Kinsta, SiteGround): usa la funzione staging dedicata. Crea la copia in pochi clic.

Se non hai strumenti automatici, puoi usare WP-CLI da SSH:

# Duplica i file in una sottocartella
cp -r /home/account/public_html/ /home/account/staging/

# Crea un database separato per lo staging
mysql -u root -p -e "CREATE DATABASE staging_db; GRANT ALL ON staging_db.* TO 'utente'@'localhost';"

# Esporta e importa il database
mysqldump -u utente -p production_db | mysql -u utente -p staging_db

Poi aggiorna wp-config.php nella copia staging con le credenziali del nuovo database e blocca l'accesso esterno con un .htaccess che permette solo il tuo IP.

Lo staging non è obbligatorio per siti semplici, ma per WooCommerce o siti con traffico significativo è quasi sempre la scelta giusta.

---

Passo 6: costruisci la timeline dell'attacco

Prima di iniziare la bonifica vera e propria, cerca di capire quando è successo e attraverso quale via. Una timeline anche parziale riduce enormemente il tempo necessario per trovare tutti i file coinvolti.

File modificati di recente: cerca i file PHP modificati negli ultimi 30 giorni che non dovrebbero essere stati toccati:

# File PHP modificati negli ultimi 30 giorni, esclusi cache
find /home/account/public_html/ -name "*.php" -mtime -30 \
  -not -path "*/cache/*" \
  -not -path "*/wp-content/uploads/cache/*" \
  | sort -t/ -k6

# File in uploads (non dovrebbero esserci PHP)
find /home/account/public_html/wp-content/uploads/ -name "*.php"

# File con nomi casuali (pattern tipico di webshell)
find /home/account/public_html/ -name "*.php" | grep -E "[a-z0-9]{8,}\.php"

Richieste POST sospette nei log: la maggior parte degli attacchi usa richieste POST per caricare file o eseguire codice. Cerca nei log richieste POST verso file che normalmente non le ricevono:

grep "POST" /home/account/access-logs/tuodominio.it | \
  grep -v "wp-login\|wp-cron\|wp-admin\|xmlrpc\|checkout\|cart" | \
  awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Accessi wp-login.php anomali: picchi di tentativi di login indicano brute force o credential stuffing:

grep "wp-login.php" /home/account/access-logs/tuodominio.it | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Cronologia plugin e aggiornamenti: controlla la tabella wp_options nel database per recently_activated e verifica la lista dei plugin installati, inclusi quelli disattivati. Un plugin installato e subito disattivato è un segnale d'allarme.

Annota tutto in un documento: data del primo file modificato, IP che ha fatto richieste anomale, plugin installati nelle ultime settimane, accessi strani alla dashboard. Questa timeline è la base per la bonifica.

---

Gli errori più comuni nella prima ora

Dopo aver gestito centinaia di compromissioni WordPress, questi sono gli errori che vediamo più spesso e che complicano la bonifica:

Ripristinare un backup senza analizzare il vettore: il backup riporta online il sito com'era prima, ma se la vulnerabilità che ha permesso l'attacco è ancora presente (plugin non patchato, password debole, configurazione errata), il sito viene ricompromesso entro ore o giorni. Il ripristino da backup non è una bonifica - è solo una pulizia temporanea.

Installare Wordfence e "scannerizzare": Wordfence è uno strumento utile per monitoraggio e firewall, ma la sua scansione si basa su pattern noti e non trova malware custom, backdoor nel database o codice offuscato in modo non standard. Una scansione "verde" non significa sito pulito.

Cancellare file sospetti uno per uno: ogni file PHP sospetto che trovi non è necessariamente l'unico. Le backdoor si installano in più punti simultaneamente. Rimuovere un file senza analizzare la catena di infezione lascia quasi sempre qualcosa dietro.

Cambiare solo la password admin: le credenziali WordPress sono raramente il vettore primario di attacco. Cambiare la password non risolve un'infezione da file, una SQL injection nel database o un plugin con vulnerabilità nota.

Lavorare direttamente sul live senza backup: qualsiasi operazione fatta senza copia preventiva è ad alto rischio. Un'eliminazione sbagliata, un'operazione database andata male o un aggiornamento che rompe il sito possono rendere irrecuperabile quello che era ancora recuperabile.

---

Dopo la prima ora: il passo successivo

Una volta che hai documentato i sintomi, creato il backup, raccolto gli accessi e costruito la timeline, sei pronto per la bonifica vera e propria.

La bonifica richiede analisi sistematica di file, database, plugin, tema, utenti, configurazione hosting e log. Il processo corretto è documentato in dettaglio in bonifica malware WordPress: il metodo che usiamo davvero.

Se preferisci affidarti a un tecnico, la pagina sito WordPress hackerato spiega come funziona il nostro intervento: staging quando possibile, analisi root cause, hardening post-bonifica e monitoraggio 30 giorni. Per capire i costi, leggi quanto costa rimuovere malware da WordPress.

---