Sécurité des Identités : Active Directory Certificate Services (AD CS)

Danger

Résumé exécutif : Active Directory Certificate Services (AD CS) fournit l’infrastructure à clés publiques (PKI) native pour les domaines Windows. Si l’Active Directory gère les identités, AD CS agit comme le notaire cryptographique qui délivre les “passeports” (certificats) prouvant ces identités. Depuis les recherches fondatrices “Certified Pre-Owned” de SpecterOps, les erreurs de configuration d’AD CS sont devenues la voie royale vers la compromission totale du domaine. L’exploitation de modèles de certificats défaillants permet aux attaquants de contourner totalement les mots de passe et de forger du matériel d’authentification pour n’importe quel utilisateur, y compris les administrateurs du domaine.

1. La mécanique d’AD CS et PKINIT

Pour comprendre les attaques sur AD CS, il faut comprendre comment les certificats se traduisent en accès au domaine.

AD CS s’appuie sur des modèles de certificats (Certificate Templates) — des gabarits définissant à quoi un certificat peut servir (Extended Key Usage, ou EKU), qui peut le demander, et sa durée de validité. Lorsqu’un terminal demande un certificat, il passe par le processus d’enrôlement (Enrollment) en interagissant avec l’Autorité de Certification (CA).

Le pont entre la PKI et l’authentification Active Directory est PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Au lieu d’envoyer un horodatage chiffré avec un hash de mot de passe lors de l’échange Kerberos AS-REQ initial, un utilisateur peut présenter un certificat valide (ex: une carte à puce). Le contrôleur de domaine (DC) vérifie la signature du certificat auprès de la CA de confiance. Si elle est valide, le DC émet un Ticket Granting Ticket (TGT).

L’objectif de l’attaquant : tromper la CA pour qu’elle émette un certificat valide au nom d’un compte hautement privilégié. L’attaquant utilise ensuite PKINIT via des outils comme Rubeus pour convertir ce certificat en un TGT d’administrateur de domaine.

2. Vecteurs d’attaque principaux (la taxonomie ESC)

Les chercheurs en sécurité classent les vulnérabilités AD CS selon des chemins d’escalade spécifiques (de ESC1 à ESC14+). Les analystes DFIR doivent prioriser les deux vecteurs les plus dévastateurs et courants : ESC1 et ESC8.

A. ESC1 : élévation de privilèges via une mauvaise configuration de modèle

Ce vecteur ne nécessite aucun exploit, uniquement l’abus d’un modèle mal configuré.

• La faille : un modèle de certificat est vulnérable à ESC1 s’il remplit trois conditions simultanément :
  1. Il accorde des droits d’enrôlement à des utilisateurs peu privilégiés (ex: Utilisateurs du domaine ou Utilisateurs authentifiés).
  2. Il contient un EKU permettant l’authentification (ex: Authentification client ou Ouverture de session par carte à puce).
  3. Le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT est activé. Cette faille fatale permet au demandeur de spécifier manuellement le Subject Alternative Name (SAN) au sein du certificat.
• L’attaque : un attaquant standard demande un certificat basé sur ce modèle. Dans sa demande, il injecte le nom d’utilisateur principal (UPN) d’un administrateur du domaine dans le champ SAN. La CA émet aveuglément le certificat. L’attaquant possède désormais un passeport cryptographique qui dit en substance : “je suis l’administrateur du domaine”.

B. ESC8 : relais NTLM vers les pages d’enrôlement Web AD CS

• La faille : de nombreux déploiements AD CS comportent une interface d’enrôlement web (/certsrv) fonctionnant sur HTTP, qui est intrinsèquement dépourvue de protection contre le relais NTLM.
• L’attaque : l’attaquant utilise une technique de coercition (ex: PetitPotam) pour forcer une machine critique (comme un contrôleur de domaine) à s’authentifier vers la machine de l’attaquant. L’attaquant relaie cette authentification NTLM vers le point de terminaison HTTP d’enrôlement web d’AD CS.
• Le résultat : la CA émet un certificat pour le compte machine du contrôleur de domaine. L’attaquant utilise ce certificat pour s’authentifier en tant que DC et exécute une attaque DCSync, volant ainsi tous les hashs de mots de passe du domaine.

