Migliorare la sicurezza di Active Directory: AdminSDHolder in soccorso

Questo documento sottolinea l'importanza dei permessi di lettura predefiniti nella sicurezza di Active Directory (AD), spesso trascurati. La foresta AD non è solo un confine di sicurezza, ma dovrebbe essere considerata anche come il raggio di accesso e di valutazione della sicurezza degli oggetti AD da parte di un intruso dopo l'ingresso nella rete di un'organizzazione. La rimozione di specifiche autorizzazioni di lettura predefinite è una misura a basso rischio che aumenta la difficoltà per gli intrusi di effettuare ricognizioni e pianificare le loro prossime mosse. La comprensione della logica integrata del meccanismo di protezione di Microsoft per gli account più privilegiati della directory è fondamentale per comprendere i vantaggi e gli svantaggi di questo meccanismo.

Questo documento spiega come regolare il meccanismo di protezione rimuovendo le autorizzazioni di lettura predefinite e rischiose per migliorare la sicurezza di AD. Inoltre, il documento affronta il problema del debito di configurazione nella maggior parte delle infrastrutture AD e come correggere le autorizzazioni sugli oggetti che un tempo facevano parte di un gruppo privilegiato ma che ora non lo sono più. In definitiva, proteggere AD limitando la visibilità degli oggetti e le autorizzazioni generali di lettura è fondamentale per ridurre la superficie di attacco di AD e migliorarne la sicurezza.

Limitazione della ricognizione e dei movimenti laterali

Un lockdown adeguato ha un impatto diretto sulla difficoltà o la facilità con cui gli intrusi possono usare Active Directory (AD) contro di voi durante la fase di ricognizione di un attacco.

Come illustrato nella Figura 1, questa fase si verifica dopo che un utente malintenzionato ha stabilito un punto d'appoggio nella rete aziendale, in genere ingannando i dipendenti tramite e-mail di phishing o siti Web speciali dannosi. A questo punto, l'intruso si è impossessato solo dell'account AD di un normale utente autenticato (ossia un account di dipendente non privilegiato che non amministra l'AD dell'azienda). Potreste pensare che un utente non privilegiato non sia una minaccia per la sicurezza della vostra azienda, ma per quanto tempo un intruso rimarrà non privilegiato? Inizialmente gli intrusi sfruttano le vulnerabilità note del sistema operativo (OS) o dei driver sugli endpoint non sufficientemente patchati per elevare i propri privilegi locali e ottenere così rapidamente l'accesso amministrativo al client compromesso. Ciò consente loro di disattivare altre protezioni eventualmente presenti sul client, scaricare altro malware e stabilire un sistema di comando e controllo che di solito consente l'accesso remoto diretto da parte di altri membri della banda. L'obiettivo successivo sarebbe quello di spostarsi lateralmente su altri client, eseguendo un'adeguata ricognizione con l'obiettivo di compromettere un account di amministrazione del dominio per ottenere infine il dominio del dominio.

Tuttavia, il vero obiettivo dell'intruso è chiaro: raggiungere ed estrarre i vostri dati aziendali sensibili per mettervi sotto pressione. Meglio ancora, aumentare tale pressione criptando il maggior numero possibile di sistemi del vostro ambiente, compresi tutti i server, i loro backup e le copie di sicurezza di tali backup. Queste azioni sono poi seguite da un'amichevole nota di riscatto, che richiede un pagamento in Bitcoin entro poche ore o giorni e promette che al momento del pagamento riceverete una chiave di decrittazione e che i vostri dati sensibili non saranno assolutamente rilasciati al miglior offerente sul Dark Web. Paghereste? Idealmente, non dovrete rispondere a questa domanda. Al contrario, dovrete impegnarvi per evitare che gli intrusi raggiungano il loro obiettivo, rilevando il vostro AD e distruggendo la vostra azienda. Il primo passo è rendere difficile per qualsiasi intruso individuare gli utenti privilegiati e leggere i dati sensibili dall'AD.

Bloccare l'AD può fare la differenza

Un "blocco" dell'AD di solito si riferisce alla modifica dei permessi nella directory (cioè alla modifica di alcuni permessi predefiniti). Sfortunatamente, questi permessi sono troppo aperti, e rendono accessibili ai malintenzionati troppe informazioni memorizzate nell'AD. Gli utenti tipici e le applicazioni aziendali hanno raramente bisogno di queste informazioni, quindi la rimozione di alcuni permessi nell'AD vi avvicina molto di più alla best practice generale della sicurezza informatica: il modello del minimo privilegio, in cui si concedono agli utenti solo i permessi necessari per svolgere il proprio lavoro. Per qualsiasi modifica dei permessi in AD, tuttavia, è sempre necessario valutare i pro e i contro di come tali modifiche potrebbero influire sulle applicazioni aziendali. Dopotutto, un AD perfettamente sicuro che non riesce a supportare le vostre applicazioni aziendali non vi è di alcun aiuto. L'ideale è disporre di un solido ambiente di test che contenga non solo una foresta AD di prova (configurata proprio come l'AD di produzione), ma anche una copia delle applicazioni aziendali più critiche che utilizzate. Questo ambiente consente di verificare l'impatto di eventuali modifiche ai permessi in AD prima di implementarle in produzione.

In ogni caso, le modifiche ai permessi devono essere pianificate con attenzione (vedi Figura 2). La buona notizia è che il ripristino dei permessi originali è abbastanza semplice (ad esempio, se il test ha trascurato alcuni artefatti). La documentazione dei permessi modificati in AD è fondamentale per poter annullare tali modifiche. Uno strumento di auditing AD adeguato può fare questo per voi, mantenendovi in una posizione sicura.

I vostri oggetti privilegiati sono un obiettivo chiave per gli intrusi

Se dovete scegliere un'area specifica per iniziare il lockdown dell'AD, la prima scelta dovrebbe essere chiaramente quella degli account e dei gruppi privilegiati. Si tratta dei gruppi enterprise e domain admins e dei loro membri, ma anche di altri gruppi speciali come account operator, server operator ecc. e dei loro membri. In un AD correttamente configurato, nessuna delle applicazioni aziendali utilizzerà questi gruppi e account privilegiati. Tali applicazioni non hanno nemmeno bisogno di eseguire una ricerca LDAP (lightweight directory access protocol) come "chi è membro del gruppo admins del dominio" per funzionare. Pertanto, questo blocco di AD è in genere un'attività a basso rischio. AD utilizza l'attributo "adminCount" sugli oggetti per segnalare quelli che considera "privilegiati"; gli oggetti corrispondenti hanno questo attributo impostato su 1. Per capire quali gruppi AD considera privilegiati, è possibile eseguire una semplice query LDAP con il seguente filtro^:1

(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))

Questa query cerca solo i gruppi di sicurezza, in particolare quelli contrassegnati da un '1' nell'attributo adminCount. Utilizzare il metodo di interrogazione LDAP preferito, ad esempio DSQUERY:

dsquery * domainroot “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”

o PowerShell:

Get-ADObject -LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”

o il filtro LDAP direttamente in AD Users & Computers Microsoft Management Console (MMC), con l'opzione di ricerca personalizzata/avanzata (vedere Figura 3). I risultati nel vostro dominio potrebbero essere diversi, soprattutto se avete annidato altri gruppi in questi gruppi privilegiati predefiniti, anche se temporaneamente. I risultati dipendono anche dalla versione del sistema operativo dei controller di dominio AD e dal modo in cui è stato effettuato l'aggiornamento tra le versioni. Idealmente, però, l'elenco non si discosta troppo da quello predefinito. In caso contrario, potreste dover fare un po' di lavoro di pulizia (discusso di seguito). Innanzitutto, è importante capire il significato e la provenienza dell'attributo adminCount, oltre ad alcune nozioni di base sul comportamento e la progettazione di AD.

La delega fine dei permessi è stata una pietra miliare del successo di AD

Quando Microsoft ha progettato AD più di 23 anni fa, ha aggiunto potenti funzionalità di delega dei permessi, fino a ogni attributo degli oggetti della directory. La base di questa capacità era la memorizzazione di autorizzazioni separate, chiamate descrittore di sicurezza o elenco di controllo degli accessi (ACL), per ogni oggetto in AD come parte dell'oggetto stesso (memorizzato nell'attributo nTSecurityDescriptor ). Il modello di sicurezza di AD supportava l'ereditarietà dei permessi lungo un intero albero di unità organizzative (UO) per configurare in modo efficiente i permessi senza doverli impostare separatamente su tutti gli oggetti. Ma il modello consentiva anche di impostare permessi espliciti direttamente su un oggetto (ad esempio un'altra OU, un utente o un gruppo) (cfr. Figura 4). I permessi espliciti di questo oggetto possono essere mescolati con i permessi ereditati o possono bloccare i permessi ereditati dall'oggetto padre.

Questa flessibilità ha permesso anche alle aziende più grandi di utilizzare una directory IT centrale e globale, in grado di delegare importanti attività di assistenza ad altri team. All'epoca in cui fu progettato AD, era prassi comune avere team di helpdesk separati in ogni paese in cui operava un'azienda. Questi team eseguivano le classiche attività di assistenza, come il ripristino della password di un account utente nella propria regione, l'aggiunta di oggetti informatici o persino l'aggiunta di utenti ai gruppi, come richiesto dalla gestione dell'azienda. Attraverso la delega dei permessi al livello OU appropriato (ad esempio, OU=PHX,OU=US, DC=mycompany,DC=com) e l'ereditarietà dei permessi lungo l'intero ramo OU agli oggetti pertinenti (ad esempio, utente, computer, gruppo), i membri di un gruppo AD di helpdesk corrispondente potevano eseguire tutte le attività di supporto necessarie per gli utenti, i computer e i gruppi in una qualsiasi delle sotto-UO. Questa capacità non richiede che i membri del gruppo abbiano l'autorizzazione ad amministrare il servizio AD stesso. In altre parole, il personale dell'helpdesk non era membro del gruppo degli amministratori di dominio e non poteva modificare la configurazione AD, promuovere nuovi controller di dominio (DC) o accedere ai controller di dominio AD.

Gli utenti dell'helpdesk con autorizzazioni specifiche delegate in AD sono definiti amministratori di dati AD, mentre gli account veramente privilegiati, come gli amministratori di dominio, sono conosciuti come amministratori di servizi AD. Ma cosa succede se un "vero" account di amministratore di dominio si trova in una sotto-unità a cui il personale dell'helpdesk ha concesso i diritti di reimpostare le password degli utenti? O peggio, se qualcuno non concede all'helpdesk le autorizzazioni al livello appropriato della sub-OU, ma lo fa alla radice del dominio? Senza un meccanismo di protezione aggiuntivo in AD che impedisca a un amministratore di dati, come un account di helpdesk, di eseguire modifiche (come la reimpostazione della password) su un amministratore di servizi, come un account di amministratore di dominio o qualsiasi altro account o gruppo privilegiato, la sicurezza complessiva di qualsiasi implementazione di AD sarebbe in uno stato disastroso. Il personale dell'helpdesk delegato potrebbe facilmente compromettere l'intero AD.

