gruppo AD vuoto: verifica dei gruppi privilegiati

Cosa accerta la verifica di un gruppo AD privilegiato vuoto

La verifica di un gruppo AD vuoto accerta se l’assenza di membri segnalata in un gruppo privilegiato è attendibile e intenzionale. Un risultato informativo è un punto di partenza per la verifica: identificare il gruppo, stabilire cosa abbia effettivamente letto la raccolta e registrare la decisione del responsabile. La chiusura del rilievo deve conservare queste prove, anziché modificare l’appartenenza solo per far scomparire il risultato.

Microsoft documenta diversi gruppi di operatori senza membri predefiniti, tra cui Account Operators, Backup Operators, Print Operators e Server Operators. Il loro stato vuoto può quindi essere previsto. Lo stesso riferimento spiega le capacità amministrative dei gruppi e le restrizioni sull’eliminazione dei gruppi incorporati. Consultare il riferimento sui gruppi di sicurezza di Active Directory per il gruppo in esame.

La distinzione utile è tra appartenenza sconosciuta, presenza di membri confermata e assenza intenzionale di membri confermata entro un ambito definito. Questi esiti richiedono attività successive diverse. Un attributo mancante, un comando non riuscito e un gruppo vuoto approvato non devono condividere la stessa etichetta di chiusura.

Perché le prove di appartenenza possono essere incomplete

L’attributo member dell’oggetto gruppo è multivalore e utilizza la sintassi dei nomi distinti. La sua lettura fornisce una vista a livello di attributo. La verifica deve considerare anche i gruppi annidati e, ove pertinente, l’appartenenza al gruppo primario registrata negli account.

La paginazione dei risultati LDAP e il recupero degli attributi per intervalli risolvono problemi diversi. La paginazione recupera lotti di oggetti; il recupero degli attributi per intervalli recupera lotti di valori da un singolo attributo multivalore. Un raccoglitore può completare la paginazione della ricerca dei gruppi senza riuscire a ricomporre i valori di appartenenza di un gruppo specifico. Durante la diagnosi di un’esportazione LDAP grezza, esaminare i nomi degli attributi restituiti e il completamento degli intervalli.

Il riferimento di schema primaryGroupID definisce questo attributo dell’account come identificatore relativo del suo gruppo primario. Un’esportazione limitata ai gruppi non esamina tale attributo degli account. Il nostro articolo sull’appartenenza tramite primaryGroupID omessa dalle esportazioni limitate a member spiega questo percorso di appartenenza distinto. Usarlo per comprendere i limiti della copertura; questa verifica non richiede di modificare primaryGroupID né di riprodurre la tecnica di abuso.

Prima di interpretare un risultato vuoto, annotare il DC esatto, il dominio, la base di ricerca, l’identità di raccolta e i limiti pertinenti. Conservare gli errori restituiti. Se questi elementi non possono essere accertati, contrassegnare l’appartenenza come sconosciuta e assegnare un responsabile del seguito. Non trasformare un errore operativo in un risultato vuoto ottenuto con successo.

Rilevamento: verificare il gruppo su un DC scelto

I seguenti esempi PowerShell utilizzano sintassi documentata da Microsoft Learn. Sono esempi di verifica in sola lettura adattati con valori di ambiente segnaposto, non comandi eseguiti in un laboratorio AD per questo articolo. Sostituire il server, il dominio e l’identità del gruppo prima di eseguirli da un sistema con il modulo ActiveDirectory disponibile.

Passaggio 1: accertare l’identità prima di contare i membri

Usare un DN, GUID o SID verificato, anziché presumere che il nome visualizzato identifichi in modo univoco il gruppo privilegiato previsto. Get-ADGroup supporta queste identità e il recupero esplicito delle proprietà:

$server = 'dc01.example.com'
$groupIdentity = 'CN=Schema Admins,CN=Users,DC=example,DC=com'
$group = Get-ADGroup -Identity $groupIdentity -Server $server -Properties member -ErrorAction Stop
$group | Select-Object DistinguishedName, SID, GroupScope, GroupCategory, member

Per questo esempio, selezionare un DC nel dominio radice della foresta che contiene Schema Admins e sostituire il DN di conseguenza. Registrare il SID restituito e confrontarlo con l’inventario autorevole dei gruppi. Se si esamina invece un gruppo di operatori, scegliere la sua identità e il suo dominio effettivi. Conservare la registrazione dell’identità anche quando la lettura dell’appartenenza è vuota.

Passaggio 2: conservare separatamente i risultati diretti e ricorsivi

Get-ADGroupMember accetta un server e un’identità di gruppo espliciti. La modalità ricorsiva espande la gerarchia fino ai membri privi di oggetti figli. Conservare il risultato non ricorsivo per vedere gli oggetti gruppo che un risultato appiattito non mantiene:

$direct = @(Get-ADGroupMember -Identity $group.DistinguishedName -Server $server -ErrorAction Stop)
$direct | Select-Object DistinguishedName, objectClass, SID

$recursive = @(Get-ADGroupMember -Identity $group.DistinguishedName -Server $server -Recursive -ErrorAction Stop)
$recursive | Select-Object DistinguishedName, objectClass, SID

Trattarli come insiemi di prove distinti, non come conteggi intercambiabili. Se un risultato diretto contiene un gruppo, esaminarne l’identità e l’appartenenza sul DC appropriato. Un gruppo annidato vuoto resta un membro diretto del proprio gruppo padre. Un output ricorsivo senza account non deve cancellare tale relazione dalla registrazione della verifica.

-ErrorAction Stop visualizza un errore e arresta il comando; converte gli errori non terminanti in errori terminanti. Se un comando non riesce, interrompere quella misurazione e conservare l’errore; non riutilizzare il contenuto di una variabile precedente come nuovo risultato. Un comando riuscito resta una prova per il server scelto e l’ambito leggibile, non una certificazione incondizionata di ogni dominio o relazione di trust. La documentazione Microsoft di Get-ADGroupMember esclude anche gli snapshot di Active Directory e i gruppi con membri in un’altra foresta quando tale foresta non dispone di Active Directory Web Service. Registrare ciascuna limitazione come lettura irrisolta, non come gruppo vuoto.

Passaggio 3: leggere primaryGroupID quando pertinente

Per un gruppo di sicurezza di dominio verificato, un controllo lato account può confrontare primaryGroupID con il RID di quel gruppo. Mantenere la query entro il dominio rappresentato dal SID del gruppo: il solo RID non è un’identità valida per l’intera foresta. Non applicare meccanicamente questo esempio di gruppo di dominio a un SID del contenitore Builtin.

L’esempio seguente utilizza i parametri documentati LDAPFilter, SearchBase, Server e Properties di Get-ADObject, combinati con la definizione di primaryGroupID nello schema:

$domainBase = 'DC=example,DC=com'
$rid = $group.SID.Value.Split('-')[-1]
$primaryMembers = @(Get-ADObject -LDAPFilter "(primaryGroupID=$rid)" -SearchBase $domainBase -SearchScope Subtree -Server $server -Properties primaryGroupID,objectSid -ErrorAction Stop)
$primaryMembers | Select-Object DistinguishedName, objectClass, objectSid, primaryGroupID

Questa è una query di verifica, non uno script di correzione del gruppo primario. Accertarne l’applicabilità e la popolazione leggibile prima di interpretare l’output. Per i gruppi di dominio annidati, considerare anche le prove pertinenti lato account a quei livelli; non presumere che il risultato ricorsivo del livello superiore risponda a ogni domanda sul gruppo primario. Se la popolazione o la visibilità degli attributi è incompleta, conservare tale limitazione nella conclusione.

Risolvere le lacune nelle prove prima della chiusura (Remediation)

La correzione consiste qui nel risolvere l’incertezza della verifica o nel documentare la configurazione prevista. Le modifiche di appartenenza richiedono una giustificazione separata. Usare la seguente sequenza dopo aver raccolto le prove di identità e appartenenza.

1. Risolvere le letture sconosciute. Esaminare l’errore registrato, l’identità di raccolta, la visibilità degli attributi, l’ambito di ricerca e i limiti degli oggetti. Quando LDAP grezzo restituisce attributi di appartenenza per intervalli, usare un percorso di recupero che gestisca gli intervalli e conservarne le prove di completamento. Ripetere la lettura pertinente sul DC registrato dopo aver risolto il problema di raccolta.
2. Confrontare i membri confermati. Se la verifica nativa restituisce membri mentre il raccoglitore segnala una lista vuota, conservare entrambi gli output con gli orari e le identità di raccolta. Esaminare la differenza prima di classificare il rilievo. Non rimuovere membri validi per forzare la concordanza con un’esportazione incompleta.
3. Documentare l’assenza intenzionale di membri. Chiedere al responsabile del gruppo di confermare la finalità operativa, lo stato vuoto approvato e il processo per qualsiasi uso futuro. Allegare l’identità verificata e l’ambito di lettura a tale decisione. Per un gruppo di operatori senza membri predefiniti, documentare perché lo stato attuale è coerente con il modello di amministrazione locale.
4. Segnalare un’assenza inattesa di membri. Se il responsabile si aspettava amministratori attivi o un gruppo annidato documentato, esaminare la discrepanza tramite il processo di gestione delle modifiche dell’organizzazione. Non ripopolare automaticamente il gruppo da una vecchia esportazione e non aggiungere un’identità di ampia portata come soluzione rapida.
5. Conservare la registrazione di chiusura. Includere il responsabile, la decisione, la data delle prove, il DC, il SID del gruppo, i comandi, gli errori e i limiti irrisolti. Definire quando la decisione deve essere riesaminata, per esempio in seguito a una modifica del modello di amministrazione o a una nuova discrepanza nelle prove raccolte.

La guida correlata sull’appartenenza eccessiva pericolosa nei gruppi privilegiati e sull’assenza intenzionale di membri in Schema Admins spiega perché riempire un gruppo privilegiato non sia una risposta appropriata a questa Info. Mantenere la sua trattazione del rischio di accesso separata dalla decisione sulla completezza delle prove affrontata qui.

Per esempio, chi esegue la verifica potrebbe ricevere una lista vuota dal raccoglitore per un gruppo di operatori. Se l’identità corrisponde, le letture indipendenti si completano nell’ambito richiesto e il responsabile conferma che non sono previsti operatori, la decisione può conservare lo stato vuoto. Se la stessa verifica incontra un errore di lettura irrisolto, l’esito corretto è un’appartenenza sconosciuta con un responsabile del seguito identificato. Si tratta di decisioni illustrative, non di risultati di test osservati.

Come EtcSec rileva questo caso

Il rilevatore GROUP_EMPTY_PRIVILEGED di EtcSec produce un rilievo Info per i gruppi privilegiati riconosciuti la cui lista Member raccolta soddisfa len(Member) == 0. La revisione di etc-collector esaminata è 20268a321609c193b79c5da6764f3f56950449cb; il rilevatore è public/internal/audit/detectors/ad/groups/privileged/empty-privileged.go.

Riconosce dieci nomi inglesi: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators, DnsAdmins e Group Policy Creator Owners. Confronta sAMAccountName senza distinzione tra maiuscole e minuscole, usa DisplayName quando sAMAccountName è vuoto, oppure cerca una sottostringa di nome cn= in qualsiasi punto del DN. Non verifica un SID né un confine di RDN. I gruppi rinominati o localizzati possono essere omessi; una sola corrispondenza del nome non accerta l’identità incorporata.

Il predicato non espande le appartenenze annidate e non calcola primaryGroupID. Nel provider LDAP esaminato, la raccolta dei gruppi usa per impostazione predefinita (objectClass=group) entro il BaseDN configurato e il limite di oggetti. Il parser legge esattamente member, senza ricomporre i valori member;range=.... L’assenza dell’attributo esatto diventa una lista vuota. La paginazione degli oggetti non corregge questa lacuna nel recupero degli attributi.

Queste osservazioni del codice accertano un rischio di interpretazione incompleta, non un falso positivo dimostrato in un ambiente AD reale. Non sono stati eseguiti test AD per questo articolo. La raccomandazione generica del rilevatore menziona la rimozione dei gruppi inutilizzati; non deve essere applicata ai gruppi incorporati. Usare l’Info per avviare la verifica di identità, completezza e decisione del responsabile descritta sopra.