Reporting et remédiation

Le rapport, livrable final de la mission

Dix chapitres de ce parcours ont suivi la logique d'un attaquant : cartographier, énumérer, casser des secrets Kerberos, se déplacer latéralement, escalader jusqu'au contrôle du domaine. Techniquement, cette chaîne d'actions constitue la mission. Commercialement et opérationnellement, elle n'en constitue que la matière première. Ce que le client paie, relit, archive et présente à sa direction, c'est le rapport — et c'est sur ce document que se joue, in fine, si le pentest a réellement amélioré la sécurité du domaine ou s'il a simplement produit une preuve de compétence technique sans suite concrète.

Ce constat n'est pas une posture. Les praticiens qui suivent leurs missions dans la durée observent régulièrement le même schéma : un rapport techniquement irréprochable, avec une compromission complète du domaine démontrée, dont une part significative des recommandations reste non appliquée un an plus tard — non par mauvaise volonté du client, mais parce que le rapport ne lui a jamais donné les moyens de prioriser, chiffrer et planifier la remédiation. Un pentester qui ignore cette réalité recommence, mission après mission, le même travail sur le même domaine, avec la même satisfaction technique et le même défaut d'impact.

Une liste de vulnérabilités, même correctement décrites, n'est pas un plan d'action. Un bon rapport de pentest AD raconte un chemin d'attaque cohérent, hiérarchise les correctifs par ce qu'ils cassent réellement dans ce chemin, et donne au client une séquence d'actions datée qu'il peut porter devant sa direction sans traduction supplémentaire.

Évaluer la sévérité : au-delà du score CVSS

Le réflexe le plus répandu consiste à coter chaque vulnérabilité avec un score CVSS et à s'arrêter là. Le CVSS a une utilité réelle — il normalise la communication entre organisations et permet des comparaisons — mais il a été conçu pour des vulnérabilités logicielles isolées, pas pour des chaînes d'abus de configuration propres à un annuaire Active Directory. Une délégation Kerberos non contrainte mal configurée n'a pas de CVE, et son score dépend entièrement du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire du domaine testé : elle peut être totalement inoffensive sur un domaine bien cloisonné, ou constituer le maillon décisif d'une compromission complète sur un autre.

Une méthode de cotation plus fiable en environnement AD combine trois facteurs distincts, évalués séparément avant d'être synthétisés :

• L'impact — que se passe-t-il si la faiblesse est exploitée avec succès ? Une distinction nette doit être maintenue entre un impact local (accès à un poste, lecture d'un partage) et un impact structurel (compromission du domaine, accès à Tier 0).
• L'exploitabilité observée — la faiblesse a-t-elle été effectivement exploitée pendant la mission, avec quel niveau de compétence requis et quels outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire ? Une faiblesse démontrée en pratique pèse plus lourd qu'une faiblesse identifiée uniquement par revue de configuration, même à impact théorique identique.
• L'exposition réelle — combien de comptes, de machines ou de chemins BloodHound sont concernés ? Une ACL GenericAll mal placée sur un compte isolé et sans lien avec un chemin vers Tier 0 n'a pas la même sévérité que la même ACL placée sur un compte qui ouvre, via BloodHound, un chemin direct vers Domain Admins.

Cette approche évite le travers inverse, tout aussi fréquent : la sur-cotation systématique de tout ce qui touche à Kerberos ou à Active Directory par réflexe, qui dilue la crédibilité du rapport aux yeux d'un client averti et rend impossible toute priorisation sérieuse — si tout est critique, rien ne l'est.

Un Kerberoasting réussi sur un compte de service svc-print avec un mot de passe cassé en quelques minutes est coté « élevé » sur un domaine A, où ce compte n'a que des droits sur une imprimante réseau. Le même finding, sur un domaine B où BloodHound révèle que ce compte est membre imbriqué d'un groupe disposant de droits WriteDacl sur l'OU des contrôleurs de domaine, est coté « critique » — l'exploitabilité technique est identique, mais l'exposition réelle transforme radicalement l'impact.

Documenter la preuve sans sur-exposer le client

Une découverte non documentée n'existe pas pour le lecteur du rapport, quelle que soit la certitude du pentester. Le standard de preuve attendu répond à trois exigences simultanées, souvent en tension les unes avec les autres.

