• Guide, Sicurezza, Sistemi Operativi
• 6 Luglio 2026

Quando si parla di sicurezza Active Directory, quasi sempre si parte dagli stessi punti: Domain Admin, Kerberos, NTLM, service account, deleghe, ACL, certificati, Domain Controller.

Tutto giusto. Ma c’è un componente che spesso rimane sullo sfondo, proprio perché è troppo normale per sembrare interessante: SYSVOL.

SYSVOL è una di quelle cose che gli amministratori vedono da anni, usano da anni, danno per scontata da anni. È lì, sui Domain Controller. È replicata. È necessaria. È consultata dai client. Contiene script, policy, template, configurazioni e file usati dalle Group Policy. In altre parole: SYSVOL non è semplicemente una share. È uno dei luoghi in cui Active Directory smette di essere un database e diventa comportamento sui client.

Ed è proprio per questo che va considerata parte della superficie d’attacco.

Group Policy: non solo LDAP

Una Group Policy Object, o GPO, viene spesso vista dalla console Group Policy Management come un oggetto unico. In realtà, sotto il cofano, una GPO è composta da due elementi distinti.

Il primo è il Group Policy Container, o GPC. È la parte LDAP della GPO. Vive in Active Directory e contiene metadati come nome, stato, versione, attributi, percorso del template e informazioni usate dai client per capire cosa elaborare.

Il secondo è il Group Policy Template, o GPT. È la parte file della GPO. Vive normalmente dentro SYSVOL ed è raggiungibile tramite SMB. Qui si trovano i file che descrivono concretamente le configurazioni da applicare ai client: impostazioni di registro, configurazioni di sicurezza, script, preferenze, scheduled task, gruppi locali e altro ancora.

Questa doppia natura è fondamentale. Una GPO non è solo un oggetto Active Directory. È un oggetto Active Directory che punta a un contenuto file. Il client legge entrambi: interroga Active Directory per capire quali GPO deve applicare, poi raggiunge il relativo percorso in SYSVOL per recuperare le configurazioni.

La presentazione DEFCON “Turning your Active Directory into the attacker’s C2” (approfondiremo in altri articoli anche questo aspetto) sintetizza bene questo punto: le GPO sono composte da un GPC, cioè un oggetto LDAP, e da un GPT, cioè una struttura file accessibile tramite SMB, generalmente collocata in SYSVOL.

Figura 1 – Group Policy Management Editor

Figura 2 – Sysvol – GPO

Perché questo cambia il modo in cui guardiamo SYSVOL

Il punto non è solo tecnico. È concettuale. SYSVOL è pericoloso non perché sia nascosto, ma perché è normale.

Tutti sanno che esiste. Tutti sanno che serve. Tutti sanno che i client devono poterlo leggere. Proprio per questo, spesso non viene osservato con la stessa attenzione riservata ad altri componenti di Active Directory.

Eppure dentro SYSVOL possono esserci informazioni estremamente utili per un attaccante.

Un file Groups.xml, ad esempio, può rivelare che un certo gruppo di dominio viene aggiunto ai Remote Desktop Users locali di alcune workstation.

Un file Registry.xml può mostrare quali chiavi di registro vengono usate per applicare hardening, disabilitare protocolli legacy, configurare software, modificare servizi o cambiare impostazioni di sicurezza.

Un file GptTmpl.inf può contenere configurazioni di sicurezza locali, assegnazioni di privilegi utente, membership di gruppi e parametri che influenzano direttamente il comportamento della macchina.

Uno script di logon o startup può raccontare molto più di quanto dovrebbe: percorsi interni, nomi server, share applicative, agent installati, vecchie logiche amministrative, dipendenze rimaste in produzione più per sedimentazione che per scelta.

Figura 3 – Struttura della cartella Machine dentro la GPO

Per ottenere un file Registry.xml come questo, devi creare una Group Policy Preference che definisce una chiave di registro.

Apri la Group Policy Management Console, crea o modifica una GPO e vai in Computer Configuration → Preferences → Windows Settings → Registry. Qui aggiungi una nuova voce di tipo Registry Item.

Configura l’azione su Create o Update, imposta l’hive su HKEY_LOCAL_MACHINE, inserisci il percorso della chiave (ad esempio SOFTWARE\ICTPower\SYSVOL), il nome del valore (per esempio Demo), il tipo (REG_SZ) e il dato che vuoi scrivere.

