Pourquoi Active Directory est une cible majeure en 2025

Active Directory reste en 2025 la cible numéro 1 des ransomware et des groupes APT visant les entreprises, malgré 10 ans de discours sur Zero Trust et migration cloud. Selon le Microsoft Digital Defense Report 2024, 95 % des Fortune 1000 utilisent encore AD on-prem comme système d'identité principal. Selon CrowdStrike Global Threat Report 2024, 80 % des intrusions observées incluent une phase de compromission AD (privilege escalation ou credential access). Les retours terrain PASSI français (Synacktiv, Almond, Wavestone Cyber, Orange Cyberdefense en 2024) convergent : 60 à 80 % des pentests internes AD démontrent une chaîne d'escalade vers Domain Admin en 1-5 jours. Cinq raisons structurelles expliquent cette position dominante : ubiquité (95 % F1000, 80 % ETI françaises), centralisation excessive (compromettre Domain Admin = contrôle total immédiat), dette historique (domaines 10-20 ans avec GPOs legacy, comptes dormants, ACLs non-auditées), IAM critique (Kerberos authentifie tout le réseau Windows), documentation offensive massive (BloodHound, Certipy, Impacket, SpecterOps, Harmj0y publications, trainings Altered Security). Les 7 attaques dominantes 2024-2025 sont Kerberoasting, AS-REP Roasting, DCSync, NTLM Relay, Pass-the-Hash, ADCS abuse (ESC1-ESC8), Certifried (CVE-2022-26923) — toutes exploitables via outils publics et documentation exhaustive. L'ADCS est devenu le nouveau vecteur majeur depuis 2021 avec le paper Certified Pre-Owned de SpecterOps (juillet 2021) qui a exposé 8 chaînes d'abus jamais patchées par défaut avant KB5014754 (mai 2022, enforcement avril 2023). Le coût médian d'un incident AD avec ransomware est 4,54 M$ (IBM Cost of a Data Breach 2024), avec des cas à 100 M$-1 Md$ documentés (Change Healthcare, CDK Global 2024). Cet article détaille les 5 raisons structurelles avec données, les 7 attaques dominantes, les limites architecturales de Kerberos, le cas ADCS depuis 2021, les limites des contre-mesures Microsoft natives (Protected Users, Credential Guard), et la migration Entra ID qui ne règle pas le problème mais le déplace. Pour le contexte méthodologique d'un audit AD offensif, voir Qu'est-ce qu'un pentest interne. Pour l'IAM global, Qu'est-ce que l'IAM.

1. Les chiffres qui disent tout

1.1 Prévalence AD dans les incidents 2024

1.2 Pourquoi pas cloud-first pour tout le monde

Les organisations 2025 sont massivement en architecture hybride (AD on-prem + Entra Connect sync + Entra ID cloud) pour des raisons structurelles :

• Applications legacy : ERP (SAP ECC, Oracle EBS), GED, applis métier custom qui auth via LDAP ou Kerberos, sans support OIDC/SAML.
• Device management : domain-join Windows + GPO pour 10 000+ postes bureautique, difficilement migrable vers Intune pur.
• File servers on-prem avec auth Kerberos.
• Coût migration : refactoring applicatif, formation ops, risque rollback.

Gartner Cloud Adoption Report 2024 estime la migration complète AD → Entra ID only à 10-15 ans pour les organisations Fortune 1000. D'ici là, AD reste la surface critique.

2. Raison n°1 — Ubiquité

AD a été lancé en Windows 2000 Server (2000), remplaçant NT 4.0 Domain. Sur 25 ans, il est devenu le standard de facto de l'IT enterprise :

• 95 % Fortune 1000 (Microsoft 2024).
• ~80 % ETI françaises 500-5000 personnes (observations terrain PASSI).
• Universités, collectivités, hôpitaux, administrations : quasi-systématique.

Cette ubiquité signifie :

• Expertise attaquant universelle — former un attaquant AD sert pour tous les mandats.
• Outils mutualisés — BloodHound, Impacket, Mimikatz fonctionnent partout.
• Trainings offensifs dédiés — SANS SEC565, Altered Security CRTE/CRTP, OffSec OSEP, Zero Point Security CRTO.
• Veille technique concentrée — un nouveau bug AD = impact massif.

3. Raison n°2 — Centralisation excessive

3.1 Le piège architectural Domain Admin

Dans le modèle AD classique, Domain Admin est un groupe hautement privilégié qui, par défaut, a des droits admin sur tous les serveurs et postes joints au domaine. Enterprise Admin est encore pire (root sur toute la forêt multi-domaines).

Compromettre un compte DA = game over immédiat :

