Évaluation PingCastle : du rapport AD au plan d'action

Un rapport PingCastle est le moyen le plus rapide d'obtenir une image honnête d'un domaine Active Directory. Il est aussi facile à mal utiliser. Certaines équipes le lancent une fois, constatent un score rouge, corrigent les trois constats les plus simples et ne l'ouvrent plus jamais. D'autres poursuivent le score jusqu'à zéro et passent des semaines sur de l'hygiène à faible impact pendant qu'un serveur en délégation non contrainte ou une GPO modifiable sur l'UO Domain Controllers reste ouvert. Ce guide explique comment exécuter PingCastle en toute sécurité, lire ses résultats comme le modèle de notation le prévoit, et transformer les constats en plan de remédiation avec des responsables, un ordre de priorité et une vérification.

La stratégie d'évaluation plus large, y compris la comparaison avec les référentiels SCT et CIS et la place de PingCastle à côté de Purple Knight, figure dans l'article pilier sur l'évaluation, la sauvegarde et la restauration. Ce guide porte sur le passage d'un rapport à un plan exécuté.

Mesurer : lancer le health check

Téléchargez PingCastle depuis son site officiel sur un poste d'administration ou une station d'administration sécurisée. Vérifiez la signature du fichier et ne l'exécutez pas depuis un DC. Lancez-le en tant qu'utilisateur standard du domaine. Le health check ne nécessite pas de droits d'administration, et l'exécuter en tant que Domain Admin ne fait qu'exposer un identifiant Tier 0 sur une machine supplémentaire.

# Vérifier le binaire avant la première utilisation
Get-AuthenticodeSignature .\PingCastle.exe | Select-Object Status, SignerCertificate

# Health check sur un domaine précis
.\PingCastle.exe --healthcheck --server corp.example.com

Lancer PingCastle.exe sans argument ouvre un menu interactif, dont l'option 1 correspond au même health check. Chaque exécution produit deux fichiers nommés d'après le domaine :

• ad_hc_<domain>.html, le rapport destiné aux humains.
• ad_hc_<domain>.xml, les données pour le suivi de tendance et les scripts. Il contient des informations détaillées sur votre domaine : conservez-le avec le même soin que le HTML.

Exécutez-le une fois par domaine, y compris pour chaque domaine enfant et chaque domaine que vous approuvez. La section sur les approbations montre ce que le domaine analysé expose, mais les risques internes à un domaine approuvé n'apparaissent que lorsque vous analysez ce domaine.

Auditer : lire correctement le rapport

Les quatre scores

PingCastle regroupe ses règles en quatre catégories, chacune notée de 0 (meilleur) à 100 :

Le score de risque du domaine est le plus élevé des quatre, pas leur somme. Un domaine à 15, 10, 0 et 85 obtient 85, car une seule mauvaise catégorie suffit à un attaquant. Cela signifie aussi que corriger Stale Objects ne change rien au score principal tant qu'Anomalies reste la pire catégorie.

Niveaux de maturité et identifiants de règles

Chaque règle possède un identifiant préfixé par sa catégorie (S-, P-, T-, A-), une valeur en points et un niveau de maturité de 1 à 5. Les constats de niveau 1 sont les plus critiques. La section maturité du rapport indique le niveau le plus bas auquel votre domaine échoue, ce qui constitue pour la direction un meilleur indicateur de progrès que le score brut. Passer du niveau 1 au niveau 3 est une vraie amélioration, même si le score bouge à peine.

Dépliez chaque règle dans le rapport HTML. Le détail liste les objets exacts concernés et renvoie à la documentation à l'origine de la règle. Travaillez toujours à partir de la liste d'objets, pas du titre de la règle.

Trier : transformer les constats en plan

Exportez les règles depuis le XML pour pouvoir les intégrer à un outil de suivi :

[xml]$hc = Get-Content .\ad_hc_corp.example.com.xml
$hc.SelectNodes('//HealthcheckRiskRule') |
  Select-Object RiskId, Category, Points, Rationale |
  Sort-Object Points -Descending |
  Export-Csv .\pingcastle-findings.csv -NoTypeInformation

Classez chaque constat dans l'une de quatre catégories :

