Huy Kha | Architetto senior per l'identità e la sicurezza

Active Directory (AD) è ancora al centro della maggior parte degli ambienti aziendali e gli aggressori lo sanno. Poiché le minacce prendono sempre più di mira l'identità, l'AD continua a essere un punto chiave di accesso e di escalation dei privilegi. Il problema è che molte delle stesse configurazioni errate e sviste si riscontrano in diverse organizzazioni, indipendentemente dalle dimensioni o dal settore.

Dopo aver esaminato i risultati di diverse valutazioni della sicurezza di Active Directory (ADSA) nel 2025, il team di Semperis Identity Forensics and Incident Response (IFIR) ha individuato un chiaro schema. Alcuni rischi continuano ad emergere. Alcuni sono ben noti ma non vengono affrontati, mentre altri sono facili da ignorare senza gli strumenti o la visibilità giusti.

In questo post, illustrerò i 10 rischi AD più comuni riscontrati negli ambienti reali e spiegherò cosa sono, perché sono importanti e come gli aggressori li sfruttano.

Rischio 1: Percorsi di attacco di livello 0 aperti da autorizzazioni non correttamente configurate

Durante le attività di ADSA, una delle configurazioni errate più pericolose che il team IFIR ha osservato è quella in cui gli account o i gruppi si ritrovano con diritti DCSync attraverso autorizzazioni indirette. Ciò non significa che qualcuno abbia assegnato direttamente i permessi. Ad esempio, un account non privilegiato potrebbe far parte di un gruppo che ha pieni diritti di controllo su un account privilegiato che dispone già di funzionalità DCSync.

Di conseguenza, un aggressore non ha bisogno di colpire direttamente l'account privilegiato. Può puntare all'anello più debole della catena e ottenere comunque l'accesso allo stesso livello di controllo. La configurazione errata di solito avviene perché le autorizzazioni sono delegate in modo troppo ampio, il che porta a una violazione indiretta del livello 0 (Figura 1).

Figura 1. Questa scansione mostra un indicatore di esposizione (IOE) derivante da una configurazione errata delle autorizzazioni delegate.

Un altro esempio di percorso di attacco che porta a una violazione di livello 0 è la compromissione di un account con autorizzazioni di scrittura sugli oggetti del controller di dominio (DC)(Figura 2). Questo accesso può essere sfruttato per eseguire un attacco RBCD (Resource-Based Constrained Delegation), consentendo all'aggressore di impersonare account con privilegi elevati.

Figura 2. Questo indicatore espone gli utenti o i gruppi non predefiniti a cui è stato concesso l'accesso in scrittura a un oggetto DC.

Rischio 2: uso eccessivo di gruppi AD integrati con privilegi elevati

Gli ambienti Windows più vecchi spesso includono gruppi integrati destinati all'amministrazione delegata di funzioni quali Operatori account, Operatori server, Operatori backup e Operatori stampa. Questi gruppi sono spesso trascurati, ma possono ancora detenere privilegi elevati in Active Directory(Figura 3). Se questi gruppi sono popolati, i loro membri possono eseguire azioni che portano all'escalation dei privilegi e all'accesso diretto agli asset di livello 0.

Figura 3. Questa scansione esamina l'AD alla ricerca di gruppi incorporati legacy ad alto privilegio che rappresentano un rischio per la sicurezza.

L'uso continuato di gruppi incorporati legacy aumenta il rischio di compromissione, soprattutto se gli account al loro interno non sono strettamente monitorati o controllati. In generale, le best practice consigliano di evitare di affidarsi alla maggior parte dei gruppi incorporati in AD (ad esempio, DnsAdmins, DHCP Administrators, Group Policy Creator Owners, Remote Desktop Users), poiché spesso dispongono di ampie autorizzazioni(Figura 4).

Figura 4. Questo indicatore identifica i membri di gruppi integrati comuni che possono avere ampie autorizzazioni.

Rischio 3: Configurazione insicura di LAN Manager

NT LAN Manager versione 1 (NTLMv1) è un protocollo di autenticazione legacy che è ancora sorprendentemente comune in alcuni ambienti, ma non dovrebbe esserlo. Utilizza una crittografia debole che rende facile per gli aggressori catturare e decifrare il traffico di autenticazione(Figura 5). Se un aggressore riesce a far autenticare un computer utilizzando NTLMv1 (di solito con uno strumento di attacco come Responder), può prendere l'hash della password e decifrarla offline per ottenere il testo della password.

Figura 5. Questo avviso di Microsoft segnala la consapevolezza della vulnerabilità dei protocolli di autenticazione obsoleti.

