Dump della MIB via SNMP: Simple Network Management Protocol Enumeration (T1602.001)

L'enumerazione SNMP inizia dalla scoperta del servizio sulla porta UDP 161. Un red teamer tipicamente combina scansione, brute force delle community string ed enumerazione degli OID rilevanti.

Per la scoperta iniziale, Nmap (open source) offre uno script dedicato:

nmap -sU -p 161 --script snmp-brute,snmp-info,snmp-interfaces,snmp-sysdescr

Lo script snmp-brute prova un dizionario di community string comuni, mentre snmp-info restituisce la descrizione del sistema. Una volta identificata una community string valida, si passa a strumenti dedicati.

snmpwalk dal pacchetto Net-SNMP (open source) è lo standard de facto per il dump della MIB. Il comando classico è:

snmpwalk -v2c -c public .1.3.6.1

Questo interroga ricorsivamente l'intero sottoalbero iso.org.dod.internet, restituendo migliaia di variabili. Per un target Cisco, l'OID .1.3.6.1.4.1.9.9.96 espone la funzionalità di copia della configurazione, mentre .1.3.6.1.2.1.1 fornisce descrizione, uptime e location.

Per il brute force delle community string in modo più aggressivo, onesixtyone (open source) è estremamente veloce:

onesixtyone -c community.txt -i targets.txt

snmp-check (open source, incluso in Kali) produce un report leggibile con hostname, interfacce, processi in esecuzione e software installato su host Windows con SNMP attivo:

snmp-check -c public

Per scenari più mirati, il modulo Metasploit (freemium, edizione community open source) auxiliary/scanner/snmp/snmp_enum automatizza l'estrazione delle informazioni tipiche di sistemi Windows e Cisco. Esiste anche auxiliary/scanner/snmp/cisco_config_tftp che, in presenza di community RW, può forzare un router Cisco a esfiltrare la propria running-config verso un server TFTP controllato dall'attaccante.

Su ambienti Windows con SNMP legacy, gli OID hrSWInstalledName (.1.3.6.1.2.1.25.6.3.1.2) elencano il software installato, mentre hrSWRunName (.1.3.6.1.2.1.25.4.2.1.2) mostra i processi attivi — informazioni preziose per pianificare le fasi successive.

Per laboratorio, è utile allestire un router virtuale con GNS3 (open source) o EVE-NG (freemium) configurando community string deboli, così da praticare l'enumerazione end-to-end senza rischi legali. In un engagement reale, la raccolta va sempre limitata allo scope autorizzato e documentata per il report finale.

La detection di T1602.001 si concentra sul management plane dei dispositivi di rete e sfrutta le fonti networkdevice:syslog, networkdevice:audit e la telemetria di flusso NSM:Flow (NetFlow, IPFIX, sFlow).

Il pattern principale è l'anomalia volumetrica: un client SNMP legittimo effettua query mirate a un ristretto insieme di OID durante finestre di polling regolari (tipicamente ogni 30-300 secondi da un NMS come SolarWinds, LibreNMS o Zabbix). Un attaccante che esegue snmpwalk genera invece migliaia di GetNext o GetBulk consecutivi in pochi secondi, coprendo l'intero sottoalbero .1.3.6.1. Una regola comportamentale efficace conta le richieste SNMP per source IP in finestre di 60 secondi e genera alert quando il volume supera il baseline di 3-5 deviazioni standard.

Gli indicatori chiave da monitorare includono: source IP non appartenenti alla whitelist degli NMS autorizzati, community string non riconosciute (che generano authentication failure loggati come SNMP_AUTH_FAIL sui router Cisco IOS), pattern di GetBulk con max-repetitions elevati, e query concentrate su OID sensibili come le tabelle di routing (ipRouteTable) o la MIB di configurazione. Il tuning richiede quattro parametri: AuthorizedAdminIPs per la whitelist, NormalSNMPQueryRate come soglia volumetrica, CommunityStringPatterns per identificare stringhe non conformi e TimeWindow per le finestre di manutenzione consentite.

Su SIEM come Splunk (a pagamento) o Elastic Security (freemium), una search efficace correla eventi syslog Cisco con codice %SNMP-3-AUTHFAIL seguiti entro breve tempo da traffico UDP/161 di volume anomalo. Su piattaforme aperte, Zeek (open source) con lo script snmp.log registra tipo di richiesta, community string e OID richiesti, offrendo visibilità granulare senza dover attivare debug sui router.

Dal punto di vista D3FEND, i controlli difensivi ricadono su Network Traffic Filtering (blocco UDP/161 dal segmento utenti) e Message Authentication attraverso SNMPv3 con profilo authPriv, che rende inefficace l'intercettazione passiva delle community string.

I falsi positivi più frequenti derivano da attività legittime: sistemi di monitoraggio che effettuano discovery iniziale di un nuovo apparato producono naturalmente burst di query, così come tool di inventario come Nmap eseguiti dal team IT durante audit interni. Una whitelist accurata di NMS e scheduling degli audit riduce drasticamente il rumore, permettendo di isolare i comportamenti realmente anomali provenienti da segmenti dove SNMP non dovrebbe mai originare.

L'analisi forense di un MIB dump si sviluppa su artefatti di rete piuttosto che su endpoint, perché il traffico SNMP raramente lascia tracce sui sistemi utente. La timeline si costruisce a partire da tre fonti: i log locali dei dispositivi target, la telemetria di flusso raccolta dai sensori NSM e i pacchetti eventualmente catturati sul management network.

