Détection et défense

Changer de côté du miroir

Les chapitres précédents ont suivi la logique d'un attaquant : énumérer, casser des secrets, se déplacer latéralement, escalader jusqu'au contrôle du domaine. Un pentest de qualité ne s'arrête pourtant pas à la démonstration de faisabilité. La valeur d'un rapport se mesure aussi à sa capacité à dire au client, avec précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire, ce qu'il aurait pu observer et ce qu'il peut mettre en place pour réduire la portée de la prochaine compromission. Ce chapitre traite de la défense d'un domaine Active Directory sous l'angle de quatre leviers concrets : la télémétrie, les honeytokens, le tiering d'administration et un socle de durcissement autour de LAPS et Protected Users.

Comprendre la défense n'est pas un exercice théorique réservé au Blue Team. Un pentester qui sait exactement quels événements il génère peut adapter son opsec en engagement Red Team, éviter de griller une technique inutilement, et surtout rédiger des recommandations qui correspondent à la réalité opérationnelle du client plutôt qu'à une liste générique copiée d'un référentiel.

La télémétrie : voir avant de réagir

Aucune détection n'est possible sans donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire à corréler. En environnement Active Directory, quatre sources de télémétrie couvrent l'essentiel des scénarios abordés dans les chapitres précédents.

Les journaux d'événements Windows restent la base, à condition d'activer les bonnes catégories d'audit — la configuration par défaut d'un contrôleur de domaine ne journalise pas tout ce qui est utile. Les catégories à activer explicitement via GPO incluent l'audit des connexions (succès et échec), l'audit des changements de groupe de sécurité, l'audit de l'accès aux objets sensibles (SACL sur NTDS.dit, sur les objets AdminSDHolder) et l'audit Kerberos détaillé. Sans cette configuration, une bonne partie des Event ID mentionnés dans les chapitres sur le mouvement latéral et le Kerberoasting n'apparaît simplement jamais dans les journaux.

Sysmon comble les angles morts des journaux natifs : création de process avec ligne de commande complète (Event ID 1), connexions réseau (ID 3), accès à un processus comme LSASS (ID 10, essentiel pour repérer un dump de credentials), et création de pipes nommés utilisés par certains frameworks C2 (ID 17-18). Une configuration Sysmon mal calibrée génère un volume ingérable de bruit ; les configurations communautaires de référence (type SwiftOnSecurity ou olafhartong) filtrent déjà l'essentiel du bruit légitime.

Les journaux LDAP et Netlogon sur les contrôleurs de domaine tracent les requêtes d'énumération massive (recherches LDAP avec des filtres larges, typiques d'un passage BloodHound) et les authentifications NTLM, respectivement. Le journal Netlogon en mode debug est verbeux mais très utile pour confirmer un usage résiduel de NTLM sur un domaine censé être Kerberos-first.

L'EDR, quand il est déployé, complète ces sources avec une visibilité comportementale (chaînes de process, injection mémoire, accès API sensibles) que les journaux natifs ne couvrent pas.

Collecter des journaux sans règle de corrélation revient à filmer sans jamais regarder l'enregistrement. La valeur n'apparaît qu'au moment où un SIEM ou un analyste relie plusieurs événements a priori anodins — une requête LDAP large suivie, quelques minutes plus tard, d'une authentification Kerberos vers un compte de service jamais utilisé en interactif.

Honeytokens : détecter sans faux positifs

Là où la télémétrie brute produit un volume de signaux à trier, le honeytoken inverse la logique : il s'agit d'un objet qui n'a aucune raison légitime d'être utilisé, de sorte que toute interaction avec lui constitue en elle-même une alerte fiable, sans nécessiter de seuil ni de corrélation complexe.

En Active Directory, plusieurs formes de honeytokens sont couramment déployées :

• Comptes utilisateurs leurres — un compte au nom plausible (svc-backup-legacy, j.dupont-admin) jamais utilisé pour une authentification réelle. Toute tentative d'authentification, réussie ou échouée, déclenche une alerte immédiate.
• Comptes avec SPN piégé — un compte de service factice disposant d'un Service Principal Name, volontairement exposé à l'énumération Kerberoasting. Toute demande de TGS pour ce SPN précis (Event ID 4769) est un signal fort, car aucun processus légitime n'a de raison de le demander.
• ACL leurres sur des objets sensibles — des permissions déléguées artificiellement sur un objet qui semble intéressant (par exemple un droit GenericAll apparent sur un compte à privilèges), détectées par un outil comme BloodHound côté attaquant, mais surveillées côté défense via l'audit d'accès sur cet objet précis.
• Attributs de mot de passe visibles — un attribut LDAP en clair (souvent dans la description ou un champ personnalisé) contenant une valeur qui ressemble à un identifiant, utilisé pour piéger l'énumération automatisée en phase de reconnaissance.