SDPROP: la funzione di protezione AD integrata

La protezione di questi oggetti AD privilegiati è esattamente il compito del processo Security Descriptor Propagation (SDPROP). Questo processo viene eseguito periodicamente (ogni 60 minuti per impostazione predefinita, o in base alla configurazione) su ogni emulatore di controller di dominio primario (PDCE) di ogni dominio in una foresta AD e cerca tutti gli oggetti privilegiati nel rispettivo dominio AD. SDPROP non si limita a verificare l'appartenenza ai gruppi predefiniti (come gli amministratori di dominio), ma continua a seguire tutti i gruppi annidati in questi gruppi privilegiati e a contrassegnare questi ultimi e i loro membri come "privilegiati". Poiché è possibile aggiungere utenti, gruppi e persino oggetti informatici a tali gruppi privilegiati, tutti questi oggetti vengono presi in considerazione durante la scansione. Avvertenza importante: gli oggetti devono essere locali allo stesso dominio del gruppo privilegiato per essere considerati da SDPROP, quindi non aspettatevi la stessa protezione per gli utenti aggiunti da un altro dominio.

Per ogni oggetto privilegiato trovato da SDPROP, il processo confronta il descrittore nTSecurityDescriptor dell'oggetto con uno speciale modello di autorizzazione riservato esclusivamente allo scopo di proteggere tali oggetti privilegiati. Questo modello concede una serie di autorizzazioni, ma soprattutto garantisce che solo gli amministratori, gli amministratori di dominio e gli amministratori aziendali possano modificare la password degli account privilegiati. Se il processo SDPROP trova una deviazione tra le autorizzazioni degli oggetti individuati e quelle del modello, sostituisce il descrittore nTSecurityDescriptor dell'oggetto in questione con quello del modello e aggiorna l'attributo adminCount dell'oggetto con un "1".

Dietro le quinte: AdminSDHolder

Il modello di autorizzazione speciale che SDPROP copia negli oggetti privilegiati è configurabile. È l'nTSecurityDescriptor(permissions) dell'oggetto AdminSDHolder del dominio. Questo nome dovrebbe far suonare un campanello: è letteralmente l'oggetto "admin security descriptor holder", un oggetto contenitore situato nel contenitore di sistema di ogni dominio(CN=AdminSDHolder,CN=System,DC=myco mpany,DC=com). I permessi predefiniti impostati su AdminSDHolder sono relativamente restrittivi per quanto riguarda le modifiche agli oggetti. È quello che ci si aspetta dai permessi che verranno applicati a tutti i gruppi e gli utenti privilegiati dell'AD. L'elenco esemplificativo delle autorizzazioni nella Figura 5 proviene da una recente implementazione di un laboratorio di prova su Windows Server 2019 che non contiene server Exchange. Se nel vostro ambiente è presente Exchange, troverete altre autorizzazioni aggiunte a questo modello. Dopotutto, gli sviluppatori di Exchange hanno pensato di "possedere" l'AD per la loro applicazione. Per il momento, tenete presente che le seguenti autorizzazioni sono impresse su tutti gli oggetti privilegiati nel rispettivo dominio AD. Soprattutto, si può notare che questo elenco di controllo degli accessi (ACL) non ha l'ereditarietà abilitata. In altre parole, l'ACL blocca l'ereditarietà dei permessi impostati su un oggetto genitore (OU), compresi i permessi di reimpostazione della password di helpdesk discussi in precedenza. In questo modo, la combinazione di SDPROP e AdminSDHolder protegge gli account più privilegiati da autorizzazioni mal configurate nell'AD.

Tecnicamente, è possibile rimuovere alcuni gruppi di amministratori predefiniti in AD dall'essere considerati privilegiati dal processo SDPROP, in particolare i gruppi di operatori di account, operatori di server, operatori di stampa e operatori di backup. I membri non verrebbero quindi sovrascritti con le autorizzazioni dell'oggetto AdminSDHolder. Tuttavia, poiché ogni gruppo presenta un rischio proprio per quanto riguarda l'elevazione dei privilegi in AD, questa configurazione non è consigliata. È opportuno proteggere questi gruppi o, meglio ancora, non utilizzarli affatto. Per saperne di più sull'esclusione (o reinclusione) di questi gruppi dal processo SDPROP, consultate l'articolo "Active Directory Security: Capire l'oggetto AdminSDHolder"^.2

Il ruolo dell'attributo AdminCount

L'attributo adminCount non ha alcuna rilevanza per la sicurezza. È una semplice funzione di supporto che consente di utilizzare più facilmente una query LDAP per determinare quali permessi degli oggetti sono stati sostituiti con i permessi impostati su quel modello speciale, come mostrato in precedenza. Si noti che una volta rimosso un utente, un gruppo o un computer da un gruppo privilegiato, questo non sarà più privilegiato. Il processo SDPROP scrive l'event-id 4780 nel registro degli eventi di sicurezza del controller di dominio primario (PDC) quando timbra le autorizzazioni AdminSDHolder sugli oggetti privilegiati e aggiorna tali oggetti con l'attributo adminCount (impostato a 1). Tuttavia, non ripristina tali modifiche una volta che l'oggetto non è più privilegiato, né scrive alcun evento nell'event-log per informare l'utente che non lo considera più privilegiato. Ad esempio, quando si aggiunge temporaneamente qualcuno al gruppo admins del dominio e il processo SDPROP viene eseguito prima di rimuovere l'utente, quest'ultimo avrà ancora l'impostazione nTSecurityDescriptor bloccata e sarà contrassegnato con adminCount=1. Lo stesso vale per qualsiasi oggetto. Idealmente, quindi, non si dovrebbe aggiungere temporaneamente un utente a un gruppo privilegiato. Se lo si è fatto, è necessario ripulire i permessi e l'attributo adminCount , in modo che l'utente sia configurato di nuovo allo stato originale. Questo processo di pulizia è descritto più avanti in questo documento.

Uno sguardo più approfondito ai permessi di AdminSDHolder

Una volta compresi questi concetti, siete soddisfatti delle autorizzazioni concesse tramite l'oggetto AdminSDHolder e SDPROP a tutti gli account privilegiati? Se guardate più da vicino questi permessi, anche senza Exchange, noterete alcune autorizzazioni discutibili, come evidenziato nella Figura 6, tratta dalla pagina delle impostazioni di sicurezza avanzate dell'oggetto AdminSDHolder, a cui si accede tramite AD users and computers o ADSI edit. Quale accesso concedono le altre voci contrassegnate come 'speciali' al rispettivo preside di sicurezza in quella ACL? Sfortunatamente, l'editor di sicurezza standard di AD non riesce a convertire correttamente la stringa SDDL memorizzata nell'attributo nTSecurityDescriptor . Anche quando si apre la rispettiva voce di controllo degli accessi (ACE), spesso le autorizzazioni speciali non vengono visualizzate. Pertanto, è necessario trovarli direttamente tramite PowerShell, attraverso qualcosa come (Get-Acl'AD:CN=AdminSDHolder,CN=System,D C=mydom,DC=local').access, oppure utilizzando DSACLS.exe, entrambi con un output difficile da decifrare. Uno strumento relativamente facile, potente e spesso trascurato per la gestione delle ACL è LDP.exe, che fa un lavoro perfetto visualizzando tutti gli ACE con le relative informazioni. Seguite questi passaggi per visualizzare completamente i permessi corretti dell'oggetto AdminSDHolder: Avviare LDP.exe;

1. Scegliere Connessione > Bind (o Ctrl + B) e Bind come utente attualmente connesso;
2. Scegliere Visualizza > Struttura (o Ctrl + T) e selezionare il proprio dominio come BaseDN;
3. Nell'albero dei domini a sinistra, spostarsi su Sistema > AdminSDHolder;
4. Fare clic con il pulsante destro del mouse sull'oggetto AdminSDHolder e selezionare Avanzate > Descrittore di sicurezza;
5. Fare clic su OK per visualizzare il descrittore di sicurezza;

La finestra risultante dovrebbe essere simile a quella della Figura 7. Se la si confronta con la Figura 6 dell'editor di sicurezza standard, si può notare che anche gli ACE sono ordinati nello stesso modo. Se non avete mai aggiornato i permessi di AdminSDHolder con l'editor di sicurezza predefinito (utilizzato in AD Utenti e computer e ADSIedit), l'editor di sicurezza LDP.exe mostra persino gli ACE di accesso originali compatibili con il periodo precedente a Windows 2000, suddivisi per molti tipi di oggetti. L'editor di sicurezza predefinito non è in grado di elaborare correttamente tali ACE e li sostituisce semplicemente con un'autorizzazione di lettura generica su qualsiasi altro aggiornamento dell'ACL; una volta aggiornato con l'interfaccia utente (UI) dell'editor di sicurezza predefinito, gli altri ACE per questo gruppo vengono automaticamente rimossi. Questo non accade se l'autorizzazione AdminSDHolder (o qualsiasi altra) viene aggiornata con l'editor di sicurezza LDP.exe, quindi in generale LDP.exe è l'opzione più sicura per l'aggiornamento delle ACL critiche in AD.

A questo punto si può facilmente confermare che i permessi di tutti e gli auto-permessi non sono preoccupanti. Il permesso di modifica della password potrebbe sembrare pericoloso, ma non indica altro che i diritti di modificare la password di un utente quando si conosce la vecchia password dello stesso utente (a differenza di reset password, che consente a un amministratore di sovrascrivere qualsiasi password esistente). Detto questo, qual è il problema con gli ACE evidenziati? L'account MSOL_5c0317387a29 (cioè "MSOL_" più una stringa casuale), evidenziato in arancione nella Figura 7, è presente nella maggior parte degli ambienti. Si tratta di un account predefinito che viene creato automaticamente durante la configurazione dello strumento Azure AD Connect, che utilizza l'account per sincronizzare gli oggetti tra l'AD on-premises e Azure AD. Le versioni precedenti di Azure AD Connect, quando si utilizzava l'opzione di installazione express, aggiungevano automaticamente l'account all'ACL AdminSDHolder per consentire il controllo dei gruppi e degli utenti privilegiati. Se l'account Azure AD Connect è stato configurato manualmente o si utilizza una versione più recente dello strumento, questa voce potrebbe non essere presente.

