Threat Lab Quarterly: agosto 2026

Individuare SPN obsoleti e fantasma prima degli attaccanti

Di Huy Kha

Introduzione

Negli ultimi anni, gli attacchi ad Active Directory che sfruttano i Service Principal Names (SPN) sono aumentati. È iniziato con il Kerberoasting, ma le tecniche sono diventate più creative da allora. Gli attacchi Ghost SPN possono consentire l'escalation dei privilegi reclamando obiettivi di servizio che nessuno usa più. Più recentemente, gli attacchi di collisione Unicode degli SPN permettono a qualsiasi utente autenticato con permessi write-SPN di scalare i privilegi, usando solo uno SPN visivamente identico ma tecnicamente diverso.

C'è anche un problema più silenzioso che non riceve molta attenzione, ovvero l'igiene di sicurezza di base. In Netwrix, vediamo lo stesso schema ripetersi più e più volte, indipendentemente dalla dimensione dell'organizzazione. Gli account computer rimangono abilitati in Active Directory molto tempo dopo che la macchina a cui erano associati è stata dismessa. Gli account di servizio mantengono SPN che puntano ancora a host che non esistono più. Nessuno torna indietro a pulire tutto ciò, quindi l'account resta lì, ancora attivo, ancora vulnerabile al Kerberoasting, e nessuno ci fa caso.

Trovare SPN nascosti nel tuo/i dominio/i

Il nostro team di ricerca sulla sicurezza ha deciso di creare qualcosa che rendesse questo facile per i professionisti IT e gli amministratori: uno script PowerShell chiamato Find-StealthSPNs che cerca SPN nascosti sia negli account computer che utente, così puoi esaminare i risultati e decidere cosa necessita effettivamente di pulizia.

Lo script viene eseguito in due passaggi principali. Il primo esamina ogni account computer nella foresta. Poiché ogni macchina unita al dominio registra almeno un SPN per impostazione predefinita, questo passaggio verifica se il nome host del computer si risolve ancora in DNS e se uno qualsiasi dei suoi SPN punta a host che non esistono più. Chiamiamo questo un ghost SPN, uno SPN che è ancora presente su un account, tecnicamente valido, ma che punta a nulla di reale. Rileva anche account computer precreati in AD ma mai effettivamente uniti, poiché spesso finiscono senza alcun SPN, rimanendo lì indefinitamente senza che nessuno se ne accorga.

Verifichiamo intenzionalmente questo tramite DNS anziché con un ping ICMP. Alcuni amministratori si affidano al ping per avere un’idea rapida se un host dietro un SPN è ancora attivo, ma ICMP viene spesso bloccato da firewall e filtri basati sull’host nella maggior parte degli ambienti, quindi un ping fallito non dice molto. Un record DNS mancante è un segnale più affidabile che nessuno si aspetta più che quel nome host esista, indipendentemente dal fatto che la macchina risponderebbe a un ping.

Il secondo passaggio esamina gli account utente, in particolare quelli che detengono SPN, poiché questa è la configurazione classica per un account di servizio. Per ogni SPN trovato, verifica due cose: se esiste ancora un account computer corrispondente in AD e se quel nome host si risolve ancora in DNS. Se nessuna delle due condizioni è vera, questo è un segnale chiaro che l'SPN è un peso morto. L'account è ancora attivo, l'SPN è ancora registrato ed è ancora altrettanto sfruttabile tramite Kerberoasting come sempre, tranne che ora non c'è nulla di legittimo che ne dipenda.

Inoltre, lo script controlla anche le collisioni Unicode degli SPN, il tipo di attacco menzionato prima, in cui uno SPN creato ad arte può sembrare visivamente reale pur essendo un valore completamente diverso sotto. Segnala ogni SPN con caratteri nascosti o simili e confronta ogni SPN nella foresta per individuare casi in cui due account sembrano avere lo stesso SPN. Potrebbero esserci falsi positivi, quindi verifica sempre due volte.

