đ§© 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 ?
