# Checklist dopo un hack: 20 punti per il dopo-attacco

> Checklist se il sito è stato violato: 20 punti dal contenimento e dalla raccolta delle prove alla bonifica, ai nuovi accessi e agli obblighi di notifica.

Fonte: https://phpsos.de/it/ratgeber/checkliste-nach-dem-hack/  
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:** 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

1. **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.
2. **Non cancellare nulla:** non rimuovere file, non reinstallare il server e non svuotare i log prima di aver messo al sicuro le tracce.
3. **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.
4. **Mettere al sicuro un'immagine:** creare come stato probatorio una copia di file e database, per i server virtuali uno snapshot, e non modificarla.
5. **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

6. **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.
7. **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.
8. **Circoscrivere il periodo:** determinare il momento più antico di attività sospetta. Decide quali backup possono essere puliti e quali dati possono essere coinvolti.
9. **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.
10. **Bonificare il database:** rimuovere account admin sconosciuti, script introdotti in contenuti e impostazioni e contenuti di spam.
11. **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

12. **Cambiare le password:** per CMS, account di hosting, pannello, database, FTP, SFTP, SSH ed e-mail, e da un dispositivo pulito.
13. **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.
14. **Terminare le sessioni:** disconnettere tutti gli accessi attivi nel CMS e nei servizi e controllare i dispositivi a due fattori registrati.
15. **Attivare l'autenticazione a due fattori:** per tutti gli accessi admin, inclusi hosting, dominio e DNS.
16. **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

17. **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](https://phpsos.de/it/compliance/dsgvo-meldepflicht-72-stunden/). 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.
18. **Valutare la denuncia:** i [punti di contatto centrali tedeschi per il cybercrimine (Zentrale Ansprechstellen Cybercrime, ZAC)](https://phpsos.de/it/compliance/anzeige-polizei-zac/) della polizia ricevono le denunce delle aziende. I log messi al sicuro ne sono una base importante.
19. **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](https://phpsos.de/it/ratgeber/google-warnung-entfernen/).
20. **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.

> **Importante:**
> 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](https://phpsos.de/it/leistungen/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](https://phpsos.de/it/leistungen/it-forensik/).
- 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.

## Fonti

- [Art. 33 GDPR: notifica all'autorità di controllo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polizia tedesca: punti di contatto centrali per il cybercrimine](https://www.polizei.de/)
- [BSI: indicazioni sugli incidenti di sicurezza IT](https://www.bsi.bund.de/)
- [php.net: bollettini di sicurezza su PHP2Shell](https://www.php.net/)