Scansione di Blocchi IP: Scanning IP Blocks (T1595.001)

La simulazione di una scansione di blocchi IP in ambiente red team è il punto di partenza di qualsiasi ingaggio esterno. L'obiettivo non è soltanto trovare porte aperte, ma costruire un inventario ragionato della superficie d'attacco, proprio come farebbero Ember Bear o TeamTNT contro le rispettive tipologie di target.

Il primo passo è identificare i blocchi IP associati all'organizzazione. Interrogando i database WHOIS dei Regional Internet Registries si ottengono i range CIDR assegnati. Da riga di comando, whois -h whois.ripe.net -- '-i origin ASXXXXX' restituisce tutti i prefissi annunciati da un determinato Autonomous System (sostituendo ASXXXXX con il numero reale). Lo strumento amass (open source) di OWASP automatizza questa enumerazione:

amass intel -asn XXXXX

Una volta definiti i range, la scansione vera e propria può seguire un approccio stratificato. Si parte da un discovery veloce per capire quali host sono vivi, per poi approfondire con scansioni mirate.

Fase 1 — Host discovery ad alta velocità. Masscan (open source) è progettato per scansioni su larga scala con rate control preciso:

masscan 198.51.100.0/24 -p 80,443,22,8080 --rate 1000 -oJ output.json

Il parametro --rate controlla i pacchetti al secondo: in laboratorio si può alzare, in ingaggi reali va calibrato per non saturare il link o triggerare contromisure.

Fase 2 — Scansione dettagliata con fingerprinting. Sugli host identificati, Nmap (open source) offre granularità superiore:

nmap -sV -O -T3 -iL live_hosts.txt -oX detailed_scan.xml

Il flag -sV esegue il service version detection, -O tenta l'OS fingerprinting, e -T3 mantiene un timing moderato. Il risultato XML è parsabile con strumenti come searchsploit di Exploit-DB (open source) per correlare immediatamente versioni e vulnerabilità note.

Fase 3 — Scansione mirata in stile TeamTNT. Questo gruppo opera tipicamente con liste di IP specifici piuttosto che range interi, puntando a servizi cloud mal configurati. Per simulare questo approccio, Naabu (open source) di ProjectDiscovery è particolarmente efficace:

naabu -list target_ips.txt -p 2375,2376,6443,10250 -o exposed_services.txt

Le porte scelte nell'esempio corrispondono a Docker API e Kubernetes API, target tipici di attori focalizzati su infrastrutture cloud e container.

Tutta l'attività va documentata con timestamp e output strutturati. Consiglio di centralizzare i risultati in un workspace Reconmap (open source) o equivalente per correlare le informazioni con le fasi successive dell'ingaggio.

Rilevare una scansione di blocchi IP dall'interno è un esercizio di detection indiretta. L'attività avviene dall'esterno, quindi non troverai processi sospetti sugli endpoint: ciò che puoi osservare è il pattern di traffico che arriva al tuo perimetro.

La sorgente di log critica è il Network Traffic, come indicato nella detection ufficiale. I firewall perimetrali, gli IDS/IPS e i flow collector (NetFlow/sFlow) sono i sensori primari. L'anomalia da cercare è un singolo IP sorgente che contatta un numero elevato di indirizzi interni in un intervallo temporale ristretto, spesso su porte identiche o su un set limitato di porte.

Su Suricata (open source), le regole di threshold rilevano il pattern classico:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP sweep detected"; detection_filter:track by_src, count 50, seconds 30; sid:1000001; rev:1;)

Questa regola scatta quando un IP esterno invia più di 50 pacchetti ICMP verso la rete interna in 30 secondi. Per le scansioni TCP SYN, la logica è analoga ma va applicata al traffico con flag SYN senza completamento del three-way handshake.

In un SIEM come Elastic Security (freemium) o Splunk (a pagamento), la correlazione diventa più espressiva. Il concetto chiave è aggregare le connessioni per IP sorgente e contare il numero di IP destinazione distinti e porte distinte in finestre temporali mobili. Una query KQL su Elastic potrebbe filtrare il traffico firewall aggregando source.ip con cardinalità elevata su destination.ip in finestre di 60 secondi.

La gestione dei falsi positivi richiede una whitelist degli scanner legittimi: motori di ricerca come Shodan e Censys, vulnerability scanner aziendali, e i range di servizi CDN che possono generare connessioni distribuite. Consiglio di mantenere una lookup table aggiornata con gli ASN di questi servizi.

Per il hardening preventivo, la mitigazione Pre-compromise suggerisce di monitorare la propria superficie esposta prima che lo faccia l'avversario. Strumenti come Shodan Monitor (freemium) o Censys Attack Surface Management (a pagamento) ti avvisano quando un nuovo servizio diventa visibile dall'esterno — la stessa vista che ha l'attaccante.

