Account privilegiati Active Directory: Protected Users, delega e lacune negli account di servizio

Cos'è la protezione degli account privilegiati di Active Directory (Protected Users e delega)

Gli account Domain Admins, Enterprise Admins e altri account Tier 0 sono quelli di cui un attaccante ha bisogno per compromettere completamente un dominio. Per gli account privilegiati di Active Directory, tre controlli nativi e indipendenti svolgono la maggior parte del lavoro di protezione reale: l'appartenenza al gruppo di sicurezza Protected Users, il flag di delega "questo account è sensibile e non può essere delegato", e la regola di igiene di base secondo cui gli account di servizio non devono trovarsi in gruppi privilegiati. In aggiunta, l'attributo SID History — pensato per le migrazioni di dominio — può concedere silenziosamente accesso privilegiato se non viene mai controllato.

Nulla di tutto ciò è esotico. Sono funzionalità AD native e pronte all'uso. La lacuna trattata in questo articolo non è una patch mancante né uno zero-day: si tratta semplicemente di controlli non attivati per gli account che ne avrebbero bisogno, motivo per cui continua a comparire come una delle principali criticità nelle valutazioni di sicurezza di Active Directory. Ciascuna lacuna descritta di seguito è sfruttabile in modo indipendente, e nessuna richiede strumenti residenti in memoria o process injection: si tratta di errori di configurazione a livello di attributo, visibili a chiunque interroghi la directory nel modo corretto.

Come funziona

Protected Users: creato ma inutilizzato

Il gruppo di sicurezza globale Protected Users, introdotto con Windows Server 2012 R2, applica protezioni non configurabili a qualsiasi account che vi venga aggiunto. Secondo la documentazione Microsoft su Protected Users, i membri non possono autenticarsi con NTLM, non possono usare DES o RC4 per la pre-autenticazione Kerberos, non possono essere delegati tramite delega vincolata o non vincolata, e ottengono una durata fissa di 4 ore per il TGT Kerberos, senza rinnovo. La sola appartenenza al gruppo fa il lavoro — non c'è alcuna policy da configurare male una volta che l'account è nel gruppo.

Il problema è che la maggior parte degli ambienti non lo popola mai. Gli account Domain Admins e gli altri account Tier 0 continuano ad autenticarsi con protocolli legacy e a memorizzare le credenziali in cache in LSASS esattamente come se il gruppo non esistesse, semplicemente perché nessuno li ha aggiunti.

Il flag "sensibile e non delegabile"

Separatamente da Protected Users, ogni account AD possiede un bit userAccountControl — NOT_DELEGATED (0x100000 / 1048576) — esposto nella GUI come "Questo account è sensibile e non può essere delegato". Quando è impostato, il ticket Kerberos dell'account non può essere inoltrato a un servizio configurato per la delega, anche se quel servizio è altrimenti trusted per la delega. Secondo la valutazione di sicurezza di Microsoft Defender for Identity per questo controllo, lasciarlo non impostato sugli account privilegiati significa che un servizio compromesso o malevolo trusted per la delega può richiedere e riutilizzare il ticket di quell'account per impersonarlo altrove sulla rete — un percorso di escalation indipendente dal fatto che l'account sia o meno in Protected Users.

Esposizione alla delega sull'account stesso

Oltre al flag sensibile, un account può portare direttamente una configurazione di delega: TRUSTED_FOR_DELEGATION (non vincolata), msDS-AllowedToDelegateTo (vincolata), o la delega vincolata basata sulle risorse tramite msDS-AllowedToActOnBehalfOfOtherIdentity. Ognuna di queste su un account Tier 0 significa che un servizio compromesso trusted per la delega può richiedere ticket come quell'account. Trattiamo lo sfruttamento di questi meccanismi in dettaglio in Attacchi di delega Kerberos: dalla delega non vincolata all'abuso di RBCD — il punto di questo articolo è più circoscritto: un account sensibile non dovrebbe mai essere un target di delega, indipendentemente dalla tecnica di attacco usata contro di esso.

Account di servizio in gruppi privilegiati

Un account di servizio con uno SPN (Service Principal Name) è kerberoastable per progettazione — qualsiasi utente di dominio autenticato può richiedere un ticket di servizio per esso e tentare di craccare il ticket offline (vedi la nostra guida al Kerberoasting per questa catena di attacco). Questo rischio è tollerabile quando l'account ha accesso solo al servizio che esegue. Smette di essere tollerabile nel momento in cui l'account è anche membro di Domain Admins o Enterprise Admins.

Le linee guida Microsoft su come ridurre l'appartenenza nei gruppi amministrativi altamente privilegiati sono esplicite: i gruppi privilegiati dovrebbero rimanere vuoti o limitati a un piccolo numero di amministratori responsabili, e gli account di servizio dovrebbero ricevere permessi delegati e ristretti anziché diritti Domain Admin generici. Un account di servizio in Domain Admins combina una password craccabile con un privilegio a livello di dominio — chiunque possa interrogare gli SPN ha già un percorso per tentare la compromissione completa del dominio.

SID History: la quarta via silenziosa

L'attributo sIDHistory esiste per preservare l'accesso durante le migrazioni tra domini — un utente migrato mantiene il SID del suo vecchio account, aggiunto al proprio token, in modo che i permessi esistenti continuino a funzionare. Secondo MITRE ATT&CK T1134.005, un attaccante con diritti equivalenti a Domain Admin (o capacità DCSync) può inserire un SID privilegiato ottenuto o ben noto — come quello di Enterprise Admins — nel SID History di un account a basso privilegio. Il token di quell'account porta quindi i diritti di Enterprise Admin senza mai comparire come membro del gruppo Enterprise Admins, il che è esattamente ciò che lo rende pericoloso: una revisione dell'appartenenza ai gruppi non lo rileva affatto.

