↓ Skip to main content
u-random
u-random
  1. Concetti/

Wireshark

·12 mins
base
Network-Defense Dfir
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Wireshark

Cosa fa
#

Analizzatore di pacchetti con interfaccia grafica. Cattura traffico live da una interfaccia di rete oppure apre file .dfir salvati con tcpdump. Mostra ogni pacchetto scomposto nei livelli OSI — dal frame fisico fino al payload applicativo. Strumento standard in SOC per analisi traffico e incident response.

Workflow tipico
#

tcpdump -w capture.dfir          (cattura sul server remoto)
         |
         | scp o rsync
         v
Wireshark File → Open            (analisi in locale con GUI)
         |
         | filtri display
         v
isolamento del traffico sospetto

tcpdump e Wireshark leggono lo stesso formato .dfir — si usano insieme.

Interfaccia — le tre zone principali
#

┌─────────────────────────────────────────────┐
│  BARRA FILTRI                               │
│  "Apply a display filter..."                │
├─────────────────────────────────────────────┤
│  LISTA PACCHETTI                            │
│  N  | Time | Src | Dst | Proto | Info       │
│  19 | 0.58 | ... | ... | TCP   | [SYN]      │
│  21 | 0.58 | ... | ... | TCP   | [SYN,ACK]  │
├─────────────────────────────────────────────┤
│  DETTAGLIO PACCHETTO (click su una riga)    │
│  > Frame                                    │
│  > Ethernet II                              │
│  > Internet Protocol                        │
│  > Transmission Control Protocol            │
│    > Flags: 0x012 (SYN, ACK)                │
│        ACK: Set                             │
│        SYN: Set                             │
├─────────────────────────────────────────────┤
│  BYTES RAW (esadecimale)                    │
└─────────────────────────────────────────────┘

Frame → livello 1 — fisico Ethernet II → livello 2 — MAC Internet Protocol → livello 3 — IP Transmission Control Proto → livello 4 — TCP, porte, flag

I flag TCP in Wireshark
#

Ogni flag e' un bit — Set = 1 (acceso), Not set = 0 (spento). Wireshark li mostra espansi, tcpdump li comprime in [S.].

Wireshark                    tcpdump
─────────────────────────    ───────
SYN: Set, ACK: Not set   →   [S]
SYN: Set, ACK: Set       →   [S.]
ACK: Set                 →   [.]
PSH: Set, ACK: Set       →   [P.]
RST: Set                 →   [R]
RST: Set, ACK: Set       →   [R.]
FIN: Set, ACK: Set       →   [F.]

La rappresentazione esadecimale Flags: 0x012 e' la stessa informazione compressa — non serve leggerla a memoria, serve riconoscere il pattern.

Analisi Malware & Triage SOC
#

In un contesto SOC, Wireshark serve per identificare rapidamente chi e' la vittima e cosa sta facendo il malware.

Identificare l'Utente (Username)
#

In una rete Windows, lo username non e' in ogni pacchetto. Devi cercarlo nei protocolli di autenticazione:

ProtocolloFiltro DisplayCosa cercare
Kerberoskerberos.CNameStringPacchetti AS-REQ (richiesta ticket login)
NTLMntlmssp.auth.usernameMessaggi di autenticazione NTLM
SMB2smb2.userSession Setup (se non cifrato)

Isolare il traffico Malware (C2)
#

Per vedere sia HTTP che l'inizio di connessioni TLS verso un IP sospetto, eliminando il rumore dei servizi di discovery locale:

# Filtro "Lumma Stealer" style
(http.request or tls.handshake.type <mark> 1) && !ssdp && !nbns && ip.addr </mark> [IP_SOSPETTO]
  • tls.handshake.type == 1 → Isola il Client Hello, ovvero l'inizio della negoziazione TLS (anche se il contenuto sara' poi cifrato, vedi il dominio target nell'estensione SNI).
  • !ssdp / !nbns → Nasconde i pacchetti di discovery che "sporcano" l'analisi.

Identificare lo Hostname
#

Se non hai accesso ai log DHCP, usa NBNS per vedere come si annuncia la macchina: nbns → Cerca pacchetti di tipo Registration o Query. Il nome host apparira' come NOME-PC<20>.

Filtri display — i piu' usati
#

I filtri si scrivono nella barra in cima. Sintassi diversa da tcpdump.

# Per host
ip.addr == 192.168.64.200
ip.src == 192.168.64.200         # solo sorgente
ip.dst == 192.168.64.3           # solo destinazione

# Per porta
tcp.port == 22
tcp.port <mark> 80 || tcp.port </mark> 443

# Per protocollo
tcp
udp
icmp
dns
http