L'analisi forense di una scansione IP è intrinsecamente diversa da quella di una compromissione endpoint. Gli artefatti risiedono quasi esclusivamente nei log di rete e nei dispositivi perimetrali, non sui singoli host. Il lavoro del forensic analyst consiste nel ricostruire la fase di ricognizione a partire da tracce che spesso emergono solo retrospettivamente, quando un incidente è già in corso.

Il punto di partenza sono i log del firewall perimetrale. Ogni connessione bloccata o permessa lascia un record con timestamp, IP sorgente, IP destinazione, porta e azione. L'artefatto chiave è una sequenza di connessioni dallo stesso IP sorgente verso indirizzi consecutivi nel range aziendale — il footprint inconfondibile di una scansione sequenziale. Esporta i log in formato CSV e ordina per IP sorgente e timestamp per visualizzare il pattern.

I log IDS/IPS forniscono un secondo livello di evidenza. Se Suricata o Snort (entrambi open source) erano attivi al momento della scansione, i file eve.json o unified2 contengono gli alert con la firma specifica che ha matchato. Cerca eventi classificati come "attempted-recon" o "network-scan" nel periodo di interesse.

Per le scansioni più sofisticate — quelle che completano il three-way handshake per ottenere banner — i log applicativi dei servizi esposti diventano rilevanti. I log di Apache/Nginx registrano richieste da IP che non hanno mai proseguito con traffico legittimo. I log di OpenSSH mostrano handshake TLS o tentativi di autenticazione da IP che compariranno poi nella timeline dell'intrusione vera e propria.

La correlazione con fonti esterne è fondamentale. Verifica l'IP sorgente della scansione su database di reputazione come AbuseIPDB (freemium) e GreyNoise (freemium). GreyNoise è particolarmente utile perché classifica gli IP in "benign" (scanner legittimi) e "malicious", aiutandoti a distinguere la ricognizione opportunistica da quella mirata. Se l'IP risulta associato a infrastruttura nota di gruppi come Ember Bear — che ha preso di mira range IP legati a organizzazioni governative e infrastrutture critiche — questo dato arricchisce significativamente la timeline.

Infine, un controllo su passive DNS e database WHOIS storici (DomainTools, a pagamento, o servizi equivalenti) permette di collegare l'IP sorgente a domini, registrant e pattern infrastrutturali più ampi, costruendo il ponte tra la fase di ricognizione e l'eventuale compromissione successiva.

La scansione di blocchi IP è utilizzata da 2 gruppi documentati, con profili operativi e motivazioni radicalmente diversi. Questa diversità rende la tecnica un indicatore debole se presa isolatamente, ma prezioso quando contestualizzata nel profilo dell'avversario.

Ember Bear (G1003) è un gruppo orientato verso target governativi e infrastrutture critiche. La sua attività di scansione è mirata: seleziona range IP specifici appartenenti a organizzazioni nel proprio mirino e li analizza alla ricerca di vulnerabilità sfruttabili. Il pattern suggerisce un approccio di ricognizione focalizzato, dove la scansione è il preludio diretto a tentativi di accesso iniziale. Per un TI analyst che monitora enti governativi o operatori di infrastrutture critiche, attività di scansione anomala proveniente da IP associati a questo gruppo giustifica un innalzamento immediato del livello di allerta.

TeamTNT (G0139) opera con un modello completamente diverso. Questo gruppo si concentra su ambienti cloud e container, e la sua scansione parte da liste di IP precompilate anziché da range contigui. Questo approccio indica l'utilizzo di fonti di intelligence proprie — probabilmente risultati di query su motori di ricerca come Shodan o Censys — per identificare host con servizi cloud esposti prima ancora di avviare la scansione diretta. Il pattern è più opportunistico e orientato al volume.

Il denominatore comune tra i due gruppi è che la scansione IP non è mai fine a sé stessa: è sempre propedeutica a fasi successive ben definite. Per Ember Bear, alimenta campagne di sfruttamento vulnerabilità contro target specifici. Per TeamTNT, alimenta compromissioni massive di ambienti container per cryptomining o furto di credenziali cloud.

Dal punto di vista del tracking, la raccomandazione operativa è duplice. Per chi protegge infrastrutture governative, correlare le scansioni ricevute con gli IoC noti di Ember Bear utilizzando piattaforme come MISP (open source) o equivalenti. Per chi gestisce ambienti cloud-native, monitorare le scansioni sulle porte caratteristiche dei servizi container (Docker API, kubelet) e incrociarle con i TTP storici di TeamTNT. In entrambi i casi, la scansione è il segnale più precoce disponibile — e spesso l'unico che precede l'impatto.

Framework MITRE ATT&CK: T1595.001 (Scanning IP Blocks), TA0043 (Reconnaissance), G1003 (Ember Bear), G0139 (TeamTNT), M1056 (Pre-compromise). Tool di detection: Suricata, Snort, Elastic Security, Splunk, GreyNoise, AbuseIPDB, Shodan Monitor. Integrato con conoscenza professionale per tool e procedure operative.