Una volta salvata la configurazione, la GPO genererà automaticamente il file Registry.xml all’interno di SYSVOL, nel percorso Machine\Preferences\Registry della GPO.

Figura 4 – GPO creazione chiave registro

Per generare un file Groups.xml tramite GPO devi usare una Group Policy Preference nella sezione Local Users and Groups. In pratica:

• Apri la Group Policy Management Console (gpmc.msc)
• Crea una nuova GPO oppure modifica una GPO esistente
• Vai in:
  Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups
• Click destro → New → Local Group
• Imposta:
  • Action: Update (o Replace, a seconda del comportamento desiderato)
  • Group name: ad esempio “Remote Desktop Users”
• Nella sezione Members:
  • Click su Add
  • Inserisci il gruppo di dominio (es. LAB\GPO-Demo-RDP)
• Applica e chiudi la GPO

A questo punto, quando la GPO viene salvata, Windows crea automaticamente il file Groups.xml nel percorso SYSVOL della GPO:

\dominio.local\SYSVOL\dominio.local\Policies{GUID}\Machine\Preferences\Groups\Groups.xml

Non devi creare manualmente il file: viene generato dalla configurazione della Group Policy Preference.

Figura 5 – GPO Aggiornamento gruppo AD

Figura 6 – Sysvol

Figura 7 – Sysvol – GPO registro

Figura 8 – Sysvol – GPO Gruppi

Figura 9 – Sysvol – Files GPO

Il problema, quindi, non è soltanto “chi può modificare una GPO”. Il problema è anche “cosa raccontano le GPO a chi può leggerle”. E in molti domini Active Directory la lettura di SYSVOL è ampia per progettazione, perché i client e gli utenti del dominio devono poter recuperare le policy applicabili.

SYSVOL come superficie di ricognizione

La prima dimensione del rischio è la ricognizione. Un attaccante che ottiene un account di dominio, anche non privilegiato, può spesso leggere SYSVOL. Questo non significa automaticamente compromissione, ma significa visibilità. E la visibilità, in Active Directory, vale molto.

Guardando le GPO si può capire come è organizzato il dominio, quali OU ricevono determinate configurazioni, dove viene consentito RDP, quali gruppi diventano amministratori locali, quali controlli di sicurezza sono stati applicati e quali invece sembrano assenti. È una ricognizione diversa dalla scansione classica. Non devo necessariamente interrogare ogni host della rete. Non devo fare tentativi rumorosi su migliaia di indirizzi IP. Posso leggere ciò che l’ambiente dichiara di voler applicare. È la differenza tra bussare a ogni porta di un palazzo e trovare l’elenco delle chiavi nella stanza del custode.

Nella presentazione DEFCON già citata, la parte di enumeration evidenzia proprio questo aspetto: l’analisi delle GPO può rivelare membership, privilege assignments, modifiche di registro e scheduled task, cioè informazioni utili per comprendere postura di sicurezza e possibili percorsi di movimento laterale.

Figura 10 – Lettura del percorso SYSVOL della GPO tramite PowerShell

Esempio:

Il risultato più importante, in questa fase, è gPCFileSysPath: l’attributo che indica il percorso UNC del Group Policy Template, cioè dove si trovano i file della GPO.

Figura 11 – Output PowerShell con displayName, gPCFileSysPath e flags

A questo punto possiamo esplorare il contenuto della GPO lato file system:

Quello che stiamo guardando non è un dettaglio interno privo di significato. È la parte della GPO che i client useranno per applicare configurazioni.

SYSVOL come superficie di distribuzione

La seconda dimensione del rischio è ancora più importante: distribuzione. Una GPO non è solo informazione. È istruzione.

Se configuro una chiave di registro tramite Group Policy Preference, quella chiave viene applicata ai client interessati.

Se configuro l’appartenenza a un gruppo locale, quella membership viene applicata ai client interessati.

Se configuro una scheduled task, quella attività viene creata sui client interessati.

Se configuro uno script di startup, quello script viene eseguito all’avvio dei computer interessati.

Questo rende SYSVOL diverso da una share documentale. Un file dentro una cartella condivisa normalmente viene aperto da qualcuno. Un file dentro il GPT di una GPO può essere processato automaticamente da un client di dominio. È qui che Active Directory diventa “sistema nervoso” dell’ambiente.

