Nascondersi dietro domini legittimi: Domain Fronting (T1090.004)

Il domain fronting è una delle tecniche più sottili da dimostrare in un engagement red team, perché richiede la comprensione dell'architettura CDN e la capacità di identificare coppie di domini che condividono la stessa infrastruttura. Il primo passo è sempre l'enumerazione dei domini "frontabili".

Per identificare domini che condividono lo stesso edge CDN, puoi effettuare ricerche DNS mirate. Con nslookup o dig verifica che due domini risolvano verso lo stesso blocco di indirizzi IP di una CDN nota:

dig +short dominio-legittimo.com dig +short dominio-target.com

Se entrambi puntano a range della stessa CDN (ad esempio Cloudfront, Azure CDN o Fastly), hai una coppia candidata. Uno strumento utile per automatizzare questa ricerca è FindFrontableDomains (open source), uno script PowerShell che enumera i domini ospitati su CDN comuni verificando la risoluzione DNS e i certificati.

Per testare manualmente il fronting con curl, il comando è diretto:

curl -s -H "Host: dominio-c2-reale.com" https://dominio-facciata-legittimo.com/path

Questo invia una richiesta TLS verso il dominio di facciata, ma l'header Host indirizza il CDN verso il server C2. Osserva la risposta: se ricevi contenuto dal server C2 anziché dal dominio di facciata, il fronting funziona.

Cobalt Strike (a pagamento) supporta nativamente il domain fronting. Nel profilo Malleable C2, configura il parametro set header "Host" "dominio-c2.com"; all'interno del blocco http-get o http-post, specificando il dominio di facciata come indirizzo di destinazione nel listener HTTPS. Il beacon si connetterà al dominio legittimo visibile in rete, mentre il CDN instraderà il traffico al tuo teamserver.

Mythic (open source) offre un approccio analogo attraverso i profili di comunicazione personalizzati. Configura custom headers nella definizione del C2 profile HTTP, impostando l'header Host sul dominio reale e il target di connessione sul dominio di facciata.

Per la variante domainless fronting, testa con:

curl -s --resolve dominio-facciata.com:443:<IP_CDN> -H "Host: dominio-c2.com" https://dominio-facciata.com/ --connect-to ::dominio-facciata.com:

Il tool meek (open source), un plugin di trasporto per Tor, è stato documentato proprio in combinazione con APT29 per nascondere traffico C2. In laboratorio puoi configurare meek-client specificando il dominio di facciata e il dominio reale del bridge, osservando come il traffico risultante appaia identico a normali richieste HTTPS verso un servizio CDN legittimo.

Un test di validazione utile: cattura il traffico con Wireshark (open source) e verifica che il campo SNI nel ClientHello TLS mostri solo il dominio di facciata, senza alcuna traccia del dominio C2.

Il cuore della detection per il domain fronting risiede in un'unica osservazione: il mismatch tra il campo SNI nell'header TLS e il campo Host nell'header HTTP. Sembra semplice, ma richiede la capacità di ispezionare il traffico HTTPS — il che significa disporre di un'infrastruttura di SSL/TLS Inspection (M1020) configurata nei punti chiave della rete.

Su ambienti Windows, le log source primarie sono NSM:Connections e Sysmon (open source). Sysmon con EventID 3 (Network Connection) permette di correlare il processo che inizia la connessione HTTPS con l'indirizzo di destinazione. Se il tuo proxy o firewall next-gen può esportare il campo SNI estratto dal ClientHello — operazione possibile senza decifratura completa — confrontalo con l'Host header disponibile solo dopo TLS inspection. Quando i due differiscono, hai un indicatore ad alta fedeltà.