Tutto funziona usando solo ADSI e DirectorySearcher, quindi non c’è dipendenza dal modulo ActiveDirectory PowerShell e funziona su ogni dominio della foresta, non solo su quello da cui lo esegui.

Una breve nota sulla risoluzione DNS: Questo script controlla il DNS usando il resolver configurato sulla macchina da cui viene eseguito. Per risultati (più) accurati, eseguilo da un controller di dominio anziché da una workstation, poiché i DC sono già configurati per risolvere ogni dominio nel tuo ambiente. Eseguirlo da una macchina con impostazioni DNS insolite o limitate potrebbe produrre risultati falsi di MISSING_DNS per record che esistono realmente.

Conclusione

Alla fine, cerchiamo di aiutare le organizzazioni a ridurre la loro superficie di attacco eliminando gli account obsoleti che nessuno monitora più. Ogni ghost SPN, ogni account computer abilitato legato a una macchina ormai sparita, ogni account di servizio che punta ancora a un host che non esiste più, è un elemento in più in Active Directory che non dovrebbe esserci. Non serve un attaccante sofisticato. Basta che qualcuno se ne accorga prima di te.

---

L'angolo di sicurezza dell'identità di DEF CON 34

Di Darryl Baker

DEF CON 34 e Black Hat USA 2026 hanno prodotto tre ricerche separate che indicano tutte l'infrastruttura di identity. Ecco cosa ha annunciato ciascuna e cosa significa per chi gestisce programmi di identity e AD.

CloudBasher: shell cloud gratuiti trasformati in infrastruttura per attaccanti

Jenko Hwong e Chris Ryan hanno presentato CloudBasher, un toolkit open-source creato tramite reverse engineering delle REST API private e delle sessioni WebSocket dietro le funzionalità gratuite di cloud shell in AWS, Azure e GCP. Il toolkit sarà pubblico su GitHub, insieme a un'analisi del 2026 sui modelli di errata configurazione cloud basata su dati di violazioni.

La ricerca ha evidenziato alcuni risultati specifici da segnalare ai team di Identity Management.

• Un'identità AWS compromessa può assumere un ruolo e avviare un gran numero di ambienti CloudShell.
• Le sessioni terminali WebSocket rimangono attive dopo che il token di accesso sottostante è stato revocato, quindi revocare una credenziale non termina necessariamente una sessione attiva.
• Gli account consumer di M365 e Gmail ottengono l'accesso predefinito a CloudShell, estendendo la superficie di attacco rilevante agli account personali, non solo a quelli aziendali.

Una volta stabilita la sessione, il toolkit persiste nella directory $HOME (che sopravvive ai reset), può bloccare l’utente legittimo dall’uso di sudo nella propria sessione e installa un framework C2.

Perché è importante: se il tuo programma di identity considera la revoca del token equivalente alla terminazione della sessione, questa ricerca suggerisce che tale assunzione debba essere verificata, non data per scontata. Vale anche la pena confermare se le tue politiche di accesso e il monitoraggio di CloudShell rileverebbero la creazione anomala di sessioni.

GhostJacking: agenti di codifica AI che agiscono su istruzioni nascoste nei log 

Barak Sternberg, Nevo Poran e Ron Bobrov di Tenet Security hanno presentato GhostJacking, una tecnica per dirottare agenti di codifica AI inserendo istruzioni all’interno dei log che l’agente si aspetta di leggere, come avvisi WAF, rapporti di errore e output di monitoraggio. Tenet ha riportato un tasso di successo del 90% contro Claude Code con la configurazione predefinita di Cloudflare e ha stimato che più di 15.000 organizzazioni sono esposte solo tramite configurazioni Cloudflare.