Non si dovrebbe replicare alcun account o gruppo AD privilegiato in Azure AD, poiché ciò potrebbe portare a ulteriori percorsi di attacco tra le due directory. Se si segue questa regola, non è necessario mantenere l'account di sincronizzazione con i permessi in questo modo, quindi si può anche rimuovere la voce da AdminSDHolder. L'account di sincronizzazione stesso, tuttavia, deve essere visto come altamente privilegiato e sensibile, quindi la rimozione dell'ACL in questo caso non fornisce un'ulteriore riduzione della superficie di attacco AD. Non è così per le due voci evidenziate in rosso: i gruppi ^Accesso3 e Utenti autenticati compatibili con pre-Windows 2000. A entrambi vengono concessi permessi di lettura completi su qualsiasi oggetto privilegiato in AD. Questo non è certo l'ideale: qualsiasi utente (o computer) nella foresta AD può enumerare il contenuto di qualsiasi gruppo privilegiato (ad esempio Domain Admins) ed elencare le varie appartenenze ai gruppi di qualsiasi utente privilegiato. Questo è esattamente il modo in cui piace agli intrusi: è facile determinare chi prendere di mira nell'AD e quale account catturare e utilizzare per eseguire un pass-the-hash o altri attacchi per ottenere il dominio e la foresta. Gli utenti e le applicazioni aziendali molto probabilmente non avranno mai bisogno di cercare queste informazioni, quindi perché concederle?

La risposta è semplice: non si deve. Rimuovete queste due autorizzazioni (compresi tutti gli altri ACE che potrebbero essere assegnati al gruppo di accesso compatibile con pre-Windows 2000). Sostituitele semplicemente con un'autorizzazione per un altro gruppo, ad esempio SVC-ADconfig- AdminSDHolder-READ. Il gruppo deve essere un gruppo locale di dominio, in modo da poterne controllare l'appartenenza quando si ha bisogno di un account di servizio o di un oggetto informatico che esegue un software che ha il diritto legittimo di leggere i dati dagli oggetti privilegiati. L'uso del tipo di gruppo locale di dominio consente di aggiungere qualsiasi utente, gruppo globale o universale o computer da qualsiasi dominio della foresta AD. Questa funzionalità potrebbe essere necessaria per il software o i sistemi utilizzati per monitorare o amministrare l'AD. Ad esempio, se si esegue Semperis Directory Services Protector (DSP), si desidera aggiungere l'account del computer DSP a tale gruppo. In questo modo, tutti gli altri utenti e computer non potranno leggere nulla degli oggetti privilegiati, il che rappresenta un modo efficace per ridurre la superficie di attacco dell'AD. Agli intrusi viene semplicemente impedito di enumerare gli oggetti appropriati. Si noti che questa azione deve essere ripetuta per ogni dominio della foresta AD.

Un modello AdminSDHolder aggiornato nel dominio root avrebbe quindi l'aspetto della Figura 8. Per determinare l'effetto che tali modifiche avranno sulla postura di sicurezza di AD, è necessario utilizzare i diritti che un intruso avrebbe a disposizione attraverso un normale utente di dominio sia prima che dopo la modifica dell'autorizzazione sull'oggetto AdminSDHolder nell'ambiente di produzione. Per semplicità, questo esempio controlla la sicurezza del dominio principale di una foresta AD, ignorando il dominio figlio. In realtà, si desidera controllare la sicurezza di tutti i domini della foresta.

Utilizzo di potenti scanner di vulnerabilità AD

È possibile eseguire facilmente questi controlli semplici utilizzando strumenti gratuiti: lo strumento di scansione delle vulnerabilità AD Purple Knight ^{,4 BloodHound5} e SharpHound (lo strumento di raccolta dati di BloodHound). Gli intrusi spesso utilizzano una combinazione di SharpHound nella rete della vittima e di BloodHound su un computer esterno per trovare il percorso di attacco più breve verso il gruppo degli amministratori di dominio. Entrambe le scansioni di vulnerabilità possono essere facilmente ripetute in un ambiente AD, senza alcuna configurazione speciale, anche se il funzionamento di BloodHound e delle sue dipendenze (ad esempio il database NEOj4 e il JDK Java) può richiedere un notevole sforzo. Purple Knight non richiede alcuna installazione oltre al download e alla decompressione del file .zip corrispondente.

Prima di regolare AdminSDHolder

Questo esempio esegue entrambe le scansioni come utente semplice, JustArootUser. Questo utente non ha diritti speciali di amministrazione in AD, ma è un utente autenticato nella foresta AD. Questo scenario imita le azioni di un intruso nell'ambiente AD. La prima scansione, effettuata con Purple Knight, mostra 29 indicatori di esposizione (IOE), ovvero vulnerabilità che un intruso potrebbe utilizzare per attaccare AD (vedere Figura 9). La scansione BloodHound/SharpHound elenca tutti gli account di amministrazione del dominio (cfr. Figura 10) a cui l'utente semplice può accedere e il percorso più breve per tale utente verso il gruppo degli amministratori del dominio (cfr. Figura 11).

Dopo la regolazione di AdminSDHolder

