Registre Windows, GPO et services, fonctionnement et attaques

Registre Windows, GPO et services, fonctionnement et attaques

Le registre, les GPO (Group Policy Objects, objets de stratégie de groupe) et les services forment la colonne de configuration de Windows : le premier stocke, les deuxièmes imposent, les troisièmes exécutent. Les trois se rejoignent au même endroit, des clés de registre protégées par des ACL (Access Control Lists, listes de contrôle d’accès), et c’est là que se jouent la persistance et l’élévation de privilèges. Cette page décrit les trois mécanismes, ce qui les relie, et ce qu’il faut verrouiller en premier.

Explication de la marmotte

Un ordinateur sous Windows ressemble à un grand hôtel. Il y a un énorme cahier où chaque réglage de la maison est noté, un règlement envoyé par la direction à tous les hôtels de la chaîne, et du personnel qui travaille en coulisses sans qu’aucun client ne le voie. Comprendre ces trois choses, c’est savoir qui commande vraiment.

→ Lire l’explication complète de la marmotte

Registre Windows : ruches, clés racines et ACL

Le registre n’est pas une base unique. C’est un assemblage de fichiers, les ruches (hives), montés dans une arborescence commune au démarrage et à l’ouverture de session. Savoir quel fichier porte quelle branche répond à deux questions pratiques : que faut-il sauvegarder, et que récupère quelqu’un qui lit le disque hors ligne.

Branche logique	Fichier sur disque	Contenu
HKLM\SYSTEM	%SystemRoot%\System32\config\SYSTEM	pilotes, services, configuration de démarrage
HKLM\SOFTWARE	%SystemRoot%\System32\config\SOFTWARE	configuration machine des logiciels, stratégies machine
HKLM\SAM	%SystemRoot%\System32\config\SAM	comptes locaux et leurs empreintes de mot de passe
HKLM\SECURITY	%SystemRoot%\System32\config\SECURITY	secrets LSA, identifiants de domaine mis en cache
HKU\<SID>	%USERPROFILE%\NTUSER.DAT	configuration de l’utilisateur
HKU\<SID>_Classes	%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat	associations et classes propres à l’utilisateur

Quelques sigles à poser. HKLM (HKEY_LOCAL_MACHINE) porte la configuration de la machine. HKU (HKEY_USERS) contient une sous-clé par utilisateur dont le profil est chargé, nommée par son SID (Security Identifier, identifiant de sécurité). SAM désigne le Security Account Manager, LSA la Local Security Authority, l’autorité de sécurité locale qui garde entre autres les mots de passe des comptes de service.

Le reste est fait d’alias et de vues, et c’est là que les diagnostics dérapent :

• HKCU (HKEY_CURRENT_USER) n’existe pas en propre : c’est un lien vers HKU\<SID> de l’utilisateur du processus appelant. Un script lancé sous SYSTEM qui écrit dans HKCU écrit dans le profil de SYSTEM, pas dans celui de la personne assise devant l’écran.
• La ruche d’un utilisateur non connecté n’est pas montée. Auditer « tous les HKCU » d’un poste impose de charger chaque NTUSER.DAT (reg load), sinon l’audit ne voit que les sessions ouvertes.
• HKCR (HKEY_CLASSES_ROOT) est une vue fusionnée de HKLM\SOFTWARE\Classes et de HKCU\Software\Classes, la partie utilisateur étant prioritaire. Un utilisateur sans privilège peut donc redéfinir pour lui-même un objet COM (Component Object Model) déclaré au niveau machine : c’est le principe du détournement COM.
• HKLM\SYSTEM\CurrentControlSet est un lien vers ControlSet00x, choisi par la clé HKLM\SYSTEM\Select. Analyser une ruche hors ligne en cherchant CurrentControlSet ne donne rien : le lien n’existe que sur un système démarré.
• Sur un système 64 bits, un processus 32 bits qui ouvre HKLM\SOFTWARE est redirigé vers HKLM\SOFTWARE\WOW6432Node. Un paramètre posé dans une vue est invisible dans l’autre, ce qui explique une bonne part des « la clé est là mais le logiciel ne la lit pas ».

ACL des clés et audit

Chaque clé porte un descripteur de sécurité : un propriétaire, une DACL (Discretionary Access Control List) qui dit qui peut lire, créer une sous-clé ou écrire une valeur, et une SACL (System Access Control List) qui dit quels accès sont journalisés. Les droits s’héritent de clé en clé, et les valeurs n’ont pas d’ACL propre : qui écrit dans une clé écrit dans toutes ses valeurs.

Deux conséquences d’architecture. Un utilisateur standard a un contrôle étendu sur sa ruche, donc toute décision de sécurité lue dans HKCU par un processus privilégié est une décision confiée à l’utilisateur. Et le registre ne garde aucun historique : une clé expose seulement la date de sa dernière écriture, pas l’auteur ni l’ancienne valeur. La traçabilité vient d’ailleurs : SACL sur les clés sensibles avec la sous-catégorie d’audit « Registre » (événement 4657 du journal Sécurité pour une valeur modifiée), ou les événements 12, 13 et 14 de Sysmon, dont la collecte est décrite dans Centraliser les journaux Sysmon des postes Windows.

Emplacements de persistance

Le registre est le premier endroit où un attaquant s’installe pour survivre au redémarrage, parce que Windows y lit ce qu’il doit lancer. Les emplacements à surveiller en priorité :

• Software\Microsoft\Windows\CurrentVersion\Run et RunOnce, sous HKLM comme sous HKCU ;
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, valeurs Shell et Userinit ;
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<exe>, valeur Debugger, qui substitue un programme à un autre ;
• HKLM\SYSTEM\CurrentControlSet\Control\Lsa, valeurs Security Packages et Notification Packages, chargées dans le processus LSA ;
• HKLM\SYSTEM\CurrentControlSet\Control\Session Manager, valeur BootExecute ;
• HKLM\SYSTEM\CurrentControlSet\Services, traité plus bas.

La liste est loin d’être fermée, et la recopier dans un tableur ne protège de rien. L’outil Autoruns de Sysinternals en énumère bien davantage et reste la référence pour un état des lieux. Les clés Run et RunOnce existent aussi sous HKCU, où l’utilisateur écrit sans aucun privilège : la persistance n’exige pas d’être administrateur, seulement d’être patient.

GPO : conteneur dans l’annuaire, modèle dans SYSVOL et ordre LSDOU

Une GPO est un objet en deux morceaux qui vivent dans deux systèmes de réplication différents. Le GPC (Group Policy Container) est un objet de l’annuaire Active Directory, sous CN=Policies,CN=System, nommé par un GUID (Globally Unique Identifier) : il porte la version, les droits et la liste des extensions concernées. Le GPT (Group Policy Template) est un dossier du partage SYSVOL des contrôleurs de domaine, \\<domaine>\SYSVOL\<domaine>\Policies\{GUID}\, qui porte le contenu : GPT.INI, Machine\Registry.pol, User\Registry.pol, le modèle de sécurité GptTmpl.inf, les scripts, les fichiers XML (Extensible Markup Language) des préférences.

Le schéma suivant montre le trajet complet d’un paramètre, de la console d’administration à la valeur lue par l’application ; il faut y repérer les deux canaux distincts (annuaire et partage de fichiers) et le fait que le client tire, le contrôleur de domaine ne pousse rien.

Deux fragilités découlent de cette structure. L’annuaire et SYSVOL se répliquent séparément (DFSR, Distributed File System Replication, pour SYSVOL) : pendant la fenêtre de convergence, un client peut lire un GPC à jour et un GPT ancien, ou l’inverse. Et une réplication SYSVOL cassée sur un seul contrôleur de domaine produit des postes qui appliquent des versions différentes selon le serveur qui leur a répondu, sans erreur visible côté administration.

Liaison, ordre LSDOU, héritage et « Appliqué »

Une GPO non liée ne fait rien. La liaison se fait sur un site, un domaine ou une OU (Organizational Unit, unité d’organisation), par l’attribut gPLink du conteneur. Le traitement suit l’ordre LSDOU (Local, Site, Domaine, OU) : stratégie locale d’abord, puis site, domaine, et les OU de la plus haute à la plus proche de l’objet. La dernière écriture gagne, donc la GPO la plus proche de la machine ou de l’utilisateur l’emporte en cas de conflit.

Les modificateurs, par ordre de nuisance potentielle :

• Ordre des liens : dans un même conteneur, le lien d’ordre 1 est traité en dernier, donc il gagne.
• Blocage de l’héritage : une OU peut refuser les GPO venues d’en haut.
• « Appliqué » (Enforced) : indicateur posé sur le lien. La GPO gagne alors sur tout ce qui est plus bas et traverse les blocages d’héritage. Entre deux GPO appliquées, c’est la plus haute dans la hiérarchie qui gagne, à l’inverse de la règle normale.
• Filtrage de sécurité : une GPO ne s’applique qu’aux principaux qui ont à la fois « Lire » et « Appliquer la stratégie de groupe » sur l’objet. Depuis la mise à jour MS16-072, les GPO utilisateur sont récupérées dans le contexte du compte machine : retirer « Utilisateurs authentifiés » du filtrage sans redonner « Lire » aux ordinateurs fait disparaître la GPO en silence.
• Filtres WMI (Windows Management Instrumentation) et boucle de rappel (loopback), qui applique à l’utilisateur des paramètres choisis selon la machine où il ouvre sa session.

Position assumée : réserver « Appliqué » au socle de sécurité lié au domaine, et s’interdire le blocage d’héritage. Chaque exception empilée rend le résultat calculable seulement par outil, et une stratégie que personne ne sait prédire de tête finit par ne plus être relue. Vingt ans de métier apprennent que l’arborescence d’OU dessinée pour ressembler à l’organigramme survit rarement à la première réorganisation, alors que celle dessinée pour porter les GPO vieillit très bien.

Actualisation des stratégies

Le traitement au premier plan a lieu au démarrage (paramètres machine) et à l’ouverture de session (paramètres utilisateur). En arrière-plan, l’actualisation se fait toutes les 90 minutes avec un décalage aléatoire de 0 à 30 minutes, et toutes les 5 minutes sur un contrôleur de domaine. Certaines extensions (installation de logiciels, redirection de dossiers) ne s’exécutent qu’au premier plan.

Le piège : par défaut, une extension ne retraite pas une GPO dont la version n’a pas changé. Si un administrateur local efface une valeur sous une clé Policies, elle ne revient pas à l’actualisation suivante. Les paramètres de sécurité font exception, réappliqués toutes les 16 heures. Pour les valeurs de registre, le paramètre « Configurer le traitement de la stratégie de Registre », option « Traiter même si les objets de stratégie de groupe n’ont pas été modifiés », rétablit la réapplication systématique. Pour un socle de sécurité, l’activer : le coût est un peu de traitement sur le poste, le gain est une dérive corrigée en deux heures au plus au lieu de jamais.

Stratégies, préférences et tatouage

L’essentiel d’une GPO se traduit en valeurs de registre. Les modèles d’administration (fichiers ADMX, des descriptions XML des paramètres) ne contiennent aucune logique : ils associent un libellé de la console à une clé et une valeur, sérialisées dans Registry.pol puis écrites par l’extension côté client (Client-Side Extension) dans quatre emplacements réservés :

• HKLM\SOFTWARE\Policies et HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies ;
• HKCU\Software\Policies et HKCU\Software\Microsoft\Windows\CurrentVersion\Policies.

Ces clés ont deux propriétés qui font une vraie stratégie. Leur ACL interdit l’écriture à l’utilisateur standard, y compris dans sa propre ruche. Et leur contenu est retiré quand la GPO cesse de s’appliquer : l’état de la machine suit l’état de l’annuaire.

Les préférences (GPP, Group Policy Preferences) et tout paramètre de registre écrit hors de ces quatre clés se comportent autrement. La valeur est posée à l’emplacement natif de l’application, l’utilisateur ou l’administrateur local peut la modifier, et elle reste en place quand la GPO est déliée : c’est le tatouage. Les paramètres de sécurité (droits utilisateur, ACL, services système) persistent de la même façon tant qu’une autre stratégie ne les réécrit pas.

Le compromis est là. Les stratégies sont réversibles et verrouillées, mais ne couvrent que ce que l’éditeur a prévu de lire sous Policies. Les préférences couvrent tout, au prix d’un état qui s’accumule et ne se nettoie pas. La règle : stratégie pour tout ce qui est une exigence de sécurité, préférence seulement faute de modèle d’administration, et dans ce cas prévoir explicitement la GPO de retour arrière. Délier une GPO ne « désactive » pas un durcissement tatoué, croire le contraire est l’erreur la plus répandue du domaine.

Surface d’attaque des GPO

• Droit d’écriture sur une GPO : il équivaut à l’exécution de code sur tous les objets visés (script de démarrage, tâche planifiée immédiate, ajout à un groupe local). Une GPO liée aux contrôleurs de domaine est un actif du niveau le plus sensible, ses éditeurs aussi.
• Droit d’écriture sur gPLink : pouvoir lier une GPO à une OU sans pouvoir la modifier suffit, s’il existe ailleurs une GPO contrôlée. Les délégations de ce type sont détaillées dans Active Directory : structure, délégations et chemins d’attaque.
• SYSVOL lisible par tout compte authentifié : c’est voulu, donc tout secret qui s’y trouve est publié en interne. Les mots de passe des préférences (attribut cpassword) sont chiffrés en AES (Advanced Encryption Standard) avec une clé documentée publiquement ; le correctif MS14-025 empêche d’en créer de nouveaux, il ne supprime pas les anciens fichiers. Même constat pour les scripts de connexion avec identifiants en dur.
• Usurpation du serveur : un client qui récupère une GPO auprès d’un faux contrôleur de domaine exécute ce qu’on lui sert. La parade est le durcissement des chemins UNC (Universal Naming Convention), qui exige authentification mutuelle et intégrité pour \\*\SYSVOL et \\*\NETLOGON (clé HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths). Le relais d’authentification qui rend ce scénario praticable est traité dans la page NTLM (NT LAN Manager) : fonctionnement et durcissement.

Services Windows : SCM, clé Services et comptes de service

Un service est un programme lancé sans session interactive par le SCM (Service Control Manager, processus services.exe). Le SCM ne possède aucune configuration propre : sa base est la clé HKLM\SYSTEM\CurrentControlSet\Services, une sous-clé par service ou par pilote. Le schéma suivant montre les trois objets à protéger pour un seul service (la clé, le binaire, le compte) et le fait que l’un quelconque des trois suffit à prendre le contrôle.

Les valeurs qui comptent : ImagePath (la ligne de commande), ObjectName (le compte), Start (0 et 1 pour les pilotes chargés tôt, 2 automatique, 3 manuel, 4 désactivé), Type (pilote noyau, processus propre ou partagé), DelayedAutostart, FailureActions, et Parameters\ServiceDll pour les services hébergés dans svchost.exe. Un pilote noyau se déclare ici aussi : écrire dans cette clé, c’est potentiellement charger du code dans le noyau.

Comptes de service

Compte	Privilèges locaux	Identité sur le réseau	Mot de passe
LocalSystem	totaux	compte machine	aucun à gérer
LocalService	réduits	anonyme	aucun à gérer
NetworkService	réduits	compte machine	aucun à gérer
Compte virtuel NT SERVICE\<nom>	réduits, identité propre au service	compte machine	aucun à gérer
gMSA	ceux qu’on lui accorde	compte de domaine dédié	géré par l’annuaire, renouvelé automatiquement
Compte de domaine classique	ceux qu’on lui accorde	compte de domaine	statique, stocké dans les secrets LSA

Le gMSA (group Managed Service Account) est un compte de domaine dont le mot de passe est calculé par le KDS (Key Distribution Service) des contrôleurs de domaine et renouvelé tous les 30 jours par défaut ; seules les machines explicitement autorisées peuvent le récupérer.

La recommandation tient en trois lignes. Compte virtuel pour un service sans besoin d’identité réseau propre : il donne un SID par service, donc des ACL fichier et registre par service, sans rien à administrer. gMSA dès qu’il faut une identité de domaine. LocalSystem uniquement avec une justification écrite. Le compte de domaine classique avec mot de passe statique cumule tout : son mot de passe est lisible dans les secrets LSA par tout administrateur local de chaque machine où il tourne, et s’il porte un SPN (Service Principal Name), il est exposé au cassage hors ligne décrit dans Active Directory : chemins d’attaque. Un compte de service membre des administrateurs du domaine « parce que l’installeur le demandait » reste le raccourci le plus fréquent entre un serveur applicatif et l’annuaire entier.

Les comptes réduits ont une limite à connaître : LocalService, NetworkService et les comptes virtuels détiennent le privilège d’emprunt d’identité (SeImpersonatePrivilege), levier classique d’élévation vers SYSTEM. Réduire le compte limite les dégâts d’une compromission, cela ne remplace pas le correctif du service.

Descripteur de sécurité, binaire, clé et chemins sans guillemets

Quatre contrôles d’accès indépendants protègent un service, et l’élévation de privilèges locale passe par le plus faible :

• Le descripteur de sécurité du service, tenu par le SCM. Un principal non administrateur doté de SERVICE_CHANGE_CONFIG peut réécrire ImagePath et faire lancer n’importe quoi sous le compte du service ; WRITE_DAC et WRITE_OWNER y mènent en une étape de plus.
• Les droits sur le binaire et son dossier. Un exécutable remplaçable par les utilisateurs est un service offert. Le cas typique : un logiciel installé à la racine d’un volume, hors de Program Files, qui hérite de droits de création accordés aux utilisateurs authentifiés.
• Les droits sur la clé du service. Écrire dans Services\<nom> contourne le descripteur précédent : le SCM relit ImagePath au prochain démarrage.
• Les chemins non entre guillemets. Pour C:\Program Files\Outil Métier\svc.exe sans guillemets, Windows essaie successivement C:\Program.exe, puis C:\Program Files\Outil.exe, avant le bon chemin. Le défaut n’est exploitable que si l’attaquant peut créer un fichier dans l’un des dossiers intermédiaires ; il se corrige de toute façon en ajoutant les guillemets dans ImagePath.

Le chargement d’une DLL (Dynamic-Link Library) depuis un dossier inscriptible relève de la même famille, celle du détournement de l’ordre de recherche, détaillée dans DLL hijacking Windows et ordre de recherche des bibliothèques ; la réduction du nombre de services exposés est traitée dans Durcissement système et minimisation de surface.

Exemple : suivre un service désactivé par GPO jusqu’au registre

Cas d’école qui traverse les trois mécanismes : désactiver le spouleur d’impression (Spooler) sur des serveurs par le paramètre « Services système » d’une GPO. Le schéma décrit ce qui se passe réellement, et où la chaîne peut casser sans bruit.

À lire dans cet ordre : le paramètre voyage par SYSVOL, pas par l’annuaire ; il finit en une seule valeur de registre ; un administrateur local peut le défaire, et c’est la réapplication périodique des paramètres de sécurité qui le rétablit ; délier la GPO ne réactive pas le service. Trois commandes confirment chaque étage, à lancer dans une invite élevée sur le serveur :

:: 1. La GPO est-elle bien appliquée à la machine (et sinon, filtrée pourquoi) ?
gpresult /scope computer /r

:: 2. La valeur est-elle arrivée dans le registre ? (attendu : 0x4)
reg query HKLM\SYSTEM\CurrentControlSet\Services\Spooler /v Start

:: 3. Que voit le SCM, et qui a le droit de reconfigurer le service ?
sc.exe qc Spooler
sc.exe sdshow Spooler

La dernière commande rend le descripteur en SDDL (Security Descriptor Definition Language). Le réflexe de lecture : chercher DC (changer la configuration), WD (réécrire la DACL) ou WO (changer le propriétaire) dans une entrée accordée à AU (utilisateurs authentifiés), BU (utilisateurs) ou IU (utilisateurs interactifs). S’il y en a une, le service est une élévation de privilèges en attente.

Ce que registre, GPO et services ne garantissent pas

• Une GPO n’est pas une frontière de sécurité face à un administrateur local. Il a les droits d’écriture sur HKLM, donc sur les clés Policies machine et sur la clé Services. La GPO corrige après coup, elle n’empêche pas. Ce qui empêche, c’est l’absence de droits d’administration locale.
• Une valeur sous Policies ne vaut que si quelque chose la lit. Un composant tiers qui ignore sa clé de stratégie affichera un paramètre « configuré » dans la console et fera autre chose. La conformité se mesure sur le comportement, pas sur le rapport de GPO.
• Une machine qui ne joint pas un contrôleur de domaine garde son dernier état. Un poste nomade hors réseau interne ne reçoit ni nouvelle stratégie ni retrait.
• Les ACL du registre ne protègent pas un disque lu hors ligne. Les fichiers SAM, SECURITY et SYSTEM copiés depuis un disque non chiffré livrent empreintes locales, secrets LSA et identifiants en cache. Le reste doit venir du chiffrement de volume, et de la restriction du privilège de sauvegarde, qui permet de lire les ruches sur un système en marche.
• Un compte de service réduit ne confine pas le service. L’isolement réseau, le filtrage sortant et la mise à jour du logiciel restent à faire.

Côté Linux, le découpage équivalent (fichiers de configuration, droits, processus de fond) est décrit dans Linux : shell, permissions et processus et dans Systemd : services, unités et journal ; la différence de fond est qu’ici la configuration et son contrôle d’accès vivent dans une base, pas dans des fichiers texte comparables ligne à ligne.

Prérequis et exploitation des GPO, des services et du registre

Prérequis de plateforme. Les gMSA exigent un schéma d’annuaire Windows Server 2012 ou ultérieur et une clé racine KDS créée au préalable (Add-KdsRootKey), utilisable par défaut dix heures après sa création, le temps de la réplication. L’intervalle de renouvellement du mot de passe se fixe à la création du compte et ne se modifie plus ensuite. Les modèles d’administration gagnent à être centralisés dans le magasin SYSVOL\<domaine>\Policies\PolicyDefinitions, faute de quoi chaque console édite avec sa propre version. SYSVOL doit être répliqué par DFSR.

Secrets et rotation. Aucun mot de passe dans SYSVOL, jamais, sous aucune forme. Inventorier les comptes de service de domaine à mot de passe statique et les migrer vers gMSA ; pour ceux qui restent, la rotation implique de mettre à jour chaque service qui les utilise, raison pour laquelle elle n’est en pratique jamais faite.

Supervision. Trois signaux valent leur coût : la création de service (événement 7045 du journal Système, 4697 du journal Sécurité si l’audit correspondant est activé), la modification d’un objet GPO dans l’annuaire (événement 5136, avec SACL sur le conteneur des stratégies), et les écritures sur les clés de persistance listées plus haut. Le journal Microsoft-Windows-GroupPolicy/Operational de chaque poste dit quelles GPO ont été traitées et lesquelles ont échoué. Un contrôle périodique compare la version du GPC et celle du GPT.INI sur chaque contrôleur de domaine : un écart durable signale une réplication en panne.

Sauvegarde et reprise. Une sauvegarde de GPO depuis la GPMC (Group Policy Management Console) ou par Backup-GPO capture le contenu et les droits de l’objet, pas ses liens (ils appartiennent aux conteneurs) ni les filtres WMI, à exporter séparément. Restaurer des GPO sans la carte des liens redonne des objets inertes. Côté registre, sauvegarder les fichiers de ruche à froid ou par un mécanisme d’instantané, et traiter ces sauvegardes comme des secrets : elles contiennent SAM et SECURITY.

FAQ

Une GPO déliée annule-t-elle ses effets ?

Seulement pour les valeurs écrites sous les quatre clés Policies, retirées au traitement suivant. Les préférences, les paramètres de sécurité et toute valeur écrite ailleurs restent en place. Le retour arrière d’un paramètre tatoué demande une GPO qui écrit explicitement la valeur inverse.

Pourquoi un paramètre apparaît-il dans la console mais pas sur le poste ?

Dans l’ordre de probabilité : le filtrage de sécurité (droit « Lire » manquant pour le compte machine), une GPO plus proche ou marquée « Appliqué » qui gagne, un filtre WMI faux, une réplication SYSVOL en retard, ou une extension qui ne s’exécute qu’au premier plan et attend un redémarrage. gpresult /h <fichier> produit le rapport qui départage ces cas.

LocalSystem est-il acceptable pour un service applicatif ?

Rarement. LocalSystem a tous les privilèges locaux et s’authentifie sur le réseau avec le compte machine. Une faille dans le service donne alors la machine entière, y compris ses ruches SAM et SECURITY. Un compte virtuel couvre la plupart des besoins avec le même coût d’administration, c’est-à-dire aucun.

🐝 Ce qui arrive si on s’en passe

Sans stratégies centralisées, chaque machine devient un cas particulier : il n’existe plus d’état de référence auquel comparer un poste, et une modification malveillante du registre ne se distingue plus d’un réglage manuel ancien. Sans maîtrise des droits sur les objets de stratégie, la liste des personnes capables d’exécuter du code sur tout le parc cesse d’être connue. Sans discipline sur les comptes de service, un défaut dans une application de second rang donne les pouvoirs complets sur son serveur, puis une identité de domaine réutilisable ailleurs. Sans journalisation des créations de service et des écritures sensibles, une reconstitution après incident ne peut dater ni l’installation d’un programme persistant ni le changement d’un réglage, et la reprise se réduit à réinstaller sans savoir depuis quand.

🦫 Explication de la marmotte 🍫

Windows range presque tous ses réglages dans une base appelée registre. Cette base est faite de plusieurs fichiers sur le disque, certains pour la machine entière, un par utilisateur. Chaque réglage y est rangé dans une clé, et chaque clé possède sa propre liste de personnes autorisées à la lire ou à la modifier. Dans une entreprise, personne ne règle les machines une par une. Les administrateurs écrivent des stratégies sur des serveurs centraux. Chaque ordinateur vient les chercher au démarrage, puis à peu près toutes les heures et demie, et les recopie dans son propre registre, à des emplacements réservés que l’utilisateur ordinaire ne peut pas modifier. Quand plusieurs stratégies se contredisent, celle qui est rattachée au plus près de la machine l’emporte, sauf si une stratégie plus générale a été marquée comme prioritaire. Les services, eux, sont des programmes lancés par le système sans que personne n’ouvre de session. Leur description (quel programme, quel compte, quel mode de démarrage) est aussi rangée dans le registre. Tout se tient donc par les droits : si une personne non autorisée peut modifier une stratégie, tous les ordinateurs concernés lui obéissent ; si elle peut modifier la description d’un service ou remplacer son programme, elle obtient les pouvoirs du compte qui fait tourner ce service. Et quand un ordinateur ne parvient pas à joindre les serveurs, il garde ses anciens réglages sans prévenir.

À lire aussi

• GPO Active Directory : durcissement, abus et contrôleFonctionnement, usages de durcissement, détournements et contrôle des objets de stratégie de groupe (GPO) dans Active Directory.
• Auditer l'héritage des permissions et le droit effectifComment un droit descend par héritage sur NTFS, Active Directory, SharePoint et dans l'IAM cloud, où cet héritage se rompt ou se contourne, et comment auditer le droit effectif plutôt que les listes d'accès.
• Auditer les comptes orphelins Active DirectoryMéthode pas-à-pas pour détecter, qualifier et traiter les comptes orphelins et les droits excessifs dans un annuaire d’entreprise.
• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.

Pages voisines

La citent

• RDP exposé sur Internet : risques, durcissement et détection
• Auditer l'héritage des permissions et le droit effectif

Registre Windows, GPO et services, fonctionnement et attaques

Elle cite

• ⇄Lien dans les deux sens :Active Directory délégations et chemins d’attaque
• ⇄Lien dans les deux sens :Comment structurer Active Directory et déléguer sans escalade
• Durcissement Linux et Windows par minimisation de surface
• Linux shell, permissions et processus, le modèle de contrôle d'accès
• Systemd : gérer services, unités et journal sous Linux
• Centraliser les journaux Sysmon des postes Windows
• DLL hijacking Windows et ordre de recherche des bibliothèques
• NTLM : protocole authentification LAN Manager New Technology Microsoft

⇄ : les deux pages se citent l’une l’autre.