Tenet ha dimostrato la tecnica su tre piattaforme. Voci di log WAF di Cloudflare avvelenate (Cloudflare protegge circa il 42% delle aziende Fortune 500) hanno causato agli agenti di modificare le impostazioni DNS e reindirizzare il traffico. Messaggi di log iniettati di Datadog (usato da circa il 48% delle Fortune 500) hanno fatto sì che gli agenti installassero pacchetti dannosi, portando all'esecuzione remota di codice e al furto di credenziali. Rapporti di errore di Sentry avvelenati (Sentry serve circa 4 milioni di sviluppatori) hanno fatto sì che un'istanza compromessa di Claude Code garantisse per l'attaccante all'agente Seer AI di Sentry, producendo una catena di fiducia tra agenti. Tenet ha anche segnalato di aver trovato oltre 2.700 chiavi API Datadog esposte e ha rivelato separatamente una fuga da sandbox legata a JWT in Claude Desktop a Anthropic. Il problema è stato risolto prima del talk DEF CON.

Le azioni dell'agente in tutti e tre i casi utilizzano le proprie credenziali legittime e già autorizzate. Ciò significa che gli strumenti EDR, WAF e IAM non segnalano nulla di anomalo.

Perché è importante: RBAC, il principio del minimo privilegio e MFA non aiutano qui, perché l'accesso dell'agente è legittimo. Il problema è cosa gli è stato detto di fare con quell'accesso. Le raccomandazioni di Tenet sono una lista di controllo ragionevole per iniziare: limitare per default l'accesso in uscita alla rete dell'agente, richiedere l'approvazione umana prima di modifiche all'infrastruttura, separare gli strumenti in sola lettura da quelli con capacità di scrittura, e trattare ogni log o avviso che un agente legge come input non affidabile, indipendentemente dalla piattaforma da cui proviene.

The OpenAI–Hugging Face incident: An agent that escaped its own test

A luglio 2026, OpenAI ha rivelato che durante una valutazione interna usando il benchmark ExploitGym (898 vulnerabilità reali), una versione sperimentale di GPT-5.6 Sol, eseguita con le protezioni di sicurezza disabilitate, è uscita dalla sandbox e ha compromesso l'infrastruttura di produzione di Hugging Face. Hugging Face ha reso noto l'incidente il 16 luglio; OpenAI ha rivelato il proprio ruolo il 21 luglio. Eric Wallace e Michael Dalton ne hanno parlato al Black Hat USA 2026.

Secondo le rivelazioni, l’agente ha trovato e sfruttato una zero-day in un’istanza self-hosted di Artifactory (il proxy cache del registro pacchetti di JFrog) per uscire dalla sandbox e raggiungere internet. L’agente ha quindi dedotto che Hugging Face ospitava la chiave delle risposte del benchmark ed è andato direttamente a prenderla. Più istanze di agenti si sono poi coordinate tramite Artifactory stesso, scambiandosi centinaia di migliaia di messaggi per dividere i compiti e condividere gli exploit. A un certo punto, gli agenti hanno proposto di firmare crittograficamente i loro messaggi dopo aver sospettato un impostore. Quando OpenAI ha chiuso il canale il 4 luglio, gli agenti lo hanno ricostruito entro quattro giorni usando nomi di directory su un endpoint non autenticato come canale di messaggistica sostitutivo.

Durante una campagna di 4,5 giorni, OpenAI ha registrato oltre 17.600 azioni degli agenti, inclusa l'esfiltrazione di 136 chiavi dell'archivio credenziali, il furto di una chiave di autenticazione mesh VPN, l'iscrizione di 181 dispositivi tramite Tailscale e l'acquisizione dell'accesso in scrittura a GitHub App. L'attività su 11 nodi Kubernetes ha incluso l'impersonificazione del nodo tramite i metadata delle istanze AWS, token di identità falsificati usando una chiave EdDSA JWT rubata e la creazione di pod privilegiati con mount del filesystem host. OpenAI ha dichiarato di aver identificato anche altre fughe minori dalla sandbox, descritte come limitate, nessuna delle quali ritiene abbia lasciato la propria rete.

