Persistence et backdoors AD

Une fois Domain Admin obtenu, la vraie question commence

Dans un engagement offensif structuré, obtenir des droits d'administrateur du domaine n'est pas la fin du test — c'est le moment où il faut démontrer ce qu'un attaquant réel ferait pour survivre à ce niveau d'accès plus longtemps que la mission elle-même. Un pentester ne s'arrête pas à la capture d'un accès « Domain Admin » : il documente comment cet accès pourrait être conservé, discrètement, même après une réinitialisation de mot de passe standard côté client. C'est l'objet de ce chapitre : les mécanismes de persistence et de backdoor propres à Active Directory, depuis la forge de tickets Kerberos jusqu'à l'abus de fonctionnalités de récupération légitimes des contrôleurs de domaine.

Toute technique de persistence testée dans ce chapitre doit être neutralisée avant la fin de l'engagement — suppression du ticket forgé (il expire de toute façon), retrait de tout SPN ajouté, restauration de la configuration DSRM d'origine. Le rapport documente la faisabilité et la méthode de détection, jamais une porte dérobée active laissée pour le client. Un backdoor oublié en fin de mission transforme un exercice professionnel en incident de sécurité que vous avez vous-même créé.

Quatre techniques structurent ce chapitre : le Golden Ticket et le Silver Ticket, qui exploitent la confiance accordée aux tickets Kerberos correctement chiffrés ; l'abus du compte DSRM, une porte dérobée légitime souvent oubliée sur les contrôleurs de domaine ; et l'ajout d'un SPN malveillant, une technique de persistence légère qui transforme un compte à privilèges en cible de Kerberoasting permanente.

Golden Ticket : forger un TGT à partir du hash krbtgt

Le mécanisme

Le compte krbtgt signe et chiffre tous les tickets Kerberos délivrés par le KDC (Key Distribution Center) d'un domaine. Son hash — NTLM ou clé AES selon la configuration — sert de secret racine pour l'intégralité de la confiance Kerberos du domaine. Si un attaquant obtient ce hash, typiquement via un dump NTDS.dit ou une extraction DCSync, il peut forger lui-même un TGT (Ticket Granting Ticket) complet, sans jamais interroger le contrôleur de domaine pour son émission initiale.

Le ticket forgé — le « Golden Ticket » — peut contenir n'importe quel SID, n'importe quelle appartenance de groupe (y compris Domain Admins ou Enterprise Admins), et une durée de vie arbitraire, puisque c'est l'attaquant qui construit la structure du ticket avant de la signer avec le hash krbtgt volé. Le KDC vérifie seulement que la signature est valide avec sa propre clé, jamais qu'il a réellement émis ce ticket. Un Golden Ticket correctement forgé passe donc cette vérification sans distinction avec un TGT légitime.

# Extraction du hash krbtgt via DCSync (nécessite déjà des droits de réplication)
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Forge du Golden Ticket
mimikatz # kerberos::golden /user:administrateur /domain:corp.local /sid:S-1-5-21-XXXX /krbtgt:<hash_ntlm> /id:500 /ptt

Limites et détection

Le hash krbtgt reste valide tant qu'il n'est pas explicitement changé, et un seul changement ne suffit pas : Active Directory conserve l'ancien et le nouveau hash pendant une période de grâce liée à la durée de vie maximale des tickets, ce qui permet à un Golden Ticket forgé avec l'ancien hash de rester utilisable. La remédiation correcte impose deux réinitialisations successives du mot de passe krbtgt, espacées d'un délai suffisant pour purger les tickets en circulation — un point détaillé plus loin dans ce chapitre.

Côté détection, un Golden Ticket ne génère aucune requête TGT (Event ID 4768) sur le contrôleur de domaine, puisqu'il est forgé hors ligne. Les indices reposent plutôt sur des anomalies dans les requêtes de service qui suivent : un Event ID 4769 pour un compte dont le SID ne correspond à aucun 4768 précédent, une durée de vie de ticket incohérente avec la politique Kerberos du domaine (10 heures par défaut), ou un type de chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire RC4 alors que le domaine impose AES. Microsoft Defender for Identity et des règles Sigma dédiées surveillent spécifiquement ces incohérences.

Silver Ticket : cibler un service sans jamais solliciter le KDC

Le mécanisme

Le Silver Ticket applique le même principe que le Golden Ticket, à un niveau plus restreint : au lieu du hash krbtgt, l'attaquant utilise le hash du compte de service associé à une ressource cible — par exemple le compte machine d'un serveur de fichiers, ou un compte de service SQL. Il forge directement un TGS (Ticket Granting Service) valide pour ce service précis, sans jamais passer par le KDC.

# Forge d'un Silver Ticket ciblant un service CIFS sur SRV-FILES01
mimikatz # kerberos::golden /user:administrateur /domain:corp.local /sid:S-1-5-21-XXXX /target:srv-files01.corp.local /service:cifs /rc4:<hash_du_compte_machine> /ptt

Portée et détection

Le Silver Ticket est plus discret que le Golden Ticket sur un point précis : aucune trace n'apparaît sur le contrôleur de domaine, ni Event ID 4768 ni 4769, puisque le KDC n'intervient jamais dans son émission. Toute la validation du ticket se fait localement, sur le serveur cible, par le service Kerberos local qui vérifie la signature avec son propre hash de compte machine ou de service.

Un Silver Ticket bien construit produira un Event ID 4624 (connexion réussie) sur la machine cible sans qu'aucun 4768/4769 correspondant n'existe côté contrôleur de domaine dans la fenêtre temporelle attendue. C'est précisément cette absence de corrélation — une connexion Kerberos sans requête TGS préalable journalisée par le KDC — qui trahit un Silver Ticket lors d'une investigation, à condition que les deux sources de journaux (serveur cible et DC) soient effectivement corrélées.

Sa contrepartie est une portée plus limitée : un Silver Ticket ne donne accès qu'au service pour lequel il a été forgé (CIFS, HTTP, MSSQLSvc, etc.). Il ne permet pas de rebondir librement dans le domaine comme un Golden Ticket, mais reste redoutable en persistence discrète sur une ressource critique unique — un partage de fichiers sensible, une base SQL.

DSRM : la porte dérobée oubliée des contrôleurs de domaine

Qu'est-ce que le compte DSRM

Chaque contrôleur de domaine dispose d'un compte administrateur local distinct du domaine, utilisé pour le Directory Services Restore Mode (DSRM) — un mode de démarrage spécial permettant de restaurer ou réparer la base Active Directory (NTDS.dit) hors ligne. Ce compte, souvent appelé « Administrateur DSRM », possède un mot de passe défini à la promotion du contrôleur en DC et rarement changé par la suite — un point d'accès local avec des droits équivalents à SYSTEM sur cette machine.

DsrmAdminLogonBehavior : transformer un compte de secours en backdoor réseau

Par défaut, ce compte DSRM ne peut s'authentifier que localement, en mode restauration. Une clé de registre, DsrmAdminLogonBehavior, sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa, contrôle ce comportement : mise à 2, elle autorise l'authentification du compte DSRM même lorsque le contrôleur de domaine fonctionne normalement, via le réseau, en Pass-the-Hash ou avec le mot de passe s'il est connu.

# Activer l'authentification réseau du compte DSRM (persistence)
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DsrmAdminLogonBehavior /t REG_DWORD /d 2

# Synchroniser le mot de passe DSRM avec un mot de passe choisi par l'attaquant
ntdsutil "set dsrm password" "reset password on server null" q q

Un attaquant ayant obtenu un accès Domain Admin modifie la clé DsrmAdminLogonBehavior sur un contrôleur de domaine secondaire peu surveillé, puis synchronise le mot de passe DSRM avec une valeur qu'il maîtrise via ntdsutil. Ce compte n'appartient à aucun groupe de sécurité du domaine, n'apparaît dans aucune requête LDAP portant sur les membres de Domain Admins, et continue de fonctionner même après une rotation complète des mots de passe utilisateurs et du compte krbtgt. Seule une revue explicite de la configuration DSRM sur chaque contrôleur révèle l'anomalie.

Détection

Cette persistence échappe à la plupart des audits centrés sur les groupes AD, précisément parce que le compte DSRM n'est pas un objet du domaine — il est local à chaque contrôleur. La détection repose sur la surveillance de la clé de registre elle-même (à zéro par défaut sur des DC sains) et sur le monitoring des Event ID 4624 dont le SID correspond à l'administrateur DSRM local, distinct du SID -500 du domaine.

SPN malveillant : un Kerberoasting activable à la demande

Le mécanisme

Le Kerberoasting classique cible des comptes qui possèdent déjà un SPN (Service Principal Name) légitime, généralement des comptes de service. La persistence par SPN malveillant inverse la logique : un attaquant ayant des droits suffisants ajoute lui-même un SPN arbitraire à un compte à privilèges élevés qui n'en possédait pas — par exemple un compte Domain Admins normalement protégé par sa seule absence de SPN.

# Ajout d'un SPN arbitraire sur un compte Domain Admin
setspn -A HTTP/service-fictif.corp.local corp\admin_domaine

# Le compte devient kerberoastable : demande d'un TGS pour ce SPN
Rubeus.exe kerberoast /user:admin_domaine /outfile:hashes.txt

Une fois le SPN en place, n'importe quel utilisateur authentifié du domaine, même à faible privilège, peut demander un TGS pour ce service fictif et obtenir une portion du ticket chiffrée avec le hash du compte Domain Admin ciblé, exploitable hors ligne par cassage de mot de passe. C'est une persistence particulièrement insidieuse : elle ne modifie ni groupe ni ACL visible, seulement un attribut servicePrincipalName sur un compte existant.

Détection

L'Event ID 4738 (modification d'un compte utilisateur) journalise les changements d'attributs, SPN inclus, si l'audit approprié est activé ; l'Event ID 5136 (modification d'un objet AD, si l'audit avancé DS Access est actif) est plus précis encore. Une règle simple et à fort rendement consiste à alerter sur tout ajout de SPN à un compte membre d'un groupe protégé (Domain Admins, Enterprise Admins, Administrators), un cas qui ne devrait jamais se produire légitimement.

Comparatif des quatre techniques

Détection et hygiène : ce qu'un audit doit vérifier

Aucune de ces quatre techniques ne repose sur une vulnérabilité corrigeable par un correctif Windows : elles exploitent des mécanismes de confiance et des fonctionnalités légitimes. La défense se construit donc en couches.

• Rotation du krbtgt en double reset — changer le mot de passe krbtgt deux fois, espacé d'au moins la durée de vie maximale des tickets, pour purger le hash courant et le hash précédent
• Surveillance de DsrmAdminLogonBehavior sur chaque DC, avec alerte sur toute valeur différente de 0, son comportement par défaut
• Comptes canaris (honeypot accounts) — des comptes à privilèges apparents mais factices, surveillés en continu : toute authentification ou tentative de Kerberoasting dessus est un signal fort, sans faux positif
• Audit régulier des SPN sur les groupes protégés — aucun compte Domain Admins ou équivalent ne devrait porter de SPN en fonctionnement normal
• Surveillance d'AdminSDHolder — ce conteneur repropage ses ACL vers les comptes protégés toutes les 60 minutes ; ses modifications, rares en usage légitime, sont un point de persistence classique complémentaire
• Corrélation multi-source — détecter un Silver Ticket ou un backdoor DSRM suppose de croiser les journaux du DC et des serveurs membres, ce qu'un SIEM permet mais pas une simple consultation locale

Depuis novembre 2022, Windows applique une vérification renforcée de la signature PAC (Privilege Attribute Certificate) sur les contrôleurs de domaine, ce qui complique certains scénarios de forge de ticket mal construits. Cela ne rend pas le Golden Ticket obsolète — la technique reste pleinement fonctionnelle avec un hash krbtgt valide et une construction correcte — mais un audit doit vérifier que ce correctif est bien déployé, car son absence facilite des variantes plus anciennes comme MS14-068.

Checklist de fin d'engagement

1. Vérifier qu'aucun ticket forgé n'est plus injecté dans une session active (klist purge)
2. Retirer tout SPN ajouté à des fins de démonstration
3. Restaurer la configuration DSRM d'origine (DsrmAdminLogonBehavior à sa valeur initiale, mot de passe DSRM re-synchronisé si modifié)
4. Documenter précisément, pour chaque technique testée, l'heure, le compte ciblé et la méthode de détection recommandée
5. Recommander explicitement le double reset krbtgt si un hash krbtgt a été extrait pendant l'engagement, avec le délai à respecter entre les deux réinitialisations
6. Vérifier la présence des correctifs de validation PAC sur l'ensemble des contrôleurs de domaine

Ce qu'il faut retenir

La persistence en environnement Active Directory ne se limite pas à laisser un compte supplémentaire dans un groupe à privilèges — c'est la technique la plus grossière et la plus facilement détectée. Les quatre mécanismes de ce chapitre partagent un point commun : ils exploitent la confiance accordée à un secret cryptographique (hash krbtgt, hash de service) ou à une fonctionnalité de récupération légitime (DSRM), plutôt qu'une faille corrigeable. C'est ce qui les rend redoutables en engagement réel et ce qui justifie qu'un rapport les documente avec la même rigueur que l'obtention initiale des droits Domain Admin. Le chapitre suivant s'appuie sur ce parcours technique pour aborder la structuration du rapport et la priorisation des remédiations face à un client.