Nelle settimane passate ho individuato un'anomalia tecnica sul sito istituzionale di un piccolo comune della Valle Telesina.
Ho quindi cristallizzato la situazione con hash SHA-256 e ho immediatamente segnalato l’accaduto alla pubblica amministrazione, che ha poi gestito l’incidente in autonomia.
Spesso si pensa che gli attacchi informatici colpiscano solo i grandi centri, ma la realtà è diversa: molte campagne sono automatizzate, "sparano nel mucchio" e finiscono per colpire proprio gli enti meno strutturati dal punto di vista della sicurezza.
L'analisi tecnica di questi casi evidenzia spesso un aspetto ricorrente: non è tanto l'attacco in sé a fare la differenza, quanto la capacità (o meno) di accorgersene in tempi rapidi e gestirlo correttamente.
Ora che il problema sembra rientrato, ho deciso di scrivere qualche riga per spiegare l’importanza della cybersecurity, argomento purtroppo ancora poco sentito nelle nostre zone, e condividere qualche lezione pratica per chi si occupa di gestione di siti web istituzionali.
Cosa è successo
Il sito compromesso era costruito con WordPress ed era ospitato su un hosting condiviso Aruba: un mix purtroppo molto vulnerabile agli attacchi automatici.
Gli attaccanti hanno sfruttato questa configurazione debole per effettuare un defacement mirato a SEO spam. Questo tipo di attacco consiste nell'inserire o modificare contenuti e pagine del sito per inserire link e keyword destinati a migliorare artificialmente la posizione di altri siti sui motori di ricerca, una pratica nota come SEO poisoning.
Le conseguenze immediate sono state:
- inserimento di contenuti visibili al pubblico (defacement)
- indicizzazione di contenuti non autorizzati sui motori di ricerca
- errore sul database che ha reso il sito temporaneamente inutilizzabile
- potenziale presenza di backdoor o shell che avrebbero permesso all’attaccante di rientrare anche dopo un ripristino
Un backup ripristinato “alla buona” risolve solo l’aspetto visivo e funzionale, può riportare online il sito, ma non equivale a una gestione dell'incidente e non elimina necessariamente le tracce dell’intrusione.
Perché è successo
Questo tipo di attacco ha successo quando:
- WordPress, plugin o temi non sono aggiornati
- le credenziali admin sono deboli o riutilizzate
- l’hosting condiviso non implementa isolamento tra siti, firewall applicativi (WAF) o monitoraggio dei file
- mancanza di misure di sicurezza attive e/o passive
- mancanza di Sistema di Monitoring/Alerting
È un attacco molto diffuso perché sfrutta configurazioni comuni e superficiali, e può colpire anche siti di piccole amministrazioni senza competenze dedicate.
Come si riconosce un sito compromesso anche da Google
Una cosa che molti sottovalutano è che un sito compromesso non è “sparito” solo perché il contenuto è stato rimosso.
Spesso rimane indicizzato per giorni o settimane sui motori di ricerca.
In questo caso ho documentato anche questa fase con screenshot, oscurando il nome del Comune, proprio per mostrare un punto importante: anche quando il sito sembra tornato normale, la traccia dell’incidente può restare visibile online.
Questo è un aspetto rilevante perché:
- il danno reputazionale continua
- l’utente può ancora raggiungere risultati compromessi dai motori di ricerca
- la cache di Google può mantenere in circolazione contenuti non più presenti sul sito
Per questo il ripristino tecnico non basta: serve anche una pulizia della presenza sui motori di ricerca.
Questo è uno degli indicatori più evidenti di una gestione incompleta dell’incidente: il sito viene ripristinato, ma la sua “traccia compromessa” continua a vivere all’esterno.
Cosa occorre fare in queste situazioni
Al di fuori degli adempimenti burocratici in capo all’ente hackerato, le operazioni tecniche corrette includono:
- Dump e analisi dei dati – preservare ogni evidenza e calcolare hash SHA-256 per garantire integrità
- Valutare il vettore di attacco – capire come gli aggressori hanno ottenuto l’accesso
- Bonifica del sito – rimozione di file malevoli, plugin compromessi e backdoor
- Migrazione da hosting condiviso a VPS – per applicare misure di sicurezza attive (WAF, controllo accessi) e passive (backup, monitoraggio integrità)
- Verifica dati personali – controllare se l’attacco ha coinvolto informazioni soggette a GDPR; se sì, valutare eventuale comunicazione al Garante
- Controllo del dark web – accertarsi che credenziali o contenuti compromessi non siano stati diffusi
- Gestione indicizzazione – rimozione degli URL compromessi dai motori di ricerca e aggiornamento della cache Google tramite Search Console
Perché è importante capire quanto l’attacco sia stato penetrante
Non tutti gli attacchi sono uguali.
Un defacement può sembrare “solo” un problema estetico o reputazionale, ma dietro può esserci molto di più.
Se l’attaccante ha avuto accesso al pannello di amministrazione, al database o ai file del sito, non si può escludere un coinvolgimento di dati personali.
Ed è qui che entra in gioco la valutazione privacy.
Se l’incidente ha comportato accesso, alterazione, indisponibilità o possibile esfiltrazione di dati personali, potrebbe rendersi necessaria una valutazione formale ai fini GDPR e, nei casi previsti, la notifica al Garante.
Il punto non è fare allarmismo. Il punto è che non basta ripristinare il sito: bisogna capire cosa è stato toccato.
In assenza di un’analisi approfondita, escludere a priori il coinvolgimento di dati personali è tecnicamente scorretto. La valutazione non può basarsi su ipotesi, ma su evidenze.
Perché fare analisi del darknet è importante
Un altro aspetto spesso ignorato è la verifica dell’eventuale presenza dei dati compromessi nel dark web.
Per questo si utilizzano strumenti OSINT che permettono di cercare riferimenti a domini, email, credenziali o dataset riconducibili a un determinato ente.
Alcuni strumenti possono segnalare velocemente la presenza di dati associati a un comune o a un dominio nel dark web o in archivi di leak già noti.
Nel caso documentato ho anche raccolto screenshot di questi risultati, oscurando i riferimenti sensibili, proprio per evidenziare un principio fondamentale: un incidente non finisce quando il sito torna online. Se dati o credenziali sono finiti altrove, il rischio prosegue anche dopo il ripristino.
Questo tipo di verifica non è un dettaglio accessorio: è parte della risposta corretta a un incidente, soprattutto quando si lavora su siti istituzionali.
Il ruolo del Comune e del Sindaco
In una situazione del genere il responsabile politico-amministrativo dell’ente è il Sindaco in qualità di legale rappresentante del Comune.
Questo è un passaggio importante, perché significa che il problema non è solo “del tecnico” o “del fornitore”.
È una questione che coinvolge la responsabilità dell’ente nella sua interezza.
Per questo motivo, quando si verifica un incidente, servono:
- tracciabilità delle decisioni
- chiarezza sulle comunicazioni
- preservazione delle evidenze
- valutazione dell’eventuale impatto sui dati personali
Questo implica che le decisioni in materia di sicurezza informatica non possono essere trattate come meri interventi tecnici, ma richiedono consapevolezza e tracciabilità.
Il ripristino “alla buona” può chiudere il problema sul momento, ma non sostituisce una gestione corretta dell’incidente.
Lezione principale
Il rischio non è solo il defacement o il malfunzionamento temporaneo: un sito compromesso può avere conseguenze durature sulla reputazione online, soprattutto se i contenuti rimangono indicizzati dai motori di ricerca.
Questi incidenti mostrano quanto sia cruciale:
- aggiornare costantemente WordPress, plugin e temi
- fare monitoraggio attivo e difesa proattiva
- monitorare i siti con strumenti automatici
- avere una governance ICT attiva, anche quando il sito è gestito da fornitori esterni
- pianificare backup sicuri e strategie di ripristino testate
- trattare eventuali dati sensibili secondo GDPR
- fare formazione e sensibilizzazione interna sull’importanza della sicurezza
Trascurare questo tipo di verifica significa rinunciare a comprendere l’effettiva portata dell’incidente.
Conclusione
In molti casi, l’incidente viene considerato chiuso nel momento in cui si ripristina un backup ed il sito torna online. Dal punto di vista tecnico, è esattamente il momento in cui dovrebbe iniziare la fase più importante: l’analisi.
Gestire un incidente informatico non significa solo ripristinare il backup. Significa:
- cristallizzare le evidenze
- capire come è avvenuta la compromissione
- prevenire recidive
- tutelare utenti, cittadini e dati
Solo un approccio proattivo, tecnico e strutturato può ridurre i rischi e rendere un sito resiliente.
L’obiettivo di questo articolo non è puntare il dito, ma condividere conoscenze e sensibilizzare chi gestisce siti web istituzionali: la cybersecurity non è un optional, è essenziale anche nei comuni più piccoli.
Prevenire è sempre meglio che curare
La vera differenza, però, non la fa la gestione dell’incidente, ma la prevenzione.
Un sito istituzionale non dovrebbe mai essere lasciato su un hosting condiviso senza adeguate misure di sicurezza.
La base minima dovrebbe prevedere:
- infrastruttura su VPS o ambiente isolato
- sistemi di protezione attivi
- sistemi di protezione passivi
- un sistema di monitoring e alerting in grado di notificare immediatamente anomalie, modifiche ai file o comportamenti sospetti
Perché la realtà è semplice: gli attacchi oggi sono automatici, continui e inevitabili.
La differenza la fa quanto una infrastruttura e in grado di difendersi da sola e quanto velocemente ci si accorge di eventuali problemi e come si reagisce.
Se un sito istituzionale viene compromesso e nessuno se ne accorge, il problema non è solo l’attacco in sé, ma l’assenza totale di controllo.
In un contesto pubblico questo non è accettabile: significa esporre cittadini, dati e reputazione dell’ente a rischi evitabili.
Se un sito istituzionale viene compromesso e nessuno se ne accorge, il problema non è solo l'attacco in sé, ma l'assenza totale di controllo.
In un contesto pubblico questo non è solo un limite tecnico, ma un rischio concreto per cittadini, dati e affidabilità dell'ente.
La sicurezza non è un intervento straordinario, ma un processo continuo.
Aggiungi un commento