Il 5 luglio 2026 diversi siti web, anche nel territorio di Terni, hanno mostrato all’improvviso la stessa schermata di rivendicazione: “Hacked by Antonkill”. A prima vista potrebbe sembrare il classico episodio di vandalismo digitale, uno di quegli attacchi che “sporcano” la homepage senza necessariamente rubare dati o cifrare sistemi. In realtà, liquidarlo così sarebbe un errore.
Un defacement è un attacco molto visibile, quasi teatrale. Proprio per questo spesso viene percepito come meno grave di un ransomware o di una violazione silenziosa. Ma quando un sito istituzionale, un ordine professionale o una piattaforma usata da cittadini e iscritti viene sostituita da una pagina di rivendicazione, il problema non è solo estetico. Significa che qualcuno ha trovato una porta aperta, l’ha usata e ha modificato ciò che gli utenti vedono. E, alla luce delle vulnerabilità Joomla emerse nelle ultime settimane, quella porta potrebbe non essere affatto banale.
Chi è Antonkill e perché questo tipo di attacco funziona
Il nome Antonkill compare in archivi pubblici di defacement con migliaia di notifiche associate, molte delle quali classificate come mass defacement. Questo dettaglio aiuta a leggere l’episodio nel modo corretto: non siamo davanti, almeno dalle informazioni disponibili, a un’operazione mirata contro una singola realtà locale, ma a una campagna ampia, automatizzata, costruita per colpire il maggior numero possibile di siti vulnerabili.
È una dinamica tipica del web esposto: bot e script scandagliano la rete alla ricerca di installazioni CMS non aggiornate, estensioni vulnerabili, configurazioni deboli o credenziali amministrative compromesse. Quando trovano una combinazione favorevole, l’attacco parte quasi in automatico. La vittima non viene scelta perché “interessante” in senso strategico. Viene scelta perché raggiungibile, magari attraverso una falla nota in un’estensione molto diffusa.
Il caso Terni: il punto non è la geografia, ma la superficie esposta
Nel caso specifico, l’attenzione si è concentrata anche su alcune realtà del territorio ternano diverse tra loro. Il fatto che siano stati colpiti soggetti così diversi tra loro è indicativo: non emerge, almeno da quanto noto, una motivazione politica o un interesse specifico verso quei contenuti. Il denominatore comune sembra piuttosto tecnico.
Al momento, i siti coinvolti risultano ripristinati e nuovamente accessibili. Questo è certamente un passaggio positivo, ma non esaurisce il tema della sicurezza: dopo un defacement, il ripristino della disponibilità deve sempre essere accompagnato da verifiche tecniche approfondite, per escludere modifiche residue, accessi non autorizzati o meccanismi di persistenza lasciati dall’attaccante.
Quando più siti, anche molto distanti per missione e dimensione, mostrano la stessa firma d’attacco, la spiegazione più probabile è la presenza di vulnerabilità comuni. In questi casi i CMS, e Joomla non fa eccezione, diventano bersagli naturali se non vengono mantenuti con continuità: core non aggiornato, template datati, plugin non più supportati, backup non verificati, permessi troppo permissivi o account amministrativi lasciati lì per anni.
Il contesto rende l’episodio ancora più significativo. A giugno 2026 l’ecosistema Joomla è stato interessato da più vulnerabilità critiche in estensioni molto popolari, accomunate da un punto tecnico estremamente delicato: la possibilità, per un attaccante remoto e non autenticato, di caricare file PHP ed eseguire codice sul server. In pratica, non serve avere un account sul sito. Basta che l’estensione vulnerabile sia presente, esposta e non aggiornata.
Tre falle critiche che hanno cambiato il quadro
Tra le vulnerabilità più rilevanti segnalate nel mese di giugno ci sono quelle che hanno coinvolto JCE, SP Page Builder e iCagenda. Non è corretto attribuire automaticamente il defacement di Terni a una di queste falle senza un’analisi forense dei singoli server, ma il collegamento tecnico è importante: tutte mostrano quanto possa essere rischioso dipendere da estensioni non aggiornate o non controllate con continuità.
JCE, Joomla Content Editor, è stato interessato dalla CVE-2026-48907, una vulnerabilità critica legata a controlli di accesso impropri nella gestione dei profili editor. Secondo gli avvisi tecnici pubblicati, un attaccante non autenticato poteva creare profili editor non autorizzati e abilitare il caricamento di file PHP, arrivando così alla possibile esecuzione di codice arbitrario sul server. La falla è stata indicata come attivamente sfruttata e associata a un punteggio CVSS 10.0.
SP Page Builder è stato invece colpito dalla CVE-2026-48908, anche questa critica. In questo caso il problema riguardava la funzionalità di upload delle icone personalizzate: l’endpoint vulnerabile poteva consentire il caricamento di file PHP senza autenticazione, con conseguente esecuzione di codice remoto. Gli indicatori osservati in alcuni casi includono la creazione di account Super Administrator non riconosciuti, spesso con indirizzi e-mail riconducibili al dominio @secure.local, e la presenza di webshell o file manager PHP in percorsi anomali.
Anche iCagenda, estensione usata per la gestione di eventi, è stata interessata da una vulnerabilità critica di upload arbitrario di file. Il problema riguardava il form frontend di invio eventi, che in determinate versioni poteva accettare allegati senza controlli server-side sufficienti sul tipo di file, permettendo il caricamento e l’esecuzione di una web shell PHP in una directory accessibile via web. La versione corretta indicata dagli advisory è iCagenda 4.0.8.
Come avviene un defacement di questo tipo
Senza un’analisi forense dei server coinvolti non è corretto indicare una singola vulnerabilità come causa certa. Tuttavia, il comportamento osservato è coerente con una catena d’attacco piuttosto comune negli incidenti che riguardano CMS esposti su Internet, soprattutto quando entrano in gioco estensioni vulnerabili che consentono upload di file e remote code execution senza autenticazione.
1. Ricognizione automatizzata
La prima fase è quasi sempre una scansione. Gli attaccanti cercano versioni di Joomla, estensioni installate, percorsi noti, pannelli amministrativi accessibili e segnali che possano indicare una configurazione debole. Non serve “studiare” ogni sito uno per uno: su larga scala bastano strumenti automatici.
2. Sfruttamento della debolezza
Se il sito presenta una falla nota, un componente vulnerabile o credenziali compromesse, l’attaccante può ottenere la possibilità di scrivere codice o modificare contenuti. Nelle vulnerabilità Joomla emerse a giugno, il punto critico è proprio questo: alcune estensioni permettevano il caricamento di file PHP senza login, trasformando un semplice upload in una porta verso l’esecuzione di codice remoto. Il risultato, però, è lo stesso: il sito non è più sotto il pieno controllo del proprietario.
3. Iniezione della schermata di rivendicazione
A quel punto può essere modificata la homepage, un file del template, una risorsa JavaScript o persino una porzione del database. Alcuni casi pubblicamente discussi su forum della community Joomla parlano proprio di codice malevolo inserito nel database o di account amministrativi alterati. Questo è il motivo per cui la bonifica non può limitarsi a cancellare la pagina visibile: bisogna capire dove l’attaccante ha scritto, cosa ha cambiato e se ha lasciato un accesso secondario.
4. Persistenza e rischio di reinfezione
La parte più insidiosa è ciò che non si vede. Un defacement può essere solo la manifestazione finale di una compromissione più ampia. File PHP caricati in directory temporanee, webshell, utenti amministrativi creati ad hoc, permessi modificati o script offuscati possono restare attivi anche dopo il ripristino grafico del sito. È il motivo per cui la patch è indispensabile, ma non basta: chiudere la vulnerabilità non significa rimuovere ciò che l’attaccante ha già lasciato dentro.
Questo aspetto è particolarmente importante nel caso delle campagne automatizzate. I payload possono cambiare nel tempo, gli indicatori di compromissione possono evolvere e una scansione effettuata nei primi giorni potrebbe non intercettare varianti successive. Per questo la bonifica deve essere trattata come un’attività di incident response, non come una semplice manutenzione del CMS.
Perché un defacement non è mai solo un problema d’immagine
Il danno reputazionale è immediato, soprattutto per enti, ordini professionali e organizzazioni che basano parte della propria credibilità sulla fiducia del pubblico. Ma l’impatto operativo può essere persino più concreto: servizi non disponibili, comunicazioni interrotte, utenti che non riescono ad accedere a informazioni o documenti, richieste che arrivano su canali alternativi e personale costretto a gestire l’emergenza.
C’è poi un secondo livello di rischio. Se il sito compromesso serve codice malevolo agli utenti, i browser e i motori di ricerca possono segnalarlo come pericoloso. In quel caso il ripristino tecnico non coincide automaticamente con il ripristino della fiducia: possono servire verifiche, rimozione da blacklist, nuove scansioni e tempo prima che la visibilità organica torni alla normalità.
Cosa fare subito: remediation prima, hardening dopo
La risposta a un incidente di questo tipo dovrebbe seguire una logica semplice: prima contenere, poi capire, poi ripristinare. Mettere il sito in manutenzione o limitarne l’accesso evita che eventuale codice malevolo continui a essere servito agli utenti. Subito dopo servono backup, log e una copia forense dell’ambiente, perché intervenire “a mano” senza conservare evidenze rischia di cancellare informazioni utili.
La bonifica deve includere il controllo dei file del template, delle directory temporanee, dei file modificati di recente, degli utenti amministrativi, delle estensioni installate e del database. Nel caso di vulnerabilità come quelle osservate su JCE, SP Page Builder e iCagenda, è importante cercare anche profili editor anomali, account Super Administrator sconosciuti, file PHP caricati in percorsi media o immagini, webshell, file manager PHP e qualunque modifica non riconducibile all’attività ordinaria del sito. Solo dopo ha senso aggiornare Joomla, rimuovere componenti non necessari, cambiare tutte le credenziali, verificare i permessi e introdurre misure di protezione più robuste.
Per ridurre il rischio di nuovi episodi, alcune misure diventano quasi obbligatorie:
- aggiornamenti regolari del core e delle estensioni,
- autenticazione a più fattori per gli amministratori,
- backup frequenti e soprattutto verificati,
- rimozione dei plugin inutilizzati,
- Web Application Firewall,
- monitoraggio dell’integrità dei file e alert su modifiche sospette.
La documentazione e gli advisory più recenti convergono su un principio molto concreto: aggiornare subito è necessario, ma non sostituisce la bonifica. Se il sito era già stato compromesso prima della patch, l’aggiornamento chiude l’ingresso principale, ma non rimuove automaticamente webshell, account nascosti o backdoor già presenti.
La sicurezza dei CMS è manutenzione, non emergenza
L’attacco attribuito ad Antonkill ricorda una cosa che nel mondo della cybersecurity si ripete spesso, ma che nella pratica viene ancora sottovalutata: un sito web non è un oggetto statico. È un sistema vivo, composto da core, template, plugin, estensioni, configurazioni, credenziali, hosting e processi di manutenzione. Se uno di questi elementi resta indietro, prima o poi entra nel radar di qualcuno.
Il vero tema, quindi, non è solo rimuovere una scritta dalla homepage. È costruire un processo di gestione continua: patch, monitoraggio, backup verificati, controllo degli accessi, rimozione delle estensioni inutilizzate, verifica periodica degli account amministrativi e responsabilità chiare.
Perché il defacement è la parte che vediamo. La vulnerabilità che lo ha reso possibile, invece, era lì già prima.
