Diritti Utente Pericolosi GPO Active Directory SeDebug SeTcb: Escalation di Privilegio SeLoadDriver a SYSTEM

Cos'è un'assegnazione di diritti utente pericolosa in Active Directory

Group Policy non si limita a distribuire software o mappare unità di rete: il suo contenitore Security Settings può anche assegnare diritti utente locali (i "privilegi" nel modello del token di accesso di Windows, distinti dai permessi sugli oggetti) a qualsiasi principal di sicurezza, inclusi Authenticated Users, Domain Users o un gruppo personalizzato. Quando la sezione [Privilege Rights] di una GPO assegna un privilegio ad alto impatto come SeDebugPrivilege, SeLoadDriverPrivilege o SeTcbPrivilege ad account che non sono amministratori locali, ogni computer a cui la GPO si applica eredita un percorso diretto, senza bisogno di exploit, da "qualsiasi account di dominio" a SYSTEM. I team di sicurezza e gli auditor segnalano sempre più spesso questo pattern — diritti utente pericolosi assegnati via GPO — come un finding di Active Directory distinto, diverso dalla più nota misconfigurazione "la GPO aggiunge un utente al gruppo Administrators locale".

Non si tratta di una vulnerabilità di Windows, ma di un errore nella stesura della Group Policy, di solito introdotto per sbloccare un agente di monitoraggio, uno strumento di backup o un tool di helpdesk che ha legittimamente bisogno di diritti elevati, e poi lasciato in essere (o copiato in GPO non correlate) molto dopo che la giustificazione originale è venuta meno. Le misconfigurazioni delle GPO sono tra i modi più comuni in cui Group Policy diventa un vettore di attacco, proprio perché sono silenziose: nulla si rompe, non scatta alcun alert, e la GPO continua ad applicarsi a ogni ciclo di refresh della policy.

Il raggio d'impatto dipende dal collegamento della GPO, non da come è stata giustificata l'assegnazione. Una GPO creata per risolvere l'agente di monitoraggio di un singolo server, e poi collegata per comodità a una OU o alla radice del dominio, assegna silenziosamente lo stesso diritto a tutti i computer sotto quel collegamento — trasformando un'eccezione ristretta e difendibile in un percorso di escalation a livello di dominio che nessuno ha approvato, un'altra variante dei percorsi nascosti verso Domain Admin del nesting pericoloso dei gruppi.

Perché Active Directory considera pericolosi questi diritti utente assegnati via GPO

Windows applica circa una trentina di diritti utente tramite il token di accesso. La maggior parte sono innocui nelle mani sbagliate — "Modificare il fuso orario" non è un percorso verso SYSTEM. Tre di essi sono l'eccezione.

SeDebugPrivilege ("Debug dei programmi")

SeDebugPrivilege consente al titolare di aprire un handle verso qualsiasi processo o thread della macchina, bypassando il controllo di accesso che normalmente impedirebbe a un non proprietario di toccare il processo di un altro utente — inclusi i processi di proprietà di NT AUTHORITY\SYSTEM. Poiché LSASS viene eseguito come SYSTEM e mantiene in memoria materiale di credenziali in cache, un account con SeDebugPrivilege può aprire un handle verso LSASS ed estrarne credenziali utilizzabili — la stessa primitiva usata dal modulo sekurlsa di Mimikatz, e la stessa alla base di tecniche living-off-the-land come il dump di LSASS tramite l'export MiniDump di comsvcs.dll. Per impostazione predefinita, solo gli amministratori possiedono questo diritto.

SeLoadDriverPrivilege ("Caricamento e rimozione di driver di dispositivo")

SeLoadDriverPrivilege consente al titolare di caricare un driver in modalità kernel tramite l'API NtLoadDriver(). I driver kernel vengono eseguiti senza alcuna barriera di sicurezza rispetto al resto del sistema operativo, quindi un account con questo diritto può registrare e caricare un driver firmato noto per essere vulnerabile (il driver Capcom.sys ne è un esempio ben documentato) e usarlo come primitiva per leggere/scrivere memoria kernel o eseguire codice arbitrario come SYSTEM — una tecnica comunemente chiamata BYOVD (Bring Your Own Vulnerable Driver). Questo percorso resta rilevante anche contro un EDR moderno, perché un driver vulnerabile firmato è considerato attendibile dai controlli di integrità del codice che bloccano il codice non firmato.

SeTcbPrivilege ("Agire come parte del sistema operativo")

SeTcbPrivilege è il più diretto dei tre: consente al titolare di chiamare le API di autenticazione normalmente riservate alla Trusted Computing Base di Windows, il che include l'impersonificazione di qualsiasi account del sistema, SYSTEM incluso. Un attaccante che possiede questo diritto non ha bisogno di dumpare credenziali né di caricare un driver — può creare un servizio che chiama direttamente le API di logon attendibili e impersonare SYSTEM senza intermediari. Su un sistema configurato correttamente, nessun account non amministratore dovrebbe mai possedere SeTcbPrivilege.

🚨 Pericolo: tutti e tre i diritti sono considerati critici perché nessuno richiede un exploit di esecuzione codice. Se la GPO concede il diritto, l'escalation è un uso documentato e supportato di un'API Windows — non un bug.

