Secrets cPassword GPO SYSVOL Active Directory : pourquoi un correctif de 2014 n'a pas suffi

Secrets cPassword GPO SYSVOL Active Directory : de quoi s'agit-il

Les secrets cPassword GPO SYSVOL Active Directory comptent parmi les plus anciennes mauvaises configurations qui refusent de disparaître — et l'une des mauvaises configurations Active Directory les plus courantes encore retrouvées aujourd'hui lors des audits en production. Elles proviennent des Group Policy Preferences (GPP), une fonctionnalité ajoutée par Microsoft dans Windows Server 2008 permettant aux administrateurs de déployer via une stratégie de groupe des comptes utilisateurs locaux, des lecteurs mappés, des tâches planifiées, des services et des sources de données — y compris, pour plusieurs de ces types de préférences, un nom d'utilisateur et un mot de passe à appliquer sur les machines cibles.

Ces identifiants étaient stockés dans l'attribut cpassword du fichier XML de la préférence (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), chiffrés en AES-256, et écrits dans le partage SYSVOL du domaine — le même partage que chaque contrôleur de domaine réplique et que tout utilisateur authentifié (et, par défaut, les utilisateurs de tout domaine approuvé) peut lire afin que les postes clients récupèrent leurs objets de stratégie de groupe (GPO).

Le problème : Microsoft a publié dans sa propre documentation de protocole la clé AES privée utilisée pour chiffrer chaque valeur cpassword, car les GPP avaient besoin d'un moyen de déchiffrer la valeur côté client lors du traitement de la stratégie. Tout utilisateur de domaine authentifié pouvant lire SYSVOL — c'est-à-dire, par conception, absolument tous — peut trouver la chaîne chiffrée et la déchiffrer en quelques secondes avec des outils publiquement disponibles. L'exposition a été documentée publiquement pour la première fois en 2012 par le chercheur en sécurité Chris Campbell (obscuresec), qui a publié une preuve de concept PowerShell permettant de localiser et déchiffrer ces valeurs bien avant que Microsoft ne publie un correctif.

Pourquoi ce problème réapparaît encore une décennie plus tard

Si MS14-025 a été publié en 2014, pourquoi les audits trouvent-ils encore aujourd'hui des entrées cpassword actives ? Plusieurs schémas récurrents l'expliquent :

• Migrations de domaine et acquisitions. Les GPO sont fréquemment migrées en bloc depuis un domaine historique, avec toutes les préférences configurées avant que l'environnement acquis n'ait jamais été corrigé ou revu.
• Sauvegardes de GPO restaurées. Des sauvegardes de GPO effectuées avant 2014 et restaurées des années plus tard réintroduisent exactement le XML que le correctif était censé empêcher à l'avenir — le correctif protège l'éditeur, pas une opération de restauration.
• Environnements gérés par des MSP et prestataires. Un prestataire de services managés réutilisant un modèle de GPO standard sur plusieurs clients peut propager le même identifiant admin local exposé à tous les environnements que ce modèle touche.
• Absence de revue périodique de SYSVOL. Contrairement à un service actif, le contenu de SYSVOL n'expire pas et n'est signalé par aucun patching de routine — rien ne force une nouvelle analyse à moins que quelqu'un n'en lance une délibérément.

Aucun de ces scénarios ne nécessite qu'un système mal configuré ait manqué le correctif de 2014. Ils exigent uniquement qu'une valeur cpassword ait existé à un moment donné dans SYSVOL au cours de l'histoire du domaine et n'ait jamais été activement recherchée puis supprimée — ce qui explique précisément pourquoi le scan proactif, et non la conformité aux correctifs, est le contrôle qui referme réellement cette faille.

Comment ça fonctionne

Microsoft a corrigé une partie de ce problème avec MS14-025 (CVE-2014-1812), publié le 13 mai 2014, et livré sous la mise à jour KB2962486. Le correctif a supprimé les champs « Mot de passe » de l'éditeur de Group Policy Preferences dans la console de gestion des stratégies de groupe (GPMC) et les Remote Server Administration Tools (RSAT), afin que les administrateurs ne puissent plus créer de nouvelles entrées GPP contenant un mot de passe (Microsoft Support : MS14-025).

Ce que KB2962486 ne fait pas, c'est supprimer rétroactivement les valeurs cpassword déjà écrites dans SYSVOL avant l'installation du correctif, et il n'empêche pas non plus un attaquant de déchiffrer ce qui s'y trouve encore. Le guide de l'ANSSI sur l'administration sécurisée d'AD signale précisément cette lacune : le correctif modifie ce que l'éditeur permet à un administrateur de saisir désormais, mais les objets GPP historiques créés avant l'installation du correctif doivent être localisés et nettoyés manuellement (ANSSI-PA-099).

La clé AES elle-même n'est pas un secret que l'attaquant doit voler — c'est la même clé statique de 32 octets pour chaque domaine Active Directory sur Terre, documentée par Microsoft et reprise dans la recherche en sécurité depuis cette divulgation initiale de 2012, puis intégrée directement dans des outils offensifs comme PowerSploit et CrackMapExec (adsecurity.org : Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

La chaîne d'attaque

Exploiter un cpassword oublié ne nécessite aucun accès élevé ni aucun exploit — c'est une technique post-authentification disponible pour tout utilisateur de domaine, et souvent pour tout utilisateur d'une forêt approuvée également.

Étape 1 — Énumérer SYSVOL à la recherche de cpassword

Un attaquant disposant d'un identifiant de domaine valide (ou d'un point d'ancrage à faibles privilèges) recherche dans le partage SYSVOL les fichiers XML contenant l'attribut cpassword :

# Linux, avec des identifiants de domaine valides
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Étape 2 — Déchiffrer avec la clé AES publiée

Get-GPPPassword et les outils équivalents (Get-DecryptedCpassword, gpp-decrypt) appliquent la clé AES publiquement connue à la valeur cpassword décodée en Base64 et renvoient le texte en clair instantanément — il n'y a ni brute force ni étape de cassage, juste une routine de déchiffrement fixe.

Étape 3 — Réutiliser l'identifiant

Les GPP étant fréquemment utilisées pour standardiser un compte administrateur local sur de nombreuses machines, ou pour exécuter une tâche planifiée ou un service sous un compte de service de domaine, le mot de passe récupéré est souvent directement réutilisable pour un mouvement latéral ou une élévation de privilèges, sans technique supplémentaire nécessaire. Une seule entrée Groups.xml ayant défini un mot de passe admin local commun à l'ensemble du domaine suffit à compromettre tous les postes de travail concernés par cette GPO.

Détection

Pour confirmer directement l'exposition plutôt que d'attendre des signaux de journal, le guide de l'ANSSI sur l'administration sécurisée d'AD (ANSSI-PA-099) fournit une vérification proactive en une ligne que les auditeurs peuvent exécuter depuis un système joint au domaine :

:: Remplacer <FQDN> par le nom de domaine complet du domaine AD.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Tout résultat positif signifie qu'une valeur cpassword — outil corrigé ou non — se trouve encore aujourd'hui dans SYSVOL (ANSSI-PA-099, Recommandation R31, Listing 3). Comme cette vérification lit du contenu de fichier statique plutôt que de la télémétrie en direct, c'est le moyen le plus rapide pour un auditeur d'obtenir une réponse définitive sans attendre la rétention des journaux. Le même principe s'applique à d'autres fuites d'identifiants persistantes à vérifier lors du même passage, comme les mots de passe laissés dans les champs de description AD. Pour un tour d'horizon plus large des priorités d'une revue complète, consultez notre guide sur comment auditer la sécurité Active Directory.

Remédiation

1. Confirmez le déploiement de KB2962486 sur tout système encore utilisé pour éditer les stratégies de groupe via la console native GPMC/MMC (avant Windows Server 2016) ou via des outils RSAT plus anciens (avant Windows 10). Cela empêche uniquement la saisie de nouveaux mots de passe dans les GPP à l'avenir.
2. Lancez le scan SYSVOL (commande findstr ci-dessus, ou une recherche récursive équivalente) et recensez chaque fichier Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml et DataSources.xml de chaque GPO à la recherche d'un attribut cpassword — y compris les GPO désactivées et non liées, souvent ignorées lors des revues manuelles.
3. Faites tourner immédiatement chaque identifiant trouvé. Supprimer l'entrée XML n'invalide pas un mot de passe déjà déchiffrable ; considérez qu'il a été lu et agissez en conséquence.
4. Supprimez le paramètre GPP plutôt que de laisser un champ mot de passe vide — conformément à la recommandation R32 de l'ANSSI, aucun mot de passe ne devrait plus jamais être enregistré dans une préférence de stratégie de groupe (ANSSI-PA-099, Recommandation R32, p.49). Notre guide pratique des recommandations AD de l'ANSSI explique comment transformer une recommandation comme celle-ci en plan d'action.
5. Remplacez les comptes administrateurs locaux gérés par GPP par Windows LAPS, qui fait tourner un mot de passe unique et aléatoire par machine et le stocke dans un attribut AD protégé plutôt que dans un fichier XML statique.
6. Étendez la même vigilance aux scripts d'ouverture/fermeture de session stockés sur SYSVOL ou NETLOGON — la recommandation R31 de l'ANSSI applique le même principe de secret réutilisable à tout script lisible par des comptes à privilèges réduits, pas seulement au XML des GPP. Un script qui mappe un lecteur avec un mot de passe de compte de service intégré est exactement aussi exposé qu'un champ cpassword.
7. Durcissez l'accès en lecture là où c'est possible. SYSVOL et NETLOGON doivent rester lisibles pour le traitement des stratégies, mais vérifiez les dérives de permissions SYSVOL/NETLOGON au-delà du réglage par défaut, et activez le durcissement UNC sur ces partages pour que les clients valident l'intégrité et l'authentification mutuelle lors de leur lecture.
8. Relancez le scan après chaque restauration de sauvegarde de GPO ou migration de domaine, pas seulement une fois. Ces deux situations étant les principales sources de réapparition d'anciennes entrées cpassword, faites du re-scan de SYSVOL une étape permanente de tout plan de migration plutôt qu'un nettoyage ponctuel, et assignez-en la responsabilité pour ne pas dépendre de la mémoire de quelqu'un.

Comment EtcSec détecte ce problème

L'audit Active Directory d'EtcSec signale cette exposition sous le nom GPO_PASSWORD_IN_SYSVOL, un contrôle de sévérité critique qui analyse le XML de préférences de chaque GPO à la recherche d'un attribut cpassword renseigné — y compris les GPO désactivées ou non liées, que les revues manuelles manquent souvent. Il est associé à SYSVOL_NETLOGON_PERMISSIONS, qui examine les droits de lecture/écriture sur les partages SYSVOL et NETLOGON à la recherche de dérives par rapport à la ligne de base attendue. Ensemble, ces deux contrôles couvrent à la fois l'exposition GPP historique et l'hygiène de permissions continue nécessaire pour empêcher SYSVOL de redevenir une décharge de secrets réutilisables.