Guida tecnica
Sito WordPress compromesso: cosa facciamo sul server
Quando arriva la segnalazione di un sito infetto, la tentazione è agire subito sul sito. Il primo lavoro vero, però, si fa un livello sotto: sui log, sui processi e sulle evidenze che il server conserva. Questa guida descrive la sequenza che seguiamo in qualità di sistemisti, e il confine netto tra ciò che compete al server e ciò che compete a chi bonifica l'applicativo.
Prima regola: non distruggere le evidenze
La reazione più comune alla scoperta di un malware è cancellare i file sospetti e ripristinare un backup. È anche il modo più efficace di rendere l'incidente permanente: senza evidenze non si identifica il vettore d'ingresso, e un vettore non identificato è una porta che resta aperta. Prima di qualsiasi modifica raccogliamo tre cose:
- backup completo di file e database dello stato attuale, infetto incluso
- copia dei log di accesso e di errore degli ultimi 30-60 giorni
- snapshot di processi attivi, connessioni di rete e task pianificati
Attribuzione: il log dice a quale livello è avvenuta l'intrusione
Il secondo passo è capire se l'attaccante è entrato dall'applicativo o dall'infrastruttura. La domanda si risponde leggendo le richieste POST nelle 48 ore che precedono i primi file malevoli:
- richieste verso endpoint di plugin o verso
wp-login.phpexmlrpc.php: ingresso applicativo, la gestione del sito è il perimetro d'intervento - file infetti fuori dallo spazio utente, cron di sistema alterati, altri account sul server con lo stesso malware: ingresso infrastrutturale, e qui la responsabilità è nostra
Nella maggior parte dei casi reali l'ingresso è applicativo: plugin con vulnerabilità note sfruttate in massa, credenziali rubate altrove, componenti non aggiornati. Un server impeccabile non può impedire queste intrusioni, ma determina quanto rapidamente si ricostruisce cosa è successo.
Contenimento lato server
Mentre chi gestisce il sito organizza la bonifica, sul server si riduce il danno in corso senza alterare le evidenze: isolamento dell'account coinvolto se l'ambiente è condiviso, blocco degli indirizzi IP chiaramente malevoli, sospensione dei task pianificati sospetti dopo averli documentati, verifica che backup recenti e ripristinabili siano disponibili per il post-intervento.
La collaborazione con chi bonifica
La bonifica applicativa di un sito WordPress è un mestiere a sé: lettura dei log nella chiave del CMS, confronto dei file con i checksum ufficiali, analisi del database, rimozione di backdoor e persistenze, hardening mirato al vettore trovato. Quando il nostro cliente ne ha bisogno, indichiamo un percorso che documenta il metodo completo con evidenze e garanzia: la guida alla bonifica malware WordPress passo per passo di WPsec.it, e per gli interventi veri e propri la pagina sulla rimozione malware WordPress.
La divisione dei ruoli vale la pena di essere ripetuta: il sistemista tiene il server osservato, aggiornato e ripristinabile; chi bonifica riporta l'applicativo allo stato noto e pulito. Sugli stessi log, i tempi dell'incidente si misurano in giorni invece che in settimane.
Per concludere
Se il tuo sito è stato segnalato infetto e il tuo hosting ti ha risposto "reinstalla WordPress", la sequenza corretta è un'altra: evidenze prima, attribuzione poi, bonifica mirata infine. E se gestisci infrastrutture che ospitano siti di clienti, il monitoraggio di integrità e la conservazione dei log non sono un extra: sono ciò che rende risolvibile il prossimo incidente.