Codifica Dati: Data Encoding (T1132)
La tecnica T1132 - Data Encoding rientra nella tattica TA0011 (Command and Control) e descrive l'uso di schemi di codifica standard per offuscare il traffico C2, rendendone più difficile l'ispezione automatica da parte di IDS, proxy e sistemi di DLP. Gli avversari ricorrono a rappresentazioni come Base64, esadecimale, ASCII, Unicode, MIME o algoritmi di compressione come gzip per trasformare comandi e risposte in stringhe che rispettano le specifiche di protocolli legittimi (tipicamente HTTP/HTTPS) e passano inosservate tra il traffico web ordinario.
A differenza della cifratura, la codifica non richiede una chiave: chiunque intercetti il traffico può decodificarlo, ma il costo computazionale per ispezionare ogni sessione HTTP alla ricerca di stringhe Base64 sospette è elevato, e i falsi positivi abbondano (cookie, JWT, immagini inline). Questo rende la codifica una scelta di evasione low-cost ma efficace, spesso combinata con cifratura (doppio strato) o con varianti custom degli alfabeti di codifica.
Sul piano della kill chain, T1132 si colloca dopo la fase di Initial Access e Execution, quando l'impianto ha bisogno di un canale bidirezionale con il proprio operatore. I dati MITRE registrano 5 famiglie di malware che implementano data encoding (BADNEWS, H1N1, Linux Rabbit, Ursnif, Mythic) e il gruppo Velvet Ant, che ha inviato comandi codificati con passkey a dispositivi F5 BIG-IP compromessi. La mitigazione ufficiale si concentra su M1031 (Network Intrusion Prevention) tramite firme di rete specifiche per famiglie di malware note.
Per simulare T1132 in un red team engagement, il framework di riferimento è Mythic (open source), che fornisce transform functions componibili per codificare e randomizzare il traffico C2 a livello di profilo di comunicazione. Un operatore può concatenare trasformazioni come Base64, XOR con chiave dinamica e padding casuale direttamente nel file di configurazione del C2 profile (es. http profile in Mythic), ottenendo payload che non corrispondono ad alcuna firma statica.
Sul lato Windows, un impianto minimalista può codificare il beacon in PowerShell con una singola riga. Il pattern osservato in campagne reali come quelle di Ursnif prevede l'inserimento del payload codificato direttamente nel path o nella query string di richieste HTTP GET verso domini apparentemente benigni. Per riprodurre l'effetto in laboratorio:
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($data))
seguito da un Invoke-WebRequest con la stringa risultante come parametro URL. La stessa logica è replicabile in Linux tramite base64 -w0 e curl, oppure con xxd -p per output esadecimale che simula il comportamento di BADNEWS, il quale cifra i dati C2 e li converte in esadecimale prima del wrapping Base64.
Su macOS, gli utility integrate base64, xxd e plutil consentono di produrre codifiche direttamente da script bash o zsh senza dipendenze esterne, riducendo l'impronta forense. In ambienti ESXi, l'esercizio red team più realistico prevede l'abuso di esxcli e shell interattive raggiunte via SSH, dove gzip e Base64 possono essere concatenati in pipeline per esfiltrare configurazioni prima di un movimento laterale.
Per test più sofisticati, Sliver (open source) e Havoc (open source) offrono profili di comunicazione personalizzabili paragonabili a Mythic. Il red teamer deve prestare attenzione a due dettagli: la lunghezza delle stringhe codificate (payload troppo lunghi in header HTTP sono anomali) e la frequenza delle richieste, che va modulata per emulare traffico utente reale. Combinare T1132 con T1071.001 (Web Protocols) e domain fronting completa la catena di evasione. Ogni test deve essere confinato a una lab network isolata con cattura pcap per verificare a posteriori quanto del traffico prodotto sarebbe stato intercettabile dai controlli difensivi.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo