Il fenomeno di cui nessuno vuole parlare
L’edizione 20 24 aprilea di “Locked Shields 2026 ” si è conclusa a Tallinn il , con oltre 4.000 partecipanti provenienti da 41 nazioni, che hanno formato 16 squadre multinazionali per contrastare circa 8.000 attacchi informatici in tempo reale rivolti a infrastrutture critiche: difesa aerea, voto elettronico, 5G, gestione satellitare e un sistema di generazione di energia elettrica completamente funzionante. I comunicati ufficiali, come sempre, hanno elogiato la capacità dei partecipanti di «Detect are e reagire alle attività informatiche dolose».
Tale interpretazione è corretta. Inoltre, anno dopo anno, è proprio questo l’aspetto di cui tutti vogliono parlare, e ciò finisce per mettere silenziosamente in secondo piano una tendenza meno lusinghiera: le squadre blu che faticano non lo fanno perché i loro piani operativi SOC fossero carenti. Fanno fatica perché qualcosa si è spezzato sotto di loro e non se ne sono minimamente accorti. Stavano guardando verso il Livello 7 , mentre la squadra rossa si trovava già al Livello 2.
Se ha fatto parte di un “blue team”, sa bene di cosa si tratta. Un servizio cessa di funzionare. I primi dieci minuti li si trascorre a inveire contro il firewall. I dieci minuti successivi vengono trascorsi sulla console “ EDR ”. Quando qualcuno esegue il comando ` ` o `arp -a ` oppure consulta una tabella BGP, il ciclo è già a metà.
Questo articolo offre una panoramica del modello OSI, non perché il modello a sette livelli sia sacrosanto, ma perché rappresenta la lista di controllo più chiara per gli ingegneri che sono caduti nella trappola del pensiero " IR " (dai, proviamo a vedere cosa succede). Se la Sua prima reazione alla notizia che “il servizio non è disponibile” è “controllare il WAF”, sta trascurando cinque livelli di superficie di attacco in cui il red team si è già insediato.
Indice
Perché il modello OSI continua a meritare il proprio posto
Ogni pochi anni qualcuno pubblica un articolo del tipo “Il modello OSI è superato, utilizzate il TCP/IP”. Hanno ragione nel dire che il modello è un’astrazione: i livelli 5 e 6 , in particolare, svolgono principalmente funzioni di gestione interna negli stack moderni. Si sbagliano nel ritenere che ciò lo renda inutile. OSI è un modello di triage. Quando qualcosa non funziona o è sotto attacco, esaminare i livelli dal basso verso l’alto è il modo più rapido per individuare l’origine del problema, anziché limitarsi a ciò che i vostri strumenti sono in grado di rilevare.
I team rossi ne sono consapevoli. Scelgono lo strato in cui il rilevamento risulta più debole. In un ambiente Locked Shields, ciò non corrisponde quasi mai al Livello 7.
Livello 1: Fisico
Nell’esercizio il livello fisico viene astratto, ma il concetto rimane valido: gestione fuori banda, server di console, KVM, interfacce di gestione “lights-out” (iDRAC, iLO, IPMI). Questi dispositivi vengono solitamente lasciati con le credenziali predefinite o su VLAN di gestione condivise e offrono un percorso che aggira tutti i controlli di rilevamento a loro superiori.
L’onesto fallimento del team blu: , che considera la rete OOB come «infrastruttura, non rientrante nell’ambito di applicazione». Rientra nell'ambito di applicazione. Se il traffico "red" riesce a raggiungere il vostro iDRAC, il firewall a monte di esso è puramente decorativo.
Livello 2: Collegamento dati
È proprio qui che si verifica la maggior parte dei danni, ed è lo strato a cui la maggior parte dei difensori senior ha smesso di prestare attenzione perché “se ne occupa lo switch”. Lo switch non è in grado di gestirlo. L'opzione applica le impostazioni da Lei configurate, che spesso non sono alcuna.
Il catalogo degli attacchi Layer 2 non è una novità. È proprio questo il punto. Non si tratta affatto di una ricerca innovativa:
- Lo spoofing ARP/cache poisoning continua a funzionare su qualsiasi segmento privo di Dynamic ARP Inspection. Consente all’autore dell’attacco di assumere una posizione di tipo “man-in-the-middle” invisibile ai vostri strumenti L3+
- L'attacco di tipo "CAM table flooding" trasforma uno switch in un hub, trasmettendo frame che l'autore dell'attacco può intercettare
- VLAN hopping tramite doppio tagging o abuso del protocollo DTP: alla Sua rete “segmentata” basta una porta trunk configurata in modo errato per diventare una rete piatta
- Carenza di DHCP e DHCP non autorizzato : assegnate il proprio gateway e indirizzate tutti attraverso di esso
- Gli attacchi STP all’ : si presentano come bridge principale, modificano la topologia L2 e deviano il traffico attraverso il vostro tap
- L'iniezione di LLDP/CDP è utile per la ricognizione e, su alcune piattaforme, per ingannare i dispositivi vicini
Le misure di sicurezza sono obsolete, ben documentate e sistematicamente applicate solo in parte: sicurezza dei porti, DHCP snooping, Dynamic ARP Inspection, BPDU Guard, Root Guard, disabilitazione del DTP, separazione delle VLAN di gestione. Nessuno di essi compare sulla copertina di un white paper di un fornitore. Sono tutti determinanti per l’esito dei round.
L’errore in buona fede del team blu: , ovvero aver dato per scontato che il team di rete avesse risolto il problema nel corso 2019 senza mai verificarlo nuovamente. Eseguite i controlli. Ci vuole un’ora.
Livello 3: Rete (e sì, BGP)
Il livello IP è l’ambito in cui gli esperti di sicurezza si sentono a proprio agio, ma tale sicurezza viene meno non appena si entra nel campo dei protocolli di instradamento.
Per il routing interno (OSPF, EIGRP, IS-IS), si ripete lo stesso schema descritto al punto L2 . L'autenticazione è facoltativa nel protocollo, obbligatoria nella pratica, e viene sistematicamente disabilitata «per il momento» in contesti di laboratorio e di esercitazione, che poi finiscono per diventare parte integrante delle prassi operative. Un malintenzionato presente su un segmento di peering privo di autenticazione OSPF MD5/SHA può iniettare percorsi, deviare il traffico verso un "blackhole" o reindirizzarlo in modo invisibile.
E poi c'è il BGP. Il BGP gestisce Internet sulla base di un modello di fiducia le cui origini risalgono alle RFC 1105 e 1989, e gli scenari di “Locked Shields” lo includono sempre più spesso poiché anche gli avversari reali lo fanno. La superficie di attacco in questione:
- Dirottamenti di route: , ovvero l’annuncio di un prefisso più specifico di cui non si è titolari per convogliare il traffico verso di sé
- Fughe di route: in cui le route apprese da un peer vengono comunicate a un altro peer in violazione delle linee guida, spesso in modo accidentale, con lo stesso impatto operativo di un dirottamento
- Reimpostazione delle sessioni: , che utilizza traffico TCP appositamente modificato per interrompere le sessioni BGP. Ecco perché esiste il TCP-AO (RFC 5925), o, storicamente, il TCP MD5
- Manipolazione dei percorsi: inserimento di AS-path all’inizio ( ) e abuso del “ Community ” per deviare il traffico in modi che il vostro sistema di monitoraggio non rileva, poiché le rotte risultano comunque “valide”
Le misure di mitigazione sono di natura operativa, non legate al prodotto: convalida dell’origine tramite RPKI, limiti al numero massimo di prefissi, filtri sui prefissi in ogni sessione eBGP, autenticazione dei peer e BGPsec, ove disponibile. Se la Sua risposta alla domanda «Siamo esposti al rischio di una fuga di route dal nostro provider a monte?» è «Il firewall la intercetterà», non sarà così. Il firewall rileva i pacchetti in arrivo. Non riesce a rendersi conto che sono arrivati seguendo un sentiero che non dovrebbe esistere.
Il sincero fallimento del team blu: , che considera il routing un “problema del team di rete”, isolato dal settore della sicurezza. Sia in un esercizio che nella realtà, il routing è sinonimo di sicurezza.
Livello 4: Trasporto
In questo caso vi sono meno complicazioni, ma gli aspetti fondamentali rimangono comunque importanti: protezione contro gli attacchi SYN flood, timeout TCP ragionevoli, consapevolezza del fatto che una sessione TCP inattiva possa essere dirottata in caso di fuga dei numeri di sequenza, nonché vettori di amplificazione UDP su qualsiasi servizio esposto (DNS, NTP, memcached, CLDAP). La maggior parte dei difensori gestisce questa situazione con competenza. L'errore al punto L4 non consiste solitamente nella mancata individuazione. Si tratta di un articolo pubblicato su * *. Servizi accessibili da segmenti dai quali non dovrebbero essere accessibili.
Livelli 5 e 6: Sessione e presentazione
In pratica, si tratta di “TLS e tutto ciò che lo circonda”. Algoritmi di crittografia deboli, certificati scaduti o convalidati in modo errato, configurazioni errate della ripresa della sessione, “ TLS ” reciproco che in realtà non è tale poiché il server non verifica la catena di certificati del client. Gli scenari di Locked Shields includono regolarmente un file ` TLS ` configurato in modo errato come trappola deliberata. I responsabili della sicurezza che si limitano a verificare che "HTTPS sia attivo" non se ne rendono conto.
L’altro aspetto sottovalutato del L5/6 riguarda la gestione delle sessioni nelle applicazioni: ID di sessione prevedibili, token che non vengono aggiornati e JWT non firmati. Si tratta di L7 vulnerabilità secondo la definizione dell’OWASP, ma si collocano al confine tra sessione e presentazione e rappresentano il modo in cui un aggressore, una volta ottenuto un punto d’appoggio, riesce a conquistare un’identità di lunga durata.
Livello 7: Applicazione
È proprio qui che si concentra la maggior parte degli strumenti difensivi, motivo per cui la maggior parte dei difensori tende automaticamente a concentrarsi su questo aspetto. Vulnerabilità web, comportamento del malware, abuso delle procedure di autenticazione, difetti nella logica delle API. Nulla di tutto ciò è irrilevante, è semplicemente un argomento ormai ben consolidato, e il vostro stack ne tiene già conto. The bias to correct is the reverse one: if you find yourself thirty minutes into an incident still chasing an L7 explanation when the symptoms don't fit, walk back down the stack.
Il firewall non è il punto centrale della questione
Un’ipotesi di lavoro che emerge da anni di rapporti post-esercitazione relativi alle simulazioni “Locked Shields” e dalle attività lavorative quotidiane che ne costituiscono la base: l’ingegnere medio del “blue team” con esperienza attribuisce un’importanza eccessiva al rilevamento e una insufficiente alla configurazione. Il punto di forza dei loro strumenti è proprio la capacità di rilevamento. È proprio la configurazione a determinare l’esito della partita.
A useful pre-engagement 5 step checklist for an experienced defender, in the order an attacker thinks about them:
- Il livello 2 è stato configurato in modo sicuro su ogni switch di accesso: sicurezza delle porte, DHCP snooping, DAI, BPDU Guard, disattivazione del DTP, VLAN di gestione separata?
- Le sessioni dei protocolli di routing sono autenticate, con filtri “max-prefix” e “prefix” su ogni peer eBGP? La convalida RPKI viene effettivamente applicata, e non è solo abilitata?
- I livelli di gestione (OOB, iDRAC/iLO/IPMI, gestione degli switch, console dell’hypervisor) si trovano su un segmento che l’autore dell’attacco non può raggiungere da un’ endpoint utente compromessa?
- La configurazione di TLS è stata verificata, anziché data per scontata: compresa la convalida del certificato client nei casi in cui viene richiesto l'mTLS?
- A seguire, la raccolta “ L7 ”: regole WAF, copertura EDR , rilevamenti SIEM , playbook IR .
L'ordine è importante. È proprio nei primi quattro punti che si perdono silenziosamente le battaglie prima ancora che abbia inizio la fase “ ” IR . Sono inoltre gli elementi che con minore probabilità compaiono nelle diapositive delle revisioni trimestrali, poiché non generano avvisi quando funzionano correttamente.
Il ruolo dell’ Tanium e (una volta che le basi sono solide)
Vorrei essere sincero riguardo alla portata del progetto. Tanium non autentica i Suoi peer BGP. Non configura l'ispezione ARP dinamica sugli switch di accesso. I primi quattro punti dell’elenco di controllo riportato sopra riguardano l’ingegneria di rete, e nessuna piattaforma di “ endpoint ” può sostituire tale attività.
Ma non appena si risale la pila, il quadro cambia. Infatti, una volta configurato correttamente il piano di rete, la domanda successiva è: sapete effettivamente cosa è in esecuzione su ogni endpoint? È stato aggiornato, protetto e configurato proprio come ritiene che sia? Eseguire i servizi necessari e nient’altro?
È proprio in quel livello che abbiamo implementato “ Tanium” durante l’evento Locked Shields 2026. Durante il periodo di trasmissione in diretta, la piattaforma ha fornito:
- Inventario in tempo reale di ogni host della rete per Windows e Linux, compresi i segmenti che abbiamo integrato nel corso dell’esercizio
- La distinta dei materiali software e la visibilità a livello di libreria coprono ogni endpoint, fino al singolo componente e alla versione
- Dati relativi alle vulnerabilità collegati direttamente alla correzione: individuare la libreria vulnerabile e applicare la correzione dalla stessa console
- Distribuzione automatica dell’agente Tanium agli host appena rilevati, senza alcuna coda di integrazione manuale
- La distribuzione e l’aggiornamento degli agenti antivirus e di EDR dei partner vengono effettuati contemporaneamente a quelli di Tanium su l’intera flotta da un’unica console
- Applicazione di patch di terze parti per sistemi operativi e su larga scala come Windows aggiornamenti cumulativi, .NET, SharePoint, Linux patch per il kernel e le librerie
- Gli script di hardening sono stati distribuiti e riapplicati in tutto l’ambiente, in modo che nessun host rimanesse non configurato
- La rotazione delle credenziali locali è stata implementata con cadenza ravvicinata, al fine di limitare la durata di validità di qualsiasi password rubata
- Pacchetti personalizzati di risposta agli incidenti , elaborati in tempi ristretti e distribuiti alla flotta, che comprendono l’implementazione delle regole del firewall, la rimozione delle tracce di persistenza e l’eliminazione degli implant
- e per l’individuazione delle minacce nell’intero ambiente endpoint da un’unica console
- Distribuzione dei comandi basata su agenti come soluzione alternativa in caso di degrado dei percorsi di rete standard
Nulla di tutto ciò può sostituire una corretta comprensione del Livello 2 . Se non sapete di quali endpoint disponete, il sistema smette di funzionare. Le due discipline sono complementari. Le squadre che ottengono buoni risultati al Locked Shields gestiscono entrambe le componenti in parallelo: un piano di rete protetto a livello di base e un ambiente endpoint completamente gestito e pienamente visibile a livello superiore.
Il punto fondamentale
"Locked Shields" è un'opera impressionante e il lavoro dell’ IR , che essa mette in luce, è autentico. Tuttavia, l’analisi continua a dimostrare, anno dopo anno, che i difensori esperti hanno la meglio nei livelli fondamentali. Il team che ha messo in sicurezza i protocolli ARP e DHCP sul segmento di accesso, ha autenticato le proprie sessioni di routing e ha segmentato il proprio piano di gestione riuscirà, in media, a superare il team che dispone di un playbook SOAR più sofisticato.
Se c’è una cosa che dovete ricordare di questo post: , la prossima volta che si verifica un malfunzionamento e il vostro primo istinto è quello di aprire la console del firewall, aprite prima show mac address-table oppure show ip bgp summary . La risposta si trova più spesso di quanto vorreste ammettere. Quindi, una volta che il piano di rete è ben funzionante, si assicuri di disporre di una vera piattaforma endpoint che vi si sovrapponga. Cominciamo dalle nozioni di base. La piattaforma, in secondo luogo. In quest'ordine.
Dati e citazioni relativi a Locked Shields 2026 tratti da , CCDCOE, , SHAPE NATO, nonché i dettagli dello scenario dell’esercitazione confermati tramite , SANS Institute,e
. Immagine in evidenza a cura di: Blue Team 10 @ Locked Shields
