Escalation dei Privilegi Active Directory: Backup Operators, Print Operators, Server Operators, i Gruppi che Nessuno Controlla

Escalation dei Privilegi Active Directory Spiegata: Backup Operators, Print Operators, Server Operators

L'escalation dei privilegi Active Directory tramite i gruppi integrati Backup Operators, Print Operators, Server Operators è una classe di rischio che la maggior parte delle verifiche incentrate sui Domain Admins non controlla mai, perché nessuno di questi quattro gruppi — Backup Operators, Print Operators, Server Operators o Account Operators — è annidato per impostazione predefinita in Domain Admins o Enterprise Admins. Eppure la documentazione stessa di Microsoft elenca tutti e quattro come gruppi di sicurezza di Active Directory, e Microsoft li classifica separatamente come account e gruppi protetti — lo stesso livello di protezione di Domain Admins e Schema Admins.

Quella classificazione è il segnale rivelatore. L'appartenenza a uno qualsiasi di questi quattro gruppi è sufficiente per ottenere accesso completo in lettura/scrittura a ogni file su un domain controller, esecuzione di codice in modalità kernel, esecuzione di comandi a livello di servizio, o manipolazione di account a livello di dominio. Nessuno di questi casi è una configurazione errata o una patch mancante — è il comportamento previsto dei diritti utente di Windows, applicato per impostazione predefinita a un gruppo a cui un attaccante deve solo far aggiungere un singolo account.

Come Ogni Gruppo Concede Diritti Prossimi a Domain Admin

Il meccanismo è la Default Domain Controllers Policy (GPO), che assegna diritti utente Windows specifici a questi gruppi su ogni DC del dominio:

Questi valori predefiniti sono documentati direttamente da Microsoft: la pagina della policy "Backup di file e directory" elenca Administrators, Backup Operators e Server Operators come titolari predefiniti sui domain controller, e la pagina della policy "Caricamento e scaricamento di driver di dispositivo" elenca Administrators e Print Operators. L'ambito di Account Operators è descritto nella stessa guida di riferimento sui gruppi di sicurezza: i membri possono creare e modificare la maggior parte dei tipi di account, ma il gruppo stesso non ha membri per impostazione predefinita, e la linea guida di Microsoft è di mantenerlo tale.

La Catena di Attacco: Quattro Vie d'Ingresso Distinte

Passo 1 — Da Backup Operators a ntds.dit

SeBackupPrivilege aggira completamente le ACL NTFS, il che significa che può essere usato per prelevare il database AD direttamente da un DC in produzione senza mai toccare il gruppo Domain Admins. Lo schema documentato in diverse pubblicazioni pubbliche — Semperis, Hacking Articles e nhimg.org — utilizza diskshadow.exe per creare una copia shadow del volume in modo da poter copiare il file bloccato ntds.dit, poi robocopy (che rispetta SeBackupPrivilege) per estrarre la copia e un export dell'hive di registro SYSTEM:

# script diskshadow (da eseguire da un account con SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Offline, ntds.dit insieme all'hive SYSTEM consegnano ogni hash di password del dominio — una via diretta a un accesso pass-the-hash come Domain Admin, senza exploit né CVE necessari. Raggiunge gli stessi segreti trattati nel nostro articolo ACL abuse e DCSync per i percorsi basati su ACL — solo tramite un bypass del file system invece di un diritto di replica.

Passo 2 — Da Print Operators a SYSTEM tramite un driver caricato

SeLoadDriverPrivilege consente a un membro di Print Operators di caricare un driver in modalità kernel su un domain controller. Come descrivono la ricerca di Tarlogic su questo privilegio e diverse raccolte di note di offensive-security (ad esempio HackTricks), questo privilegio viene comunemente abusato caricando un driver legittimamente firmato ma sfruttabile — la tecnica Capcom.sys è l'esempio pubblico meglio documentato — per eseguire codice arbitrario in spazio kernel come NT AUTHORITY\SYSTEM. Da lì, aggiungere l'account corrente a Domain Admins o estrarre direttamente ntds.dit diventa banale.

Passo 3 — Da Server Operators al dirottamento dei servizi

Server Operators eredita gli stessi diritti di backup/ripristino di Backup Operators, ma ottiene anche SERVICE_ALL_ACCESS sulla maggior parte dei servizi di un DC. L'articolo di Hacking Articles su questo gruppo illustra come ripuntare il percorso binario di un servizio legittimo verso un eseguibile controllato dall'attaccante e riavviare quel servizio — il servizio esegue quindi il payload come SYSTEM. La ricerca pubblicata sull'abuso di SeRestorePrivilege (raggiunto comunemente tramite l'appartenenza a Server Operators) mostra inoltre che consente di sovrascrivere binari di sistema protetti e dirottare le DLL dei servizi, offrendo almeno tre percorsi indipendenti da una singola appartenenza a un gruppo fino a SYSTEM su un DC.

