# Scanner di malware per siti web: cosa trovano e cosa no

> Scanner di malware per siti web: cosa riconoscono scanner esterni, di plugin e di server, dove sono i loro limiti e perché «nulla trovato» non significa pulito.

Fonte: https://phpsos.de/it/blog/grenzen-von-malware-scannern/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** uno scanner di malware per siti web trova soprattutto schemi noti nei file o nella pagina consegnata. Codice nuovo e offuscato, backdoor nel database, account estranei, cron job e chiavi SSH restano spesso invisibili. «Nulla trovato» non significa quindi «pulito». Una verifica diventa affidabile solo grazie alla combinazione di scanner, confronto con l'originale, controllo di database e sistema e monitoraggio del comportamento.

## La falsa quiete dopo la spunta verde

Dopo PHP2Shell molti gestori hanno fatto ciò che viene naturale: far girare uno scanner. Un servizio online controlla la home page, un plugin di sicurezza scandisce la directory web, il risultato è verde. Così sembra risolta la domanda se sia successo qualcosa prima della patch.

Il problema sta nel principio. La maggior parte degli scanner confronta i contenuti con schemi di software dannoso noto. Per le vulnerabilità CVE-2026-109618 e CVE-2026-109619, però, non esistono Indicators of Compromise pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Uno scanner non può cercare tracce che nessuno conosce. Al massimo trova software dannoso generico scaricato dopo un'intrusione, a condizione che segua schemi noti.

Questo non rende gli scanner inutili. Significa solo che il loro risultato va inquadrato correttamente. Quali indizi contano oltre agli scanner lo descrive [Sono già stato compromesso?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

## Scanner di malware per siti web: tre tipi

| Tipo | Che cosa vede | Che cosa non vede |
|---|---|---|
| Scanner esterno (servizio online) | pagine consegnate, script incorporati, reindirizzamenti, blacklist | file, database, account, tutto ciò che viene consegnato solo a certe condizioni |
| Scanner nel CMS (plugin o estensione) | file nella directory web, in parte contenuti del database, confronto con i file core | livello di sistema, cron job, SSH; gira nel sistema forse compromesso |
| Scanner sul server (basato su firme) | tutti i file leggibili, anche fuori dalla directory web | schemi sconosciuti e offuscati, database, account, comportamento |

Gli scanner esterni sono utili per riconoscere le conseguenze visibili, ad esempio reindirizzamenti o inserimenti nelle blacklist. Molti attacchi, però, consegnano i contenuti di spam o di reindirizzamento solo a determinati visitatori, ad esempio motori di ricerca o dispositivi mobili. Lo scanner vede allora una pagina pulita.

Gli scanner nel CMS hanno più visibilità, ma un problema di fondo: girano nello stesso sistema che dovrebbero controllare. Codice con privilegi sufficienti può influenzarne i risultati, nascondere file o disattivare lo scanner. Gli scanner di server lavorano fuori dall'applicazione, ma restano legati agli schemi.

## Che cosa gli scanner trascurano per principio

Indipendentemente dal tipo, esistono aree che uno scanner di file o di pagine riesce a coprire a malapena:

1. **Codice nuovo o offuscato in modo individuale:** ogni variante che appare diversa dagli schemi noti passa inosservata.
2. **Il database:** script nei contenuti, impostazioni modificate, trigger e account estranei. Maggiori informazioni in [Verificare la presenza di codice iniettato nel database](https://phpsos.de/it/blog/datenbank-auf-schadcode-pruefen/).
3. **Gli accessi:** account amministratore aggiuntivi, chiavi SSH, utenti del database, account nel pannello di hosting.
4. **Servizi di sistema e cron job:** meccanismi che ricaricano regolarmente codice dannoso.
5. **Modifiche poco appariscenti a file legittimi:** una sola riga in più in un file core, dall'aspetto innocuo.
6. **Dati sottratti:** se credenziali o dati dei clienti siano stati copiati non lo mostra nessuno scanner.

## Che cosa dà invece certezza

Più sicurezza viene dalla combinazione di tipi di verifica che lavorano in modo diverso:

- **Confronto con l'originale:** trova ogni modifica ai file noti, indipendentemente dagli schemi. La procedura è descritta in [Confrontare i file core del CMS con l'originale](https://phpsos.de/it/blog/cms-kerndateien-vergleichen/).
- **Ricerca mirata di anomalie:** file PHP nelle cartelle di upload, file modificati di recente, codice offuscato, file eseguibili in cartelle temporanee.
- **Verifica di account e servizi di sistema:** confrontare utenti, chiavi, cron job e servizi con lo stato atteso noto.
- **Analisi dei log:** richieste a file sconosciuti, picchi di errori, accessi insoliti.
- **Monitoraggio del comportamento:** processi del server web che avviano una shell, connessioni in uscita inattese, nuovi file in cartelle sensibili.

L'ultima categoria è la più importante quando non ci sono tracce note. Non chiede che aspetto abbia il codice dannoso, ma che cosa faccia. Un processo del server web che avvia all'improvviso una shell salta all'occhio, comunque sia offuscato il codice che lo ha provocato.

> **Consiglio:**
> Faccia girare uno scanner di server da un sistema pulito su una copia in sola lettura, invece che sul server sospetto stesso. Così il codice iniettato non può influenzare il risultato.

## Come usare gli scanner in modo sensato

Gli scanner hanno il loro posto, come uno strumento tra più. Uno scanner esterno è adatto come controllo regolare delle conseguenze visibili, ad esempio ogni settimana. Uno scanner nel CMS segnala nella quotidianità software dannoso noto e file core modificati. Uno scanner di server integra la ricerca di schemi noti nell'intero file system.

Decisivo è come si tratta il risultato. Un reperto è un chiaro incarico di verifica e giustifica un'indagine completa, perché di rado è interessato un solo file. Un risultato vuoto, invece, è solo un'affermazione sugli schemi controllati. Annoti nella documentazione quale scanner è stato eseguito, quando e con quale aggiornamento, e non scriva «sistema pulito», ma «nessuno schema noto trovato».

Per la direzione questo significa: una spunta verde non sostituisce una verifica da parte di qualcuno che consideri insieme file, database, account e comportamento. Dopo un incidente con possibile esecuzione di codice, come è pensabile con PHP2Shell, questa verifica dovrebbe aver luogo.

Se invece uno scanner segnala un reperto, serve un intervento rapido ma ordinato. Non cancelli subito il file segnalato con la funzione dello scanner. Metta prima al sicuro file e log, in modo da poter chiarire come sia arrivato sul server. Come si svolge una bonifica completa lo descrive il servizio [Far rimuovere malware e web shell](https://phpsos.de/it/leistungen/malware-entfernung/).

## Come aiuta PHP SOS in concreto?

- Combiniamo gli scanner con il confronto con l'originale, la ricerca mirata e l'analisi di account, servizi e log.
- Verifichiamo i sistemi sospetti tramite copie messe al sicuro, in modo che i risultati non siano influenzati dal sistema compromesso.
- Contrassegniamo ogni risultato in modo onesto come provato, probabile o sconosciuto.
- Con il [Security Monitoring per server web](https://phpsos.de/it/leistungen/security-monitoring/) monitoriamo in modo continuo il comportamento dei Suoi server, non solo gli schemi noti.


## Domande frequenti

**Il mio sito è pulito se lo scanner di malware non trova nulla?**  
Non necessariamente. Gli scanner trovano soprattutto schemi noti. Codice nuovo o ben offuscato, backdoor nel database, account estranei, cron job e chiavi SSH restano spesso non scoperti. Un risultato vuoto è un tassello, non un'assoluzione.

**Qual è la differenza tra uno scanner esterno e uno scanner di plugin?**  
Uno scanner esterno richiama il sito dall'esterno e vede solo ciò che viene consegnato. Uno scanner di plugin gira all'interno del CMS e può leggere i file, ma gira nello stesso sistema, che potrebbe essere compromesso. Entrambi hanno punti ciechi propri.

**Esistono firme di scanner per PHP2Shell?**  
Per PHP2Shell non esistono Indicators of Compromise pubblicati e confermati. Gli scanner non possono quindi cercare in modo mirato tracce certe di PHP2Shell. Il rilevamento si basa sull'analisi del comportamento e sulla ricerca di indizi generali di compromissione.

**Qual è lo scanner migliore?**  
La domanda è fuorviante. Più importante di un determinato prodotto è la combinazione di diversi tipi di verifica: confronto con l'originale, ricerca in file e database, verifica di account e servizi di sistema e monitoraggio del comportamento.

## Fonti

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [BSI: indicazioni sugli incidenti di sicurezza IT](https://www.bsi.bund.de/)
- [php.net: avvisi di sicurezza](https://www.php.net/)