Il rasoio di Occam non serve a farsi la barba

«Nell’ambito delle attività di monitoraggio è stata rilevata una connessione di rete originata dall’host interno verso un indirizzo IP pubblico sulle porte 445 e 139.» L’incipit è quello di sempre, e ciò che segue è un’analisi ordinata, a suo modo esemplare. Molteplici connessioni su una finestra di trenta giorni. Altri due host interni coinvolti. Sessioni tentate e mai completate, sistematicamente in timeout. L’indirizzo di destinazione attribuito a un’organizzazione estera, con tanto di settore merceologico e hostname. Due utenze associate al traffico. E la conclusione: pattern di beaconing, con la raccomandazione di identificare il processo responsabile e di verificare i sistemi per escludere la presenza di una minaccia ancora attiva.

L’ente blocca l’indirizzo e risponde. Arriva un sollecito, poi una richiesta di approfondimento, poi un altro sollecito. Quando finalmente l’analisi viene fatta, sta in una riga: l’indirizzo di destinazione differiva di una cifra da quello del gateway della rete locale. Qualcuno, in configurazione, aveva digitato 192.169.2.1 al posto di 192.168.2.1.

Non è una storia di incompetenza. Il refuso è banale e capita a chiunque; l’analisi che ne è seguita era metodologicamente corretta in ogni suo passaggio. È una storia su quando si usa il rasoio.

Il rasoio non dice quello che pensiamo dica

Nella vulgata, il principio attribuito a Guglielmo di Occam suona così: «la spiegazione più semplice è quella giusta». Detta in questi termini è falsa, e giustamente irrita chiunque faccia un mestiere in cui le cose semplici quasi mai lo sono. La formulazione originale è un’altra e molto più utile: non moltiplicare gli enti oltre il necessario. A parità di evidenze spiegate, si preferisce l’ipotesi che introduce meno entità nuove. Non è un criterio di verità: è un criterio di ordine. Non dice dove arrivare, dice da dove cominciare.

Applicato a questo caso, il conteggio è impietoso. L’ipotesi della compromissione richiede: un impianto malevolo installato su tre macchine distinte; un canale di comando e controllo che sceglie SMB, protocollo bloccato in uscita praticamente ovunque e da vent’anni; un operatore remoto che per trenta giorni non completa mai una sessione e non cambia mai strategia; un malware che in tutto quel tempo non produce nessun altro segnale rilevabile. Quattro entità nuove, nessuna delle quali osservata. L’ipotesi del refuso richiede un dito su un tasto sbagliato: il gateway esisteva già, gli host già lo cercavano, il traffico SMB verso quell’indirizzo era già la normalità quotidiana. Zero entità nuove.

Le stesse evidenze, due storie

Il punto delicato è che ogni singolo elemento della segnalazione era compatibile con entrambe le ipotesi. Nessuno di essi era sbagliato. Ma sotto l’ipotesi banale ognuno smetteva di essere un indizio e diventava una conseguenza attesa.

La periodicità dei tentativi non era il battito regolare di un canale di comando e controllo: era un client Windows che riprova, perché è esattamente ciò che fa un client Windows davanti a una risorsa di rete che non risponde. Le porte 445 e 139 non erano una scelta esotica dell’attaccante: erano l’uso ordinario di quegli host, semplicemente puntato nella direzione sbagliata — la stessa segnalazione lo notava, osservando che quelle macchine usavano SMB abitualmente verso l’interno. La presenza di più sorgenti non era movimento laterale: era la medesima configurazione errata replicata.

Le due utenze associate meritano un discorso a parte, perché sono l’elemento che più facilmente viene scambiato per una prova. Nel log di un apparato perimetrale il nome utente non è un attributo del pacchetto: è il prodotto di una correlazione, quella fra l’indirizzo sorgente e la sessione autenticata attiva su quella macchina nello stesso momento. Dice chi era collegato, non chi ha generato il traffico. E il tentativo di raggiungere una risorsa di rete non lo decide l’utente: lo decide il sistema operativo, spesso mentre nessuno sta toccando la tastiera. Due nomi distribuiti su tre host, per giunta, non raccontano la propagazione di un attacco: raccontano due persone che quel giorno stavano lavorando.

E poi c’è l’elemento più eloquente di tutti, quello che nel report compare come dettaglio tecnico e che invece era la risposta: il timeout sistematico. Non «un attacco che non è riuscito», ma la prova che dall’altra parte non c’era nessuno. Un canale di comando e controllo che per trenta giorni non risponde mai non è un canale di comando e controllo compromesso o inefficace: non è un canale. È un indirizzo che, per chi lo chiama, non esiste.

La geografia dei quasi-privati

