• Guide, Sicurezza, Sistemi Operativi
• 27 Aprile 2026

Le Group Policy sono uno degli strumenti più potenti di Active Directory. E proprio per questo sono anche uno degli strumenti più delicati. Per anni le abbiamo considerate soprattutto per quello che fanno dal punto di vista amministrativo: applicano configurazioni, distribuiscono impostazioni di sicurezza, gestiscono script, controllano il firewall, modificano chiavi di registro, assegnano privilegi, configurano utenti e computer.

Tutto corretto. Il problema è che, dal punto di vista di un attaccante, questa descrizione suona in modo molto diverso. Una Group Policy non è solo una configurazione centralizzata. È un meccanismo nativo, distribuito, ricorrente e considerato affidabile dai sistemi Windows joined al dominio. In altre parole: se un attaccante riesce a modificare la GPO giusta, Active Directory può trasformarsi in un canale di comando interno.

Non perché le GPO siano “sbagliate” ma perché fanno esattamente quello per cui sono state progettate: applicare istruzioni su larga scala.

Da strumento amministrativo a superficie critica

In Active Directory ci sono oggetti che tutti usano, molti amministrano e pochi monitorano davvero. Le Group Policy sono tra questi. Su ICTPower ne abbiamo parlato tantissimo, forse l’articolo più dettagliato in merito è Funzionamento delle Group Policy (GPO) in Windows Server di Nicola Ferrini.

In un ambiente Microsoft reale, le GPO possono essere usate per gestire configurazioni di sicurezza, impostazioni utente, policy di password, restrizioni locali, software deployment, Windows Firewall, script di logon e logoff, configurazioni del registro, mapping di rete, privilegi utente, membership dei gruppi locali e molto altro.

Questo le rende estremamente comode. Ma anche estremamente interessanti dal punto di vista della sicurezza.

Il punto non è che una GPO sia vulnerabile di per sé. Il punto è che una GPO, se modificata da chi non dovrebbe poterla modificare, permette di cambiare il comportamento di molti sistemi contemporaneamente usando un meccanismo perfettamente legittimo.

È qui che nasce il problema.

Una modifica malevola a una GPO non assomiglia necessariamente a un exploit rumoroso. Può sembrare una normale attività amministrativa. Può essere distribuita dal Domain Controller. Può essere applicata dai client durante il normale refresh delle policy. Può arrivare su server, workstation, jump server o sistemi amministrativi senza richiedere connessioni dirette verso ogni singola macchina.

In mano a un amministratore, le Group Policy sono automazione. In mano a un attaccante, possono diventare distribuzione, persistenza e movimento laterale.

Figura 1 – Group Policy Management Console

Le GPO sono spesso numerose, storiche e non sempre documentate. Il primo controllo è sapere quante sono, a cosa servono e dove vengono applicate.

Come è fatta una Group Policy

Per capire perché le GPO siano così importanti anche dal punto di vista difensivo, bisogna ricordare un dettaglio spesso sottovalutato: una Group Policy non è un singolo oggetto. È composta da due parti principali.

La prima è il Group Policy Container, o GPC.

Il GPC è l’oggetto presente in Active Directory. Contiene metadati, attributi, stato della GPO, versione, informazioni di collegamento, ACL e riferimenti alla parte file system della policy.

La seconda è il Group Policy Template, o GPT.

Il GPT risiede nel SYSVOL dei Domain Controller e contiene i file effettivi della policy: template di sicurezza, script, impostazioni del registro, configurazioni XML, scheduled task, preferenze e altri elementi applicati dai client.

In forma semplificata:

Figura 2 – GPO

Il collegamento tra una GPO e gli oggetti a cui si applica avviene attraverso i link alle OU, ai domini o ai site. In Active Directory, questo collegamento è rappresentato anche da attributi come gPLink.

Il percorso verso il template della policy è invece indicato dall’attributo gPCFileSysPath, che normalmente punta a una posizione all’interno di SYSVOL.