La regola di detection DET0196 si articola su quattro ambienti. Per tutti vale un principio comune: definisci una CDN allowlist dei domini frontali legittimi della tua organizzazione (tipicamente il tuo CDN aziendale) e segnala qualsiasi mismatch SNI/Host che coinvolga domini non in lista. Il tuning critico è il parametro SNIHostMismatch: alcune applicazioni legittime utilizzano architetture multi-dominio su CDN, quindi serve stabilire una soglia di tolleranza basata sul traffico di baseline.

Su Linux, concentra l'attenzione sui log auditd:SYSCALL per tracciare le system call di connessione e correla con i flussi di rete (NSM:Flow). Un indicatore particolarmente forte è la variante domainless fronting: sessioni TLS con campo SNI vuoto sono estremamente rare nel traffico legittimo. Configura un alert dedicato per SNIFieldAbsent con soglia molto bassa — qualsiasi sessione TLS senza SNI merita indagine.

Per macOS, i log unificati (macos:unifiedlog) combinati con query osquery (open source) permettono di identificare i binari non firmati che iniziano sessioni HTTPS con anomalie SNI/Host. Il tuning UnsignedBinary è cruciale: un'applicazione priva di firma digitale che effettua connessioni HTTPS verso CDN con mismatch è un forte segnale di compromissione.

L'ambiente ESXi merita attenzione speciale. Un host ESXi non dovrebbe quasi mai iniziare connessioni HTTPS in uscita, men che meno verso CDN. Il parametro AdminPortAccess dovrebbe avere soglia prossima a zero: qualsiasi traffico HTTPS originato dall'interfaccia di gestione ESXi verso l'esterno è anomalo per definizione.

Per ridurre i falsi positivi, integra il contesto del processo (ProcessInitiator): scripting engines come powershell.exe, wscript.exe, binari sconosciuti o LOLBins che generano traffico frontato sono priorità alta. Applicazioni note come browser e client di aggiornamento software sono più probabilmente legittimi.

L'analisi forense del domain fronting presenta una sfida peculiare: il traffico malevolo è nascosto dentro sessioni HTTPS che, dall'esterno, sembrano del tutto normali. La chiave è ricostruire la catena dal processo all'endpoint di rete, passando per artefatti che l'attaccante non può facilmente eliminare.

Sul versante rete, se disponi di catture PCAP full-packet con TLS inspection, l'artefatto primario è la discrepanza tra il campo SNI nel messaggio ClientHello e l'header Host nella richiesta HTTP decifrata. Con Wireshark (open source) puoi filtrare il traffico TLS con il filtro display tls.handshake.extensions_server_name per estrarre tutti i valori SNI e confrontarli sistematicamente con gli Host header corrispondenti. Anche senza TLS inspection, analizza i pattern di connessione: sessioni HTTPS ripetitive verso nodi CDN con cadenza regolare (beaconing) sono sospette, specialmente se il volume di dati trasferiti è anomalo rispetto al contenuto atteso dal dominio di facciata.

Su Windows, la ricostruzione della timeline parte dai log Sysmon. L'EventID 3 documenta ogni connessione di rete con il processo sorgente, il PID, l'indirizzo di destinazione e la porta. Correla questi eventi con l'EventID 1 (Process Create) per ricostruire la genealogia del processo che ha iniziato la connessione frontata. Se il processo è un beacon Cobalt Strike o un agente SMOKEDHAM, troverai tipicamente un binario non firmato o un processo legittimo iniettato che mantiene connessioni persistenti verso IP appartenenti a range CDN.

Cerca nei registri di sistema e nei file di configurazione degli agenti malevoli i domini hardcoded. SMOKEDHAM utilizza domini frontati hardcoded nel proprio codice — l'estrazione delle stringhe dal binario con strings (open source, incluso in GNU binutils) o con FLOSS (open source) può rivelare sia il dominio di facciata che il dominio C2 reale.

Su Linux, gli artefatti di auditd catturano le syscall connect() con gli indirizzi di destinazione. Correla con i log di rete per identificare sessioni anomale. Verifica la cronologia dei comandi (.bash_history) per eventuali invocazioni di meek o configurazioni di proxy che implementano il fronting.

