Scansione Attiva: Active Scanning (T1595)

In un ingaggio red team la scansione attiva è la fase di enumerazione esterna, da eseguire in modo controllato e autorizzato dallo scope. L'obiettivo è ricostruire la superficie esposta della vittima senza ancora sfruttare nulla.

Il coltellino svizzero resta Nmap (open source). Una discovery iniziale ICMP e ARP-based si ottiene con

nmap -sn 192.0.2.0/24

per individuare host vivi senza port scanning. Per una scansione TCP SYN mirata con rilevamento versione e OS:

nmap -sS -sV -O -p- --min-rate 1000 target

Lo script engine amplia l'enumerazione: nmap -sC --script vuln target lancia i controlli di vulnerabilità NSE. Per grandi range internet-facing conviene masscan (open source), che satura la banda con SYN asincroni:

masscan -p1-65535 203.0.113.0/24 --rate 10000

Sul fronte applicativo web, l'enumerazione di virtual host e path si fa con ffuf o gobuster (entrambi open source), mentre httpx e nuclei (open source, di ProjectDiscovery) permettono di sondare in massa endpoint HTTP e testare template di vulnerabilità note.

Un approccio lab-safe consiste nell'incrociare scansione attiva e passiva: prima si consultano Shodan e Censys (freemium) per capire cosa è già indicizzato, poi si valida attivamente solo ciò che serve, riducendo il rumore e il rischio di detection. Per ICMP crafting personalizzato e verifica di firewall/filtri, hping3 (open source) consente pacchetti su misura:

hping3 -S -p 80 -c 3 target

La catena tipica in laboratorio parte da host discovery, prosegue con port/service enumeration, quindi banner grabbing e infine fingerprinting delle versioni per correlare le CVE. Nel caso di infrastrutture OT/ICS — pertinente al contesto della campagna Triton — la ricognizione va condotta con estrema cautela: protocolli industriali come Modbus o proprietari Triconex sono fragili, e una scansione aggressiva può causare interruzioni. In un lab ICS si usano ambienti simulati (Conpot, open source) per non toccare controllori reali.

Un ethical hacker documenta timing, rate e sorgenti IP per permettere al blue team di correlare gli eventi durante il debrief, trasformando la fase di scanning in materiale didattico per la detection.

La scansione attiva è un'attività che avviene fuori dal perimetro, quindi il SOC la osserva soprattutto come traffico di rete anomalo in ingresso verso gli asset esposti. L'artefatto digitale centrale è il Network Traffic — sessioni e flussi — e la logica difensiva ruota attorno all'analisi comportamentale del traffico più che alla firma statica.

La detection AN1962 suggerisce di monitorare flussi di dati non comuni: processi o sorgenti che normalmente non comunicano in rete, o pattern che non rispettano gli standard di protocollo. In pratica, un singolo IP che tocca centinaia di porte o host in pochi secondi è la firma classica di un port scan; connessioni SYN senza completamento del three-way handshake, pacchetti ICMP echo verso interi range, o traffico con struttura sintattica anomala sono altri segnali forti.

Le fonti di log essenziali sono i firewall perimetrali (connection denied, port sweep), i flow record NetFlow/IPFIX, gli IDS come Suricata o Zeek (entrambi open source) e i log dei reverse proxy/WAF per lo scanning applicativo. In Zeek il file conn.log permette di aggregare connessioni per sorgente e contare porte distinte contattate; Suricata dispone di regole ET SCAN nel ruleset Emerging Threats (freemium) che identificano Nmap, masscan e nuclei tramite pattern di traffico. Un correlation rule in SIEM può innescare un alert quando un IP supera una soglia di porte o host distinti per unità di tempo.

Sul piano dei controlli preventivi (Harden/Isolate secondo la logica D3FEND), il rate-limiting a livello di firewall, la segmentazione di rete e l'inventario dei nodi riducono la superficie e la visibilità offerta all'attaccante. In ottica pre-compromise (M1056), il monitoraggio della superficie esterna con Shodan e Censys aiuta a sapere cosa vede l'avversario prima che lo scansioni.

Attenzione ai falsi positivi: scanner di vulnerabilità legittimi (Nessus, Qualys), tool di monitoraggio uptime, crawler dei motori di ricerca e servizi di security research internet-wide generano traffico simile allo scanning malevolo. Occorre mantenere una allowlist degli scanner interni autorizzati e delle finestre di scansione pianificate. Nel contesto ICS il rilevamento va tarato con estrema sensibilità: qualsiasi traffico anomalo verso controllori di sicurezza — come nel caso Triton — deve essere trattato come incidente prioritario, non come rumore di fondo.

Nell'analisi forense la scansione attiva lascia tracce prevalentemente lato rete e sui sistemi perimetrali, poiché precede l'accesso agli endpoint interni. La ricostruzione della timeline parte quindi dalle fonti che registrano il primo contatto tra infrastruttura avversaria e vittima.

