Network Forensics con Wireshark — Analizzare il Traffico Malevolo e Trovare le Prove

Il server ha smesso di rispondere alle 3:47. Il log di accesso mostra un POST verso una pagina che non esiste. Il firewall ha registrato una connessione in uscita verso un IP in un paese dove non hai clienti. Il tuo primo pensiero è "formattiamo e via". Sbagliato. Prima di cancellare tutto devi rispondere a una domanda: cosa è successo esattamente? È qui che entra in gioco la network forensics, e Wireshark è lo strumento che usiamo ogni giorno per trovare le risposte.

Noi, di Meteora Web, lavoriamo su incidenti reali da anni. Quando un cliente ci chiama dopo un attacco, la prima cosa che chiediamo non è "che antivirus hai?" ma "che traffico hai catturato?". Il traffico di rete non mente. I log possono essere alterati, i file cancellati, ma il pacchetto che è passato dal firewall in quel preciso momento è una prova tecnica.

Questa guida è una sessione operativa di network forensics con Wireshark: come catturare il traffico nel momento giusto, come isolare i flussi malevoli, come estrarre le prove che reggono in una relazione tecnica. Niente teoria da manuale. Solo procedure che funzionano.

Perché la Network Forensics è Diversa dalla Sicurezza Tradizionale

La sicurezza tradizionale cerca di impedire l'accesso. La network forensics assume che l'accesso sia già avvenuto e lavora per ricostruire cosa è successo dopo. È una differenza di mentalità fondamentale.

Quando analizziamo un traffico malevolo, non stiamo cercando vulnerabilità. Stiamo cercando evidenze di movimento laterale: chi ha parlato con chi, quando, su quale porta, con quale payload. Un singolo pacchetto DNS può rivelare il comando di un C2. Una sessione TLS ben formata può nascondere esfiltrazione di dati. Un handshake TCP anomalo può indicare una scansione di rete.

L'errore comune è aprire Wireshark e guardare la lista dei pacchetti senza un metodo. Vediamo tutto, non capiamo niente. La network forensics seria parte da una domanda operativa: quale domanda voglio rispondere? Solo dopo si sceglie il filtro.

La differenza tra packet capture e flow data

Prima di scavare nei pacchetti, capiamo la materia prima. I flow data (es. NetFlow, IPFIX) sono riassunti statistici: IP sorgente, IP destinazione, porte, protocollo, numero di pacchetti. Sono utili per capire "chi ha parlato con chi" ma non dicono nulla sul contenuto. Le full packet capture (PCAP) contengono i byte originali. Sono pesanti, ma permettono di ricostruire una sessione, estrarre un file, rileggere un comando.

Nel nostro lavoro usiamo entrambi. I flow data per l'analisi iniziale, le PCAP per la prova definitiva. Se hai solo i log del firewall, puoi fare un'analisi preliminare. Se hai una PCAP, puoi chiudere il caso.

Checklist immediata:

• Verifica se il tuo firewall o router supporta NetFlow/IPFIX e abilitalo, anche se non pensi di averne bisogno oggi.
• Configura un mirroring della porta SPAN sul tuo switch principale per catturare il traffico di un segmento critico.
• Stabilisci una rotazione dei file PCAP: conservane almeno 7 giorni, per gli incidenti servono i dati del passato.

Come Catturare il Traffico nel Modo Giusto

Catturare male è il primo passo verso un'analisi fallita. Se la tua interfaccia è in modalità promiscua sul posto sbagliato, registri rumore. Se il buffer è troppo piccolo, perdi pacchetti nel momento peggiore. Se catturi su un server di produzione con dischi lenti, il sistema collassa sotto il carico delle scritture.

Noi usiamo una regola semplice: cattura il meno possibile ma nel punto giusto. Per un sospetto C2, il punto giusto è l'interfaccia di Default Gateway del segmento compromesso. Per una esfiltrazione, il punto giusto è l'interfaccia del server dati. Non serve catturare tutto il backbone.

Filtri di cattura BPF da usare subito