Dopo aver rimosso l'ACE per gli utenti autenticati e i gruppi di accesso compatibili con i sistemi pre-Windows 2000 dall'AdminSDHolder nel dominio root e aver aggiunto l'ACE per il gruppo SVC-ADconfig- AdminSDHolder-READ, è necessario attendere l'esecuzione del processo SDPROP e aggiornare gli oggetti privilegiati in modo che i loro attributi nTSecurityDescriptor siano aggiornati con quelli del modello AdminSDHolder. Questo processo richiede circa un'ora, ma è possibile attivare manualmente l'aggiornamento, come descritto più avanti nel documento. Dopo queste azioni, una scansione di Purple Knight trova solo 18 IOE - 11 vulnerabilità in meno rispetto a prima (vedi Figura 12). Ora che l'utente semplice non è più in grado di enumerare il gruppo admins del dominio o i suoi membri, una scansione BloodHound/SharpHound mostra che un intruso non sarebbe in grado di vedere i membri del gruppo o di individuare i percorsi di attacco verso di loro (vedere le Figure 13 e 14).

L'AD è ora sicuro?

Si noti che le vulnerabilità contro gli account privilegiati non scompaiono del tutto; semplicemente non sono facilmente visibili agli aggressori. Tuttavia, trovare i punti deboli per attaccare l'AD è diventato molto più difficile. Ad esempio, gli intrusi non possono più vedere quali utenti privilegiati sono adeguatamente protetti dal gruppo di utenti protetti, un gruppo di cui gli amministratori del dominio e gli altri utenti privilegiati devono far parte, poiché il gruppo fa ciò che il suo nome implica: proteggere gli account da vari vettori di attacco, come gli attacchi pass-the-hash. Con il blocco, gli intrusi non possono più pianificare un percorso di attacco dettagliato verso gli account più privilegiati e devono trovare altri modi per compromettere l'AD. Questi modi sono spesso più complessi. Se disponete di un monitoraggio adeguato dell'AD e degli endpoint, tali attacchi potrebbero far scattare un allarme anticipato per il team del centro operativo di sicurezza (SOC). Una combinazione di strumenti come Microsoft Defender for Identity, Semperis Directory Services Protector e SentinalOne XDR vi porterà molto lontano in questo settore.

Tuttavia, questo blocco delle autorizzazioni non significa che si possa rinunciare ad altre best practice di sicurezza. Dovete continuare a fare sul serio per quanto riguarda il tiering della vostra infrastruttura AD. Come minimo, ciò significa che gli account privilegiati più elevati non devono mai accedere a sistemi diversi dai controller di dominio (o da altri sistemi di livello 0 altamente affidabili). Nascondere l'accesso agli account privilegiati è solo uno degli aspetti di questo tipo di livellamento amministrativo e affronta in modo specifico le tecniche di ricognizione utilizzate dagli aggressori, come descritto nel framework MITRE^ATT&CK6.

Tenete presente che la scansione Purple Knight ha rilevato altre potenziali vulnerabilità, anche dopo il blocco dell'AdminSDHolder. IOE come "Principali non predefiniti con diritti di sincronizzazione DC sul dominio" o "Fiducia del dominio verso un dominio di terze parti senza quarantena", sono stati ancora rilevati tramite le autorizzazioni standard per gli utenti autenticati su altri oggetti del dominio e potrebbero ancora essere utilizzati dagli intrusi per pianificare un attacco.

Non avete ancora finito...

Ora che è stato creato il gruppo SVC- ADconfig-AdminSDHolder-READ, è necessario aggiungere al gruppo gli account appropriati che si desidera abilitare nuovamente alla lettura di oggetti privilegiati. Questi account includono gli account di servizio a basso privilegio per gli strumenti di sicurezza e di gestione e, in una foresta a più domini, gli amministratori di dominio di altri domini. Ad esempio, la Figura 15 mostra la vista dell'amministratore di dominio di un dominio figlio sugli oggetti della radice della foresta. Questo account, che si basava sulle autorizzazioni per gli utenti autenticati in AdminSDHolder, non ha più i diritti per leggere i gruppi privilegiati del dominio principale.

Questo problema si risolve facilmente aggiungendo il gruppo di amministratori del dominio figlio (globale) al gruppo locale SVC-ADconfig- AdminSDHolder-READ nel dominio radice. Una volta bloccato il dominio figlio, sarà necessario ripetere l'operazione per aggiungere il gruppo di amministratori del dominio radice al gruppo del dominio figlio; in alternativa, è possibile rendere il gruppo speciale AdminSDHolder un gruppo universale nel dominio radice, utilizzarlo su tutti i modelli AdminSDHolder della foresta e aggiungervi tutti i gruppi di amministratori del dominio. A voi la scelta. Non c'è bisogno di dirlo: non abilitate l'ereditarietà sul modello AdminSDHolder stesso. Ciò invaliderebbe l'intera funzione. Si noti inoltre che, così come si può usare AdminSDHolder per bloccare l'AD rimuovendo i permessi, gli intrusi possono anche usare l'oggetto per ottenere la persistenza in un AD compromesso. Per farlo, un intruso crea innanzitutto un utente poco appariscente e lo nasconde da qualche parte nella struttura della vostra OU. Quindi assegna a questo utente il permesso di reimpostare le password degli utenti nel modello AdminSDHolder. SDPROP fa il resto, consentendo all'intruso di mantenere il controllo. È chiaro che dovrete monitorare costantemente questo modello per verificare che non vi siano modifiche. Infine, come accennato in precedenza, è necessario ripulire i residui di amministratori e gruppi di amministratori che potrebbero essere stati generati nel corso degli anni.

Pulizia degli oggetti privilegiati: Trovare gli oggetti mal configurati