La console GPMC ci mostra un’interfaccia ordinata, quasi rassicurante. Ma dietro quella console ci sono attributi LDAP, link alle OU, percorsi UNC, file XML e client-side extensions che traducono il contenuto della GPO in modifiche reali sulla macchina.

Sul client, dopo l’applicazione della policy, possiamo verificare la presenza della chiave:

Figura 12 – Verifica applicazione GPO

Figura 13 – Verifica funzionamento GPO

La dimostrazione è semplice, ma il concetto è enorme: un file generato dentro SYSVOL è diventato una modifica concreta su una macchina di dominio.

Un esempio più vicino alla sicurezza: gruppi locali

Per rendere il laboratorio più interessante dal punto di vista cybersecurity, possiamo aggiungere un secondo esempio, sempre controllato e non distruttivo: la gestione di un gruppo locale.

Creiamo un gruppo di dominio chiamato:

LAB\GPO-Demo-RDP

Figura 14 – Creazione nuovo gruppo

Poi configuriamo una Group Policy Preference per aggiungere questo gruppo al gruppo locale:

Remote Desktop Users

Figura 15 – GPO Modifica gruppo

Non stiamo facendo nulla di malevolo. È una normale operazione amministrativa. Ma è proprio questo il punto: una normale operazione amministrativa può diventare un percorso di attacco se viene modificata da un’identità non autorizzata.

Figura 16 – Sysvol – File GPO

Sul client possiamo verificare:

Figura 17 – Verifica applicazione GPO

A questo punto la domanda per il lettore diventa naturale: se una GPO può aggiungere un gruppo ai Remote Desktop Users locali, cosa succede se qualcuno ottiene il diritto di modificare quella GPO?

La risposta è scomoda: non serve necessariamente compromettere subito un Domain Controller. Potrebbe bastare modificare una policy che si applica a macchine interessanti. Ed è per questo che le deleghe sulle GPO sono così delicate.

Non tutte le modifiche passano dallo stesso punto

Un errore comune è pensare che basti controllare Active Directory “lato LDAP”.

In realtà, una modifica significativa a una GPO può coinvolgere sia la parte LDAP sia la parte SYSVOL.

La parte LDAP contiene informazioni come:

displayName

gPCFileSysPath

flags

gPCMachineExtensionNames

gPCUserExtensionNames

versionNumber

La parte SYSVOL contiene invece i file veri e propri, come:

Registry.xml

Groups.xml

GptTmpl.inf

Scripts.ini

ScheduledTasks.xml

registry.pol

Questo significa che, per monitorare correttamente le GPO, dobbiamo guardare entrambi i mondi.

Se cambia un attributo LDAP della GPO, vogliamo saperlo.

Se cambia un file dentro SYSVOL, vogliamo saperlo.

Se cambia un link tra GPO e OU, vogliamo saperlo.

Se cambia il percorso gPCFileSysPath, vogliamo saperlo molto rapidamente.

Quest’ultimo punto è particolarmente delicato, perché gPCFileSysPath indica dove si trova il GPT. Nella normalità punta al percorso SYSVOL del dominio, ma la possibilità di manipolare questo attributo è stata discussa anche in scenari offensivi avanzati: se il client viene indotto a recuperare il template da un percorso SMB diverso, la superficie di rischio cambia radicalmente.

Non è il primo scenario da testare in produzione e non è il punto da cui partire in un ambiente reale. Ma è un promemoria importante: le GPO non sono solo “impostazioni grafiche” dentro una console. Sono relazioni tra oggetti LDAP, percorsi UNC e file consumati dai client.

Cosa monitorare

Ci sono almeno quattro aree da controllare. La prima è la delega amministrativa sulle GPO. Chi può creare GPO? Chi può modificarle? Chi può linkarle a una OU? Chi può cambiare i permessi? Chi può modificare una GPO applicata a server critici, jump server, workstation amministrative o Domain Controller?

Per eseguire questo controllo in modo pratico, è possibile partire dalla Group Policy Management Console (GPMC). Apri la console, espandi il dominio e vai nella sezione “Group Policy Objects”. Per ogni GPO rilevante, apri le proprietà e controlla la tab “Delegation”: qui trovi gli utenti e i gruppi che hanno diritti di lettura, modifica o controllo completo. Cliccando su “Advanced” puoi vedere nel dettaglio le ACL e capire esattamente quali permessi sono assegnati.

Figura 18 – Group Policy Management – Verifica delega

Figura 19 – Verifica configurazioni di sicurezza GPO