Perché gli attaccanti concatenano queste lacune

Nessuna di queste quattro criticità deve essere isolata per essere utile a un attaccante, e in pratica raramente lo è. Un account privilegiato senza il flag sensibile è un target di delega valido; lo stesso account fuori da Protected Users può comunque autenticarsi con NTLM, quindi un attaccante con un hash relayed non ha nemmeno bisogno di Kerberos. Se lo stesso ambiente ha anche un account di servizio in Domain Admins, un attaccante che esegue il Kerberoasting e cracca la sua password ottiene una seconda via, indipendente, verso lo stesso livello di privilegio — senza bisogno di abusare della delega. E il SID History offre un'opzione di persistenza che sopravvive interamente a una rotazione delle credenziali sull'account privilegiato originale, poiché il SID iniettato viaggia su un'identità completamente diversa e a basso privilegio.

Questo è anche ciò che distingue questa lacuna dagli account privilegiati obsoleti (credenziali dormienti che nessuno ha disabilitato — vedi Account privilegiati obsoleti: rischio nascosto in Active Directory) e dalla deriva degli accessi privilegiati (diritti che tornano dopo una pulizia — vedi Deriva degli accessi privilegiati in Active Directory). Quei casi riguardano account che non dovrebbero più avere accesso, o accessi tornati di soppiatto. Questo riguarda account che oggi sono correttamente privilegiati, ma privi delle protezioni a livello di attributo che Active Directory offre già nativamente per contenerli.

Rilevamento

Interrogate direttamente la directory per ciascuna lacuna — non serve alcuno strumento di terze parti.

# Account privilegiati NON in Protected Users
$protected = (Get-ADGroupMember "Protected Users" -Recursive).SamAccountName
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object { $_.SamAccountName -notin $protected } |
    Select-Object SamAccountName

# Account privilegiati privi del flag "sensibile, non delegabile" (bit 0x100000)
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties userAccountControl |
    Where-Object { -not ($_.userAccountControl -band 1048576) } |
    Select-Object SamAccountName

# Account ancora trusted per la delega non vincolata/vincolata
Get-ADUser -Filter 'TrustedForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*"' `
    -Properties TrustedForDelegation, msDS-AllowedToDelegateTo

# Account di servizio (con SPN) all'interno di gruppi privilegiati
Get-ADGroupMember "Domain Admins","Enterprise Admins" -Recursive |
    Get-ADUser -Properties ServicePrincipalNames |
    Where-Object { $_.ServicePrincipalNames.Count -gt 0 }

# Qualsiasi account che porti un SID History
Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory.Count -gt 0 } |
    Select-Object SamAccountName, SIDHistory

Per una mappa più ampia degli ID evento rilevanti nel resto del vostro ambiente AD, vedi Monitoraggio di Active Directory: gli ID evento di sicurezza che contano.

Correzione

1. Popolate Protected Users solo con account Tier 0 umani. Testate prima su un gruppo pilota — Protected Users interrompe le app dipendenti da NTLM, il login in cache/offline e qualsiasi flusso che dipenda dal rinnovo del ticket Kerberos oltre le 4 ore. Non aggiungete mai account di servizio o computer.
2. Impostate il flag sensibile su ogni account privilegiato umano:

   Get-ADUser -Identity "jdoe" | Set-ADAccountControl -AccountNotDelegated:$true
   

   Fatelo anche per gli account già in Protected Users — il blocco della delega di Protected Users viene applicato al momento dell'autenticazione, ma un flag sensibile esplicito fornisce difesa in profondità e conta immediatamente per qualsiasi account non ancora completamente migrato nel gruppo.
3. Rimuovete la trust di delega dagli account Tier 0. Cancellate TrustedForDelegation e msDS-AllowedToDelegateTo su qualsiasi account privilegiato; gli account privilegiati non dovrebbero mai essere target di delega. Consultate la nostra guida Attacchi di delega Kerberos su come controllare la configurazione della delega a livello di dominio prima di iniziare a rimuoverla.
4. Portate gli account di servizio fuori dai gruppi privilegiati. Sostituite l'appartenenza a Domain Admin con un Group Managed Service Account (gMSA) più permessi delegati e ristretti sull'OU o sulla risorsa di cui il servizio ha effettivamente bisogno. Se il servizio ha davvero bisogno di diritti a livello di dominio, è un segnale che va riprogettato, non che si debba lasciare un account kerberoastable con pieno privilegio di dominio.
5. Controllate ed eliminate il SID History obsoleto. Eseguite la query di rilevamento sopra riportata; qualsiasi valore sIDHistory non legato a una migrazione di dominio documentata e ancora rilevante va indagato e rimosso con Set-ADUser -Clear sIDHistory dopo aver confermato che nessun accesso legittimo ne dipenda. Per le trust cross-forest ed esterne, abilitate il SID filtering (quarantena) in modo che i SID iniettati dall'altro lato della trust vengano rimossi prima di raggiungere il vostro dominio — vedi Attacchi alle trust di Active Directory: dal dominio figlio alla radice della foresta per capire come vengono sfruttate le lacune del SID filtering attraverso le trust.

Come EtcSec rileva questo problema

L'audit Active Directory di EtcSec verifica tutte e quattro le lacune a ogni scansione: NOT_IN_PROTECTED_USERS segnala gli account privilegiati assenti dal gruppo Protected Users, SENSITIVE_DELEGATION individua gli account privilegiati privi del flag "non delegabile", SERVICE_ACCOUNT_PRIVILEGED trova gli account con SPN all'interno di Domain Admins/Enterprise Admins, e SID_HISTORY fa emergere qualsiasi account con un sIDHistory non vuoto per la revisione.