GPO ACL debole, OU Tier 0, Active Directory: il pivot che annulla il modello a tier che avete appena costruito

GPO ACL Debole, OU Tier 0, Active Directory: Cosa Significa Davvero Questa Configurazione Errata

GPO ACL debole, OU Tier 0, Active Directory: questo collegamento è il controllo che la maggior parte dei team dimentica di verificare una volta che il proprio modello a tier è già stato distribuito. Creare un'unità organizzativa Tier 0 dedicata e bloccarvi l'ereditarietà delle policy è un passaggio ben noto — è R58 e R59 di ANSSI-PA-099, la guida dell'agenzia francese per la cybersicurezza sulla messa in sicurezza dell'amministrazione di Active Directory (vedi il nostro riepilogo delle raccomandazioni ANSSI per l'insieme più ampio). R58 richiede un'OU dedicata che raggruppi gli oggetti Tier 0 — con un'eccezione esplicita: gli account computer dei domain controller e gli utenti e gruppi predefiniti restano nelle rispettive OU predefinite; R59 richiede che questa OU "limiti le policy di sicurezza applicabili all'unità organizzativa Tier 0" bloccando l'ereditarietà e assicurando che ogni GPO collegato o applicato ad essa sia dedicato alle risorse Tier 0 e modificabile solo dagli amministratori Tier 0.

Quella seconda metà di R59 — "modificabile solo dagli amministratori Tier 0" — è la parte che silenziosamente esce dal perimetro una volta costruita la struttura delle OU. Bloccare l'ereditarietà chiude un primo piano di controllo: quali policy fluiscono verso il basso sull'OU. Non dice nulla su un secondo piano di controllo, indipendente: chi può scrivere sugli oggetti GPO già collegati a quell'OU. Un GPO è a sua volta un oggetto di Active Directory con una propria access control list. Se quella ACL concede diritti di modifica a qualcuno al di sotto del Tier 0 — un gruppo di helpdesk, una delega di qualcuno che se n'è andato e che non è mai stata ripulita, un gruppo di sicurezza annidato un livello più in basso del previsto — quel principal poco affidabile può riscrivere il contenuto della policy, e Active Directory applicherà le sue modifiche a ogni computer e account Tier 0 raggiunto dal GPO, blocco dell'ereditarietà o meno.

Si tratta di un fallimento più circoscritto e specifico rispetto alla questione generale di come viene costruito un modello a tier in primo luogo. Un team può implementare correttamente la gerarchia di OU prevista da R58, superare ogni revisione della struttura delle OU stessa, e comunque distribuire un'OU Tier 0 con un GPO dai permessi deboli collegato ad essa — perché l'ACL propria del GPO è un oggetto separato che nessuno ha pensato di ricontrollare dopo che il modello a tier è stato dichiarato completo.

Come Funziona

Un Group Policy Object sono in realtà due artefatti mantenuti sincronizzati: il Group Policy Container (GPC), un oggetto Active Directory sotto CN=Policies,CN=System,DC=<dominio> che porta il security descriptor proprio del GPO, e il Group Policy Template (GPT), la cartella corrispondente nella condivisione SYSVOL che contiene i file di impostazioni effettivi. Il collegamento tra un GPO e un'OU è un terzo elemento separato: l'attributo gPLink sull'OU, che si limita a referenziare il GPO tramite il suo GUID.

La documentazione Microsoft sul processamento delle Group Policy conferma la meccanica dietro il requisito "blocco dell'ereditarietà" di R59: ogni OU ha un attributo GPOptions che può bloccare le policy provenienti da contenitori di livello superiore, ma "sebbene l'ereditarietà bloccata impedisca alla maggior parte delle impostazioni di applicarsi a un'OU, ciò non influisce sulle impostazioni applicate tramite GPO con l'opzione forzata (enforced)" — enforced è una proprietà del collegamento e ha la precedenza sul blocco dell'ereditarietà, che è una proprietà del contenitore. È esattamente per questo che R59 richiede anche di verificare che nessun GPO applicato in modalità forzata da un'OU padre sia modificabile da chiunque al di fuori del Tier 0: il blocco dell'ereditarietà da solo non ferma il problema di permessi di un GPO forzato, ma solo quello a priorità normale.

Nulla di tutto ciò tocca l'ACL propria dell'oggetto GPC. Per impostazione predefinita, solo Domain Admins, Enterprise Admins e SYSTEM detengono diritti di modifica su un GPO — il riferimento Microsoft Get-GPPermission mostra esattamente questo insieme predefinito nel proprio esempio di output, e denomina questo livello di permesso GpoEditDeleteModifySecurity. Le ACL deboli emergono per deriva, non per una singola decisione sbagliata: un GPO viene creato da un amministratore di tier inferiore tramite GPMC e viene successivamente collegato all'OU Tier 0 senza che nessuno riverifichi chi detiene ancora diritti di modifica su di esso, oppure una delega di helpdesk limitata a un GPO specifico per un compito specifico non viene mai revocata, oppure un gruppo di sicurezza destinato al Tier 1 riceve accidentalmente "Edit settings" durante una pulizia dei permessi.

La Catena di Attacco

Fase 1 — Trovare l'anello debole

Un attaccante (o un auditor) enumera l'ACL di ogni GPO alla ricerca di concessioni GenericAll, GenericWrite, WriteDacl o WriteOwner a un principal al di sotto del Tier 0, poi incrocia il risultato con il gPLink di ogni GPO su un'OU Tier 0 — direttamente, oppure tramite un GPO forzato da un'OU padre. Get-GPPermission -Guid <GUID del GPO> -All restituisce un solo GPO alla volta — -Guid (o -Name) è obbligatorio, quindi la scansione deve iterare invece di essere eseguita una sola volta: qualsiasi trustee la cui Permission risulti GpoEditDeleteModifySecurity — o una ACE personalizzata che il cmdlet non riesce a mappare su un livello nominato — e che non sia un principal Tier 0 riconosciuto è un riscontro.

Fase 2 — Trasformare la policy in un'arma

La documentazione BloodHound di SpecterOps sull'edge di abuso GenericWrite descrive la tecnica standard: aprire il GPO nel Group Policy Management Editor e aggiungere "una policy malevola che consenta il targeting a livello di elemento, come una nuova attività pianificata immediata" — una funzionalità delle Group Policy Preferences che esegue un comando arbitrario come NT AUTHORITY\SYSTEM al successivo aggiornamento della policy. Gli strumenti nominati per questo — SharpGPOAbuse su Windows, pyGPOAbuse su Linux — automatizzano la scrittura di quell'XML di attività pianificata nel GPO. La stessa documentazione segnala un limite importante: GenericWrite limitato a "solo questo oggetto", senza altre ACE, non basta da solo — le impostazioni del GPT risiedono in SYSVOL, quindi l'attaccante ha bisogno anche dell'accesso in scrittura alla cartella SYSVOL di quel GPO per modificare realmente ciò che viene distribuito. In pratica, i due percorsi di accesso vengono concessi insieme abbastanza spesso da rendere questo un vero percorso di attacco, non solo teorico — ma è anche il dettaglio che separa un vero GPO con ACL debole da un falso positivo.

Fase 3 — Attendere la finestra di aggiornamento

Non è richiesto alcun accesso ulteriore dopo la modifica. Secondo la documentazione Microsoft citata sopra, i computer membri del dominio e i server ricontrollano le modifiche ai GPO ogni 90 minuti con uno scarto casuale fino a 30 minuti, mentre i domain controller controllano ogni cinque. Il contenuto SYSVOL stesso si replica tra i domain controller secondo una pianificazione DFSR che può scendere fino a 15 minuti all'interno dello stesso sito. Una volta applicata la modifica, ogni computer Tier 0 raggiunto dal GPO — per un GPO collegato all'OU Tier 0, questo significa le workstation di amministrazione Tier 0, gli account di amministrazione e gli account di servizio lì ospitati — esegue l'attività dell'attaccante come SYSTEM secondo la propria pianificazione, senza bisogno di alcuna interazione. I domain controller sono un salto separato: R58 mantiene i loro account computer nell'OU predefinita OU=Domain Controllers, quindi un GPO con ACL debole raggiunge un DC solo se è anch'esso collegato a quell'OU o applicato a un contenitore padre in modalità forzata.

Rilevamento

L'Event ID 5136 ("Un oggetto del servizio directory è stato modificato") si attiva nella sottocategoria Audit Directory Service Changes ogni volta che viene modificato un oggetto con una voce SACL appropriata per l'audit di "Scrittura" — non comparirà affatto a meno che quella SACL non sia configurata in anticipo sugli oggetti contenitore GPO (o ereditata da CN=Policies,CN=System). Il campo AttributeLDAPDisplayName dell'evento è ciò che consente a un SIEM di distinguere una normale modifica di policy da una modifica del security descriptor; filtrare su ObjectClass=groupPolicyContainer isola l'attività GPO da tutte le altre modifiche al servizio directory che questo evento copre.

# Sweep every GPO for trustees with edit/full-control rights, then
# cross-reference against GPOs linked to a Tier 0 OU
Get-GPO -All | ForEach-Object {
    $gpo = $_   # keep the GPO: inside the nested pipeline $_ is a GPPermission
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -match 'GpoEdit|GpoCustom' } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, Trustee, TrusteeType, Permission
}