Passo 4 — Da Account Operators alla persistenza silenziosa

Account Operators non porta alcun privilegio a livello di SO, ma i suoi diritti nativi in AD sono ampi: creare nuovi utenti, reimpostare la maggior parte delle password utente, e aggiungere o rimuovere membri dalla maggior parte dei gruppi, a livello di dominio. L'articolo di Cyber Advisors su Account Operators lo descrive spesso come "a un passo da Domain Administrator" — il gruppo non può toccare direttamente Domain Admins, Enterprise Admins o gli altri gruppi protetti (sono schermati dall'ACL di AdminSDHolder), ma può creare liberamente account, aggiungersi a qualsiasi gruppo non protetto con diritti delegati, e reimpostare la password di qualsiasi account che non sia in un gruppo protetto. Questo è sufficiente per una persistenza duratura e a bassa visibilità anche senza mai toccare un gruppo Tier 0.

🚨 Pericolo: nessuna di queste quattro tecniche richiede una vulnerability disclosure, un CVE o una patch mancante. Sono il comportamento previsto, per progettazione, dei diritti utente di Windows — l'unico "bug" è che un account sia membro del gruppo.

Rilevamento

Le modifiche di appartenenza ai gruppi e l'uso dei privilegi sono entrambi registrati nativamente — il divario è quasi sempre che nessuno li sta monitorando.

Correlate tutto quanto sopra con accessi interattivi o RDP (Event ID 4624, tipo di accesso 2 o 10) da questi quattro gruppi su un DC — in qualsiasi modello di tiering ragionevole, nessuno di essi dovrebbe mai averne bisogno. La nostra guida al Monitoraggio di Active Directory sugli Event ID che contano copre i prerequisiti della policy di controllo per tutti gli eventi sopra elencati. Strumenti di enumerazione continua come etc-collector, PingCastle e Purple Knight possono anche segnalare direttamente l'appartenenza non vuota a questi gruppi, senza attendere che si attivi un evento di log.

Rimedio

1. Mantenete tutti e quattro i gruppi vuoti. Questo è lo stato predefinito documentato; trattate ogni aggiunta come una modifica degna di un incidente, non come una delega di routine.
2. Delegate in modo mirato invece di annidare in gruppi integrati. Se un team ha realmente bisogno di creare account utente, concedete quel diritto tramite una delega ACL a livello di OU invece dell'appartenenza ad Account Operators, che per progettazione è a livello di dominio.
3. Spostate i job di backup fuori dal privilegio a livello di dominio. Dove il prodotto di backup lo consente, usate un account di servizio dedicato, limitato al target di backup specifico, invece di un account umano o condiviso che detiene SeBackupPrivilege/SeRestorePrivilege a livello di dominio tramite Server/Backup Operators.
4. Applicate un modello di tiering. Nessun account admin, helpdesk o di servizio di Tier 1 o Tier 2 dovrebbe mai essere annidato in un gruppo Tier 0 — questi quattro inclusi. Il nostro articolo Deriva degli Accessi Privilegiati illustra come l'appartenenza annidata ritorni anche dopo un audit pulito, e la nostra guida Messa in Sicurezza di Active Directory copre dove questo si inserisce in una sequenza di hardening più ampia.
5. Attivate la policy di controllo e create alert. Abilitate "Controllo dell'uso di privilegi sensibili" e "Controllo della gestione dei gruppi di sicurezza", inoltrate gli Event ID 4728/4732/4756/4673 al vostro SIEM, e create un alert su qualsiasi occorrenza che coinvolga i SID di questi quattro gruppi.
6. Ricontrollate regolarmente, non una sola volta. Questi quattro gruppi sono esattamente il tipo di finding che una revisione più ampia delle configurazioni di sicurezza errate di Active Directory più comuni tende a far emergere insieme, come descritto nella nostra checklist di audit sulla sicurezza di Active Directory — eseguite questo controllo a ogni ciclo di audit ricorrente, non come pulizia una tantum.

Come EtcSec lo Rileva

I controlli ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER e SERVER_OPERATORS_MEMBER di EtcSec segnalano qualsiasi appartenenza non vuota a questi quattro gruppi in ogni audit AD — la stessa tolleranza quasi nulla documentata da Microsoft. PRIVILEGE_SEBACKUP_ABUSE e PRIVILEGE_SERESTORE_ABUSE rilevano separatamente i casi in cui SeBackupPrivilege o SeRestorePrivilege sono stati assegnati oltre i valori predefiniti integrati tramite una GPO, l'altro modo in cui questi diritti finiscono nelle mani sbagliate.