Figura 3 – GPO nel SYSVOL

Il Group Policy Template risiede in SYSVOL e contiene i file applicati dai client. Anche questa parte deve essere protetta e monitorata.

Questi dettagli non sono solo teoria. Sono punti di controllo.

Se un attaccante può modificare il GPC, può alterare attributi importanti della GPO. Se può modificare il GPT, può cambiare i file che i client useranno per applicare la configurazione. Se può modificare il link a una OU, può influenzare quali sistemi riceveranno una determinata policy.

Il problema delle deleghe

Molte organizzazioni controllano con attenzione chi è membro del gruppo Domain Admins. È giusto. Ma non basta. In Active Directory, il privilegio reale non coincide sempre con l’appartenenza esplicita a un gruppo privilegiato. Un account che può modificare una GPO applicata a sistemi critici può avere un impatto enorme, anche se non è Domain Admin. Un gruppo che può linkare GPO a una OU può cambiare quali configurazioni vengono applicate agli oggetti contenuti in quella OU. Un account che può modificare le ACL di una GPO può concedere ad altri la possibilità di alterarla. Un amministratore delegato che può intervenire su una OU operativa potrebbe, in alcuni scenari, influenzare sistemi molto più sensibili di quanto previsto.

Il problema, quindi, non è solo chi può accedere a un server. È chi può cambiare le regole che quel server applicherà al prossimo refresh delle policy. Immaginiamo uno scenario semplice. Un account di amministrazione di secondo livello ha permessi di modifica su una GPO collegata alla OU dei jump server.

Non è Domain Admin. Non può modificare tutto il dominio. Non ha accesso diretto ai Domain Controller. Ma può modificare una GPO applicata a server usati da amministratori privilegiati. In quel momento, il confine tra delega operativa e percorso di escalation diventa molto sottile. Non basta quindi sapere chi è Domain Admin.

Bisogna sapere chi può modificare ciò che viene applicato ai Domain Admin, ai loro server, ai loro strumenti e ai sistemi che usano per amministrare l’ambiente.

Figura 4 – Deleghe GPO

Il controllo delle deleghe è uno dei punti più importanti nella sicurezza delle Group Policy. Non basta sapere chi può leggerle: bisogna sapere chi può modificarle.

GPO abuse non significa solo malware

Quando si parla di abuso delle Group Policy, il pensiero va subito all’esecuzione di codice. È comprensibile, ma è una visione troppo stretta. Una GPO compromessa può essere usata anche per modificare configurazioni, indebolire controlli, creare persistenza, abilitare servizi, cambiare privilegi o alterare gruppi locali. In alcuni casi l’obiettivo non è distribuire un payload, ma rendere l’ambiente più favorevole all’attaccante. Per esempio, una modifica malevola potrebbe puntare a:

• aggiungere un gruppo controllato agli amministratori locali di alcune macchine;
• abilitare servizi remoti non previsti;
• modificare regole firewall;
• alterare impostazioni di sicurezza;
• modificare privilegi assegnati agli utenti;
• introdurre task pianificati inattesi;
• modificare impostazioni del registro;
• cambiare script di logon o startup;
• indebolire controlli difensivi già presenti.

Il punto non è solo “eseguire qualcosa” ma modificare il comportamento dell’ambiente usando un meccanismo che i sistemi considerano legittimo. Ed è questo che rende il tema così delicato. Molte attività possono apparire amministrative, soprattutto se non esiste un processo chiaro di change management sulle GPO. Se nessuno sa chi dovrebbe modificare una policy, quando, perché e con quale approvazione, distinguere una modifica legittima da una pericolosa diventa molto più difficile.

Dal punto di vista dell’attaccante: cosa cerca davvero in una GPO

