Angles morts supervision Active Directory : Display Specifiers, RODC, falsification Default Domain Policy et PAM Shadow Principals

Angles morts supervision Active Directory : Display Specifiers, RODC et deux autres

Les angles morts de supervision Active Directory — display specifiers, mise en cache des identifiants RODC, falsification de la Default Domain Policy et PAM shadow principals — apparaissent rarement dans une revue de sécurité standard, alors que ces quatre mécanismes sont documentés par Microsoft et peuvent offrir à un attaquant persistance ou accès privilégié pendant que les tableaux de bord habituels (appartenance à Domain Admins, droits DCSync, modifications d'ACL sur les objets Tier 0) restent au vert. Ce sont des angles morts parce que personne ne pointe une SACL ou une requête vers eux, pas parce qu'ils sont cachés.

Cet article couvre chacun d'eux tour à tour : ce qu'est réellement l'objet ou le mécanisme, comment il est détourné ou dérive, ce qu'il faut surveiller pour le détecter, et comment y remédier.

Display Specifiers : un point d'extension de l'interface transformé en backdoor de persistance

Le mécanisme

Les display specifiers sont des objets de classe displaySpecifier, stockés dans des conteneurs spécifiques à chaque locale sous CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> — par exemple CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration. Parce qu'ils résident dans le naming context Configuration, ils se répliquent vers tous les contrôleurs de domaine de la forêt. Leur objectif documenté, selon la référence de programmation Win32 AD de Microsoft, est entièrement légitime : ils stockent les données derrière les fiches de propriétés, les menus contextuels, les icônes et les assistants de création dans les outils MMC comme Active Directory Users and Computers (ADUC).

Les attributs qui rendent cela intéressant d'un point de vue sécurité sont adminContextMenu et adminPropertyPages (snap-ins administratifs) ainsi que leurs équivalents non-admin contextMenu/shellContextMenu — tous documentés dans la spécification de protocole [MS-ADTS] de Microsoft et la référence de classe de schéma Display-Specifier. Chacun peut enregistrer un objet COM ou une application à exécuter lorsqu'un administrateur interagit avec un objet via ADUC. Les chercheurs en sécurité de Semperis et SDM Software ont documenté directement ce cas d'abus : un attaquant disposant d'un accès en écriture à un display specifier peut ajouter une entrée de menu contextuel factice — qui ressemble à une action normale (par exemple une option de réinitialisation de mot de passe) — mais qui lance en réalité un script lorsqu'un administrateur du helpdesk fait un clic droit sur un objet utilisateur.

Détection

Les modifications d'objets d'annuaire génèrent l'Event ID 5136 de sécurité Windows (« A directory service object was modified »), mais seulement si deux conditions sont réunies : le DC a la sous-catégorie d'audit avancé « Audit Directory Service Changes » activée, et l'objet cible porte une SACL pour les attributs concernés. Aucune des deux n'est activée par défaut pour le conteneur DisplaySpecifiers — c'est précisément pour cela que cet angle mort existe. Une fois l'audit en place, surveillez les événements 5136 où la classe d'objet est displaySpecifier et l'attribut modifié est adminContextMenu, adminPropertyPages, contextMenu ou shellContextMenu. Voir Supervision Active Directory : les Event ID de sécurité qui comptent pour la base de politique d'audit plus large que ces contrôles supposent.

# Énumère tous les objets display specifier et leurs attributs de menu/fiche de propriétés
Get-ADObject -SearchBase "CN=DisplaySpecifiers,CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'displaySpecifier'" `
  -Properties adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu |
  Where-Object { $_.adminContextMenu -or $_.adminPropertyPages -or $_.contextMenu -or $_.shellContextMenu } |
  Select-Object Name, adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu

Une base saine pour cette requête est un jeu de résultats vide sur la plupart des domaines — tout résultat mérite une revue manuelle du CLSID COM ou du chemin d'application référencé.

Falsification de la Default Domain Policy : des changements silencieux dans la base de sécurité du domaine

Le mécanisme

La Default Domain Policy porte un GUID bien connu et indépendant de la forêt — {31B2F340-016D-11D2-945F-00C04FB984F9} — et applique la base de politique de compte, de mot de passe, Kerberos et de verrouillage à l'échelle du domaine, sauf si elle est surchargée par une GPO plus spécifique. Parce que ce GUID est codé en dur et prévisible, et parce que cette GPO est ancienne au point que la plupart des équipes ont cessé de la revoir après le durcissement initial, les modifications qui lui sont apportées passent généralement inaperçues. MITRE ATT&CK répertorie la falsification de GPO comme la sous-technique T1484.001 (Domain or Tenant Policy Modification: Group Policy Modification) — les adversaires modifient les GPO pour affaiblir les seuils de verrouillage de compte, désactiver la complexité des mots de passe, ou pousser une tâche planifiée / un script de connexion vers chaque ordinateur qui applique la politique.

Détection

Deux Event ID distincts couvrent des couches différentes d'un changement de GPO, et les confondre est une erreur courante :

• Event ID 5136 (« A directory service object was modified ») se déclenche sur l'objet AD groupPolicyContainer lui-même lorsque la sous-catégorie « Audit Directory Service Changes » et une SACL sur l'objet sont toutes deux en place. Le contenu de détection de Splunk et les recommandations de détection de MITRE pointent tous deux spécifiquement la surveillance des attributs gPCFileSysPath, gPCMachineExtensionNames et versionNumber — une incrémentation de version sans demande de changement SYSVOL correspondante est en soi un signal à signaler.
• Event ID 4739 (« Domain Policy was changed ») se déclenche lorsque la politique de compte effective — seuil de verrouillage, politique de mot de passe, politique Kerberos — change réellement, que ce changement provienne de la Group Policy ou de la Local Security Policy. C'est l'événement à plus fort signal pour savoir « si la base de sécurité elle-même a bougé », mais il n'indique pas quelle GPO ou quel administrateur a fait la modification — associez-le au 5136 pour l'attribution.

# Ébauche de détection façon Splunk : modification de l'objet Default Domain Policy
index=wineventlog EventCode=5136 ObjectDN="*CN=Policies,CN=System,DC=*"
| search ObjectDN="*{31B2F340-016D-11D2-945F-00C04FB984F9}*"
| table _time, SubjectUserName, AttributeLDAPDisplayName, AttributeValue, OperationType

PAM Shadow Principals : un accès admin éphémère que les requêtes standard ratent

Le mécanisme

La fonctionnalité Privileged Access Management (PAM) de Windows Server, construite sur Microsoft Identity Manager, accorde un accès privilégié limité dans le temps sans jamais ajouter de compte à un groupe permanent comme Domain Admins. La documentation PAM de Microsoft décrit elle-même le mécanisme : un shadow principal — un objet de classe msDS-ShadowPrincipal, créé uniquement dans le conteneur par défaut CN=Shadow Principal Configuration sous CN=Services dans le NC Configuration d'une forêt bastion — porte un attribut msDS-ShadowPrincipalSid qui le mappe vers un SID de groupe privilégié de la forêt de production (par exemple Domain Admins). L'appartenance à ce shadow principal est accordée avec une durée de vie (TTL) via la fonctionnalité AD Expiring Links (Windows Server 2016+) : le KDC plafonne tout ticket Kerberos qu'il émet à la TTL restante sur le lien, de sorte que l'accès expire réellement au lieu de dépendre de quelqu'un qui se souvient de le retirer.

L'angle mort : les liens de groupe expirants sont stockés comme des valeurs ordinaires de l'attribut member avec un indicateur de TTL, mais cette TTL n'est visible que par une requête qui passe explicitement le contrôle étendu LDAP_SERVER_LINK_TTL (OID 1.2.840.113556.1.4.2309), comme le documentent les recherches de DSInternals sur le fonctionnement réel des Expiring Links. Une requête classique « qui est dans ce groupe » qui ne passe pas ce contrôle voit une appartenance d'apparence normale — pas d'expiration, pas d'indicateur de limitation dans le temps évident — ce qui signifie qu'un administrateur qui scanne les groupes shadow principal avec un outillage d'audit AD générique peut manquer le fait que l'accès est éphémère par conception, ou manquer entièrement des ajouts d'appartenance de courte durée si l'intervalle de scan est plus long que la TTL.

Détection

Les groupes shadow principal restent des objets de classe groupe de sécurité, donc les ajouts d'appartenance génèrent les mêmes événements AD standard d'appartenance à un groupe que n'importe quel autre groupe, selon le type de groupe : 4728 (membre ajouté à un groupe de sécurité global), 4732 (domaine local), 4756 (universel). Filtrez ces événements spécifiquement pour les objets situés dans CN=Shadow Principal Configuration,CN=Services,CN=<config-NC> pour isoler les activations PAM de l'administration de groupe classique.

# Liste les shadow principals actuels et leur SID de forêt de production associé
Get-ADObject -SearchBase "CN=Shadow Principal Configuration,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'msDS-ShadowPrincipal'" `
  -Properties 'msDS-ShadowPrincipalSid', member |
  Select-Object Name, 'msDS-ShadowPrincipalSid', @{N='MemberCount';E={$_.member.Count}}

Mise en cache des identifiants RODC, en bref

Les Read-Only Domain Controllers (RODC) sont déployés spécifiquement pour les sites à faible confiance — agences, emplacements physiquement exposés — en partant du principe qu'en cas de compromission, le rayon d'impact se limite aux mots de passe de comptes qu'il était autorisé à mettre en cache. Cette limite est appliquée par deux appartenances de groupe : le Allowed RODC Password Replication Group (vide par défaut — un RODC ne met rien en cache tant que ce n'est pas explicitement autorisé) et le Denied RODC Password Replication Group, correspondant aux attributs msDS-RevealOnDemandGroup et msDS-NeverRevealGroup documentés par Microsoft. Ce qui a réellement été mis en cache est visible via msDS-RevealedList ; qui s'est authentifié via le RODC figure dans msDS-AuthenticatedToAccountlist.

