Sécuriser Active Directory Certificate Services : détecter ESC1, ESC4, ESC6 et ESC8

AD CS est un système d’identité, pas seulement un serveur de certificats

Une autorité de certification d’entreprise peut émettre les certificats utilisés par Kerberos, les cartes à puce, le Wi-Fi, le VPN, LDAPS, Intune ou les serveurs Web. Une mauvaise combinaison de modèle, de droit d’inscription et de mappage d’identité peut donc transformer le compte d’un utilisateur ordinaire en certificat accepté comme preuve d’une identité privilégiée.

Les noms ESC1, ESC4, ESC6 et ESC8 viennent de la taxonomie publiée par Will Schroeder et Lee Christensen dans la recherche Certified Pre-Owned. Ce ne sont ni des CVE ni des niveaux de gravité automatiques : ce sont des chemins d’attaque. Il faut confirmer toutes leurs conditions, la publication réelle du modèle et les contrôles compensatoires avant de déclarer un environnement exploitable.

Dans un audit, je commence par la chaîne complète : autorités d’entreprise, modèles publiés, ACL, services Web d’inscription, configuration du KDC et certificats déjà émis. Regarder seulement la console Certification Authority laisse facilement passer les permissions stockées dans Active Directory ou un ancien point de terminaison IIS oublié.

• SpecterOps — Certified Pre-Owned et boîte à outils défensive PSPKIAudit ↗
• Microsoft — Concepts des modèles de certificats AD CS ↗

Reconnaître rapidement les quatre chemins d’attaque

La présence d’un seul réglage n’est pas toujours suffisante. Par exemple, Supply in the request répond à des besoins légitimes pour certains certificats Web. Le danger ESC1 apparaît lorsque ce réglage rencontre un usage d’authentification, un demandeur peu privilégié et l’absence de validation. À l’inverse, ESC4 est déjà préoccupant même si le modèle semble sain aujourd’hui : celui qui peut l’écrire peut fabriquer ESC1, puis remettre les valeurs originales après l’émission.

• Microsoft Defender for Identity — Évaluations de sécurité des certificats ↗

Faire un inventaire en lecture seule avant de toucher aux modèles

Exécutez la collecte depuis une station d’administration avec le module ActiveDirectory. Le script ci-dessous exporte les autorités d’entreprise, les modèles qu’elles publient, les indicateurs importants et les droits capables de modifier un modèle. Il ne demande aucun certificat et ne change rien.

Les groupes personnalisés et imbriqués doivent ensuite être développés. Un groupe nommé PKI-Enrollment n’est pas sûr par son nom : vérifiez ses membres effectifs, son propriétaire et le processus qui les ajoute. Conservez aussi la sortie certutil de chaque autorité, la liste des rôles AD CS et les configurations IIS.

Import-Module ActiveDirectory

$Out = 'C:\Temp\ADCS-Audit'
New-Item -ItemType Directory -Path $Out -Force | Out-Null
$configNC = (Get-ADRootDSE).ConfigurationNamingContext
$services = "CN=Public Key Services,CN=Services,$configNC"
$templateBase = "CN=Certificate Templates,$services"
$caBase = "CN=Enrollment Services,$services"

$cas = Get-ADObject -SearchBase $caBase -LDAPFilter '(objectClass=pKIEnrollmentService)' `
  -Properties dNSHostName,certificateTemplates,cACertificate
$cas | Select-Object Name,dNSHostName,certificateTemplates |
  Export-Clixml "$Out\Enterprise-CAs.xml"

$templates = Get-ADObject -SearchBase $templateBase `
  -LDAPFilter '(objectClass=pKICertificateTemplate)' `
  -Properties displayName,msPKI-Certificate-Name-Flag,msPKI-Enrollment-Flag,`
              msPKI-RA-Signature,pKIExtendedKeyUsage

