Manipolazione delle Group Policy: Group Policy Modification (T1484.001)

Il primo passo in un engagement red team è capire chi ha permessi di scrittura sulle GPO. BloodHound (open source, Community Edition) è lo strumento naturale: dopo aver raccolto i dati con SharpHound, una query Cypher rivela gli utenti e i gruppi con diritto GenericWrite o WriteDacl su oggetti GPO. In alternativa, dal modulo Active Directory di PowerShell si può enumerare direttamente:

Get-GPO -All | ForEach-Object { Get-GPPermission -Guid $_.Id -All }

Questo restituisce le ACL di ogni GPO nel dominio, evidenziando deleghe sospette. In ambienti di lab è il modo più rapido per identificare un punto di ingresso.

Una volta individuata una GPO scrivibile, il vettore classico passa per la creazione di una scheduled task malevola. Il cmdlet New-GPOImmediateTask, disponibile nel modulo PowerSploit (open source) e integrato anche in Empire (open source), modifica il file ScheduledTasks.xml all'interno del percorso SYSVOL della GPO. Il task viene eseguito sugli endpoint al successivo aggiornamento della policy, senza richiedere interazione utente.

Per un approccio più manuale — utile quando si vuole evitare la firma dei tool noti — è possibile editare direttamente i file nella share SYSVOL. Il file GptTmpl.inf, sotto il percorso *MACHINE\Microsoft\Windows NT\SecEdit*, controlla i diritti utente: aggiungendo il SID di un account controllato alla riga SeEnableDelegationPrivilege, si ottiene una backdoor che sopravvive ai reset password e ai cambi di credenziali. Dopo la modifica, occorre incrementare il numero di versione nel file GPT.INI affinché i client la rilevino come aggiornamento.

Per forzare l'applicazione immediata anziché attendere il ciclo standard:

gpupdate /force /target:computer

In un esercizio strutturato, SharpGPOAbuse (open source) offre un'interfaccia più pulita per aggiungere task immediati, script di logon o diritti utente a una GPO esistente, con sintassi che consente di specificare target user, comando e GPO name in un'unica riga.

Infine, per simulare scenari ransomware come quelli documentati nelle campagne reali, si può usare una GPO per pushare uno script batch che disabilita Windows Defender via registro di sistema, replica un payload su una share di rete e lo esegue tramite un servizio Windows — replicando fedelmente il pattern di LockBit 2.0 e Prestige.

La detection di modifiche GPO malevole ruota attorno a due canali di log complementari: gli eventi di Directory Service e il monitoraggio file su SYSVOL.

Sul lato Active Directory, l'EventCode 5136 (oggetto directory modificato) è il segnale primario. Questo evento viene generato quando un attributo di un oggetto AD cambia, e filtrando sull'ObjectDN che contiene CN=Policies,CN=System,DC= si isolano esclusivamente le modifiche a contenitori GPO. L'attributo critico da monitorare è gPCFileSysPath, la cui modifica può indicare un reindirizzamento della GPO verso un percorso malevolo. Per attivare questo logging, la policy di audit avanzata deve avere abilitato Audit Directory Service Changes nella categoria DS Access.

Il secondo canale riguarda le scritture su file SYSVOL. Con Sysmon (gratuito, parte di Sysinternals) configurato sul domain controller, l'EventID 11 (FileCreate) e l'EventID 2 (FileCreateTime change) permettono di intercettare la creazione o modifica di file come ScheduledTasks.xml e GptTmpl.inf. La regola Sysmon dovrebbe filtrare su TargetFilename contenente il percorso SYSVOL e i nomi file specifici.

La chiave per ridurre i falsi positivi sta nella correlazione temporale e contestuale. Una modifica GPO legittima proviene quasi sempre da un account amministrativo noto, durante una finestra di change management, e riguarda GPO già esistenti. Un alert efficace dovrebbe quindi combinare:

• EventCode 5136 su oggetti GPO da parte di account non inclusi in una whitelist di amministratori GPO
• Scrittura su file in SYSVOL entro una finestra temporale ristretta (es. 120 secondi) dallo stesso host o account
• Esecuzione di cmdlet sospetti nel log PowerShell (EventCode 4104 con ScriptBlock contenente New-GPOImmediateTask, Set-GPRegistryValue o Set-GPPermission)

Per il monitoraggio proattivo delle deleghe eccessive, BloodHound Community Edition (open source) consente audit periodici dei percorsi di attacco verso le GPO. Sul versante commerciale, PingCastle (freemium) esegue scan automatizzati delle ACL GPO e segnala configurazioni pericolose.

Un controllo hardening complementare è il WMI e security filtering sulle GPO critiche, come raccomandato nelle mitigazioni: restringere quali utenti e computer ricevono una GPO riduce la superficie d'attacco anche in caso di modifica malevola.

L'analisi forense di una compromissione via GPO richiede la ricostruzione su due piani paralleli: le modifiche all'oggetto AD e le alterazioni ai file sul filesystem SYSVOL.

Il punto di partenza è il log Security del domain controller. Gli eventi 5136 documentano ogni modifica attributo sull'oggetto GPO, incluso il timestamp preciso e l'account responsabile. Affiancando questi eventi con il 5137 (creazione oggetto directory), si distingue tra la modifica di una GPO esistente e la creazione di una nuova — quest'ultimo scenario è tipico di attacchi più sofisticati che evitano di toccare policy già monitorate.

Sul filesystem, la cartella SYSVOL conserva lo storico delle modifiche tramite i metadati NTFS. Con MFTECmd (open source, parte di Eric Zimmerman's Tools), si può parsare la Master File Table del volume che ospita SYSVOL ed estrarre i timestamp di creazione e ultima modifica di ScheduledTasks.xml, GptTmpl.inf e Registry.pol. Il file GPT.INI all'interno di ogni GPO contiene un numero di versione incrementale: confrontando la versione attuale con backup noti o snapshot precedenti del System State, si identifica il momento esatto dell'alterazione.

Per ricostruire cosa ha fatto concretamente la GPO malevola sugli endpoint, occorre esaminare i log di Group Policy processing. L'EventCode 4016 e i log operativi sotto Microsoft-Windows-GroupPolicy/Operational registrano quale GPO è stata applicata, quando, e con quale risultato. Incrociando queste informazioni con i log Sysmon degli endpoint — in particolare EventID 1 (Process Create) per l'esecuzione di task schedulati e EventID 13 (Registry Value Set) per modifiche a chiavi di sicurezza — si ottiene la catena completa: modifica GPO → propagazione → esecuzione payload.

Nelle campagne documentate il pattern è ricorrente. Durante il 2022 Ukraine Electric Power Attack (C0034), Sandworm Team ha sfruttato le GPO per distribuire CaddyWiper sugli endpoint della rete OT, mentre nella campagna SharePoint ToolShell Exploitation (C0058) gli attori — incluso Storm-2603 — hanno modificato le group policy per abilitare la distribuzione ransomware dopo aver ottenuto accesso iniziale via vulnerabilità SharePoint. In entrambi i casi, l'artefatto forense chiave era la discrepanza tra il timestamp di modifica dei file SYSVOL e l'ultima modifica legittima documentata nei change log dell'organizzazione.

La modifica delle Group Policy è diventata una tecnica trasversale, adottata sia da gruppi orientati allo spionaggio sia da operatori ransomware. L'analisi dei 4 gruppi documentati rivela pattern distinti ma convergenti.

APT41 (G0096) rappresenta il ponte tra spionaggio e cybercrime. Il gruppo ha utilizzato scheduled task creati via GPO per distribuire ransomware, dimostrando come la stessa tecnica venga impiegata sia per persistenza silenziosa sia per deployment distruttivo su larga scala. La scelta delle GPO come vettore di distribuzione riflette la maturità operativa del gruppo nell'ambiente Active Directory.

Indrik Spider (G0119), noto per l'ecosistema malware che include Dridex e varianti ransomware, ha adottato un approccio più diretto: GPO per distribuire batch script. Questo pattern è condiviso con Cinnamon Tempest (G1021), che ha utilizzato la stessa catena — GPO → batch script → ransomware deployment — suggerendo una possibile convergenza di tattiche nel panorama ransomware, dove la distribuzione via Group Policy sta sostituendo approcci meno scalabili come il lateral movement manuale.

Storm-0501 (G1053) si distingue per un uso specificamente difensivo-offensivo: le GPO vengono modificate per disabilitare prodotti di sicurezza sugli endpoint prima del deployment del payload principale. Questo colloca la tecnica squarely nella tattica Defense Evasion e indica un livello di pre-pianificazione che implica ricognizione interna dell'ambiente target.

Sul piano dei tool, il panorama è dominato dal ransomware. LockBit 2.0 e LockBit 3.0 integrano nativamente la propagazione via GPO, con la versione 2.0 capace di disabilitare Windows Defender automaticamente tramite modifica policy. Prestige, HermeticWiper, Qilin e Meteor completano il quadro con deployment via Default Domain Policy — il vettore più aggressivo, perché impatta ogni macchina del dominio.

Le 2 campagne documentate evidenziano la traiettoria geografica della tecnica. Il 2022 Ukraine Electric Power Attack (C0034) colloca l'abuso GPO nel contesto di operazioni distruttive contro infrastrutture critiche, con Sandworm Team che combina GPO e living-off-the-land per massimizzare l'impatto sui sistemi SCADA. La più recente SharePoint ToolShell Exploitation (C0058) mostra l'evoluzione verso catene di attacco ibride: l'accesso iniziale avviene tramite vulnerabilità web (CVE-2025-49706, CVE-2025-49704), la propagazione interna via GPO. Questo pattern — exploit esterno + GPO interna — è la tendenza da monitorare nei prossimi trimestri, perché riduce drasticamente il tempo tra compromissione iniziale e impatto dominio-wide.

Framework MITRE ATT&CK v16 — Tecnica T1484.001, Tattiche TA0004, TA0005. Campagne C0034 (2022 Ukraine Electric Power Attack), C0058 (SharePoint ToolShell Exploitation). Detection DET0305, analisi AN0854. Tool di detection e audit: Sysmon, BloodHound CE, PingCastle, MFTECmd. Integrato con conoscenza professionale per tool e procedure operative.