Per quanto riguarda il tool meek, usato da APT29 in combinazione con Tor, cerca artefatti specifici: file di configurazione del trasporto Tor nella directory dell'utente, processi meek-client nella timeline di esecuzione, e connessioni verso noti domini di facciata utilizzati storicamente dal progetto meek (tipicamente servizi cloud di grandi provider). La presenza di meek-client su un sistema aziendale è di per sé un indicatore di compromissione significativo.

Per la timeline finale, ordina cronologicamente: prima esecuzione del processo malevolo → prima connessione verso IP CDN → pattern di beaconing stabilizzato → eventuali download di payload secondari attraverso il canale frontato.

Il domain fronting occupa una posizione particolare nel panorama delle tecniche di Command and Control: è sofisticato nella concezione ma relativamente semplice nell'implementazione, il che lo rende appetibile sia per gruppi APT di alto livello sia per operatori meno esperti che sfruttano framework pronti all'uso.

APT29 è il gruppo documentato più significativo nell'uso di questa tecnica. Il collettivo, attribuito a operazioni di intelligence di matrice russa, ha impiegato il plugin meek per Tor specificamente per mascherare il traffico C2 dietro domini CDN legittimi. Questa scelta riflette il modus operandi tipico di APT29: privilegiare la furtività e la persistenza a lungo termine rispetto alla velocità operativa. L'uso di meek con Tor aggiunge un doppio livello di offuscamento — il fronting nasconde la natura del traffico, mentre Tor anonimizza la destinazione finale. Questo pattern è coerente con operazioni orientate allo spionaggio dove il mantenimento dell'accesso nel tempo è prioritario rispetto all'esfiltrazione rapida.

L'ecosistema software che supporta il domain fronting rivela pattern interessanti. Cobalt Strike e Mythic rappresentano i due poli del tooling offensivo: il primo è un framework commerciale diffusissimo nei red team e adottato massivamente da attori sia statali che criminali, il secondo è un framework open source modulare con crescente adozione. Entrambi supportano il fronting nativamente attraverso la manipolazione degli header HTTP nei profili C2, abbassando drasticamente la barriera d'ingresso per gli operatori.

SMOKEDHAM merita attenzione particolare perché implementa il domain fronting con domini hardcoded nel binario — un approccio meno flessibile ma che suggerisce operazioni mirate dove l'infrastruttura CDN è stata pre-selezionata e testata prima del deployment. Questo indica una fase di preparazione significativa prima dell'attacco effettivo.

Dal punto di vista predittivo, il domain fronting presenta un'evoluzione interessante. Diversi provider CDN hanno iniziato a implementare controlli per prevenire il fronting, verificando la corrispondenza SNI/Host. La variante domainless fronting (SNI vuoto) è emersa come risposta diretta a queste contromisure. È ragionevole attendersi che gli attori avanzati continueranno a sviluppare varianti per aggirare i controlli dei provider, spostando potenzialmente il fronting verso servizi cloud meno presidiati o CDN regionali con policy di sicurezza meno mature.

Per il monitoraggio proattivo, concentra le risorse di intelligence sull'identificazione dei domini CDN utilizzati come facciata: cross-referenzia i domini risolti verso range IP CDN con le connessioni anomale segnalate dal SOC. L'overlap di tool tra gruppi APT e operatori criminali è elevato in questo dominio, quindi la distinzione tra attori statali e cybercrime basata sulla sola tecnica non è affidabile — servono indicatori di contesto operativo e targeting per l'attribuzione.

Framework MITRE ATT&CK v16 — Tecnica T1090.004 (Domain Fronting), Tattica TA0011, Mitigazione M1020, Detection DET0196 (AN0564–AN0567). Gruppi: G0016. Software: S0154, S0175, S0699, S0649. Integrato con conoscenza professionale per tool e procedure operative.