Attualmente, tutti i sistemi operativi Microsoft supportano la nuova versione 2 di NT LAN Manager. Prima di imporre NTLMv2 in tutto il dominio, iniziate ad abilitare l'auditing di NTLM per identificare i sistemi o le applicazioni che utilizzano ancora NTLMv1. Una volta esaminati i registri e risolte eventuali dipendenze legacy, potete iniziare a configurare un oggetto Criteri di gruppo (GPO) a livello di dominio per impostare il livello di autenticazione di LAN Manager su Send NTLMv2 response only. Refuse LM & NTLM (Figura 6). Questa impostazione impone l'autenticazione moderna e blocca i protocolli più deboli.

Figura 6. Assicuratevi di impostare i criteri di sicurezza per applicare i moderni protocolli di autenticazione.

Rischio 4: Configurazione insicura dell'ADCS

Il nostro team IFIR rileva che i servizi di certificazione di Active Directory (ADCS) mal configurati rimangono un rischio trascurato ma ad alto impatto in molti ambienti. Quando i modelli di certificato, le autorizzazioni di iscrizione o le funzioni di iscrizione via web non sono adeguatamente protette, gli aggressori possono abusare degli ADCS per impersonare gli utenti, aumentare i privilegi e ottenere il controllo non autorizzato di sistemi sensibili.

Un problema comune è rappresentato dai modelli di certificato eccessivamente permissivi che consentono a qualsiasi utente autenticato di iscriversi per ottenere certificati con l'opzione Client Authentication EKU. In combinazione con il ENROLLEE_SUPPLIES_SUBJECT questa configurazione consente agli utenti di specificare autonomamente l'oggetto del certificato (Figura 7), che può consentire agli utenti con un basso livello di privilegio di richiedere certificati per conto di altri account, compresi gli amministratori di dominio. Questi certificati possono essere utilizzati per impersonare tali account e ottenere un accesso elevato. Questo tipo di configurazione errata è classificata come ESC1.

Figura 7: I modelli di certificato ADCS mal configurati possono consentire agli aggressori di richiedere certificati per account con privilegi elevati e ottenere un accesso elevato.

Un rischio correlato si verifica quando gli utenti con privilegi bassi hanno la possibilità di modificare i modelli di certificato. Gli aggressori possono abusare di questa vulnerabilità per introdurre impostazioni non sicure, come ad esempio l'abilitazione di ENROLLEE_SUPPLIES_SUBJECT, che può trasformare un template precedentemente sicuro in uno vulnerabile ad attacchi come ESC1 (Figura 8). Questo tipo di errata configurazione rientra nella categoria ESC4.

Figura 8. Questo indicatore di sicurezza avverte che una configurazione errata del modello di certificato può comportare dei rischi.

Rischio 5: delega non vincolata

La delega non vincolata(Figura 9) è pericolosa perché quando un utente richiede un ticket di servizio su un server con questa impostazione, il suo ticket di concessione (TGT) viene incluso e rimane in memoria. Se un utente malintenzionato prende il controllo del server, può prendere il TGT e usarlo per impersonare l'utente. Il rischio aumenta se il servizio Windows Print Spooler è in esecuzione sui DC. Un utente malintenzionato può utilizzare il bug della stampante per far autenticare un DC al server compromesso, facendo così trapelare il TGT del DC stesso e dandogli il pieno controllo.

Per ridurre il rischio, assicuratevi che i vostri conti Tier 0 o equivalenti abbiano i requisiti necessari. Account is sensitive and cannot be delegated e aggiungerli al gruppo Utenti protetti.

Figura 9. L'impostazione di una delega non vincolata su un server espone il TGT di Kerberos a compromessi e abusi.

Rischio 6: Gli utenti non privilegiati possono aggiungere account di computer al dominio.

Nella maggior parte degli ambienti AD, ogni utente autenticato può aggiungere fino a 10 computer al dominio. È un'impostazione predefinita che spesso viene dimenticata. Ma gli aggressori non lo dimenticano. Se ottengono l'accesso a qualsiasi account a basso livello di privilegio, possono creare un oggetto computer(Figura 10) e utilizzarlo in attacchi che sfruttano l'RBCD.

La situazione peggiora quando alcuni modelli di certificato consentono ai computer di dominio di iscriversi e di includere il Client Authentication EKU con il ENROLLEE_SUPPLIES_SUBJECT flag. Questa combinazione apre la porta a un classico attacco ESC1, in cui l'aggressore può richiedere un certificato che gli consenta di impersonare un altro utente. Se non si ha un motivo per consentire agli utenti di aggiungere macchine al dominio, è meglio impostare l'opzione ms-DS-MachineAccountQuota a 0 e bloccarlo.

Figura 10. Questo indicatore di sicurezza avverte che è necessario assicurarsi che gli utenti non possano aggiungere macchine al dominio.

Rischio 7: account privilegiati con SPN configurato

