Audit ACL Active Directory DPAPI Tombstone Schema: 3 diritti che nessuno controlla

Cos'è un audit dei diritti ACL di Active Directory DPAPI, Tombstone, Schema?

Un audit completo dei diritti ACL di Active Directory DPAPI, Tombstone, Schema controlla molto più di GenericAll e DCSync. Un tipico audit ACL — sia esso manuale con dsacls e PowerView, o con uno strumento come BloodHound — si concentra su un elenco ben noto: GenericAll, GenericWrite, WriteDACL, WriteOwner, e i diritti di replica dietro DCSync. Quell'elenco è corretto, ma non è completo. Altri tre diritti collegati alle ACL sono altrettanto pericolosi e raramente compaiono in una checklist: l'accesso non predefinito alla chiave di backup di dominio DPAPI, il diritto esteso Reanimate-Tombstones, e i permessi non standard sullo schema AD. Sono pericolosi per lo stesso motivo di fondo di GenericAll — un principal al di fuori del livello amministrativo previsto può usarli per leggere segreti, resuscitare oggetti obsoleti, o impiantare un meccanismo di persistenza che sopravvive all'eliminazione degli oggetti e ai reset delle password — ma non compaiono nella maggior parte dei contenuti sull'abuso di ACL perché non sono ACE ordinarie su oggetti utente o computer. Questo articolo illustra cosa concede realmente ciascun diritto, come viene abusato, e come rilevarlo e correggerlo.

Per i percorsi più comunemente controllati, vedi Abuso ACL e DCSync: I Percorsi Silenziosi verso Domain Admin.

Diritto n. 1 — Accesso non predefinito alla chiave di backup di dominio DPAPI

La Data Protection API (DPAPI) di Windows protegge i segreti a riposo — password del browser salvate, profili Wi-Fi, credenziali RDP, certificati EFS, voci di Gestione credenziali — cifrandoli con una chiave derivata dalla password dell'utente. In un dominio, la chiave master DPAPI di ogni utente viene anche cifrata con una chiave di backup DPAPI a livello di dominio, in modo che una password utente persa o scaduta non significhi una perdita permanente di dati. Quella chiave di backup viene generata una sola volta, alla creazione del dominio, e memorizzata come segreti LSA BCKUPKEY_* replicati su ogni controller di dominio (Microsoft Learn: chiavi di backup DPAPI sui controller di dominio AD).

Come gli attaccanti recuperano la chiave di backup

Per impostazione predefinita, recuperare la chiave di backup richiede diritti equivalenti a Domain Admin sull'oggetto di policy LSA. Strumenti come Mimikatz (lsadump::backupkeys) e SharpDPAPI la estraggono tramite le chiamate MS-LSAD/LSARPC LsaOpenPolicy / LsaRetrievePrivateData; DSInternals documenta lo stesso percorso di estrazione con Get-LsaBackupKey (DSInternals: recuperare le chiavi di backup DPAPI da Active Directory). La domanda dell'audit non è «la chiave di backup esiste» — esiste sempre — ma «quali principal, oltre ai Domain Admin, detengono attualmente diritti che permettono di leggerla». Quell'accesso viene solitamente concesso in modo indiretto: diritti LSA delegati, una GPO troppo permissiva, o un account di servizio aggiunto a un gruppo privilegiato per un motivo non correlato.

Diritto n. 2 — Il diritto esteso Reanimate-Tombstones

Active Directory estende il modello standard di ACE con i control access right — permessi non legati a uno specifico attributo o bit della maschera di accesso, ma identificati da un GUID e verificati sull'intero oggetto. Reanimate-Tombstones (GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f) è uno di questi: consente a chi lo detiene di ripristinare un oggetto eliminato (tombstoned) ovunque in un naming context, e per impostazione predefinita viene concesso solo alla radice del naming context a Domain Admin / Enterprise Admin (Microsoft: diritto esteso Reanimate-Tombstones, Microsoft: ripristino di oggetti eliminati).

Perché una concessione delegata è un percorso di privilege escalation

Il caso di abuso è sottile ma reale: un oggetto tombstoned o riciclato può conservare la maggior parte dei suoi attributi originali — SID history, appartenenze a gruppi, SPN — per la durata del tombstone (o indefinitamente nel Cestino di AD se abilitato ma mai svuotato). Un principal a cui è stato delegato Reanimate-Tombstones al di fuori del livello amministrativo predefinito può ripristinare un account o un gruppo privilegiato eliminato, resuscitando di fatto un percorso di accesso ritenuto chiuso. La ricerca di CravateRouge sul Cestino di AD come superficie di privilege escalation documenta scenari concreti (Have You Looked in the Trash? Unearthing Privilege Escalations from the AD Recycle Bin). Questo diritto è facile da trascurare proprio perché gli auditor esaminano le ACL attuali degli oggetti e dimenticano di controllare i diritti estesi delegati alla radice della partizione, dove questo risiede. Per saperne di più su come questo tipo di accesso delegato si accumula nel tempo, vedi Deriva degli Accessi Privilegiati in Active Directory.

Diritto n. 3 — Permessi non standard sullo schema AD

