Phishing bancario: l'evasione via IPv4-mapped…

Campagna phishing contro e-banking belga sfrutta la sintassi IPv4-mapped IPv6 in notazione compressa per bypassare controlli regex e nascondere la traccia DNS.

Una campagna di phishing attiva contro un servizio di e-banking belga utilizza indirizzi IPv4-mapped IPv6 in notazione compressa per eludere controlli di sicurezza basati su regex e cancellare ogni traccia DNS. L'incidente, documentato il 19 giugno 2025 dall'handler senior Xavier Mertens dell'Internet Storm Center (ISC SANS), dimostra come la conformità rigorosa a uno standard RFC possa diventare arma di evasione nelle mani di un attaccante.

Punti chiave

L'URL malevolo impiega la sintassi ::ffff:5511:74be, che per RFC 4291 rappresenta l'indirizzo IPv4 85.17.116.190 mappato in formato IPv6
La bracket notation [...] indica al parser URL un literal IPv6, bypassando regex semplici progettati per estrarre nomi dominio
Non esiste alcun record DNS associato all'indirizzo, eliminando un intero layer di rilevabilità e intelligence
Il reindirizzamento finale carica il phishing kit su verificatie.qzz.io, con path che suggerisce targeting di istituto bancario belga

Come funziona la notazione che inganna il parser

L'indirizzo osservato nell'URL malevolo è https://[::ffff:5511:74be]. La sintassi, apparentemente arcana, è tecnicamente valida e ben definita. Come documenta Mertens, il prefisso ::ffff: segnala un IPv4-mapped IPv6 address, formalizzato nella Sezione 2.5.5 dell'RFC 4291.

I due gruppi esadecimali finali, 5511 e 74be, corrispondono agli ottetti IPv4 85, 17, 116 e 190: 0x55=85, 0x11=17, 0x74=116, 0xbe=190. L'indirizzo sottostante è quindi 85.17.116.190, un IPv4 ordinario travestito da IPv6.

Il meccanismo di evasione si attiva a monte. Le parentesi quadre [...] obbligano il parser URL a interpretare il contenuto come indirizzo IPv6 letterale, non come nome dominio. I controlli di sicurezza che estraggono domini o IP tramite regex semplificate — pensate per catturare stringhe alfanumeriche puntate o ottetti decimali — non riconoscono la struttura. Il filtro vede un formato che non matcha i pattern attesi, e lascia passare.

"The technique used by the attacker is to bypass simple security controls trying to extract domain names and IP addresses via simple regular expressions. The notation "[…]" tells the URL parser that what's inside is a literal IPv6 address. But it's not a real IPv6 address." — Xavier Mertens, Senior ISC Handler

Il vantaggio dell'assenza di DNS

Una conseguenza immediata della tecnica è la cancellazione del DNS dal percorso dell'attacco. Come rileva Mertens: "there is no DNS record!" — un vantaggio operativo per l'attaccante, non un difetto. Senza richieste di risoluzione, non ci sono query ricorsive da monitorare, non ci sono record passivi da analizzare, non ci sono sinkhole o blacklist reactive da attivare.

L'URL non risolve tramite nome: si connette direttamente all'indirizzo IP sottostante. Per i team che basano il monitoraggio su log DNS, query anomale o domain reputation, questo vettore è invisibile per costruzione. Il gap non è tecnico ma architetturale: il parser URL fa il proprio dovere, e nel farlo rimuove un intero strato di osservabilità.

L'infrastruttura di reindirizzamento e il possibile target

L'URL IPv6 osservato non ospita direttamente il contenuto fraudolento: effettua un reindirizzamento a https://3439-aanmelden.verificatie.qzz.io/mon-belfius. Il dominio qzz.io funge da hosting del phishing kit finale. Il path /mon-belfius suggerisce un targeting del servizio bancario Belfius, istituto maggiore del Belgio, anche se la fonte non dichiara esplicitamente il nome dell'istituto.

Il dominio verificatie.qzz.io — con il sottodominio in olandese "verificatie" (verifica) — indica una progettazione linguistica mirata al mercato fiammingo-belga. Il prefisso numerico 3439- nel sottodominio potrebbe servire a istanziare kit multipli o a tracciare segmenti di campagna. Il dossier non specifica lo stato attuale del dominio né eventuali azioni di takedown.

Cosa fare adesso

Le azioni seguenti derivano direttamente dall'analisi di Mertens e dalla struttura dell'incidente documentato:

Verificare i parser URL nei tool di sicurezza. I controlli che estraggono domini o IP tramite regex semplici devono essere testati contro la sintassi IPv4-mapped IPv6. La notazione [::ffff:xxxx:xxxx] con bracket notation deve essere esplicitamente inclusa nei pattern di matching o gestita come caso a parte.

Monitorare le connessioni dirette a IP letterali. Le connessioni HTTPS a indirizzi IPv6 bracket notation in email o log di proxy meritano ispezione manuale, specialmente se seguite da redirect. L'assenza di query DNS non implica assenza di traffico sospetto.

Analizzare i path di redirect per indicatori di targeting. Il pattern /mon-[istituto] o sottodomini linguistici regionali come verificatie possono segnalare campagne mirate prima che emergano report pubblici. Il prefisso numerico 3439- suggerisce che kit multipli siano attivi su sottodomini variabili.

Valutare il coverage dei feed di threat intelligence. Se l'intelligence si basa su indicatori DNS-based, gli URL IPv4-mapped IPv6 sfuggono per costruzione. È necessario integrare fonti che monitorino attivamente gli IP sottostanti o i domini di landing post-redirect.

Perché è importante

Il dossier non documenta la scala della campagna né il numero di potenziali vittime. Non emergono sovrapposizioni infrastrutturali che colleghino l'attore a gruppi noti allo stato attuale. La fonte non specifica se i controlli bypassati siano endpoint security, email gateway o altri layer difensivi, né se la tecnica sia già stata osservata in campagne precedenti.

Il brief non elenca misure correttive specifiche né raccomandazioni operative testuali dalla fonte primaria. Non è documentato se l'implementazione dei parser URL nei browser, nelle librerie di networking o nei tool di sicurezza gestisca uniformemente la sintassi IPv4-mapped IPv6, o se esistano discrepanze tra stack software che amplifichino il problema. Il dossier non specifica inoltre la natura dei dati eventualmente esposti o il successo dell'attacco in termini di credenziali compromesse.

Ciò che il caso rende leggibile è un pattern sistemico: la tensione tra conformità standard e sicurezza operativa. Gli RFC sono progettati per l'interoperabilità, non per la resilienza contro attori malevoli. Quando un parser "corretto" per costruzione abbatte un controllo "semplificato" per necessità, l'attaccante sfrutta un disallineamento strutturale, non una vulnerabilità patchabile.

FAQ

È una vulnerabilità software o una tecnica di evasione?

Il dossier la classifica come tattica di evasione, non come vulnerabilità con CVE associabile. Il parser URL funziona come specificato; il controllo di sicurezza non copre il caso.

Possono i filtri regex essere aggiornati per coprire questa sintassi?

La fonte non fornisce indicazioni tecniche in merito. L'evidence map mostra che la complessità della notazione IPv6 — con compressione zero, formati mappati e bracket notation — rende i pattern regex semplici intrinsecamente incompleti, ma non propone soluzioni alternative.

Il dominio qzz.io è ancora attivo?

Il dossier non documenta lo stato del dominio né eventuali azioni di takedown al momento della pubblicazione.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti