Punti di forza
- I file SVG non sono dati immagine binari come i JPEG o i PNG. Sono basati su XML e possono contenere script eseguibili che il browser eseguirà immediatamente all'apertura.
- Secondo il “Phishing Trends Report 2026” di Hoxhunt, nel 2025 gli allegati SVG dannosi sono aumentati di cinquanta volte rispetto al 2024 e ora rappresentano il terzo tipo più diffuso di allegato dannoso nelle e-mail a livello globale.
- Ogni payload SVG è personalizzato in base all'indirizzo e-mail del destinatario. La destinazione del reindirizzamento viene suddivisa e crittografata su più variabili, per poi essere ricomposta solo in fase di esecuzione, risultando incomprensibile a qualsiasi scanner che legga il file in modo statico.
- Il rilevamento tradizionale si basa sul riconoscimento di modelli di attacco noti, sia tramite firme che tramite metodi euristici.
- La tecnologia Deep CDR™ rimuove i contenuti attivi dai file immagine supportati prima che raggiungano l'utente, indipendentemente dal fatto che la minaccia sia già stata rilevata in precedenza. Non sono necessarie né firme né un'esposizione precedente.
Nessuna macro. Nessun eseguibile. Solo un'immagine in grado di eseguire uno script.
Il 2 giugno 2026, Xavier Mertens, responsabile del SANS Internet Storm Center, ha pubblicato un’analisi su una nuova campagna di phishing che da diversi giorni arrivava nella sua casella di posta. L’allegato di ogni e-mail era un file SVG, il tipo di file che la maggior parte delle persone associa a icone, illustrazioni e grafica web. Nulla in esso faceva pensare a una minaccia.
Facendo doppio clic sull'elemento si apriva il browser predefinito, lo script incorporato veniva eseguito in modo invisibile e il browser reindirizzava a una pagina dedicata al furto di credenziali, personalizzata in base all'indirizzo e-mail del destinatario. Non c'era alcun indizio che fosse successo qualcosa, finché non era ormai troppo tardi.
L'attacco non ha richiesto alcun software speciale, nessun documento con macro abilitate e nessuna autorizzazione da parte dell'utente oltre al semplice istinto di aprire un allegato. L'intero meccanismo si basava su un presupposto comune: che un file immagine sia intrinsecamente a basso rischio.
Il JPEG visualizza. L'SVG esegue. È proprio questa la differenza.
È comprensibile ragionare in questo modo. I file JPEG e PNG vengono rappresentati come dati pixel, il che ne limita la superficie di attacco a livello di file.
L'SVG è diverso. È scritto in XML (Extensible Markup Language), lo stesso linguaggio di marcatura alla base delle pagine web, il che significa che un file SVG può contenere tag di script, elementi di ancoraggio e altri contenuti web attivi che un browser elabora allo stesso modo di qualsiasi pagina web.
È proprio questa la vulnerabilità che gli autori degli attacchi stanno sfruttando. I file della campagna analizzata da Mertens non contenevano alcun contenuto grafico. Si trattava esclusivamente di codice: JavaScript offuscato racchiuso in un involucro SVG il più sottile possibile, in cui il contenitore SVG esisteva per un unico motivo: raggiungere il browser della vittima pur venendo classificato come allegato immagine dal gateway di posta elettronica.
Perché la questione è diventata così urgente
L'uso dell'SVG come vettore di attacco non è una novità, ma il suo impiego su larga scala ha subito un'accelerazione. I ricercatori hanno documentato la presenza di allegati SVG dannosi nelle e-mail già a partire dal 2017 circa, il che solleva l'ovvia domanda: cosa è cambiato per rendere questo fenomeno un problema degno di discussione proprio oggi?
Sono cambiate due cose, principalmente.
In primo luogo, la portata del fenomeno è cambiata radicalmente. Gli allegati SVG dannosi sono aumentati di cinquanta volte nel 2025 rispetto al 2024 (Hoxhunt 2026 Phishing Trends Report) e, in una singola campagna nel febbraio 2026, Microsoft ha rilevato l’invio di 1,2 milioni di messaggi di phishing basati su SVG a oltre 53.000 organizzazioni in 23 paesi. La tecnica non è nuova, ma lo è la sua adozione su larga scala.
In secondo luogo, il panorama della sicurezza informatica ha subito cambiamenti che hanno reso il formato SVG più allettante. Nel 2022 Microsoft ha disabilitato per impostazione predefinita le macro di Office, le minacce basate sui file PDF sono state sottoposte a un controllo più rigoroso e il formato SVG è arrivato su molti gateway con una storia di reputazione relativamente pulita; ciò ha fatto sì che gli autori degli attacchi, seguendo la via della minore resistenza, trovassero rapidamente il formato SVG molto allettante.
La tecnica di elusione documentata da Mertens è sottile. Il codice JavaScript incorporato nel file SVG viene dichiarato utilizzando il tipo “application/ecmascript” anziché lo standard “text/javascript” e, sebbene i browser trattino entrambi in modo identico ed eseguano gli script contrassegnati con entrambi i tipi, la divergenza tra ciò che i browser accettano e ciò che gli strumenti di sicurezza controllano è proprio il punto in cui avviene l’attacco.
Quando nel 2022 la RFC 9239 ha aggiornato lo standard, i fornitori di soluzioni di sicurezza si sono adeguati e hanno rimosso "application/ecmascript" dai propri elenchi di controllo. I browser, progettati per garantire la retrocompatibilità, hanno continuato comunque a eseguirlo. Lo standard indicava che quel tipo era stato ritirato. I browser non ne sono mai stati informati.
Il risultato è una lacuna persistente. "application/ecmascript" non è un identificatore nuovo o oscuro, ma ha una storia che risale ai primi anni 2000. Non sono stati gli aggressori a inventarlo. Hanno semplicemente notato che la transizione prevista dall’RFC ha creato un’asimmetria tra i browser che mantengono il vecchio comportamento e gli scanner che applicano il nuovo standard, e tale asimmetria non si risolve da sola. Qualsiasi gateway che non abbia esplicitamente reinserito nelle proprie regole di ispezione gli alias MIME ECMAScript deprecati rimane esposto, non perché sia obsoleto, ma perché ha implementato uno standard che i browser non hanno seguito.
Come l'attacco viene personalizzato per arrivare nella posta in arrivo
L'indirizzo del destinatario viene codificato in Base64 e incorporato direttamente nel payload SVG; ciò significa che ogni singolo allegato di questa campagna genera un URL di phishing unico e personalizzato, destinato a un destinatario specifico, a un costo pressoché nullo.
Questo livello di personalizzazione è importante perché elude i meccanismi euristici che individuano le campagne generiche, poiché non vi sono contenuti ripetuti, né URL di reindirizzamento condivisi, né schemi ricorrenti tra i destinatari, come invece accade nel phishing di massa.
La destinazione del reindirizzamento viene codificata in Base64 e poi crittografata utilizzando una chiave generata al momento dell'esecuzione a partire da due variabili distinte. Non si tratta di una crittografia sofisticata, ma ciò che la rende efficace contro gli scanner automatici è proprio il processo di generazione della chiave.
I sistemi di rilevamento che tentano di invertire l’offuscamento devono conoscere sia l’algoritmo che la chiave, e la chiave in questo caso non esiste come valore singolo in nessuna parte del file. È suddivisa tra due variabili e concatenata solo al momento dell’esecuzione, il che significa che uno scanner non può ricostruire l’URL di destinazione senza prima risolvere l’assembly di runtime, e ciò richiede l’esecuzione dello script anziché la sua semplice lettura. L’analisi statica fornisce pochi segnali utilizzabili e il payload diventa leggibile solo all’interno di un ambiente browser attivo, che è esattamente il luogo in cui la maggior parte delle ispezioni a livello di gateway non avviene.
Ogni singolo livello di elusione potrebbe essere individuato, ma, se combinati tra loro, un formato di allegato classificato come immagine, un tipo MIME obsoleto, un payload crittografato e un dominio di destinazione su un dominio di primo livello con una storia di abusi limitata contribuiscono ad aumentare in modo significativo la probabilità di raggiungere la posta in arrivo.
Il tuo gateway non ha fallito. L'attacco è riuscito a eludere il sistema di rilevamento.
La sicurezza della posta elettronica basata sul rilevamento si fonda su una domanda fondamentale: questo file corrisponde a una minaccia nota o riconoscibile? La sua efficacia dipende dalle conoscenze pregresse, acquisite tramite firme o modelli comportamentali.
Tale dipendenza rappresenta il limite strutturale che questa campagna mette in luce. L’accumulo di tecniche di offuscamento fa sì che ci sia davvero poco da rilevare per uno scanner, mentre la classificazione come SVG implica che il file potrebbe non essere sottoposto allo stesso livello di controllo di un documento Office o di un file eseguibile. Se il vostro gateway classifica l’SVG come formato immagine e applica di conseguenza un’ispezione meno approfondita, è probabile che questa campagna non sia stata individuata a livello di gateway. Si tratta di un caso in cui l’attacco opera al di fuori di ciò che i sistemi di rilevamento sono in grado di valutare.
Non si tratta di sostenere che il rilevamento non funzioni. Funziona bene contro le minacce note, e nessuna architettura di sicurezza della posta elettronica è efficace senza di esso. La domanda è: cosa succede con minacce del tutto nuove che i sistemi di rilevamento non hanno mai incontrato prima?
"Prevenzione prima di tutto" significa rimuovere preventivamente tutti i contenuti attivi
Un approccio incentrato sulla prevenzione introduce una risposta complementare a quella di rilevamento: questo file contiene ancora contenuti attivi?
La tecnologia Deep CDR™ non cerca di stabilire se un file sia dannoso. Piuttosto, lo scompone, rimuove eventuali elementi potenzialmente dannosi o non conformi alle politiche aziendali e fornisce una versione pulita e utilizzabile. Nel caso di un file SVG contenente uno script attivo, ciò significa che l’utente riceve un file che viene visualizzato come previsto, qualora vi siano contenuti grafici legittimi, ma senza lo script che consente l’attacco.
Questo approccio è stato confermato dal primo punteggio assoluto del 100% ottenuto nel test di neutralizzazione e ricostruzione dei contenuti condotto da SE Labs, che ha riconosciuto la tecnologia Deep CDR™ come la prima soluzione CDR in assoluto a raggiungere un punteggio del 100% sia in termini di protezione che di accuratezza.
Non tutte le minacce vengono neutralizzate dalla sola sanificazione. I payload evasivi, ovvero file progettati per apparire innocui durante l’analisi statica e attivarsi solo in fase di esecuzione, richiedono un’ispezione comportamentale che vada oltre quanto coperto dalla sanificazione. MetaDefender colma questa lacuna attraverso l’analisi dinamica in sandbox, mettendo in luce i comportamenti dannosi tramite emulazione e fornendo un unico verdetto affidabile. Con un tasso di rilevamento degli attacchi zero-day del 99,9%, Aether affronta l’esposizione residua che la sanificazione e la scansione multipla da sole non sono in grado di gestire.
Un modello da tenere d'occhio al di là dell'SVG
L'SVG è solo l'esempio più recente, ma non sarà l'ultimo. Il fenomeno va ben oltre l'SVG: qualsiasi formato di file che appaia legittimo ma che nasconda contenuti eseguibili è suscettibile di subire lo stesso trattamento.
Gli allegati HTML consentono di far passare di nascosto i payload attraverso i gateway. I codici QR incorporati nei PDF reindirizzano a pagine volte al furto di credenziali. I payload steganografici si nascondono all’interno dei metadati delle immagini. In ciascuno di questi casi, il file è esattamente ciò che dichiara di essere a livello strutturale, pur contenendo contenuti che il controllo di classificazione a livello superficiale non è mai stato progettato per individuare.
La lezione da trarre non è che un formato specifico sia pericoloso, bensì che l’affermazione «questo file sembra innocuo» non costituisce più una motivazione valida per le decisioni relative alla consegna. Quando un file supera tutti i controlli di rilevamento, dovrebbe essere consegnato automaticamente o dovrebbe comunque essere sottoposto a sanificazione?
Come OPSWAT un approccio multilivello alla Email Security
Ogni giorno gli autori degli attacchi agiscono partendo dal presupposto che il rilevamento rappresenti l’ultima linea di difesa. Per noi, invece, esso fa parte di un approccio multilivello che combina diverse tecnologie per massimizzare la sicurezza perimetrale dei nostri clienti. MetaDefender™ Email Security applica questa logica a due modelli di implementazione:
- MetaDefender™ Email Gateway Security viene implementata in locale come software a livello SMTP/MX. La tecnologia Deep CDR™, compatibile con oltre 200 tipi di file, rimuove i contenuti attivi da ogni allegato ed esegue una scansione ricorsiva degli archivi annidati per una sanificazione approfondita, mentre Multiscanning Metascan™ Multiscanning, che utilizza oltre 30 motori antivirus, esegue il rilevamento in parallelo; l’intelligenza artificiale predittiva Alin AI fornisce in pochi millisecondi un verdetto sulla presenza di minacce nell’allegato senza necessità di esecuzione, la tecnologia sandbox MetaDefender copre i payload evasivi che richiedono un’analisi comportamentale più approfondita, mentre la tecnologia Proactive DLP™ previene le fughe di dati alla fonte su oltre 125 tipi di file.
- MetaDefender™ Cloud Email Security applica lo stesso approccio incentrato sulla prevenzione all’interno degli ambienti Microsoft 365 senza modifiche ai record MX, senza hardware e senza interruzioni del flusso di posta. La tecnologia Deep CDR™, MetaDefender , Multiscanning Metascan Multiscanning un massimo di 17 motori antivirus e l’intelligenza artificiale predittiva Alin AI ispezionano e sanificano ogni allegato delle e-mail in entrata e in uscita, compresi i file crittografati, prima che raggiungano l’utente.