Un client crée un compte svc-sql-legacy avec un SPN valide et un mot de passe volontairement complexe, jamais utilisé par aucune application. Il configure une alerte SIEM sur tout Event ID 4769 référençant ce SPN. Six mois plus tard, un incident réel se déclenche : un attaquant ayant obtenu un accès initial lance une énumération Kerberoasting classique avec Rubeus, demande un TGS pour ce SPN parmi une dizaine d'autres, et déclenche l'alerte en quelques secondes — bien avant d'avoir pu casser le moindre hash. C'est l'exemple type d'une détection à coût de faux positif nul, qui ne dépend d'aucun modèle comportemental.

Le principal piège des honeytokens est leur découverte par l'attaquant : un compte trop visiblement isolé, sans historique d'appartenance à des groupes plausibles ni ancienneté cohérente (attribut whenCreated), éveille les soupçons d'un opérateur expérimenté. Un honeytoken crédible s'intègre dans l'AD avec la même patine que les comptes réels : groupes cohérents, description plausible, ancienneté simulée si l'outillage le permet.

Le tiering : cloisonner plutôt que détecter

La télémétrie et les honeytokens relèvent de la détection. Le tiering d'administration relève d'une logique différente et complémentaire : réduire structurellement la portée d'une compromission, indépendamment de sa détection. Le modèle, popularisé par Microsoft sous le nom d'Enterprise Access Model (successeur du modèle en trois tiers historique), repose sur un principe simple : un compte à privilèges élevés ne doit jamais s'authentifier sur une machine de niveau de confiance inférieur.

• Tier 0 — les contrôleurs de domaine, les serveurs PKI, et tout système dont la compromission équivaut à celle du domaine entier. Les comptes Tier 0 (Domain Admins, Enterprise Admins) ne s'authentifient que sur des postes d'administration dédiés (PAW — Privileged Access Workstation), jamais sur un poste utilisateur standard.
• Tier 1 — les serveurs applicatifs et d'infrastructure. Un compte administrateur Tier 1 gère ces serveurs mais n'a aucun droit sur les contrôleurs de domaine.
• Tier 2 — les postes utilisateurs. Les comptes d'administration de ce niveau (support informatique, help desk) sont cantonnés aux postes utilisateurs et n'ont aucune portée au-delà.

La raison d'être du tiering découle directement du chapitre sur le mouvement latéral : si un compte Domain Admin s'authentifie ne serait-ce qu'une fois sur un poste utilisateur compromis (support à distance, dépannage ponctuel), son secret devient extractible via un dump LSASS et compromet immédiatement le domaine entier. Le tiering ne rend pas cette extraction impossible techniquement — il rend la situation elle-même impossible en interdisant l'authentification croisée.

En audit, il est fréquent de trouver un tiering documenté dans une politique de sécurité mais non appliqué techniquement : rien n'empêche concrètement un administrateur Domain Admin de se connecter en RDP sur un poste utilisateur en cas d'urgence. Sans restriction technique (GPO de refus de connexion interactive, Deny log on locally / Deny log on through Remote Desktop Services pour les comptes Tier 0 sur les postes Tier 1/2), le modèle reste une intention sur le papier. Un pentest qui démontre une compromission de domaine via un poste utilisateur, alors que le client affirme appliquer un tiering strict, constitue une preuve particulièrement parlante dans un rapport.

LAPS et Protected Users : réduire la portée d'un secret volé

Deux contre-mesures ciblées reviennent systématiquement dans les recommandations d'un pentest AD, car elles s'attaquent directement aux techniques les plus rentables pour un attaquant.

LAPS (Local Administrator Password Solution), désormais intégré nativement à Windows depuis Windows Server 2019/Windows 11 sous le nom LAPS Windows (successeur du LAPS legacy Microsoft), attribue à chaque machine du domaine un mot de passe administrateur local unique, stocké chiffré dans un attribut de l'objet ordinateur en Active Directory, et renouvelé automatiquement selon une politique définie (typiquement tous les 30 jours). L'effet direct : un hash NT extrait sur une machine ne fonctionne sur aucune autre. Le scénario de Pass-the-Hash "à grande échelle", où un même compte administrateur local partagé ouvre l'accès à tout un parc déployé depuis la même image, disparaît intégralement.