• Accès SYSTEM sur tous les DCs.
• Dump de Ntds.dit (base de données AD complète avec hashes).
• Déploiement massif via GPO (persistence, ransomware, keylogger).
• Accès à toute ressource partagée.
• Pas de détection distinguable d'une action admin légitime.

3.2 Tiering Microsoft / ANSSI — l'antidote

Le modèle Enhanced Security Administrative Environment (ESAE) Microsoft (2016) et son évolution Privileged Access Strategy (2020+), parallèlement aux guides ANSSI Administration sécurisée SI (2018, v2 2023), définissent 3 niveaux :

Règle stricte : un credential Tier 0 ne doit jamais s'authentifier sur un Tier 2 (sinon un keylogger endpoint capture le DA). Admin workstations séparées (Privileged Access Workstations, PAW) dédiées Tier 0.

Tiering Active Directory — modèle ANSSI / Microsoft
────────────────────────────────────────────────────
 
  ┌───────────────────────┐
  │      TIER 0           │   ← DCs, ADCS, Entra Connect
  │  (infra identité)     │     Admins Tier 0 via PAW dédié
  │  Admins : DA, EA      │
  └───────────────────────┘
           ✗ pas d'auth descendante
           ▼
  ┌───────────────────────┐
  │      TIER 1           │   ← Serveurs apps, DB, middleware
  │  (applications)       │
  │  Admins : Server Ops  │
  └───────────────────────┘
           ✗ pas d'auth descendante
           ▼
  ┌───────────────────────┐
  │      TIER 2           │   ← Postes utilisateurs
  │  (endpoints)          │
  │  Admins : Helpdesk    │
  └───────────────────────┘

Taux d'adoption 2025 : selon Microsoft, < 20 % des organisations avec AD ont un tiering strict déployé. 80 % ont des violations de tier (DA qui se connecte à un serveur app, admin serveur avec compte DA bureautique) — chaque violation ouvre un chemin d'escalade.

4. Raison n°3 — Dette historique

4.1 Un AD typique a 10-20 ans

Les organisations maintiennent souvent le même domaine AD depuis sa création initiale, héritant :

• GPOs créées par des admins partis depuis 10+ ans — personne ne sait ce qu'elles font exactement.
• Comptes de service avec SPNs pour applications décommissionnées, mots de passe inchangés depuis 2015.
• Délégations Kerberos non contraintes accordées à des serveurs legacy — vecteur T1550.003 (Pass-the-Ticket).
• ACLs personnalisées sur des OUs ou des comptes, accordées pour un besoin ponctuel et jamais révoquées.
• Trusts forestiers avec entités acquises ou revendues, rarement désactivés.
• Relations LDAP avec applications tierces, auth basic non chiffrée.

4.2 Audit ACL — le point le plus sous-estimé

Un domaine AD moyen a 50 000 à 500 000 permissions ACL distribuées. Impossible à auditer manuellement. L'outil BloodHound (créé en 2016 par SpecterOps, version CE open-source + Enterprise commercial depuis 2021) modélise le domaine en graphe Neo4j et identifie les chemins d'attaque par requête Cypher :

-- Exemple requête BloodHound Cypher
-- Chemins vers Domain Admin depuis un user standard
 
MATCH p = shortestPath(
    (u:User {name: "alice@DOMAIN.LOCAL"})-[*1..10]->(g:Group {name: "DOMAIN ADMINS@DOMAIN.LOCAL"})
)
RETURN p
LIMIT 10

Résultat typique sur un domaine non-audité : 3-8 chemins d'escalade identifiés en minutes, via combinaisons ACL WriteOwner, WriteDACL, GenericAll, AddMember, ReadLAPSPassword, délégation Kerberos, Kerberoasting, ADCS templates.

5. Raison n°4 — Kerberos architectural

5.1 Le protocole et sa surface

Kerberos v5 (RFC 4120, 2005, basé sur MIT Kerberos 1988) est le protocole d'authentification AD. Fonctionnement simplifié :

Kerberos authentication flow — simplification
──────────────────────────────────────────────
 
1. User → KDC (DC) : AS-REQ, demande TGT avec pre-auth encrypted_timestamp
2. KDC → User : AS-REP, TGT chiffré avec krbtgt key
3. User → KDC : TGS-REQ avec TGT, demande TGS pour un service SPN
4. KDC → User : TGS-REP, TGS chiffré avec la clé du compte service
5. User → Service : présentation du TGS pour authentification

Chaque étape a ses faiblesses exploitables :