3. Investigation forensique (CSIRT)

La chasse aux abus d’AD CS nécessite de déplacer l’attention des journaux d’authentification standards vers les journaux d’audit spécifiques générés par l’Autorité de Certification.

1. Activer l’audit de la CA : par défaut, l’audit de la CA est désactivé. Les administrateurs doivent configurer les propriétés de la CA pour auditer “Délivrer et gérer les demandes de certificats” et s’assurer que la GPO correspondante est activée (Auditer les services de certification).
2. Analyser les événements 4886 et 4887 : ces événements résident dans le journal de sécurité (Security) du serveur hébergeant la CA.
   • 4886 : les services de certification ont reçu une demande de certificat.
   • 4887 : les services de certification ont approuvé une demande de certificat et émis un certificat.
3. Chasser les SAN anormaux : au sein de l’événement 4887, analysez le champ Subject Alternative Name. Si le demandeur (Requester) est un compte d’utilisateur standard mais que le SAN contient l’identité d’un compte privilégié (ex: Administrator), une attaque ESC1 a eu lieu.

4. Détection et Threat Hunting

KQL (Defender XDR)

hunt_adcs_esc1_abuse.kql

// Détecte l'exploitation potentielle d'ESC1 en cherchant l'Événement 4887 où un certificat
// a été émis contenant un Subject Alternative Name (SAN).
SecurityEvent
| where EventID == 4887
// Filtrer les événements contenant des SAN
| where EventData has "Subject Alternative Name:"
| parse EventData with * "Requester: " RequesterAccount "\n" *
| parse EventData with * "Subject Alternative Name: " SAN "\n" *
| project TimeGenerated, Computer, RequesterAccount, SAN, EventData
// Exclure les auto-enrôlements légitimes des comptes machines (qui utilisent souvent des SAN)
| where RequesterAccount !endswith "$"
| sort by TimeGenerated desc

Sigma (Exécution d'outils Certipy/Rubeus)

sigma_adcs_tools_execution.yaml

title: Exécution d'Outils d'Exploitation AD CS (Certify/Certipy)
id: f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c
status: experimental
description: Détecte l'exécution en ligne de commande des outils classiques de Red Team utilisés pour l'énumération et l'exploitation d'AD CS.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains:
            - 'Certify.exe find '
            - 'certipy req '
            - 'certipy auth '
            - 'Rubeus.exe asktgt /certificate:'
    condition: selection
level: critical
tags:
    - attack.credential_access
    - attack.t1649

5. Atténuation et durcissement

1. Atténuation ESC1 : auditez tous les modèles de certificats à l’aide d’outils comme Certify ou PingCastle. Désactivez le drapeau ENROLLEE_SUPPLIES_SUBJECT sur tout modèle utilisé pour l’authentification. Si un modèle nécessite absolument ce drapeau, refusez explicitement l’enrôlement aux Utilisateurs du domaine, en restreignant l’accès aux administrateurs désignés.
2. Atténuation ESC8 : désactivez la fonctionnalité d’enrôlement Web d’AD CS si elle n’est pas strictement nécessaire. Si elle est requise, imposez le protocole HTTPS et configurez la Protection étendue de l’authentification (EPA) dans IIS pour neutraliser totalement les attaques par relais NTLM.

---

Sources et références

• SpecterOps : Certified Pre-Owned: Abusing Active Directory Certificate Services
• Vaadata : Understanding Active Directory Certificate Services (AD CS) Attacks
• RedfoxSec : Exploiting Active Directory Certificate Services (AD CS)
• Analyse liée : Failles de l’authentification NTLM et relais
• Analyse liée : Architecture de l’authentification Kerberos