Comptes obsolètes, privilèges et trusts
Guide professionnel et progressif consacré à comptes obsolètes, privilèges et trusts, avec méthodologie autorisée, interprétation, preuves et remédiations.
En bref
- But : Guide professionnel et progressif consacré à comptes obsolètes, privilèges et trusts, avec méthodologie autorisée, interprétation, preuves et remédiations.
- Preuve attendue : une relation AD confirmée par deux sources et une recommandation de réduction des privilèges
- Limite : le résultat est valable uniquement pour les versions, rôles, chemins et conditions effectivement testés.
Contexte métier et menace
Utiliser PingCastle pour obtenir une vue de santé Active Directory et construire un plan de correction. Une démarche Red Team fiable combine compréhension du système, progression mesurée, journalisation des actions et restitution compréhensible par les équipes techniques et métier.
Dans « Contexte métier et menace », le contrôle porte sur les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine. La méthode combine une observation initiale, une action limitée et une validation indépendante pour que le résultat reste explicable. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
La section « Contexte métier et menace » applique une méthode progressive à « Comptes obsolètes, privilèges et trusts » : état attendu, observation, validation limitée, interprétation puis retest. Les éléments centraux sont autorités de certification, modèles de certificats, identités, groupes, ACL, relations de confiance et événements d’authentification. Chaque étape doit produire une trace exploitable par un second analyste.
Surface technique
Dans « Surface technique », le contrôle porte sur les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine. La méthode combine une observation initiale, une action limitée et une validation indépendante pour que le résultat reste explicable. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
Pour cette partie de « Comptes obsolètes, privilèges et trusts », la démarche la plus fiable est de commencer par l’inventaire en lecture seule, corréler les relations avec BloodHound ou PingCastle, puis valider une hypothèse avec les journaux et les droits effectifs. Les preuves utiles sont requêtes LDAP, exports de groupes et GPO, graphes, événements des contrôleurs de domaine, horodatages et identité du compte de test, tandis que les limites connues sont documentées avant la conclusion.
La section « Surface technique » applique une méthode progressive à « Comptes obsolètes, privilèges et trusts » : état attendu, observation, validation limitée, interprétation puis retest. Les éléments centraux sont autorités de certification, modèles de certificats, identités, groupes, ACL, relations de confiance et événements d’authentification. Chaque étape doit produire une trace exploitable par un second analyste.
- Cartographier pour « Comptes obsolètes, privilèges et trusts » les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine.
Collecte minimale
Dans « Collecte minimale », le contrôle porte sur les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine. La méthode combine une observation initiale, une action limitée et une validation indépendante pour que le résultat reste explicable. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
La correction liée à « Collecte minimale » doit permettre de appliquer le moindre privilège, le tiering, corriger les délégations et durcir Kerberos/NTLM. Une preuve de déploiement est obtenue avant de reproduire le contrôle initial avec les mêmes données et le même périmètre.
Validation progressive
Un résultat de « Validation progressive » n’est retenu que lorsqu’il correspond à un chemin de privilèges reproductible, une délégation excessive, une ACL modifiable par un groupe inattendu ou une authentification incompatible avec le modèle de sécurité prévu. Une seconde source — journal, configuration ou observation indépendante — doit confirmer le constat. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
La section « Validation progressive » applique une méthode progressive à « Comptes obsolètes, privilèges et trusts » : état attendu, observation, validation limitée, interprétation puis retest. Les éléments centraux sont autorités de certification, modèles de certificats, identités, groupes, ACL, relations de confiance et événements d’authentification. Chaque étape doit produire une trace exploitable par un second analyste.
L’analyse de « Comptes obsolètes, privilèges et trusts » sépare résultat positif, résultat négatif et résultat indéterminé. Les limites suivantes sont mentionnées explicitement : la réplication, les groupes imbriqués, les sessions anciennes, les contrôles EDR et les droits locaux peuvent produire des écarts entre le graphe et la réalité.
Impact démontré
Dans « Impact démontré », le contrôle porte sur les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine. La méthode combine une observation initiale, une action limitée et une validation indépendante pour que le résultat reste explicable. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
La correction liée à « Impact démontré » doit permettre de appliquer le moindre privilège, le tiering, corriger les délégations et durcir Kerberos/NTLM. Une preuve de déploiement est obtenue avant de reproduire le contrôle initial avec les mêmes données et le même périmètre.
Mesures de réduction
Dans « Mesures de réduction », le contrôle porte sur les identités, groupes, délégations, ACL, relations de confiance, chemins d’administration et événements d’authentification du domaine. La méthode combine une observation initiale, une action limitée et une validation indépendante pour que le résultat reste explicable. Le point est ici appliqué au cas « Comptes obsolètes, privilèges et trusts ».
Commandes et exemples
Les exemples ci-dessous proviennent des éléments utiles de « Comptes obsolètes, privilèges et trusts ». Adaptez uniquement les valeurs du laboratoire et conservez la commande exacte avec sa sortie.
Exemples de laboratoire
# Chapitre : Comptes obsolètes, privilèges et trusts
# Répertoire de preuve conseillé : preuves/comptes_obsoletes_privileges_et_trusts/bloc_01
# Vérifier version, aide et empreinte avant admission dans le catalogue
outil --version 2>/dev/null || outil -h
sha256sum ./outil
Tutoriel guidé et reproductible — Comptes obsolètes, privilèges et trusts
# Comptes obsolètes, privilèges et trusts
New-Item -ItemType Directory -Force "preuves/04_comptes_obsoletes_privileges_et_trusts" | Out-Null
.\PingCastle.exe --healthcheck --server lab.local --out "preuves/04_comptes_obsoletes_privileges_et_trusts"Détection, correction et retest
La correction de « Comptes obsolètes, privilèges et trusts » vise d’abord les droits excessifs, les configurations héritées et les systèmes non corrigés. Le retest utilise le même compte, la même portée et les mêmes requêtes en lecture seule.
Références
- SpecterOps — BloodHound documentation
- Microsoft — AD security best practices
- Microsoft — Active Directory Certificate Services
- PingCastle Documentation
- Microsoft Learn — Active Directory Domain Services
- CIS Benchmarks
- Penetration Testing Execution Standard
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
- A-poc — RedTeam-Tools
- infosecn1nja — Red-Teaming-Toolkit
- HackTricks — Pentesting Methodology
À retenir
Pour maîtriser « Comptes obsolètes, privilèges et trusts », retenez trois idées : comprendre les objets AD concernés, les relations de contrôle, l’héritage des ACL et les dépendances entre domaines, hôtes et identités, exécuter une méthode limitée et reproductible, puis transformer la sortie en preuve contextualisée. Le chapitre est terminé lorsque le résultat peut être confirmé, que ses limites sont explicites et que la correction peut être retestée sans réinterpréter toute la mission.
- Savoir expliquer le mécanisme propre à « Comptes obsolètes, privilèges et trusts » sans réciter une commande.
- Conserver au minimum objet source et objet cible, relation ou droit observé et portée de l’héritage.
- Éviter en priorité de prendre un chemin théorique pour une compromission confirmée et de ignorer les groupes imbriqués et les héritages.
- Proposer une action corrective mesurable et un retest réalisable.