Per un difensore, una Group Policy è spesso una configurazione da mantenere ordinata. Per un attaccante, invece, una GPO è prima di tutto una mappa. Una mappa che racconta come è organizzato l’ambiente, quali sistemi sono più interessanti, quali utenti possono accedere dove, quali gruppi vengono aggiunti localmente, quali servizi vengono abilitati, quali impostazioni di sicurezza sono presenti e quali controlli potrebbero essere aggirati. Il primo valore offensivo delle GPO non è necessariamente l’esecuzione di codice. È la ricognizione. Una GPO può rivelare che un determinato gruppo viene aggiunto agli amministratori locali di alcune workstation. Può indicare che un gruppo ha diritto di accesso RDP a una specifica OU. Può mostrare privilegi assegnati tramite security template. Può esporre scheduled task, script, configurazioni firewall, impostazioni del registro, configurazioni di hardening o eccezioni create nel tempo per far funzionare applicazioni legacy.

Dal punto di vista dell’attaccante, queste informazioni sono preziose perché riducono il rumore. Invece di eseguire scansioni ampie, tentare accessi a caso o interrogare decine di sistemi, l’attaccante può studiare le policy e capire quali percorsi hanno più probabilità di funzionare. Non sta ancora compromettendo nulla. Sta scegliendo meglio dove andare. Uno degli errori più comuni è pensare alle GPO solo come a un vettore di modifica. In realtà sono anche un vettore di lettura. Leggere bene le GPO significa capire come l’organizzazione distribuisce privilegi, accessi, eccezioni e configurazioni di sicurezza.

La catena di attacco: dalle policy alla compromissione

Un abuso delle Group Policy raramente nasce dal nulla. Di solito segue una sequenza abbastanza prevedibile. La prima fase è la ricognizione: l’attaccante enumera GPO, OU, link, ereditarietà, filtri di sicurezza, gruppi locali, privilegi assegnati, script e configurazioni applicate ai sistemi.

La seconda fase è la selezione del target: non tutte le GPO hanno lo stesso valore. Una policy applicata a workstation generiche può essere interessante, ma una GPO collegata a jump server, sistemi amministrativi, server applicativi critici o Domain Controller ha un peso completamente diverso.

La terza fase è la verifica dei permessi: l’attaccante cerca account o gruppi che possano modificare una GPO, alterarne le ACL, modificarne il template in SYSVOL o collegarla a una OU sensibile.

La quarta fase è l’abuso della funzionalità nativa: invece di introdurre un meccanismo esterno, l’attaccante usa quello che Active Directory già offre. Scheduled task, script, membership locali, registry settings, configurazioni firewall o privilegi utente diventano primitive operative.

La quinta fase è la persistenza o espansione: la modifica può essere temporanea, mirata, limitata a specifici sistemi o pensata per riapparire nel tempo se nessuno controlla davvero il ciclo di vita delle GPO. Vista così, una Group Policy compromessa non è solo una configurazione alterata.

È un passaggio della catena di attacco.

Figura 5 – GPO Kill Chain

Perché una GPO può diventare un canale di comando

Senza trasformare il tema in una guida operativa, ci sono alcuni scenari che ogni amministratore Active Directory dovrebbe conoscere.

Il primo è la GPO come fonte di ricognizione.

Una policy può raccontare molto più di quanto sembri: gruppi locali, privilegi, script, scheduled task, configurazioni registry, impostazioni di hardening, eccezioni firewall, software distribuito e regole applicate solo a determinati target.

Il secondo è l’abuso delle ACL sulle GPO.

Dal punto di vista offensivo, una delega eccessiva su una GPO può valere più di un accesso diretto a un server. Se quella GPO viene applicata a sistemi sensibili, il permesso di modificarla diventa un permesso indiretto su quei sistemi.

Il terzo è la separazione tra GPC e GPT.

Molti controlli si concentrano sulla Group Policy Management Console, ma un attaccante guarda anche agli attributi LDAP della GPO e al percorso del template. Se il percorso del GPT, i file in SYSVOL o la versione della policy non sono coerenti con ciò che ci si aspetta, il problema potrebbe non essere visibile con un controllo superficiale.

Il quarto è il controllo del link tra GPO e OU.

Chi può modificare il collegamento di una GPO a una OU può influenzare quali oggetti riceveranno quella configurazione. Per questo il controllo non deve fermarsi alla GPO in sé, ma deve includere anche le OU, i link, l’ereditarietà e gli eventuali enforcement.

Il mental model dell’attaccante

Un attaccante che guarda le Group Policy non si chiede solo: “cosa posso modificare?”.

Si fa domande più sottili:

• quali GPO si applicano ai sistemi più sensibili?
• quali GPO controllano jump server o workstation amministrative?
• quali gruppi vengono aggiunti localmente tramite policy?
• quali utenti possono accedere via RDP o WinRM?
• quali privilegi vengono assegnati attraverso security template?
• quali script vengono eseguiti automaticamente?
• quali scheduled task esistono già?
• quali eccezioni firewall sono state distribuite?
• quali impostazioni di hardening sono presenti?
• quali policy sembrano obsolete, temporanee o poco presidiate?
• chi può modificare la GPO?
• chi può modificarne le ACL?
• chi può linkarla a una OU diversa?
• chi può scrivere nel relativo percorso SYSVOL?

Queste domande sono offensive solo in apparenza. In realtà sono le stesse domande che dovrebbe porsi un buon difensore. La differenza è che l’attaccante le usa per trovare un percorso. Il difensore dovrebbe usarle per chiuderlo prima.

Dove guardare: i punti critici

Il primo passo difensivo è smettere di considerare le GPO come semplici oggetti di configurazione. Le GPO sono asset di sicurezza. E come tali vanno inventariate, classificate, protette e monitorate. Alcuni punti meritano particolare attenzione:

• GPO collegate a OU critiche;
• GPO applicate ai Domain Controller;
• GPO applicate a server amministrativi o jump server;
• GPO con deleghe non standard;
• GPO modificate di recente;
• GPO con owner inattesi;
• GPO obsolete ma ancora linkate;
• GPO disabilitate ma non rimosse;
• GPO con nomi generici come “Test”, “Temp”, “Old”, “Backup”;
• modifiche agli attributi gPLink e gPCFileSysPath;
• permessi di scrittura su SYSVOL;
• script o scheduled task inattesi all’interno dei template;
• differenze non documentate tra GPC e GPT.

In molte infrastrutture il problema non è la GPO malevola. È la GPO dimenticata. La policy creata anni prima per un test, mai rimossa. La delega temporanea diventata permanente. Il gruppo tecnico che ha ancora permessi di modifica anche se il progetto è finito. La OU riorganizzata senza rivedere i link ereditati. La GPO chiamata “Old” che però viene ancora applicata a server importanti. Active Directory ha memoria lunga. A volte troppo lunga.

Controlli PowerShell utili

La console Group Policy Management è indispensabile, ma non basta.

PowerShell permette di ottenere rapidamente una vista più ampia delle GPO presenti nell’ambiente, delle modifiche recenti e dei permessi configurati.

Per elencare tutte le GPO:

 

Per identificare le GPO modificate negli ultimi 30 giorni:

 

Per visualizzare i permessi configurati su una GPO specifica:

 

Per ottenere i link GPO configurati sulle OU:

 

Per verificare l’ereditarietà delle Group Policy su un target specifico:

 

Per eseguire un backup difensivo delle GPO:

Questi comandi non sostituiscono un audit completo, ma sono un buon punto di partenza per capire quante GPO esistono, chi le possiede, quando sono state modificate e quali deleghe sono presenti.

Figura 6 – PowerShell get GPO

Logging e monitoraggio

Il monitoraggio delle GPO non può limitarsi alla console GPMC.

Serve audit sugli oggetti Active Directory, controllo delle modifiche su SYSVOL e correlazione tra chi ha modificato una policy, quale oggetto è stato cambiato, a quale OU è collegata la GPO e quali sistemi la ricevono.

Tra gli eventi da considerare ci sono:

• 5136: un oggetto directory è stato modificato;
• 5137: un oggetto directory è stato creato;
• 5141: un oggetto directory è stato eliminato;
• 4670: i permessi su un oggetto sono stati modificati;
• modifiche agli attributi gPLink, gPCFileSysPath, nTSecurityDescriptor;
• modifiche a file e cartelle in SYSVOL;
• variazioni inattese della versione delle GPO;
• creazione o modifica di script, XML, scheduled task o template di sicurezza nel GPT.

Naturalmente questi eventi devono essere raccolti e interpretati nel contesto corretto.

Un Event ID 5136 da solo non basta a dire che è successo qualcosa di male.

Figura 7 – EventID 5136

Il monitoraggio delle modifiche agli oggetti Active Directory è fondamentale per rilevare alterazioni non autorizzate o fuori processo.

Ma un 5136 relativo a una GPO critica, fuori finestra di change, eseguito da un account inatteso e seguito da modifiche su SYSVOL merita sicuramente attenzione.

Il punto è la correlazione. Chi ha modificato? Che cosa ha modificato? La GPO è collegata a quale OU? Quali computer o utenti ricevono quella policy? La modifica era prevista? Esiste un change approvato? Senza queste domande, il logging rischia di diventare solo rumore ben formattato.

Cosa proteggere davvero

Per ridurre il rischio legato alle GPO, non basta “controllare ogni tanto”. Serve un modello operativo. Alcune misure concrete:

• limitare chi può creare GPO;
• limitare chi può modificare GPO esistenti;
• limitare chi può linkare GPO a OU, domini e site;
• separare l’amministrazione delle GPO dall’amministrazione ordinaria dei server;
• rivedere periodicamente ACL e deleghe;
• usare gruppi dedicati e tracciabili;
• evitare permessi permanenti concessi per esigenze temporanee;
• proteggere SYSVOL e monitorarne le modifiche;
• fare backup periodico delle GPO;
• versionare le configurazioni critiche;
• documentare owner e scopo di ogni GPO;
• rimuovere GPO obsolete;
• applicare change management alle GPO critiche;
• controllare in modo specifico le GPO applicate a Domain Controller, server Tier 0, jump server e sistemi amministrativi;
• integrare gli eventi relativi alle GPO nel SIEM;
• verificare periodicamente che le policy applicate corrispondano a quelle attese.

Una GPO collegata a una OU critica dovrebbe essere trattata come un componente di sicurezza, non come una semplice configurazione amministrativa.

Questo vale soprattutto per gli ambienti con modello Tiering, sistemi amministrativi dedicati, server sensibili, account privilegiati e infrastrutture ibride.

Checklist finale

Una checklist minima per iniziare:

• censire tutte le GPO del dominio;
• identificare GPO applicate a OU critiche;
• verificare owner e data ultima modifica;
• controllare le deleghe su ogni GPO critica;
• verificare chi può creare e linkare GPO;
• controllare permessi e contenuto di SYSVOL;
• cercare scheduled task, script e modifiche registry inattese;
• monitorare modifiche a gPLink e gPCFileSysPath;
• abilitare auditing sugli oggetti critici;
• inviare eventi rilevanti al SIEM;
• eseguire backup periodico delle GPO;
• rimuovere GPO obsolete;
• documentare scopo, owner e change delle policy sensibili.

Conclusioni

Le Group Policy sono uno degli strumenti più potenti di Active Directory. Proprio per questo non possono essere considerate solo un dettaglio amministrativo. Ogni GPO può definire configurazioni, privilegi, script, task, impostazioni di sicurezza e comportamenti applicati a decine, centinaia o migliaia di sistemi.

In mano a un amministratore sono automazione. In mano a un attaccante sono distribuzione, persistenza e movimento laterale. La differenza non la fa la tecnologia. La fanno le deleghe, il monitoraggio e il controllo del cambiamento.

Active Directory non diventa il C2 dell’attaccante perché le GPO sono sbagliate. Lo diventa quando nessuno controlla davvero chi può modificarle.

Stay tuned!