$templates | ForEach-Object {
  [pscustomobject]@{
    Template              = $_.Name
    DisplayName           = $_.DisplayName
    PublishedBy           = (($cas | Where-Object certificateTemplates -Contains $_.Name).Name -join '; ')
    SuppliesSubject       = (([int]$_.'msPKI-Certificate-Name-Flag' -band 0x1) -ne 0)
    ManagerApproval       = (([int]$_.'msPKI-Enrollment-Flag' -band 0x2) -ne 0)
    AuthorizedSignatures  = [int]$_.'msPKI-RA-Signature'
    EKU                    = ($_.pKIExtendedKeyUsage -join '; ')
    DistinguishedName     = $_.DistinguishedName
  }
} | Export-Csv "$Out\Templates.csv" -NoTypeInformation -Encoding UTF8

$templates | ForEach-Object {
  $template = $_
  (Get-Acl -Path ("AD:\{0}" -f $template.DistinguishedName)).Access |
    Where-Object { $_.AccessControlType -eq 'Allow' -and
      $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty' } |
    ForEach-Object {
      [pscustomobject]@{
        Template = $template.DisplayName
        Principal = $_.IdentityReference
        Rights = $_.ActiveDirectoryRights
        ObjectType = $_.ObjectType
        Inherited = $_.IsInherited
      }
    }
} | Export-Csv "$Out\Template-Write-Rights.csv" -NoTypeInformation -Encoding UTF8

certutil -getreg policy\EditFlags
certutil -getreg CA\AuditFilter
certutil -CATemplates > C:\Temp\ADCS-Audit\Published-Templates.txt

Get-WindowsFeature ADCS-Cert-Authority,ADCS-Web-Enrollment,ADCS-Enroll-Web-Svc
Get-Website
Get-WebApplication | Select-Object Site,Path,PhysicalPath

• Microsoft — Get-ADObject ↗
• Microsoft — Certutil ↗

ESC1 : le demandeur peut choisir l’identité du certificat

Un modèle ESC1 exploitable réunit généralement quatre éléments : il est publié; un utilisateur non privilégié peut s’y inscrire; le demandeur peut fournir le sujet ou le SAN; et le certificat permet une authentification, par exemple avec Client Authentication, Smart Card Logon, PKINIT Client Authentication, Any Purpose ou parfois aucun EKU. Sans approbation du gestionnaire ni signature autorisée, la demande peut être émise immédiatement.

Dans la console Certificate Templates, examinez Subject Name, Extensions, Security et Issuance Requirements. Ne vous arrêtez pas à Domain Users et Authenticated Users : une ACL accordée à un groupe applicatif peut redevenir large à cause de groupes imbriqués. Confirmez aussi que le modèle apparaît réellement dans Certificate Templates to Issue sur au moins une autorité.

La correction la plus sûre dépend du besoin. Dépubliez d’abord un modèle inutile. Sinon, faites dériver le sujet d’Active Directory, retirez les EKU d’authentification lorsqu’ils ne servent pas, limitez Enroll/Autoenroll à un groupe géré et ajoutez une approbation ou des signatures lorsque le processus l’accepte. Pour un serveur Web qui doit fournir plusieurs DNS dans son SAN, créez un modèle distinct et réservez-le aux comptes de déploiement contrôlés.

• Ne modifiez pas un modèle partagé par NPS, VPN, Wi-Fi, carte à puce ou Windows Hello sans identifier ses consommateurs.
• Préférez dupliquer un modèle, piloter le remplacement, puis dépublier l’ancien plutôt qu’un changement global sans retour arrière.
• Une entrée Deny ajoutée au hasard peut produire des effets inattendus; simplifiez les groupes et les autorisations Allow.
• Traitez tout certificat d’authentification déjà émis à un sujet inattendu comme une piste d’incident.

• Microsoft — Prévenir les demandes valides pour des utilisateurs arbitraires (ESC1) ↗

ESC4 : auditer qui peut réécrire le modèle

Un modèle est un objet dans la partition Configuration d’Active Directory. Son propriétaire et son ACL contrôlent bien plus que l’inscription. GenericAll, GenericWrite, WriteProperty, WriteDacl ou WriteOwner peuvent permettre de changer le sujet, les EKU, les exigences d’émission ou les droits d’inscription. Microsoft Defender for Identity signale séparément un propriétaire faible et une ACL de modèle faible sous ESC4.

Pour chaque entrée exportée, remontez jusqu’à l’utilisateur effectif. Les droits accordés à Enterprise Admins, Domain Admins ou à un groupe PKI étroitement géré sont attendus; ceux accordés à Authenticated Users, Domain Users, Everyone, à un compte de service ordinaire ou à un groupe délégué sans processus de changement demandent une justification immédiate.

Remettez le propriétaire à une identité privilégiée et surveillée, retirez les droits d’écriture non nécessaires et séparez l’administration des modèles de la simple inscription. Si vous soupçonnez une modification malveillante, ne vous contentez pas de l’ACL actuelle : comparez les événements 4899 et 4900, les sauvegardes d’Active Directory et les certificats émis pendant la fenêtre de changement.

• Microsoft — Propriétaire et ACL de modèles mal configurés (ESC4) ↗

ESC6 : un seul drapeau de l’autorité affecte tous les modèles

EDITF_ATTRIBUTESUBJECTALTNAME2 autorise le SAN fourni comme attribut de demande au niveau de l’autorité. Contrairement à Supply in the request, ce réglage s’applique à tous les modèles traités par cette autorité. Il suffit alors d’un modèle publié, accessible et valide pour l’authentification pour créer une combinaison dangereuse.

Sur chaque autorité, cherchez explicitement EDITF_ATTRIBUTESUBJECTALTNAME2 dans la sortie de certutil. Avant de le retirer, identifiez les systèmes qui envoient SAN: dans les attributs de demande — anciennes intégrations, outils de certificats Web ou passerelles. Migrez-les vers un modèle dédié et un mécanisme de demande contrôlé; n’entretenez pas une exception globale pour un seul produit.

Microsoft documente la commande suivante pour retirer le drapeau. Elle modifie la configuration et redémarre le service de certificats : planifiez-la, sauvegardez la configuration, testez les scénarios d’inscription et prévoyez le retour arrière. Ne l’exécutez pas comme simple commande d’audit.

certutil -getreg policy\EditFlags

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc & net start certsvc

• Microsoft — Corriger le réglage d’autorité vulnérable (ESC6) ↗

ESC8 : fermer la cible de relais NTLM dans IIS

ESC8 vise principalement Certificate Authority Web Enrollment, souvent exposé sous /certsrv, et Certificate Enrollment Web Service (CES). Lorsque ces services acceptent NTLM sans HTTPS et sans Extended Protection for Authentication, un attaquant peut tenter de relayer l’authentification forcée d’un ordinateur ou d’un utilisateur et obtenir un certificat utilisable au nom de cette identité.

Microsoft recommande d’activer EPA — Required est l’option la plus sûre — pour Web Enrollment et CES, puis Require SSL. Pour CES, le web.config du rôle doit aussi refléter extendedProtectionPolicy=Always lorsque l’interface IIS est à Required. Redémarrez IIS seulement dans une fenêtre approuvée et testez les clients réels, les noms SPN, les répartiteurs de charge et toute terminaison TLS.

Retirez Web Enrollment ou CES s’il n’existe aucun consommateur confirmé. Si le service demeure, désactivez NTLM là où les tests le permettent et privilégiez Negotiate:Kerberos. HTTPS sans EPA n’est pas une correction complète du relais; bloquer seulement une méthode de coercition ne ferme pas non plus la cible. Le contrôle durable se trouve sur le service d’inscription lui-même.

• Inventorier /certsrv, les applications CES, les liaisons HTTP/HTTPS et les méthodes d’authentification.
• Exiger un certificat TLS valide et Require SSL sur chaque application d’inscription.
• Mettre EPA à Required; utiliser When Supported uniquement comme transition documentée.
• Valider Kerberos, les SPN et le canal TLS de bout en bout avant de désactiver NTLM.
• Filtrer le réseau afin que seuls les clients ou relais attendus atteignent les points d’inscription.

Import-Module WebAdministration

Get-Website | Select-Object Name,State,PhysicalPath
Get-WebBinding | Select-Object protocol,bindingInformation,certificateHash
Get-WebApplication | Where-Object { $_.Path -match 'certsrv|CES' } |
  Select-Object Site,Path,PhysicalPath

& $env:windir\system32\inetsrv\appcmd.exe list config `
  /section:system.webServer/security/authentication/windowsAuthentication

• Microsoft KB5005413 — Atténuer le relais NTLM contre AD CS ↗

Le mappage fort des certificats aide, mais ne remplace pas le durcissement

KB5014754 a renforcé la façon dont les contrôleurs de domaine associent un certificat à un compte. Les contrôleurs corrigés sont passés par défaut en mode Full Enforcement avec les mises à jour de février 2025; la possibilité de revenir au mode de compatibilité a pris fin avec la mise à jour de sécurité du 9 septembre 2025. Un certificat qui ne possède ni extension SID valide ni autre mappage fort est alors refusé pour l’authentification concernée.

Ce changement réduit plusieurs abus fondés sur un mappage faible, mais il ne rend pas ESC1 ou ESC6 acceptable. Les autorités et modèles doivent encore limiter qui choisit le sujet, les certificats peuvent servir à d’autres protocoles, et des mappages explicites ou des configurations particulières changent le résultat. Le fait que Microsoft continue d’évaluer ESC1 et ESC6 dans Defender for Identity est un bon rappel : corrigez la cause, puis utilisez le mappage fort comme défense supplémentaire.

Sur les contrôleurs de domaine, surveillez les événements Kdcsvc 39, 40 et 41 liés aux certificats qui ne se mappent pas fortement ou dont le SID ne correspond pas. Une vieille application de certificat qui cesse de fonctionner ne doit pas conduire à rétablir un mappage faible sans échéance; émettez plutôt un nouveau certificat conforme ou créez un mappage explicite fort et documenté.

• Microsoft KB5014754 — Changements au mappage des certificats ↗

Activer les journaux qui permettent de prouver ce qui s’est passé

Dans une GPO appliquée aux autorités, activez Advanced Audit Policy Configuration > Object Access > Audit Certification Services pour les succès et les échecs. L’autorité possède aussi son propre filtre d’audit : lisez CA\AuditFilter et définissez les catégories nécessaires dans les propriétés de l’autorité. Une GPO active avec un filtre CA incomplet produit des trous.

Les événements 4886 et 4887 relient la demande, le demandeur et le certificat émis. Les événements 4882, 4885, 4890 et 4891 révèlent des changements sensibles à l’autorité. Les événements 4899 et 4900 montrent respectivement la modification du contenu et de la sécurité d’un modèle. Centralisez-les dans votre SIEM; conserver seulement le journal local d’un serveur compromis n’est pas une stratégie de détection.

$ids = 4882,4885,4886,4887,4890,4891,4899,4900
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = $ids
  StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated,Id,MachineName,Message |
  Export-Csv C:\Temp\ADCS-Audit\CA-Security-Events.csv `
    -NoTypeInformation -Encoding UTF8

• Microsoft — Événements PKI à surveiller ↗

Utiliser Defender for Identity comme contrôle continu

Defender for Identity fournit des évaluations de posture pour ESC1, ESC4, ESC6, ESC8 et d’autres configurations AD CS. Pour les contrôles qui dépendent de la configuration locale de l’autorité ou d’IIS, un capteur sur le serveur AD CS est requis. Les entités touchées apparaissent rapidement, mais le score et l’état global peuvent prendre jusqu’à 24 heures après une correction.

Cette vue accélère la priorisation, mais elle ne remplace pas l’inventaire. Ajoutez les modèles métiers, les dépendances d’inscription, les autorités hors ligne, les certificats existants et les groupes imbriqués au dossier. Après chaque correction, vérifiez à la fois la disparition de la recommandation et le succès d’une demande légitime dans le pilote.

• Installer et rendre sain le capteur MDI sur chaque autorité d’entreprise prise en charge.
• Assigner un propriétaire à chaque recommandation et documenter les modèles ou hôtes touchés.
• Établir une référence mensuelle des autorités, modèles publiés, ACL et services Web.
• Alerter sur les changements entre deux références, pas seulement sur le score Secure Score.

• Guide connexe — Migrer Defender for Identity vers les capteurs v3.x →

Si un certificat suspect a été émis, passer en mode incident

Corriger le modèle empêche de nouvelles demandes; cela n’invalide pas un certificat déjà émis. Recherchez dans la base de l’autorité les requêtes correspondant au modèle, au demandeur, au sujet et à la période suspecte. Comparez les événements 4886/4887, les connexions des comptes privilégiés et les changements de modèles ou de CA.

Révoquez les certificats confirmés malveillants, publiez une nouvelle CRL et assurez-vous que les consommateurs consultent réellement la CRL ou l’OCSP. Un certificat peut rester utile à l’attaquant jusqu’à son expiration si le protocole ne vérifie pas la révocation. Réinitialisez les identifiants ou comptes concernés et traitez le serveur CA, sa clé privée et les comptes d’administration comme compromis si les preuves le suggèrent.

Une clé privée d’autorité compromise change complètement la réponse : la révocation d’un certificat final ne suffit plus. Isolez le serveur, préservez les preuves et engagez le plan de compromission PKI, qui peut aller jusqu’au renouvellement ou au remplacement de l’autorité et à la redistribution des chaînes de confiance.

certutil -config "CA01.contoso.com\Contoso Issuing CA" -view `
  -restrict "CertificateTemplate=UserAuthentication" `
  -out "RequestID,RequesterName,Request.Disposition,CertificateTemplate,NotBefore,NotAfter,SerialNumber"

• Microsoft — Révoquer un certificat et publier une CRL ↗

Corriger par vagues sans casser Wi-Fi, VPN ou ouverture de session

La priorité n’est pas de faire disparaître quatre étiquettes dans un tableau. Elle est de fermer les chemins d’usurpation tout en gardant les usages légitimes. Commencez par dépublier ce qui est manifestement inutile et par limiter les droits trop larges. Les changements qui touchent le sujet, les EKU, EPA, NTLM ou le mappage KDC passent ensuite par un pilote représentatif.

Avant chaque vague, sauvegardez la configuration et la base de l’autorité, exportez les ACL, confirmez la publication des CRL et documentez une méthode de retour. Testez l’inscription initiale et le renouvellement : un certificat encore valide peut masquer une politique cassée pendant des mois.

La liste de contrôle qui ferme réellement le dossier

AD CS pardonne mal les inventaires incomplets : un ancien modèle ou une application CES oubliée peut réintroduire un chemin vers les comptes les plus privilégiés. Une revue ponctuelle ferme les failles visibles; une référence de configuration, des journaux centralisés et un responsable PKI empêchent qu’elles reviennent silencieusement.

Si vous voulez une vue indépendante de la chaîne complète — autorités, modèles, permissions, mappage, journaux et dépendances — l’audit de sécurité Active Directory sert précisément à produire cette cartographie et une feuille de route de correction priorisée.

• Toutes les autorités d’entreprise, subordonnées et hors ligne sont documentées avec leurs propriétaires.
• Chaque modèle publié possède un besoin, un propriétaire, une population d’inscription et une date de révision.
• Aucun modèle d’authentification à inscription large ne combine SAN fourni, émission automatique et absence de signature.
• Aucun principal non privilégié ne possède GenericAll, GenericWrite, WriteDacl, WriteOwner ou WriteProperty sur un modèle sensible.
• EDITF_ATTRIBUTESUBJECTALTNAME2 est absent ou fait l’objet d’une exception temporaire, isolée et testée.
• Web Enrollment et CES inutiles sont retirés; les autres imposent HTTPS, EPA et une authentification réduite.
• Le mappage fort est appliqué et les événements KDC 39, 40 et 41 sont traités.
• Les événements CA et de modèles sont centralisés, conservés et reliés aux identités et aux certificats émis.
• Les certificats suspects ont été recherchés; la révocation et la publication de CRL ont été testées.
• Le renouvellement des usages critiques a été validé après les changements, pas seulement leur fonctionnement actuel.
• La sauvegarde de la CA, la protection de sa clé et la restauration font partie du plan de continuité.

• Service — Audit de sécurité Active Directory →
• Guide connexe — Auditer la sécurité d’Active Directory →
• Guide connexe — Migrer Kerberos de RC4 vers AES →