C'est le seul angle mort de cet article où la solution est avant tout une question de politique, pas une lacune de supervision que la plupart des équipes ignorent — EtcSec a déjà couvert le parcours complet de détection et de remédiation pour la mise en cache privilégiée sur RODC, y compris les mauvaises configurations précises de la Password Replication Policy qui laissent un identifiant Tier 0 se retrouver là où il ne devrait jamais être répliqué. Voir RODC mise en cache des identifiants privilégiés : le contrôleur de domaine en lecture seule qui détient les hachages Domain Admin pour l'analyse approfondie ; le résumé ici est volontairement bref pour éviter de la dupliquer.

Angles morts supervision Active Directory : ce qu'il faut réellement surveiller

Aucun de ces contrôles ne nécessite un nouveau pipeline de journalisation — il faut simplement des SACL placées sur des objets qui n'en ont pas par défaut, et quelqu'un pour interroger des attributs que les scripts de contrôle de santé AD standard ne touchent pas.

Remédiation

Étape par étape

1. Display specifiers. Placez une SACL « Write all properties » (ou, plus précisément, sur les attributs de menu/fiche de propriétés concernés) sur CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> et ses enfants. Établissez dès maintenant une base de référence des valeurs actuelles de adminContextMenu/adminPropertyPages, car une backdoor compromise pourrait déjà être présente.
2. Default Domain Policy. Appliquez une SACL à l'objet groupPolicyContainer de la Default Domain Policy ainsi qu'à son dossier SYSVOL (\\<domain>\SYSVOL\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}). Générez une alerte sur toute paire 5136/4739 qui ne correspond à aucun ticket de changement suivi.
3. PAM shadow principals. Si PAM/MIM n'est pas déployé intentionnellement, confirmez que le conteneur CN=Shadow Principal Configuration est vide et qu'il le reste. S'il est déployé, revoyez l'appartenance aux shadow principals à une cadence qui tient compte de TTL plus courtes que votre intervalle de revue — un lien qui a expiré entre deux scans hebdomadaires n'apparaît dans aucun des deux, sauf si vous comparez les événements 4728/4732/4756 plutôt que de simples instantanés d'appartenance ponctuels.
4. Mise en cache des identifiants RODC. Confirmez que le Allowed RODC Password Replication Group ne contient aucun principal Tier 0, directement ou via une appartenance de groupe imbriquée — voir l'article dédié lié ci-dessus pour le parcours complet de remédiation, y compris les contrôles précis de la politique de réplication.
5. Envoyez les cinq Event ID ci-dessus (5136, 4739, 4728, 4732, 4756) vers le SIEM qui ingère déjà votre base de politique d'audit Active Directory — il s'agit d'une extension de l'audit existant Account Management et Policy Change, pas d'une nouvelle catégorie de journalisation, et cela s'articule naturellement avec les processus existants de supervision des GPO et de revue des accès privilégiés.

Comment EtcSec détecte cela

Les détecteurs Advanced et Computers d'EtcSec signalent automatiquement ces quatre angles morts lors de chaque audit AD : DISPLAY_SPECIFIER_CHANGES détecte les modifications récentes des objets display specifier, DEFAULT_DOMAIN_POLICY_CHANGED signale les modifications de la politique de sécurité de base du domaine, EPHEMERAL_ADMINS_PAM fait apparaître l'activité des shadow principals PAM (y compris les appartenances à TTL courte qu'un instantané manuel manquerait), et RODC_PRIVILEGED_CACHING — classé Critique — détecte les identifiants Tier 0 répliqués vers un RODC.