In breve: gli account admin estranei li trova solo se verifica tutti i livelli: il CMS o lo shop, il pannello di hosting, gli utenti di sistema del server, gli accessi SSH e gli utenti del database. Non si fidi dell'elenco utenti nel backend, perché il codice inserito può nascondervi degli account. Documentare i ritrovamenti per primi e bloccarli, poi chiarire la causa, solo dopo cancellare.
Perché un amministratore sconosciuto è così pericoloso
Un account admin aggiuntivo è per gli aggressori la backdoor più comoda. Non richiede codice dannoso, non spicca nelle scansioni dei file e sopravvive a ogni aggiornamento. Chi in seguito accede con questo account, nel log appare come un normale redattore.
Dopo PHP2Shell questa verifica acquista peso. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 consentono l'esecuzione di codice dannoso senza autenticazione. Chi può eseguire codice sul server può anche scrivere nel database e quindi creare account. Un aggiornamento di PHP chiude la vulnerabilità, ma non rimuove un account nato in precedenza.
Per PHP2Shell non esistono Indicators of Compromise pubblicati e confermati, cioè nessun elenco di tracce tipiche. Un account sconosciuto non è quindi una prova di PHP2Shell, ma un chiaro indizio di accesso non autorizzato, in qualunque modo. Una panoramica di altri segni è in Sono già compromesso?.
Dove possono nascondersi account admin estranei
Molti gestori guardano solo nel CMS. Gli aggressori ragionano per livelli, e ogni livello ha account propri:
| Livello | Dove guardare | A cosa fare attenzione |
|---|---|---|
| CMS o shop | Gestione utenti e tabella utenti del database | Ruolo Administrator, data di creazione, indirizzo e-mail estraneo |
| Pannello di hosting | Utenti, account aggiuntivi, account FTP | Account che nessuno nel team ha creato |
| Server Linux | /etc/passwd, gruppi sudo o wheel, sudoers |
altri account con UID 0, nuove shell di login |
| SSH | authorized_keys di tutti gli utenti |
Chiavi senza proprietario noto |
| Database | Tabella utenti del server di database | Utenti con diritti globali o host % |
| Servizi esterni | Dominio, DNS, Search Console, CDN | titolari o autorizzati aggiuntivi |
Il livello SSH è abbastanza autonomo da meritare un articolo proprio: Trovare e rimuovere chiavi SSH sconosciute.
Trovare account admin estranei nel CMS, anche quelli nascosti
L'elenco utenti nel backend è generato dall'applicazione stessa. Se gira del codice inserito, può filtrare singole voci. Più affidabili sono quindi gli strumenti che guardano direttamente i dati memorizzati. Per WordPress, WP-CLI elenca tutti gli amministratori con la data di creazione:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Un livello più in profondità va un'interrogazione di sola lettura nel database. Mostra ogni account a cui è assegnato il ruolo di amministratore, indipendentemente da ciò che mostra l'interfaccia. Il prefisso di tabella wp_ lo adatti alla Sua installazione:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Confronti i risultati di backend, WP-CLI e database. Se un account compare solo nel database, è un forte segnale d'allarme, perché allora è in gioco anche del codice che lo nasconde. Per altri sistemi come Shopware, TYPO3 o Joomla vale lo stesso principio: interrogare direttamente la tabella utenti e confrontarla con la visualizzazione nel backend. Quali siano le tabelle lo indica la documentazione del produttore.
Verificare utenti di sistema e utenti del database
Sul server stesso interessano soprattutto gli account con diritti di root e quelli che possono accedere. I comandi seguenti leggono soltanto:
# Account con UID 0 (normalmente solo root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Account con una vera shell di login
grep -vE '(nologin|false)$' /etc/passwd
# Membri dei gruppi admin
getent group sudo wheel
# Regole sudo aggiuntive
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Ultimi accessi con data completa
last -F | head -30
Sul server di database verifichi quali utenti esistano e quali diritti abbiano:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Un'applicazione di norma ha bisogno di un utente con diritti su esattamente un database. Un utente aggiuntivo con diritti globali che può accedere da host qualsiasi (%) va chiarito.
Non dimentichi gli account fuori dal server. Chi ha accesso al contratto del dominio o alla gestione DNS può reindirizzare i visitatori o far emettere certificati su server estranei. Un titolare aggiuntivo in Google Search Console può inviare sitemap e modificare impostazioni. Presso registrar, fornitore DNS, CDN e Search Console passi quindi in rassegna l'elenco degli autorizzati e lo confronti con ciò che il Suo team conosce.
Come comportarsi correttamente con un ritrovamento
Il primo impulso è cancellare subito l'account estraneo. Così però sparisce anche una traccia importante: la data di creazione spesso circoscrive quando l'aggressore fosse nel sistema. Meglio questo ordine:
- Documentare: annotare nome utente, ID, e-mail, data di creazione, ruolo e ultima attività con l'ora, meglio come schermata ed esportazione.
- Bloccare invece di cancellare: togliere il ruolo, sostituire la password con un valore casuale o disattivare l'account.
- Circoscrivere il periodo: verificare i log intorno alla data di creazione. Quali richieste ci sono state poco prima, quali file sono cambiati?
- Verificare altri livelli: chi crea un account raramente ne lascia uno solo. Esaminare anche file, cron job, chiavi SSH e database.
- Bonificare e rinnovare gli accessi: solo dopo la bonifica e l'aggiornamento di PHP rinnovare tutte le password, le chiavi e le sessioni.
Un'avvertenza di prudenza: non ogni account sconosciuto è malevolo. Agenzie, fornitori precedenti o plugin di manutenzione a volte creano account propri. Lo chiarisca prima di dare l'allarme, ma lo chiarisca tempestivamente.
Impedire il ritorno
Dopo la bonifica gli account admin dovrebbero essere l'eccezione, non la regola. Si sono rivelati validi account personali invece di accessi condivisi, il minor numero possibile di amministratori e un'autenticazione a due fattori per gli accessi admin. Stabilisca inoltre chi possa creare nuovi account admin e dove ciò venga documentato.
Un'interrogazione regolare come quelle sopra, ad esempio settimanale e con confronto con la settimana precedente, rende rapidamente visibili i nuovi account. Con WordPress aiuta inoltre la guida Trovare backdoor in WordPress.
Come aiuta concretamente PHP SOS?
- Verifichiamo tutti i livelli di account, dal CMS al server fino al database, e confrontiamo la visualizzazione nel backend con i dati memorizzati.
- Conserviamo i ritrovamenti con marcature temporali prima che gli account vengano bloccati o rimossi.
- Nell'ambito dell'incident response chiariamo come sia nato l'account e se esistano altre backdoor.
- Rinnoviamo gli accessi nell'ordine corretto e configuriamo un controllo continuo dei nuovi account admin.
Domande frequenti
Devo cancellare subito un account admin sconosciuto?
Meglio non subito. Documenti prima nome utente, data di creazione, indirizzo e-mail e ultima attività e blocchi l'account. Si cancella solo quando le tracce sono state conservate, perché la data di creazione è spesso un indizio importante del momento dell'intrusione.
Un account admin può essere invisibile nel backend?
Sì. Il codice inserito può nascondere singoli account dall'elenco utenti dell'interfaccia. Un'interrogazione diretta del database o uno strumento da riga di comando mostra invece tutti gli account memorizzati. Per questo non dovrebbe guardare solo nel backend.
Quali livelli devo verificare oltre al CMS?
Pannello di hosting, accessi FTP e SFTP, utenti di sistema del server compresi i diritti sudo, chiavi SSH, utenti del database e account presso dominio, DNS e Search Console. All'aggressore basta una di queste porte per tornare.
Dopo il ritrovamento basta cambiare tutte le password?
No. Un account estraneo mostra che qualcuno ha avuto accesso. Allora vanno chiariti anche il punto d'ingresso, altre backdoor e possibili fughe di dati. Le password le cambi solo dopo la bonifica e da un dispositivo pulito.