Caso reale anonimizzato · giugno 2026

L'interfaccia mentiva. Il database no. È la sintesi di tutta questa storia, e conviene ricordarla ogni volta che qualcuno dice "ho controllato in wp-admin, non c'è niente di strano".

Cosa è successo a monte

A giugno 2026 uno degli attacchi supply chain più larghi dell'anno ha colpito la rete Awesome Motive, la casa dietro plugin diffusissimi come OptinMonster. Si stima che oltre 1,2 milioni di siti WordPress abbiano caricato codice compromesso, servito dal CDN del plugin e non da un file sul server. Il proprietario non doveva aggiornare niente: il codice arrivava da fuori, a ogni caricamento di pagina.

Il payload creava un utente amministratore nascosto e installava un plugin backdoor che riapriva la porta anche dopo una prima pulizia superficiale. L'admin fantasma era filtrato dalla lista utenti della dashboard, così chi verificava a mano non lo trovava.

Il nostro cliente aveva OptinMonster attivo. Era esposto.

L'admin che c'era e non si vedeva

Il servizio tiene il conto degli amministratori di ogni sito che segue. Il conto lo tira dal database, direttamente dalle tabelle utenti.

Ora 0 · L'allarme. Il monitoraggio nota che gli admin registrati dal nostro flusso sono due, ma la conta dal database ne restituisce tre. Il terzo account non è mai passato dai nostri canali. Nessuno lo ha creato in un modo che avessimo tracciato.

Chi apriva la dashboard di WordPress in quel momento vedeva due amministratori. Puliti. Nessun avviso, nessun plugin sospetto in evidenza.

Ora 0 → 0:15 · La query che smaschera. Andiamo dritti alla fonte:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Tre righe. La terza era un account registrato tre giorni prima, con una email su un dominio che il cliente non aveva mai usato. In wp_usermeta c'era la chiave che lo teneva fuori dalla vista: un filtro sulla lista utenti, iniettato per nascondere proprio quell'ID. La dashboard obbediva al filtro. Il database, quello, elencava tutto.

Il plugin che non doveva esserci

Un admin fantasma da solo è un problema. Ma un attacco serio lascia sempre una via di rientro.

Ora 0:15 → 0:40 · Caccia alla backdoor. Confronto tra i plugin attivi in wp_options (active_plugins) e le cartelle presenti in /wp-content/plugins/. Salta fuori una cartella con un nome che imitava un plugin di cache legittimo, mai installata dal cliente. Dentro, un file PHP con eval su una stringa decodificata a runtime e una chiamata wp_remote_post verso un server esterno: il canale di comando, il C2, che riceveva istruzioni e le eseguiva sul sito.

Il file leggeva anche i cookie di sessione degli amministratori. Serviva a rientrare senza nemmeno bisogno dell'account fantasma.

La pulizia, in ordine

Qui l'ordine conta. Rimuovere l'admin senza chiudere la backdoor significa ritrovarselo dopo dieci minuti.

Ora 0:40 → 1:10 · Backup e bonifica.

  • Snapshot completo del sito e dump del database, prima di toccare qualsiasi cosa.
  • Rimozione dell'utente admin rogue e dei suoi record in wp_usermeta (nessuna riga orfana lasciata indietro).
  • Cancellazione della cartella del plugin backdoor e del file di comando.
  • Ripristino del filtro sulla lista utenti al valore pulito, così la dashboard torna a dire la verità.

Ora 1:10 → 1:40 · Chiusura degli accessi.

  • Rotazione di tutte le password amministratore e delle chiavi di sicurezza in wp-config.php (i SALT): ogni sessione aperta viene invalidata, compresa quella dell'attaccante.
  • Attivazione dell'autenticazione a due fattori sugli account rimasti.
  • Blocco a livello di rete del CDN compromesso, in attesa della versione pulita del plugin da Awesome Motive. Finché il canale restava avvelenato, meglio zittirlo.

Ora 1:40 → 2:00 · Verifica. Nuova conta admin dal database: due, e tornano. Nessun plugin fuori inventario. Nessuna chiamata in uscita verso il server di comando nei log. Sito online, senza redirect, senza rallentamenti.

Perché la dashboard non basta

La lezione è scomoda per chi controlla un sito solo dalla schermata di amministrazione. Un attacco moderno le tracce non le lascia dove ti aspetti. Le nasconde proprio lì, dietro un filtro, dove l'occhio umano passa senza fermarsi.

Il monitoraggio del servizio confronta lo stato reale del database con lo stato che dovrebbe avere, letto alla fonte. Un amministratore in più tra due letture è un segnale che parte da solo, di notte, quando nessuno sta davanti allo schermo.

Con WPSonar il controllo degli admin, dei plugin attivi e delle chiamate in uscita gira in automatico su ogni sito seguito. Quando la conta non torna, il sistema apre l'intervento prima che il proprietario si accorga di qualcosa. Qui il cliente ha saputo del problema a bonifica già chiusa.