Reproductibilité — la commande exacte, la cible précise et le résultat obtenu doivent permettre à l'équipe technique du client de rejouer la démonstration, ou au moins de vérifier la configuration en cause sans avoir à deviner ce qui a été fait. Une capture d'écran seule, sans la commande qui l'a produite, ne suffit pas.

Horodatage — chaque preuve doit être datée précisément. Cela sert deux objectifs : permettre au client de retrouver l'événement correspondant dans ses propres journaux s'il veut vérifier sa capacité de détection, et établir une traçabilité en cas de question sur un incident survenu pendant la fenêtre de test.

Minimisation — la preuve doit démontrer le risque sans l'aggraver ni exposer inutilement des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles. Kerberoaster un compte de service et casser son mot de passe hors ligne suffit à prouver la faiblesse ; il n'est pas nécessaire d'utiliser ensuite ce mot de passe pour se connecter à des systèmes tiers non couverts par la démonstration initiale, ni de conserver ce mot de passe en clair dans le rapport final. Le mot de passe cassé peut être mentionné comme preuve de faisabilité (par exemple sa complexité, ou le temps de cassage), sans être reproduit intégralement dans un document qui circulera ensuite entre plusieurs équipes internes du client.

Un rapport de pentest AD circule souvent plus largement que prévu — direction, RSSI, équipes IT, parfois assurance cyber. Y laisser des mots de passe en clair, des hashs NT non tronqués ou des captures d'écran de contenus de messagerie transforme le livrable lui-même en surface d'exposition. La règle pratique : tronquer les secrets (premiers caractères suivis de points de suspension), et fournir si nécessaire les preuves complètes dans une annexe séparée, chiffrée, à diffusiondiffusionIAFamille de modèles génératifs qui synthétisent une image (ou autre signal) en dénisant progressivement un bruit.Voir dans le glossaire restreinte.

Distinguer quick wins et remédiation structurelle

Toutes les recommandations n'ont pas le même coût de mise en œuvre, et confondre un correctif de cinq minutes avec un chantier de plusieurs mois dans une même liste plate décourage l'action. Deux catégories doivent être séparées explicitement dans le rapport.

Les quick wins partagent trois caractéristiques : ils se déploient sans changement d'architecture, sans risque de régression significatif, et en quelques heures à quelques jours. Retirer un droit GenericAll orphelin laissé par un projet terminé, réinitialiser le mot de passe d'un compte de service compromis, purger une appartenance à un groupe à privilèges qui n'a plus lieu d'être, ou nettoyer l'objet AdminSDHolder d'ACL indésirables entrent dans cette catégorie. Leur intérêt principal, au-delà de la réduction immédiate du risque, est de démontrer au client qu'agir sur les conclusions du rapport est concrètement possible et rapide — ce qui entretient l'élan vers les chantiers plus lourds qui suivent.

Les chantiers structurels, à l'inverse, demandent une planification : déployer LAPS sur l'ensemble du parc, mettre en place un modèle de tiering d'administration, refondre les délégations Kerberos historiques, ou réorganiser les groupes à privilèges hérités de plusieurs années d'administration sans gouvernance. Ces actions touchent souvent plusieurs équipes (infrastructure, support, parfois métier pour les applications legacy dépendantes de NTLM), nécessitent des tests de non-régression, et ne peuvent raisonnablement pas être présentées avec le même horizon temporel qu'un quick win.

Un rapport qui commence par le chemin d'attaque complet vers Domain Admins, avant de donner au client la liste des trois correctifs immédiats qui coupent l'essentiel du risque à court terme, retarde l'action de plusieurs semaines. Placer les quick wins tôt dans le document, avec leur effet estimé sur le chemin d'attaque démontré, permet au client d'agir dès la lecture, avant même la réunion de restitution.

Construire une roadmap 30/90 jours défendable

Une fois la sévérité établie et les quick wins séparés des chantiers structurels, le rapport doit se conclure par une séquence datée plutôt que par une liste non ordonnée. La roadmap 30/90 jours est un format éprouvé, suffisamment court pour rester crédible auprès d'une direction, suffisamment long pour couvrir un chantier structurel raisonnable.

La fenêtre immédiate (avant J+30) regroupe les quick wins et toute mesure qui coupe directement le chemin d'attaque démontré dans le rapport — typiquement la rotation d'un secret exposé ou la suppression d'un droit d'ACL critique identifié comme maillon du chemin vers Domain Admins.

