Configurazioni Errate GPO come Vettore di Attacco

Cosa sono le configurazioni errate dei GPO?

Le configurazioni errate GPO trasformano uno dei meccanismi di gestione più importanti di Active Directory in uno dei suoi vettori di attacco più pericolosi. I Group Policy Object (GPO) controllano le impostazioni di sicurezza, la distribuzione del software, l'esecuzione di script e l'ambiente utente su ogni macchina del dominio. Quando i loro permessi sono configurati in modo errato, creano uno dei vettori di attacco più potenti di Active Directory: un singolo GPO mal configurato collegato ai Domain Controller può compromettere l'intero dominio.

Le configurazioni errate dei GPO sono particolarmente pericolose perché combinano due minacce: movimento laterale su larga scala (un GPO compromesso può distribuire script dannosi a centinaia di macchine contemporaneamente) ed escalation dei privilegi (permessi deboli su un GPO permettono a utenti con pochi privilegi di modificare policy applicate agli stessi Domain Controller).

L'altro problema critico dei GPO è l'assenza di LAPS. Senza Local Administrator Password Solution, tutte le workstation del dominio condividono la stessa password dell'Administrator locale. Basta craccarla una volta su una qualsiasi macchina - tramite un dump o un hash - per ottenere admin locale su tutte le workstation del dominio.

Come funziona

I GPO sono memorizzati come oggetti in Active Directory e come file nella condivisione SYSVOL sui Domain Controller. Ogni GPO ha due componenti:

• GPC (Group Policy Container) - l'oggetto AD, controllato dalle ACL di AD
• GPT (Group Policy Template) - i file in \\dominio\SYSVOL\, controllati dalle ACL NTFS

Entrambi devono essere protetti. Un attaccante con accesso in scrittura a uno dei due componenti può iniettare contenuto dannoso che viene eseguito su ogni macchina a cui si applica il GPO.

Ordine di elaborazione delle Group Policy

I GPO vengono applicati in questo ordine (in caso di conflitto vince l'ultimo scrittore):

1. Policy locale
2. GPO a livello di sito
3. GPO a livello di dominio
4. GPO a livello di OU (dalla OU padre alla figlia)

Questo significa che un GPO collegato a livello di OU che contiene i Domain Controller viene applicato a ogni DC di quella OU, rendendolo un bersaglio di altissimo valore per gli attaccanti.

La catena di attacco

Passo 1 - Enumerare i permessi dei GPO

# Trova tutti i GPO in cui account non privilegiati hanno diritti di modifica
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $acl = Get-GPPermission -Guid $gpo.Id -All
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo.SOMPath -join ", "
  $acl | Where-Object {
    $_.Permission -match "GpoEditDeleteModifySecurity|GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM|Creator Owner"
  } | Select-Object `
    @{N="GPO";E={$gpo.DisplayName}},
    @{N="Trustee";E={$_.Trustee.Name}},
    @{N="Permission";E={$_.Permission}},
    @{N="LinkedTo";E={$links}}
}

Passo 2 - Identificare i collegamenti pericolosi

# Trova i GPO collegati a OU di alto valore (Domain Controllers, Tier 0)
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo | Where-Object { 
    $_.SOMPath -match "Domain Controllers|Tier0|Admin" 
  }
  if ($links) {
    Write-Host "GPO AD ALTO VALORE: $($gpo.DisplayName) - Collegato a: $($links.SOMPath -join ', ')"
    Get-GPPermission -Guid $gpo.Id -All | Where-Object {
      $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
    }
  }
}

Passo 3 - Sfruttare i permessi deboli (se trovati)

Se un account con pochi privilegi ha diritti GpoEdit su un GPO collegato ai Domain Controller, l'attaccante può aggiungere uno script di avvio dannoso che viene eseguito come SYSTEM su ogni DC target:

# L'attaccante modifica il GPO per aggiungere un'attività pianificata dannosa
# Viene eseguita come SYSTEM su ogni macchina nell'ambito al successivo refresh di Group Policy
# I Domain Controller aggiornano la policy ogni 5 minuti per impostazione predefinita (non
# l'intervallo di 90 minuti di workstation/server) - un GPO dannoso collegato a una OU di DC
# si propaga rapidamente
# Può essere forzato immediatamente con: gpupdate /force

Passo 4 - Sfruttare l'assenza di LAPS per il movimento laterale

Senza LAPS, l'account Administrator locale su tutte le workstation condivide la stessa password. Un singolo dump dell'hash porta a un movimento laterale a livello di dominio:

# Ottenere l'hash dell'admin locale da una qualsiasi macchina
# Usare pass-the-hash per autenticarsi su tutte le workstation (NetExec, il successore
# mantenuto attivamente del ormai archiviato CrackMapExec)
netexec smb 10.10.0.0/24 -u Administrator -H "aabbccdd11223344:aabbccdd11223344"
# Tutte le macchine con la stessa password admin locale mostreranno [+]

Rilevamento

Event ID di Windows

Query di rilevamento SIEM (Elastic KQL)

GPO modificato da un account non amministrativo:

event.code: "5136" AND
winlog.event_data.ObjectClass: "groupPolicyContainer" AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM" OR "*$")

Modifica di file in SYSVOL:

event.code: "4663" AND
file.path: (*\\SYSVOL\\*) AND
event.action: "File Write" AND
NOT winlog.event_data.SubjectUserName: ("SYSTEM" OR "*$")

Remediation

1. Correggere i permessi pericolosi dei GPO

# Rimuovere i permessi pericolosi da un GPO specifico
Set-GPPermission -Name "Default Domain Controllers Policy" `
  -TargetName "Domain Users" -TargetType Group `
  -PermissionLevel None

# Verificare e correggere tutti i GPO
Get-GPO -All | ForEach-Object {
  $gpo = $_
  Get-GPPermission -Guid $gpo.Id -All | Where-Object {
    $_.Permission -match "GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
  } | ForEach-Object {
    Set-GPPermission -Guid $gpo.Id -TargetName $_.Trustee.Name `
      -TargetType Group -PermissionLevel GpoRead
    Write-Host "Corretto: $($gpo.DisplayName) - $($_.Trustee.Name) declassato a Read"
  }
}

2. Distribuire LAPS

# Windows LAPS è integrato in Windows Server 2019/2022 (aggiornamento di aprile 2023
# o successivo) e nativamente in Windows Server 2025 / Windows 11 22H2+ - non serve
# installarlo dalla PowerShell Gallery. Confermate che il modulo sia presente:
Get-Command -Module LAPS

# Estendere lo schema AD per LAPS (richiede Schema Admin)
Update-LapsADSchema

# Concedere ai DC i permessi per scrivere gli attributi LAPS
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# Configurare tramite GPO:
# Computer Configuration > Administrative Templates > LAPS
# - Enable local admin password management: Enabled
# - Password complexity: maiuscole + minuscole + numeri + caratteri speciali
# - Password length: minimo 20 caratteri
# - Password age: massimo 30 giorni

3. Applicare standard di password policy sui GPO

# Verificare tutti i GPO che distribuiscono password policy
Get-GPO -All | ForEach-Object {
  $report = Get-GPOReport -Guid $_.Id -ReportType XML
  if ($report -match "MinimumPasswordLength") {
    # Estrarre e verificare il valore
    $minLen = [regex]::Match($report, 
      '<MinimumPasswordLength[^>]*>(\d+)<').Groups[1].Value
    if ([int]$minLen -lt 14) {
      Write-Warning "Password policy debole nel GPO: $($_.DisplayName) - MinLength: $minLen"
    }
  }
}

4. Proteggere SYSVOL

# Verificare che le ACL di SYSVOL siano corrette
# Solo Domain Admins e SYSTEM devono avere accesso in scrittura
icacls "\\corp.local\SYSVOL\corp.local\Policies" /verify

# Abilitare l'auditing delle modifiche a SYSVOL tramite GPO:
# Computer Configuration > Windows Settings > Security Settings > 
#   Advanced Audit Policy > Object Access > Audit File System: Success, Failure

Come EtcSec rileva questo problema

EtcSec verifica ogni GPO del vostro dominio alla ricerca di permessi pericolosi, policy deboli e controlli mancanti.

GPO_DANGEROUS_PERMISSIONS identifica i GPO in cui account non privilegiati hanno permessi di modifica - in particolare i GPO collegati a OU di Domain Controller, dove lo sfruttamento porta direttamente alla compromissione totale del dominio.

GPO_WEAK_PASSWORD_POLICY segnala qualsiasi GPO che distribuisce una password policy al di sotto degli standard di sicurezza attuali - lunghezza minima, requisiti di complessità, età massima e cronologia delle password.

GPO_LAPS_NOT_DEPLOYED rileva ambienti in cui LAPS non è configurato tramite GPO, lasciando le password dell'Administrator locale non gestite e identiche su tutte le workstation, il che abilita il movimento laterale a livello di dominio a partire dalla compromissione di una singola macchina.

Domande frequenti

Perché le configurazioni errate dei GPO sono così pericolose? Un GPO mal configurato è pericoloso per la sua scala. Un singolo GPO collegato ai Domain Controller può eseguire codice come SYSTEM su tutti i DC dell'organizzazione contemporaneamente. A differenza della compromissione di singoli account, un GPO dannoso colpisce ogni macchina nell'ambito al successivo ciclo di refresh di Group Policy - potenzialmente centinaia di macchine entro 90 minuti.

Cos'è LAPS e perché dovrei distribuirlo? Local Administrator Password Solution (LAPS) gestisce automaticamente la password dell'account Administrator locale su ogni computer unito al dominio, impostando una password casuale unica che ruota secondo una pianificazione. Senza LAPS, tutte le workstation condividono tipicamente la stessa password Administrator locale, permettendo a un attaccante che craccka l'hash di una macchina di autenticarsi su tutte le altre workstation - una tecnica chiamata pass-the-hash.

Qual è la configurazione minima dei GPO che devo rivedere? Date priorità innanzitutto ai GPO collegati ai Domain Controller e alle OU Tier 0 - sono i bersagli a maggiore impatto. Poi verificate la Default Domain Policy e la Default Domain Controllers Policy alla ricerca di modifiche di permessi non autorizzate. Questi due GPO da soli coprono la superficie di rischio più critica.

Priorità di revisione

Configurazioni Errate GPO come Vettore di Attacco deve essere trattato come un'esposizione reale all'interno del vostro ambiente Active Directory, non come un'impostazione isolata. Iniziate definendo il perimetro di revisione: quali gruppi privilegiati, account di servizio, ACL, collegamenti GPO, trust, impostazioni di delega, template dei certificati e workstation amministrative sono coinvolti, quali flussi di lavoro aziendali dipendono da essi, quali privilegi espongono e quali eccezioni di emergenza sono state aggiunte nel tempo. Questo passaggio di scoping evita una remediation superficiale, perché il sintomo tecnico è spesso più piccolo del reale raggio d'impatto operativo. Documentando il percorso completo dalla configurazione al privilegio, il team può dare priorità alle modifiche che riducono rapidamente il rischio senza interrompere l'accesso in produzione. Questo crea anche una baseline difendibile per la validazione successiva e fornisce al management una spiegazione chiara del perché il problema conti ora.

Controlli adiacenti da rivedere

Quando gli attaccanti raggiungono il vostro ambiente Active Directory, raramente si fermano al primo punto debole. Intorno alle Configurazioni Errate GPO, normalmente verificano se il percorso esposto può essere concatenato con account privilegiati obsoleti, nidificazione dei gruppi non sicura, delega eccessiva, impostazioni di password deboli, percorsi GPO scrivibili e abuso di ACL ereditate. Questo significa che i difensori devono rivedere non solo la debolezza principale, ma ogni dipendenza vicina che trasforma l'accesso in persistenza o escalation dei privilegi. Confermate quali identità, ruoli, permessi e presupposti di trust possono essere riutilizzati da un operatore motivato. Se una correzione chiude un solo oggetto lasciando intatti i percorsi di privilegio adiacenti, il rischio effettivo cambia a malapena. Una revisione disciplinata delle opportunità di concatenamento è ciò che trasforma questo argomento in un esercizio pratico di hardening invece che in una casella da spuntare una tantum.

Configurazioni Errate GPO: validazione prima della chiusura

Una revisione solida delle Configurazioni Errate GPO dovrebbe concludersi con evidenza di produzione, non con l'assunzione che il percorso rischioso sia scomparso. Prima di chiudere il finding, ricontrollate le identità privilegiate, i diritti delegati e l'accesso ereditato, la policy, l'ACL, il gruppo o l'ambito del GPO che è effettivamente cambiato, e l'evidenza di logging o del collector legata al finding. Confermate che lo stato più sicuro si applichi all'ambito che conta davvero: la OU di produzione, l'assegnazione di ruolo effettiva, il percorso applicativo o il percorso di trust e delega che un attaccante sfrutterebbe realmente. Registrate l'owner tecnico, la dipendenza di business e la condizione di rollback in modo che la revisione successiva possa stabilire se lo stato più sicuro è stato mantenuto.

Usate una breve checklist di chiusura:

• verificate che lo stato di rischio sia scomparso dal punto di vista dell'attaccante, non solo da uno screenshot amministrativo
• conservate un export o un campione di log prima/dopo che dimostri che l'ambito interessato è cambiato
• documentate l'owner e la decisione di eccezione se il controllo non ha potuto essere applicato completamente

Per l'esposizione adiacente, verificate il risultato con Nidificazione Pericolosa dei Gruppi AD: Percorsi verso Domain Admin, Percorsi di Attacco AD verso Domain Admin, Monitoraggio della Sicurezza Active Directory: Gli Eventi che Contano Davvero, e Conformità AD e Azure: NIS2, ISO 27001, CIS Controls. La stessa lacuna di controllo spesso riappare in percorsi identitari vicini, lacune di logging o permessi delegati, motivo per cui il passaggio di validazione finale conta quanto il finding iniziale.

Configurazioni Errate GPO: evidenza da conservare per il prossimo ciclo di revisione

Il prossimo revisore non dovrebbe dover ricostruire il caso a memoria. Conservate l'evidenza che ha originariamente giustificato il finding, la prova che la modifica è stata applicata e la nota che spiega perché lo stato finale è accettabile. Per questo argomento, l'evidenza più utile di solito combina l'export attuale delle identità, dei gruppi o dei percorsi delegati interessati, la prova di configurazione prima/dopo per il controllo modificato, e il ticket, l'owner e la nota di eccezione che spiega lo stato finale. Questo pacchetto compatto rende molto più veloci le revisioni trimestrali o post-modifica e aiuta a spiegare se il problema è stato rimosso, ridotto o formalmente accettato.

Se una successiva modifica amministrativa, di policy o applicativa riapre il percorso, questa evidenza storica rende anche più facile dimostrare cosa è deviato. Questo è ciò che trasforma le Configurazioni Errate GPO da un controllo una tantum in un processo di assurance ripetibile.

Letture correlate

Rivedete questo argomento insieme a Monitoraggio della Sicurezza Active Directory: Gli Eventi che Contano Davvero, Sicurezza delle Password in Active Directory: Configurazioni Errate che Contano, Nidificazione Pericolosa dei Gruppi AD: Percorsi verso Domain Admin, Attacchi NTLM Relay: Dirottamento dell'Autenticazione in AD, e Percorsi di Attacco AD verso Domain Admin. Questi articoli adiacenti mostrano come le stesse debolezze identitarie tendano a concatenarsi in una valutazione reale, invece di presentarsi come finding isolati.

• Monitoraggio della Sicurezza Active Directory: Gli Eventi che Contano Davvero
• Sicurezza delle Password in Active Directory: Configurazioni Errate che Contano
• Nidificazione Pericolosa dei Gruppi AD: Percorsi verso Domain Admin
• Attacchi NTLM Relay: Dirottamento dell'Autenticazione in AD
• Percorsi di Attacco AD verso Domain Admin

L'uso di questi riferimenti mantiene la discussione sulla remediation concentrata sull'intero percorso di attacco, invece che su una singola lacuna di controllo.

Convalidare ambito, ereditarietà ed eccezioni

La pulizia dei GPO deve essere testata rispetto alla struttura reale delle OU e ai flussi di lavoro amministrativi presenti in produzione. I team devono confermare quali policy collegate si applicano ancora a sistemi ad alto valore, se i blocchi di ereditarietà o i diritti di modifica delegati introducono nuove opportunità di bypass, e se le policy di emergenza o legacy restano giustificate. Questa revisione mantiene l'hardening di Group Policy ancorato a come privilegio e controllo delle workstation funzionano realmente nell'ambiente.

Rivedere la proprietà amministrativa dei GPO

La domanda finale è chi può ancora modificare la policy dopo la pulizia. Se troppi amministratori, team delegati o script legacy possono modificare GPO ad alto impatto, lo stesso rischio ritorna rapidamente attraverso l'amministrazione ordinaria. Rivedere la proprietà, i percorsi di approvazione e il monitoraggio delle modifiche sensibili ai GPO mantiene lo sforzo di hardening duraturo invece che temporaneo.

Cosa monitorare dopo la pulizia

Dopo un progetto di remediation dei GPO, prestate molta attenzione ai nuovi editor delegati, alle modifiche di policy di emergenza e ai collegamenti applicati a OU ad alto valore. Questi sono i punti in cui le vecchie debolezze tendono a riapparire. Una revisione leggera delle modifiche recenti ai GPO, dei cambi di proprietà e delle policy appena collegate aiuta a confermare che l'ambiente resti protetto dopo la conclusione dello sforzo di pulizia iniziale.

Sostenere la governance dei GPO nel tempo

Il controllo a lungo termine è la coerenza. Se i team continuano a tracciare chi può modificare le policy critiche, quali modifiche di emergenza aggirano la revisione standard e con quale rapidità vengono indagati i collegamenti ad alto rischio, Group Policy resta un controllo difensivo invece di diventare una superficie di attacco ricorrente. Questo ritmo operativo è spesso ciò che distingue una pulizia una tantum da un hardening duraturo.

L'hardening dei GPO dipende anche dalla rapidità con cui vengono revisionate le modifiche di policy insolite dopo manutenzioni fuori orario, patch di emergenza e nuovi rollout di workstation. Mantenere attivo questo ciclo di revisione aiuta i team a rilevare quando modifiche di comodo reintroducono impostazioni pericolose molto dopo la chiusura del progetto di remediation originale. In pratica, la sicurezza duratura dei GPO dipende meno da una baseline perfetta e più dal mantenere visibilità su ogni futura modifica che possa interessare sistemi privilegiati.