Il naming context dello schema definisce tutte le classi e gli attributi della foresta. Per impostazione predefinita, l'accesso in scrittura è limitato al gruppo Schema Admins (più gli Enterprise Admins alla radice della foresta); questo è intenzionale, perché le modifiche allo schema riguardano l'intera foresta e sono in gran parte irreversibili — gli attributi e le classi possono essere disattivati ma non eliminati (Semperis: NSA Top Ten Cybersecurity Misconfigurations — An AD Perspective).

Perché l'accesso in scrittura allo schema è una primitiva di persistenza a livello di foresta

L'accesso in scrittura allo schema è un premio più grande di quanto sembri. Un attributo in particolare, defaultSecurityDescriptor su un oggetto classSchema, definisce il modello di DACL applicato a ogni oggetto futuro creato di quella classe — il che significa che un attaccante con accesso in scrittura allo schema può incorporare una ACE backdoor (ad esempio, concedendo WriteDACL a un account con pochi privilegi) nel security descriptor predefinito della classe user o group, così che ogni account o gruppo creato successivamente eredita permessi controllati dall'attaccante fin dal momento della creazione. Questa è una primitiva di persistenza ben documentata, che attraversa anche i confini di dominio all'interno di una foresta poiché lo schema è a livello di foresta (itm8: Schema change trust attack — from child to parent), (BorderGate: Active Directory Schema Modification Attacks). In pratica, le ACE di schema non standard sono solitamente residui di installer di prodotti di terze parti (Exchange, alcuni strumenti di backup/gestione AD) che hanno richiesto diritti di schema più ampi del necessario durante l'installazione e non sono mai stati rimossi.

Rilevamento

Tutti e tre i diritti richiedono che le sottocategorie corrette della audit policy siano abilitate sui controller di dominio prima che generino qualcosa di utile nel log di sicurezza.

L'audit dell'evento 4662 per la chiave di backup richiede l'audit dei successi su Audit Other Object Access Events abilitato su ogni DC — è disattivato per impostazione predefinita (DSInternals: rilevare il furto della chiave di backup DPAPI). La sottocategoria Directory Service Changes genera gli eventi 5136 (modificato), 5137 (creato), 5138 (ripristinato), 5139 (spostato) e 5141 (eliminato) per qualsiasi oggetto che porti una voce SACL corrispondente (Microsoft: evento 5136 — A directory service object was modified) — ma solo per gli oggetti e gli attributi su cui è stata esplicitamente impostata una SACL, quindi sia la radice del naming context sia il container Schema devono riceverne una manualmente (ADSI Edit → Properties → Security → Advanced → Auditing).

Altri Event ID da configurare insieme a questi tre sono trattati in Monitoraggio di Active Directory: gli Event ID di sicurezza che contano.

Remediation

Correggere l'esposizione della chiave di backup DPAPI

Non esiste un modo supportato per ruotare la chiave di backup di dominio (Microsoft Learn: chiavi di backup DPAPI sui controller di dominio AD), quindi trattate l'accesso ad essa con lo stesso rigore del krbtgt. Rivedete regolarmente i diritti LSA delegati e l'appartenenza ai gruppi privilegiati; se la chiave viene confermata compromessa, la guida di recupero di Microsoft è sufficientemente limitata da richiedere che un piano completo di recupero di foresta/dominio esista già prima che ve ne sia bisogno (SANS: Critical Confusion — Microsoft's Domain Compromise Recovery Guidance).

Correggere la delega di Reanimate-Tombstones

Elencate le ACE su ogni radice di naming context per il control access right GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f (dsacls o Get-ObjectAcl -ResolveGUIDs di PowerView). Rimuovete qualsiasi concessione al di fuori di Domain Admins/Enterprise Admins, e richiedete un ticket di change documentato per qualsiasi ripristino delegato legittimo.

Correggere i permessi non standard dello schema

Eseguite dsacls su CN=Schema,CN=Configuration,DC=<forest-root> e confermate che l'accesso in scrittura sia limitato a Schema Admins (ed Enterprise Admins alla radice della foresta). Prestate particolare attenzione a qualsiasi ACE che tocchi defaultSecurityDescriptor sugli oggetti classSchema user, group o computer — è l'obiettivo di maggior valore per una backdoor di persistenza.

Aggiungere SACL per rilevare la deriva futura

Aggiungete SACL sulla radice del naming context e sul container Schema come descritto nella sezione Rilevamento sopra, in modo che qualsiasi deriva futura compaia nel log di sicurezza invece di essere scoperta durante il prossimo audit manuale. Per una baseline di hardening più ampia oltre questi tre diritti, vedi Messa in sicurezza di Active Directory: cosa blindare per primo e come validarlo e Quali sono le configurazioni di sicurezza errate più comuni di Active Directory?.

Come EtcSec rileva questo

EtcSec controlla tutti e tre questi elementi durante ogni audit di Active Directory: DPAPI_KEY_NON_DEFAULT_ACCESS segnala i principal che detengono diritti sulla chiave di backup di dominio al di fuori del livello amministrativo previsto, REANIMATE_TOMBSTONES_RIGHT segnala concessioni non predefinite del control access right alla radice del naming context, e SCHEMA_NON_STANDARD_PERMISSIONS segnala ACE sul naming context dello schema al di fuori di Schema Admins/Enterprise Admins. Questi si affiancano al controllo più noto ACL_GENERICALL, così che lo stesso audit copra sia i percorsi di abuso ACL ben noti sia quelli che la maggior parte degli strumenti tralascia.