Remediation

1. Censire l'esposizione. Elencate ogni GPO collegato all'OU Tier 0, più qualsiasi GPO applicato in modalità forzata da un'OU padre — secondo ANSSI-PA-099 R59, entrambi contano. (Get-GPInheritance -Target "<DN dell'OU Tier0>").GpoLinks restituisce l'insieme collegato direttamente; controllate manualmente le OU padre per i collegamenti forzati.
2. Esaminare la scheda Delega. Per ogni GPO, apritelo in GPMC e controllate la scheda Delega, poi cliccate su Avanzate per vedere l'ACL grezza invece dei livelli di permesso riassunti — la guida Microsoft sulla delega documenta questo come il percorso supportato per aggiungere, rimuovere o ispezionare i permessi Edit settings, delete, and modify security su un GPO.
3. Rimuovere qualsiasi trustee esterno al Tier 0 che detenga un livello Edit, Edit/Delete/Modify Security, o Custom. Confermate che la cartella SYSVOL corrispondente a quel GPO non conceda separatamente lo stesso accesso in scrittura allo stesso principal — l'ACL AD e l'ACL SYSVOL sono due controlli distinti su due oggetti distinti.
4. Riverificare l'altra metà di R59. Confermate che l'ereditarietà sia ancora bloccata sull'OU Tier 0, che la Default Domain Policy vi sia collegata con la priorità più bassa come specifica R59, e che nessun GPO forzato da un'OU padre porti ancora un'ACL debole.
5. Rieseguire la scansione della sezione Rilevamento su base periodica, non una sola volta — i permessi dei GPO derivano allo stesso modo delle appartenenze ai gruppi, tramite deleghe una tantum che nessuno si ricorda di revocare. Questo controllo appartiene alla stessa rotazione di un audit di sicurezza di Active Directory più ampio, non a una pulizia una tantum.

Come EtcSec Rileva Questo

Il catalogo di conformità di EtcSec traccia esattamente questa modalità di fallimento come ANSSI_R59_TIER0_OU_POLICIES: enumera ogni collegamento GPO abilitato, segnala quelli che puntano a un GPO la cui ACL propria concede accesso in scrittura a un principal non amministratore, e riporta un riscontro per ogni collegamento che ricade su un'OU Tier 0. È abbinato a GPO_DANGEROUS_PERMISSIONS per il caso generale di ACL GPO deboli ovunque nel dominio, PATH_GPO_TO_DA per la vista percorso di attacco della stessa esposizione, e ANSSI_R15_TIER_MODEL_VIOLATION per la questione più ampia di se il modello a tier stesso sia intatto.