I filtri di cattura in Wireshark (BPF, Berkeley Packet Filter) sono diversi dai filtri di visualizzazione. Si applicano alla sorgente e ti permettono di scartare pacchetti inutili già in fase di acquisizione. Ecco i comandi che usiamo ogni giorno:

# Cattura tutto il traffico verso un IP sospetto e da quell'IP
tcpdump -i eth0 -w incidente.pcap host 185.220.101.34

# Cattura traffico HTTP/HTTPS verso una rete specifica
tcpdump -i eth0 -w webserver.pcap net 10.0.0.0/24 and port 80 or port 443

# Cattura traffico DNS (fondamentale per individuare C2)
tcpdump -i eth0 -w dns.pcap port 53

# Cattura con rotazione file, per non bloccare il disco
tcpdump -i eth0 -w capture.pcap -C 100 -W 10 port 80 or port 53

Il comando -C limita ogni file a 100 MB e -W mantiene al massimo 10 file. Sembra ovvio, ma lo vediamo spesso: analisti che catturano senza limiti e riempiono il disco, perdendo le prove. Una cattura ben configurata è una cattura che non si ferma prima dell'incidente.

Azione da fare adesso: apri una shell sul tuo server di test e lancia una cattura con tcpdump su porta 53 per 30 secondi. Poi apri il file con Wireshark e osserva quante query DNS passano in un minuto. Questo è il tuo rumore di base.

Wireshark per l'Analisi del Traffico Malevolo — I Filtri che Contano

Wireshark è lo strumento standard per l'analisi dei pacchetti. Ma usarlo bene significa conoscere i filtri di visualizzazione che separano il segnale dal rumore. Non esiste un pulsante magico "trova attacco". Esiste una sequenza logica di filtri che porta alla prova.

Quando apriamo una PCAP sospetta, la nostra sequenza è sempre la stessa: prima guardiamo i protocolli anomali, poi le connessioni anomale, poi il contenuto dei pacchetti.

Filtri di visualizzazione essenziali

// Mostra solo il traffico tra due host specifici
ip.addr == 10.0.0.10 && ip.addr == 185.220.101.34

// Esclude il traffico broadcast e multicast (rumore)
!(ip.broadcast) && !(ip.multicast)

// Trova richieste DNS verso domandi sospette (C2)
dns.qry.name contains "\.xyz" || dns.qry.name contains "\.top"

// Identifica sessioni TCP con pochi pacchetti ma payload grandi
tcp.len > 1000

// Cerca payload HTTP con pattern tipici di exploit (eval, base64, cmd)
http.request.uri contains "eval" || http.request.uri contains "base64"

// Visualizza solo il traffico verso porte non standard
!tcp.port in {80,443,22,53} && tcp.flags.syn == 1

Il filtro tcp.flags.syn == 1 mostra solo l'inizio delle connessioni TCP. È perfetto per individuare scansioni di rete verticali (tante porte verso un singolo IP) o orizzontali (stessa porta verso tanti IP). In pochi secondi capisci se il tuo server sta facendo da bersaglio o se è stato trasformato in scanner.

Errore comune: analizzare senza contesto. Un singolo pacchetto con payload strano non è una prova. Devi ricostruire il flusso: right-click su un pacchetto, poi Follow, poi TCP Stream. Lì vedi la conversazione completa, e spesso la cattiveria diventa evidente.

Statistiche che non usi mai ma dovresti

Il menu Statistics di Wireshark è sottovalutato. Tre voci in particolare ci salvano nei casi reali:

Endpoints ti mostra gli indirizzi IP con più traffico. Se un IP di cui non conosci l'esistenza ha trasferito 500 MB, è un sospetto naturale. Conversations ti mostra le sessioni tra coppie di host. Ordina per byte e guarda chi sta parlando con chi in modo anomalo. Protocol Hierarchy ti mostra la distribuzione dei protocolli. Se vedi ICMP a raffica, qualcuno sta facendo ping sweep o tunneling.