Per verificare chi può creare nuove GPO, è possibile controllare i permessi sul contenitore “Group Policy Objects” a livello di dominio. Sempre da GPMC, clic destro su “Group Policy Objects”, seleziona “Delegation”: gli utenti o gruppi con permessi di creazione (tipicamente membri di “Group Policy Creator Owners”) sono quelli che possono creare nuove policy.

Figura 20 – Verifica delega da GPMC

Per capire chi può linkare una GPO a una OU, controllare i permessi direttamente sull’OU. Aprire “Active Directory Users and Computers”, abilita “Advanced Features”, poi vai sulle proprietà della OU e controlla la tab “Security”. Qui cerca permessi come “Link GPOs” o “Write gPLink”.

Figura 21 – Verifica ADUC

Figura 22 – Verifica permessi su OU tramite GPMC

La seconda è la modifica degli attributi LDAP.

Eventi come le modifiche agli oggetti groupPolicyContainer e agli attributi delle OU possono essere molto importanti. In particolare, vanno osservati attributi come gPCFileSysPath, gPCMachineExtensionNames, gPCUserExtensionNames, versionNumber, flags e gPLink.

Esempio di ricerca base sugli eventi Directory Service Changes:

Figura 23 – EventID 5136 relativo a modifica GPO o gPLink

La terza è la modifica dei file dentro SYSVOL.

Per questo serve configurare correttamente l’auditing sul file system, perché non basta sperare che Windows ci mostri magicamente ogni modifica significativa. Bisogna abilitare la subcategory corretta e impostare SACL mirate sui percorsi da monitorare.

Esempio:

Poi, sui percorsi interessati dentro SYSVOL, va configurato l’auditing per le operazioni di scrittura, creazione, modifica, eliminazione e cambio permessi.

Trovo la GPO ed applico le corrette SACL

Figura 24 – Audit e verifica SACL

Verifico che sia tutto ok

Figura 25 – Verifica SACL

Se, ora, modifico qualcosa, genero un EventID 4663

Figura 26 – Ricerca EventID 4663

La quarta è il risultato sui client.

Non basta vedere che la GPO è stata modificata. Bisogna capire dove è stata applicata.

Qui entrano in gioco strumenti semplici ma ancora utilissimi:

oppure:

Figura 27 – GPResult su Client

In un’indagine reale, questa parte è fondamentale: sapere che una policy è stata modificata è solo metà della storia. L’altra metà è capire quali computer e quali utenti hanno ricevuto quella modifica.

Hardening: cosa fare davvero

La protezione di SYSVOL e delle GPO non si risolve con un singolo flag.

Serve un approccio ordinato.

Prima cosa: ridurre le deleghe non necessarie.

Molti ambienti Active Directory hanno accumulato deleghe nel tempo. Gruppi creati per vecchi progetti. Utenti tecnici mai rimossi. Team che dovevano gestire “solo una policy” e che oggi hanno diritti più ampi del necessario.

Le GPO applicate a sistemi critici devono essere trattate come asset critici.

Seconda cosa: separare il diritto di modificare una GPO dal diritto di linkarla.

Modificare una GPO è pericoloso. Linkare una GPO a una OU può esserlo ancora di più. Una policy innocua, se applicata al posto sbagliato, può diventare devastante.

Terza cosa: controllare periodicamente i contenuti di SYSVOL.

Non basta guardare la console GPMC. Bisogna ispezionare anche i file. Vecchi script, preferenze dimenticate, configurazioni legacy e riferimenti a share non più gestite possono creare esposizione.

Quarta cosa: monitorare le modifiche.

Le modifiche alle GPO dovrebbero generare evidenza. Non necessariamente un incidente, ma almeno una traccia visibile. Chi ha modificato cosa? Quando? Su quale GPO? Quale file è cambiato? Quale OU è stata coinvolta?

Quinta cosa: usare naming, ownership e documentazione.

Una GPO senza proprietario è un rischio. Una GPO chiamata “test nuova policy” applicata da cinque anni a una OU produttiva è un classico. Una GPO disabilitata ma piena di configurazioni sensibili è un altro classico.

In Active Directory, l’entropia è un avversario silenzioso.

Il punto vero

Alla fine, SYSVOL è parte della superficie d’attacco perché contiene configurazioni che i client del dominio si fidano ad applicare.

Questo è il punto.