La catena d'attacco: dalla misconfigurazione GPO a SYSTEM

Passo 1 — Scoprire l'assegnazione

Un attaccante che dispone già di un punto d'appoggio nel dominio (un utente phishato, un account di servizio a bassi privilegi) enumera le GPO applicate alle OU interessanti — controller di dominio, server tier-0, host di salto — e legge la sezione [Privilege Rights] del GptTmpl.inf di ogni GPO in SYSVOL, leggibile per impostazione predefinita da qualsiasi utente autenticato:

# Enumera la sezione User Rights Assignment di ogni GPO per i tre diritti critici
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Passo 2 — Confermare che l'account è nell'ambito

L'attaccante verifica se il proprio account attuale — o un gruppo che controlla, incluso un gruppo ampio come Authenticated Users se la GPO ha un ambito così permissivo — figura tra i membri dell'assegnazione, e a quali computer è collegata la GPO. Una GPO collegata alla radice del dominio o a una OU che contiene controller di dominio trasforma questo da "interessante" a "fine del dominio".

Passo 3 — Sfruttare il diritto

• Con SeDebugPrivilege: aprire un handle su lsass.exe e dumpare materiale di credenziali per il cracking offline o il replay.
• Con SeLoadDriverPrivilege: registrare e caricare un driver firmato vulnerabile, poi sfruttarlo per ottenere una shell SYSTEM.
• Con SeTcbPrivilege: chiamare direttamente le API di logon attendibili per impersonare SYSTEM, senza driver né dump di credenziali.

Ciascuno dei tre trasforma "utente di dominio in questa OU" in "SYSTEM locale su ogni macchina toccata dalla GPO" — il che, se la OU include asset tier-0, equivale funzionalmente a un percorso di attacco diretto verso Domain Admin. Da SYSTEM locale su un controller di dominio, l'attaccante è a un solo passo dai diritti DCSync e dall'intero set di credenziali del dominio.

Rilevamento

Il monitoraggio di Active Directory copre l'insieme più ampio di ID evento da tenere sotto osservazione se si vuole estendere il rilevamento oltre questi tre privilegi. Il repository pubblico di detection rule di Elastic include anche una regola "Group Policy Abuse for Privilege Addition" che monitora l'evento di modifica del directory service (Event ID 5136) che si attiva quando viene modificato il GUID dell'estensione client Security di una GPO — il segnale che il contenuto del suo GptTmpl.inf, incluso [Privilege Rights], è cambiato — segnalando esattamente questa classe di diritto ad alto impatto (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) — un riferimento utile anche al di fuori di Elastic Security. Qualunque sia la fonte da cui si genera l'alert, trattate ogni riscontro come ad alta gravità: non esiste alcuna ragione legittima perché questi tre diritti raggiungano un account non amministratore per semplice drift di policy.

Correzione

1. Inventariate ogni GPO che tocca [Privilege Rights]. Esportate tutte le GPO con Get-GPOReport -All -ReportType Xml e cercate i nodi UserRightsAssignment; non date per scontato che solo le GPO di "baseline di sicurezza" tocchino questa sezione.
2. Limitate i tre diritti critici agli amministratori. I CIS Benchmark per Windows Server e Windows 11 impostano entrambi "Debug dei programmi" (SeDebugPrivilege) ai soli amministratori come raccomandazione di base; applicate lo stesso standard a SeLoadDriverPrivilege e SeTcbPrivilege, salvo un'eccezione specifica, documentata e a tempo determinato.
3. Rintracciate l'origine di ogni eccezione. Se un agente di monitoraggio o uno strumento di backup ha davvero bisogno di uno di questi diritti, limitate la GPO al gruppo di sicurezza più piccolo possibile invece che a una OU ampia o ad Authenticated Users, e documentate l'eccezione con un responsabile e una data di revisione.
4. Testate in una OU isolata prima del rollout. Distribuite prima una baseline di diritti utente irrigidita su una OU pilota — alcuni agenti legacy falliscono in modo rumoroso (e visibile) se viene rimosso un diritto da cui dipendono, una scoperta molto più economica che farla in produzione.
5. Versionate le modifiche alle GPO. Trattate le modifiche a GptTmpl.inf come modifiche al codice — un processo di diff/revisione delle GPO trasforma una concessione silenziosa di privilegio in una modifica revisionabile anziché in una sorpresa.
6. Ripetete la scansione a intervalli regolari, non solo una volta. Le GPO vengono copiate, ereditate e ricollegate nel tempo, e una baseline pulita oggi non garantisce una baseline pulita il prossimo trimestre. Il drift degli accessi privilegiati segue esattamente questo pattern: i diritti ritornano dopo la chiusura dell'audit originale.

Come EtcSec rileva questo problema

L'audit Active Directory di EtcSec verifica la sezione [Privilege Rights] di ogni GPO collegata rispetto alle tre assegnazioni critiche trattate qui — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE e PRIVILEGE_SETCB_ABUSE — e segnala qualsiasi SID non predefinito che ne possieda uno al di fuori del gruppo integrato Administrators, con il nome della GPO e la OU collegata, per un finding immediatamente azionabile senza bisogno di una scansione manuale con Get-GPOReport.