Queste statistiche non richiedono un PC potente. Richiedono disciplina nell'osservare prima di filtrare. Noi apriamo sempre queste tre viste prima di qualsiasi filtro manuale. È il nostro modo per evitare il bias di cercare solo ciò che già sospettiamo.

Azione da fare adesso: sulle tue ultime PCAP di test, apri Statistics → Conversations e ordina per byte. Se c'è un flusso che non sai spiegare, analizzalo con Follow TCP Stream. Allenati a riconoscere il traffico normale del tuo ambiente prima che arrivi un incidente.

Come Riconoscere un Flusso C2 e una Esfiltrazione di Dati

La parte più delicata della network forensics è distinguere un falso positivo da un vero indicatore di compromissione (IoC). Lo vediamo tutti i giorni: un cliente ci mostra un IP straniero e ci chiede "è un attacco?". A volte sì, spesso è solo un servizio esterno legittimo. Serve metodo.

Un flusso C2 (Command and Control) ha caratteristiche ricorrenti: connessioni periodiche con intervalli regolari, payload di dimensioni costanti, protocolli non standard su porte comuni, o DNS verso domini appena registrati. Il traffico C2 non è mai casuale. Segue un ritmo, perché il malware deve ricevere comandi e inviare stato.

Per individuare un C2 in Wireshark:

# Trova connessioni che si ripetono con intervalli regolari
# Usa il filtro per il server sospetto e guarda la colonna Time
ip.addr == 10.0.0.10 && tcp.port == 443

Poi osserva la differenza tra i timestamp. Se vedi un pacchetto ogni 60 secondi esatti, molto probabilmente è un beacon. Apri la conversazione e guarda la dimensione del payload. Se è sempre la stessa, è un comando cifrato o un heartbeat.

Una esfiltrazione di dati, invece, è un flusso di dati in uscita anomalo per volume. Il modo più efficace per vederla è ancora una volta la statistica Conversations, ordinata per data transfer. Se un host parla con un IP esterno e il volume è sproporzionato rispetto alla normale attività, hai un sospetto. A quel punto guarda il payload: se è cifrato e viaggia su porta 53 verso un server DNS non autorizzato, hai trovato il tunnel.

Il pattern DNS tunnel

Il DNS tunnel è la tecnica preferita per aggirare i firewall: il malware codifica i dati rubati nelle query DNS verso un dominio controllato dall'attaccante. In Wireshark è riconoscibile perché il nome di dominio contiene sottodomini lunghi e casuali.

// Filtro per trovare query DNS sospette con label molto lunghe
dns.qry.name.len > 50

Un dominio normale esempio.com raramente ha sottodomini di 50+ caratteri. Se ne vedi uno, non è un caso.

Azione da fare adesso: scarica una PCAP pubblica con traffico C2 da un repository come Malware-Traffic-Analysis.net e applica i filtri di questa sezione. Non è necessario analizzare tutto il file, solo trovare un beacon. Quando lo trovi, descrivilo a parole: IP sorgente, IP destinazione, porta, intervallo, dimensione payload. Questa è la base della tua prossima relazione.

Come Estarre Prove e Scrivere una Relazione Forense

La network forensics non finisce con l'analisi. Finisce quando produci una prova utilizzabile. Che tu debba consegnarla a un consulente esterno, alla tua direzione o a un'autorità, il file PCAP da solo non basta. Serve una relazione che spieghi cosa hai trovato, perché è malevolo, e come lo hai scoperto.

Le buone relazioni di network forensics seguono una struttura semplice: contesto, metodologia, evidenze, conclusioni. Contesto: cosa è successo, quando, su quale sistema. Metodologia: quali strumenti e quali filtri hai usato. Evidenze: screenshot dei pacchetti, estrazione dei payload, hash dei file. Conclusioni: cosa indicano le prove e quali sono le prossime azioni.

Uno strumento che usiamo spesso per estrarre file dalle PCAP è foremost. Quando un attaccante trasferisce un payload tramite HTTP, il file può essere recuperato e analizzato in isolamento.

# Estrae file dalla PCAP
foremost -i incidente.pcap -o estrazione/

