Stai leggendo questo articolo perché qualcosa non va
Forse te lo ha segnalato un cliente. Forse Google ha mostrato un avviso rosso prima della tua homepage. Forse il tuo sito reindirizza verso una farmacia online o un casinò. Forse il pannello di amministrazione non risponde più ai tuoi accessi.
Qualunque sia il segnale, la sensazione è sempre la stessa: panico, disorientamento, e la domanda immediata — da dove si comincia?
Questa guida è scritta per quel momento. Non è un manuale tecnico per sviluppatori: è un protocollo operativo per chi deve prendere decisioni nei prossimi 60 minuti.
Prima di tutto: come capire se sei davvero sotto attacco
Alcuni segnali sono ovvi. Altri no. Ecco i più comuni, divisi per categoria.
Segnali visibili agli utenti Il sito mostra contenuti che non hai mai pubblicato (farmaci, scommesse, contenuti per adulti). La homepage è stata sostituita con una pagina di rivendicazione dell'attacco. Appare un messaggio di ransomware che chiede pagamento in criptovaluta. Il sito reindirizza verso domini sconosciuti.
Segnali nel browser e nei motori di ricerca Google Chrome mostra l'avviso "Il sito contiene malware". Google Search Console ha inviato una notifica di sicurezza. I risultati di ricerca per il tuo sito mostrano descrizioni in cinese, russo o altri contenuti estranei. Il sito è stato rimosso dall'indice di Google.
Segnali tecnici meno visibili Il pannello di amministrazione non accetta le tue credenziali, ma non ricordi di averle cambiate. Sono apparse pagine o sezioni che non hai mai creato. Nei log del server ci sono accessi da IP sconosciuti a orari insoliti. Le email aziendali vengono marcate come spam dai destinatari. Il server è insolitamente lento o consuma risorse anomale.
Il caso più subdolo: alcune compromissioni non mostrano nulla di visibile per settimane. L'attaccante installa una backdoor silente, raccoglie dati o usa il server come relay per spam, e aspetta. Lo scopri mesi dopo da una notifica del Garante o da un cliente che ti segnala email sospette ricevute a suo nome.
Le prime 4 cose da fare subito (nei primi 30 minuti)
1. Metti offline il sito — subito
Sembra controintuitivo. Un sito offline fa perdere visibilità e potenziali clienti. Ma un sito compromesso fa danni enormemente peggiori: distribuisce malware ai tuoi visitatori, danneggia la tua reputazione in modo molto più profondo di qualche ora di inattività, e ti espone a responsabilità legali ai sensi del GDPR se i dati degli utenti vengono violati mentre il sito è ancora online.
Come fare: contatta il tuo hosting provider e chiedi la sospensione temporanea del sito, oppure sostituisci la homepage con una pagina statica di manutenzione. Se usi un pannello come cPanel o Plesk, puoi farlo in autonomia.
Non lasciare il sito online mentre investighi.
2. Cambia tutte le password — da un dispositivo pulito
Cambia nell'ordine: la password del pannello di hosting, le credenziali FTP/SFTP, la password del database, tutte le credenziali degli utenti amministratori del CMS, la password dell'email aziendale collegata al sito.
Usa un dispositivo che non hai usato per accedere al sito negli ultimi giorni — idealmente un telefono con una connessione dati diversa dalla rete aziendale. Se l'attaccante ha compromesso la tua rete locale, cambiare le password dallo stesso dispositivo potrebbe farle intercettare di nuovo.
Usa password nuove, generate casualmente, almeno 20 caratteri. Non riutilizzare password già usate in precedenza.
3. Fai un backup dello stato attuale — anche del sito compromesso
Sembra assurdo fare il backup di un sito infetto. Eppure è fondamentale per due ragioni.
Prima ragione: l'analisi forense. Per capire come è entrato l'attaccante, avrai bisogno dei log e dei file nel loro stato al momento della compromissione. Se pulisci tutto prima di analizzare, perdi questa informazione e rischi di lasciare aperta la stessa vulnerabilità.
Seconda ragione: il GDPR. In caso di violazione di dati personali, sei obbligato a notificare il Garante della Privacy entro 72 ore. Avere una documentazione dello stato del sistema al momento della scoperta è indispensabile per ricostruire cosa è successo e cosa potrebbe essere stato esfiltrato.
Fai un backup completo — file e database — e conservalo in un posto separato dal server compromesso.
4. Documenta tutto con timestamp
Annota l'ora esatta in cui hai scoperto il problema, il segnale che ti ha allertato, le prime azioni che hai eseguito. Fai screenshot di tutto ciò che vedi: pagine anomale, messaggi di errore, notifiche nei pannelli di controllo.
Questa documentazione non è burocrazia: è la base del tuo rapporto al Garante se dovesse servire, e la prova che hai agito tempestivamente.
Nelle ore successive: analisi e pulizia
Identifica il vettore di attacco prima di pulire
Il sito è stato compromesso in un modo specifico. Se non lo identifichi, la pulizia serve a poco: l'attaccante rientrerà dalla stessa porta entro pochi giorni.
I vettori più comuni su siti WordPress e CMS open source sono questi.
Plugin o tema vulnerabile. La causa più frequente in assoluto. Un plugin non aggiornato con una vulnerabilità nota viene sfruttato da scanner automatici che cercano quella specifica versione su milioni di siti. Controlla la data dell'ultimo aggiornamento di ogni plugin installato e confrontala con i log degli accessi anomali.
Credenziali compromesse. Le password degli account amministratori vengono rubate attraverso phishing, keylogger sul computer del developer, o riutilizzo di password già esposte in altre violazioni. Il sito Have I Been Pwned (haveibeenpwned.com) permette di verificare se un'email è presente in database di credenziali rubate.
File upload non protetto. Se il sito permette agli utenti di caricare file — immagini, documenti, allegati — e la validazione non è adeguata, è possibile caricare file PHP malevoli che vengono poi eseguiti come codice sul server. Queste webshell danno all'attaccante accesso completo al filesystem.
Configurazione server esposta. File come wp-config.php, .env, o .htaccess accessibili pubblicamente espongono credenziali del database e chiavi di configurazione. Succede spesso dopo migrazioni di sito fatte in fretta.
Attacco brute force sull'amministrazione. Se il pannello admin non era protetto da autenticazione a due fattori e il nome utente era il classico admin, gli attaccanti hanno potuto provare automaticamente migliaia di combinazioni di password fino a trovare quella corretta.
Scansione e rimozione del malware
Una volta identificato il vettore, procedi con la scansione. Su WordPress esistono strumenti come Wordfence o Sucuri che analizzano i file alla ricerca di codice malevolo. Questi strumenti sono utili ma non infallibili: un malware sofisticato può nascondersi in modo da eludere le firme note.
Cerca in modo specifico file PHP in cartelle dove non dovrebbero esserci (cartelle uploads, images, cache), funzioni PHP pericolose nei file esistenti come eval(), base64_decode(), system(), exec(), righe di codice offuscato che sembrano stringhe casuali, e utenti amministratori creati di recente che non riconosci.
Il metodo più affidabile — se hai un backup pulito antecedente alla compromissione — è ripristinare i file originali e riapplicare solo i contenuti (testi, immagini, database) dopo averli ispezionati.
Richiedi l'Audit di Sicurezza Gratuito →
La backdoor nascosta: il pericolo più sottovalutato
Ogni volta che un sito viene compromesso, l'attaccante installa quasi invariabilmente una backdoor: un file o una porzione di codice che gli permette di rientrare anche dopo che hai cambiato tutte le password e rimosso il malware evidente.
Le backdoor vengono nascoste nei posti meno ovvi: in file con nomi che imitano file di sistema legittimi (.info.php, wp-cache.php), in immagini che in realtà contengono codice PHP, in plugin o temi disattivati ma non eliminati, nei file di configurazione del server.
Se non sei sicuro di aver trovato e rimosso ogni backdoor, l'approccio più sicuro è un ripristino completo dell'ambiente da zero: server pulito, CMS reinstallato, plugin reinstallati dalle fonti ufficiali, contenuti ripristinati dal backup.
L'obbligo che molti dimenticano: la notifica GDPR entro 72 ore
Se il sito raccoglie dati personali degli utenti — e quasi tutti i siti aziendali lo fanno, anche solo attraverso il modulo di contatto — una violazione della sicurezza che potrebbe aver esposto quei dati è un data breach ai sensi del GDPR.
In questo caso hai l'obbligo di notificare il Garante della Privacy entro 72 ore dalla scoperta dell'incidente, attraverso il portale dell'Autorità.
La notifica deve includere: la natura della violazione e le categorie di dati coinvolte, il numero approssimativo di persone interessate, le misure adottate o in corso per rimediare, i contatti del Responsabile della Protezione dei Dati (DPO) se nominato.
Le sanzioni per mancata notifica possono arrivare fino a 10 milioni di euro o al 2% del fatturato annuo mondiale. Ma al di là delle sanzioni, notificare tempestivamente è anche una questione di correttezza verso le persone i cui dati potresti aver esposto.
Non aspettare di avere la certezza assoluta di cosa è successo per notificare. La norma accetta notifiche preliminari da aggiornare successivamente. Aspettare di avere tutti i dettagli e superare le 72 ore è peggio di notificare con informazioni incomplete.
Cosa fare dopo la pulizia: i 5 passi per non ricominciare da capo
Rimesso online il sito, il lavoro più importante è assicurarsi che non succeda di nuovo.
Aggiorna tutto, immediatamente e sempre. Core del CMS, tutti i plugin, tutti i temi — inclusi quelli non attivi. Un tema inattivo ma presente sul server è comunque accessibile e sfruttabile. Valuta di eliminare tutto ciò che non usi.
Attiva l'autenticazione a due fattori sul pannello admin. Con 2FA attivo, una password rubata non basta per accedere. L'attaccante avrebbe bisogno anche del tuo telefono. Questa misura da sola elimina la grande maggioranza degli attacchi brute force e di phishing sulle credenziali.
Limita gli accessi al pannello di amministrazione. Se accedi sempre dalla stessa rete, puoi configurare una whitelist di IP da cui è consentito l'accesso al pannello admin. Tutto il resto riceve una risposta 403, anche con credenziali corrette.
Monitora attivamente. Un sistema di monitoraggio che ti avvisa quando viene creato un nuovo file PHP nelle cartelle di upload, quando si registra un nuovo utente amministratore, o quando viene modificato un file core, ti permette di intercettare una compromissione entro minuti invece di scoprirla settimane dopo.
Rivedi chi ha accesso e con quali permessi. Ogni account amministratore è un potenziale punto di ingresso. Rimuovi gli account degli sviluppatori che non lavorano più con te, abbassa i permessi degli utenti che non hanno bisogno dei pieni diritti amministrativi, e tieni traccia di chi ha accesso a cosa.
La domanda che vale la pena porsi adesso
Se il tuo sito è stato attaccato, la domanda più importante non è "come lo riparo?" ma "perché è successo?".
La risposta onesta, nella maggior parte dei casi, è che il sistema su cui gira il tuo sito è stato costruito senza considerare la sicurezza come un requisito architetturale. La sicurezza è stata aggiunta dopo — con plugin, con servizi esterni, con aggiornamenti manuali — su una base che non era progettata per resistere.
Un CMS costruito con la sicurezza nel core, dove la protezione da SQL injection e XSS non dipende da plugin di terze parti ma è integrata nel modo in cui il sistema gestisce ogni input e ogni output, ha una superficie di attacco fondamentalmente diversa. Non perché sia magicamente invulnerabile, ma perché il problema viene risolto dove va risolto: nell'architettura, non nella toppa.
Se vuoi capire concretamente quanto è esposto il tuo sito attuale, puoi richiederci un audit gratuito. Analizziamo la superficie di attacco del tuo sito esistente e ti forniamo un report con le vulnerabilità trovate — senza impegno.