• AS-REQ sans pre-auth (DONT_REQUIRE_PREAUTH flag) → AS-REP Roasting (hash crackable offline).
• TGS-REQ pour n'importe quel SPN → Kerberoasting (hash du compte service crackable).
• Krbtgt key → si connue, permet de forger Golden Ticket (TGT valide pour tout user, 10 ans par défaut).
• Service key → si connue, permet de forger Silver Ticket (TGS local au service).
• Délégation non contrainte → compte serveur peut impersonifier n'importe qui (T1550.003).
• Délégation contrainte (S4U) → abus via constrained delegation à tout service (T1558.003).

5.2 La krbtgt — clé d'or

Le compte krbtgt signe tous les TGTs du domaine. Sa compromission = compromission permanente de l'AD jusqu'à rotation — et ANSSI/Microsoft recommandent rotation double (2x en 24h) pour invalider les Golden Tickets en circulation. Moins de 30 % des organisations font la rotation krbtgt régulièrement (benchmarks terrain 2024).

6. Raison n°5 — Documentation offensive massive

L'écosystème attaquant AD est le plus documenté et outillé de toute la cybersécurité offensive :

6.1 Outils open-source universels

6.2 Recherche publique

• SpecterOps (Will Schroeder / Harmj0y, Andy Robbins, Lee Christensen) : papers BloodHound, Certified Pre-Owned, trainings.
• TrustedSec (Dave Kennedy) : papers, outils Spawn, RunOf, post-exploitation Windows.
• Microsoft MSRC : advisories CVE, patches, recherche interne.
• MITRE ATT&CK T1558 (Steal or Forge Kerberos Tickets) + 5 sous-techniques documentées.
• Conférences : DEFCON, Blackhat, Troopers, NDH, Barbhack, HEXACON — dizaines de talks AD chaque année.

6.3 Trainings offensifs dédiés

Pour la roadmap pentest complète, voir Roadmap pentest.

7. Les 7 attaques AD dominantes 2024-2025

Par prévalence observée en pentest 2024-2025 :

7.1 Kerberoasting (T1558.003)

Demander TGS pour comptes avec SPN, cracker le hash offline avec hashcat mode 13100.

# Impacket GetUserSPNs pour énumérer + extraire les TGS
GetUserSPNs.py -request -dc-ip 10.0.0.1 DOMAIN.LOCAL/standarduser:Password123
 
# Cracking offline avec hashcat
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt \
    --rules-file /usr/share/hashcat/rules/best64.rule

7.2 AS-REP Roasting (T1558.004)

Utilisateurs avec flag DONT_REQUIRE_PREAUTH permettent de demander AS-REP sans authentification, hash crackable.

7.3 DCSync (T1003.006)

Compte avec privilèges DS-Replication-Get-Changes (DA, EA, ou délégués) peut répliquer Ntds.dit via Mimikatz lsadump::dcsync. Game over direct.

7.4 NTLM Relay (T1557.001)

Attaque Responder poisoning LLMNR/NBT-NS/mDNS + relai des hashes NTLMv2 captés vers SMB / LDAP / ADCS via ntlmrelayx. Coercion via PetitPotam / Coercer sur WebClient.

7.5 Pass-the-Hash (T1550.002)

Hash NT capturé via LSASS dump ou SMB relay, utilisé directement sans cracker via Impacket psexec.py, wmiexec.py, smbexec.py.

7.6 ADCS ESC1-ESC8 (T1649 ADCS abuse)

Templates de certificats autorisant Client Authentication avec Subject Alternative Name attacker-controlled → demande certificat au nom de Domain Admin → authentification Kerberos avec PKINIT → Domain Admin.

# Certipy pour énumérer ADCS + exploiter ESC1
certipy find -u user@domain.local -p Password123 -vulnerable -stdout
 
certipy req -u user@domain.local -p Password123 \
    -ca DC-CA -template VulnerableTemplate \
    -upn administrator@domain.local

7.7 Golden Ticket / Silver Ticket (T1558.001, T1558.002)

Après compromission krbtgt (Golden) ou clé service (Silver), forge de tickets Kerberos valides sans crédential.

8. ADCS — le nouveau vecteur majeur 2021-2025

8.1 Le paper Certified Pre-Owned

Publié par Will Schroeder (Harmj0y) et Lee Christensen (SpecterOps) le 22 juillet 2021, le paper Certified Pre-Owned documente 8 chaînes d'abus ADCS (ESC1 à ESC8) exploitables depuis un user standard :

8.2 Patches Microsoft

• KB5014754 (mai 2022) : correction ESC9 + ESC10.
• Enforcement mode par défaut : 11 avril 2023.
• ESC1-ESC8 restent exploitables sur configurations non auditées.

