Gruppi AD nidificati: Percorsi nascosti verso DA

Cos'è la nidificazione pericolosa dei gruppi?

La nidificazione pericolosa dei gruppi si verifica quando le catene di appartenenza ai gruppi di Active Directory creano privilegi effettivi che i revisori non intendevano concedere. Un utente, un account di servizio o un gruppo operativo potrebbe non essere membro diretto di Domain Admins, Enterprise Admins, Schema Admins o di un altro gruppo sensibile. Ma se è annidato tramite uno o più gruppi intermedi, l'account può comunque ereditare il contesto di autorizzazione risultante.

I gruppi di sicurezza di Active Directory sono oggetti di autorizzazione. Possono essere inseriti in liste di controllo accessi, ricevere diritti ed essere aggiunti ad altri gruppi. Questa nidificazione è utile per l'amministrazione, ma rende anche più difficile la revisione dei privilegi. L'appartenenza diretta risponde a una sola domanda: chi è esplicitamente membro di questo gruppo? L'appartenenza effettiva risponde alla domanda più importante: chi riceve questo privilegio una volta risolte tutte le appartenenze annidate?

Il problema è comune nei domini di lunga durata. I gruppi sopravvivono a migrazioni, riorganizzazioni, fusioni, ricostruzioni applicative, modifiche di emergenza e cambi di proprietario. Un gruppo creato per l'amministrazione dei server nel 2016 può essere ancora annidato in un percorso protetto nel 2026, anche se nessuno nel team attuale ricorda più il perché.

Come la nidificazione dei gruppi crea privilegi nascosti

Quando il Gruppo A è membro del Gruppo B, i membri del Gruppo A ereditano i permessi effettivi del Gruppo B. Se il Gruppo B è a sua volta membro di un gruppo Tier 0, i membri del Gruppo A dispongono ora di un percorso Tier 0, anche se nessuno di questi account compare come membro diretto del gruppo privilegiato finale.

Questo è il rischio centrale: i percorsi annidati nascondono il privilegio nel mezzo della catena. Una revisione diretta di Domain Admins può mostrare solo uno o due gruppi. Ma ciascuno di questi gruppi può contenere altri gruppi, account di servizio, utenti obsoleti o identità operative condivise.

Microsoft documenta gli account e i gruppi protetti in Active Directory, tra cui gruppi come Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators e altri. Questi gruppi meritano una revisione particolare perché l'appartenenza può concedere capacità amministrative potenti o attivare un comportamento da account protetto tramite AdminSDHolder.

Appartenenza diretta vs appartenenza effettiva

Una revisione utile distingue tre viste:

Solo la terza vista offre un piano di remediation. Se un utente helpdesk si risolve in Domain Admins attraverso cinque gruppi, rimuovere l'utente dall'ultimo gruppo non è la soluzione perché non ne è membro diretto. Bisogna rimuovere o riprogettare l'arco di gruppo che crea il percorso.

Dove si nascondono di solito i percorsi Tier 0 nascosti

I problemi di nidificazione pericolosa derivano solitamente da schemi prevedibili:

• gruppi di migrazione mantenuti dopo un consolidamento della directory
• gruppi di amministrazione server annidati verso l'alto per troubleshooting temporaneo
• account di backup, deployment o monitoraggio a cui è stato concesso ampio accesso durante un'interruzione
• gruppi operativi condivisi usati da più team senza un proprietario attuale
• gruppi di supporto applicativo che hanno ereditato diritti da vecchi gruppi admin
• gruppi creati per una regione o business unit e poi riutilizzati altrove
• vecchi gruppi di progetto che contengono ancora ex dipendenti o account di servizio

Una revisione pratica parte dall'alto del confine di privilegio e scende. Iniziate dai gruppi Tier 0 e dimostrate chi può raggiungerli in modo transitivo. Rivedere i gruppi in ordine alfabetico spreca tempo e di solito non individua il percorso che conta.

La catena di attacco

Passo 1 - Trovare il percorso annidato

L'attaccante o il valutatore mappa l'appartenenza ricorsiva a partire dai gruppi privilegiati. L'obiettivo è trovare un account più facile da compromettere rispetto a un Domain Admin diretto, ma che si risolva comunque in un percorso privilegiato.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Select-Object SamAccountName, ObjectClass, DistinguishedName

Passo 2 - Identificare l'anello più debole

L'anello più debole spesso non è un amministratore con nome. Può essere un account di servizio con un SPN, un account utente obsoleto, un account operatore condiviso o un grande gruppo di supporto. Il percorso annidato trasforma quell'identità più debole in un bersaglio di escalation significativo.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Where-Object {$_.objectClass -eq 'user'} |
  Get-ADUser -Properties Enabled, PasswordLastSet, ServicePrincipalName, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

Passo 3 - Usare l'autorizzazione esistente

Se l'identità compromessa eredita già i diritti richiesti, l'attaccante non ha bisogno di una nuova vulnerabilità in Active Directory. La directory concede già l'accesso. Per questo la nidificazione pericolosa è un problema di percorso di attacco, non solo di igiene.

Rilevamento

Event ID di Windows

Monitorate le modifiche ai gruppi di sicurezza sui controller di dominio. Microsoft documenta le famiglie di eventi chiave sotto Audit Security Group Management, e l'elenco di eventi richiesti da Microsoft Defender for Identity include anche le varianti "membro aggiunto" di questi eventi (4728, 4732, 4756).