Gli artefatti digitali chiave sono i Network Traffic e le Network Session: i pacchetti catturati (PCAP), i flow record e i log di connessione permettono di isolare l'IP sorgente, la sequenza di porte contattate e la cadenza temporale delle sonde. Con Zeek (open source) l'analista ricostruisce dal conn.log l'intera fase di enumeration correlando timestamp, durata e stato delle connessioni; Wireshark e la sua versione a riga di comando tshark (open source) consentono di ispezionare i PCAP e riconoscere le firme dei tool, ad esempio i pacchetti SYN privi di payload tipici di masscan o le opzioni TCP peculiari di Nmap.

Sui dispositivi perimetrali si esaminano i log dei firewall e dei bilanciatori: le deny rule aggregate rivelano port sweep e host sweep, mentre i log del WAF documentano lo scanning applicativo (path fuzzing, user-agent di nuclei o gobuster). La correlazione temporale di questi eventi permette di distinguere una scansione mirata da rumore di fondo internet-wide.

Per arricchire il quadro con fonti esterne — approccio necessario quando la ricognizione avviene fuori perimetro — l'analista consulta il passive DNS, gli storici WHOIS e i Certificate Transparency logs (il database CT di crt.sh, gratuito) per profilare l'infrastruttura da cui provengono le sonde. Piattaforme come VirusTotal (freemium) aiutano a verificare se gli IP sorgenti siano già noti come malevoli.

Un riferimento operativo emerge dal Triton Safety Instrumented System Attack (C0030): il gruppo TEMP.Veles condusse ricognizione di rete contro una organizzazione petrolchimica, mappando i controllori di sicurezza Triconex prima dell'attacco vero e proprio. L'incidente fu scoperto solo per un safety trip causato da un bug del malware, non dalla scansione in sé — a conferma di quanto la fase di reconnaissance sia difficile da individuare a posteriori. In un contesto ICS l'analista deve raccogliere le catture di rete degli storici di sistema OT e correlarle con gli eventi degli engineering workstation, ricostruendo il momento in cui l'infrastruttura industriale è stata sondata per la prima volta.

Sul piano dell'intelligence, la scansione attiva è una fase quasi universale nel ciclo di vita degli avversari, ma i dati documentati per questa tecnica convergono su un caso emblematico nel dominio industriale.

Il profilo di riferimento è TEMP.Veles, l'attore dietro il Triton Safety Instrumented System Attack (C0030), condotto tra giugno e agosto 2017 contro una organizzazione petrolchimica. In quella campagna il gruppo eseguì ricognizione di rete verso obiettivi di interesse, preparando il terreno per il dispiegamento del framework malware Triton contro specifici controllori di sicurezza Triconex. Ciò che rende questo caso particolarmente rilevante per un threat intelligence officer è il target: i Safety Instrumented System, ovvero i sistemi che impediscono condizioni operative pericolose in un impianto. Colpirli significa passare dal furto di dati alla potenziale minaccia per l'incolumità fisica.

Dal punto di vista dei pattern, la campagna evidenzia come la scansione attiva in ambito OT/ICS sia condotta con obiettivi diversi rispetto all'IT tradizionale. L'avversario non cerca semplicemente porte aperte, ma mappa protocolli industriali proprietari e identifica i controllori specifici da manipolare. La scoperta dell'incidente — avvenuta per un safety trip innescato da un difetto del malware e non da un rilevamento difensivo — segnala una lezione ricorrente nell'intelligence: contro attori sofisticati e pazienti, la fase di reconnaissance passa spesso inosservata, e la compromissione emerge solo quando qualcosa va storto nell'esecuzione avversaria.

Il trend che ne deriva riguarda la crescente attenzione di gruppi capaci verso infrastrutture critiche ed energetiche. La sequenza osservata — ricognizione di rete, poi accesso mirato, poi manipolazione di componenti safety — rappresenta un modello di riferimento per chi difende ambienti convergenti IT/OT.

Sul piano difensivo strategico, la mitigazione M1056 (Pre-compromise) raccomanda di ridurre l'esposizione informativa e di monitorare la propria superficie esterna con strumenti come Shodan e Censys, integrando piattaforme di threat intelligence quali MISP (open source), Recorded Future e Anomali (a pagamento) per tracciare infrastruttura, tool e attività avversaria. Per un intelligence officer, la priorità è correlare i tentativi di scansione verso asset OT esposti con i TTP noti degli attori interessati alle infrastrutture critiche, trattando ogni sonda anomala verso sistemi di sicurezza industriale come potenziale indicatore precoce di una campagna strutturata.

MITRE ATT&CK: tecnica T1595 (Active Scanning), tattica TA0043 (Reconnaissance). Campagna C0030 (Triton Safety Instrumented System Attack). Mitigazione M1056 (Pre-compromise). Detection DET0830 / AN1962. Tool di detection e analisi citati: Nmap, masscan, Zeek, Suricata, Wireshark/tshark, ffuf, nuclei, Shodan, Censys, MISP. Alcuni comandi, sintassi e artefatti forensi derivano da conoscenza professionale di cybersecurity oltre ai dati MITRE forniti.