I passaggi seguenti consentono di individuare e ripulire gli oggetti che in precedenza erano considerati privilegiati da AD (e quindi 'timbrati' tramite SDPROP aggiornando la loro ACL e impostando l'attributo adminCount su '1') ma che non sono più membri di alcun gruppo privilegiato:

1. Mark all existing groups with admincount=1 via the telephoneNumber attribute (or some other unused attribute) so that you can more easily locate these groups again in a later stage of the clean-up: Get-ADObject-LDAPfilter “(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))”| Set-ADObject -Replace @ {telephoneNumber=“adminCount- Check-20220730”};
2. Cancella l'impostazione corrente dell'attributo adminCount per tutti i gruppi trovati in precedenza: Get- ADObject -LDAPfilter "(&(group Type:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))" | Set- ADObject -Clear "adminCount";
3. Assicurarsi che il processo SDPROP esegua il restamping di tutti gli oggetti rilevanti: SDPROP eseguirà un aggiornamento solo sugli oggetti rilevanti quando si verifica una modifica dell'ACL sulla destinazione o su AdminSDHolder. Il modo più semplice per assicurarsi che SDPROP esegua la sua magia è aggiungere manualmente un ACE fasullo (ad esempio, Consenti 'Operatori di backup' a 'Elenco oggetti') in AdminSDHolder, quindi rimuovere l'ACE dopo il controllo;
4. Forza l'esecuzione di SDPROP.

È possibile attendere fino a 60 minuti per l'esecuzione del processo SDPROP (cioè attendere che la pianificazione predefinita attivi l'operazione). Oppure potete forzare il DC con il ruolo PDCE FSMO ad avviare il processo SDPROP su vostro comando, inviando il comando RunProtectAdminGroupsTask al RootDSE del vostro dominio. Il metodo più semplice consiste nell'utilizzare LDP.exe come utente con privilegi di amministratore del dominio: scegliendo l'opzione 'esegui come amministratore' al momento dell'avvio, quindi:

• Avviare LDP.exe, scegliendo l'opzione Esegui come amministratore ;
• Selezionate Connessione > Connetti e inserite il DC con ruolo di emulatore PDC nel vostro dominio;
• Premere Ctrl + B o selezionare Connessione > Collegamento per effettuare il collegamento come utente attualmente connesso;
• Premere Ctrl + M o selezionare Sfoglia > Modifica per avviare un'operazione di modifica;
• Lasciare DN: vuoto e inserire RunProtectAdminGroupsTask come Attributo e 1 come Valore;
• Scegliere Operazione ADD e quindi fare clic su Invio o premere Alt + E;
• Quando viene visualizzata la voce [Add] RunProtectAdminGroupsTask:1 nell'elenco delle voci della finestra Modifica (vedere Figura 16), fare clic sul pulsante Esegui per avviare l'operazione ed eseguire il processo SDPROP.

5. Attendere che il processo SDPROP termini l'elaborazione. È possibile verificare che
   l'attributo adminCount=1 restituisca gli oggetti conosciuti che ci si aspetta (ad esempio i membri diretti del gruppo admins del dominio) oppure controllare il registro degli eventi di sicurezza sul PDCE e verificare che non vengano generati altri eventi con ID 4780 (categoria di attività: gestione account utente). Questi eventi mostrano quali oggetti sono stati ripristinati tramite il processo SDPROP.
6. Controllare quali gruppi non sono stati aggiornati utilizzando il flag precedente e aggiungendo un filtro per i gruppi in cui adminCount non è impostato su '1': Get- ADObject-LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648)(telephoneNumber=adminCount-Check-20220730)(!(adminCount=1)))”;
7. Il risultato dell'ultimo filtro è l'oggetto che si vuole ripulire al più presto. Essi contengono ancora l'ACL dell'impostazione AdminSDHolder nel momento in cui erano un gruppo privilegiato, il che significa anche che non ereditano le autorizzazioni eventualmente impostate a livello di UO;
8. Ripetere la stessa procedura con il computer e gli account utente. Probabilmente non si vuole usare l'attributo telephoneNumber come flag di controllo AdminSDHolder temporaneo sugli oggetti utente; forse facsimileTelephoneNumber non viene più usato. Il filtro LDAP corretto per trovare gli utenti privilegiati sarebbe: (&(objectClass=user) (objectCategory=person) (admincount=1));
9. Rimuovere l'ACE fasullo dall'oggetto AdminSDHolder dopo aver determinato gli oggetti di pulizia.

Pulizia degli oggetti privilegiati: Ripristino delle ACL sugli oggetti mal configurati

L'uso di PowerShell per ripristinare le ACL sugli oggetti interessati è un po' più complicato. Non esiste un semplice equivalente PowerShell dell'opzione "ripristina i valori predefiniti" disponibile nell'interfaccia utente delle impostazioni di sicurezza avanzate degli oggetti AD. I valori predefiniti sono memorizzati nello schema AD, in particolare nell'attributo defaultSecurityDescriptor della classe di oggetti interessata. Quando si fa clic sull'opzione di ripristino dei valori predefiniti nell'interfaccia utente della sicurezza, le autorizzazioni della classe vengono lette dallo schema e quindi applicate all'oggetto. Se gli oggetti configurati in modo errato sono pochi, questo metodo potrebbe essere il modo più semplice per risolverli. Ma cosa succede se si hanno molti oggetti di questo tipo in più posizioni?