# Lecture d'un mot de passe LAPS (nécessite délégation explicite)
Get-LapsADPassword -Identity SRV-APP01 -AsPlainText

# Recherche des comptes disposant du droit de lecture LAPS (côté audit)
Get-ADObject -SearchBase "DC=corp,DC=local" -LDAPFilter "(msLAPS-Password=*)" -Properties msLAPS-Password

LAPS ne protège que les comptes locaux qu'il gère : un compte de service Active Directory partagé entre plusieurs serveurs, ou un compte administrateur de domaine mal utilisé, reste hors de son périmètre.

Le groupe Protected Users, présent depuis Windows Server 2012 R2, applique une série de restrictions strictes aux comptes qui en sont membres :

• Interdiction totale de l'authentification NTLM pour ce compte, y compris en tant que source
• Interdiction de la délégation Kerberos, contrainte ou non, pour ce compte
• Pas de mise en cache des identifiants en clair ni du hash NT sur les machines où le compte s'authentifie
• Durée de vie du TGT ramenée à 4 heures maximum, sans renouvellement au-delà
• 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 Kerberos limité à AES, excluant RC4 — ce qui neutralise directement le Kerberoasting classique basé sur le cassage d'un ticket chiffré en RC4

L'ajout d'un compte à Protected Users peut casser des scénarios d'authentification legacy qui dépendent de NTLM ou d'une délégation Kerberos non contrainte — applications anciennes, certains partages réseau, certains outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire d'administration tiers. Un pentest qui recommande Protected Users sans mentionner ce risque opérationnel expose le client à une régression de service au moment de l'application, ce qui décrédibilise durablement la recommandation suivante.

Une baseline de hardening réaliste

Au-delà de ces mécanismes ciblés, un socle de durcissement général réduit la surface d'attaque globale du domaine :

1. Désactiver SMBv1 et exiger la signature SMB sur l'ensemble du parc, limitant les relais NTLM
2. Restreindre les délégations Kerberos non contraintes aux seuls comptes qui en ont un besoin documenté et justifié
3. Auditer et nettoyer AdminSDHolder régulièrement, cet objet étant une cible récurrente pour une persistance discrète
4. Limiter l'appartenance aux groupes à privilèges (Domain Admins, Enterprise Admins) au strict nécessaire, avec revue périodique
5. Désactiver le cache de credentials en mémoire via WDigest et limiter l'exposition de LSASS (RunAsPPL)
6. Déployer une baseline GPO reconnue (CIS Benchmarks ou Microsoft Security Baseline) plutôt que des réglages ad hoc dispersés
7. Segmenter le réseau pour limiter l'accès direct entre postes utilisateurs et serveurs Tier 0/1

Aucune n'est suffisante isolément — c'est leur superposition, associée au tiering et à la détection par télémétrie et honeytokens, qui constitue une défense en profondeur cohérente.

Restituer ces recommandations dans un rapport

Une recommandation défensive n'a de valeur que si elle est actionnable. Trois pratiques distinguent un rapport utile d'une liste générique :

• Prioriser par impact réel démontré, pas par sévérité théorique — une recommandation LAPS appuyée par une démonstration concrète de Pass-the-Hash à grande échelle pèse plus qu'une liste de bonnes pratiques non contextualisées
• Indiquer les effets de bord attendus (comme pour Protected Users) pour que l'équipe IT puisse planifier un déploiement progressif plutôt que de renoncer face à un risque de régression mal anticipé
• Fournir les règles de détection concrètes, pas seulement la liste des Event ID — un client qui reçoit "activez l'audit Kerberos" sans logique de corrélation associée ne saura pas quoi faire de cette information une fois le SIEM configuré

Ce qu'il faut retenir

La défense d'un domaine Active Directory ne repose pas sur un outil unique mais sur la combinaison de plusieurs leviers indépendants : une télémétrie correctement configurée pour voir, des honeytokens pour détecter sans bruit, un tiering pour cloisonner structurellement, et LAPS/Protected Users pour réduire la portée de tout secret volé. Un pentester qui maîtrise ces mécanismes ne se contente pas de démontrer une compromission : il restitue une feuille de route défendable, hiérarchisée et réaliste. Le chapitre suivant aborde la persistance et le maintien d'accès, dont la compréhension complète ce tableau défensif.