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

Il Fantasma nella Rete

·4 mins
medio difesa
Network-Defense Threat-Hunting
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Il Fantasma nella Rete

TL;DR
  • Un honeypot è un sistema esca - qualsiasi connessione ricevuta è per definizione sospetta
  • La ricognizione interna (lateral movement iniziale) lascia tracce nei log prima che l'attaccante agisca
  • Analizzare chi ha contattato il honeypot rivela quali host sono compromessi o controllati da un attaccante
  • IDS/IPS signature-based non rileva zero-day - il comportamento anomalo verso risorse inesistenti lo fa
▶ $ history
  • tshark -r capture.pcap -Y "ip.dst == 192.168.10.99" -T fields -e ip.src -e tcp.dstport
  • dig -x 192.168.10.99

Sono le 14:33. Il SIEM ha flaggato una connessione TCP verso 192.168.10.99. Il problema: a quell'IP non c'è nessun server. Non c'è nessun servizio. Non c'è nessun device registrato nell'inventario.

Eppure qualcuno lo ha contattato.

L'IP che non esiste
#

Il nostro honeypot è un sistema configurato per sembrare attraente - share di rete aperta, nome host FILESERVER-OLD, porta 445 aperta. Nessun utente legittimo dovrebbe mai connettersi lì. Non è documentato. Non è nel DNS interno. Non ha un record in Active Directory.

Questo è esattamente il punto.

graph TD
    I["Internet"] --> FW["Firewall perimetrale"]
    FW --> LAN["LAN aziendale"]
    LAN --> WS["Workstation (192.168.10.x)"]
    LAN --> SRV["Server reali (192.168.20.x)"]
    LAN --> HP["HONEYPOT 192.168.10.99
    Nessun uso legittimo
    Ogni connessione = alert"]
    HP -->|"alert istantaneo"| SIEM["SIEM / SOC"]

Qualsiasi connessione al honeypot segnala una di queste tre cose: un attaccante in ricognizione, un worm che scansiona la rete automaticamente, o un device già compromesso che esegue ordini da C2.

Cosa vedo nel pcap
#

Filtro sul traffico verso quell'IP nelle ultime sei ore.

tshark -r capture.pcap \
  -Y "ip.dst == 192.168.10.99" \
  -T fields -e frame.time -e ip.src -e tcp.dstport
14:31:02  192.168.10.47   445
14:31:02  192.168.10.47   139
14:31:03  192.168.10.47   3389
14:31:04  192.168.10.47   22
14:31:05  192.168.10.47   80
# output simulato

Un solo host sorgente: 192.168.10.47. Cinque porte diverse in tre secondi - 445, 139, 3389, 22, 80. Non è un utente che cerca un file. È una scansione sistematica di porte.

192.168.10.47 è una workstation del reparto marketing. Nella normale operatività, quella macchina non apre mai connessioni verso altri host interni su porte di questo tipo.

Il profilo della scansione
#

Espando la ricerca a tutto il traffico generato da 192.168.10.47 nell'ultima ora.

tshark -r capture.pcap \
  -Y "ip.src == 192.168.10.47 && tcp.flags.syn == 1 && tcp.flags.ack == 0" \
  -T fields -e ip.dst \
  | sort -u | wc -l
31
# output simulato

Trentuno host distinti contattati con SYN puro in un'ora - pattern classico di port scan. La workstation sta mappando sistematicamente la subnet /24.

Il primo host che ha scansionato era il honeypot. Questo ci dice che la scansione parte da 192.168.10.1 e procede in ordine - arrivata a .99, il honeypot ha alzato la mano.

Ricostruire il percorso
#

graph LR
    ATT["Attaccante esterno
    o accesso iniziale via phishing"] -->|"initial access"| WS["192.168.10.47
    Workstation marketing
    COMPROMESSA"]
    WS -->|"lateral movement recon"| HP["Honeypot 192.168.10.99
    ALERT"]
    WS -->|"scansione 192.168.10.x"| ALTRI["31 host scansionati"]
    HP --> SOC["SOC avvisato
    14:33"]
    SOC -->|"indaga"| WS

La workstation è il pivot. Qualcuno ha ottenuto accesso a quella macchina - phishing, credenziali rubate, exploit - e ora sta eseguendo ricognizione interna prima di muoversi verso target di valore.

IoC e tecniche
#

TipoValoreContestoMITRE ATT&CK
IP interno192.168.10.47Host compromesso, sorgente scansioneT1046
ComportamentoSYN scan su 31 host interni in 60 minNetwork Service DiscoveryT1046
ComportamentoConnessione a risorsa inesistenteHoneypot triggered - ricognizione attivaT1018
TecnicaPorte 445/139 - targeting SMBLateral movement preparationT1021.002

Risposta
#

# Isola immediatamente la workstation a livello switch
# (NAC quarantine o disabilita porta)

# Verifica processi attivi sulla macchina al momento dell'alert
# (da memory forensics o EDR)

# Cerca altri host con pattern simile nella stessa finestra temporale
tshark -r capture.pcap \
  -Y "tcp.flags.syn == 1 && tcp.flags.ack == 0" \
  -T fields -e ip.src \
  | sort | uniq -c | sort -rn | head -10

Checklist:

  • Isola la workstation - togli accesso rete prima di investigare
  • Acquisisci immagine della memoria (volatility) e del disco prima di spegnere
  • Analizza processi, connessioni e task schedulati al momento dell'alert
  • Cerca lateral movement riuscito - qualcuno ha risposto alla scansione?
  • Verifica se altri host hanno pattern di scansione simili (worm?)
  • Cambia credenziali dell'utente della workstation

exit 0
#

Un honeypot non protegge niente. Non ha patch da aggiornare, non ha dati da cifrare, non ha utenti da difendere. È un sensore puro - il suo unico valore è non ricevere mai traffico legittimo.

Quando il SIEM ha alzato quell'alert a ore 14:33, la scansione era iniziata alle 14:31. Due minuti. In un ambiente senza honeypot, quell'attaccante avrebbe continuato silenzioso per ore. Forse giorni.

Il fantasma nella rete si è rivelato perché ha bussato alla porta sbagliata.

Comandi usati: tshark Concetti correlati: smtp, dns-resolution-flow

Related