Sito WordPress compromesso o server compromesso: dove sta il confine
Quando un sito WordPress risulta infetto, la domanda vera è a quale livello è avvenuta l'intrusione: applicativo o infrastruttura. Come si legge l'evidenza dai log, chi risponde di cosa, e quando serve chi bonifica l'applicativo.
Tra le richieste che arrivano a un provider di sicurezza gestita, quella che apre più spesso una discussione complicata è questa: "il mio sito WordPress è infetto, è colpa del server?".
La risposta onesta è quasi sempre la stessa: probabilmente no, ma l'unica maniera di saperlo è leggere le evidenze. E la distinzione non è una questione di scaricare responsabilità: determina chi deve intervenire, su cosa, e con quali competenze.
I due livelli, e perché vanno tenuti separati
Una compromissione che coinvolge un sito WordPress può avvenire a due livelli:
Livello applicativo: l'intrusione passa attraverso il CMS e i suoi componenti. Plugin obsoleto con vulnerabilità nota, credenziali rubate e riusate, tema nulled con backdoor integrata, account amministratore compromesso. L'attaccante entra dalla porta del sito, con le chiavi del sito.
Livello infrastruttura: l'intrusione passa dal sistema sotto lo spazio del sito. Isolamento insufficiente tra account su hosting condiviso, pannello di gestione obsoleto, cron di sistema manipolato, file infetti depositati fuori dallo spazio utente. Qui la responsabilità è del gestore dell'infrastruttura.
La confusione tra i due livelli produce i due errori classici: il titolare che cambia hosting sperando di risolvere (e si reinfetta identico), e il provider accusato ingiustamente che perde un cliente senza aver potuto difendersi, perché nessuno ha mai letto i log.
Come si legge l'evidenza: l'endpoint dice il livello
Nei log di accesso, la richiesta che ha permesso l'intrusione indica da sola il livello responsabile:
| Segnale nei log | Livello | Chi interviene |
|---|---|---|
| POST ripetuti su endpoint di plugin vulnerabili | Applicativo | Chi gestisce il sito |
| Brute force o stuffing su wp-login.php e xmlrpc.php | Applicativo | Chi gestisce il sito |
| Attività admin da IP sconosciuti con credenziali valide | Applicativo | Chi gestisce il sito |
| File infetti fuori dallo spazio utente | Infrastruttura | Gestore del server |
| Cron di sistema manipolati | Infrastruttura | Gestore del server |
| Altri account sullo stesso server infetti con lo stesso malware | Infrastruttura (probabile) | Gestore del server |
Il metodo pratico: si stabilisce il timestamp dei primi file malevoli (con la cautela dovuta, perché i timestamp si falsificano), si filtrano le richieste POST nelle 48 ore precedenti, si isola l'indirizzo IP responsabile e si ricostruisce la sua sessione completa. L'endpoint sfruttato chiude la catena causale.
Cosa può fare un MSSP sul server (e cosa no)
Dal nostro punto di vista, con la gestione di server che ospitano siti WordPress, il perimetro è chiaro.
Sul server possiamo e dobbiamo: mantenere il sistema aggiornato, garantire l'isolamento tra account, conservare log completi e accessibili, mantenere backup verificati, rilevare anomalie di sistema (processi insoliti, cron modificati, consumi anomali), bloccare traffico malevolo a livello di rete.
Sul server non possiamo: aggiornare i plugin del cliente, gestire le credenziali degli amministratori WordPress, rimuovere backdoor dal database, capire quale componente applicativo ha lasciato entrare l'attaccante. Sono attività che richiedono l'accesso al sito e competenze specifiche sull'ecosistema WordPress.
Quando l'intrusione è applicativa, il server può essere impeccabile e il sito infetto comunque. È il caso più frequente: la maggior parte delle compromissioni WordPress entra da plugin con vulnerabilità note sfruttate in massa, non da debolezze di sistema.
Il caso della doppia compromissione
Esiste poi lo scenario che tiene svegli chi fa questo mestiere: il sito infetto usato come punto d'appoggio per attaccare il server, o viceversa. Un webshell trascurato in un sito secondario può diventare il punto di appoggio per movimenti laterali su un server mal isolato.
Per questo il monitoraggio di integrità va fatto su entrambi i livelli, e per questo la bonifica seria non si dichiara chiusa finché non si è identificato il vettore d'ingresso. Un sito ripulito senza analisi root cause è una porta che si richiude a chiave, con il ladro ancora dentro la stanza accanto.
Quando serve chi bonifica l'applicativo
Se l'evidenza indica livello applicativo, l'intervento richiede competenze specifiche sull'ecosistema WordPress: lettura dei log nella chiave giusta, confronto dei file con i checksum ufficiali, analisi del database, rimozione delle persistenze (utenti fantasma, task pianificati, webshell offuscate) e hardening mirato al vettore trovato.
Sul metodo completo, con le fasi operative documentate passo per passo, esiste una risorsa italiana di riferimento: la guida alla bonifica malware WordPress con analisi root cause di WPsec.it, che descrive il metodo incident response applicato specificamente al CMS, dal congelamento delle evidenze al monitoraggio post-intervento. Per chi deve far bonificare un sito di un cliente e vuole capire cosa aspettarsi da un intervento serio, la stessa fonte documenta la rimozione malware WordPress con prezzo fisso e garanzia.
La divisione dei ruoli, alla fine, è semplice: noi teniamo il server sano, osservato e ripristinabile; chi fa bonifica applicativa riporta il sito allo stato noto e pulito. Quando entrambi i ruoli lavorano sulle stesse evidenze, l'incidente si chiude in giorni invece che in settimane.