Abuso dei privilegi in Windows: come gli autori degli attacchi passano da account con diritti pericolosi alla compromissione di Active Directory

Ho dedicato molti anni allo studio del modo in cui gli autori di attacchi informatici abusano dei privilegi di Windows per elevare il proprio livello di accesso, passando da account con privilegi limitati fino a raggiungere NT AUTHORITY\SYSTEM. Quella che era nata come semplice curiosità riguardo a una manciata di primitive di impersonificazione si è gradualmente trasformata in un catalogo sistematico di tecniche di attacco incentrate sull’abuso dei privilegi di Windows . Molte di queste tecniche rimangono attuali anche in ambienti moderni e aggiornati con le patch.

In questo post vi illustrerò i privilegi di Windows più allettanti dal punto di vista di un aggressore: quelli che consentono un’escalation diretta dei privilegi. Continuate a leggere per scoprire:

• Quali privilegi mettono maggiormente a rischio il tuo ambiente?
• Perché gli hacker prendono di mira questi privilegi
• In che modo gli aggressori possono sfruttare questi privilegi per ottenere privilegi SYSTEM locali, spesso con uno sforzo sorprendentemente minimo

In che modo i privilegi di Windows possono aumentare i rischi per la sicurezza informatica

Dal 2018 discuto con i professionisti dell’IT e della sicurezza informatica dei pericoli legati all’abuso dei privilegi in Windows. Dalla classica manipolazione dei token alla famiglia di exploit “Potato”, questo argomento ha caratterizzato gran parte della ricerca sull’escalation dei privilegi locali in Windows negli ultimi 10 anni.

Eppure il messaggio rimane attuale come non mai. Molti continuano a sottovalutare questi privilegi, il loro funzionamento e il livello di controllo che possono garantire agli aggressori. Questo rischio persiste per due motivi:

• I privilegi non sono autorizzazioni. Le organizzazioni che controllano attentamente i propri ACL e le deleghe spesso trascurano i privilegi assegnati agli account utente non privilegiati.
• Microsoft non rilascia patch per gli abusi di privilegi. L'abuso di un privilegio di cui si è legittimamente in possesso non costituisce una violazione dei confini di sicurezza. Le tecniche che descrivo in questo post, compresi gli exploit Potato, sono sopravvissute per molti anni e attraverso innumerevoli versioni di Windows perché si basano su funzionalità, non su bug. Pertanto, le vostre difese devono essere di tipo architetturale.

L'abuso di privilegi è solitamente associato all'escalation dei privilegi locali (LPE). Tuttavia, sappiamo tutti che la compromissione totale di un dominio spesso ha inizio proprio da lì: un'escalation dei privilegi locali che consente a un aggressore di ottenere il massimo livello di accesso su una singola macchina. A quel punto, gli aggressori possono spesso sfruttare i diritti elevati, le credenziali, i token o altre risorse esposte per muoversi lateralmente e proseguire il loro percorso di escalation all'interno del vostro ambiente.

Il rischio diventa ancora più grave in ambienti condivisi. Si pensi, ad esempio, a un server RDP, a un host di transito o a qualsiasi sistema in cui interagiscono più utenti. Ottenere il controllo amministrativo locale su una macchina di questo tipo può avere conseguenze che vanno ben oltre l’host stesso.

Se esegui whoami /priv e vuoi leggere più di una manciata di post, questo blog fa proprio al caso tuo.

Cosa sono i privilegi di Windows?

Microsoft definisce un privilegio come«il diritto di un account, ad esempio un account utente o di gruppo, di eseguire varie operazioni relative al sistema sul computer locale, quali lo spegnimento del sistema, il caricamento dei driver di periferica o la modifica dell'ora di sistema».

In pratica, i privilegi sono un meccanismo che affianca, e talvolta prevale su, il modello tradizionale di autorizzazioni basato sulle ACL. Dal punto di vista della sicurezza, è fondamentale comprendere alcuni aspetti:

• I privilegi vengono assegnati tramite Assegnazione dei diritti utente nell'Editor dei criteri locali o di gruppo (Figura 1). Ma possono anche essere gestiti a livello di programmazione tramite l'API di Windows, utilizzando funzioni quali LsaOpenPolicy() e LsaAddAccountRights().