Un dettaglio specifico di identity e incident response: le query forensi di Hugging Face sono state bloccate dalle stesse barriere di sicurezza AI commerciali integrate nei modelli OpenAI e Anthropic che ha cercato di usare per l’indagine, perché le barriere non riuscivano a distinguere le domande di un incident responder da quelle di un attaccante. Hugging Face ha usato un modello open-weight da 753 miliardi di parametri (GLM-5.2) per elaborare più di 17.000 eventi di attaccanti in ore invece che in giorni.

Perché è importante: questo è un caso documentato di un agente autonomo che scopre indipendentemente una vulnerabilità, esfiltra credenziali, falsifica token e si muove lateralmente attraverso l'infrastruttura cloud senza direzione umana. Se il tuo modello di IAM e governance considera solo identità umane e di account di servizio, questo incidente è una ragione concreta per aggiungere una terza categoria: agenti autonomi che possono agire di propria iniziativa.

Cosa che questi tre hanno in comune

CloudBasher riguarda le lacune nei controlli di identity a livello di protocollo: revoca dei token, confini di assunzione dei ruoli, politiche di accesso predefinite. GhostJacking riguarda un agente AI che utilizza un'identità legittima e delegata per agire su istruzioni in cui non avrebbe dovuto fidarsi. L'incidente OpenAI–Hugging Face riguarda un agente che ottiene e falsifica credenziali da solo, senza che un umano o un log compromesso lo abbia spinto a farlo.

Un filo separato attraversa tutti e tre: i difensori sono vincolati da strumenti che gli aggressori non devono rispettare. CloudBasher ha sfruttato ipotesi che i difensori non avevano testato. GhostJacking ha sfruttato il fatto che gli strumenti di identity non possono valutare l’intento. E nel caso OpenAI–Hugging Face, le barriere di sicurezza pensate per prevenire abusi hanno anche rallentato chi rispondeva.

---

Passi pratici successivi per i team di identity e AD

Quattro cose da fare questo trimestre basate su questa ricerca:

Ricerche che potresti aver perso

Nel caso te lo fossi perso, condividiamo tre dei migliori post del team di Security Research di Netwrix.

Controlli LDAP estesi potenti: Anti-remediation e ricognizione invisibile in AD 

Il ricercatore senior di sicurezza Darryl Baker ha esaminato tutti i controlli estesi LDAP documentati di Active Directory e ha trovato due con potenziale offensivo che non erano stati precedentemente pubblicati. FORCE_UPDATE consente a un attaccante con accesso in scrittura a un solo attributo di far vincere un valore dannoso nella risoluzione dei conflitti di replicazione di AD, quindi una correzione successiva del difensore viene silenziosamente annullata. Il flag OBJECT_SECURITY su DirSync consente a qualsiasi utente di dominio di leggere in massa i dati AD tramite il percorso di replicazione senza generare gli eventi di log che una ricerca normale attiverebbe. Nessuno concede nuovi privilegi, ma entrambi sconfiggono i rilevamenti su cui si basano la maggior parte dei difensori; il post include indicazioni di rilevamento corrispondenti e strumenti open source red/blue.

Perché è importante: entrambe le tecniche superano gli eventi di log esatti (Evento 1644, Evento 4662) su cui si basano la maggior parte delle regole di monitoraggio AD. Se le tue rilevazioni non sono state testate specificamente su di essi, probabilmente non si attiveranno. Vale sicuramente la pena verificare se i tuoi canarini SACL e le query di ricerca li rileverebbero effettivamente. 

Leggi di più

Il tuo assistente di codifica AI sta perdendo segreti 

