In breve: se vuole far rimuovere il malware dal Suo sito web, cancellare singoli file raramente basta. Prima salviamo il reperto, troviamo web shell, backdoor e attività nascoste, ricostruiamo da fonti attendibili e chiudiamo il punto d'ingresso. Solo allora la bonifica è affidabile.
Da che cosa si riconosce il malware sul sito web
Il codice dannoso sui siti web spesso emerge solo indirettamente. Sono tipici reindirizzamenti verso siti estranei, contenuti di spam visibili solo ai motori di ricerca o ai dispositivi mobili, un avviso di Google nei risultati di ricerca, reclami dei clienti o un blocco da parte dell'hoster per invio di spam. Sul server compaiono file PHP sconosciuti, nuovi account admin, file .htaccess modificati o cronjob inspiegabili.
Dopo PHP2Shell si aggiunge un'altra preoccupazione: tramite CVE-2026-109618 e CVE-2026-109619 gli aggressori possono eseguire codice senza autenticarsi. Non esistono Indicators of Compromise pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Come appaiono di norma le web shell e dove si trovano è descritto alla pagina Riconoscere e rimuovere le web shell.
Rimuovere il malware dal sito web: perché essere accurati conta più che essere rapidi
Gli aggressori raramente depositano un solo file. Sono abituali più backdoor in luoghi diversi: nelle cartelle di upload, in plugin o temi, nei plugin must-use, nel database, nei cronjob o in account utente aggiuntivi. Se si cancella solo il file più vistoso, il codice dannoso ritorna.
Allo stesso tempo lo stato infetto è un elemento di prova. Chi bonifica in modo precipitoso perde la possibilità di accertare se siano coinvolti dati dei clienti. Per questo salviamo prima di ogni modifica. Costa poco tempo e Le lascia aperte tutte le strade, anche una successiva notifica all'autorità di controllo o all'assicuratore.
Un aggiornamento di PHP o del CMS non rimuove il malware già presente sul server. E un sito web bonificato viene infettato di nuovo finché il punto d'ingresso resta aperto.
Dove il codice dannoso si nasconde di solito
I luoghi seguenti li verifichiamo a ogni bonifica, perché nella pratica sono colpiti sempre di nuovo:
| Luogo | Reperto tipico |
|---|---|
| Cartelle di upload | file PHP con nomi dall'aspetto innocuo o camuffati da immagine |
| Plugin, temi, moduli | file aggiuntivi o file originali modificati |
| Configurazione | righe introdotte in .htaccess, .user.ini o nei file di ingresso |
| Database | account admin estranei, script nei contenuti o nelle opzioni |
| Sistema | cronjob, chiavi SSH aggiuntive, processi senza scopo riconoscibile |
| Cache e cartelle temporanee | copie di codice dannoso che riappaiono dopo la cancellazione |
È importante il contesto: un singolo reperto raramente spiega l'intero incidente. Solo il quadro d'insieme mostra come ha proceduto l'aggressore e se si è portato via delle credenziali.
Come aiuta concretamente PHP SOS?
- Salvare: creiamo una copia di file, database e log nello stato infetto. Viene conservata per una successiva analisi.
- Cercare: confrontiamo i file del programma con gli originali del produttore, verifichiamo che le cartelle di upload non contengano codice eseguibile, esaminiamo database, cronjob, account utente e configurazione del server. Per gli ambienti WordPress procediamo come descritto alla pagina Trovare backdoor in WordPress.
- Bonificare: core, estensioni e temi vengono reinstallati da fonti attendibili, invece di rattoppare singolarmente i file sospetti. I contenuti propri e gli upload li verifichiamo a parte e riprendiamo solo ciò che non desta dubbi.
- Chiudere la causa: applichiamo la patch a PHP e all'applicazione, rimuoviamo gli account estranei e sostituiamo tutte le credenziali e le chiavi che l'aggressore potrebbe aver visto.
- Controllo successivo: osserviamo il sito web dopo la bonifica per rilevare nuove modifiche e La assistiamo nel far verificare un avviso di Google tramite la Search Console. Maggiori informazioni alla pagina Rimuovere l'avviso di Google.
Per gli amministratori, un primo sguardo innocuo ai file PHP modificati di recente:
# file PHP nella directory web modificati negli ultimi 10 giorni
find /var/www -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
Il risultato è un indizio, non una prova: gli aggressori possono alterare i timestamp.
Che cosa riceve e che cosa ci serve
Riceve un rapporto con i componenti dannosi trovati e il loro luogo di rinvenimento, le misure di bonifica, l'elenco delle credenziali sostituite e il probabile punto d'ingresso. Distinguiamo con chiarezza ciò che è provato, ciò che è probabile e ciò che è sconosciuto.
Da Lei ci servono:
- accesso a server o pannello di hosting, backend del CMS e database
- un referente in grado di autorizzare cambi di password e spegnimenti
- informazioni su agenzia, sviluppatore o hoster e sulle personalizzazioni del sistema
- backup esistenti con data, per poter valutare quale stato possa essere pulito
- accesso alla Google Search Console, se viene mostrato un avviso
Che cosa non promettiamo
Non promettiamo che ogni backdoor su ogni sistema venga trovata con certezza se mancano i log o se l'infezione risale a lungo tempo fa. In caso di situazione poco chiara raccomandiamo la ricostruzione su un server nuovo, su cui vengono trasferiti solo contenuti verificati. È più laborioso, ma spesso la via più affidabile. Non prevediamo nemmeno quando Google o altri servizi rimuoveranno un avviso; lo decidono questi fornitori.
Se occorre chiarire in modo valido in tribunale che cosa sia accaduto esattamente e quali dati siano coinvolti, coinvolgiamo l'analisi forense IT con partner specializzati. In caso di attacco acuto e ancora in corso, il lavoro inizia con l'assistenza urgente per sito web hackerato.
Domande frequenti
Basta un plugin scanner antimalware per bonificare il mio sito web?
Uno scanner trova schemi noti, ma non ogni backdoor. Le web shell sono spesso offuscate, si trovano in immagini, cache o nel database oppure sono ancorate come cronjob. Uno scanner è uno strumento di supporto, non una bonifica completa.
Posso semplicemente ripristinare un vecchio backup?
Solo se è certo che il backup risalga a prima dell'intrusione e se poi il punto d'ingresso viene chiuso. Altrimenti il sito web resta pulito per poco e viene infettato di nuovo per la stessa via.
Perché il malware ricompare sempre dopo averlo cancellato?
Di solito c'è una seconda backdoor, un cronjob, un account admin manipolato oppure la vulnerabilità è ancora aperta. Solo quando tutti i meccanismi di persistenza sono stati trovati e la causa è eliminata, la bonifica regge.
Un aggiornamento di PHP rimuove il malware presente?
No. Una patch chiude la vulnerabilità, ma non rimuove il malware già introdotto. Sono due fasi di lavoro distinte.