Injection SIDHistory : élévation de privilèges vers Domain Admin

Qu'est-ce que l'injection SIDHistory ? L'élévation de privilèges par SID bien connu expliquée

L'injection SIDHistory avec un SID bien connu est une technique de persistance et d'élévation de privilèges Active Directory dans laquelle un attaquant écrit un SID privilégié bien connu — comme le suffixe RID 512 (Domain Admins) ou RID 519 (Enterprise Admins) du SID de domaine — dans l'attribut sIDHistory d'un compte non privilégié. MITRE ATT&CK répertorie cette sous-technique sous T1134.005 — Access Token Manipulation: SID-History Injection.

Comme chaque SID stocké dans sIDHistory est copié dans le PAC Kerberos (Privilege Attribute Certificate) du compte, puis dans son jeton d'accès lors de l'ouverture de session, le compte peu privilégié hérite effectivement des droits Domain Admin sans jamais être ajouté au groupe Domain Admins. Les audits d'appartenance aux groupes, les revues de groupes imbriqués et les vérifications net group /domain reviennent tous propres — l'élévation est invisible pour tout ce qui n'inspecte que l'appartenance aux groupes.

Comment ça marche : sIDHistory et les SID bien connus

sIDHistory est un attribut Active Directory légitime conçu pour les migrations inter-domaines et inter-forêts : lorsqu'un compte est déplacé vers un nouveau domaine, son ancien SID est conservé dans sIDHistory afin qu'il conserve l'accès aux ressources pour lesquelles il était déjà autorisé, sans qu'un administrateur ait à réécrire manuellement chaque ACL. La fonction DsAddSidHistory de Microsoft et le paramètre de confiance EnableSIDHistory existent précisément pour prendre en charge ce scénario de migration.

Le problème est que Windows ne fait aucune distinction entre un SID ajouté lors d'une migration légitime et un SID ajouté par un attaquant. À l'ouverture de session, le contrôleur de domaine construit le PAC de l'utilisateur à partir de tous les SID associés au compte — groupe primaire, toutes les appartenances aux groupes, et le contenu complet de sIDHistory — et ce PAC devient le jeton d'accès auquel fait confiance chaque service en aval. C'est une surface de persistance fondamentalement différente de l'imbrication dangereuse de groupes, où le privilège est au moins visible dans la liste des membres d'un groupe — ici, aucune appartenance à un groupe ne change jamais.

Les comptes de domaine normaux, et même la plupart des outils d'administration, ne peuvent pas simplement faire Set-ADUser -Replace @{sidHistory=...} via LDAP ; sIDHistory est un attribut construit/protégé. En pratique, les attaquants y accèdent via :

• Les modules sid::patch et sid::add de Mimikatz, exécutés directement sur un contrôleur de domaine avec privilege::debug — ce qui nécessite un accès équivalent Domain Admin/SYSTEM sur le DC lui-même, et sid::patch ne fonctionne plus sur Windows Server 2016 et versions ultérieures.
• Add-ADDBSidHistory de DSInternals modifiait la base ntds.dit hors ligne et nécessitait l'arrêt du service NTDS — utilisé directement contre la base de données d'un DC plutôt que via l'API de réplication normale. À la date de rédaction, cette cmdlet a été retirée du module PowerShell DSInternals actuel (sa documentation est conservée à titre de référence uniquement) ; l'équivalent maintenu est Add-ADReplSidHistory, qui effectue l'injection en ligne via le protocole de réplication MS-DRSR et nécessite toujours des droits de réplication équivalents à ceux d'un DC.
• L'API légitime DsAddSidHistory, destinée à la migration inter-forêts, que certains outils détournent de manière non prévue lorsque l'attaquant contrôle déjà des privilèges équivalents à ceux d'un DC.

Dans tous les cas, l'attaquant a déjà besoin d'un accès de niveau réplication ou contrôleur de domaine pour écrire dans sIDHistory — il s'agit d'une technique de persistance et de furtivité post-compromission, pas d'un vecteur d'accès initial. Ce qui justifie une détection dédiée, c'est ce qui se passe après : le privilège injecté n'est pas visible dans l'appartenance aux groupes, survit aux réinitialisations de mot de passe, et n'est pas affecté par le retrait du compte de quelque groupe que ce soit (puisqu'il n'en a jamais été membre).

La chaîne d'attaque

Étape 1 — Obtenir un accès de niveau DC ou équivalent réplication

L'attaquant a d'abord besoin de privilèges équivalents à Domain Admin, ou d'un accès direct à un contrôleur de domaine — par exemple via une compromission DCSync préalable, un accès console/RDP direct au DC, ou une copie exfiltrée de ntds.dit. Cette étape est le même prérequis qu'une attaque DCSync ou qu'un Golden Ticket forgé.

Étape 2 — Identifier le compte cible et le SID bien connu

L'attaquant choisit un compte peu privilégié et peu visible (un compte de service, un ancien compte de prestataire, ou un compte nouvellement créé) et le SID de domaine avec le RID bien connu qu'il souhaite injecter :

Étape 3 — Injecter le SID dans sIDHistory

Sur un DC compromis, avec Mimikatz :

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Historiquement, hors ligne contre une copie de ntds.dit, avec DSInternals :

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Étape 4 — S'authentifier en tant que compte peu privilégié

À la prochaine ouverture de session, le DC construit un PAC pour lowpriv-svc qui inclut le SID Domain Admins injecté. Tout service qui fait confiance aux données d'autorisation Kerberos accorde désormais au compte un accès équivalent Domain Admin — alors que son appartenance réelle aux groupes ne montre toujours rien d'anormal.

🚨 Danger : comme le SID injecté réside sur l'objet compte lui-même plutôt que dans un ticket forgé, il persiste à chaque ouverture de session future jusqu'à ce que quelqu'un inspecte spécifiquement et efface sIDHistory — contrairement à un Golden Ticket, qui expire ou est invalidé par une rotation de KRBTGT.

Détection

Les modifications de sIDHistory sont rares dans un environnement sain en dehors d'une fenêtre de migration active, ce qui en fait une surface de détection à fort signal — mais seulement si la bonne stratégie d'audit est activée et que les bons RID sont vérifiés.

Les ID d'événement 4765/4766 nécessitent que la sous-catégorie d'audit avancé « Auditer la gestion des comptes d'utilisateurs » soit activée — elle n'est pas activée par défaut dans de nombreux environnements, il faut donc vérifier la stratégie d'audit avant de présumer une couverture.

Énumérez les comptes existants à la recherche d'un sIDHistory renseigné et filtrez spécifiquement sur les RID privilégiés bien connus, pas seulement sur une valeur historique quelconque :

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

Microsoft Defender for Identity propose une évaluation de la posture de sécurité pour les comptes portant une valeur sIDHistory et inclut une logique de détection comportementale calibrée pour signaler les modifications inattendues de l'attribut SID-History en dehors d'une activité de migration — un contrôle compensatoire utile là où la stratégie d'audit avancé présente des lacunes.

Remédiation

1. Activer la stratégie d'audit avancé pour la gestion des comptes. Activez « Auditer la gestion des comptes d'utilisateurs » afin que les ID d'événement 4765/4766 se déclenchent réellement, et transférez-les vers votre SIEM avec des alertes sur toute occurrence en dehors d'une fenêtre de changement de migration connue.
2. Restreindre et surveiller l'accès de niveau DC et équivalent réplication. Puisque l'injection de sIDHistory nécessite un accès Domain Admin/SYSTEM sur un DC ou une copie de ntds.dit, le contrôle le plus efficace est le même que celui qui bloque DCSync et les Golden Ticket : minimiser et auditer les comptes détenant DS-Replication-Get-Changes-All et restreindre l'ouverture de session interactive/RDP sur les contrôleurs de domaine.
3. Auditer sIDHistory sur l'ensemble du domaine selon un calendrier récurrent, pas seulement après une migration connue. Toute valeur renseignée contenant un RID privilégié bien connu qui n'est pas lié à un projet de migration documenté et limité dans le temps doit être traitée comme un incident critique.
4. Nettoyer sIDHistory après la fin des migrations. Une fois les ACL corrigées vers les nouveaux SID, effacez les valeurs sIDHistory héritées — une surface d'attaque réduite sans valeurs résiduelles est plus facile à surveiller qu'une surface où « un peu de SID history est attendu ».
5. Déployer un outil de détection et de réponse aux menaces d'identité (ITDR), comme Microsoft Defender for Identity, pour ajouter une couverture comportementale des modifications de sIDHistory qui complète les règles statiques basées sur les journaux d'audit.

# Supprimer toutes les valeurs sIDHistory d'un compte une fois la migration/remédiation terminée
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec distingue spécifiquement les problèmes d'hygiène SID-History des indicateurs actifs d'élévation de privilèges :

• SIDHISTORY_WELLKNOWN_SIDS (Critique) — signale tout compte dont l'attribut sIDHistory contient un RID privilégié bien connu (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) correspondant au propre SID du domaine — le schéma spécifique décrit dans cet article, pas une simple présence générique de SID History.
• SID_HISTORY (Élevé) — signale tout compte avec un sIDHistory renseigné, afin que le travail de nettoyage post-migration légitime puisse être suivi et complété.
• SIDHISTORY_RECENT_CHANGES (Info) — met en évidence les objets dont le sIDHistory a récemment changé, pour corréler avec les fenêtres de migration documentées.
• DCSYNC_CAPABLE — signale le privilège de point d'entrée (comptes non-DC détenant des droits de réplication) qui est le prérequis habituel pour atteindre un DC et effectuer l'injection en premier lieu.

Priorités de revue

L'injection SIDHistory avec des SID bien connus doit être traitée comme un constat de niveau domination du domaine, pas comme une simple lacune d'hygiène de routine. Commencez par énumérer chaque compte avec un sIDHistory non vide, puis séparez les artefacts de migration documentés des valeurs inexpliquées — en particulier toute correspondance avec un RID privilégié bien connu sur le propre SID du domaine actuel. Confirmez quels contrôleurs de domaine étaient accessibles par quels administrateurs et comptes de service pendant la fenêtre suspectée, car la technique nécessite un accès de niveau DC ou équivalent réplication pour s'exécuter. Comme le privilège injecté contourne entièrement la revue d'appartenance aux groupes, tout plan de remédiation qui n'audite que l'appartenance aux groupes le manquera — l'attribut lui-même doit être la source de vérité.

Contrôles adjacents à examiner

L'injection SIDHistory est rarement isolée : l'accès de niveau DC qu'elle nécessite est le même accès qui permet l'extraction d'identifiants via DCSync, la falsification de Golden Ticket et le vol direct de ntds.dit. Lors de l'investigation d'une injection suspectée, vérifiez qui détenait des droits de réplication et un accès en ouverture de session aux DC pendant la fenêtre d'exposition, si KRBTGT a été récemment tourné, et si d'autres comptes privilégiés montrent des signes de falsification. Un correctif qui efface le sIDHistory d'un seul compte sans fermer la voie d'accès DC sous-jacente laisse l'attaquant libre de l'injecter à nouveau — ou dans un compte différent.

Lectures complémentaires

À lire avec Golden Ticket : les clés de votre royaume, Abus ACL et DCSync : les chemins silencieux vers Domain Admin, Attaques de confiance Active Directory : du domaine enfant à la racine de la forêt, Comptes privilégiés Active Directory : Protected Users, délégation et lacunes des comptes de service, Imbrication dangereuse de groupes dans Active Directory, et Surveillance Active Directory : les ID d'événements de sécurité qui comptent.

• Golden Ticket : les clés de votre royaume
• Abus ACL et DCSync : les chemins silencieux vers Domain Admin
• Attaques de confiance Active Directory : du domaine enfant à la racine de la forêt
• Comptes privilégiés Active Directory : Protected Users, délégation et lacunes des comptes de service
• Imbrication dangereuse de groupes dans Active Directory
• Surveillance Active Directory : les ID d'événements de sécurité qui comptent

Liste de contrôle de validation

Avant de clore la revue, relancez l'énumération sIDHistory par RID bien connu en production et confirmez qu'aucun résultat inexpliqué ne subsiste. Vérifiez que la stratégie d'audit avancé est activée sur chaque contrôleur de domaine afin que les ID d'événement 4765/4766 soient réellement générés, pas seulement théoriquement disponibles. Confirmez que les droits de réplication et l'accès en ouverture de session aux DC ont été restreints aux comptes qui en ont réellement besoin, et consignez les preuves — la sortie d'énumération et l'état de la stratégie d'audit — comme référence pour le prochain audit récurrent.