🧩 Contexte — l’annuaire qui sait tout (et que tout le monde ignore)
Active Directory (AD) n’est pas juste un annuaire : c’est le clef de voûte de l’authentification et des autorisations dans la majorité des grandes entreprises. Applications, services, postes, mêmes les imprimantes parlent AD. Résultat : qui contrôle AD contrôle (pratiquement) tout. Le récent article de The Hacker News le rappelle — AD est la cible « holy grail » pour les attaquants, en particulier dans les environnements hybrides on-premises / cloud.
💀 Pourquoi AD intéresse tant les attaquants
Parce qu’une fois dedans, on peut créer des comptes, escalader des privilèges, désactiver des contrôles, et bouger latéralement sans ressembler à un robot malveillant — ça ressemble tout à fait à de l’activité « légitime » pour la plupart des outils de détection. Les techniques classiques ? Golden Tickets, DCSync, Kerberoasting, et exploitation des mécanismes de synchronisation cloud/on-prem. Ces méthodes permettent d’extraire des secrets ou de persister pendant des mois.
🔍 Exemples d’attaques (concrets et rodés)
- Golden Ticket : vol du Kerberos TGT (ticket-granting ticket) pour fabriquer des tickets donnant accès illimité au domaine pendant des mois. (Technique ancienne, toujours efficace si le KRBTGT n’a pas été réinitialisé.)
- DCSync : requête simulée vers un contrôleur de domaine pour récupérer les hashes de mots de passe — utile quand l’attaquant a obtenu des droits de réplication.
- Kerberoasting : ciblage des comptes de service (SPNs) dont le chiffrement peut être attaqué offline si le mot de passe est faible.
Exemple opérationnel : un serveur mal patché ou un compte service avec mot de passe statique → pivot → DCSync → Golden Ticket. Boom : tout l’empire s’effondre parce qu’on a estimé que « personne ne touchera ce vieux compte ». Grave erreur.
🧱 Parades techniques et organisationnelles (pratiques, pas du baratin)
- MFA obligatoire pour tous les comptes privilégiés — pas « recommandé », obligatoire. Multifacteur sur les comptes admin et les tâches de synchronisation cloud. The Hacker News
- Séparer les comptes d’administration — comptes user / comptes admin distincts ; utiliser des Privileged Access Workstations (PAW) pour les opérations sensibles.
- Just-In-Time (JIT) & Just-Enough-Access (JEA) — réduire la fenêtre et l’étendue des privilèges ; automatiser l’octroi temporaire.
- Rotation & durcissement des comptes de service — pas de mots de passe « qui ne changent jamais ». Utiliser Managed Service Accounts / Group Managed Service Accounts quand c’est possible.
- Bloquer les mots de passe compromis — intégration de listes de mots de passe connus compromis et scan continu. (Specops et similaires sont cités comme solutions.)
- Surveillance continue des changements AD — alertes sur modifications de groupe « Domain Admins », répliques anormales, créations massives de comptes, horaire bizarre d’actions admin (3h du matin = rouge).
- Patch management agressif des DCs — déployer les correctifs des contrôleurs de domaine en jours, pas en mois : les vulnérabilités AD sont activement scannées par les attaquants.
⚙️ Exemple concret de durcissement d’un domaine hybride (to-do list exécutable)
- Audit initial : inventaire des comptes à privilèges, SPN, GPOs suspects, contrôleurs non patchés.
- Isolation : créer PAW pour les admins et retirer l’accès RDP direct depuis le LAN aux DCs.
- MFA & Conditional Access : déployer MFA sur tous les comptes à haut privilège et règles conditionnelles basées sur device health / IP.
- Revoir la sync Azure AD Connect : limiter les comptes qui peuvent écrire en-arrière (cloud → on-prem), activer sync filtering, vérifier permissions d’AD Connect.
- Rotation KRBTGT si historique de compromission ou soupçon — plan et procédure de rotation testée hors production.
- SIEM + EDR + Alerting AD : créer playbooks pour anomalies AD (replication anormale, DCSync, changement membership Domain Admin).
- Tabletop & exercices : simuler un Golden Ticket / DCSync et vérifier que le SOC détecte et que l’équipe sait isoler.
🧠 Conclusion (avec une pointe de sarcasme)
Avoir Active Directory, c’est confortable — jusqu’au jour où il devient la porte ouverte de ton SI. Si tu traites l’AD comme un service annexe, arrête tout de suite : tu as construit un château fort… sans fossé ni pont-levis. Défendre AD, c’est technique et organisationnel : MFA, PAM, monitoring, patching et discipline. Les solutions existent et sont connues ; la vraie question est : veux-tu défendre ton royaume… ou seulement espérer que les attaquants aient de la courtoisie ?
