Domain Fronting: Occultamento del C2 tramite CDN (T1090.004)

Simulare Domain Fronting in laboratorio richiede la disponibilità di un CDN che consenta ancora il routing tra domini co-ospitati. Molti provider (Google, AWS CloudFront, Azure Front Door, Fastly) hanno introdotto restrizioni progressive, quindi la scelta del provider di test è parte integrante dello scenario.

Il framework di riferimento per red team è Cobalt Strike (a pagamento), che supporta il fronting tramite la direttiva header "Host" all'interno del Malleable C2 Profile. Un profilo minimale dichiara nel blocco http-get l'header Host puntante al dominio C2 reale, mentre il beacon si collega al front domain configurato nel listener HTTPS. In alternativa, Mythic (open source) offre supporto nativo al fronting tramite header personalizzati configurabili nei profili C2 come http e websocket.

Per scenari più stealth su infrastruttura Tor, meek (open source) è il pluggable transport storicamente usato da APT29: si integra con il Tor Browser Bundle o con obfs4proxy e utilizza CDN come front per nascondere la connessione al bridge Tor.

Una catena d'attacco tipica in ambiente controllato prevede: registrazione di un dominio C2 e configurazione dietro un CDN che accetti origini custom; identificazione di un front domain legittimo servito dallo stesso CDN; generazione di payload (beacon Cobalt Strike, agent Mythic, o loader custom come SMOKEDHAM) configurato con il front domain nell'SNI e il C2 reale nell'Host header; esecuzione del payload sull'endpoint di test e verifica del round-trip.

Per validare manualmente la configurazione, uno strumento utile è curl (open source) con il flag --resolve, che consente di forzare la risoluzione di un dominio verso l'IP del CDN:

curl -H "Host: c2-reale.example" --resolve front-domain.example:443:CDN_IP https://front-domain.example/

Questo invia la richiesta all'IP del front domain, con SNI corrispondente al front ma Host header puntante al C2 reale. Se il CDN accetta il routing, la risposta arriverà dal server C2.

Per il domainless fronting è possibile usare openssl s_client (open source) con SNI vuoto tramite -servername "", seguito dall'invio manuale della richiesta HTTP. Strumenti di analisi come Wireshark (open source) e mitmproxy (open source) permettono di verificare la separazione tra i due campi nell'handshake e nella richiesta applicativa. In laboratorio è essenziale operare su infrastruttura di proprietà o esplicitamente autorizzata: il fronting su CDN di terzi senza consenso viola i loro termini di servizio.

La detection del Domain Fronting si basa principalmente sull'individuazione della discrepanza tra il campo SNI dell'handshake TLS e il campo Host dell'header HTTP interno. Poiché il payload HTTP è cifrato, questa correlazione è possibile solo dopo terminazione TLS: serve quindi un'infrastruttura di ispezione SSL/TLS in linea, come previsto dalla mitigazione M1020.

Su piattaforme Windows monitorate con Sysmon (open source) e sensori NSM come Zeek (open source) o Suricata (open source), la regola di detection cardine (AN0564) confronta i log ssl.log (che riportano il campo SNI) con http.log (che riporta l'Host). Un mismatch persistente verso lo stesso IP CDN è un indicatore ad alta confidenza. Il tuning richiede una allowlist di CDN front-end legittimi (es. domini interni aziendali serviti da CloudFront o Akamai) e una soglia sul rapporto di mismatch accettabile, poiché alcuni servizi cloud usano legittimamente Host header differenti per il routing multi-tenant.

È importante correlare il traffico con il processo iniziatore: scripting engine (powershell.exe, wscript.exe), LOLBin (certutil, bitsadmin) o binari non firmati che generano connessioni HTTPS verso CDN devono essere prioritizzati. Su Windows, Sysmon EventID 3 (Network Connection) arricchito con EventID 1 (Process Create) fornisce la lineage necessaria.

Su Linux (AN0565), il monitoraggio combina flow NSM con auditd configurato per tracciare le syscall connect e execve. Client come curl o wget che generano handshake TLS con SNI assente (SNIFieldAbsent) verso CDN sono anomalie forti, soprattutto se lanciati da utenti di servizio o da processi non attesi. Il domainless fronting è particolarmente sospetto perché nessun browser moderno omette l'SNI.

Su macOS (AN0566), l'Unified Log combinato con osquery (open source) permette di correlare le connessioni TLS con binari non firmati o applicazioni user-space. La firma del binario e la reputazione dello sviluppatore sono discriminanti chiave.

In ambiente ESXi (AN0567), gli host di virtualizzazione dovrebbero raramente iniziare connessioni HTTPS verso Internet: qualsiasi traffico verso CDN da interfacce di management è sospetto e merita alerting immediato tramite log firewall e shell ESXi.

I falsi positivi principali derivano da: applicazioni mobile che usano Host header per API gateway multi-tenant, servizi legacy che configurano male l'SNI, telemetria di prodotti di sicurezza che usano CDN come front. Una baseline di 30-60 giorni sui pattern SNI/Host per subnet è essenziale prima di attivare alert in produzione. L'integrazione con feed di threat intelligence su domini front noti (es. quelli storicamente usati da APT29 o da campagne Cobalt Strike) aumenta la precisione.

L'analisi forense del Domain Fronting è complessa perché il canale è cifrato e il traffico appare legittimo. Le fonti primarie sono i log di rete, gli artefatti endpoint del processo C2 e le eventuali catture PCAP disponibili.

Su endpoint Windows, la timeline parte dall'identificazione del processo che ha instaurato la connessione. Sysmon EventID 3 con IP di destinazione appartenente a range CDN noti (CloudFront, Fastly, Azure Front Door) è il punto di partenza. Correlando con EventID 1 si risale al binario e alla command line; EventID 7 (Image Loaded) può rivelare DLL sospette caricate, come nel caso di beacon Cobalt Strike iniettati in processi legittimi (svchost.exe, rundll32.exe). L'analisi della memoria con Volatility 3 (open source) tramite plugin come windows.malfind e windows.netscan permette di individuare regioni RX iniettate e connessioni attive non associate a processi legittimi.

La presenza di Malleable C2 Profile custom di Cobalt Strike lascia tracce nella configurazione del beacon estraibile dalla memoria con CobaltStrikeScan (open source) o 1768.py di Didier Stevens (open source), che decodifica la configurazione includendo il front domain e l'Host header configurato.

Su Linux, gli artefatti chiave sono: log auditd delle syscall connect, file di configurazione di eventuali proxy locali (meek-client, obfs4proxy), history della shell dell'utente compromesso, e file temporanei in /tmp o /var/tmp contenenti binari di stage. Il file /proc/<pid>/net/tcp e l'output di ss -tanp al momento dell'incident response documentano le connessioni attive.

Su macOS, l'Unified Log (log show --predicate 'subsystem == "com.apple.network"') fornisce visibilità sulle connessioni; osquery con la tabella process_open_sockets correlata a processes ricostruisce il contesto.

Per le fonti esterne, il Certificate Transparency log consultabile tramite crt.sh consente di identificare certificati emessi per domini C2 dietro CDN, mentre servizi di passive DNS come quelli offerti da SecurityTrails (freemium) o Farsight DNSDB (a pagamento) documentano storicamente le risoluzioni. VirusTotal (freemium) permette di verificare la reputazione di domini e IP e di correlare con sample noti.

APT29 ha storicamente usato meek per instradare C2 attraverso Tor via CDN: la presenza di binari meek-client o di configurazioni Tor Browser modificate su endpoint compromessi è un indicatore forte di attribuzione. Per SMOKEDHAM, il dominio front è hardcoded nel binario: l'estrazione di stringhe con strings o l'analisi statica con Ghidra (open source) o IDA (freemium) rivela sia il front che il C2 reale.

La timeline forense deve correlare: primo contatto con il CDN, processo iniziatore, artefatti di persistenza creati contestualmente, e movimento laterale successivo.

Il panorama degli attori che utilizzano Domain Fronting è dominato da gruppi statuali sofisticati e da operatori con accesso a framework C2 commerciali o open source di alto livello.

APT29 (noto anche come Cozy Bear, The Dukes) è l'unico gruppo formalmente attribuito a questa tecnica nei dati MITRE. Riconducibile all'intelligence russa (SVR), APT29 ha impiegato il plugin meek per Tor per nascondere la destinazione del traffico C2 all'interno di CDN legittimi. Questa scelta è coerente con la dottrina operativa del gruppo, caratterizzata da lunga persistenza, bassa rumorosità e forte investimento in evasione. Le operazioni di APT29 hanno storicamente colpito enti governativi, think tank, entità diplomatiche e, in modo notorio, la supply chain software (caso SolarWinds), con targeting geografico prevalente su Nord America ed Europa occidentale.

Sul fronte del tooling, Cobalt Strike rimane il framework C2 più diffuso in operazioni offensive, sia legittime sia criminali. La sua capacità di configurare l'Host header tramite Malleable C2 Profile lo rende naturalmente adatto al fronting. Cracked version di Cobalt Strike circolano ampiamente e sono utilizzate da gruppi ransomware (Conti, LockBit, Black Basta storicamente), operatori di initial access broker e APT statuali che ne apprezzano la deniability.

Mythic è un framework C2 open source modulare emergente, adottato sempre più frequentemente da red team professionali e, in modo crescente, da threat actor che cercano alternative meno signaturate rispetto a Cobalt Strike. Il supporto nativo al fronting tramite header personalizzati lo rende una scelta operativa in scenari dove la detection di Cobalt Strike è ormai matura.

SMOKEDHAM è un backdoor .NET associato a operazioni di intrusione con motivazione mista (spionaggio e monetizzazione), documentato in campagne contro settori tecnologici e servizi professionali. L'uso di front domain hardcoded semplifica il deployment ma facilita anche l'attribuzione tramite analisi statica.

meek merita una menzione a parte: nato come pluggable transport del Tor Project per aggirare la censura in stati autoritari (Iran, Cina, Russia), è stato weaponizzato da attori offensivi che ne hanno riconosciuto il valore per l'evasione C2.

Il trend osservabile è una progressiva restrizione del fronting da parte dei grandi CDN: Google, AWS e Azure hanno implementato controlli di coerenza SNI/Host già dal 2018-2020, spingendo gli attori verso CDN minori, verso il domainless fronting e verso tecniche alternative come domain hiding basato su ESNI/ECH. L'adozione crescente di Encrypted Client Hello rappresenta la prossima frontiera di questa competizione tra evasione e detection, con implicazioni significative per la visibilità di rete.

MITRE ATT&CK T1090.004 (Domain Fronting), tattica TA0011. Gruppo G0016 (APT29). Software S0154 (Cobalt Strike), S0175 (meek), S0649 (SMOKEDHAM), S0699 (Mythic). Mitigazione M1020 (SSL/TLS Inspection). Detection DET0196 con analytics AN0564-AN0567. MITRE D3FEND per artefatti Network Traffic e Certificate. Integrazione con conoscenza professionale per sintassi di tool operativi (curl, openssl, Volatility, CobaltStrikeScan, Zeek, Suricata, Sysmon, osquery) e per il contesto di threat intelligence su framework C2 e trend ECH.