Un audit ADCS sur environnement enterprise non-audité trouve typiquement 3-8 templates vulnérables sur les 15-50 templates publiés.

9. Les limites des contre-mesures Microsoft natives

9.1 Ce qui existe — et qui aide

9.2 Ce qui manque par défaut

• Tiering strict non-imposé par l'OS — dépend de la discipline admin.
• Audit ACL automatique non-natif — nécessite BloodHound ou outils tiers.
• Rotation krbtgt automatique absente — script manuel.
• Détection mouvement latéral inter-tier — Defender for Identity détecte partiellement.
• MFA sur authentification Kerberos — impossible par design Kerberos (pas de factor user interaction par TGS).

9.3 Mitigations tierces 2025

10. Migration Entra ID — solution ou problème déplacé ?

10.1 Ce qu'Entra ID règle

• Élimine Kerberos network authentication → plus de Kerberoasting, AS-REP.
• Élimine ADCS on-prem → plus d'ESC attacks (mais Entra ID Certificate-based Auth a son propre modèle).
• Élimine les GPOs legacy → configuration via Intune policy.
• MFA natif sur toutes authentifications (Conditional Access).
• Audit natif CloudTrail-like via Entra ID audit logs + Sentinel.
• Zero Trust alignment naturel avec Conditional Access + risk-based auth.

10.2 Ce qu'Entra ID ajoute comme surface

• Evil-proxy phishing (Evilginx, Modlishka) qui captent les tokens MFA.
• Token theft post-auth, refresh token valide 90 jours.
• OAuth application consent phishing — user accepte scope malicieux.
• Service principals avec permissions excessives (T1078.004).
• Entra Connect sync account compromise — pont critique vers AD.
• Guest accounts B2B mal gérés.

CrowdStrike Global Threat Report 2024 rapporte +110 % d'attaques identity cloud-native depuis 2022, illustrant que la migration cloud déplace la surface, ne la réduit pas automatiquement.

10.3 L'architecture hybride — la pire des deux mondes ?

65-70 % des organisations 2025 sont en hybride (AD on-prem + Entra Connect + Entra ID). Les attaques cumulent les deux surfaces :

• Compromission AD on-prem → pivot via sync account → Entra ID.
• Phishing Entra ID → accès SaaS + bascule vers AD on-prem via Entra Connect.
• Entra Connect Sync account (MSOL_abc123456789) est Tier 0 bidirectionnel — critique.

Pour la détection cross-environnement, voir Détection d'intrusion : les bases et CTI définition.

11. ROI du hardening AD en 2025

11.1 Coût d'un incident

11.2 Coût d'un programme AD hardening

ROI : évitement d'un seul incident ransomware en 3-5 ans rentabilise 10-50x le programme. C'est le meilleur ROI sécurité documenté 2024-2025.

Points clés à retenir

• Prévalence : 95 % Fortune 1000, 80 % ETI françaises, 80 % intrusions incluent compromission AD, 60-80 % pentests FR DA en 1-5 jours.
• 5 raisons structurelles : ubiquité, centralisation (DA = game over), dette historique 10-20 ans, IAM Kerberos critique, documentation offensive massive.
• 7 attaques dominantes : Kerberoasting, AS-REP Roasting, DCSync, NTLM Relay, Pass-the-Hash, ADCS ESC1-ESC8, Golden/Silver Ticket.
• ADCS majeur depuis juillet 2021 : paper Certified Pre-Owned de SpecterOps, ESC1-ESC8 + ESC9-ESC14 publiés 2022-2024. Enforcement Microsoft avril 2023 mais configs legacy restent vulnérables.
• Tiering 0/1/2 adopté par < 20 % des organisations — cause n°1 de propagation rapide.
• Contre-mesures natives : Protected Users, LAPS v2, Credential Guard, gMSA, Defender for Identity — utiles mais insuffisantes sans discipline tiering + audit ACL continu.
• Migration Entra ID : règle certains problèmes (Kerberos, GPOs legacy) mais ajoute surface cloud (evil-proxy, token theft, OAuth consent, service principals). Hybride est la pire configuration.
• ROI : programme AD hardening 200-450 k€/an ETI = meilleur ROI sécurité 2024-2025, évite incidents 3-15 M€+.

Pour la méthodologie pentest AD, voir Qu'est-ce qu'un pentest interne, Roadmap pentest, Pourquoi le pentest ne suffit pas. Pour la fiche métier AD security, Qu'est-ce qu'un spécialiste Active Directory Security. Pour le contexte IAM global, Qu'est-ce que l'IAM. Pour la détection des attaques AD, Détection d'intrusion : les bases et CTI définition.