Il vicinato degli spazi riservati è affollato, e ogni confine è a un tasto di distanza. Sopra 192.168.0.0/16 comincia 192.169.0.0/16, che è spazio pubblico regolarmente assegnato. Il blocco 172.16.0.0/12 è delimitato da 172.15.x e 172.32.x, entrambi pubblici e entrambi a portata di errore per chi ricorda «172 punto qualcosa». Una trasposizione di due tasti trasforma 192.168.x in 192.186.x. E 100.64.0.0/10, lo spazio del CGNAT, genera a valle una confusione della stessa famiglia: sembra privato, si comporta quasi come tale, ma non lo è.

Per questo la prossimità a uno spazio riservato non è una curiosità aneddotica: è una classe di errore ricorrente, con una firma riconoscibile. Ultimo ottetto .1 o .254, cioè il posto dove vivono i gateway. Porte di servizi rigorosamente interni: 445, 139, 389, 3268, 631, 3389. Esito costantemente negativo. Sorgenti che condividono la stessa subnet e lo stesso profilo. Reputazione nulla, perché l’indirizzo non compare in nessun feed per la ragione che nessuno lo sta usando per fare del male. Quando quattro di questi cinque elementi compaiono insieme, l’ipotesi da testare per prima non è l’esfiltrazione.

Perché il triage la salta

Il primo motivo è che l’arricchimento produce una narrazione. Uno strumento di enrichment risponde sempre: interrogato su un indirizzo qualunque restituisce numero di sistema autonomo, proprietario, hostname, geolocalizzazione, categoria merceologica. Da un dato privo di significato — un indirizzo che nessuno ha mai voluto contattare davvero — tira fuori un’organizzazione con un nome, un settore e un paese. Quel nome non è un’evidenza: è la risposta a una domanda che non andava posta. Ma una volta scritto in un report diventa il perno della storia, e la storia, da lì in poi, si racconta da sola.

Il secondo è che le etichette arrivano prima del senso. «Beaconing» descrive una periodicità, e qualunque retry automatico è periodico: un orologio rotto e un impianto disciplinato producono la stessa serie temporale. L’etichetta è formalmente corretta e la conclusione che se ne trae è sbagliata, il che è la condizione più insidiosa in cui un’analisi possa trovarsi, perché ogni passaggio successivo risulta rigoroso.

Il terzo è l’asimmetria degli incentivi. Nessun analista è mai stato ripreso per aver segnalato troppo. Il costo di un’ipotesi sovradimensionata non ricade su chi la formula, ma su chi la riceve — moltiplicato per ogni destinatario, e sommato ai solleciti. È lo stesso meccanismo di cui ho già scritto a proposito degli allarmi diffusi senza verifica: un piccolo risparmio a monte che diventa un grande spreco a valle.

Trenta secondi prima di trenta giorni

Non serve un processo nuovo. Serve una manciata di domande poste prima dell’attribuzione, non dopo. La destinazione è a una cifra da uno spazio riservato? Un confronto meccanico, automatizzabile in una riga di codice, che nessun feed commerciale farà mai al posto nostro. Qual è l’esito, non il volume? Trenta giorni di tentativi e zero sessioni stabilite non descrivono un avversario tenace, descrivono un interlocutore assente. Il protocollo ha senso verso Internet? SMB in uscita non è quasi mai un canale: è quasi sempre una LAN indirizzata male. L’ultimo ottetto dice qualcosa? Un .1 o un .254 raccontano un gateway, non un server di comando e controllo. L’indirizzo esiste per qualcun altro? Se non compare in alcun feed di reputazione, l’attribuzione al legittimo proprietario non è un indicatore di compromissione: è un dato di registro.

E infine la domanda che vale tutte le altre: si è chiesta la cosa banale prima di chiedere quella complessa? Una riga — «verificate se in configurazione esiste un indirizzo simile a quello del vostro gateway» — costa meno di un sollecito, e molto meno di una richiesta di analisi forense rivolta a un ente che, quasi sempre, ha due persone per tutto.

Perché capirlo fa la differenza

Chi opera fa errori di battitura; chi analizza fa narrazioni. Sono entrambi errori umani, ma non hanno lo stesso raggio d’azione. Il primo genera traffico che non arriva da nessuna parte. Il secondo mobilita persone, apre ticket, chiede analisi forensi e consuma la risorsa più scarsa che un’organizzazione abbia: l’attenzione dei suoi tecnici. E ogni volta che una segnalazione elaborata si sgonfia in una riga, chi la riceve impara qualcosa che sarebbe meglio non imparasse — che la prossima si può leggere con un po’ meno attenzione.

Vale anche qui la regola che percorre tutto il lavoro sull’infrastruttura, dal DNS alle blocklist: un controllo — come un’analisi — va reso difendibile e verificabile. E difendibile significa, prima di ogni altra cosa, aver escluso ciò che era banale da escludere. Il rasoio di Occam non serve a farsi la barba: serve a tagliare le ipotesi di troppo. Va usato all’inizio dell’analisi, non alla fine, quando le ipotesi di troppo sono già finite in un report.

Fa parte della serie sulle fondamenta invisibili dell’infrastruttura. Leggi anche Il deserto dei falsi positivi e Vieni al lato oscuro.