Termini sensibili in description di Active Directory: DA e admin

I termini sensibili in description di Active Directory possono rivelare quali identità meritano maggiore attenzione anche quando il testo non contiene alcuna password. Questa guida distingue una revisione manuale ampia delle etichette DA, admin e privileged dai cinque pattern implementati da etc-collector, quindi mostra come inventariare, ripulire e ricontrollare le singole descrizioni.

Cosa rivelano i termini sensibili in description di Active Directory

Una descrizione come domain admin — backup operator indica la funzione di un account. L’inferenza di sicurezza è che un lettore potrebbe usarla per preselezionare possibili obiettivi. Non dimostra che l’account disponga effettivamente di diritti amministrativi. L’esempio è fittizio: non è un’osservazione in produzione né un attacco confermato.

La stessa distinzione vale per DA, le note sull’accesso di emergenza e le etichette di servizio. Un revisore potrebbe interpretarle come indizi sul ruolo di un’identità, ma la terminologia locale conta. admin può riferirsi ad attività amministrative esterne all’IT. service client può descrivere un reparto aziendale. Una vecchia descrizione può sopravvivere a un cambio di mansioni. Chiedete al proprietario cosa significhi il testo prima di considerarlo una prova di privilegi attuali.

Questo articolo riguarda l’identificazione degli obiettivi senza un segreto. Per password esatte, valori temporanei o indizi sulle credenziali, seguite la procedura di esposizione delle password, rotazione e indagine nei campi descrizione di AD. Eliminare un’etichetta di ruolo e rispondere a una credenziale esposta sono attività diverse; scoprire un segreto cambia la risposta necessaria.

Usate un registro di revisione che distingua il testo osservato, la sua interpretazione e le prove ancora necessarie. Per esempio, registrate separatamente «la descrizione contiene privileged» e «il proprietario ha confermato che si tratta di un’identità amministrativa». Lasciate aperto un caso irrisolto quando il proprietario è sconosciuto. Non trasformate una corrispondenza lessicale nell’affermazione che l’account sia compromesso, aggiri la MFA o appartenga a Domain Admins.

Come funziona l’accesso in lettura a description

La guida Microsoft agli account e ai gruppi privilegiati spiega che le ACL concedono comunemente ad Authenticated Users l’accesso alle informazioni generali degli oggetti. La sezione sui permessi include esplicitamente le proprietà generali degli utenti. Questo giustifica la verifica dell’esposizione di description con un’identità autenticata ordinaria, invece di presumere che il campo sia visibile soltanto agli amministratori. Autenticato non significa anonimo, e il permesso di lettura non implica il permesso di modifica.

La documentazione storica sugli attributi riservati descrive anche l’accesso in lettura predefinito agli attributi e il ruolo di READ_PROPERTY. L’accesso effettivo dipende dai permessi effettivi dell’oggetto. Una modifica locale dei permessi può cambiare ciò che riceve un lettore: verificate quindi il deployment invece di presumere che ogni oggetto segua i valori predefiniti.

Il riferimento allo schema di description identifica l’attributo LDAP come description, con searchFlags=0x00000000 e systemFlags=0x00000010. Le osservazioni distinguono le descrizioni a valore singolo per le classi gestite da SAM, inclusi i principali di sicurezza, dai possibili valori multipli sulle altre classi. Una revisione estesa degli oggetti deve conservare tali valori, invece di presumere che ogni descrizione sia una singola stringa di un account utente.

Per un confronto utile dell’esposizione, scegliete un oggetto noto con il campo valorizzato ed eseguite la stessa lettura delimitata con un lettore ordinario e un revisore autorizzato. Registrate l’identità usata, il controller di dominio, la base di ricerca, l’ora e gli eventuali errori. È una procedura di misurazione raccomandata, non un’affermazione che questi test siano stati eseguiti qui. Conservate il materiale di revisione in una posizione ad accesso controllato; un’attività di pulizia non deve diventare un nuovo elenco di identità sensibili ampiamente condiviso.

Rilevamento

Passaggio 1 — Inventariare le descrizioni utente valorizzate

I comandi seguenti sono adattati da Microsoft Learn, usando i parametri documentati di Get-ADUser e Get-ADObject. Non sono stati eseguiti su una directory per questo articolo. Sostituite il DN e il server di esempio, usate il modulo ActiveDirectory e selezionate il lettore di cui intendete misurare l’accesso. Ogni blocco è una misurazione distinta.

Iniziate dalle descrizioni utente valorizzate:

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Richiedere -Properties description richiede l’attributo; non concede l’accesso. Considerate una risposta vuota come qualcosa da indagare. Controllate l’ambito, i permessi e se viene restituito un oggetto noto con il campo valorizzato prima di dichiarare che la directory è priva di descrizioni sensibili.

Passaggio 2 — Separare gli account abilitati e disabilitati

L’esempio 5 di Get-ADUser di Microsoft usa il test LDAP bit per bit del bit 2 di userAccountControl per escludere gli account disabilitati. L’inventario seguente aggiunge la condizione su description e usa la forma NOT tra parentesi documentata nella sintassi dei filtri di ricerca LDAP di Microsoft:

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Per la revisione complementare, mantenete il test del bit senza negazione:

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Questo separa lo stato dell’account, non i suoi privilegi effettivi. Mantenete gli oggetti disabilitati nella coda di pulizia e rivedetene le descrizioni prima di qualsiasi riattivazione pianificata. Non interpretate il flag di disabilitazione come prova che nessuno possa leggere l’oggetto o che tutte le sessioni precedenti siano state invalidate.

Passaggio 3 — Rivedere le corrispondenze lessicali e le etichette locali più ampie

Una preselezione per sottostringhe può rendere gestibile la prima revisione:

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Questa preselezione LDAP non equivale alle regex del collector. Rivedete l’inventario originale delle descrizioni valorizzate cercando DA, break-glass, service, abbreviazioni locali e termini in altre lingue. Altrimenti una query ristretta può nascondere proprio le etichette che l’esercizio manuale intende valutare.

I pattern esatti del collector sono definiti in accounts/privileged/domain-admin-description.go:35–41, rispetto a public/internal/audit/detectors/ad/:

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

Tutti e cinque ignorano maiuscole e minuscole. Non hanno confini di parola né ancoraggi di inizio o fine, e \s* ammette zero spazi bianchi. Di conseguenza, domainadmin corrisponde al primo pattern e unprivileged all’ultimo. Quest’ultimo può descrivere l’opposto di ciò che il revisore si aspetta: esaminate il valore completo invece di trattare la sottostringa corrispondente come un verdetto.

Questi esiti derivano dai pattern del codice sorgente; non sono risultati riportati da un audit dal vivo. Mantenete tre conclusioni separate: testo corrispondente, funzione confermata dal proprietario e accesso verificato indipendentemente. Questa separazione rende spiegabile un falso positivo senza fingere che l’inventario più ampio sia completo.

Passaggio 4 — Estendere gli oggetti e monitorare le modifiche

Se le descrizioni di altre classi di oggetti rientrano nell’ambito, usate un inventario separato:

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Include qualsiasi classe di oggetto restituita con una descrizione valorizzata. È un’estensione manuale oltre i due rilevatori utente, non una prova che la loro copertura automatica includa quegli oggetti. Conservate i valori multipli di description dove lo schema li consente.

Per monitorare la reintroduzione del testo, il riferimento Microsoft all’Event ID 5136 documenta le modifiche della directory. Configurate Audit Directory Service Changes e una SACL Write appropriata per gli oggetti e gli attributi monitorati. Selezionate gli eventi in cui AttributeLDAPDisplayName=description; esaminate l’attore, l’oggetto e il valore. Dove sono disponibili sia gli eventi Value Deleted sia Value Added, correlateli usando OpCorrelationID e lo stesso oggetto e attributo.

L’assenza di un evento 5136 non dimostra che nessuno abbia letto il testo precedente. Questi eventi di modifica e l’inventario della postura rispondono a domande diverse: cosa è scritto ora e quale modifica sottoposta ad audit si è verificata.

Correzione (Remediation)

Passaggio 1 — Concordare le informazioni sostitutive

Per una divulgazione relativa soltanto al ruolo, il flusso raccomandato consiste nello spostare il contesto sensibile in un inventario o runbook con controlli di accesso appropriati. Fate approvare dal proprietario ciò che deve rimanere in AD. Un riferimento opaco come Managed record INV-01234 può conservare un rimando operativo senza nominare il privilegio o la procedura di emergenza. Anche il sistema referenziato deve controllare l’accesso; nascondere soltanto il nome di un record non equivale ad autorizzare.

Definite esempi di formulazioni accettabili e inaccettabili con il team che effettua il provisioning degli account. Includete le etichette locali che i controlli automatizzati non rilevano. Rivedete i modelli dell’helpdesk, le istruzioni di passaggio di consegne e chi può modificare le descrizioni, in modo che la stessa nota non venga ripristinata alla successiva manutenzione. Prendete una decisione per ogni oggetto invece di svuotare indiscriminatamente tutte le descrizioni valorizzate.

Passaggio 2 — Visualizzare in anteprima e confermare la modifica di un campo

Questi esempi adattano i parametri Clear, Description, WhatIf e Confirm documentati per Set-ADUser. L’esempio 4 svuota specificamente description. Scegliete la rimozione o la sostituzione per l’account selezionato.

Visualizzate in anteprima la rimozione:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

