Modifica delle Group Policy: Domain Policy Hijacking (T1484.001)

Iniziare una simulazione di attacco GPO richiede prima di tutto l'identificazione delle autorizzazioni correnti. Su Windows, il comando PowerShell Get-GPPermission -Name "Default Domain Policy" -All rivela chi può modificare le policy critiche del dominio. Una volta identificati i target con permessi di scrittura, è possibile procedere con la modifica.

Il tool Empire fornisce il modulo New-GPOImmediateTask che automatizza la creazione di scheduled task malevoli attraverso GPO:

powershell/lateral_movement/invoke_wmi_debugger

Per una modifica manuale più granulare, accedere direttamente al percorso SYSVOL e modificare i file XML pertinenti. Il file \<GPO_PATH>\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml può essere editato per inserire task schedulati che eseguiranno payload su tutti i computer del dominio al prossimo refresh delle policy.

Un approccio più sofisticato prevede la modifica del file \<GPO_PATH>\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf per assegnare privilegi speciali come SeEnableDelegationPrivilege a utenti controllati dall'attaccante. Questa tecnica crea una backdoor sottile ma potente che garantisce controllo completo sul dominio.

Per testare l'efficacia delle modifiche, forzare un aggiornamento delle policy sui sistemi target con gpupdate /force. Il comando gpresult /r permette di verificare quali policy sono state applicate e da quale domain controller.

La detection delle modifiche GPO richiede un approccio multi-layer che combina monitoring degli oggetti AD e dell'attività file system su SYSVOL. Il Windows Security Event Log registra modifiche agli oggetti directory con EventID specifici che devono essere monitorati costantemente.

Configurare alert per modifiche ai percorsi critici come CN=Policies,CN=System,DC=domain,DC=com nel contesto AD. Ogni modifica a questi oggetti deve generare un alert immediato, specialmente se eseguita da account non amministrativi o in orari anomali.

Il monitoring dei file SYSVOL richiede attenzione particolare a ScheduledTasks.xml e GptTmpl.inf. Sysmon può catturare queste modifiche file con una configurazione appropriata che traccia l'accesso in scrittura alla directory SYSVOL. La correlazione temporale è fondamentale: una modifica AD seguita entro pochi secondi da scritture SYSVOL indica quasi certamente attività malevola.

I comandi PowerShell come Set-GPRegistryValue o New-GPOImmediateTask devono triggare alert immediati. La command line analysis diventa cruciale per identificare l'uso di tool di manipolazione GPO. Implementare whitelist ristrette per gli account autorizzati a eseguire questi comandi riduce drasticamente i falsi positivi.

L'analisi forense delle modifiche GPO inizia sempre dall'esame dei backup SYSVOL. Windows mantiene versioni storiche delle GPO nella directory SYSVOL che possono rivelare esattamente cosa è stato modificato e quando. Comparare i file XML prima e dopo l'incidente fornisce una visione chiara delle modifiche introdotte dall'attaccante.

I log di Active Directory contengono tracce dettagliate di ogni modifica agli oggetti GPO. L'attributo gPCFileSysPath negli oggetti directory rivela il percorso SYSVOL associato, permettendo di correlare modifiche AD con modifiche file system. La timeline deve includere sia le modifiche agli oggetti AD che quelle ai file SYSVOL per una ricostruzione completa.

Durante la campagna 2022 Ukraine Electric Power Attack, Sandworm Team ha lasciato tracce forensi distintive nelle loro modifiche GPO per distribuire malware. L'analisi ha rivelato pattern temporali precisi: prima la modifica dell'oggetto GPO, poi l'upload del payload in SYSVOL, infine il trigger attraverso gpupdate forzato sui sistemi target.

Gli artefatti di replicazione AD forniscono informazioni preziose su quale domain controller è stato usato per la modifica iniziale. Il metadata di replicazione contiene timestamp e originating DC che aiutano a identificare il punto di ingresso dell'attaccante nell'infrastruttura AD.

APT41 ha dimostrato una predilezione particolare per l'uso di scheduled task deployati via GPO nei loro attacchi ransomware. Il gruppo crea tipicamente task che si attivano a orari predefiniti per massimizzare l'impatto e complicare la risposta. La loro signature include l'uso di nomi task che mimano servizi Windows legittimi.

Indrik Spider preferisce invece deployare batch script attraverso GPO, spesso utilizzando tecniche di obfuscation per nascondere il vero payload. I loro script tendono a disabilitare prima le difese endpoint, poi a stabilire persistenza attraverso multiple tecniche ridondanti.

Cinnamon Tempest ha evoluto l'approccio combinando modifiche GPO con lateral movement veloce. Deployano ransomware attraverso GPO solo dopo aver compromesso almeno il 70% dei sistemi critici, garantendo così massimo impatto anche se la modifica GPO viene scoperta rapidamente.

La campagna SharePoint ToolShell Exploitation ha visto Storm-2603 utilizzare modifiche GPO come meccanismo di distribuzione secondario. Dopo lo sfruttamento iniziale delle vulnerabilità SharePoint, le GPO venivano modificate per garantire persistenza anche dopo il patching dei server compromessi. Questo pattern suggerisce un'evoluzione tattica dove le GPO non sono più solo vettore primario ma parte di una strategia di resilienza multi-layer.

Framework MITRE ATT&CK T1484.001. Campagne documentate: 2022 Ukraine Electric Power Attack (C0034), SharePoint ToolShell Exploitation (C0058). Detection: DET0305 per correlazione modifiche AD e attività SYSVOL. Mitigazioni: M1018 User Account Management, M1047 Audit con focus su BloodHound per GPO permission abuse.