Codifica Non-Standard: Non-Standard Encoding (T1132.002)
La tecnica T1132.002 - Non-Standard Encoding descrive l'uso di schemi di codifica dati non conformi agli standard pubblici per offuscare il traffico di comando e controllo. Gli avversari partono spesso da schemi noti come Base64, Base32 o esadecimale, e li modificano introducendo alfabeti custom, sostituzioni di caratteri, byte swap o operazioni bitwise, così da rendere il contenuto illeggibile ai parser standard e alle firme di rete tradizionali.
L'obiettivo tattico si colloca nella fase TA0011 (Command and Control) della kill chain, dove la comunicazione tra host compromesso e infrastruttura avversaria deve mimetizzarsi nel traffico legittimo per garantire persistenza operativa. La codifica non-standard non fornisce riservatezza crittografica robusta, ma alza significativamente il costo dell'analisi difensiva: un IDS che cerca pattern Base64 su URI o body HTTP fallisce, e anche l'analista che intercetta il payload deve prima ricostruire l'alfabeto o l'algoritmo per decodificarlo.
I dati MITRE ATT&CK associano questa tecnica a 16 famiglie malware documentate, con una sola mitigazione formale (M1031 - Network Intrusion Prevention) e quattro analitiche comportamentali che coprono Windows, Linux, macOS ed ESXi. La varietà di implementazioni — da Base62 custom in Uroburos, allo XOR complesso di Lizar, al byte swap esadecimale di Small Sieve — evidenzia come si tratti di un pattern trasversale a APT statuali, gruppi finanziari e operatori ransomware.
Per simulare T1132.002 in un esercizio red team autorizzato, l'obiettivo è costruire un canale C2 il cui payload non venga riconosciuto da regole Suricata/Snort basate su alfabeti Base64/Hex standard. Il primo passo è definire un alfabeto custom: una permutazione dei 64 caratteri di Base64, oppure una tabella Base62 (0-9, a-z, A-Z) come quella osservata in Uroburos. In Python bastano poche righe usando str.maketrans() per mappare l'output di base64.b64encode() su un alfabeto riordinato; lo stesso pattern è riproducibile in Go o Rust per payload compilati.
Un secondo approccio, ispirato a NightClub, consiste nel post-processing di un Base64 standard: rimozione del padding =, sostituzione di / con -s e + con -p. Utile per DNS tunneling, dove i caratteri riservati non sono ammessi nei label. Uno script in Bash può gestire la trasformazione con tr e sed prima di iniettare i dati nei sottodomini di query TXT.
Per chi vuole replicare pattern più aggressivi come Lizar o TONESHELL, lo XOR multi-byte con chiave rotante (32 o 256 byte) offre entropia elevata mantenendo reversibilità. In lab si può usare CyberChef (open source) per prototipare la catena encode/decode e validare i round-trip prima di implementarla nell'agent.
Sul lato infrastruttura, consiglio di appoggiarsi a framework C2 open source come Sliver (open source) o Mythic (open source), che permettono di scrivere transport module custom in Go o Python. Un transport personalizzato può wrappare il traffico HTTP del beacon con l'encoder non-standard, lasciando invariato il resto del protocollo. Per test cross-platform, Covenant (open source) su Windows e Merlin (open source) per beacon Go coprono scenari misti.
Durante l'engagement, verificare l'efficacia con Zeek (open source) e Suricata (open source) in ambiente controllato: catturare il traffico con tcpdump -i eth0 -w capture.pcap e riprocessarlo con zeek -r capture.pcap per osservare quali log (http.log, dns.log, conn.log) mostrano anomalie. Un indicatore utile è calcolare l'entropia di Shannon dei body HTTP con script Python (libreria scipy.stats): payload con entropia >4.8 su token lunghi >120 caratteri sono candidati sospetti anche senza firma. Documentare sempre l'alfabeto e la chiave usati per consentire al blue team la successiva reverse.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo