Mascheramento del Traffico C2: Domain Fronting (T1090.004)

Per testare la resilienza della tua infrastruttura contro il domain fronting, inizia configurando Cobalt Strike con header HTTP personalizzati. Il framework supporta nativamente questa tecnica attraverso il parametro Host Header nelle impostazioni del profilo di comunicazione.

Implementa un test base utilizzando curl per verificare la fattibilità: curl -H "Host: dominio-target.com" https://dominio-frontale.cdn.com/path

Il traffico apparirà diretto verso il dominio frontale, ma il CDN lo instraderà al target reale specificato nell'header Host. Per simulazioni avanzate, Mythic offre capacità di domain fronting attraverso header personalizzabili nei suoi agenti.

La variante domainless richiede modifiche più profonde al client TLS. Puoi utilizzare meek come transport plugin: meek-client --url=https://cdn-provider.com --front=

Questa configurazione lascia intenzionalmente vuoto il campo SNI, permettendo il bypass di controlli che verificano la corrispondenza tra SNI e Host header. SMOKEDHAM implementa questa tecnica hardcodando domini frontali per offuscare i server C2 reali.

Per validare l'efficacia in laboratorio, cattura il traffico con tcpdump e analizza la discrepanza tra i campi: tcpdump -i eth0 -w fronting.pcap 'port 443'

Esamina poi con Wireshark filtrando per handshake TLS e verificando che il campo SNI differisca dall'Host header HTTP successivo.

La detection del domain fronting richiede visibilità sia sul layer TLS che HTTP. Implementa analisi comportamentale che correli il campo SNI del ClientHello TLS con l'Host header della richiesta HTTP successiva.

Per Windows, configura Sysmon per catturare eventi di connessione di rete e correla con i log del proxy: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=3}

Crea una detection rule che identifichi discrepanze tra SNI e Host header. I falsi positivi comuni includono servizi legittimi che usano CDN, quindi costruisci una allowlist dei domini CDN autorizzati nella tua organizzazione.

Su sistemi Linux, monitora le syscall di connessione attraverso auditd focalizzandoti su processi che iniziano connessioni HTTPS anomale. La regola dovrebbe catturare: -a always,exit -F arch=b64 -S socket,connect -F a0=2 -F a1=1 -k domain_fronting

Per la variante domainless, cerca sessioni TLS dove il campo SNI risulta vuoto. Questo pattern è estremamente raro nel traffico legittimo e costituisce un indicatore ad alta confidenza. Implementa threshold dinamici basati sul volume di traffico per ridurre il rumore.

Gli strumenti di Network Security Monitoring devono essere configurati per estrarre e confrontare i metadati TLS/HTTP in tempo reale. Zeek offre script personalizzabili per questa correlazione specifica.

Durante l'analisi post-compromissione, il domain fronting lascia tracce distintive nei log di rete e negli artefatti del sistema. Su Windows, esamina i log di Sysmon EventCode 3 per identificare connessioni HTTPS verso CDN noti.

La timeline reconstruction inizia correlando:

• Timestamp delle connessioni di rete anomale
• Processi che hanno iniziato le connessioni (parent process analysis)
• Persistenza mechanisms associati temporalmente

APT29 nelle sue campagne ha mostrato pattern ricorrenti: installazione di meek come servizio, seguito da connessioni periodiche verso domini CDN legittimi. Cerca binari non firmati o processi con nomi generici che stabiliscono connessioni HTTPS frequenti.

Su sistemi Linux, analizza i log di auditd per syscall di socket e connect. La sequenza tipica mostra: execve() → socket() → connect() → write() con payload TLS anomalo

Per ESXi, eventi di connessione outbound da host di virtualizzazione sono altamente sospetti. Questi sistemi raramente iniziano traffico HTTPS esterno, rendendo qualsiasi domain fronting facilmente identificabile nella timeline.

Documenta meticolosamente le coppie dominio-frontale/dominio-reale identificate. Questa mappatura rivela l'infrastruttura C2 reale dell'attaccante e può essere correlata con threat intelligence per attribution.

APT29 rimane l'utilizzatore più sofisticato di domain fronting, integrando meek nei propri toolkit operativi. Il gruppo mostra preferenza per CDN globali che offrono copertura geografica ampia e latenza ridotta.

L'analisi delle campagne documentate rivela pattern operativi consistenti. Gli attaccanti selezionano domini frontali che:

• Appartengono a servizi cloud mainstream (riduce sospetti)
• Hanno volume di traffico elevato (nasconde comunicazioni C2)
• Supportano websocket per comunicazioni bidirezionali persistenti

Il tooling evolve rapidamente. Cobalt Strike e Mythic rappresentano le piattaforme commerciali/open source più adoperate, mentre malware custom come SMOKEDHAM indica capacità di sviluppo proprietario per operazioni mirate.

Geograficamente, l'uso di domain fronting correla con paesi che implementano censura internet aggressiva. Questo suggerisce doppio uso: evasione di controlli aziendali e bypass di restrizioni nazionali. Monitor attentamente CDN provider che annunciano modifiche alle policy di domain fronting.

L'overlap negli strumenti utilizzati suggerisce condivisione di TTP tra gruppi o utilizzo di contractor comuni. La presenza di meek in toolkit diversi indica standardizzazione su soluzioni testate sul campo.

Framework MITRE ATT&CK T1090.004. Campagne APT29 documentate con utilizzo operativo di meek plugin. Analisi comparative di Cobalt Strike, Mythic, SMOKEDHAM per capacità di domain fronting. Best practices per SSL/TLS inspection in ambienti enterprise.