Sui router e switch Cisco, il buffer di log accessibile via show logging conserva eventi %SNMP-3-AUTHFAIL con timestamp, source IP e community string tentata. Se è configurato snmp-server enable traps con destinazione syslog remota, questi eventi confluiscono nel SIEM e restano disponibili anche dopo un reboot del dispositivo. Su Juniper Junos, il comando show log messages | match snmpd fornisce visibilità equivalente. Su apparati Palo Alto e Fortinet, i log di sistema categoria snmp contengono la stessa informazione.

A livello di flusso, la correlazione critica è tra source IP sospetto e volume di byte scambiati su UDP/161. Un dump completo di un MIB medio genera tra 500 KB e diversi MB di risposta, distribuiti su migliaia di pacchetti di piccole dimensioni — un profilo molto diverso dal polling regolare di un NMS. Zeek (open source) e Suricata (open source) archiviano queste sessioni con metadati completi, e il file conn.log di Zeek permette di ricostruire la durata dell'enumerazione e i byte totali.

Se è disponibile una cattura PCAP, Wireshark (open source) decodifica nativamente il protocollo SNMP e permette di estrarre l'elenco completo degli OID richiesti tramite il filtro snmp.name. Questo passaggio è fondamentale per determinare l'obiettivo dell'attaccante: enumerazione generica (sottoalbero .1.3.6.1.2.1), targeting delle configurazioni Cisco (.1.3.6.1.4.1.9) o raccolta di informazioni su software installato (hrSWInstalled).

La timeline tipica di un incidente inizia con burst di autenticazioni fallite (brute force delle community string), seguito dopo minuti o ore da una singola sessione lunga con community valida che estrae l'intera MIB. Il gap temporale suggerisce se l'attaccante disponeva già delle credenziali o le ha scoperte durante la stessa operazione.

Gli artefatti D3FEND rilevanti includono Network Session, Network Traffic e Authentication Log. Per la chain of custody, i log dei dispositivi vanno esportati preservando hash SHA-256 e i PCAP archiviati con metadati del sensore. La retention della telemetria di flusso è spesso il fattore limitante: molte organizzazioni conservano NetFlow solo 30-90 giorni, insufficienti per indagini su compromissioni scoperte tardivamente.

I dati MITRE ATT&CK forniti per T1602.001 non associano gruppi APT, software o campagne specifiche a questa sotto-tecnica. Questa assenza di attribuzione formale non riflette una scarsa rilevanza operativa, ma piuttosto la natura trasversale e opportunistica dell'enumerazione SNMP: si tratta di un'attività che numerosi attori adottano come passaggio tattico durante il reconnaissance interno, senza che ne diventi una firma distintiva.

Dal punto di vista dell'intelligence, il valore analitico si sposta quindi sul pattern d'uso e sul contesto strategico. Il MIB dump è particolarmente attrattivo per attori interessati alla mappatura di infrastrutture critiche — telco, energy, transportation — dove i dispositivi di rete espongono topologie complesse e spesso adottano configurazioni SNMP legacy per compatibilità con sistemi di gestione datati. Le campagne pubblicamente documentate contro provider di telecomunicazioni negli ultimi anni hanno frequentemente incluso enumerazione SNMP come step preliminare al pivoting verso apparati di core network.

Il trend più significativo è la persistenza di SNMPv1/v2c in ambienti operativi. Nonostante SNMPv3 sia disponibile da oltre due decenni, molti operatori mantengono le versioni legacy per ragioni di compatibilità con NMS storici o per semplicità configurativa. Questa realtà mantiene la tecnica costantemente utilizzabile con investimento tecnico minimo, un fattore che la rende attraente anche per attori con capacità limitate.

Un secondo pattern osservabile riguarda l'esposizione internet-facing di SNMP: motori di ricerca come Shodan (freemium) e Censys (freemium) censiscono costantemente centinaia di migliaia di endpoint UDP/161 raggiungibili pubblicamente, molti dei quali accettano ancora la community string public. Questo espone router edge, stampanti multifunzione e apparati IoT industriali a enumerazione remota anche da parte di attori non sofisticati, inclusi criminal group interessati a costruire liste di target per successive campagne di crypto-mining o ransomware.

Dal punto di vista dell'overlap tooling, l'enumerazione SNMP viene tipicamente eseguita con strumenti pubblici (Nmap, onesixtyone, script Python su libreria pysnmp) piuttosto che con malware custom, il che riduce le possibilità di attribuzione basata su artefatti binari. L'analisi delle sorgenti di traffico e delle tempistiche resta il vettore principale per ricondurre l'attività a un cluster di threat actor noto.

La raccomandazione strategica per i team di CTI è integrare il monitoraggio dell'esposizione SNMP nel proprio programma di attack surface management, correlando gli asset scoperti con feed di threat intelligence che tracciano scanner ricorrenti su UDP/161, così da distinguere ricognizione opportunistica da targeting mirato.

MITRE ATT&CK: tecnica T1602.001 (Data from Configuration Repository: SNMP MIB Dump), tattica TA0009, mitigazioni M1030, M1031, M1037, M1041, M1051, M1054, detection strategy DET0453 con analytic AN1249. MITRE D3FEND per mapping tecniche difensive Network Traffic Filtering e Message Authentication. Per comandi, sintassi tool e artefatti forensi è stata utilizzata conoscenza professionale di cybersecurity verificata su documentazione ufficiale Net-SNMP, Nmap NSE, Zeek e vendor di apparati di rete (Cisco IOS, Juniper Junos).