Occultamento Infrastruttura: Hide Infrastructure (T1665)
Hide Infrastructure raccoglie l'insieme di tecniche con cui gli avversari mascherano la propria infrastruttura di comando e controllo per ritardarne la scoperta, il blocco o il takedown. La tecnica è mappata sulla tattica TA0011 (Command and Control) e si colloca nella fase post-exploitation della kill chain, quando l'attaccante deve mantenere un canale stabile con i sistemi compromessi senza attirare l'attenzione di SOC, threat hunter o vendor di sicurezza.
Le modalità operative sono eterogenee: uso di proxy residenziali o VPN cloud per far coincidere l'origine geografica del traffico con quella della vittima, filtraggio selettivo delle richieste provenienti da user-agent noti di scanner e ricercatori, hosting di payload su CDN legittime come Akamai o AWS per beneficiare della reputazione del provider, e catene di jump host che spezzano la tracciabilità end-to-end. Alcuni attori spingono oltre, costruendo intere ORB network (Operational Relay Box) composte da router SOHO, dispositivi IoT e VPS compromessi.
L'impatto operativo è significativo: la campagna SolarWinds Compromise (2019-2021) e il botnet Quad7 (2023-2025, migliaia di router TP-Link e Asus compromessi) dimostrano come l'occultamento infrastrutturale possa prolungare la vita di un'operazione di mesi o anni, erodendo l'efficacia dei controlli basati su blocklist statiche e geolocalizzazione.
Simulare Hide Infrastructure in un red team engagement richiede un'infrastruttura C2 realistica e la capacità di replicare le tecniche di offuscamento osservate in campo. Il primo pilastro è la redirector chain: si posiziona un frontend su un provider trusted (CDN, servizio cloud) che inoltra il traffico verso un teamserver isolato, filtrando le richieste indesiderate prima che raggiungano il backend.
Per costruire redirector HTTP/S il tool di riferimento è Cobalt Strike Malleable C2 (a pagamento) con profili che imitano traffico legittimo, oppure alternative open source come Mythic (open source) e Sliver (open source) di BishopFox. Il redirector viene tipicamente implementato con Apache mod_rewrite (open source) o Nginx (open source), configurando regole che ispezionano header, user-agent e path per decidere se inoltrare al C2 o restituire una pagina benigna.
Un pattern comune è il filtraggio per user-agent: nella configurazione Apache si definiscono RewriteCond che confrontano %{HTTP_USER_AGENT} con espressioni regolari che intercettano client di scansione come curl, wget, python-requests, Nessus, Nuclei. Le richieste sospette vengono rediretta verso il sito legittimo che si sta impersonando. Lo stesso approccio funziona su Nginx con direttive if ($http_user_agent ~)* nel blocco server.
Per l'offuscamento a livello di dominio si utilizza il domain fronting dove ancora tecnicamente possibile, oppure ci si appoggia a URL shortener e servizi di marketing per la fase di initial redirect. Il tool CDN-Proxy (open source) automatizza il deployment su CloudFront e simili. Per la registrazione di domini con reputazione, la ricognizione parte da expireddomains.net (freemium) per identificare domini scaduti con categorizzazione pulita.
La componente ORB simulation in laboratorio si costruisce con VPS a basso costo distribuiti su più provider e regioni geografiche, collegati via WireGuard (open source) o OpenVPN (open source) in configurazione multi-hop. Per il chaining di jump host tipo JumbledPath, uno script SSH con ProxyJump o ProxyCommand nel ~/.ssh/config replica il pattern:
ssh -J user1@hop1,user2@hop2 target
La validazione della postura difensiva del cliente prevede test di detection con CanaryTokens (gratuito) piazzati su domini di categoria simile, e verifica che i SIEM correlino il traffico verso CDN con destinazioni interne anomale. Documentare ogni redirector con IP, dominio, TLS fingerprint e finestra temporale è essenziale per il purple team debrief.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo