SID filtering et name suffix routing

Concept

Lorsqu’une authentification traverse une frontière de confiance, deux mécanismes de filtrage et d’aiguillage s’activent sur les contrôleurs de domaine :

SID filtering (filtrage de SID) : le processus par lequel le KDC ou le LSA du domaine de destination inspecte le jeton d’authentification (PAC Kerberos ou validation Netlogon) et supprime impitoyablement tous les SIDs suspects, étrangers ou non autorisés avant de délivrer le ticket de service ou de créer la session.
Name suffix routing (routage des suffixes de noms) : le mécanisme DNS/Active Directory qui permet à un KDC d’identifier vers quel domaine distant orienter un client lorsqu’il présente un UPN (user@filiale.com) ou un SPN (cifs/server.filiale.com).

Pourquoi c’est important en DFIR

L’état du filtrage de SID dicte la gravité et le périmètre d’une intrusion :

Attaques par injection sIDHistory : un attaquant maîtrisant le hash krbtgt d’un domaine tiers peut injecter le SID S-1-5-21-...-500 (Administrateur) ou -519 (Enterprise Admins) dans le PAC d’un ticket forgé. Si le SID Filtering est actif, ces SIDs sont purgés à l’arrivée. S’il est inactif, l’attaquant devient administrateur immédiat de la cible.
Règles d’exclusion de suffixes (name suffix routing collisions) : un attaquant peut enregistrer des suffixes UPN/SPN frauduleux dans une forêt approuvée pour détourner les flux d’authentification ou intercepter des tickets Kerberos (Kerberoasting inter-forêt, Man-in-the-Middle).
Traces de filtrage dans les logs : la détection d’événements de rejet de SIDs non conformes indique sans ambiguïté une tentative d’exploitation malveillante ou une mauvaise configuration de migration historique.

Comment ça fonctionne

L’algorithme de filtrage de SID (SID filtering logic)

Lorsqu’un ticket arrive du Domaine A (Trusted) vers le Domaine B (Trusting) :

Le KDC de B extrait tous les SIDs présents dans le PAC (User SID, Group SIDs, sIDHistory).
Il applique trois catégories de règles de filtrage :
- Filtrage des SIDs well-known / haute autorité : tout SID universel (S-1-5-18 SYSTEM, S-1-5-32-544 Administrators, S-1-5-9 Enterprise Domain Controllers) provenant d’un domaine externe est systématiquement détruit.
- Filtrage de domaine (domain SID quarantine) : si la quarantaine est active (/filterSIDs:Yes), seuls les SIDs dont le préfixe correspond strictement au domaine distant approuvé sont conservés. Tout SID appartenant au domaine B local ou à un troisième domaine est supprimé.
- Filtrage intra-forêt (forest-trust SID filtering) : vérifie que les SIDs appartiennent bien aux domaines répertoriés dans la forêt partenaire via la partition de configuration.

PAC entrant depuis Domaine Distant :
[ UserSID: S-1-5-21-REMOTE-1001 ] ──► ACCEPTÉ (Correspond au domaine distant)
[ GroupSID: S-1-5-21-REMOTE-513 ]  ──► ACCEPTÉ (Domain Users distant)
[ sIDHistory: S-1-5-32-544 ]      ──► PURGÉ & BLOQUÉ (Built-in Administrator)
[ sIDHistory: S-1-5-21-LOCAL-512 ] ──► PURGÉ & BLOQUÉ (Domain Admins local)

Ce qui est possible

Désactiver la quarantaine pour des besoins de migration (forest trust) : la commande netdom trust /EnableSIDHistory:Yes autorise la transmission de sIDHistory, mais abaisse considérablement le niveau de sécurité si la forêt distante est moins sécurisée.
Vérifier l’état de quarantaine en ligne de commande : l’administrateur ou l’enquêteur peut auditer le statut exact du SID Filtering sur chaque liaison avec netdom trust <Domain> /quarantine.
Désactiver des suffixes de noms conflictuels : dans la console Domaines et approbations Active Directory, un suffixe UPN distant peut être explicitement désactivé (Disabled) pour interdire toute authentification venant de ce suffixe.

Ce qui n’est pas possible

Transmettre le SID SYSTEM (S-1-5-18) à travers une approbation : même avec le SID Filtering désactivé, le LSA Windows rejette toujours les SIDs de très haute autorité machine à travers une frontière inter-forêt.
Bypasser le SID filtering si la quarantaine est Active : il n’existe aucun bypass cryptographique connu permettant de préserver un SID injecté si la règle de quarantaine stricte est appliquée par le KDC de réception.
Activer le SID filtering intra-forêt sans risque d’impact fonctionnel : au sein d’une même forêt, activer le SID Filtering sur une liaison parent-enfant peut casser des migrations légitimes ou des droits d’administration d’Enterprise Admins.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Le SID Filtering est activé par défaut sur toutes les approbations. »	Faux. Il est activé par défaut sur les approbations Externes et de Forêt, mais désactivé par défaut au sein d’une même forêt (Parent-Enfant, Arbre).
« La commande netdom trust /quarantine:No permet d’injecter tous les SIDs. »	Même avec `quarantine:No`, les SIDs Well-Known (Administrateurs locaux, SYSTEM) restent systématiquement filtrés sur les approbations de forêt.
« Le Name Suffix Routing gère la résolution d’adresses IP. »	Non. Le Name Suffix Routing ne résout pas d’adresses IP : il aiguille les noms d’identités (UPN, SPN) vers les KDC des domaines compétents.

Exemple concret d’investigation

Dans une holding industrielle, une forêt partenaire récemment acquise (factory.local) est reliée à la forêt principale (corp.local) par une Forest Trust.

L’administrateur a exécuté lors de la migration : netdom trust corp.local /domain:factory.local /enablesidhistory:yes.
Un attaquant prend le contrôle d’un DC de factory.local.
L’attaquant forge un Golden Ticket avec Mimikatz en ajoutant dans sIDHistory le SID S-1-5-21-CORP-512 (Domain Admins de corp.local).
Parce que /enablesidhistory:yes a été activé, le KDC de corp.local ne filtre pas ce SID.
L’attaquant se connecte sur les DC de corp.local avec les privilèges d’administrateur complets du groupe principal.
Découverte DFIR : l’analyse de l’objet TDO montre le bit 0x00000040 ou la désactivation de la quarantaine, expliquant l’effondrement de la frontière inter-forêts.

Artefacts et traces forensiques

Attributs LDAP de l’objet TDO (trustedDomain) :
- Attribut msDS-TrustForestTrustInfo : structure binaire contenant la liste des suffixes de noms et les règles de routage (Enabled / Disabled / Excluded).
- Attribut trustAttributes : bit 0x4 (QUARANTINED_DOMAIN / SID Filtering actif).
Journaux de sécurité DC (événements de filtrage) :
- Event ID 4675 (SIDs were filtered) : très précieux en DFIR, consigne les SIDs retirés du jeton lors d’une authentification cross-domaine.
- Event ID 4716 : modification des informations de routage de suffixes de noms de confiance.

Méthodes d’investigation

Auditer le statut du SID filtering sur chaque approbation : Exécuter netdom trust <LocalDomain> /Domain:<RemoteDomain> /quarantine ou inspecter les bits de trustAttributes.
Vérifier l’autorisation de sIDHistory : Vérifier si EnableSIDHistory a été positionné à Yes sur une relation de confiance externe ou de forêt.
Inspecter les suffixes de noms routés : Exécuter Get-ADTrust -Identity <RemoteForest> | Select-Object -ExpandProperty ForestTrustInfo pour détecter tout conflit de suffixe UPN/SPN.

Outils d’investigation

Netdom :

netdom trust <Domain> /Domain:<RemoteDomain> /quarantine
netdom trust <Domain> /Domain:<RemoteDomain> /namesuffixes

PowerShell AD module :

Get-ADObject -Filter 'objectClass -eq "trustedDomain"' -Properties Name, trustAttributes, msDS-TrustForestTrustInfo |
  Select-Object Name, @{N="Quarantined";E={($_.trustAttributes -band 4) -ne 0}}

Points clés à retenir

Le SID filtering protège contre l’injection de SIDs frauduleux via sIDHistory.
Il est actif par défaut sur les Forest Trusts et External Trusts, mais inactif en intra-forêt.
L’activation de /enablesidhistory:yes sur une Forest Trust crée un risque critique d’escalade totale si la forêt distante est compromise.
L’Event ID 4675 enregistre les SIDs purgés par le mécanisme de filtrage.