Non stiamo parlando di una share qualunque. Stiamo parlando di una componente fondamentale del meccanismo con cui Active Directory distribuisce configurazioni a utenti e computer.

Un attaccante può usare SYSVOL per capire l’ambiente.

Un amministratore distratto può lasciarci dentro informazioni inutilmente sensibili.

Una delega sbagliata può trasformare una GPO in un meccanismo di distribuzione di configurazioni pericolose.

Un monitoring incompleto può non accorgersi che una modifica apparentemente piccola ha cambiato il comportamento di decine, centinaia o migliaia di macchine.

Per questo, quando valutiamo la sicurezza di Active Directory, non dobbiamo chiederci soltanto:

chi è Domain Admin?

Dobbiamo chiederci anche:

chi può cambiare il comportamento dei client?

Molto spesso la risposta passa da una GPO, da un link a una OU e da un file dentro SYSVOL.

Ed è lì che una normale infrastruttura di gestione può diventare, nel peggiore dei casi, il canale di comando più fidato dell’intero dominio.

Conclusione

SYSVOL è uno di quei componenti che rischiano di diventare invisibili proprio perché funzionano da sempre. È presente in ogni dominio Active Directory. Viene replicato tra Domain Controller. Viene letto dai client. Viene usato dalle Group Policy. Fa parte della normalità operativa di qualsiasi infrastruttura Microsoft tradizionale. Ma la normalità, in sicurezza, è spesso il posto migliore in cui si nascondono i rischi.

In questo articolo abbiamo visto che SYSVOL non è una semplice share di servizio. È il punto in cui una GPO smette di essere un oggetto amministrativo dentro una console e diventa file, configurazione, istruzione, comportamento applicato sui client.

Una chiave di registro configurata tramite Group Policy Preference diventa un file XML dentro SYSVOL.

Una modifica ai gruppi locali diventa un file Groups.xml.

Una configurazione di sicurezza può finire dentro GptTmpl.inf.

Uno script di startup o logon può diventare codice eseguito automaticamente da macchine e utenti del dominio.

Questo cambia completamente la prospettiva.

Quando analizziamo la sicurezza di Active Directory, non possiamo limitarci a chiederci chi è membro di Domain Admins o quali account hanno privilegi elevati. Dobbiamo anche chiederci chi può modificare ciò che i client del dominio si fidano ad applicare. Perché una delega errata su una GPO, un link applicato alla OU sbagliata, una modifica non monitorata dentro SYSVOL o una vecchia policy dimenticata possono avere conseguenze molto più ampie di quanto sembri. Il laboratorio lo mostra in modo semplice: una configurazione creata dalla console GPMC genera un file in SYSVOL; quel file viene letto dal client; il client applica la modifica. Non c’è nulla di anomalo. Non c’è nulla di “esotico”. È esattamente il comportamento previsto. Ed è proprio questo il punto. Le tecniche più pericolose non sono sempre quelle che sfruttano componenti sconosciuti. A volte sfruttano componenti perfettamente legittimi, documentati e fidati. SYSVOL rientra in questa categoria: non è un’anomalia dell’infrastruttura, è una sua funzione centrale.

Per questo motivo, una strategia di hardening di Active Directory dovrebbe includere almeno quattro attività ricorrenti:

controllare chi può modificare le GPO;

controllare chi può linkare le GPO alle OU;

analizzare periodicamente il contenuto reale di SYSVOL;

monitorare le modifiche sia lato LDAP sia lato file system.

L’ultimo punto è particolarmente importante. Come abbiamo visto, non basta abilitare genericamente l’auditing e aspettarsi che Windows registri tutto. Per ottenere eventi utili, come il 4663 sulle modifiche ai file, servono audit policy abilitate e SACL configurate sui percorsi corretti. Anche questo è un messaggio operativo importante: la visibilità non esiste per intenzione, esiste solo se viene progettata.

SYSVOL, quindi, non va trattato come una cartella tecnica da ignorare finché tutto funziona. Va trattato come una parte della superficie d’attacco di Active Directory. E in sicurezza, ogni meccanismo di fiducia è anche un possibile punto di abuso.

La domanda finale, quindi, non è solo: chi amministra il dominio?

Ma anche: chi può cambiare il comportamento delle macchine del dominio?

Molto spesso la risposta passa da una GPO, da un link a una OU e da un file dentro SYSVOL. Ed è da lì che conviene iniziare a guardare Active Directory con occhi diversi.

Stay tuned!