Due SOC, due esiti: il red team CISA smonta le difese di due infrastrutture critiche

Il 25 agosto 2026 la Cybersecurity and Infrastructure Security Agency (CISA) ha pubblicato un advisory che mette a confronto due valutazioni offensive condotte in parallelo. I risultati mostrano un divario profondo: una delle due organizzazioni non ha rilevato alcuna attività malevola, mentre l'altra ha identificato e isolato i tentativi iniziali, costringendo il red team a operare in modalità assume breach. In entrambi i casi, però, gli attaccanti simulati hanno ottenuto accesso completo al dominio, a sistemi aziendali sensibili e a risorse cloud. L'advisory non include CVE né indicatori di compromissione: si tratta di un report di valutazione, non di un bollettino su una singola vulnerabilità.

Due organizzazioni, settori critici, stesso obiettivo

La CISA ha condotto due red team assessment simultanei. Il primo ha riguardato un'organizzazione del Government Services and Facilities Sector (Organization A), il secondo un'organizzazione del Water and Wastewater Systems Sector (Organization B). Un red team simula il tradecraft di threat actor reali per valutare le capacità di rilevamento, investigazione e risposta di un'organizzazione. L'obiettivo è ottenere e mantenere accesso persistente alla rete aziendale e ai sistemi aziendali sensibili selezionati dall'organizzazione stessa. Questi sistemi, indicati come SBS, sono applicazioni, data store o componenti infrastrutturali la cui compromissione avrebbe un impatto materiale su operazioni, finanze o dati dei clienti.

L'assistenza della CISA è autorizzata ai sensi di 6 U.S.C. §§ 652(c)(5) e 659(c)(6). Il report utilizza il framework MITRE ATT&CK for Enterprise, versione 19, per mappare le tattiche e le tecniche osservate. Non sono state rese note le versioni esatte dei prodotti coinvolti: l'analisi si concentra su configurazioni e tecnologie diffuse come Active Directory, Active Directory Certificate Services (ADCS), System Center Configuration Manager (SCCM), AWS IAM e strumenti di endpoint detection and response (EDR).

Organization A: compromissione completa senza alcun allarme

Nel caso di Organization A, il red team ha ottenuto una compromissione completa del dominio e l'accesso a più SBS e risorse cloud senza che i difensori rilevassero o contennero l'attività. Il percorso è partito dalla ricognizione: è stata individuata un'applicazione web con credenziali predefinite per più account integrati, che consentiva di inviare email da un indirizzo email interno. Quell'indirizzo è stato usato per campagne di phishing mirate, portando all'accesso iniziale su quattro workstation.

Dalle workstation compromesse, il red team ha eseguito un collector BloodHound modificato, personalizzato per eludere le firme statiche dell'EDR. Lo strumento ha interrogato Active Directory raccogliendo informazioni su utenti, computer, gruppi, liste di controllo accessi, unità organizzative e oggetti Criteri di gruppo (GPO). Una delle workstation aveva la Machine Account Quota (MAQ) predefinita pari a 10: questo valore consente a utenti non privilegiati di aggiungere fino a 10 account computer al dominio. In combinazione con template ADCS configurati in modo errato secondo la tecnica nota come ESC1, il team ha potuto creare un account computer e richiedere certificati per qualsiasi account utente o computer. Da lì il movimento laterale è diventato sistematico.

Dopo avere ottenuto privilegi elevati sul dominio, il piano per accedere agli SBS prevedeva l'uso dei dati di Active Directory per identificare utenti e gruppi collegati ai sistemi sensibili, l'interrogazione dei server SCCM per enumerare le relazioni utente-dispositivo e l'individuazione delle workstation assegnate. Il movimento laterale dal server SCCM alle workstation degli utenti target ha permesso di cercare materiale di credenziali. Per il primo SBS, un database, sono state trovate credenziali in chiaro sulla workstation di un utente amministrativo. Per il secondo database, la ricerca si è concentrata sui file connections.json e product-preferences.xml di uno strumento SQL developer: decifrati, hanno rivelato la password in chiaro del database. Per il terzo SBS, un sistema di elaborazione automatizzato, sono state acquisite credenziali utente AWS Identity and Access Management (IAM) statiche a lunga durata, salvate in file di configurazione nelle home directory degli utenti target. L'organizzazione non aveva configurato scadenza o rotazione per quelle credenziali.

Nessun allarme è scattato. L'accesso agli SBS è stato esteso anche ai desktop virtuali, che limitano l'accesso alle sessioni attive e interattive degli utenti e aggiungono controlli come la segmentazione delle reti dei sistemi sensibili. Nemmeno questo ha fermato il red team.

Organization B: rilevamento precoce, ma l'assume breach concede comunque l'accesso