1. À corriger cette semaine (chemin d'attaque vers le Tier 0). Tout ce qui offre à un non-administrateur une voie vers la prise de contrôle du domaine. Par exemple : délégation non contrainte sur des serveurs autres que les DC, ACE dangereuses sur des objets privilégiés, principaux non standard disposant de droits DCSync, mots de passe GPP, modèles AD CS vulnérables à ESC1 et service spouleur actif sur les DC. Ces constats correspondent directement aux droits DCSync, à la suppression de la délégation non contrainte et à l'audit des modèles de certificats.
2. Projets (nécessitent une gestion des changements). Les paramètres susceptibles de casser des applications : signature LDAP, restrictions NTLM, signature SMB, suppression de RC4, déploiement de LAPS. Attribuez à chacun un responsable, un groupe pilote et une phase d'audit avant l'application.
3. Hygiène (traitement par lots). Comptes inactifs, anciens objets ordinateur, mots de passe sans expiration sur des comptes qui ne sont pas des comptes de service. Automatisez ces tâches plutôt que de les corriger à la main.
4. Risque accepté. Une exception documentée avec un responsable métier, un contrôle compensatoire et une date de revue. PingCastle ne connaît pas vos exceptions : le registre vit dans votre outil de suivi.

Deux règles garantissent l'honnêteté du dispositif. D'abord, chaque élément de la catégorie 1 reçoit un responsable et une échéance sous quelques jours. Ensuite, les catégories Privileged Accounts et Trusts sont revérifiées à chaque exécution, car ce sont elles qui évoluent le plus vite et comptent le plus.

Rattachez chaque constat à la méthode du site : Mesurer (la liste d'objets du rapport), Auditer (activer la journalisation du paramètre avant de le modifier), Appliquer, Vérifier (l'exécution suivante de PingCastle). La checklist de durcissement propose un ordre par défaut si vous en avez besoin.

Présenter les résultats

La direction n'a pas besoin du rapport HTML. Elle a besoin de trois éléments sur une page : le niveau de maturité actuel et sa tendance, le nombre de constats de catégorie 1 ouverts avec leur ancienneté, et la liste des risques acceptés avec des responsables nommés. Reléguez le score brut en annexe, car il varie avec les modifications de règles et engage la mauvaise conversation.

Pour chaque domaine, affichez les scores de catégorie côte à côte. Une forêt dont le domaine racine est au niveau de maturité 3 mais dont un domaine enfant issu d'une acquisition est au niveau 1 est une forêt de niveau 1, car les approbations internes à une forêt n'arrêtent pas un attaquant. Dites-le explicitement, pour que le financement aille au domaine le plus faible plutôt qu'au plus visible.

Appliquer : planifier et suivre la tendance

Un rapport isolé n'est qu'un instantané. Planifiez le health check pour que toute dérive apparaisse dans la semaine :

$action  = New-ScheduledTaskAction -Execute 'C:\Tools\PingCastle\PingCastle.exe' `
  -Argument '--healthcheck --server corp.example.com' -WorkingDirectory 'D:\PingCastle\Reports'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 6am
Register-ScheduledTask -TaskName 'PingCastle weekly' -Action $action -Trigger $trigger `
  -User 'CORP\svc-pingcastle' -Password (Read-Host 'Password')

Mieux encore, utilisez un gMSA comme identité de la tâche afin qu'aucun mot de passe ne soit stocké. Conservez les fichiers XML, renommés avec la date, dans un dossier lisible uniquement par l'équipe sécurité. Mettez à jour PingCastle délibérément, pas automatiquement, et indiquez la version dans le nom de fichier de chaque rapport. Une modification de règle ne doit jamais être confondue avec une modification de votre domaine.

Vérifier

Après chaque sprint de remédiation, relancez l'outil et comparez les ensembles de règles plutôt que les scores :

[xml]$old = Get-Content .\2026-08-31_ad_hc_corp.example.com.xml
[xml]$new = Get-Content .\2026-09-28_ad_hc_corp.example.com.xml
$o = $old.SelectNodes('//HealthcheckRiskRule').RiskId
$n = $new.SelectNodes('//HealthcheckRiskRule').RiskId
Compare-Object $o $n | ForEach-Object {
  [pscustomobject]@{ RiskId = $_.InputObject; Change = if ($_.SideIndicator -eq '=>') {'NEW'} else {'FIXED'} }
}

Traitez chaque règle NEW dans Privileged Accounts ou Trusts comme un incident tant qu'elle n'est pas expliquée. Vérifiez qui a modifié quoi à l'aide des événements de groupe et d'approbation de la référence des ID d'événements. Pour les éléments corrigés, confirmez que la liste d'objets est vide, et pas seulement que la valeur en points est passée sous un seuil.

Ce que cela casse

L'exécution de PingCastle est en lecture seule, mais agir sur son rapport sans l'étape d'audit casse des choses :

• Appliquer directement les constats liés aux protocoles. Exiger la signature LDAP, désactiver NTLMv1 ou supprimer RC4 parce qu'un rapport l'a dit, sans phase d'audit, provoque des interruptions de service. Les vieilles appliances, les scanners et les applications Java tombent en premier.
• Désactiver en masse les comptes inactifs. L'« inactivité » repose sur lastLogonTimestamp, qui peut accuser jusqu'à 14 jours de retard, et certains comptes de service s'authentifient d'une manière qui ne le met pas à jour. Désactivez par lots, déplacez vers une UO de quarantaine, et ne supprimez qu'après un délai d'attente.
• Ajouter les administrateurs à Protected Users. Cela supprime NTLM, DES, RC4 et la délégation d'identifiants pour ces comptes. Testez le mode de travail de chaque administrateur avant une modification en masse.
• Les alertes des outils de sécurité. Le health check effectue de larges requêtes LDAP que Defender for Identity ou vos honeytokens peuvent signaler comme de la reconnaissance. Indiquez au SOC quel compte et quel hôte l'exécutent, et excluez-le délibérément des règles de leurres.

Pour aller plus loin : la thématique évaluation, sauvegarde et restauration couvre le reste de cette série, la gestion des chemins d'attaque trouve les voies vers le Tier 0 que les scanners à base de règles manquent, et protéger les sauvegardes AD contre les rançongiciels traite du contrôle que PingCastle ne peut pas vérifier pour vous.