# Per flag TCP
tcp.flags.syn == 1                          # tutti i SYN
tcp.flags.syn <mark> 1 && tcp.flags.ack </mark> 0    # solo SYN puri (port scan)
tcp.flags.syn <mark> 1 && tcp.flags.ack </mark> 1    # solo SYN+ACK (porte aperte)
tcp.flags.reset == 1                        # tutti i RST

# Combinazioni
ip.addr <mark> 192.168.64.200 && tcp.flags.syn </mark> 1

Detection port scan con filtri
#

Dal lab settimana 6 — nmap -sS su Ubuntu:

Filtro: tcp.flags.syn <mark> 1 && tcp.flags.ack </mark> 0
Risultato: 2005 pacchetti — tutti i SYN di nmap

Filtro: tcp.flags.syn <mark> 1 && tcp.flags.ack </mark> 1
Risultato: 1 pacchetto — solo la porta 22 aperta

2005 SYN senza ACK = port scan confermato. 1 SYN+ACK = una sola porta aperta trovata.

Chi manda cosa — RST e SYN scan
#

Nel SYN scan di nmap i RST vengono mandati da entrambe le parti, ma in momenti e contesti diversi:

PORTA APERTA (es. 22)
  Kali  --[S]-->    Ubuntu:22    "voglio connettermi"
  Ubuntu --[S.]--> Kali          "sono aperta"
  Kali  --[R]-->    Ubuntu:22    RST — nmap taglia intenzionalmente
                                  non completa il handshake
                                  → non appare nei log di SSH

PORTA CHIUSA (es. 993)
  Kali  --[S]-->    Ubuntu:993   "voglio connettermi"
  Ubuntu --[R.]--> Kali          RST — nessun servizio in ascolto
                                  Ubuntu rifiuta immediatamente

In Wireshark per distinguerli guarda la direzione:

ip.src <mark> 192.168.64.200 && tcp.flags.reset </mark> 1   ← RST mandati da Kali
ip.src <mark> 192.168.64.3   && tcp.flags.reset </mark> 1   ← RST mandati da Ubuntu

Mittente e destinatario in Wireshark
#

La colonna Source e la colonna Destination mostrano IP e porta:

192.168.64.200:38282  →  192.168.64.3:22
       ^         ^              ^      ^
    IP src    porta src      IP dst  porta dst

Il numero dopo il punto e' la porta. Porta alta (>1024) = porta effimera assegnata dal kernel al client. Porta bassa (<1024) = porta del servizio sul server.

Per filtrare per direzione specifica:

ip.src == 192.168.64.200    ← solo traffico CHE PARTE da Kali
ip.dst == 192.168.64.3      ← solo traffico CHE ARRIVA a Ubuntu
ip.addr == 192.168.64.200   ← traffico da O verso Kali (entrambe le direzioni)

Combinazioni di flag impossibili
#

Alcuni flag sono semanticamente incompatibili — non possono apparire insieme nello stesso pacchetto perche' si contraddicono:

SYN + RST   → impossibile
              SYN = "voglio aprire una connessione"
              RST = "chiudo tutto immediatamente"
              non puoi fare entrambe le cose insieme

SYN + FIN   → impossibile
              SYN = "inizio"
              FIN = "ho finito"
              non puoi iniziare e finire nello stesso pacchetto

Combinazioni valide che hai visto nel lab:

[S]    SYN solo              → primo pacchetto handshake
[S.]   SYN + ACK             → risposta al SYN (porta aperta)
[.]    ACK solo              → conferma ricezione
[P.]   PSH + ACK             → dati da consegnare subito
[R]    RST solo              → reset brusco
[R.]   RST + ACK             → reset con conferma
[F.]   FIN + ACK             → chiusura elegante

Filtri aggiuntivi — lab settimana 6
#

# Filtra per direzione
ip.src == 192.168.64.200              # traffico da Kali
ip.dst == 192.168.64.3                # traffico verso Ubuntu

# RST per tipo
ip.src <mark> 192.168.64.200 && tcp.flags.reset </mark> 1   # RST da Kali (nmap taglia)
ip.src <mark> 192.168.64.3   && tcp.flags.reset </mark> 1   # RST da Ubuntu (porte chiuse)

# ARP
arp                                    # tutto il traffico ARP
arp.opcode == 1                        # solo ARP request
arp.opcode == 2                        # solo ARP reply

# Conversation completeness — conversazioni incomplete
tcp.completeness < 31                  # handshake non completati

TCP Streams — tcp.stream
#

Wireshark assegna un indice numerico a ogni connessione TCP nel pcap. Una connessione e' identificata dalla quintupla {IP src, porta src, IP dst, porta dst, protocollo}.

tcp.stream == 0   ← prima connessione TCP nel pcap
tcp.stream == 5   ← sesta connessione TCP (es. upload web shell in WebStrike)