Organization B ha mostrato una postura difensiva molto diversa. Ha rapidamente identificato i tentativi di compromissione iniziale, messo in quarantena i sistemi interessati e costretto il red team a passare a un modello "assume breach". In tale modello, gli agenti fidati dell'organizzazione (trusted agents, TA) hanno fornito accesso a un host che replicava il livello di accesso che il red team avrebbe avuto se i difensori non avessero rilevato l'attività iniziale.

Da quell'host, il red team ha elevato i privilegi, si è mosso lateralmente verso gli SBS, le risorse cloud e un host bastione nella DMZ OT. Qui i difensori hanno nuovamente rilevato l'attività e isolato il sistema. L'accesso alla rete OT è stato dimostrato senza esecuzione effettiva sui sistemi OT. Nonostante il doppio rilevamento e isolamento, il modello assume breach ha comunque permesso di dimostrare l'accesso a SBS, cloud e DMZ OT. La resilienza di Organization B ha rallentato l'attaccante ma non ha eliminato il rischio.

Le tecniche dietro la compromissione: ADCS, MAQ, SCCM e credenziali statiche

Il report mappa le attività con diversi identificatori del framework MITRE ATT&CK v19, tra cui T1589.001 (identificazione della vittima), T1566 (phishing), T1087.002 (scoperta di account), T1018 (scoperta di sistemi remoti), T1069.002 (scoperta di gruppi di permessi), T1615 (scoperta di Group Policy), T1136.002 (creazione di account di dominio), T1649 (furto o forgiatura di certificati), T1033 (scoperta del proprietario del sistema), T1552 (credenziali non protette) e T1552.001 (credenziali in file).

La combinazione di Machine Account Quota predefinita e template ADCS vulnerabili a ESC1 è particolarmente pericolosa. La MAQ consente a un utente normale di creare account computer; ESC1 permette di richiedere certificati per qualsiasi account, inclusi quelli appena creati. Il risultato è un percorso di escalation dei privilegi difficile da rilevare se l'EDR non è calibrato. Il collector BloodHound modificato ha aggirato le firme statiche, dimostrando che la protezione basata solo su firme note non basta contro strumenti offensivi personalizzati.

Le credenziali statiche AWS IAM a lunga durata rappresentano un'altra falla grave. Senza scadenza o rotazione, una volta rubate restano valide indefinitamente. I file connections.json e product-preferences.xml dello strumento SQL developer contengono password cifrabili con algoritmi deboli o reversibili: chi li trova può decifrarli e ottenere accesso diretto al database.

Perché i difensori falliscono: silos, rumore e cloud sottovalutato

Il confronto tra le due organizzazioni evidenzia problemi ricorrenti. Strumenti di detection non calibrati portano a minacce non rilevate. Senza baseline definite e filtraggio degli alert, falsi positivi e notifiche di routine sovraccaricano i difensori di rete, che finiscono per ignorare segnali reali. In Organization A, questo ha permesso all'attaccante di muoversi indisturbato per ore o giorni.

I silos organizzativi e gli ostacoli burocratici impediscono una risposta efficace agli incidenti. Comunicazione frammentata, responsabilità poco chiare e autorità limitata dei difensori ostacolano l'incident response anche quando gli alert vengono generati. In Organization B, sebbene la risposta iniziale sia stata rapida, la necessità di passare al modello assume breach indica che i processi interni avrebbero potuto rallentare o complicare la reazione a un attacco reale.

Gli ambienti cloud sono spesso un rischio sottovalutato. Mancano controlli di sicurezza specifici e processi per rispondere a una compromissione cloud. Le credenziali IAM statiche e i token di accesso non ruotati rappresentano un vettore d'attacco sempre più sfruttato, ma molte organizzazioni non hanno procedure per rilevare e revocare questi elementi in caso di incidente.

Le raccomandazioni della CISA per ridurre il rischio

L'advisory elenca quattro azioni chiave. Primo, stabilire e mantenere continuamente una baseline e ridurre il rumore degli alert tramite fine-tuning. Secondo, abbattere i silos e responsabilizzare i difensori di rete, assegnando autorità e canali di comunicazione chiari. Terzo, implementare policy di Conditional Access per identità di workload e monitorare permessi eccessivi o inutilizzati. Quarto, stabilire e rivedere regolarmente procedure complete per rilevare, rimediare e revocare token di accesso e refresh in caso di compromissione cloud.

I destinatari includono agenzie del Federal Civilian Executive Branch, governi statali, locali, tribali e territoriali, e infrastrutture critiche. I ruoli interessati vanno dagli amministratori di sistema agli incident responder, dagli analisti difensivi di cybersecurity agli analisti di vulnerabilità, dagli operatori di rete ai responsabili di sistemi di sicurezza. Il messaggio è chiaro: le configurazioni errate e le credenziali statiche sono la porta d'ingresso preferita dagli attaccanti, e un SOC che non riesce a filtrare il rumore non vede nemmeno gli attacchi riusciti.