GPO Errate come Vettore di Attacco

Cosa sono le configurazioni errate GPO?

Le configurazioni errate dei Group Policy Objects (GPO) diventano pericolose quando un oggetto di policy può essere modificato da soggetti non previsti o quando distribuisce impostazioni insicure su un perimetro molto ampio.

Un GPO non è solo una policy astratta: è un meccanismo che può distribuire configurazioni locali, script di avvio, membership di gruppi, preferenze e impostazioni di sicurezza a molti sistemi contemporaneamente. Per questo motivo, un GPO con permessi sbagliati o con contenuto pericoloso può diventare un moltiplicatore di privilegi e di movimento laterale.

I casi che contano davvero sono questi:

permessi di modifica eccessivi sul GPO o sul contenuto SYSVOL associato
policy locali insicure che distribuiscono diritti, membership o impostazioni deboli
assenza di una gestione credibile delle password admin locali, che lascia la stessa password riutilizzata su più host

Dove nasce il rischio tecnico

Ogni GPO ha due componenti da considerare:

il Group Policy Container (GPC) in Active Directory
il contenuto nel SYSVOL, che contiene file, script e impostazioni

Se un soggetto non previsto può modificare uno dei due lati, può cambiare il comportamento di molti sistemi in un solo passaggio.

I rischi più seri non sono “tutte le impostazioni possibili”, ma un gruppo di casi molto concreti:

modifica di script di startup o logon
modifica di policy che aggiungono utenti a gruppi locali privilegiati
distribuzione di configurazioni che abbassano il livello di sicurezza
delega GPO data a gruppi troppo larghi o non amministrativi

Per un lettore tecnico, il punto è semplice: un GPO scrivibile equivale a una superficie di controllo di massa.

Cosa verificare subito

1. Permessi di modifica sul GPO

Microsoft fornisce cmdlet dedicati per leggere i permessi GPO. Questa è una verifica di base:

Get-GPO -All | ForEach-Object {
    $gpo = $_
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object {
            $_.Permission -match 'GpoEdit|GpoEditDeleteModifySecurity' -and
            $_.Trustee.Name -notmatch 'Domain Admins|Enterprise Admins|SYSTEM'
        } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, @{N='Trustee';E={$_.Trustee.Name}}, Permission
}

Qui il problema non è avere Authenticated Users con permesso di Read per l'applicazione della policy. Il problema è trovare identità non previste con capacità di Edit, Delete o Modify Security.

2. Contenuto distribuito dal GPO

Un GPO diventa critico quando distribuisce impostazioni ad alto impatto, per esempio:

membership di Administrators locali
script eseguiti all'avvio o al logon
impostazioni di sicurezza che indeboliscono password, auditing o hardening
configurazioni che raggiungono Domain Controllers o sistemi Tier 0

3. Gestione delle password admin locali

Se gli endpoint condividono password admin locali riutilizzate, l'attaccante che compromette una singola macchina può spesso riusare la stessa credenziale altrove. Il controllo moderno qui è Windows LAPS.

Microsoft documenta Windows LAPS come il meccanismo per gestire e ruotare le password admin locali in Windows. Se LAPS non è distribuito, il rischio GPO non nasce solo dal GPO in sé, ma anche da tutto ciò che quel GPO controlla su host che condividono credenziali locali.

Catene d'attacco realistiche

Caso 1 - Permessi GPO pericolosi

Un gruppo non amministrativo ha diritti di modifica su un GPO collegato a server sensibili o a workstation amministrative. L'attaccante modifica una policy, distribuisce uno script o cambia una membership locale e ottiene esecuzione o privilegi su scala ampia.

Caso 2 - GPO che raggiunge Tier 0

Il contenuto del GPO non è di per sé “drammatico”, ma il link o lo scope includono controller di dominio, jump host o workstation admin. Una delega debole su quel GPO diventa allora una via indiretta verso Tier 0.

Caso 3 - Nessun LAPS e password locali riutilizzate

L'attaccante compromette una macchina, estrae la password admin locale e la riusa su altri host dove la password è la stessa. In questo scenario il GPO conta perché governa lo stato degli endpoint, ma il moltiplicatore reale è l'assenza di un meccanismo di rotazione credibile.

Rilevamento

Modifiche ai GPO

Le modifiche agli oggetti GPO e al relativo contenuto meritano monitoraggio continuo, soprattutto quando l'autore non è un amministratore previsto o quando l'oggetto impatta sistemi sensibili.

event.code: "5136" AND
winlog.event_data.ObjectClass: "groupPolicyContainer"

Cosa cercare in pratica

modifiche a GPO con scope su Domain Controllers, server critici o admin workstations
cambi di permessi GPO o deleghe di modifica
update di script o file nel percorso SYSVOL del GPO
variazioni di membership locali o user rights assignment distribuiti via GPO

Lettura corretta del segnale

Il punto non è solo “un GPO è stato modificato”, ma:

chi lo ha modificato
quale GPO è stato toccato
quali sistemi ricevono quella policy
se la modifica cambia privilegi, esecuzione o impostazioni di sicurezza

Remediation

1. Ripulire le deleghe GPO

La prima misura è rivedere i diritti di modifica:

mantenere la lettura dove serve per l'applicazione della policy
rimuovere diritti di Edit, Delete o Modify Security da gruppi troppo larghi
limitare i GPO ad alto impatto a gruppi amministrativi ben definiti

2. Separare i GPO che raggiungono asset sensibili

I GPO che toccano controller di dominio, admin workstation o server critici vanno trattati come asset privilegiati. Devono avere:

owner chiaro
revisione delle deleghe
controllo di change più stretto
verifica periodica del contenuto distribuito

3. Distribuire Windows LAPS

Se LAPS non è attivo, la priorità è chiara. Microsoft documenta Windows LAPS come il meccanismo di riferimento per gestire e ruotare le password admin locali.

Il beneficio concreto è eliminare il riuso della stessa password locale su più endpoint, che è una delle accelerazioni più comuni del movimento laterale.

4. Riesaminare cosa il GPO distribuisce davvero

Oltre ai permessi, bisogna rivedere il contenuto effettivo del GPO:

script
membership di gruppi locali
user rights assignment
impostazioni di sicurezza distribuite
scope e link

Un GPO con permessi puliti ma contenuto pericoloso resta comunque un rischio.

5. Verificare GPC e SYSVOL con lo stesso modello di controllo

Un errore frequente è correggere l'oggetto AD e lasciare trascurato il contenuto SYSVOL o viceversa. In una remediation credibile bisogna dimostrare che:

i trustee che possono modificare il GPO sono coerenti tra GPC e SYSVOL
non esistono script o file legacy rimasti nel path SYSVOL senza owner chiaro
il change path copre sia i permessi sia il contenuto distribuito

Questo passaggio evita di chiudere il finding nell'interfaccia GPMC e di lasciarlo aperto, di fatto, sul filesystem che distribuisce la policy.

6. Verificare LAPS e gli effetti reali della policy

Dopo la correzione bisogna controllare che i client target ricevano davvero la configurazione voluta. In pratica conviene verificare:

rotazione reale delle password LAPS su un campione di host
gruppi locali privilegiati dopo l'applicazione della policy risultante
assenza di script o preferenze che reintroducono admin locali, credenziali o esecuzioni non previste
applicazione corretta della baseline con gpresult o report RSoP su host sensibili

Senza questa prova, è facile rimuovere il problema "visibile" e lasciare invariato il comportamento effettivo dei sistemi.

Validazione dopo il fix

Una chiusura seria di un finding GPO richiede di poter dimostrare che:

Nessun trustee non previsto ha più diritti di modifica sui GPO sensibili.
I GPO che raggiungono Tier 0 o sistemi critici hanno owner e change path chiari.
Il contenuto distribuito non crea membership, script o diritti pericolosi non giustificati.
Windows LAPS è distribuito o, se non lo è ancora, esiste un piano tecnico con compensating controls temporanei.

Se manca uno di questi quattro punti, il rischio non è davvero sotto controllo.

Evidenza minima che conviene conservare

Per evitare che il finding si riapra al cambio successivo, vale la pena mantenere:

inventario dei GPO privilegiati con deleghe di modifica approvate
snapshot dei link e dello scope dei GPO che raggiungono Tier 0
campione di host dove è stata verificata l'applicazione reale della policy
elenco dei principal autorizzati a leggere le password LAPS e relativa giustificazione

Sono prove semplici, ma rendono il controllo ripetibile e riducono molto la deriva operativa.

Errori frequenti lato difensivo

Gli errori più comuni sono:

confondere Read necessario all'applicazione con permessi di modifica realmente pericolosi
rivedere solo AD e dimenticare il contenuto SYSVOL
non trattare i GPO che raggiungono Tier 0 come oggetti privilegiati
considerare l'assenza di LAPS come un problema endpoint, invece che come moltiplicatore del rischio di compromissione GPO
chiudere il finding sui permessi senza verificare cosa il GPO distribuisce davvero

Un lettore tecnico non vuole una frase generica tipo “le GPO sono importanti”. Vuole sapere chi può modificarle, dove sono collegate, cosa distribuiscono e quale percorso di privilegio aprono se vengono abusate.

Fonti primarie

Come EtcSec rileva questo

EtcSec rileva tre famiglie principali di rischio in questo ambito:

GPO_DANGEROUS_PERMISSIONS
GPO_WEAK_PASSWORD_POLICY
GPO_LAPS_NOT_DEPLOYED

Prese insieme, spiegano bene il rischio reale: un GPO modificabile, una policy debole e password locali riutilizzate non sono problemi separati. Sono spesso la stessa catena di compromissione.

Configurazioni Errate GPO come Vettore di Attacco