SIDHistory : l'héritage des migrations qui peut cacher des privilèges
Des années après une fusion de domaines ou une migration inter-forêts, de nombreux comptes portent encore d'anciens SID dans leur attribut SIDHistory. Personne ne sait plus s'ils servent. Et au milieu de ces valeurs héritées, un SID privilégié ajouté par un attaquant passerait facilement inaperçu.
À quoi sert SIDHistory
Lorsqu'un compte est migré d'un domaine à un autre, il reçoit un nouvel identifiant de sécurité (SID). Or les autorisations sur les partages, fichiers et applications de l'ancien domaine référencent l'ancien SID. Pour que l'utilisateur conserve ses accès pendant la transition, les outils de migration copient l'ancien SID dans l'attribut sIDHistory du nouveau compte. À l'ouverture de session, les SID de l'historique sont ajoutés au jeton de l'utilisateur, exactement comme s'il était encore membre de l'ancien domaine.
C'est un mécanisme de transition. Une fois les autorisations traduites vers les nouveaux SID, il n'a plus de raison d'exister.
Pourquoi c'est un vecteur de persistance
Puisque chaque SID de l'historique est ajouté au jeton, placer dans sIDHistory le SID d'un groupe privilégié (Admins du domaine, Administrateurs de l'entreprise) donne ses droits à un compte en apparence ordinaire, sans qu'il apparaisse dans la liste des membres du groupe. Cet attribut n'est pas modifiable par une simple écriture LDAP : il faut soit passer par les interfaces de migration, soit disposer d'un accès de niveau contrôleur de domaine. C'est donc une technique de persistance après compromission, destinée à survivre au nettoyage des groupes privilégiés. Les outils qui ne regardent que l'appartenance aux groupes ne la voient pas.
Auditer les comptes porteurs d'un historique
- Lister tous les utilisateurs, groupes et ordinateurs dont l'attribut
sIDHistoryest renseigné. - Pour chaque valeur, identifier le domaine d'origine à partir de la partie domaine du SID. Un SID appartenant au domaine courant est anormal : une migration introduit des SID d'un autre domaine.
- Rechercher les SID connus à privilèges, notamment ceux dont l'identifiant relatif correspond à un groupe d'administration (512, 518, 519, ou 544 pour Administrateurs).
- Vérifier si les domaines d'origine existent encore et si des approbations y mènent.
Les contrôleurs de domaine journalisent l'ajout d'un SID à l'historique (événement 4765) et les tentatives échouées (événement 4766) lorsque l'audit de gestion des comptes est activé. En dehors d'une migration planifiée, ces événements doivent déclencher une investigation.
Nettoyer après une migration
Le nettoyage suit une logique simple : traduire d'abord, supprimer ensuite. Les outils de migration et de traduction de sécurité permettent de remplacer les anciens SID par les nouveaux dans les ACL des serveurs de fichiers, des profils et des applications. Une fois cette traduction faite et vérifiée, les valeurs de sIDHistory peuvent être retirées par script, par lots, en conservant une exportation pour pouvoir restaurer un accès oublié. Procédez par population, surveillez les demandes d'accès refusés pendant quelques semaines, puis généralisez.
Le rôle du filtrage des SID. Sur une approbation, le filtrage des SID écarte des jetons les SID qui n'appartiennent pas au domaine ou à la forêt approuvés. Il est actif par défaut sur les approbations externes et les approbations de forêt. Le désactiver, ou autoriser explicitement l'historique des SID sur une approbation de forêt pour faciliter une migration, permet à un administrateur de la forêt approuvée d'injecter des SID privilégiés de votre forêt. Toute exception doit être temporaire et documentée.
Ce qu'un audit vérifie
- le nombre de comptes porteurs d'un
sIDHistoryet les domaines d'origine ; - la présence de SID privilégiés ou de SID du domaine courant dans l'historique ;
- l'état du filtrage des SID et de l'option d'historique des SID sur chaque approbation ;
- la journalisation des événements 4765 et 4766 et leur surveillance.