03. Subdomain Encoding Flusso Ioc
Subdomain Encoding in dettaglio: flusso operativo e indicatori di compromissione
Subdomain Encoding in dettaglio: flusso operativo e indicatori di compromissione
Il subdomain encoding è la tecnica di DNS exfiltration più osservata nel 2025-2026. In questa lezione ne analizziamo il flusso operativo passo per passo, esaminiamo esempi reali di query malevole e definiamo gli indicatori di compromissione (IOC) più efficaci per il rilevamento.
Il flusso operativo in sei fasi
Per comprendere come funziona concretamente un'operazione di subdomain encoding, seguiamo il percorso completo dall'infrastruttura dell'attaccante fino alla ricostruzione dei dati.
Fase 1: Setup dell'infrastruttura
L'attaccante registra un dominio dall'aspetto innocuo, ad esempio c2-2026[.]xyz. Questo dominio viene configurato con i record NS (Name Server) puntati verso un server DNS autoritativo controllato dall'attaccante. Questo server non è un normale DNS: è un software progettato per loggare ogni query ricevuta e, opzionalmente, rispondere con comandi.
Fase 2: Preparazione dei dati sul target
Il malware sul sistema compromesso identifica i dati da esfiltrare — file, credenziali, token, screenshot — e li suddivide in chunk da circa 50-63 caratteri. Il limite di 63 caratteri corrisponde alla lunghezza massima di una singola label DNS secondo RFC 1035.
Fase 3: Encoding
Ogni chunk viene codificato in Base32, scelto perché è case-insensitive e utilizza solo caratteri compatibili con i nomi DNS (A-Z, 2-7). Base64 standard sarebbe più efficiente in termini di spazio, ma include caratteri come + e / che non sono validi nei nomi di dominio.
Fase 4: Costruzione e invio della query
Il malware costruisce query DNS con questa struttura:
[chunk_codificato].[session_id].[chunk_number].[dominio_c2]
Esempio concreto:
aXNhY3JlZGl0Y2FyZA==.sess-8f3d2a1b.chunk017.c2-2026[.]xyz
Questa query viene inviata al resolver DNS aziendale come una normale richiesta di risoluzione. Il resolver, non avendo la risposta in cache, la inoltra ricorsivamente fino a raggiungere il server autoritativo dell'attaccante.
Fase 5: Ricezione e ricostruzione
Il server DNS malevolo riceve la query, estrae il chunk codificato dal campo QNAME, lo decodifica e lo salva. Utilizzando il session ID e il chunk number, ricostruisce il file originale pezzo per pezzo, nell'ordine corretto.
Fase 6: Canale di ritorno (opzionale)
Per comunicazioni bidirezionali (C2), il server può rispondere con comandi inseriti in record TXT o CNAME. Il malware legge la risposta DNS e la interpreta come istruzione operativa.
Il diagramma concettuale del flusso:
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ Sistema │ Query │ Resolver DNS │ Query │ Server DNS │
│ compromesso │────────→│ aziendale │────────→│ malevolo │
│ │ │ (ricorsivo) │ │ (autoritativo) │
│ File → chunk │ │ │ │ │
│ → Base32 │ │ Inoltra la │ │ Logga query │
│ → DNS query │ │ query │ │ Ricostruisce │
│ │←────────│ │←────────│ file │
│ (legge risposta)│ Risposta│ │Risposta │ (invia cmd) │
└─────────────────┘ └──────────────────┘ └─────────────────┘
Esempi reali di query malevole (2025-2026)
Analizzando il traffico DNS catturato in incidenti reali del biennio 2025-2026, emergono pattern ricorrenti:
Esempio 1 — Esfiltrazione di token JWT:
dG9rZW46ZXlKaGJHVmxjbk5sY25acGJtY3VJanAuZXlKcGMzTmxjblpsY25ObGNu
WnBZMlZrSWpvaU1qQXlNekl3TURJd01EazJNaXdpYVdGMElqb3hOVEkzTURJd01q
azJMQ0p3YVdGMElqb3hOVEkzTURJd01qazJMQ0p3WlhKMElqb3hOVEkzTURJd01q
azI.token-2026.c2-live[.]net
Si nota chiaramente la stringa Base64 nel subdominio, con la struttura tipica di un token JWT codificato.
Esempio 2 — Esfiltrazione di credenziali:
cmdb64-NTlmZG9tYWluXHVzZXI6cGFzczEyMw==.beacon-47a9.c2-2026[.]cloud
Il prefisso cmdb64- indica il tipo di dato, seguito dalla credenziale codificata in Base64 (dominio\user:pass123).
Esempio 3 — Esfiltrazione di hash Kerberos:
sess_9f8d2c1e_krbtgt_hash_part1==.exfil.chunk003.evil-ns[.]top
Qui il naming è più esplicito, con riferimenti diretti a krbtgt_hash, indicando l'esfiltrazione di materiale crittografico Active Directory.
Indicatori di compromissione (IOC) più efficaci nel 2026
Per rilevare il subdomain encoding e altre forme di DNS exfiltration, gli analisti devono monitorare i seguenti indicatori:
Volume anomalo: più di 400-800 query/ora verso lo stesso dominio di secondo livello è altamente sospetto. Un endpoint normale non genera questo volume verso un singolo dominio.
Lunghezza FQDN: query con FQDN superiore a 180-220 caratteri sono quasi certamente malevole. Le query DNS legittime raramente superano i 60-80 caratteri.
Entropia elevata nei subdomini: stringhe pseudo-random nei subdomini indicano dati codificati. L'entropia di Shannon superiore a 4.0-4.5 su una label è un forte indicatore.
Pattern Base32/Base64 ricorrenti: la presenza sistematica di stringhe che terminano con = o == (padding Base64) è un segnale chiaro.
Basso tasso di NXDOMAIN: se quasi tutte le query verso un dominio risolvono con successo, significa che esiste un server autoritativo malevolo che risponde a qualsiasi subdominio. In condizioni normali, query verso subdomini casuali produrrebbero molti NXDOMAIN.
Molte label nello stesso dominio: query con più di 8-10 label (segmenti separati da punti) sono altamente sospette.
Questi IOC, combinati in regole di correlazione, forniscono una capacità di detection significativa anche senza strumenti di analisi comportamentale avanzata.