Non limitatevi ad allertare sulle aggiunte dirette a Domain Admins. Allertate anche sulle modifiche a gruppi uno o due livelli sotto Tier 0, perché è lì che spesso si creano percorsi nascosti.

Controlli pratici di revisione

Usate controlli ricorrenti invece di una pulizia una tantum:

• esportare l'appartenenza ricorsiva dei gruppi protetti
• confrontare l'appartenenza diretta con quella effettiva
• segnalare account di servizio, account condivisi, utenti disabilitati e obsoleti nei percorsi ricorsivi
• identificare gruppi senza proprietario, senza descrizione o senza una data di revisione recente
• verificare se le modifiche ai gruppi erano approvate e attese
• monitorare se lo stesso arco di gruppo viene ricreato dopo la pulizia

Rimedio

L'obiettivo non è appiattire ogni gruppo. L'obiettivo è rimuovere l'ereditarietà Tier 0 nascosta e rendere i restanti percorsi privilegiati espliciti, dotati di proprietario e verificabili.

1. Verificare l'appartenenza ricorsiva a partire da Tier 0

Iniziate dai gruppi che definiscono il confine di privilegio.

$tier0Groups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Backup Operators')
$results = foreach ($group in $tier0Groups) {
  Get-ADGroupMember -Identity $group -Recursive | ForEach-Object {
    [PSCustomObject]@{
      RootGroup = $group
      Account = $_.SamAccountName
      Type = $_.ObjectClass
      DistinguishedName = $_.DistinguishedName
    }
  }
}
$results | Export-Csv tier0-recursive-membership.csv -NoTypeInformation

2. Trovare l'arco di gruppo che crea il percorso

Rimuovere un utente dal gruppo sbagliato non corregge il modello. Trovate la relazione di gruppo intermedia che concede il privilegio e decidete se è ancora necessaria. Se un gruppo di amministrazione server è annidato in un percorso domain admin, riprogettate il modello amministrativo invece di creare eccezioni account per account.

3. Ricostruire esplicitamente i confini dei tier

L'obiettivo è impedire che gruppi di tier inferiore ereditino diritti di tier superiore tramite nidificazione di comodo. Un gruppo helpdesk non dovrebbe diventare privilegiato solo perché è stato annidato in un gruppo admin server successivamente annidato più in alto.

4. Assegnare ownership e cadenza di revisione

Ogni gruppo vicino a Tier 0 dovrebbe avere un proprietario, uno scopo e una cadenza di revisione. Se nessuno riesce a spiegare perché un gruppo è annidato in un percorso privilegiato, rimuovetelo o mettetelo in quarantena finché la dipendenza non è dimostrata. Documentate le eccezioni come eccezioni, non come architettura normale.

Cosa non fare

Non rimediate alla nidificazione pericolosa eliminando gruppi alla cieca. Alcuni gruppi potrebbero ancora supportare l'amministrazione applicativa, i job di backup o i flussi operativi. La sequenza corretta è identificare il percorso esatto, confermare la proprietà, rimuovere gli archi non necessari e testare il flusso dipendente. Evitate anche di sostituire il privilegio annidato con l'appartenenza utente diretta nello stesso gruppo protetto. Questo può rendere il percorso più visibile, ma non riduce il privilegio. L'obiettivo è ridurre il privilegio effettivo e migliorare la responsabilità, non semplicemente accorciare l'elenco dei gruppi.

Validazione dopo la pulizia

Dopo la remediation, dimostrate che il percorso è scomparso:

• rieseguire gli export di appartenenza ricorsiva per i gruppi protetti
• confermare che nessun account condiviso, account di servizio, account disabilitato o utente obsoleto si risolva più in Tier 0
• rivedere gli eventi 4728, 4732, 4756, 4735, 4737 e 4755 durante e dopo la remediation
• confermare che i gruppi annidati rimanenti abbiano un proprietario e uno scopo documentato
• verificare che gli avvisi di monitoraggio scattino sulle modifiche ai gruppi sotto il confine privilegiato
• confrontare i risultati del grafo prima e dopo la pulizia in modo che il percorso rimosso sia chiaro

L'obiettivo della validazione è semplice: l'ambiente non dovrebbe dipendere da un'ereditarietà di privilegio nascosta che solo una query sul grafo può spiegare a posteriori.

Come EtcSec rileva questo

EtcSec mappa il grafo di gruppi effettivo invece di affidarsi solo all'appartenenza diretta. Questo rende il risultato utile per due motivi: mostra il percorso di privilegio completo e aiuta i revisori a identificare quale oggetto della catena sia più facile da compromettere per un attaccante.

Letture correlate

Esaminate la nidificazione pericolosa dei gruppi insieme a Percorsi di Attacco AD: Catene di Configurazioni Errate, Abuso ACL e DCSync: I Percorsi Silenziosi verso Domain Admin, Attacchi alle Trust AD: Dal Dominio Figlio alla Radice della Foresta, Configurazioni Errate GPO: Come i Criteri di Gruppo Diventano un Vettore di Attacco, e Account Privilegiati Obsoleti: Rischio Nascosto in Active Directory. Il privilegio annidato conta di solito perché si collega a un altro percorso di attacco.

Riferimenti principali

• Active Directory Security Groups
• Protected accounts and groups in Active Directory
• Audit Security Group Management
• 4732: A member was added to a security-enabled local group
• Configure Windows event auditing - Microsoft Defender for Identity