Dopo l’approvazione del proprietario, richiedete conferma per la rimozione effettiva:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

In alternativa, visualizzate in anteprima una sostituzione neutra:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Poi confermate separatamente quella sostituzione:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf non applica la modifica né dimostra la compatibilità delle applicazioni. Conservate l’identità dell’oggetto selezionato e l’azione approvata nel registro della modifica, quindi verificate il valore scritto. Questi comandi sono esempi documentati, non uno script globale di correzione né un resoconto di pulizia completata.

Passaggio 3 — Evitare scorciatoie di riservatezza non supportate

Se si considerano restrizioni locali di lettura, commissionate prima una revisione dei permessi effettivi e delle dipendenze. Le pagine Microsoft sui permessi e sugli attributi riservati spiegano le ACE, l’ereditarietà e i controlli di lettura; non convalidano una ricetta universale di ACL per questo deployment. Aggiungere un lettore dedicato non rimuove un’autorizzazione ampia già presente. Non rimuovete globalmente l’accesso in lettura di Authenticated Users senza verificare i sistemi che lo usano e la delega.

Preferite conservare le informazioni operative riservate in un sistema di riferimento protetto. Un’estensione dello schema o un modello di permessi riprogettato richiede un progetto distinto e testato. Ripulire le descrizioni riduce un indizio; non sostituisce la riduzione dei privilegi né nasconde tutte le altre proprietà della directory.

Convalida dopo la pulizia

Usate la lettura Identity documentata di Get-ADObject per esaminare l’oggetto selezionato dopo la scrittura autorizzata:

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

Il registro di accettazione raccomandato dovrebbe indicare se il valore previsto è presente, se il proprietario può usare il riferimento protetto e se gli strumenti legittimi funzionano ancora. Ricontrollate l’inventario con lo stesso lettore e lo stesso ambito usati inizialmente. Tenete conto della replica tra controller di dominio quando confrontate i server di directory, e conservate l’identità del DC affinché letture diverse possano essere investigate invece di essere ignorate.

Convalidate le etichette più ampie oltre alle corrispondenze regex. Un risultato automatizzato senza rilievi dopo aver sostituito domain admin con DA lascerebbe intatto l’indizio per selezionare gli obiettivi. Viceversa, una frase approvata contenente unprivileged può restare una corrispondenza lessicale con un contesto innocuo. Registrate esplicitamente quella decisione; non affermate che ogni corrispondenza restante rappresenti un accesso pericoloso o che ogni risultato negativo dimostri una formulazione sicura.

I diritti effettivi richiedono una revisione separata. La convalida della deriva degli accessi privilegiati esamina le appartenenze effettive, i percorsi di ACL delegate e i diritti di replica rispetto a una baseline. Usate questo flusso quando una descrizione suggerisce accesso amministrativo. Modificare la descrizione in sé non prova che i diritti dell’account siano stati ridotti.

Infine, verificate la configurazione di monitoraggio delle modifiche con una modifica di test approvata e controllate che i dati 5136 attesi raggiungano il processo di revisione. Rivedete ogni nuova formulazione sensibile con il proprietario. Se durante la convalida viene scoperto un segreto, indirizzatelo al flusso per l’esposizione di credenziali invece di chiudere il caso dopo aver modificato il campo. Definite il responsabile della prossima revisione affinché anche le descrizioni delle identità disabilitate vengano controllate prima della riattivazione.

Come EtcSec rileva questo problema

Le due implementazioni di etc-collector esaminate per questo articolo operano su data.Users e sulla stringa Description raccolta. Entrambe saltano le descrizioni vuote e si fermano dopo il primo pattern riconosciuto per un utente. Usano le stesse cinque regex, selezionando però popolazioni opposte in base allo stato dell’account.

Il predicato per gli account abilitati si trova alle righe 47–61 del primo file; quello per gli account disabilitati alle righe 43–57 del secondo. I rilievi contano gli utenti interessati. Le entità di dettaglio vengono allegate soltanto quando IncludeDetails è true e almeno un utente è interessato, alle righe 72–74 e 68–70 rispettivamente.

Nessuno dei due Detect() legge memberOf, verifica diritti effettivi, cerca password o analizza eventi della directory. L’identificatore DOMAIN_ADMIN_IN_DESCRIPTION descrive quindi un controllo di esposizione lessicale, non una prova che un utente interessato appartenga a Domain Admins. I valori High/Low sono classificazioni della politica del collector, non esiti di attacchi misurati né valutazioni di gravità Microsoft.

Trattate questi rilievi come elementi per la revisione: esaminate il testo, confermate la funzione con il proprietario, ripulite il campo approvato e rieseguite il controllo delimitato. Un rilievo lessicale negativo non dimostra l’assenza di etichette sensibili, ed eliminare un’etichetta non dimostra l’eliminazione dei privilegi.