Ogni stream ha un ciclo di vita completo:

Apertura    → 3-way handshake: SYN → SYN+ACK → ACK
Dati        → uno o piu' scambi applicativi (GET, POST, risposta)
Chiusura    → 4-way: FIN+ACK → ACK → FIN+ACK → ACK

Tutti i pacchetti con tcp.stream == 5 appartengono a quella singola connessione — dal SYN iniziale all'ACK finale del FIN.

Browser e stream multipli
#

Il browser non usa una sola connessione per tutto. Apre piu' connessioni TCP verso lo stesso host — per il parallelismo o per risorse diverse. Ogni nuova connessione = nuovo tcp.stream. Con HTTP/1.1 (keep-alive) piu' richieste possono condividere lo stesso stream.

Filtri utili
#

tcp.stream == 5                    # isola una connessione specifica
http.request.method == "POST"      # filtra POST, poi segui HTTP stream

Follow HTTP Stream vs Follow TCP Stream
#

Con HTTP/1.1 Keep-Alive, piu' richieste HTTP condividono la stessa connessione TCP — un solo tcp.stream contiene GET della pagina, GET del CSS, POST del form, tutto insieme.

TCP stream 4  →  GET /index.html
                 GET /style.css
                 POST /upload        ← tutto nella stessa connessione
Follow TCP StreamFollow HTTP Stream
Cosa mostraRaw bytes della connessione TCPSolo gli scambi HTTP, separati
EncodingTutto raw — gzip incomprensibileDecomprime gzip, legge chunked
Quando usarloAnalisi anomalie di protocollo, estrazione file binariLeggere contenuto HTTP: form, payload, risposte HTML

In pratica: per leggere cosa ha inviato un form POST o cosa ha risposto un server web, usa Follow HTTP Stream. Per analizzare comportamenti TCP anomali o estrarre dati binari, usa Follow TCP Stream.

Export Objects
#

Ricostruisce e salva i file trasferiti a livello applicativo (Layer 7) direttamente dal pcap.

Menu: File → Export Objects → HTTP (o SMB, FTP, DICOM)

Packet  Hostname              Filename              Size
------  --------------------  --------------------  ------
  142   evil.example.com      /update.exe           284 KB
  891   192.168.1.10          /upload/shell.php       2 KB
 1203   cdn.legit.com         /jquery.min.js         87 KB

Funziona solo su traffico in chiaro — su TLS cifrato vedi il trasferimento ma non il contenuto.

Indicatori di sospetto nella lista
#

  1. Hostname — IP numerico, dominio DGA (x7kq2m.ru), paese inatteso
  2. Filename — doppia estensione (image.jpg.php), nomi generici (update.exe), nomi che mimano tool legittimi (svchost32.exe)
  3. Size — anomalia rispetto al tipo: .txt da 500KB, .jpg da 2MB
  4. Metodo HTTP — POST verso /uploads/ con file .php e' sospetto indipendentemente dal nome

Workflow tipico
#

