Un sito WordPress hackerato si riconosce spesso da sintomi lontani dalla causa. In questo caso, un sito di un’agenzia immobiliare pubblicava spam su casinò e scommesse da oltre un mese. La causa era un account amministratore compromesso, non una falla del core di WordPress: con quell’accesso l’attaccante aveva installato plugin falsi, una backdoor nella cartella mu-plugins e una password applicativa per pubblicare via API. L’articolo ricostruisce la cronologia, i controlli usati, gli interventi e i punti ancora aperti. Il cliente è anonimo. Il servizio corrispondente è il recupero di un sito WordPress hackerato.
I numeri del sito WordPress hackerato
| Numero | Cosa significa |
|---|---|
| 66 | articoli spam pubblicati con l’account compromesso dal 25 agosto, su 69 pubblicati nello stesso periodo. |
| 25+ | cartelle di plugin e temi falsi, molte con nome numerico basato sul timestamp. |
| 1 | backdoor nella cartella mu-plugins, presente dal 28 luglio e invisibile nell’elenco plugin. |
| 17.700 | richieste POST su xmlrpc.php nel solo mese di settembre. |
| 235 | articoli spam spostati nel cestino di WordPress, compresi quelli tolti a mano. |
| 15 | plugin aggiornati dopo la bonifica, con un secondo backup a lavori finiti. |
La causa è un accesso amministrativo rubato. Resta aperta una domanda: come sono state ottenute le credenziali. Lo diciamo subito perché è la parte più importante del caso.
La cronologia dell’intrusione, ricostruita da file e log
I segni dell’intrusione non stavano in un unico posto. Le date dei file, i log del server e le tabelle del database hanno permesso di ricostruire una sequenza lunga mesi.
| Data (2026) | Evento | Come si è visto |
|---|---|---|
| 24 giugno, 8 agosto | Prime cartelle di plugin e temi sospette | Date di modifica in wp-content |
| 28 luglio | Creato un file da 36 KB in mu-plugins, con un nome che richiama quello di un noto servizio di sicurezza | Data del file |
| 5 agosto | Creata una password applicativa sull’utente compromesso | Tabella dei metadati utente |
| 25 agosto | Iniziano gli articoli spam: 66 su 69 sono dell’utente compromesso | Query sul database |
| 31 agosto, 16:09–17:54 UTC | Installazioni di plugin da più indirizzi IP, tramite wp-admin/update.php | Log di accesso: sessione amministrativa autenticata |
| 31 agosto, 23:47 | Primo articolo spam via API REST (POST /wp-json/wp/v2/posts, risposta 201) | Log di accesso |
| 29 settembre | Ultimo uso della password applicativa | Metadati della password applicativa |
| 3 ottobre | Ultimo articolo spam, poi la bonifica | Database |
Come si trova una backdoor in un sito WordPress hackerato
Prima di toccare qualsiasi cosa: backup completo dell’account. Poi analisi in sola lettura, nell’ordine in cui i segnali sono più affidabili.
Utenti e password applicative
Elenco degli amministratori (wp user list --role=administrator) e delle password applicative di ciascuno (wp user application-password list). Qui la password “fantasma” era creata dal 5 agosto.
File ordinati per data
Le cartelle di plugin e temi creati in finestre strette di tempo sono il segno di un’installazione automatica. Il core si verifica con wp core verify-checksums, i plugin con wp plugin verify-checksums --all.
La cartella mu-plugins
I plugin must-use vengono caricati sempre e non compaiono nella schermata dei plugin. Un file lì dentro che nessuno ricorda di aver messo va letto riga per riga.
Log di accesso del server
Richieste POST a update.php e all’API REST, indirizzi IP, orari. Servono a distinguere un login normale dalla sessione usata per installare i componenti falsi.
Database con sole letture
Query di tipo SELECT su articoli, utenti e opzioni: chi ha scritto cosa e quando. Nessuna modifica finché il quadro non è chiaro.
Cosa abbiamo fatto, in modo reversibile
Regola del lavoro: si sposta, non si cancella. Tutti i componenti sospetti sono finiti in una cartella di quarantena fuori dal sito, con la possibilità di rimetterli al loro posto.
Backup prima
Backup completo prima delle modifiche e secondo backup a bonifica e aggiornamenti conclusi.
Quarantena
Più di 25 cartelle tra plugin e temi falsi, la backdoor, 8 temi predefiniti e 8 plugin inattivi.
Accessi chiusi
Revocata la password applicativa, disconnesse le sessioni dell’utente compromesso, attivati firewall e scansione.
Aggiornamenti
15 plugin aggiornati. Il blocco delle modifiche ai file (DISALLOW_FILE_MODS) è stato tolto solo per il tempo necessario e rimesso a true.
Contenuti
Articoli spam nel cestino: reversibile. La cancellazione definitiva spetta al titolare, dopo un controllo.
Report
Ogni intervento con dove è stato fatto e come tornare indietro. Si può verificare, non basta fidarsi.
Una pulizia senza password cambiate è una pausa, non una soluzione.
Le domande rimaste aperte nel caso
Un buon report dichiara i limiti. Al momento della consegna restavano aperti questi punti.
Come sono state rubate le credenziali. Non c’è una prova. L’ipotesi più probabile è una phishing o una password riutilizzata altrove; non è stata dimostrata. Il brute force su xmlrpc.php era costante, ma non c’è evidenza che sia andato a buon fine.
Gli altri account. Sei utenti, tutti amministratori. Uno compromesso con prove dirette, due da considerare a rischio per inferenza, tre a rischio basso. WordPress non registra l’ultimo accesso: senza un plugin di audit, non c’è modo di dire chi sia entrato.
Utenti cancellati in passato. Cinque ID mancano nell’elenco: erano account creati e poi rimossi. Non si può più sapere chi fossero.
Il database. I file sono stati ripuliti; il database no, oltre agli articoli. Dopo il cambio password vanno riguardati utenti, opzioni e pianificazioni.
Dopo la bonifica: l’indice di Google e gli URL spam
Gli articoli spam nel cestino restituiscono un 404, ma restano nell’indice finché Google non li ricontrolla. Ci sono due strade complementari: segnalare gli URL con lo strumento di rimozione di Search Console e lasciare che il 404 faccia il resto. Va anche controllata la sezione Azioni manuali. La documentazione di Google sui siti hackerati descrive il percorso. Un caso come questo può non ricevere alcuna azione manuale: si verifica, non si presume.
Checklist per un sito WordPress hackerato
| Passo | Cosa fare |
|---|---|
| 1 | Backup completo di file e database prima di modificare qualsiasi cosa |
| 2 | Elenco degli utenti amministratori e delle loro password applicative |
| 3 | Controllo di mu-plugins, plugin e temi per data di creazione e checksum |
| 4 | Lettura dei log di accesso: POST su update.php, API REST, xmlrpc.php |
| 5 | Quarantena dei componenti sospetti, senza cancellare |
| 6 | Revoca delle password applicative e disconnessione delle sessioni |
| 7 | Nuove password per WordPress, hosting, FTP e database; chiavi di sicurezza rigenerate |
| 8 | Autenticazione a due fattori sugli amministratori e riduzione del loro numero |
| 9 | Aggiornamento di core, plugin e temi; rimozione di ciò che non serve |
| 10 | Search Console: URL spam, azioni manuali, eventuale richiesta di revisione |
Hai gli stessi sintomi?
Scrivimi cosa vedi sul tuo sito: ti rispondo io, di persona, e ti dico da dove partire.
Recupero di un sito WordPress hackerato
Domande frequenti su questo caso
La causa era una falla di WordPress?+
No. Nel caso descritto, la causa è un accesso amministrativo rubato. WordPress core non risulta violato; i plugin vecchi hanno aumentato il rischio ma non sono la causa dimostrata.
Perché non si cancella tutto subito?+
Perché un componente scambiato per falso, ma in uso, rompe il sito. Spostare in quarantena permette di verificare e di tornare indietro.
Cos’è un plugin must-use?+
È un file nella cartella wp-content/mu-plugins che WordPress carica sempre, senza attivazione. Nell’elenco plugin compare in una sezione separata o non compare affatto: per questo è un nascondiglio frequente.
Il nome del cliente è pubblico?+
No. Il caso è reale ma anonimo: nomi, indirizzi email e indirizzi IP non vengono pubblicati.