L'assegnazione di Service Principal Names (SPN) agli account utente privilegiati, come gli amministratori di dominio o altri account di livello 0, introduce un grave rischio per la sicurezza. Quando un account privilegiato ha un SPN (Figura 11), qualsiasi utente autenticato del dominio può inviare una richiesta di Ticket-Granting Service (TGS) Kerberos. Il ticket ottenuto è crittografato con l'hash della password dell'account, il che significa che un utente malintenzionato può estrarlo ed eseguire un'azione di Kerberoasting attacco. Una configurazione comunemente errata consiste nell'assegnare un MSSQL SPN all'account Administrator integrato (RID 500), che offre agli aggressori un percorso Kerberoasting diretto a uno degli account più potenti del dominio.

Il punto chiave è che il cracking avviene interamente offline. Una volta in possesso del ticket, l'aggressore può eseguire un attacco brute-force o a dizionario utilizzando strumenti come hashcat senza generare ulteriore traffico o avvisi sul CC. Agli account privilegiati non dovrebbero mai essere assegnati SPN. Se un servizio necessita di un SPN, deve essere eseguito con un account di servizio separato, a basso livello di privilegio e con una password forte e gestita.

Figura 11: Questa scansione identifica gli account privilegiati con SPN definiti.

Rischio 8: account di servizio obsoleti ancora abilitati

Gli account di servizio tendono ad accumularsi nel tempo. Spesso sono stati creati per sistemi che sono stati sostituiti, per script una tantum o per vecchi progetti che nessuno gestisce più. Il problema è che molti di questi account rimangono abilitati anche dopo che non sono più necessari. Alcuni di essi dispongono ancora di autorizzazioni elevate o sono esclusi dai normali criteri di password, il che li rende un bersaglio perfetto per gli aggressori. Se uno di questi account dimenticati viene compromesso, può essere difficile da individuare. Poiché nessuno lo utilizza attivamente, le attività sospette possono passare inosservate.

Come mostra la Figura 12, è opportuno rivedere regolarmente gli account di servizio. Se un account non viene utilizzato da molto tempo e nessuno può giustificarne lo scopo, disattivatelo e monitorate le eventuali ricadute.

Figura 12. L'esame regolare degli account di servizio e delle loro attività aiuta a garantire che gli account inutilizzati vengano eliminati prima che possano essere compromessi.

Rischio 9: Mancanza di applicazione di livello 0

Implementare un modello di tiering aziendale completo è impegnativo e spesso irrealistico. Ma avere un modello minimo per i sistemi di livello 0 non è negoziabile.

Il livello 0 è costituito dai sistemi che controllano l'identità e, se vengono compromessi, il resto dell'ambiente cade con loro. Nella maggior parte delle ADSA, abbiamo visto che molte organizzazioni non dispongono di alcun modello di tiering.

Se non avete ancora stabilito un modello Tier 0, è il momento di iniziare. Per aiutarvi, la Figura 13 mostra un elenco di sistemi comunemente trattati come Tier 0 in ambienti ben protetti e un modello per determinare il loro stato di Tier 0.

Figura 13. La comprensione, l'identificazione e la protezione delle risorse di livello 0, come quelle elencate, sono essenziali per la sicurezza informatica aziendale.

Rischio 10: backup di Active Directory inaffidabili e non ripristinabili

AD è il cuore dell'autenticazione e dell'accesso in tutto l'ambiente. Eppure, una delle lacune più critiche che riscontriamo ancora in molte organizzazioni è la mancanza di un'adeguata strategia di backup per Active Directory.

Alcune organizzazioni ritengono che la presenza di controller di dominio distribuiti tra i vari siti sia sufficiente, oppure si affidano a snapshot di macchine virtuali generiche senza verificare se tali backup siano in grado di ripristinare AD in modo coerente e supportato.

La realtà è che se Active Directory va in tilt e non c'è un backup pulito e ripristinabile, il ripristino diventa estremamente difficile, soprattutto dopo un cyberattacco.

Un backup AD affidabile non è solo una copia o un'istantanea a livello di file. Create un backup affidabile e convalidato. Isolatelo dal dominio di produzione. Proteggetelo dalla manomissione. E testatelo regolarmente. Perché senza di esso, state lasciando la vostra infrastruttura più critica esposta a danni irreversibili.

Istantanea Semperis

In un periodo in cui gli attacchi informatici non sono una questione di "se" ma di "quando", le organizzazioni devono adottare misure per garantire la resilienza prima, durante e dopo un incidente informatico.

Iniziate eliminando le vulnerabilità comuni come queste. Poi, collaborate con esperti di identità e scegliete strumenti identity-first che vi aiutino:

  • Rafforzare le difese
  • Stabilire in modo proattivo strategie efficaci di risposta agli incidenti
  • Recuperare rapidamente quando si verifica un incidente
  • Ridurre il rischio a lungo termine

Avete bisogno di dare un'occhiata più approfondita alla vostra infrastruttura di identità? Sfruttate le conoscenze decennali di prima mano del nostro team IFIR.

Ulteriori informazioni sull'eliminazione delle vulnerabilità di Active Directory