• I privilegi possono essere abilitati o disabilitati. Un privilegio predefinito è quello che viene abilitato automaticamente ogni volta che il sistema ne rileva la necessità.
• Alcuni privilegi prevalgono esplicitamente sui permessi degli oggetti (ACL). Questa è la causa principale della maggior parte degli abusi qui discussi.
• La maggior parte dei privilegi è accessibile solo all'interno di un processo con un livello di integrità (IL) elevato, il che significa che per utilizzarli è necessaria una shell con privilegi elevati. Tuttavia, una volta ottenuta tale shell, è possibile abusare di tali privilegi a proprio piacimento.
• Il comando più importante in assoluto in questa ricerca è whoami /priv, che mostra tutti i privilegi assegnati al token corrente, insieme al loro stato (abilitato/disabilitato). Un privilegio abilitato è pronto per l'uso. Uno disabilitato richiede semplicemente una chiamata all'API per AdjustTokenPrivileges() per abilitarlo, a meno che non sia considerato un privilegio predefinito.

Cosa sono i token di accesso di Windows?

Per comprendere l'abuso dei privilegi, occorre innanzitutto comprendere i token di accesso. Si tratta di oggetti che Windows utilizza per rappresentare il contesto di sicurezza di un processo o di un thread (Figura 2).

Un sistema crea un token durante la procedura di accesso tramite NtCreateToken(). Questo token viene quindi utilizzato ogni volta che un processo o un thread cerca di interagire con un oggetto protetto. Quando viene generato un nuovo processo o thread, gli viene assegnata una copia del token del processo o thread padre.

Un token contiene, tra le altre cose:

• Il SID dell'utente e del proprietario
• SID per ogni gruppo a cui l'utente appartiene
• Il SID di accesso
• Il DACL applicato quando l'utente crea oggetti protetti senza specificare un descrittore di sicurezza
• Il tipo di token (primario o di impersonificazione)
• Il livello di impersonificazione corrente: SecurityAnonymous, SecurityIdentification, SecurityImpersonation o SecurityDelegation
• L'elenco completo dei privilegi di cui dispongono l'utente o i suoi gruppi (Figura 3)

Esiste un vincolo importante: una volta che il PrimaryTokenFrozen Se il bit è impostato su un token, non è possibile aggiungere nuovi privilegi. È possibile solo abilitare o disabilitare i privilegi già presenti, tramite AdjustTokenPrivileges. Tuttavia, è possibile modificare il tipo di token utilizzando DuplicateToken, il che apre la strada a possibili casi di furto d'identità.
Questa struttura implica che i privilegi di cui si dispone siano determinati in gran parte al momento dell'accesso. La domanda che sorge spontanea è quindi: Chi ha effettuato l'accesso e con quale dispositivo?

Quali account di Windows sono nel mirino degli hacker?

Prima di addentrarci nei dettagli dei privilegi specifici, è bene sapere quali account dispongono di privilegi pericolosi per impostazione predefinita. Ecco un breve elenco:

• Gli amministratori e il sistema locale dispongono sostanzialmente di tutti i privilegi.
• I gruppi predefiniti, quali “Operatori di backup”, “Operatori di server” e “Operatori di stampa”, dispongono di una serie di privilegi avanzati che spesso vengono trascurati.
• Gli account di servizio locali e di rete dispongono in genere dei privilegi SeImpersonatePrivilege e SeAssignPrimaryTokenPrivilege, che sono sufficienti per raggiungere il livello SYSTEM.
• Gli account di servizio gestiti e gli account virtuali dispongono degli stessi privilegi degli account di servizio.
• Gli utenti di applicazioni di terze parti, quali i pool di applicazioni IIS, gli account di servizio di SQL Server e gli agenti di backup, vengono spesso configurati con privilegi superiori a quelli necessari.

Ancora una volta, Microsoft considera l'abuso di privilegi legittimi una violazione dei limiti di sicurezza, non una violazione dei confini di sicurezza. Le tecniche di abuso dei privilegi non sono considerate bug e pertanto non vengono corrette con patch.

Come gli hacker individuano e sfruttano i privilegi di Windows

Ma come fanno gli hacker a ottenere l'accesso ad account dotati di privilegi sfruttabili? Il processo prevede solitamente uno o più dei seguenti approcci:

• Compromissione degli account di servizio, ad esempio a causa di configurazioni di servizio inadeguate, l'esecuzione remota di codice nelle applicazioni Web o l'iniezione SQL, che possono portare a xp_cmdshell esecuzione
• Intercettazione dell'autenticazione NTLM o Kerberos mediante tecniche quali la coercizione, gli attacchi di relay o l'acquisizione delle credenziali
• Rubare credenziali o eseguire il "kerberoasting" ottenendo le credenziali degli account di servizio e decifrando gli hash offline
• Manipolazione dei token mediante l'usurpazione dell'identità di token provenienti da processi con privilegi o il loro furto diretto
• Scritture parziali o arbitrarie utilizzando la tecnica Direct Kernel Object Manipulation (DKOM), che consente agli aggressori dotati di primitive di scrittura a livello di kernel — spesso ottenute tramite driver vulnerabili — di aggirare completamente le API in modalità utente. Individuando il _TOKEN struttura attraverso _EPROCESS e modificando i campi relativi ai privilegi, gli aggressori possono aggiungere e abilitare ulteriori privilegi (Figura 4).