La fenêtre J+30 couvre les correctifs qui demandent une planification légère mais restent réalisables sans refonte : déploiement de LAPS sur les serveurs les plus exposés, correction des délégations Kerberos identifiées, activationfonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire d'une politique d'audit adaptée sur les contrôleurs de domaine.

La fenêtre J+90 couvre les chantiers qui touchent l'organisation elle-même : mise en place effective du tiering d'administration, revue exhaustive des groupes à privilèges, migration des applications encore dépendantes de NTLM.

Une dernière ligne, continue, couvre la gouvernance qui doit survivre au rapport lui-même : revue périodique des groupes à privilèges, surveillance des nouvelles délégations créées, et surtout un re-test ciblé des correctifs appliqués — sans lequel le client n'a aucune garantie que la remédiation déclarée a effectivement neutralisé le chemin d'attaque démontré.

Les dates 30/90 jours ne sont pas des engagements contractuels du pentester envers le client : ce sont des repères qui permettent à l'équipe IT de négocier des ressources et un calendrier réaliste avec sa propre direction. Un client qui ne peut objectivement pas déployer LAPS en 30 jours faute d'équipe disponible ne doit pas être pénalisé dans le rapport pour ce délai ; en revanche, le rapport doit clairement indiquer le niveau de risque maintenu tant que le correctif n'est pas appliqué.

Écrire pour deux lecteurs à la fois

Un rapport de pentest AD a structurellement deux publics, et un seul document doit servir les deux sans que l'un nuise à l'autre.

Le résumé exécutif, généralement deux à trois pages, s'adresse à un lecteur qui ne lira rien d'autre : direction générale, RSSI pressé, parfois assureur cyber. Il doit répondre à trois questions en langage non technique : qu'avons-nous démontré, quel est le risque métier concret, et que faut-il faire en priorité. Aucun acronyme sans définition, aucune commande, aucune capture d'écran technique.

Le corps technique s'adresse aux équipes qui vont effectivement appliquer la remédiation. Il assume la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire technique complète : commandes, Event ID, chemins BloodHound, extraits de configuration GPO. C'est ici que vivent la cotation détaillée de sévérité et le standard de preuve décrits plus haut.

Le lien entre les deux n'est pas seulement stylistique : chaque affirmation du résumé exécutif doit être traçable vers une section précise du corps technique, et chaque finding technique doit pouvoir se résumer en une phrase compréhensible sans jargon. Un rapport qui échoue ce test — où le résumé exécutif énonce des généralités déconnectées des findings réels, ou où le corps technique ne se laisse résumer par aucune phrase simple — perd en crédibilité des deux côtés.

Pièges de rédaction qui décrédibilisent un rapport

À contenu technique strictement identique, la manière dont un rapport est écrit change fortement la probabilité qu'il soit suivi d'effet.

• Sévérité gonflée par réflexe — coter « critique » une faiblesse à faible exposition use la crédibilité de la cotation pour les findings réellement critiques du même rapport.
• Recommandations génériques copiées-collées — une ligne « appliquer le principe du moindre privilège » sans lien explicite avec le finding décrit ne dit rien d'actionnable au lecteur.
• Absence de preuve reproductible — une affirmation non étayée par une commande, un horodatage et un résultat observable place le client en position de devoir croire sur parole, ce qui affaiblit sa capacité à convaincre en interne.
• Recommandations non chiffrées en effort — sans indication de charge (quelques heures, quelques jours, un chantier trimestriel), le client ne peut pas arbitrer entre plusieurs findings à traiter avec des ressources limitées.
• Absence de re-test proposé — un rapport qui s'arrête à la remise du document, sans mention d'une vérification ultérieure, laisse le client sans moyen objectif de savoir si sa remédiation a fonctionné.

Ce qu'il faut retenir

La valeur d'un pentest Active Directory ne se mesure pas à la sophistication de la chaîne d'attaque démontrée, mais à ce que le client en fait ensuite. Une cotation de sévérité qui intègre l'exposition réelle du domaine, un standard de preuve reproductible et minimisé, une séparation nette entre quick wins et chantiers structurels, et une roadmap datée qui reste négociable plutôt que prophétique : ce sont ces éléments, plus que la technique offensive elle-même, qui déterminent si le rapport change durablement la posture de sécurité du client. Le chapitre suivant conclut ce parcours par un atelier de synthèse qui reprend l'ensemble de la kill chain, de la reconnaissance au rapport, sur un scénario complet.