Una possibilità è quella di utilizzare lo strumento DSACLS con l'opzione /resetDefaultDACL , che ripristina la sicurezza dell'oggetto ai valori predefiniti definiti nello schema; tuttavia, mescolare strumenti PowerShell e CLI può essere complicato. Sebbene Microsoft non abbia creato un equivalente PowerShell per elaborare un ripristino diretto dell'ACL ai valori predefiniti, è possibile utilizzare il cmdlet Get-ACL per prelevare l'ACL da un altro oggetto della stessa classe, quindi imprimere tale ACL sugli oggetti non configurati tramite il cmdlet Set-ACL. In pratica, è possibile copiare e incollare le ACL da un oggetto all'altro tramite i comandi PowerShell Get-ACL e Set-ACL. Poiché anche il descrittore defaultSecurityDescriptor dello schema viene letto e utilizzato alla creazione di qualsiasi nuovo oggetto di una classe specifica, è possibile creare un oggetto fittizio per copiare l'ACL. L'oggetto può anche essere un oggetto disabilitato, poiché il suo stato non fa parte dell'ACL.

Sfortunatamente, non è possibile inviare l'output del cmdlet Get-ADObject al cmdlet Set-ACL, poiché quest'ultimo deve ricevere il percorso dell'oggetto in un formato specifico: il nome distinto (DN) dell'oggetto preceduto da "AD:". Pertanto, è necessario scorrere l'elenco degli oggetti restituiti da Get-ADObject, formare il percorso corretto da utilizzare con Set-ACL ed eseguire il comando corrispondente nel ciclo. Il seguente script PowerShell reimposta le ACL degli oggetti di classe utente su quelle di un account fittizio appena creato, chiamato DefaultUserACL (l'attributo facsimileTelephoneNumber è stato precedentemente segnalato per aiutare a individuare gli account mal configurati).

#Set path for ACLing to AD
Set-Location AD:

#Grab ACL objects from a sample user- account (e.g. newly created account) 
$DefaultAcl = (Get-Acl “AD:CN= DefaultUserACL,OU=MyOU,DC=mydo m,DC=local”)

#query for the old AdminCount objects that must get their permissions reset $OldAdminCountObjects =

Get-ADObject -LDAPfilter 
“(&(objectClass=user)
(objectCategory=person)(facsimile TelephoneNumber=adminCount- Check-20220730)(!(adminCount=1)))”

#work through every object, grab the DN, create the proper ACL-DN-Path and set sample ACL on object
ForEach ($Object in $$OldAdminCountObjects)

{
$ACLpath = “AD:” + $Object. distinguishedName
write-host “Resetting permissions on”, 
$ACLpath
Set-Acl -Path $ACLpath -AclObject 
$DefaultAcl

#update flag of object
Set-ADObject -Identity $Object. 
distinguishedName -Replace 
@{facsimileTelephoneNumber=“ACL was reset 20220730”}
}

Quando si adatta lo script per i gruppi o i computer, assicurarsi di passare al filtro LDAP appropriato con l'attributo scelto per aiutare a localizzare gli oggetti. Se si preferisce, si può saltare la creazione di questi oggetti fittizi e usare la stessa logica di loop per eseguire gli strumenti DSACLS, usando il nome distinto dell'oggetto e l'opzione /resetDefaultDACL . Entrambi i metodi vi aiuteranno a ripulire correttamente i vecchi oggetti privilegiati nell'AD.

La sicurezza degli AD richiede un'attenzione costante

Questo documento intende aiutarvi a comprendere i vantaggi delle funzionalità di sicurezza AdminSDHolder e SDPROP integrate in AD, che proteggono gli oggetti più privilegiati all'interno dell'AD, e a capire come sia possibile bloccare ulteriormente tali oggetti per migliorare la protezione, con l'intento di combattere la fase di ricognizione di un attacco. Quanto più difficile sarà per gli intrusi raggiungere gli oggetti più privilegiati, tanto meglio sarà. Come descritto, questo metodo di hardening deve essere accompagnato da una corretta suddivisione degli account amministrativi e da un monitoraggio attivo dell'AD e degli endpoint. La protezione dell'AD è sempre stata importante e il continuo aumento degli attacchi ransomware ne sottolinea la necessità.

Risorse

1. Mueller, R. e Geelen, P. (settembre 2020 [novembre 2011]), "Active Directory: LDAP Syntax Filters", Microsoft, disponibile all'indirizzo https://social.technet. microsoft.com/wiki/contents/articles/5392.active- directory-ldap-syntax-filters.aspx (visitato il 25 settembre 2022).

2. Smith, R. (gennaio 2018), "Active Directory Security: Understanding the AdminSDHolder Object", Petri, disponibile all'indirizzo https://petri.com/ active-directory-security-understanding- AdminSDHolder-object (visitato il 25 settembre 2022).

3. Grillenmeier, G. (novembre 2021), "Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022", Semperis, disponibile all'indirizzo https://www.semperis.com/blog/security-risks- pre-windows-2000-compatibility-windows-2022/ (visitato il 25 settembre 2022).

4. Purple Knight, "Scopri le vulnerabilità di Active Directory prima che lo facciano gli aggressori", disponibile all'indirizzo https://www.semperis.com/purple-knight (consultato il 25 settembre 2022).

5. GitHub, "BloodHound 4.2.0 - Azure Refactor", disponibile all'indirizzo https://github.com/BloodHoundAD (visitato il 25 settembre 2022).

6. MITRE ATT&CK, "Reconnaissance", disponibile all'indirizzo https://attack.mitre.org/tactics/TA0043 (visitato il 25 settembre 2022).