# Oppure usa tcpdump per estrarre il payload di una singola sessione
tcpdump -r incidente.pcap -A -c 50 'host 185.220.101.34 and tcp port 80'

Le evidenze vanno conservate integre: una copia del file in sola lettura, l'hash SHA-256 calcolato e annotato, e la catena di custodia documentata. Se il file viene usato in un procedimento, l'integrità è tutto.

Azione da fare adesso: prendi uno screenshot della conversazione malevola che hai trovato nella sezione precedente, esporta i pacchetti rilevanti con File → Export Specified Packets e calcola l'hash SHA-256 del file PCAP originale. Queste tre azioni producono un set di evidenze minimo ma professionale.

Network Forensics e Incident Response — Quale è il Loro Ruolo?

Potresti chiederti: dove si inserisce la network forensics nel piano di incident response? La risposta è: subito dopo il rilevamento e prima della eradicazione. Gli errori peggiori che vediamo nelle PMI sono due: ripristinare il sistema prima di aver analizzato il traffico, e buttare le PCAP di un incidente per liberare spazio. Entrambi cancellano le uniche prove disponibili.

Nel nostro approccio, la network forensics è il ponte tra il rilevamento e la risposta. Ti dice chi è entrato, come è entrato, cosa ha toccato e dove potrebbero esserci altre backdoor. Saltare questo passaggio significa tappare una falla senza sapere se ci sono altre porte aperte. Sul nostro percorso di incident response e forensics digitale, la network forensics è uno dei pilastri su cui costruire una difesa che regge.

Il consiglio che diamo a ogni cliente è semplice: prepara la cattura prima dell'incidente. Avere un sistema di packet capture sempre attivo sulle partizioni critiche ti dà la visibilità che nessun log può dare. Il costo di storage di 7 giorni di traffico è irrisorio rispetto al costo di un incidente non analizzato.

Strumenti Complementari a Wireshark

Wireshark è potente, ma da solo non basta. Nei casi complessi usiamo strumenti complementari per automatizzare l'analisi o per gestire volumi enormi di traffico.

tshark è la versione a riga di comando di Wireshark. Permette di estrarre campi specifici da PCAP di grandi dimensioni e di creare un riepilogo CSV per correlazioni successive. Un comando che usiamo spesso per tracciare flussi sospetti:

# Elenco di tutte le connessioni TCP con dimensioni
tshark -r incidente.pcap -q -z conv,tcp

Zeek (ex Bro) trasforma il traffico in log strutturati: connessioni, DNS, HTTP, TLS. È un IDS passivo ed è eccellente per l'analisi su larga scala. I log di Zeek si correlano facilmente con i dati di Wireshark.

NetworkMiner è un'altra utility che amiamo per la sua capacità di riassemblare i flussi e mostrare i file trasferiti con un'interfaccia semplice. È utile quando il cliente non è tecnico e vuole vederci chiaro.

Azione da fare adesso: installa tshark e riproduci l'analisi delle conversazioni che hai fatto con Wireshark, ma da terminale. La familiarità con tshark ti renderà più veloce nell'analisi di grandi volumi, dove la GUI non è pratica.

Cosa fare adesso

Non aspettare un incidente per prepararti. La network forensics si allena sul traffico normale prima ancora che su quello malevolo. Queste sono le prime tre azioni che faresti se fossi nelle nostre scarpe:

1. Configura la cattura continua sul gateway principale con rotazione giornaliera. Se non l'hai già fatto, parti da una cronologia di 7 giorni. Ti ripagherai al primo attacco.
2. Esercitati sulle PCAP pubbliche di traffico malevolo. Impara a riconoscere il pattern del beacon e la firma del DNS tunnel. La velocità di analisi arriva con la ripetizione.
3. Definisci il tuo processo di consegna prove. Dopo ogni analisi, calcola l'hash del file PCAP, salva gli screenshot dei flussi sospetti e scrivi una relazione di una pagina. Vedrai che quando servirà davvero, avrai già il metodo.

Il traffico di rete non mente. Sta a te ascoltarlo.