In breve: se il Suo sito è stato violato, questa checklist aiuta a non dimenticare nulla: prima contenere e mettere al sicuro le prove, poi trovare la causa e bonificare, quindi rinnovare tutti gli accessi, verificare gli obblighi e chiudere l'incidente in modo documentato. L'ordine è importante, perché chi cancella per primo perde le tracce e chi bonifica soltanto senza chiudere la vulnerabilità viene attaccato di nuovo.
A chi serve questa checklist quando il sito è stato violato
La checklist si rivolge a direzione, titolari e responsabili IT dopo un attacco confermato o probabile a un sito web, a uno shop o a un server web PHP. È adatta anche dopo PHP2Shell, se un server era raggiungibile prima dell'aggiornamento e ci sono indizi di una compromissione.
Non ogni punto si adatta a ogni ambiente. Svolga comunque l'intero elenco e annoti per ogni punto se è completato, non applicabile o aperto. Questo registro è prezioso in seguito per assicurazione, protezione dei dati e rielaborazione interna.
Per ogni passo riporti data, ora, persona responsabile e risultato. Se sono coinvolte più persone, stabilisca chi tiene l'elenco e registra le decisioni.
Fase 1: contenere e mettere al sicuro subito
- Limitare il danno: mettere il sito in modalità di manutenzione o scollegarlo dalla rete se i visitatori sono a rischio o se i dati potrebbero fuoriuscire. Il BSI (Ufficio federale tedesco per la sicurezza informatica) raccomanda per PHP2Shell di scollegare temporaneamente i server web non aggiornati quando un aggiornamento non è subito possibile.
- Non cancellare nulla: non rimuovere file, non reinstallare il server e non svuotare i log prima di aver messo al sicuro le tracce.
- Mettere al sicuro i log: copiare su un altro sistema access, error, PHP-FPM e log di sistema e registrare i checksum. Per PHP2Shell la stampa specializzata consiglia di conservare i log a partire dal 20/10/2026.
- Mettere al sicuro un'immagine: creare come stato probatorio una copia di file e database, per i server virtuali uno snapshot, e non modificarla.
- Informare i responsabili: coinvolgere presto direzione, responsabile della protezione dei dati, hoster e, se presente, l'assicurazione cyber. Molte assicurazioni hanno obblighi di comunicazione.
Fase 2: trovare la causa e bonificare
- Individuare il punto d'ingresso: analizzare log, modifiche ai file e versioni. Controlli PHP stesso, CMS, temi, estensioni, credenziali e servizi del server. Senza una causa nota resta il rischio di un nuovo attacco.
- Chiudere la vulnerabilità: portare PHP a una versione corretta (8.5.12, 8.4.27, 8.3.36 o 8.2.35 ovvero backport confermato dal fornitore), aggiornare CMS ed estensioni, riavviare tutti i worker PHP.
- Circoscrivere il periodo: determinare il momento più antico di attività sospetta. Decide quali backup possono essere puliti e quali dati possono essere coinvolti.
- Rimuovere le backdoor: controllare e rimuovere webshell, file PHP estranei nelle cartelle di upload e di cache, file core modificati, cronjob, chiavi SSH e servizi di sistema. Sostituire i file core con quelli di una fonte pulita.
- Bonificare il database: rimuovere account admin sconosciuti, script introdotti in contenuti e impostazioni e contenuti di spam.
- Valutare la ricostruzione: in caso di compromissione profonda del server, una ricostruzione su un sistema nuovo e aggiornato con dati verificati è spesso la via più affidabile rispetto a una bonifica nel sistema in esercizio.
Fase 3: rinnovare gli accessi e rafforzare
- Cambiare le password: per CMS, account di hosting, pannello, database, FTP, SFTP, SSH ed e-mail, e da un dispositivo pulito.
- Sostituire chiavi e token: rigenerare chiavi API, interfacce di servizi di pagamento e di spedizione, chiavi dell'applicazione del CMS, chiavi SSH e certificati che si trovavano sul server.
- Terminare le sessioni: disconnettere tutti gli accessi attivi nel CMS e nei servizi e controllare i dispositivi a due fattori registrati.
- Attivare l'autenticazione a due fattori: per tutti gli accessi admin, inclusi hosting, dominio e DNS.
- Rafforzare il server: controllare e documentare impostazioni PHP, permessi dei file, blocchi di esecuzione nelle cartelle di upload, firewall e header di sicurezza.
Fase 4: obblighi, comunicazione e chiusura
- Verificare gli obblighi di notifica: se possono essere coinvolti dati personali, può essere necessaria una notifica entro 72 ore ai sensi dell'art. 33 GDPR. La valutazione spetta al responsabile della protezione dei dati o a un avvocato. Verificare separatamente gli obblighi di settore, ad esempio ai sensi della NIS2.
- Valutare la denuncia: i punti di contatto centrali tedeschi per il cybercrimine (Zentrale Ansprechstellen Cybercrime, ZAC) della polizia ricevono le denunce delle aziende. I log messi al sicuro ne sono una base importante.
- Informare clienti e Google: informare gli interessati in modo oggettivo e concordato. Se Google mostra un avviso, richiedere la verifica dopo la bonifica, come descritto in Rimuovere l'avviso di Google.
- Documentare la chiusura e monitorare: registrare in un rapporto causa, periodo, misure e punti aperti, trarre insegnamenti per il piano di emergenza e monitorare i sistemi in modo rafforzato nelle settimane successive.
Errori frequenti nel dopo-attacco
Molti incidenti si trascinano perché nella prima agitazione si risparmia nel punto sbagliato o si agisce troppo in fretta. Questi errori vanno evitati:
- Rimuovere solo ciò che si vede: una pagina di spam cancellata o un reindirizzamento rimosso non sono la prova di un sito pulito. Le backdoor restano spesso inosservate.
- Cambiare le password dal sistema interessato: se sul computer o sul server gira ancora malware, le nuove credenziali possono fuoriuscire subito di nuovo.
- Ripristinare alla cieca un backup: senza vulnerabilità chiusa e senza verifica del backup, l'aggressore è presto di nuovo alla porta.
- Intendere la patch come cessato allarme: un aggiornamento a una versione corretta di PHP non dimostra che prima non sia successo nulla e non rimuove il malware introdotto.
- Verificare tardi gli obblighi: i termini iniziano con la conoscenza dell'incidente, non con la fine della bonifica.
- Nessuna documentazione: senza registro è difficile rispondere in seguito alle domande di assicurazione, autorità o clienti.
Questa checklist non sostituisce la consulenza legale. Per domande su obblighi di notifica, responsabilità o assicurazione si rivolga al Suo responsabile della protezione dei dati, a un avvocato o al Suo assicuratore.
Come aiuta concretamente PHP SOS?
- Ci occupiamo della incident response strutturata e seguiamo la checklist insieme a Lei, punto per punto con registro.
- Mettiamo al sicuro log e stati del sistema in modo che restino utilizzabili per assicurazione, autorità e una possibile analisi forense IT.
- Chiudiamo la vulnerabilità, bonifichiamo o ricostruiamo e rinnoviamo gli accessi nell'ordine giusto.
- Forniamo un rapporto finale con causa, misure e raccomandazioni e, su richiesta, continuiamo poi a monitorare i sistemi.
Domande frequenti
Qual è la prima cosa da fare se il mio sito è stato violato?
Mantenere la calma, non cancellare nulla e limitare il danno. Se necessario scolleghi il sito dalla rete o lo metta in modalità di manutenzione e metta al sicuro log e file prima di bonificare. Seguono poi la ricerca della causa e la bonifica.
Basta ripristinare il sito da un backup?
Di solito no. Il backup può già contenere codice dannoso e la vulnerabilità da cui è entrato l'aggressore è ancora aperta dopo il ripristino. Prima chiudere la causa, poi ripristinare uno stato verificato e pulito su un sistema aggiornato.
Devo segnalare un hack all'autorità per la protezione dei dati?
Se possono essere coinvolti dati personali, l'art. 33 GDPR prevede in linea di principio una notifica entro 72 ore dalla conoscenza dell'evento, a meno che un rischio per gli interessati sia improbabile. La valutazione spetta al Suo responsabile della protezione dei dati o a un avvocato.
Quando un incidente è davvero concluso?
Quando la causa è chiusa, tutte le backdoor note sono rimosse, gli accessi rinnovati, gli obblighi adempiuti e le misure documentate. Ne fa parte un periodo di monitoraggio rafforzato successivo, per riconoscere eventuali tracce trascurate.