Les GPO comme vecteur de mouvement latéral et de persistance

Concept

Un Group Policy Object (GPO) est un ensemble de paramètres de configuration appliqué automatiquement par le service client Group Policy sur les machines et utilisateurs d’un domaine Active Directory.

Une GPO est constituée de deux parties distinctes qui doivent être synchronisées :

Le group Policy container (GPC) : l’objet Active Directory stocké sous CN=Policies,CN=System,DC=domain,DC=local, contenant les attributs de version, les liens et le statut de la GPO.
Le group Policy template (GPT) : la structure de fichiers et dossiers stockée dans le partage répliqué \\domain\SYSVOL\domain\Policies\{GUID}, contenant les scripts, fichiers XML de préférences (GPP) et stratégies de registre réelles.

Pourquoi c’est important en DFIR

L’arme GPO est massivement utilisée lors des phases finales des attaques par ransomware :

Exécution asynchrone furtive : contrairement à un mouvement latéral direct (SMB/WMI/PsExec) qui déclenche des alertes réseau en temps réel, l’attaque par GPO est passive. L’attaquant modifie un fichier XML dans SYSVOL ; ce sont les machines cibles qui viennent d’elles-mêmes télécharger et exécuter la charge utile lors de leur rafraîchissement périodique.
Permissions mal configurées (weak GPO ACLs) : il n’est pas nécessaire d’être Domain Admins pour abuser des GPO. Si un compte de technicien ou un groupe délégué possède GenericAll, WriteProperty ou WriteDacl sur une GPO existante, l’attaquant peut la militariser.
Persistance pérenne : une tâche planifiée ou un service déployé via GPO est automatiquement réinstallé si un administrateur tente de le supprimer localement, tant que la GPO dans SYSVOL n’a pas été nettoyée.

Comment ça fonctionne

Vecteurs de militarisation d’une GPO

Attaquant (Modifie SYSVOL / GPC)
   │
   │ 1. Écrit dans \\domain\SYSVOL\Policies\{GUID}\...
   │    - Scheduled Tasks (Immediate Tasks)
   │    - Startup / Logon Scripts
   │    - Service Installation
   ▼
[ Partage Répliqué SYSVOL sur DC ]
   │
   │ 2. Réplication DFSR vers tous les DC
   ▼
Clients Windows (Rafraîchissement automatique toutes les 90 min)
   │
   ├───────────────────────────────► 3. Téléchargent la nouvelle version
   │                                    du fichier XML dans SYSVOL
   ▼
Exécution locale sous "NT AUTHORITY\SYSTEM"
(Désactivation Windows Defender, Déploiement Ransomware, Ajout d'Admins)

Les tâches immédiates (immediate tasks) : via les préférences de stratégie de groupe (GPP), l’attaquant configure une tâche planifiée programmée pour s’exécuter immédiatement (Task type: Immediate Task). Dès la réception de la GPO, la machine lance la commande sous SYSTEM.
Les scripts de démarrage (startup scripts) : exécutés au démarrage de la machine sous le compte SYSTEM.
La modification des groupes restreints (restricted groups / local users and groups) : permet à l’attaquant d’ordonner à toutes les machines du domaine d’ajouter un compte compromis dans leur groupe local Administrators.

Ce qui est possible

Désactiver Windows Defender sur tout le parc via GPO : en positionnant les clés de registre DisableAntiSpyware et DisableRealtimeMonitoring via une GPO hostile.
Déployer un binaire malveillant sur des milliers d’ordinateurs sans connexion directe : les postes clients tirent la charge utile depuis le partage SYSVOL.
Identifier les ACLs vulnérables sur les GPO avec BloodHound : bloodHound cartographie automatiquement les arêtes WriteGpoOwner, AddMember et GenericAll ciblant des objets de stratégie.

Ce qui n’est pas possible

Appliquer une GPO sans connectivité vers le partage SYSVOL : si un poste distant ne parvient pas à joindre le port SMB 445 d’un DC, il applique sa configuration en cache local sans exécuter la nouvelle GPO.
Modifier le GPC sans incrémenter le numéro de version : pour que les clients appliquent la GPO modifiée, le champ de version dans le fichier GPT.INI et l’attribut versionNumber dans l’Active Directory doivent être incrémentés et synchronisés.
Bypasser le filtrage WMI et les groupes de sécurité : si la GPO utilise un filtrage de sécurité (Security Filtering) ou un filtre WMI strict, seules les machines correspondant aux filtres exécutent les actions.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« La suppression de la tâche planifiée sur le serveur infecté a éradiqué la persistance. »	Erreur. Si la tâche est poussée par une GPO dans `SYSVOL`, le client la recréera automatiquement lors du prochain rafraîchissement (90 minutes maximum).
« Seuls les Enterprise Admins peuvent modifier les GPOs. »	Faux. Par défaut, le groupe `Group Policy Creator Owners` et toute délégation personnalisée sur une OU permettent de modifier ou créer des GPOs.
« Les modifications de GPO ne sont pas auditées par défaut. »	La modification d’un fichier dans `SYSVOL` relève de l’audit du système de fichiers (Event 4663), tandis que la modification de l’objet GPC dans l’AD génère l’Event ID 5136 sur les DC.

Exemple concret d’investigation

Dans une attaque par ransomware touchant un réseau industriel :

Les 600 serveurs du réseau ont exécuté simultanément le binaire malveillant locker.exe à 04h00 UTC.
Aucune connexion SMB ou WMI entrante anormale n’est constatée sur les serveurs à cette heure.
L’analyste DFIR inspecte le partage SYSVOL du DC primaire :
- Le dossier \\corp.local\SYSVOL\corp.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9} (Default Domain Policy) a été modifié à 02h15 UTC.
- Le fichier GPT.INI a vu sa version incrémentée.
- Un nouveau fichier ScheduledTasks.xml a été créé sous Machine\Preferences\ScheduledTasks\.
- Il contenait une tâche immédiate exécutant cmd.exe /c powershell -enc ... pour désactiver Defender et exécuter le ransomware stocké dans \\corp.local\SYSVOL\corp.local\scripts\locker.exe.
Conclusion DFIR : la Default Domain Policy a été militarisée par l’attaquant pour ordonner un suicide logiciel coordonné sur l’ensemble du domaine.

Artefacts et traces forensiques

Sur les contrôleurs de domaine (partage SYSVOL et Active Directory) :
- Fichiers SYSVOL : fichiers XML sous Machine\Preferences\, scripts dans Machine\Scripts\Startup\, fichier GPT.INI.
- Event ID 5136 (Directory service object was modified) : modification de l’attribut versionNumber ou gPCFileSysPath d’un GPC.
- Event ID 4663 (file system access) : écriture ou modification d’un fichier dans le partage SYSVOL.
Sur les postes et serveurs membres :
- Event ID 4698 (scheduled task created) : enregistrement local de la tâche planifiée poussée par la GPO.
- Microsoft-Windows-GroupPolicy/operational (event IDs 4004, 5312) : détails de l’application et de la découverte des GPO par le client.
- Event ID 7045 : installation de service si la GPO déploie un service local.

Méthodes d’investigation

Auditer les dates de modification récentes dans SYSVOL : Parcourir récursivement \\domain\SYSVOL\domain\Policies et trier tous les fichiers par LastWriteTime.
Vérifier l’historique des modifications des objets GPC : Exécuter Get-GPO -All | Sort-Object ModificationTime -Descending | Select-Object DisplayName, ModificationTime, Id.
Auditer les permissions d’accès sur toutes les GPO : Rechercher des délégations excessives (GenericAll, WriteOwner) accordées à des utilisateurs non privilégiés sur les objets de stratégie.

Outils d’investigation

PowerShell GroupPolicy module :

# Lister les GPO modifiées récemment
Get-GPO -All | Sort-Object ModificationTime -Descending | Select-Object -First 10 DisplayName, Id, ModificationTime

BloodHound : Requêtes de contrôle de GPO :
- MATCH p=(u)-[:CanGPO]->(g:GPO) RETURN p
- MATCH p=(u)-[:GenericAll]->(g:GPO) RETURN p

Points clés à retenir

Les GPOs permettent l’exécution de code massive et asynchrone sous le compte SYSTEM.
Une GPO militarisée contourne la détection réseau car ce sont les clients qui tirent la charge utile via SYSVOL.
L’audit des fichiers ScheduledTasks.xml, GPT.INI et des dates LastWriteTime dans SYSVOL est impératif.
L’éradication exige de nettoyer la GPO dans SYSVOL avant de nettoyer les endpoints.