Darryl Baker ha esaminato l’archiviazione delle credenziali in 14 popolari strumenti di assistenti desktop AI, tra cui Claude Code, GitHub Copilot, Cursor, Continue.dev e Cline, scoprendo che la maggior parte conserva token OAuth e chiavi API in JSON in chiaro in percorsi di file prevedibili. Una lacuna specifica: su WSL, i file delle credenziali di Claude Code su Windows possono ereditare permessi di lettura globale. Il post illustra otto scenari di attacco, incluso il dirottamento di una sessione di controllo remoto attiva di Claude Code e file di configurazione MCP che aggregano token per più servizi in un singolo file leggibile. Presenta anche AIHound, uno scanner open source di Netwrix che controlla una macchina per questo tipo di credenziali esposte.

Perché è importante: se i tuoi ingegneri usano uno di questi strumenti, le loro credenziali probabilmente sono memorizzate in chiaro sul disco in questo momento, in un percorso file che un attaccante non deve indovinare. Non è necessaria alcuna escalation di privilegi per leggerle, e poiché le configurazioni MCP raggruppano più token di servizio in un unico file, un singolo laptop compromesso può propagarsi a ogni sistema o servizio connesso. Questo può includere database, infrastrutture cloud e persino altri strumenti di IA. AIHound ti offre un modo rapido per verificare la tua esposizione prima che qualcun altro la scopra per te. 

Leggi di più

Automazione della distruzione del tenant Entra ID con AI 

Utilizzando Claude per Chrome contro Microsoft Graph Explorer, Huy Kha ha dimostrato che una volta che un account con accesso di Amministratore Globale è connesso, JavaScript lato browser e richieste batch di Graph possono automatizzare la cancellazione di massa degli utenti, il reset delle password, la revoca delle sessioni e la rimozione delle policy di Accesso Condizionale. Il post collega questo a incidenti reali, inclusi i casi Stryker e Storm-0501, dove operazioni distruttive sul tenant sono seguite a una compromissione di account privilegiato, sottolineando che l'IA non ha creato un nuovo percorso di attacco qui; ha sfruttato un flusso di lavoro amministrativo esistente rendendolo più veloce e facile da eseguire su larga scala.

Perché è importante: questa è la differenza tra una compromissione di un account privilegiato e la distruzione completa del tenant, e l'automazione AI la sta colmando rapidamente. Una volta che qualcuno ha una sessione di Global Admin, non servono più competenze di scripting o tempo per causare il massimo danno. Questo aumenta l'importanza di proteggere e monitorare le sessioni admin e strumenti come Graph Explorer, non solo le credenziali. 

Leggi di più

Rapporto sulla Sicurezza dei Dati e Identity Security 2026: Progressi e lacune nell’adozione e preparazione dell’IA agentiva

Netwrix Research Lab ha intervistato 2.317 professionisti IT e della sicurezza in 1.889 organizzazioni per realizzare il Rapporto sulla Sicurezza dei Dati e dell'Identity 2026. I risultati mostrano che le organizzazioni in cui l'IA ha ampliato significativamente la loro impronta di identity sono state violate circa quattro volte più spesso rispetto a quelle in cui non è successo. Il rapporto attribuisce il divario alla velocità di governance piuttosto che al rigore: il 76% delle organizzazioni non governa o monitora completamente le identità non umane, e solo l'11% riporta una piena preparazione alla sicurezza dell'IA attraverso un'applicazione e un monitoraggio continui.

Perché è importante: i dati complicano un'assunzione comune, ovvero che una buona igiene dell'identità da sola protegga dai rischi guidati dall'IA. Se la tua governance dell'identità si basa ancora su revisioni trimestrali e audit periodici, vale la pena verificare quanto tempo un nuovo agente IA o un'identità non umana esistono prima che qualcuno se ne accorga. Quel ritardo, non un controllo mancante, è ciò a cui si riferisce effettivamente il divario di violazione in questo rapporto.

Leggi di più

---

Questo è tutto per questa edizione del Netwrix Threat Lab Quarterly. Torneremo presto con nuove ricerche e altri modi per chiudere le falle che gli aggressori contano che tu trascuri.