Export Objects → individua file sospetto
              → Save
              → md5sum file.exe           (hash per VirusTotal)
              → file file.exe             (verifica tipo reale)
              → cat shell.php             (leggi codice se e' testo)

Follow TCP Stream
#

Funzione che ricostruisce una conversazione TCP completa — prende tutti i pacchetti tra due host sulla stessa coppia IP:porta e li mostra in sequenza come flusso unico, separando le due direzioni per colore.

Come si usa
#

  1. Clic destro su qualsiasi pacchetto della conversazione
  2. Follow → TCP Stream
  3. Si apre una finestra con il flusso completo

Cosa vedi
#

Colore 1 (rosso)  → client verso server
Colore 2 (blu)    → server verso client

I dati appaiono nell'ordine in cui sono stati scambiati — ricostruiti da Wireshark leggendo i numeri di sequenza TCP.

Pacchetti vs Conversazione
#

Filtro normale      → vedi i pacchetti uno per uno
                      ogni [P.] è un'unità separata

Follow TCP Stream   → vedi la conversazione completa
                      tutti i [P.] ricostruiti in ordine
                      come una singola chat

Un comando ls via netcat genera almeno 2 pacchetti:

Client → Server:  "ls\n"           [P.]  comando
Server → Client:  "file1 file2\n"  [P.]  risposta

Follow TCP Stream mostra entrambi come un unico flusso leggibile.

Traffico in chiaro vs cifrato
#

NETCAT (nessuna cifratura)
  Client manda:  "ls\n"          → TCP riceve testo in chiaro
  Follow Stream: leggi tutto     → comandi e risposte visibili

SSH (cifratura a livello 6 — Presentazione)
  Client manda:  [byte cifrati]  → TCP riceve dati gia' cifrati
  Follow Stream: byte illeggibili → la cifratura e' avvenuta prima di TCP

tcpdump e Wireshark operano a livello 2-3 — vedono i dati dopo che TCP li ha ricevuti, ma prima che l'applicazione li decifri. Per SSH, i dati arrivano a TCP gia' cifrati — nessuno strumento di cattura di rete li puo' leggere senza la chiave.

Trovare tutte le conversazioni
#

Menu Statistics → Conversations → tab TCP

Mostra quante conversazioni TCP distinte ci sono nel con IP, porte, numero di pacchetti e byte per ognuna.

Lab settimana 6 — netcat in chiaro
#

# Su Ubuntu — listener + cattura
nc -l -p 9999 &
sudo tcpdump -i enp0s1 port 9999 -w /tmp/netcat.dfir

# Da Kali — connessione
nc 192.168.64.3 9999
# digita comandi: ls, pwd, echo $0
# Ctrl+C per chiudere

# Trasferisci e apri in Wireshark
scp barno@192.168.64.3:/tmp/netcat.dfir ~/
# File → Open → netcat.dfir
# Clic destro su [P.] → Follow → TCP Stream

Output visibile in chiaro nel TCP Stream:

ls
pwd
file1 file2 file3
/home/barno

Attenzione — && vs & vs ;
#

Errore comune nel lab:

nc -l -p 9999 && sudo tcpdump ...   # SBAGLIATO — sequenziale con successo
nc -l -p 9999 ; sudo tcpdump ...    # SBAGLIATO — sequenziale sempre
nc -l -p 9999 & sudo tcpdump ...    # CORRETTO  — nc in background

Con && e ; tcpdump parte solo quando nc termina — troppo tardi per catturare il traffico della sessione. Con & nc va in background e tcpdump parte subito.

Il contatore Displayed
#

In basso a destra Wireshark mostra:

Packets: 2005   Displayed: 1000
   ^                ^
   totale dfir      corrispondono al filtro attivo

Utile per quantificare: 1000 SYN su 2005 pacchetti totali = circa meta' del traffico e' traffico di scan.

ARP in Wireshark — prima di tutto il resto
#

Il primo pacchetto di ogni nuova comunicazione e' sempre ARP. Kali non conosce il MAC di Ubuntu → chiede in broadcast.

Packet 1: ARP Request  → "Who has 192.168.64.3? Tell 192.168.64.200"
           opcode: 1, target MAC: 00:00:00:00:00:00 (non lo so ancora)

Packet 2: ARP Reply    → "192.168.64.3 is at b6:56:08:90:16:03"
           opcode: 2, sender MAC: b6:56:08:90:16:03

Packet 3: TCP SYN      → ora Kali conosce il MAC, puo' iniziare

Il MAC tutti-zero nel target dell'ARP Request significa "non conosco ancora il MAC di questa macchina" — e' la domanda.

tcpdump vs Wireshark
#

tcpdump                          Wireshark
──────────────────────────       ──────────────────────────────
terminale — server remoti        GUI — analisi locale
output testo                     colonne, colori, espandibile
filtri BPF (host, port)     filtri display (ip.addr.flags)
cattura → salva .dfir            apre .dfir + cattura live
veloce, scriptabile              lento, visivo

Non si escludono — si usano insieme.

Scenario Reale
#

Un analista riceve segnalazione di traffico anomalo da un server. Si collega via SSH, cattura con tcpdump:

ssh analista@server-prod
sudo tcpdump -i eth0 -w /tmp/anomalia.dfir -c 10000
# cattura 10000 pacchetti poi si ferma

Scarica il dfir in locale:

scp analista@server-prod:/tmp/anomalia.dfir ~/Desktop/

Apre in Wireshark, applica filtri per isolare il traffico sospetto, segue i TCP stream per vedere il contenuto delle connessioni.

Dove l'ho usato
#

  • Settimana 6 — prima apertura, filtri su port scan nmap -sS
  • Settimana 6 — lettura flag TCP a livello di bit

Note personali
#

Note

Wireshark richiede display grafico — non funziona via SSH senza X forwarding.Su server remoti si usa tcpdump per catturare, Wireshark in locale per analizzare.

Tip

La colonna "Displayed" in basso a destra mostra quanti pacchetti corrispondono al filtro attivo — utile per quantificare rapidamente quanto traffico di un certo tipo e' presente nel dfir.

Collegato a
#

  • incidents — categoria
  • tcpdump — genera i .dfir che Wireshark analizza
  • tcp-handshake — i flag che si leggono nel pannello dettaglio
  • network-interfaces — scegliere l'interfaccia giusta prima di catturare

Related