Duplicazione del Traffico: Traffic Duplication (T1020.001)

Dal punto di vista offensivo, la duplicazione del traffico richiede un accesso privilegiato già acquisito: credenziali IAM con permessi sulle API di mirroring cloud oppure accesso amministrativo a un apparato di rete. L'esercizio red team si concentra quindi sull'abuso post-compromissione di funzionalità legittime, non su un exploit.

In ambiente AWS, con credenziali che dispongono dei permessi ec2:CreateTrafficMirrorSession, un operatore può costruire una sessione che duplica il traffico di un'interfaccia verso un target controllato. Il flusso operativo passa da tre chiamate encapsulate nella AWS CLI (a pagamento, tier gratuito limitato): creazione del traffic mirror target, del filter e infine della session. Concettualmente:

• aws ec2 create-traffic-mirror-target --network-interface-id
• aws ec2 create-traffic-mirror-filter
• aws ec2 create-traffic-mirror-session --network-interface-id --traffic-mirror-target-id --traffic-mirror-filter-id --session-number 1

Il traffico VXLAN incapsulato arriva così su un'istanza collettrice, dove si cattura con tcpdump -i eth0 udp port 4789 -w mirror.pcap (open source, incluso nelle distro Linux).

Su apparati di rete Cisco IOS, la configurazione SPAN si realizza in modalità config con monitor session 1 source interface GigabitEthernet0/1 e monitor session 1 destination interface GigabitEthernet0/2. Per esfiltrazione remota si usa ERSPAN, che incapsula il traffico in GRE verso un IP arbitrario, permettendo di portarlo fuori dal perimetro fisico. La modifica malevola persistente del firmware (via patch dell'immagine di sistema) consente di mantenere il mirroring anche dopo reboot.

Per la fase di laboratorio è utile ricostruire l'intera catena in un ambiente isolato:

• GNS3 o EVE-NG (open source / freemium) per emulare router e switch e testare SPAN/ERSPAN;
• Wireshark (open source) per validare il contenuto dei pacchetti duplicati e verificare la presenza di credenziali in chiaro;
• Scapy (open source) per generare traffico sintetico da mirrorare durante i test;
• Pacu (open source), framework di exploitation AWS, per enumerare permessi IAM e verificare la fattibilità della creazione di sessioni di mirroring.

La catena tipica prevede: acquisizione credenziali → enumerazione permessi mirroring → creazione sessione verso collettore controllato → cattura passiva → analisi offline. La combinazione con sniffing e AiTM amplifica il valore dei dati raccolti, poiché consente di intercettare handshake e sessioni applicative.

Il rilevamento di questa tecnica poggia su una regola d'oro: il mirroring legittimo è raro, pianificato e diretto verso destinazioni note. Qualsiasi sessione di duplicazione non autorizzata o diretta verso range esterni è per definizione sospetta. La strategia di detection DET0403 distingue due domini, IaaS e apparati di rete.

Sul fronte cloud (AN1131), la logica è correlare le chiamate del management plane con l'osservazione del traffico mirrorato. Le fonti chiave sono AWS CloudTrail e AWS VPC Flow Logs. Un alert efficace si costruisce cercando eventi CreateTrafficMirrorSession, CreateTrafficMirrorTarget e CreateTrafficMirrorFilter in CloudTrail, per poi verificare in VPC Flow Logs la comparsa di traffico incapsulato verso la destinazione appena definita.

Il tuning proposto agisce su tre dimensioni. La finestra temporale correla la creazione della sessione con l'arrivo di traffico mirrorato entro pochi secondi (es. 60s), riducendo il rumore. Il MirrorDestinationCIDR consente di marcare come sospetti i target esterni ai range aziendali. La UserIdentity segnala mirroring avviato da ruoli IAM non privilegiati o inattesi — un forte indicatore di abuso.

Sugli apparati di rete (AN1132), si monitorano le sessioni di mirroring non autorizzate create via monitor session o mirror port, unite a traffico in uscita dall'interfaccia mirrorata verso destinazioni anomale. Le fonti sono syslog dell'apparato e i flow record (NetFlow/IPFIX). Il tuning distingue i tipi di modifica di configurazione accettati (auditare solo la creazione di sessioni), definisce le porte a rischio esfiltrazione (es. 4443, 8443, 2055) e stabilisce dove il mirroring è legittimamente atteso, differenziando apparati edge, core e distribution.

Sul piano preventivo, le mitigazioni indicate agiscono in profondità. User Account Management (M1018) applica il minimo privilegio: negli ambienti cloud gli utenti non devono poter creare o modificare mirror salvo esplicita necessità, con MFA sugli account amministrativi. Encrypt Sensitive Information (M1041) riduce il valore del traffico duplicato: se le comunicazioni viaggiano cifrate con TLS e i protocolli di autenticazione come Kerberos sono protetti, il pacchetto catturato risulta inutile. Data Loss Prevention (M1057) intercetta la movimentazione anomala di dati sensibili.

Attenzione ai falsi positivi: team di rete e sicurezza usano legittimamente SPAN e Traffic Mirroring per IDS, packet broker e troubleshooting. Una baseline delle sessioni approvate, dei loro creatori e delle destinazioni attese è indispensabile per non annegare l'analista in allarmi benigni.

L'analisi forense della duplicazione del traffico si sviluppa lungo due assi paralleli: la ricostruzione delle modifiche di configurazione che hanno abilitato il mirroring e la mappatura del percorso dei dati verso la destinazione dell'attaccante.

Negli ambienti cloud AWS, il punto di partenza è CloudTrail, che conserva la traccia immutabile delle chiamate API. Ogni evento CreateTrafficMirrorSession, CreateTrafficMirrorTarget e CreateTrafficMirrorFilter registra timestamp, userIdentity, ARN del ruolo, IP sorgente e parametri della richiesta. Da qui l'analista ricostruisce chi ha creato la sessione, da dove e con quali credenziali. I VPC Flow Logs completano il quadro documentando il volume e la direzione del traffico incapsulato VXLAN verso l'interfaccia collettrice, permettendo di stimare la quantità di dati esfiltrati. La correlazione tra l'orario di creazione della sessione e il primo flusso mirrorato ancora la timeline dell'incidente.

Sugli apparati di rete, la configurazione in esecuzione (show running-config) rivela le sessioni monitor session o le istanze ERSPAN attive, mentre i syslog conservano i messaggi di modifica configurazione con relativo timestamp e utente autenticato tramite AAA/TACACS+. È fondamentale confrontare la configurazione corrente con l'ultima baseline approvata per isolare le modifiche non autorizzate. In caso di sospetto ROMMONkit o patch dell'immagine di sistema, si acquisisce l'immagine firmware e se ne verifica l'hash contro quello ufficiale del vendor: una discrepanza indica manomissione persistente che sopravvive al riavvio.

La costruzione della timeline intreccia queste fonti: creazione della sessione di mirroring (management plane) → primo flusso duplicato (data plane) → destinazione ricevente. Questo ordinamento distingue un evento benigno di troubleshooting da un'esfiltrazione deliberata, che tipicamente mostra destinazioni esterne al perimetro e ruoli non abituati a operazioni di rete.

Dal lato endpoint gli artefatti sono scarsi, poiché la tecnica opera a livello di infrastruttura e non lascia tracce sul sistema mirrorato — la vittima non "vede" di essere osservata. L'analista deve quindi privilegiare le fonti di rete e le collettrici: se l'istanza destinataria è recuperabile, i file .pcap eventualmente scritti da tcpdump o dai packet broker costituiscono la prova diretta del contenuto intercettato. MITRE non associa campagne documentate a questa sottotecnica, quindi l'attribuzione si fonda sull'analisi delle credenziali abusate e dei pattern infrastrutturali, incrociando i log di autenticazione con la geolocalizzazione degli IP sorgente delle chiamate API.

I dati MITRE ATT&CK per questa sottotecnica non riportano gruppi APT, software o campagne associati: zero attribuzioni formali. Questo dettaglio è esso stesso un elemento di intelligence e va interpretato con attenzione piuttosto che liquidato come assenza di rischio.

La mancanza di attribuzione pubblica riflette la natura della tecnica più che la sua rarità. La duplicazione del traffico opera a livello di infrastruttura di rete e cloud, sfruttando funzionalità native e legittime. Non introduce malware sull'endpoint, non genera artefatti evidenti sul sistema osservato e si mimetizza in operazioni di monitoraggio ordinarie. Questa "invisibilità" rende difficile per i team di incident response attribuire con certezza un abuso di mirroring a un attore specifico, e di conseguenza il corpus di reporting pubblico resta sottile.

Sul piano del profiling degli avversari plausibili, la tecnica richiede prerequisiti che ne restringono l'adozione. Serve un accesso già privilegiato — credenziali IAM potenti o controllo amministrativo di apparati di rete — e una conoscenza approfondita dell'ambiente bersaglio. Questo profilo è coerente con attori sofisticati orientati allo spionaggio a lungo termine, per i quali la persistenza silenziosa e la raccolta continua di dati contano più della velocità. La combinazione documentata da MITRE con Network Sniffing, Input Capture e Adversary-in-the-Middle conferma un orientamento verso la sottrazione di credenziali e la sorveglianza delle comunicazioni interne.

Il pattern infrastrutturale più rilevante è l'abuso degli apparati di rete perimetrali (router e switch edge) e delle piattaforme cloud multi-vendor. La citazione esplicita di AWS Traffic Mirroring, GCP Packet Mirroring e Azure vTap segnala che la superficie d'attacco è trasversale ai principali provider e cresce con l'adozione di architetture ibride. Le modifiche persistenti tramite ROMMONkit e patch dell'immagine di sistema indicano inoltre un interesse per la persistenza a livello firmware, tratto tipico di operazioni state-sponsored contro obiettivi ad alto valore.

Il trend da monitorare è duplice. Da un lato, la progressiva "cloudificazione" del mirroring abbassa la barriera tecnica: ciò che un tempo richiedeva accesso fisico a un apparato ora si ottiene con una chiamata API. Dall'altro, la maturazione delle strategie di detection come DET0403 — che correlano management plane e data plane — sposta il vantaggio verso i difensori capaci di monitorare entrambi i livelli. Per un Threat Intelligence Officer, la raccomandazione operativa è trattare i permessi di mirroring come credenziali critiche e vigilare su ogni sessione che punti fuori dal perimetro fidato, indipendentemente dall'assenza di attribuzioni note.

MITRE ATT&CK: tecnica T1020.001 (Traffic Duplication), tattica TA0010. Mitigazioni M1018, M1041, M1057. Strategia di detection DET0403 con analytic AN1131 (IaaS) e AN1132 (Network Devices). Log source citati: AWS CloudTrail, AWS VPC Flow Logs, syslog e flow degli apparati di rete. Per comandi, tool operativi e procedure di laboratorio (AWS CLI, tcpdump, Wireshark, Scapy, Pacu, GNS3, EVE-NG) è stata utilizzata conoscenza professionale di cybersecurity, basata su documentazione ufficiale e repository pubblici verificabili.