Quali privilegi di Windows sono nel mirino degli hacker?

Ora che avete un quadro generale del rischio rappresentato dall'abuso dei privilegi in Windows, approfondiamo quali sono i privilegi che gli aggressori tendono a prendere di mira, perché questi privilegi sono così allettanti per gli autori di attacchi malevoli e in che modo vengono sfruttati.

SeCreateTokenPrivilege: Qualcuno ha dei token di accesso?

SeCreateTokenPrivilege è un potente privilegio relativo ai token che consente a un processo di richiamare le API per la creazione di token, in particolare ZwCreateToken, per creare un token di accesso completamente personalizzato con qualsiasi privilegio e appartenenza a gruppi desiderati:

      NTSTATUS ZwCreateToken(
PHANDLE                            TokenHandle,
ACCESS_MASK                     DesiredAccess,
POBJECT_ATTRIBUTES         ObjectAttributes,
TOKEN_TYPE                        Type,
PLUID                                   AuthenticationId,
PLARGE_INTEGER                 ExpirationTime,
PTOKEN_USER                      User,
PTOKEN_GROUPS                Groups,
PTOKEN_PRIVILEGES            Privileges,
PTOKEN_OWNER                 Owner,
PTOKEN_PRIMARY_GROUP PrimaryGroup,
PTOKEN_DEFAULT_DACL     DefaultDacl,
PTOKEN_SOURCE                Source
);

Su Windows Server 2016 / Windows 10 versione 1809 e precedenti, il token risultante può essere utilizzato per impersonare i thread senza richiedere ulteriori privilegi di impersonazione. Microsoft ha risolto quella specifica vulnerabilità nelle versioni successive di Windows, ma il token risultante può comunque essere utilizzato per scrivere e sovrascrivere file protetti: una funzionalità utile per gli aggressori, anche in scenari con restrizioni.

SeDebugPrivilege: l'accesso SYSTEM in breve

SeDebugPrivilege è uno dei privilegi più potenti nel modello dei privilegi di Windows. Consente a chi ne è in possesso di collegare un debugger a qualsiasi processo, indipendentemente da chi ne sia il proprietario o da quali ACL lo proteggano, e di leggere o modificare la memoria del processo.

È fondamentale sottolineare che SeDebugPrivilege aggira i normali controlli DACL. Non aggira invece i meccanismi di protezione dei processi (ad esempio, PPL, processi firmati con ELAM), ma questi rappresentano solo una piccola parte dei processi in esecuzione su un sistema tipico.

Tra gli scenari di abuso figurano:

• Iniezione di codice. Gli aggressori possono iniettare codice dannoso nei processi con privilegi utilizzando la classica sequenza VirtualAlloc() → WriteProcessMemory() → CreateRemoteThread(). Obiettivo lsass.exe, winlogon.exe, o qualsiasi processo NT AUTHORITY\SYSTEM, si ottiene l'esecuzione di codice arbitrario al massimo livello di privilegi.
• Spoofing del processo padre. Gli aggressori possono creare un nuovo processo e designare un processo privilegiato come processo padre, in modo che il processo figlio erediti il token privilegiato (Figura 5).

In pratica, qualsiasi servizio o applicazione che conceda a un account il privilegio SeDebugPrivilege garantisce di fatto a quell'account l'accesso come SYSTEM. Esistono pochi motivi legittimi per cui tale privilegio venga assegnato su larga scala.

SeBackupPrivilege e SeRestorePrivilege: dall'escalation dei privilegi locali all'estrazione di NTDS.DIT

Gli aggressori possono sfruttare le vulnerabilità SeBackupPrivilege e SeRestorePrivilege per accedere a file sensibili e, in alcuni casi, estrarre il database NTDS.DIT dai controller di dominio (DC), con il rischio di compromettere completamente Active Directory… uno scenario preoccupante.

SeBackupPrivilege: la via più veloce per l'estrazione delle credenziali

La descrizione contenuta nella documentazione Microsoft precisa che SeBackupPrivilege “consente all'utente di aggirare i permessi relativi a file e directory per eseguire il backup del sistema.” In altre parole, questo privilegio consente l’accesso in lettura a qualsiasi file presente nel sistema, indipendentemente dagli ACL, purché il file venga aperto con FILE_FLAG_BACKUP_SEMANTICS.

L'abuso più immediato consiste nel scaricare gli hive del Registro di sistema di Windows necessari per l'estrazione offline delle credenziali:

reg save HKLM\SYSTEM c:\temp\system.hive
reg save HKLM\SAM c:\temp\sam.hive

Una volta che un aggressore è in possesso di questi due file, può utilizzare qualsiasi strumento offline per estrarre gli hash NTLM locali. Su un server, dove il riutilizzo delle password degli amministratori locali è ancora una pratica fin troppo diffusa, questa capacità può fornire agli autori di attacchi un punto d’appoggio per il movimento laterale all’interno di un intero segmento (Figura 6).

Oltre al registro di sistema, SeBackupPrivilege può essere utilizzato per leggere qualsiasi file a cui il filesystem normalmente negherebbe l'accesso:

      source = CreateFile(
L"c:\users\administrator\supersecretfile4admins.doc",
GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS,
NULL
);

La chiave è il FILE_FLAG_BACKUP_SEMANTICS flag, che induce Windows a riconoscere un'operazione di backup e a bypassare la normale valutazione DACL.

SeRestorePrivilege: Accesso in scrittura senza restrizioni

Mentre SeBackupPrivilege garantisce l'accesso in lettura a qualsiasi elemento, SeRestorePrivilege garantisce l'accesso in scrittura a qualsiasi elemento, compresi i file protetti da TrustedInstaller e le chiavi del registro di sistema. Due chiamate API attivano questo comportamento:

• CreateFile() con FILE_FLAG_BACKUP_SEMANTICS
• RegCreateKeyEx() con REG_OPTION_BACKUP_RESTORE

Con un accesso in scrittura illimitato, la superficie di attacco diventa enorme. Una tecnica semplice e spesso utilizzata in modo improprio consiste nel modificare un servizio di Windows per eseguire un payload controllato dall'autore dell'attacco. Gli autori degli attacchi devono semplicemente:

1. Creare una DLL o un file eseguibile di servizio dannoso.
2. Utilizzo RegCreateKeyEx() con REG_OPTION_BACKUP_RESTORE per sovrascrivere il servizio ServiceDLL valore del registro:
   std::string buffer = "c:\windows\system32\hackerservice.dll";
LSTATUS stat = RegCreateKeyExA(
HKEY_LOCAL_MACHINE,
"SYSTEM\CurrentControlSet\Services\dmwappushservice\Parameters",
0, NULL, REG_OPTION_BACKUP_RESTORE, KEY_SET_VALUE, NULL, &hk, NULL
);
stat = RegSetValueExA(
hk, "ServiceDLL", 0, REG_EXPAND_SZ,
(const BYTE*)buffer.c_str(), buffer.length() + 1
);
3. Utilizzo CreateFile() con FILE_FLAG_BACKUP_SEMANTICS per copiare la DLL in C:\Windows\System32. (La posizione può essere qualsiasi; questo esempio serve semplicemente a dimostrare che il privilegio consente di scrivere, o addirittura sovrascrivere, i file di sistema protetti.)
4. Riavviare il servizio di destinazione. Il servizio, in esecuzione come SYSTEM, ora carica la DLL dell'autore dell'attacco.

Figura 7 mostra un esempio di questa tecnica utilizzando dmwappushservice, che è presente di default, viene eseguito come SYSTEM e può essere avviato da qualsiasi utente. Tuttavia, la stessa tecnica può essere utilizzata per sfruttare qualsiasi servizio.

Operatori di backup: il doppio dei privilegi, il doppio del rischio

I membri del gruppo predefinito "Backup Operators" dispongono sia del privilegio SeBackupPrivilege che del privilegio SeRestorePrivilege. Ancora più importante, hanno il permesso di effettuare l'accesso locale ai DC, una funzionalità che comporta un rischio gravemente sottovalutato nella maggior parte degli ambienti AD.

Questa combinazione implica che qualsiasi malintenzionato che riesca a infiltrarsi nel gruppo "Backup Operators" possa eseguire il backup del file NTDS.DIT direttamente da un DC utilizzando strumenti come wbadmin.exe:

      wbadmin start backup -backuptarget:e: -include:c:\windows\ntds
wbadmin get versions
wbadmin start recovery -version:07/12/2025-11:09 -itemtype:file
-items:c:\windows\ntds\ntds.dit -recoverytarget:c:\temp\srvdc1 -notrestoreacl
reg save HKLM\SYSTEM c:\temp\system

L'approccio basato sul file "diskshadow.exe" integrato funziona altrettanto bene ed è spesso trascurato da chi si occupa di sicurezza:

      set metadata C:\temp\metadata.cab
set context clientaccessible
set context persistent
begin backup
add volume c: alias mydrive
create
expose %mydrive% z:

Si noti che questa tecnica non funziona con ntdsutil.exe, che richiede privilegi di amministratore.

Una volta che un malintenzionato è in possesso di NTDS.DIT e dell'hive SYSTEM, può utilizzare strumenti come DSInternals o impacket-secretsdump per estrarre offline tutte le credenziali del dominio, compreso l'hash krbtgt necessario per sferrare un attacco Golden Ticket.

Inoltre, grazie a entrambi i privilegi, un malintenzionato che riesca a infiltrarsi nel gruppo “Backup Operators” può impostare la proprietà e i permessi su qualsiasi file o cartella presente nel sistema, ottenendo così l’accesso a SYSTEM semplicemente manipolando il filesystem.

SeImpersonatePrivilege e SeAssignPrimaryTokenPrivilege: perché gli exploit di Potato non vogliono scomparire

Questi due privilegi sono quelli di cui si abusa più spesso negli attacchi reali, e sono proprio la ragione per cui esiste la famiglia di exploit denominata "Potato".

• SeImpersonatePrivilege (“Fingersi un cliente dopo l'autenticazione”) consente a un thread di simulare qualsiasi token di accesso tramite SetThreadToken(), ImpersonateLoggedOnUser(), o CreateProcessWithToken().
• SeAssignPrimaryTokenPrivilege (“Assegnare il token primario di un processo”) consente a un processo di generare un processo figlio con un token primario diverso tramite CreateProcessAsUser(). Questo privilegio è disponibile anche in una shell IL standard di livello medio.

Entrambi i privilegi vengono normalmente assegnati agli account di servizio, alle identità dei pool di applicazioni IIS, agli account di servizio di SQL Server e a soggetti simili. In breve: se disponi di RCE come account di servizio, quasi certamente possiedi almeno uno di questi privilegi.

Ma in che modo gli aggressori ottengono i token privilegiati per assumere l'identità di altri? Esistono diverse tecniche, ad esempio:

• Creazione di un pipe con nome, costringendo un processo con privilegi a connettersi ad esso, quindi chiamando ImpersonateNamedPipeClient() per ottenere il token del chiamante
• Utilizzo dei callback DCOM/RPC via CoImpersonateClient(), RpcImpersonateClient()
• Utilizzando gli exploit Potato, una famiglia di ben note tecniche di escalation dei privilegi locali (ad esempio, RottenPotato, JuicyPotato, SweetPotato, GodPotato) che sfruttano tali privilegi costringendo l’autenticazione COM/RPC a livello SYSTEM a tornare a un listener controllato dall’autore dell’attacco

La tecnica risale a un'osservazione fatta da James Forshaw nel 2016:

«Le connessioni DCOM DCE/RPC locali possono essere reindirizzate verso un socket TCP in ascolto, consentendo l'accesso alla richiesta di autenticazione NTLM per l'utente LocalSystem, che può essere riprodotta al servizio di attivazione DCOM locale per elevare i privilegi.»

Negli ultimi 10 anni, questo exploit di base è stato reimplementato, adattato e riutilizzato in una notevole varietà di tecniche che, nel loro insieme, formano la famiglia Potato. Il meccanismo generale, comune a tutte le varianti, segue questa struttura:

1. Avvia un listener locale su una porta TCP affinché funga da endpoint COM o RPC fittizio.
2. Attivare un CLSID istanziando una classe COM che si avvia con l'identità NT AUTHORITY\SYSTEM.
3. Forzare il demarshaling via CoGetInstanceFromIStorage, passando un oggetto realizzato ad arte IStorage OBJREF indicando 127.0.0.1: <listener>. Il server SYSTEM COM tenta di connettersi al listener ed esegue l'autenticazione in uscita tramite NTLM.
4. Intercettare localmente l'handshake NTLM tramite SSPI (AcceptSecurityContext → QuerySecurityContextToken) per ottenere un token di impersonazione SYSTEM.
5. Assumere l'identità del token ed eseguire l'escalation via CreateProcessWithTokenW o CreateProcessAsUser per avviare una shell come SYSTEM.
   

L'intuizione fondamentale è geniale: il CLSID induce SYSTEM ad avviare l'autenticazione in uscita, CoGetInstanceFromIStorage indirizza l'autenticazione verso il listener dell'autore dell'attacco, e il relay NTLM locale intercetta il token. Non si tratta di una vulnerabilità nel senso tradizionale del termine… sono semplicemente i privilegi che fanno esattamente ciò per cui sono stati progettati.

La figura 8 mostra come lo strumento JuicyPotatoNG possa essere utilizzato per avviare una shell SYSTEM sfruttando la vulnerabilità SeAssignPrimaryTokenPrivilege da una shell in esecuzione in un IL di livello medio.

SeLoadDriverPrivilege: dal driver di periferica alla compromissione totale del sistema

SeLoadDriverPrivilege determina quali utenti possono caricare e scaricare dinamicamente driver di periferica o altro codice in modalità kernel. Questo privilegio è particolarmente degno di nota poiché i membri del gruppo di dominio "Operatori stampanti" ne dispongono per impostazione predefinita sui DC.

Lo schema di attacco è ben consolidato: caricare un driver del kernel firmato ma vulnerabile, quindi sfruttarne la vulnerabilità dall’userland per leggere o scrivere nella memoria del kernel, consentendo il furto di token, l’acquisizione di privilegi, l’aggiramento delle restrizioni PPL, la chiusura di antivirus ed EDR o l’esecuzione arbitraria in modalità kernel.

La tecnica canonica si basa sul fatto che gli utenti possono creare voci di registro all'interno del proprio hive corrente HKCU, e NtLoadDriver() accetta percorsi di registro generati a partire dal SID dell'utente, consentendo a un utente senza privilegi di registrare un servizio di driver del kernel senza intervenire su HKLM:

      std::string data = "\??\C:\TEMP\evildriver.sys";
RegCreateKeyExA(HKEY_CURRENT_USER,
"SYSTEM\CurrentControlSet\Services\Evil",
0, NULL, NULL, KEY_SET_VALUE, NULL, &hk, NULL);
RegSetValueExA(hk, "ImagePath", 0, REG_EXPAND_SZ,
(const BYTE)data.c_str(), data.length() + 1); RegSetValueExA(hk, "Type", 0, REG_DWORD, (const BYTE)&val, sizeof(val));

WCHAR winregPath[256];
wcscpy(winregPath, L"\Registry\User\");
wcscat(winregPath, sidstring);
wcscat(winregPath, L"\System\CurrentControlSet\Services\Evil");
RtlInitUnicodeString(&DriverServiceName, winregPath);
status = NtLoadDriver(&DriverServiceName);

Microsoft ha ora bloccato i percorsi alternativi del Registro di sistema, ma esistono ancora percorsi scrivibili sotto HKLM\System.

Non è raro che i GPO concedano il privilegio SeLoadDriverPrivilege a gruppi di utenti molto ampi, probabilmente a causa dell'errata convinzione che tale privilegio sia necessario affinché gli utenti possano installare le stampanti. Il risultato è un privilegio esposto inutilmente che offre agli aggressori una via diretta per l'esecuzione di codice a livello di kernel.

SeManageVolumePrivilege: accesso alla modifica delle ACL

Il privilegio SeManageVolumePrivilege consente a un utente di eseguire operazioni relative ai volumi, quali la deframmentazione, il montaggio o lo smontaggio dei volumi. Questo privilegio è disponibile in una shell IL di livello medio. Dal punto di vista di un aggressore, lo sfruttamento di questo privilegio offre diverse funzionalità utili:

• Il montaggio di volumi contenenti dati sensibili, con il rischio di aggirare i meccanismi di controllo degli accessi che regolano le modalità di esposizione dei dati attraverso il file system
• La manipolazione dei file system a livello di volume, compresa la modifica dei permessi su interi volumi (Figura 9) — un privilegio che può consentire a un malintenzionato, ad esempio, di modificare l'ACL dell'intera unità C:\ e quindi utilizzare altre tecniche per creare percorsi scrivibili in aree del sistema altrimenti protette

Sebbene questo privilegio sia meno frequente in ambiente reale rispetto a SeImpersonatePrivilege o SeBackupPrivilege, la sua presenza su un account non amministratore dovrebbe essere considerata un rischio grave.

SeRelabelPrivilege: integrità inferiore, rischio maggiore

SeRelabelPrivilege è un privilegio poco conosciuto ma interessante. Secondo la documentazione di Microsoft, questo privilegio“determina quali account utente possono modificare l’etichetta di integrità di oggetti quali file, chiavi di registro o processi di proprietà di altri utenti”.

Senza questo privilegio, un processo può abbassare l'etichetta di integrità solo degli oggetti di cui è proprietario. Con SeRelabelPrivilege, un processo può modificare le etichette di integrità degli oggetti di proprietà di altri utenti, anche elevandole al di sopra del livello di integrità del processo stesso. In altre parole:

• SeRelabelPrivilege consente di acquisire la proprietà di una risorsa anche se il suo livello di autorizzazione (IL) è superiore al proprio.
• Una volta acquisita la titolarità, potrai concederti pieno accesso al processo e ai token.
• Dal punto di vista degli abusi, il risultato è simile a quello di SeDebugPrivilege.
• La manipolazione dell'etichetta obbligatoria è solo una conseguenza.

La motivazione originaria alla base di questo privilegio rimane poco chiara, ma il suo impatto non lo è affatto. Esso consente di acquisire la proprietà di oggetti al di sopra del proprio livello di integrità (Figura 10), rendendolo uno dei privilegi più pericolosi e sottovalutati nel modello di sicurezza di Windows.

Qualsiasi assegnazione al di fuori dei conti amministrativi sottoposti a rigorosi controlli dovrebbe essere esaminata con attenzione e considerata un segnale di allarme.

SeTakeOwnershipPrivilege: Adesso sei nostro

Questo privilegio fa esattamente ciò che suggerisce il suo nome: consente a chi ne è titolare di acquisire la proprietà di qualsiasi oggetto protetto presente nel sistema. Le due chiamate API pertinenti utilizzano entrambe il OWNER_SECURITY_INFORMATION bandiera:

• SetSecurityInfo()
• SetNamedSecurityInfo()

I tipi di oggetti che possono essere presi di mira sono molteplici: file, stampanti, risorse condivise, servizi, chiavi di registro e oggetti del kernel.

Una volta stabilita la proprietà, si applicano le stesse tecniche di manipolazione dei file e del registro utilizzate nell’esplorazione della vulnerabilità SeRestorePrivilege. Un esempio pratico è quello di prendere di mira il msiserver Servizio (Windows Installer):

Passaggio 1. Assumere la proprietà della chiave di registro del servizio:

      wchar_t infile[] = L"SYSTEM\CurrentControlSet\Services\msiserver";
PSID UserSid = GetCurrentUserSID();
dwRes = SetNamedSecurityInfoW(
infile,
SE_REGISTRY_KEY,
OWNER_SECURITY_INFORMATION,
UserSid, NULL, NULL, NULL
);

Passaggio 2. Modificare i permessi della chiave di registro per concedere l'accesso completo:

      ea[0].grfAccessPermissions = KEY_ALL_ACCESS;
ea[0].grfAccessMode = SET_ACCESS;
ea[0].grfInheritance = NO_INHERITANCE;
ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
ea[0].Trustee.ptstrName = (LPTSTR)pSIDEveryone;
SetEntriesInAcl(NUM_ACES, ea, NULL, &pACL);

Passaggio 3. Modificare il file di configurazione del servizio ImagePath per eseguire un comando arbitrario:

      std::string buffer = "cmd.exe /c net localgroup administrators hacker /add";
stat = RegSetValueExA(
hk, "ImagePath", 0, REG_EXPAND_SZ,
(const BYTE*)buffer.c_str(), buffer.length() + 1
);

Quando l'utente avvia il servizio, questo esegue il comando controllato dall'autore dell'attacco con l'account SYSTEM.

SeTCBPrivilege: Usurpazione dell'identità

SeTCBPrivilege è uno dei privilegi più insoliti presenti in questo elenco. La documentazione lo descrive come “agire come parte integrante del sistema operativo,” ma la conseguenza pratica è la possibilità di utilizzare LsaLogonUser() assumere l'identità di qualsiasi utente, senza bisogno delle credenziali di tale utente.

Il meccanismo in questione è il Service For User Logon (S4ULogon), una funzionalità che consente a un processo dotato del privilegio SeTCBPrivilege di ottenere un token di sicurezza per un utente qualsiasi. È fondamentale sottolineare che il processo chiamante può richiedere che al token risultante vengano aggiunte ulteriori appartenenze a gruppi o privilegi, compresi gruppi a cui l’utente non appartiene effettivamente:

      pS4uLogon->MessageType = MsV1_0S4ULogon;
// SzUsername=UTENTE DI DESTINAZIONE DA IMPERSONARE
InitUnicodeString(&pS4uLogon->UserPrincipalName, szUsername, pbPosition);
InitUnicodeString(&pS4uLogon->DomainName, szDomain, pbPosition);

// Aggiungi S-1-5-32-544 (Amministratori locali) al token
ConvertStringSidToSid("S-1-5-32-544", &pExtraSid);
pGroups->Groups[pGroups->GroupCount].Attributes =
SE_GROUP_ENABLED | SE_GROUP_ENABLED_BY_DEFAULT | SE_GROUP_MANDATORY;
pGroups->Groups[pGroups->GroupCount].Sid = pExtraSid;
Status = LsaLogonUser(…)

Il token di impersonificazione risultante, valido nel contesto del computer locale, può essere utilizzato per impersonare i thread senza richiedere privilegi aggiuntivi come SeImpersonatePrivilege. Ciò rende SeTcbPrivilege una primitiva autonoma per l'escalation dei privilegi.

Da PowerShell, il percorso di S4ULogon di Kerberos è il seguente:

      $ident = [System.Security.Principal.WindowsIdentity]::new("administrator@domain.local")
$ctx = $ident.Impersonate()
try {
[System.IO.File]::WriteAllText("C:\Windows\System32\text.txt", "hello from Domain Admin")
}
finally {
$ctx.Undo()
}

Questo privilegio è assegnato per impostazione predefinita solo all'account SYSTEM. Non vi è alcun motivo legittimo per concederlo ad altri account. Qualsiasi assegnazione a un account diverso da SYSTEM deve essere considerata come un errore di configurazione o un indicatore di compromissione.

Ridurre il rischio di abuso dei privilegi in Windows: contromisure pratiche per gli ambienti Active Directory

Ecco cosa puoi fare oggi per ridurre i rischi legati all'abuso dei privilegi:

• Il comando whoami /priv è una delle prime operazioni che un malintenzionato esegue dopo essersi fatto strada nel sistema. Pertanto, dovrebbe essere anche una delle prime operazioni da eseguire quando si valuta lo stato di sicurezza di un account sensibile.
• Esaminare tutti gli oggetti GPO che assegnano privilegi tramite Configurazione computer → Impostazioni di Windows → Impostazioni di sicurezza → Criteri locali → Assegnazione dei diritti utente nell’intero dominio. Verificare le assegnazioni effettive su tutti i sistemi, prestando particolare attenzione alle risorse di livello 0. Questo è il vettore principale per la distribuzione involontaria dei privilegi. Verificare non solo ciò che è configurato esplicitamente, ma anche i criteri che ne derivano, poiché l’ereditarietà e la precedenza degli oggetti GPO spesso producono assegnazioni che nessun amministratore avrebbe mai voluto. Rimuovere tutto ciò che non è giustificato dal punto di vista operativo.
• Verificare l'appartenenza ai gruppi predefiniti con potenti insiemi di privilegi: Operatori di backup, Operatori di stampa, Operatori di server, Operatori di account.
• Gli account di servizio dovrebbero essere eseguiti con i privilegi minimi necessari. Per impostazione predefinita, gli account di servizio dispongono del privilegio SeImpersonatePrivilege. È possibile limitare i privilegi assegnati tramite il Required Privileges chiave di registro nella configurazione del servizio; si tratta di una buona pratica di rafforzamento della sicurezza. Tuttavia, occorre tenere presente che un malintenzionato potrebbe riottenere tali privilegi in determinate condizioni, pertanto è opportuno considerare questo passaggio come un livello di una più ampia strategia di difesa a più livelli piuttosto che come una misura di mitigazione completa.
• Controllare che whoami /priv esecuzione e per le chiamate API relative alla gestione dei token (DuplicateToken, ImpersonateLoggedOnUser, CreateProcessWithToken, LsaLogonUser) nella telemetria EDR.
• Considerare qualsiasi account in grado di effettuare l'accesso locale a un DC come risorsa di livello 0, indipendentemente dal fatto che figuri o meno nel gruppo "Domain Admins".

Non lasciare che l'abuso dei privilegi di Windows metta a rischio la tua organizzazione

Vale la pena ribadirlo: poiché i privilegi discussi in questo post funzionano come previsto, il rischio di abuso dei privilegi di Windows — e le tecniche di attacco che tale abuso rende possibili — esiste anche in ambienti ben aggiornati. Gli autori di attacchi malevoli possono utilizzare queste tecniche per compromettere Active Directory ed elevare i propri privilegi all’interno della vostra organizzazione. Non sottovalutate il rischio; adottate fin da oggi le misure necessarie per proteggere la vostra resilienza informatica.

Ulteriori ricerche specialistiche

• Biblioteca di ricerca sulla sicurezza dell'identità di Semperis
• Catalogo delle minacce all'identità di Semperis
• Cosa c'è da sapere: Escalation dei privilegi in remoto in Windows Admin Center (CVE-2026-26119)

Fonti

• https://foxglovesecurity.com/2017/08/25/abusing-token-privileges-for-windows-local-privilege-escalation/
• https://decoder.cloud/2018/01/13/potato-and-tokens/
• https://decoder.cloud/2018/02/12/the-power-of-backup-operatos/
• https://decoder.cloud/2019/07/04/creating-windows-access-tokens/
• https://decoder.cloud/2020/05/30/the-impersonation-game/
• https://decoder.cloud/2022/09/21/giving-juicypotato-a-second-chance-juicypotatong/
• https://decoder.cloud/2020/11/05/hands-off-my-service-account/
• https://decoder.cloud/2020/12/14/hands-off-my-iis-accounts/
• https://decoder.cloud/2024/05/30/abusing-the-serelabelprivilege/
• https://github.com/xct/SeManageVolumeAbuse