Pentest réseau : méthodologie, vulnérabilités et techniques d’exploitation en boite noire et grise

La compromission initiale d’un poste de travail, d’un compte utilisateur ou d’un service exposé sur Internet ne constitue généralement que la première étape d’une cyberattaque. Une fois ce premier accès obtenu, l’objectif d’un attaquant est souvent d’étendre progressivement son niveau de contrôle sur le système d’information : identifier les ressources accessibles, récupérer de nouveaux identifiants, élever ses privilèges, se déplacer latéralement entre les systèmes et atteindre des actifs critiques.

Dans les environnements d’entreprise, cette progression peut s’appuyer sur des services insuffisamment sécurisés, des défauts de segmentation, des mots de passe faibles ou réutilisés, des droits excessifs, des protocoles d’authentification hérités ou encore des erreurs de configuration d’Active Directory. Plusieurs faiblesses considérées individuellement comme modérées peuvent ainsi former un chemin d’attaque conduisant à la compromission d’un serveur d’administration, d’une infrastructure de sauvegarde ou, dans le cas d’un environnement Active Directory, à l’obtention de privilèges très élevés sur le domaine.

Un pentest réseau vise précisément à reproduire ces scénarios dans un cadre contrôlé afin de déterminer jusqu’où un attaquant pourrait progresser à partir d’un point donné. Contrairement à une simple analyse de vulnérabilités, il ne consiste donc pas seulement à recenser des services obsolètes, des ports ouverts ou des configurations dangereuses. Le pentester cherche à vérifier si les faiblesses sont réellement exploitables, à comprendre les relations entre les systèmes et à mesurer l’impact d’une compromission dans l’architecture étudiée.

Selon les objectifs, l’audit peut être réalisé depuis Internet, depuis le réseau interne sans aucun identifiant, à partir d’un compte utilisateur standard ou encore avec un niveau d’information plus important sur l’infrastructure. Chaque approche simule un scénario différent et permet d’évaluer des étapes distinctes de la chaîne d’attaque.

Dans cet article, nous détaillons le fonctionnement d’un pentest réseau, les différentes approches possibles, les composants généralement intégrés au périmètre, la méthodologie suivie par les auditeurs, et les faiblesses fréquemment rencontrées. Nous revenons également sur des scénarios d’exploitation caractéristiques des environnements Windows et Active Directory, ainsi que sur des surfaces d’attaque plus avancées comme les relations de confiance, AD CS, les comptes de service, Microsoft Configuration Manager, SQL Server, les mécanismes IPv6 ou les infrastructures hybrides Active Directory et Microsoft Entra ID.

Guide complet sur le pentest réseau

Qu’est-ce qu’un pentest réseau ?

Définition d’un pentest réseau

Un pentest réseau est une évaluation de sécurité offensive visant à tester la résistance d’une infrastructure face à des scénarios d’attaque réalistes. Le principe consiste à adopter le point de vue d’un attaquant et à rechercher les faiblesses susceptibles de lui permettre d’obtenir un accès non autorisé à des systèmes, d’élever ses privilèges ou de progresser vers des ressources sensibles.

Le périmètre peut comprendre des serveurs Windows ou Linux, des postes de travail, des équipements réseau, des pare-feu, des passerelles VPN, des services d’administration, des bases de données, des environnements Active Directory, des infrastructures Wi-Fi ou certains composants cloud et hybrides. Le niveau de profondeur dépend du contexte, du scénario retenu et des autorisations définies avant l’audit.

L’objectif n’est pas uniquement de déterminer si une vulnérabilité existe. Il s’agit également de vérifier si elle est réellement exploitable dans l’environnement étudié et, surtout, ce qu’un attaquant pourrait accomplir après son exploitation. Une vulnérabilité permettant de compromettre un poste utilisateur isolé ne présente par exemple pas le même niveau de risque si ce poste est fortement cloisonné ou s’il permet au contraire de communiquer directement avec des serveurs d’administration, une infrastructure de sauvegarde ou des contrôleurs de domaine.

Cette notion de chemin d’attaque est centrale. Une faiblesse apparemment modérée peut devenir critique lorsqu’elle est associée à d’autres mauvaises configurations. Un compte utilisateur compromis peut par exemple donner accès à un partage contenant un secret ; ce secret peut permettre de prendre le contrôle d’un serveur ; les privilèges présents sur ce serveur peuvent ensuite ouvrir un chemin vers une identité plus sensible. Le pentest permet précisément d’identifier et, lorsque les règles de la mission l’autorisent, de valider ces enchaînements.

Quels sont les objectifs d’un pentest réseau ?

Les objectifs exacts dépendent du périmètre, mais un pentest réseau vise généralement à répondre à une question simple : que pourrait réellement accomplir un attaquant disposant du niveau d’accès que nous lui attribuons au début du test ?

L’audit permet d’évaluer l’exposition des services, la robustesse des mécanismes d’authentification, la sécurité des identités, la segmentation du réseau, les possibilités d’élévation de privilèges et les mécanismes susceptibles de faciliter les mouvements latéraux. Dans un environnement Active Directory, il permet aussi d’identifier les permissions, délégations et relations de confiance pouvant former un chemin vers des comptes ou systèmes privilégiés.

Il peut également servir à mesurer les conséquences d’une compromission déjà supposée. Une organisation peut disposer d’un niveau de sécurité périmétrique élevé et rester fortement exposée si la compromission d’un seul poste interne permet ensuite d’atteindre rapidement une grande partie du système d’information. Le pentest interne apporte donc une réponse concrète à la capacité de l’organisation à contenir une intrusion.

Au-delà de l’identification des vulnérabilités, les résultats permettent de prioriser les corrections en fonction de leur impact réel. Une faiblesse moyenne située sur un chemin vers un actif critique peut être plus importante à corriger qu’une vulnérabilité théoriquement plus sévère mais isolée et difficilement exploitable.

Pentest réseau et scan de vulnérabilités : quelles différences ?

Un scanner de vulnérabilités peut identifier rapidement un grand nombre de faiblesses potentielles : versions logicielles obsolètes, correctifs manquants, ports ouverts, configurations TLS insuffisantes ou signatures correspondant à des vulnérabilités connues. Ces informations sont utiles, mais elles ne permettent pas toujours de déterminer si une vulnérabilité est réellement exploitable dans le contexte observé.

Un pentest ajoute une couche essentielle d’analyse humaine. Le pentester confronte les résultats des outils automatisés à la réalité de l’environnement, élimine les faux positifs, recherche des problèmes de configuration qui ne correspondent pas nécessairement à une CVE et tente de combiner plusieurs faiblesses afin de mesurer leur impact réel.

Dans Active Directory, les risques les plus importants ne correspondent d’ailleurs pas toujours à des vulnérabilités logicielles traditionnelles. Un droit GenericAll attribué au mauvais utilisateur, un compte de service fortement privilégié protégé par un secret faible, une GPO modifiable par un groupe non privilégié ou une mauvaise configuration d’AD CS peuvent permettre une compromission majeure alors qu’aucun logiciel vulnérable n’est présent. C’est précisément ce type de risque qu’un pentest authentifié permet d’identifier.

Pentest réseau interne et externe : quelles différences ?

Les pentests réseau peuvent être regroupés en deux grandes catégories : les audits externes et les audits internes. Les deux approches sont complémentaires, car elles correspondent à des étapes différentes d’une attaque.

Pentest réseau externe

Un pentest réseau externe est réalisé depuis Internet et simule généralement le comportement d’un attaquant ne disposant d’aucun accès préalable au système d’information. Le périmètre comprend les actifs exposés publiquement : adresses IP, passerelles VPN, équipements de sécurité, services d’administration à distance, serveurs de messagerie, services DNS ou autres composants accessibles depuis Internet et inclus dans le périmètre.

L’objectif consiste à déterminer si un attaquant externe peut identifier un service vulnérable, exploiter une mauvaise configuration, contourner un mécanisme d’authentification ou obtenir un premier accès au système d’information. Une attention particulière est portée aux technologies permettant l’accès distant, car la compromission d’un VPN, d’une passerelle de télémaintenance ou d’une interface d’administration peut transformer une attaque externe en scénario de compromission interne.

Un pentest externe ne doit donc pas se limiter à l’énumération des services. Il cherche à comprendre la fonction des actifs exposés, leur niveau de protection et les possibilités de pivot offertes par une éventuelle compromission.

Pentest réseau interne

Le pentest interne commence au contraire depuis le réseau de l’organisation. Il simule notamment la situation d’un attaquant ayant compromis un poste de travail par phishing, connecté un équipement au réseau, obtenu un accès Wi-Fi ou déjà récupéré des identifiants.

La problématique n’est alors plus uniquement celle de l’accès initial. Le pentester cherche à déterminer ce que cet accès permet de découvrir et jusqu’où il peut progresser dans l’infrastructure. Les tests portent donc davantage sur l’énumération des ressources internes, l’authentification, les privilèges, Active Directory, la récupération d’identifiants, les relations de confiance, les protocoles d’administration et les possibilités de mouvement latéral.

Ces scénarios sont essentiels pour évaluer la capacité de l’organisation à contenir une compromission. Une infrastructure correctement segmentée et disposant d’une gestion rigoureuse des privilèges doit empêcher qu’un poste utilisateur compromis devienne immédiatement un point d’accès à l’ensemble du système d’information.

Quel est le périmètre d’un pentest réseau ?

Le périmètre d’un pentest réseau doit refléter les dépendances réelles entre les systèmes. Les infrastructures modernes sont rarement composées de segments indépendants : identités, applications, services d’administration, réseaux Wi-Fi, plateformes de virtualisation, sauvegardes et composants cloud sont souvent étroitement interconnectés.

Infrastructure réseau et segmentation

L’analyse de l’infrastructure commence généralement par l’identification des systèmes joignables et des flux autorisés entre les différentes zones. Les pentesters cherchent à comprendre comment les réseaux sont segmentés et si cette segmentation correspond réellement aux objectifs de sécurité définis.

Une architecture peut sembler segmentée sur le papier tout en autorisant, dans les faits, des communications beaucoup trop larges. Un poste utilisateur ne devrait par exemple pas nécessairement pouvoir communiquer directement avec les interfaces d’administration des hyperviseurs, les serveurs de sauvegarde ou certains équipements critiques. La découverte de tels flux peut créer des chemins de mouvement latéral importants après la compromission d’un poste.

Environnements Active Directory

Active Directory constitue souvent l’un des composants les plus importants d’un pentest interne Windows. Il centralise l’identité, l’authentification, les appartenances aux groupes, les stratégies de sécurité et de nombreuses permissions utilisées dans l’ensemble de l’infrastructure.

L’audit ne se limite donc pas à rechercher des vulnérabilités sur les contrôleurs de domaine. Il s’intéresse également aux comptes, aux groupes, aux délégations, aux ACL, aux GPO, aux comptes de service, aux relations de confiance, aux services de certificats et aux différentes relations susceptibles de créer des chemins d’élévation de privilèges.

Serveurs et postes de travail

Les serveurs et postes constituent à la fois des cibles et des points de pivot potentiels. Les tests portent notamment sur les systèmes obsolètes, les services exposés, les configurations locales, les privilèges utilisateurs, les logiciels installés et les possibilités d’accès à distance.

Les pentesters cherchent également à déterminer si la compromission d’un système permet d’obtenir de nouvelles informations d’authentification ou d’accéder à d’autres ressources. La réutilisation d’un même compte administrateur local sur plusieurs machines représente par exemple un risque important : la compromission d’un seul système peut alors faciliter l’accès à plusieurs autres machines.

Équipements réseau, pare-feu et passerelles VPN

Routeurs, commutateurs, pare-feu, concentrateurs VPN et autres équipements d’infrastructure jouent un rôle majeur dans la sécurité du réseau. Une interface d’administration accessible depuis un réseau utilisateur, des identifiants par défaut, une version logicielle obsolète ou des règles trop permissives peuvent permettre à un attaquant de contourner une partie importante des mécanismes de sécurité.

L’audit cherche donc à vérifier non seulement les vulnérabilités des équipements, mais également leur exposition et les restrictions appliquées à leur administration. La séparation des plans utilisateur et d’administration est particulièrement importante pour réduire l’impact d’une compromission interne.

Infrastructures Wi-Fi

Lorsque le Wi-Fi entre dans le périmètre, les auditeurs analysent les mécanismes d’authentification et de chiffrement, la séparation entre réseaux invités et internes ainsi que les possibilités d’accès aux ressources de l’entreprise après connexion au réseau sans fil.

Dans certaines infrastructures, un Wi-Fi invité correctement isolé présente peu de risques pour le système d’information interne. Dans d’autres, une segmentation insuffisante peut permettre à un utilisateur connecté à un réseau supposé non fiable d’atteindre des services internes sensibles. Les architectures utilisant 802.1X ou des mécanismes d’authentification d’entreprise doivent également être analysées selon le scénario autorisé.

Environnements cloud et hybrides

Les infrastructures modernes combinent souvent Active Directory on-premise, Microsoft Entra ID, Microsoft 365 et différents services cloud. Le pentest réseau doit alors tenir compte des interactions entre ces environnements.

Une faiblesse affectant une identité synchronisée, un serveur d’administration hybride ou une infrastructure de fédération peut créer un chemin d’attaque dépassant largement le réseau local. Selon les objectifs, une partie de ces composants peut toutefois relever d’un pentest cloud ou d’un audit Microsoft 365 spécifique plutôt que du pentest réseau à proprement parler. Le périmètre doit donc être clairement défini.

Services et applications métier critiques

Les réseaux internes hébergent également des ressources à forte valeur : serveurs de fichiers, bases de données, ERP, solutions de sauvegarde, outils de supervision, plateformes de virtualisation ou outils d’administration centralisée.

Ces systèmes sont particulièrement intéressants pour un attaquant. La compromission d’un serveur de sauvegarde peut considérablement augmenter l’impact d’un ransomware, tandis que l’accès à une plateforme de virtualisation peut permettre de contrôler plusieurs machines depuis une interface unique. Le pentest doit donc étudier non seulement les vulnérabilités techniques mais également la place de ces composants dans l’architecture globale.

Quelle méthodologie pour réaliser un pentest réseau ?

Un pentest réseau suit généralement plusieurs grandes phases. Celles-ci ne sont pas strictement linéaires : les informations obtenues au cours de l’exploitation peuvent nécessiter de revenir à une phase d’énumération ou de rechercher de nouveaux chemins d’attaque.

Reconnaissance et découverte du réseau

La première étape consiste à comprendre l’environnement accessible depuis le point de départ du test. Les auditeurs identifient les systèmes joignables, les sous-réseaux accessibles, les ports ouverts et les principaux services exposés.

La découverte peut également permettre d’identifier des contrôleurs de domaine, serveurs DNS, passerelles, équipements réseau, interfaces d’administration ou systèmes particulièrement intéressants. L’objectif n’est pas de scanner aveuglément toutes les adresses disponibles. Les résultats doivent être analysés afin de comprendre la fonction probable de chaque système et de prioriser les investigations.

Énumération des services

Une fois les hôtes identifiés, les services accessibles sont analysés plus précisément. Il s’agit notamment de déterminer la technologie utilisée, sa version lorsque cela est possible, les mécanismes d’authentification proposés et les informations accessibles avant authentification.

Cette étape est essentielle, car un port ouvert ne constitue pas en soi une vulnérabilité. Le risque dépend de ce qui est réellement exposé derrière ce port, de sa configuration, du niveau d’accès nécessaire et de la place du système dans l’infrastructure.

Analyse des vulnérabilités et des mauvaises configurations

L’auditeur recherche ensuite les faiblesses exploitables. Cette phase combine généralement des outils automatisés avec une analyse manuelle. Les scanners permettent d’accélérer l’identification de certaines vulnérabilités connues, mais une grande partie des problèmes réellement importants nécessite une compréhension du contexte.

Dans Active Directory, les permissions excessives, les comptes de service, les délégations ou certaines configurations de certificats ne peuvent par exemple pas être correctement évalués uniquement à partir d’un scan réseau traditionnel. Les pentesters doivent corréler les informations provenant de plusieurs sources afin d’identifier les chemins d’attaque potentiels.

Exploitation contrôlée

L’exploitation permet de déterminer si une faiblesse identifiée peut réellement être utilisée par un attaquant. Le but n’est pas d’exploiter toutes les vulnérabilités disponibles. Les pentesters privilégient généralement les actions permettant de valider le risque, d’étendre le scénario d’attaque ou de démontrer l’impact d’une faiblesse.

Toutes les actions doivent rester compatibles avec les Rules of Engagement définies avant la mission. Lorsqu’une preuve moins intrusive suffit à démontrer le risque, elle est généralement préférable à une exploitation susceptible d’affecter la disponibilité ou l’intégrité du système.

Élévation de privilèges

Après l’obtention d’un premier accès, le pentester cherche à déterminer si des privilèges supplémentaires peuvent être obtenus. L’élévation peut être locale, par exemple d’un utilisateur standard vers un administrateur sur une machine, ou concerner l’environnement Active Directory.

Elle peut résulter d’une vulnérabilité locale, d’une configuration de service dangereuse, d’une permission excessive, de credentials récupérés sur le système ou d’une relation de confiance mal maîtrisée. Dans les environnements modernes, les chemins de privilèges sont souvent davantage liés à la configuration des identités qu’à l’exploitation d’une vulnérabilité de type exécution de code.

Récupération et réutilisation d’informations d’authentification

Les identifiants représentent fréquemment l’un des principaux moyens de progression dans un réseau. Un poste ou serveur compromis peut contenir des mots de passe, des hashes, des tickets Kerberos, des clés, des certificats ou d’autres secrets utilisables pour accéder à de nouvelles ressources.

Le pentester cherche donc à comprendre non seulement si ces informations sont accessibles, mais également si elles sont réutilisables ailleurs. C’est notamment pourquoi la séparation des comptes administratifs et la limitation de leurs connexions sur les postes utilisateurs sont essentielles.

Mouvement latéral

Le mouvement latéral correspond au passage d’un système compromis à d’autres ressources du réseau. Il peut s’appuyer sur des protocoles légitimes comme SMB, WinRM, RDP ou SSH, sur des interfaces d’administration, sur des comptes partagés ou sur des relations de confiance.

Cette phase permet d’évaluer concrètement la capacité de l’organisation à contenir une compromission. Une segmentation efficace doit limiter fortement les ressources accessibles depuis un poste utilisateur compromis, même si l’attaquant dispose déjà d’identifiants valides.

Post-exploitation et validation de l’impact

Lorsque des privilèges importants ont été obtenus, l’objectif consiste à déterminer l’impact réel de la compromission sans provoquer de dommage inutile. Les pentesters peuvent notamment vérifier si l’accès permettrait d’atteindre des données sensibles, des serveurs critiques, une infrastructure de sauvegarde, des consoles d’administration ou des ressources permettant d’établir une persistance.

Cette phase sert également à mesurer les capacités de détection et de réaction lorsque cela fait partie des objectifs de la mission. L’objectif reste cependant la démonstration du risque et non la reproduction de toutes les actions qu’un attaquant malveillant pourrait effectuer.

Reporting et accompagnement à la remédiation

La dernière phase consiste à documenter les vulnérabilités, les preuves obtenues, les chemins d’attaque et leurs impacts. Un bon rapport ne présente pas chaque constat de manière isolée : il explique comment les faiblesses se combinent et quelles corrections permettent de casser les chaînes de compromission.

La remédiation doit être priorisée en fonction du risque réel et des dépendances entre les vulnérabilités. Corriger une faiblesse structurante peut parfois supprimer plusieurs scénarios d’attaque sans nécessiter de traiter immédiatement chaque problème secondaire.

Quels outils sont utilisés lors d’un pentest réseau ?

Les outils facilitent la découverte, l’énumération et la validation des vulnérabilités, mais ils ne remplacent pas l’analyse du pentester. La valeur d’un audit repose surtout sur la capacité à interpréter les informations collectées et à comprendre comment différentes faiblesses peuvent être combinées.

Nmap et les outils de découverte réseau

Nmap reste une référence pour découvrir des hôtes, identifier les ports accessibles et caractériser les services exposés. Sa détection de versions permet d’interroger les ports ouverts afin de déterminer les protocoles et logiciels réellement présents derrière ceux-ci.

Dans de très grands périmètres, d’autres outils de scan peuvent être utilisés pour accélérer certaines phases de découverte avant de réaliser une analyse plus précise. L’intérêt du pentester ne réside cependant pas dans la quantité de ports détectés, mais dans sa capacité à comprendre ce que leur exposition signifie.

Scanners de vulnérabilités

Des outils comme Nessus ou Greenbone/OpenVAS peuvent aider à identifier rapidement des versions vulnérables, des correctifs manquants ou certaines mauvaises configurations. Leur résultat constitue néanmoins un point de départ.

Chaque vulnérabilité importante doit être analysée dans son contexte et, lorsque cela est possible et autorisé, validée manuellement. Les résultats automatisés peuvent contenir des faux positifs, mais surtout manquer des problèmes de permissions, de logique d’administration ou de relations de confiance qui constituent pourtant les chemins d’attaque les plus importants.

NetExec

NetExec est particulièrement utilisé dans les environnements Windows et Active Directory pour centraliser différentes opérations d’énumération et de validation sur des protocoles comme SMB, LDAP ou MSSQL. Il est notamment utile pour déterminer sur quels systèmes un compte donné fonctionne, identifier certains droits ou configurations et faciliter l’analyse d’un grand nombre de machines.

Comme pour tout framework d’automatisation, ses résultats doivent être interprétés avec prudence. L’objectif n’est pas de lancer systématiquement toutes les fonctionnalités disponibles contre l’ensemble du réseau, mais de répondre à des hypothèses précises dans le scénario d’audit.

Impacket

Impacket fournit des implémentations et des outils autour de nombreux protocoles utilisés dans les environnements Windows, notamment SMB, MSRPC, NTLM, Kerberos, LDAP et MSSQL. Il est très utilisé lors des phases d’énumération, d’authentification, de relay ou de mouvement latéral.

Sa richesse illustre également un point important : de nombreuses techniques offensives ne reposent pas sur l’exploitation d’une vulnérabilité logicielle mais sur l’utilisation détournée de protocoles et mécanismes légitimes lorsque les protections associées sont insuffisantes.

Responder

Responder est notamment utilisé pour analyser et exploiter certains mécanismes de résolution de noms présents dans les réseaux Windows. Il peut répondre à des requêtes LLMNR, NBT-NS ou mDNS et provoquer des tentatives d’authentification vers le système contrôlé par le pentester.

Selon le contexte, ces authentifications peuvent ensuite être analysées, attaquées hors ligne ou relayées vers d’autres services lorsque les protections nécessaires ne sont pas activées. L’utilisation de cet outil doit être encadrée, notamment sur les réseaux sensibles, afin d’éviter des effets de bord sur les mécanismes de résolution de noms.

BloodHound et SharpHound

BloodHound représente les relations entre les objets et privilèges Active Directory sous forme de graphe. L’objectif n’est pas simplement d’identifier les membres de Domain Admins, mais de découvrir les chemins indirects permettant à un utilisateur moins privilégié de prendre progressivement le contrôle d’objets plus sensibles.

SharpHound est couramment utilisé pour collecter les données nécessaires à cette analyse dans les environnements Active Directory. Les résultats doivent ensuite être interprétés et validés, car la présence d’un chemin théorique ne signifie pas toujours qu’il est exploitable dans le contexte exact de la mission.

Certipy et Certify

Certipy et Certify sont spécialisés dans l’analyse des environnements Active Directory Certificate Services. Ils permettent d’identifier les autorités de certification, les modèles de certificats et différentes configurations susceptibles de créer des chemins d’élévation de privilèges.

Les connaissances autour des attaques AD CS ont considérablement progressé depuis les premières recherches publiques. La nomenclature couramment utilisée couvre aujourd’hui de nombreux scénarios ESC, ce qui justifie une analyse spécifique des templates, des permissions d’enrôlement, des services web et de la configuration des autorités de certification.

Rubeus

Rubeus est principalement utilisé pour analyser et manipuler les mécanismes Kerberos dans un contexte Active Directory. Il peut notamment être utile pour étudier les tickets, les comptes de service et différentes configurations de délégation.

L’intérêt du pentest ne consiste pas simplement à exécuter l’outil, mais à comprendre dans quelles conditions une configuration Kerberos crée réellement un chemin d’attaque et quelles identités ou ressources sont concernées.

Wireshark et tcpdump

L’observation du trafic reste particulièrement utile lors des audits réseau. Wireshark et tcpdump peuvent permettre d’identifier des protocoles non chiffrés, des communications inattendues, des mécanismes d’authentification ou des flux qui ne devraient pas être accessibles depuis la zone où se trouve l’auditeur.

Ces outils sont également précieux pour comprendre le comportement réel d’un protocole lors de l’analyse d’un scénario complexe, plutôt que de déduire son fonctionnement à partir d’une simple configuration déclarative.

Quelles vulnérabilités sont fréquemment identifiées lors d’un pentest réseau ?

Les vulnérabilités rencontrées varient fortement selon les infrastructures. Certaines catégories reviennent néanmoins régulièrement et constituent souvent les premiers maillons de chemins d’attaque plus complexes.

Politiques de mots de passe insuffisantes

Des mots de passe faibles ou prévisibles peuvent permettre la compromission de comptes malgré l’absence de vulnérabilité technique sur les systèmes. Dans un environnement disposant de nombreux utilisateurs, le password spraying consiste par exemple à tester un nombre très limité de mots de passe probables sur plusieurs comptes plutôt qu’un grand nombre de mots de passe sur un seul utilisateur.

Cette approche cherche notamment à limiter le risque de déclencher les mécanismes de verrouillage. Elle doit être strictement encadrée pendant un pentest. La présence de MFA réduit considérablement l’impact de la compromission d’un mot de passe sur les services compatibles, mais ne dispense pas d’une politique d’authentification robuste sur l’ensemble de l’environnement.

Systèmes et services non corrigés

Les composants obsolètes restent une source importante de compromission. Le risque est particulièrement élevé lorsqu’une vulnérabilité permet une exécution de code ou un contournement d’authentification sans disposer préalablement d’un compte.

Il est fréquent que les systèmes les plus exposés ne soient pas les serveurs principaux, mais d’anciens équipements, des applications oubliées ou des systèmes maintenus pour des raisons de compatibilité. Un attaquant ne cherche pas nécessairement le système le plus important : il cherche souvent le point d’entrée le plus simple permettant ensuite de progresser.

Configurations SMB insuffisamment sécurisées

SMB occupe une place centrale dans de nombreux environnements Windows. Les risques peuvent notamment concerner des partages trop permissifs, des accès anonymes, des secrets présents dans des fichiers ou certaines configurations permettant des attaques de relay.

Historiquement, l’absence d’obligation de signature SMB sur de nombreux systèmes constituait une condition importante pour certains scénarios de relay NTLM. Ce point doit toutefois être évalué en fonction des versions et configurations réellement présentes. Windows 11 24H2 et Windows Server 2025 introduisent notamment des exigences de signature plus strictes par défaut.

Le pentester ne doit donc pas partir du principe que tout environnement Windows est uniformément exposé au relay SMB. Il doit identifier précisément les systèmes qui acceptent encore une authentification dans des conditions permettant ce scénario et tenir compte des éventuels équipements ou versions plus anciennes.

Mécanismes de résolution de noms hérités

Dans certains environnements Windows, des mécanismes comme LLMNR ou NBT-NS peuvent être utilisés lorsqu’une résolution DNS échoue. Un attaquant présent sur le même réseau peut tenter de répondre à certaines de ces requêtes en se faisant passer pour le système recherché.

La victime peut alors initier une authentification vers le système contrôlé par l’attaquant. L’impact dépend ensuite de nombreux facteurs : type d’authentification, robustesse du mot de passe, protections contre le relay, configuration des services ciblés et capacité de l’attaquant à provoquer ou attendre une authentification intéressante.

Protocoles non chiffrés et mécanismes d’authentification hérités

Telnet, FTP, HTTP interne ou certains protocoles historiques peuvent encore transmettre des données sensibles sans protection suffisante. NTLM reste également présent dans de nombreux environnements pour des raisons de compatibilité.

Le problème n’est pas nécessairement l’existence d’un protocole, mais les conditions dans lesquelles il peut être utilisé. Des protections complémentaires telles que la signature SMB, la signature LDAP, le channel binding ou Extended Protection for Authentication permettent par exemple de réduire certains scénarios de relay. Les versions récentes de Windows et Windows Server renforcent progressivement plusieurs de ces paramètres par défaut, mais les environnements existants doivent être vérifiés explicitement.

Permissions Active Directory excessives

L’une des catégories les plus importantes concerne les permissions attribuées aux objets Active Directory. Un utilisateur peut parfois disposer d’un droit lui permettant de modifier un groupe, de réinitialiser le mot de passe d’un autre compte, de modifier certaines propriétés ou de prendre indirectement le contrôle d’un objet plus privilégié.

Des droits comme GenericAll, GenericWrite, WriteDACL ou WriteOwner peuvent ainsi devenir extrêmement importants selon l’objet sur lequel ils s’appliquent. L’analyse doit également tenir compte des groupes imbriqués et des délégations successives. Un compte standard peut n’avoir aucun contrôle direct sur un administrateur tout en disposant d’un chemin indirect lui permettant, après plusieurs étapes, d’atteindre un groupe privilégié.

Configurations Kerberos dangereuses

Kerberos intègre plusieurs mécanismes pouvant devenir exploitables lorsqu’ils sont associés à des configurations insuffisamment sécurisées. Les comptes de service disposant d’un SPN peuvent notamment être ciblés par Kerberoasting. Certains comptes configurés sans préauthentification peuvent être exposés à l’AS-REP Roasting.

Certaines configurations de délégation peuvent également permettre à un attaquant ayant compromis un système ou un compte particulier d’usurper l’identité d’autres utilisateurs dans des conditions spécifiques. Ces scénarios doivent être analysés dans leur contexte plutôt que traités comme des vulnérabilités génériques du protocole Kerberos.

Mauvaises configurations AD CS

Active Directory Certificate Services représente aujourd’hui une surface d’attaque importante dans de nombreux environnements Active Directory. Une autorité de certification ou un modèle de certificat mal configuré peut permettre à un utilisateur normalement peu privilégié d’obtenir un certificat utilisable pour s’authentifier sous une autre identité.

ESC1 constitue l’un des scénarios les plus connus : sous certaines conditions combinant notamment permissions d’enrôlement, usage du certificat, paramètres du template et possibilité de contrôler certaines informations d’identité dans la requête, un utilisateur peut obtenir un certificat permettant d’usurper un compte plus privilégié.

ESC8 repose sur un mécanisme différent. Il concerne certaines interfaces d’enrôlement HTTP d’AD CS insuffisamment protégées et peut permettre de relayer une authentification NTLM vers ces endpoints afin d’obtenir un certificat au nom du principal relayé. Ces différences sont importantes, car les conditions d’exploitation et les remédiations ne sont pas les mêmes.

Segmentation réseau insuffisante

Une segmentation insuffisante augmente considérablement les conséquences d’une compromission. Si un poste utilisateur peut atteindre directement des interfaces RDP, WinRM ou SMB sur de nombreux serveurs sensibles, la récupération d’un seul compte privilégié peut permettre une progression très rapide.

Une segmentation efficace doit être pensée en fonction des usages réels et non seulement selon des VLAN. Le point important pour le pentester est de déterminer quels flux sont réellement possibles depuis le contexte compromis et si ces flux permettent d’atteindre des ressources plus sensibles.

Interfaces d’administration excessivement exposées

RDP, SSH, WinRM, VNC, consoles web, hyperviseurs, interfaces de stockage ou solutions de backup doivent être accessibles uniquement depuis les zones et comptes qui en ont besoin. Lorsque ces interfaces sont accessibles depuis un réseau utilisateur, elles constituent des cibles privilégiées après récupération d’identifiants.

Le risque est encore plus important lorsque les mêmes comptes sont utilisés sur plusieurs niveaux d’administration ou lorsque l’authentification multifacteur n’est pas disponible sur les interfaces concernées.

Comptes locaux et secrets réutilisés

La réutilisation d’un même compte administrateur local ou du même mot de passe sur plusieurs systèmes peut transformer une compromission locale en problème généralisé. Un attaquant obtenant une information d’authentification sur une machine peut tester sa validité sur d’autres systèmes accessibles.

Des mécanismes comme Windows LAPS permettent de gérer et de faire tourner automatiquement des mots de passe d’administrateurs locaux uniques, réduisant ainsi les possibilités de mouvement latéral fondées sur leur réutilisation. La sécurité dépend toutefois aussi des permissions permettant de lire les secrets stockés.

Comment se déroule un pentest réseau externe ?

Le pentest externe correspond généralement à la première étape d’un scénario d’attaque depuis Internet. Il vise à mesurer l’exposition réelle de l’organisation avant toute compromission interne.

Cartographie de la surface exposée

Les auditeurs commencent par identifier les services accessibles sur les adresses IP et domaines inclus dans le périmètre. L’objectif consiste à déterminer quelles technologies sont exposées et si leur présence est cohérente avec les besoins de l’organisation.

Un service d’administration qui n’aurait jamais dû être accessible depuis Internet représente déjà une information importante, même lorsqu’aucune vulnérabilité logicielle n’est identifiée. La découverte de technologies oubliées ou d’anciens équipements est également fréquente sur les périmètres exposés depuis plusieurs années.

Analyse des services et équipements exposés

VPN, passerelles SSL, interfaces web d’équipements réseau, services SSH, RDP, SMTP, DNS et autres protocoles sont ensuite analysés. Les auditeurs recherchent notamment des versions vulnérables, des configurations obsolètes, des mécanismes d’authentification insuffisants ou des fonctionnalités accessibles sans authentification.

Les appliances périmétriques représentent des cibles particulièrement importantes, car leur compromission peut fournir un accès direct au réseau interne. La criticité dépend donc autant de la vulnérabilité que de la position réseau de l’équipement.

Analyse des mécanismes d’authentification

Lorsque des services accessibles depuis Internet proposent une authentification, les auditeurs évaluent leur niveau de protection. Ils vérifient notamment l’utilisation du MFA lorsqu’il est pertinent, les politiques de verrouillage, les mécanismes de limitation, les éventuelles différences de réponse permettant d’énumérer des utilisateurs et la résistance à des scénarios contrôlés de password spraying lorsqu’ils ont été autorisés.

L’objectif n’est pas de provoquer des verrouillages ou de dégrader les services, mais de mesurer si les mécanismes exposés résistent à des techniques réalistes et courantes.

Validation d’un accès initial

Lorsqu’une vulnérabilité permet d’obtenir un accès à un système exposé, le pentester cherche ensuite à évaluer l’importance de ce point d’entrée. Un serveur compromis situé dans une DMZ correctement isolée peut offrir peu de possibilités de progression.

À l’inverse, un système disposant de multiples interfaces réseau, de comptes privilégiés ou de connexions vers l’infrastructure interne peut constituer un véritable point de pivot. C’est à ce stade que la distinction entre pentest externe et pentest interne devient moins nette : une compromission externe réussie peut servir de point de départ à l’évaluation des mouvements possibles dans le système d’information, si cette extension du scénario est prévue dans le périmètre.

Comment se déroule un pentest réseau interne black box ?

Un pentest interne black box commence généralement avec un accès au réseau mais sans identifiant. L’objectif est de déterminer si un attaquant non authentifié peut obtenir un premier compte ou compromettre directement une ressource.

Découverte des systèmes et services accessibles sans authentification

Les auditeurs identifient d’abord les hôtes joignables, les protocoles exposés et les services accessibles. Ils recherchent notamment les partages anonymes, les interfaces web internes, les services FTP ou bases de données mal configurés ainsi que les systèmes obsolètes exposant une vulnérabilité exploitable sans compte valide.

Certaines ressources apparemment anodines peuvent fournir suffisamment d’informations pour poursuivre l’attaque. Un partage en lecture seule peut par exemple contenir des scripts d’administration, de la documentation réseau ou des fichiers de configuration mentionnant des comptes, des chemins internes ou des secrets.

Écoute et analyse des communications

L’accès au réseau permet également d’observer les protocoles utilisés. La présence de communications non chiffrées peut exposer directement des données sensibles. Dans certaines architectures, des protocoles de découverte ou de résolution de noms peuvent également révéler des informations sur les systèmes et les services utilisés.

Ces observations permettent souvent de mieux comprendre l’architecture avant de tenter une exploitation active. Elles peuvent également révéler des flux inattendus entre des segments qui étaient supposés isolés.

Empoisonnement LLMNR et NBT-NS

Lorsqu’un poste Windows ne parvient pas à résoudre certains noms via DNS, il peut, selon sa configuration, utiliser des mécanismes de résolution locaux comme LLMNR ou NBT-NS. Un attaquant présent sur le réseau peut tenter de répondre à ces requêtes en prétendant être la ressource recherchée.

Le système victime peut alors essayer de s’authentifier sur le service contrôlé par l’attaquant. Ce scénario ne signifie pas automatiquement que le compte est compromis. L’attaquant doit encore être capable d’exploiter l’authentification récupérée, par exemple en attaquant hors ligne une information dérivée du mot de passe ou en relayant l’authentification vers un service compatible.

Relay NTLM

Une attaque par relay ne consiste pas à casser le mot de passe de la victime. Le principe est de récupérer une authentification NTLM initiée vers le système contrôlé par l’attaquant et de la transmettre en temps réel à un autre service.

Si le service cible accepte cette authentification et ne dispose pas des protections nécessaires, l’attaquant peut obtenir une session avec les privilèges du compte relayé sans connaître son mot de passe. SMB a historiquement constitué une cible importante lorsque la signature n’était pas exigée, mais d’autres services peuvent aussi être concernés selon leur configuration.

Les environnements Windows récents introduisent progressivement des paramètres par défaut plus protecteurs. L’audit doit donc identifier les services effectivement relayables plutôt que raisonner uniquement sur la présence de NTLM.

Test des politiques de mots de passe

Dans certaines missions, un password spraying contrôlé peut également être réalisé. Cette opération nécessite des précautions importantes afin de ne pas verrouiller les comptes. Le nombre de tentatives, leur rythme et les comptes ciblés doivent être adaptés à la politique du domaine et définis dans les Rules of Engagement.

Si un premier compte est obtenu, l’audit change alors de nature : le pentester dispose désormais d’un accès authentifié et peut commencer les opérations typiques d’un scénario grey box.

Comment se déroule un pentest réseau interne grey box ?

Un compte Active Directory standard offre généralement beaucoup plus de possibilités d’énumération qu’un attaquant non authentifié. L’objectif est d’évaluer si les informations et droits accessibles à cet utilisateur permettent de progresser vers des comptes ou systèmes plus sensibles.

Énumération de l’annuaire LDAP

L’une des premières étapes consiste généralement à analyser l’annuaire Active Directory. Un utilisateur authentifié peut obtenir de nombreuses informations sur les utilisateurs, groupes, ordinateurs, comptes de service, relations de confiance et autres objets du domaine.

Cette visibilité est normale et nécessaire au fonctionnement d’Active Directory. Elle devient problématique lorsqu’elle permet d’identifier des erreurs de configuration ou des informations sensibles qui ne devraient pas être présentes dans l’annuaire. Les champs description, commentaires ou autres attributs administratifs doivent notamment être examinés : il arrive encore que des secrets ou informations d’exploitation y aient été enregistrés pour des raisons pratiques.

Identification des comptes privilégiés et comptes de service

Le pentester cherche rapidement à comprendre la structure des privilèges. Les membres des groupes d’administration évidents sont importants, mais ils ne constituent pas les seules cibles intéressantes.

Un compte associé à une solution de sauvegarde, un outil de supervision, une plateforme de virtualisation, Configuration Manager ou une base de données peut disposer de droits considérables sans appartenir à Domain Admins. Le contexte des comptes est donc aussi important que leur appartenance aux groupes standards.

Kerberoasting

Les comptes associés à des Service Principal Names peuvent recevoir des tickets de service Kerberos. Un utilisateur authentifié peut légitimement demander certains de ces tickets. Comme une partie du ticket est protégée à partir d’un secret lié au compte de service, elle peut être soumise à une attaque hors ligne visant à retrouver son mot de passe.

Le protocole Kerberos lui-même ne constitue pas la vulnérabilité. Le risque provient essentiellement de comptes de service protégés par des mots de passe faibles ou anciens, en particulier lorsqu’ils disposent de privilèges importants. La défense consiste donc notamment à utiliser des secrets longs et aléatoires, à réduire les privilèges de ces comptes et, lorsque cela est possible, à privilégier des comptes de service managés.

AS-REP Roasting

Un autre cas particulier concerne les comptes pour lesquels la préauthentification Kerberos n’est pas requise. Dans cette configuration, un attaquant peut obtenir une réponse Kerberos contenant des données susceptibles d’être attaquées hors ligne.

Cette option doit être limitée aux rares situations où elle est réellement nécessaire. Le pentest cherche donc à identifier les comptes concernés, mais aussi à déterminer l’impact de leur compromission éventuelle.

Analyse des délégations Kerberos

Les mécanismes de délégation permettent à un service d’agir pour le compte d’un utilisateur afin d’accéder à une autre ressource. Plusieurs modèles existent, notamment la délégation non contrainte, la délégation contrainte et la Resource-Based Constrained Delegation.

Ces fonctionnalités répondent à des besoins légitimes mais peuvent devenir extrêmement sensibles lorsqu’elles sont configurées de manière incorrecte. La délégation non contrainte est particulièrement importante à identifier, car la compromission d’un système configuré de cette manière peut exposer des éléments d’authentification d’utilisateurs qui s’y connectent.

L’analyse des délégations doit donc s’intéresser à la fois aux systèmes concernés, aux comptes susceptibles de s’y authentifier et aux possibilités de contrôle de ces systèmes par d’autres utilisateurs.

Analyse des GPO et de leurs permissions

Les Group Policy Objects permettent d’appliquer automatiquement des configurations à un grand nombre de postes ou serveurs. Une GPO appliquée à des systèmes sensibles peut donc constituer un mécanisme d’administration particulièrement puissant.

Le pentester cherche à déterminer qui peut modifier ces objets et si des utilisateurs insuffisamment privilégiés disposent de droits d’écriture sur une politique affectant des machines critiques. Le contenu des GPO est également examiné afin d’identifier des scripts, commandes ou configurations susceptibles d’exposer des secrets ou de créer des droits excessifs.

Recherche de credentials historiques dans les Group Policy Preferences

Les anciennes Group Policy Preferences pouvaient contenir des mots de passe dans un attribut cpassword stocké dans SYSVOL. La clé utilisée pour protéger ces données étant connue, un utilisateur authentifié capable de lire SYSVOL pouvait récupérer les secrets.

Microsoft a supprimé en 2014 la possibilité de créer de nouvelles préférences utilisant ce mécanisme, mais cette mise à jour ne supprimait pas automatiquement les GPO historiques déjà présentes. La recherche de cpassword reste donc pertinente dans des environnements anciens ou ayant conservé des objets hérités.

Il est important de présenter cette technique pour ce qu’elle est aujourd’hui : un problème legacy qui peut encore être rencontré, et non une fonctionnalité normalement utilisée dans les environnements Windows modernes.

Analyse d’Active Directory Certificate Services

Lorsque AD CS est déployé, les autorités de certification, templates, permissions d’enrôlement et services associés doivent être analysés. Le risque résulte souvent de la combinaison de plusieurs paramètres.

Dans un scénario ESC1, par exemple, une configuration trop permissive peut permettre à un utilisateur de demander un certificat d’authentification en spécifiant une identité différente de la sienne. D’autres scénarios concernent les ACL des templates ou autorités de certification, les agents d’enrôlement, certaines extensions de sécurité ou les endpoints web.

La nomenclature publique des scénarios ESC s’est largement étendue depuis les premières publications. L’audit ne doit toutefois pas consister à rechercher mécaniquement tous les numéros ESC : l’enjeu est de déterminer si une configuration concrète permet effectivement au compte compromis d’obtenir un certificat utilisable pour accéder à une identité plus privilégiée.

Analyse des chemins d’attaque avec BloodHound

Dans un Active Directory complexe, les relations de privilège peuvent être très difficiles à analyser manuellement. Un utilisateur peut appartenir à un groupe qui contrôle un autre groupe, lequel dispose d’un droit sur une GPO permettant elle-même de compromettre plusieurs serveurs.

Pris individuellement, chacun de ces éléments peut paraître peu important. BloodHound permet de représenter ces relations et d’identifier les chemins reliant un compte initial à une cible privilégiée. Cette analyse est particulièrement intéressante pour le pentest, car elle correspond exactement à la logique d’un attaquant : rechercher non seulement les vulnérabilités directes, mais l’ensemble des relations pouvant être combinées.

Comptes administrateurs locaux et Windows LAPS

Le pentester analyse également la manière dont les comptes d’administration locale sont gérés. Si plusieurs machines utilisent le même secret, la compromission d’une seule d’entre elles peut permettre de progresser rapidement.

Windows LAPS permet au contraire de générer et faire tourner automatiquement des mots de passe d’administrateurs locaux distincts, stockés dans Active Directory ou Microsoft Entra ID avec des mécanismes de contrôle d’accès adaptés. La présence de LAPS ne suffit toutefois pas : les droits permettant de lire les secrets stockés doivent eux-mêmes être contrôlés.

Coercition NTLM et attaques par relay au-delà de SMB

Les attaques NTLM relay sont souvent associées à SMB, mais cette vision est réductrice. Le principe général consiste à obtenir une authentification NTLM émise par une victime et à la transmettre en temps réel à un autre service capable de l’accepter. L’attaquant ne connaît alors pas nécessairement le mot de passe ni le hash NT de l’utilisateur : il exploite l’authentification au moment où celle-ci est effectuée.

Provoquer une authentification vers un système contrôlé

L’une des premières questions est de savoir dans quelles circonstances une authentification NTLM peut atteindre un système contrôlé par l’auditeur. LLMNR et NBT-NS peuvent créer certaines de ces situations, mais ils ne constituent pas les seuls vecteurs possibles.

Différents services Windows peuvent, dans certaines conditions, être amenés à initier une authentification vers une ressource distante. On parle alors généralement de coercition d’authentification. La possibilité de déclencher ce comportement dépend de la surface exposée, des protocoles disponibles, des correctifs appliqués et des privilèges du compte utilisé.

Identifier les services vers lesquels l’authentification peut être relayée

La seconde question consiste à déterminer vers quels services l’authentification pourrait être relayée. SMB est historiquement l’une des cibles les plus connues, notamment lorsque la signature SMB n’est pas obligatoire. Mais d’autres protocoles et services utilisant NTLM doivent également être examinés en fonction de leur configuration, notamment LDAP et certains services HTTP utilisant l’authentification intégrée Windows.

L’impact dépend entièrement du compte relayé et du service cible. Relayer l’authentification d’un utilisateur standard vers un service sur lequel celui-ci ne dispose d’aucun privilège particulier peut avoir un impact limité. En revanche, une authentification provenant d’un compte machine ou administratif vers un service sur lequel cette identité dispose de droits importants peut transformer le même mécanisme en chemin d’élévation de privilèges.

AD CS et scénario ESC8

AD CS illustre particulièrement bien cette problématique. Dans un scénario ESC8, l’objectif est de relayer une authentification NTLM vers certaines interfaces HTTP d’enrôlement de certificats insuffisamment protégées.

Si les conditions nécessaires sont réunies, un certificat peut être obtenu au nom de l’identité relayée et utilisé ensuite comme moyen d’authentification. Le pentest doit donc considérer le relay comme une famille de scénarios plutôt que comme une simple vulnérabilité SMB.

Les protections doivent elles aussi être considérées globalement. La signature SMB empêche certaines attaques visant SMB ; la signature LDAP et le channel binding renforcent LDAP ; Extended Protection for Authentication permet à certains services de lier davantage l’authentification au canal utilisé. Réduire progressivement l’usage de NTLM diminue quant à lui l’ensemble de la surface d’attaque.

Analyse des relations de confiance Active Directory

Les environnements Active Directory ne sont pas toujours composés d’un domaine ou d’une forêt unique. Des fusions d’entreprises, acquisitions, contraintes organisationnelles ou besoins d’isolation peuvent conduire à la coexistence de plusieurs domaines ou forêts reliés par des relations de confiance.

Une relation de confiance n’accorde pas automatiquement des privilèges administratifs d’un environnement vers un autre. Elle crée néanmoins une frontière d’authentification supplémentaire qui doit être comprise lors d’un pentest.

Comprendre le sens et la portée d’une relation de confiance

Une première étape consiste à identifier les domaines et forêts concernés, puis à comprendre le sens de la relation, son caractère transitif ou non et les mécanismes de sécurité associés. Il est particulièrement important de distinguer la capacité d’un utilisateur à être authentifié dans un autre environnement de la possibilité pour celui-ci d’accéder effectivement à une ressource.

Cette distinction explique pourquoi deux relations de confiance apparemment similaires peuvent présenter des niveaux de risque très différents. Un domaine historiquement considéré comme secondaire peut, par exemple, disposer de droits sur des ressources critiques d’un autre domaine en raison de groupes ou ACL créés plusieurs années auparavant.

Authentification sélective, SID filtering et SIDHistory

Différents mécanismes permettent de limiter les risques associés aux trusts. L’authentification sélective permet de contrôler les ressources sur lesquelles les utilisateurs provenant d’une autre forêt sont autorisés à s’authentifier.

Le SID filtering constitue une autre protection importante : les SID transportés à travers une frontière de confiance font l’objet de règles de filtrage afin d’éviter que des identités provenant d’un environnement distant ne revendiquent certains SID qu’elles ne devraient pas posséder.

Les usages de SIDHistory, les groupes contenant des membres provenant d’autres domaines, les délégations croisées et les ACL appliquées à des objets sensibles méritent également une attention particulière. L’audit doit donc examiner non seulement l’existence d’un trust, mais les protections qui encadrent son utilisation et les droits réellement accordés aux identités distantes.

Les trusts comme composants d’un chemin d’attaque

L’une des erreurs classiques consiste à traiter chaque forêt comme un périmètre totalement indépendant. Imaginons qu’une forêt A soit considérée comme peu sensible et qu’une forêt B contienne les ressources les plus critiques de l’organisation.

Une compromission complète de la forêt A ne signifie pas nécessairement que la forêt B est compromise. En revanche, si des administrateurs de A possèdent des droits sur des systèmes de B, si des comptes sont réutilisés ou si certaines ressources acceptent largement l’authentification provenant de A, la frontière entre les deux environnements devient beaucoup plus faible qu’elle ne le semble.

Le pentest doit donc chercher à comprendre les relations de privilèges transverses et pas simplement représenter l’architecture logique des domaines.

Comptes de service, gMSA et dMSA

Les comptes de service sont particulièrement importants lors d’un pentest interne. Ils exécutent souvent des applications ou services nécessitant des accès à plusieurs ressources et peuvent, par conséquent, disposer de privilèges sensiblement supérieurs à ceux d’un utilisateur standard.

Les comptes de service historiques utilisant des mots de passe gérés manuellement présentent plusieurs difficultés : leurs secrets sont parfois rarement renouvelés, ils peuvent être partagés entre plusieurs machines et leur utilisation réelle devient difficile à cartographier au fil du temps. Ces caractéristiques expliquent pourquoi ils représentent fréquemment des cibles intéressantes dans des scénarios de Kerberoasting ou de récupération de credentials.

Group Managed Service Accounts

Les Group Managed Service Accounts, ou gMSA, ont notamment été conçus pour répondre à une partie de ces problématiques. Le mot de passe est géré automatiquement par Active Directory et le même principal peut être utilisé par un service fonctionnant sur plusieurs serveurs.

Un gMSA ne doit toutefois pas être considéré comme intrinsèquement sans risque. Active Directory doit être capable de déterminer quels systèmes sont autorisés à utiliser le compte et à obtenir les informations nécessaires à son fonctionnement. Les permissions permettant cette utilisation deviennent donc elles-mêmes une frontière de sécurité.

Lors d’un pentest, l’auditeur cherche ainsi à identifier les gMSA, leurs privilèges, les machines autorisées à les utiliser et les relations permettant éventuellement à un compte moins privilégié de prendre le contrôle de ces machines ou des groupes concernés. La question n’est donc plus seulement de savoir si le mot de passe est robuste, mais aussi de déterminer qui peut légitimement utiliser cette identité.

Delegated Managed Service Accounts

Windows Server 2025 introduit également les delegated Managed Service Accounts, ou dMSA. Ils permettent notamment de migrer certains comptes de service traditionnels vers un modèle dans lequel la gestion des secrets reste automatique et l’identité est davantage liée aux machines autorisées à l’utiliser.

Pour un guide publié en 2026, cette évolution mérite d’être mentionnée. Les gMSA restent extrêmement courants, mais les dMSA illustrent l’évolution progressive de la protection des identités de service dans les versions récentes de Windows Server et la volonté de réduire les risques liés au credential harvesting.

MSSQL et serveurs de bases de données dans les chemins d’attaque

Les serveurs Microsoft SQL Server sont fréquemment présents dans les environnements Windows et peuvent occuper une position importante dans l’infrastructure. Ils contiennent souvent des données sensibles, mais leur intérêt lors d’un pentest ne se limite pas à l’accès aux bases de données.

Les comptes utilisés par les services SQL, les mécanismes d’authentification Windows, les permissions attribuées aux utilisateurs et les relations entre plusieurs instances peuvent également créer des chemins d’attaque.

Privilèges et comptes de service SQL Server

Une première étape consiste à comprendre le contexte de sécurité dans lequel fonctionne l’instance. Un service SQL exécuté avec une identité excessivement privilégiée augmente considérablement les conséquences d’une compromission de l’instance.

Les permissions attribuées aux utilisateurs de la base doivent également être distinguées des permissions système. Un utilisateur capable de se connecter à SQL Server ne dispose pas nécessairement de privilèges importants sur la machine. À l’inverse, certaines configurations et certains rôles peuvent permettre d’étendre fortement l’impact d’une compromission.

Serveurs liés et propagation de la compromission

Les linked servers sont particulièrement intéressants à analyser. Ils permettent à une instance SQL Server d’interagir avec une autre source de données distante. Selon la configuration, les connexions peuvent utiliser le contexte de l’utilisateur courant ou une identité définie spécifiquement pour la connexion distante.

Du point de vue d’un attaquant, cela signifie qu’une instance peu sensible peut parfois constituer un point de passage vers une autre instance davantage privilégiée. Le pentester doit donc rechercher non seulement les serveurs liés directement accessibles, mais également les éventuelles chaînes de confiance entre plusieurs instances.

Kerberos et problématique du double hop

L’authentification Windows introduit également la problématique du Kerberos double hop. Lorsqu’un utilisateur se connecte à un premier serveur qui doit ensuite accéder à un deuxième service en son nom, ses informations d’authentification doivent pouvoir être déléguées dans des conditions précises.

Cette interaction entre SQL Server, SPN et délégation Kerberos justifie que les serveurs de bases de données soient analysés comme des composants du système d’identité, et pas uniquement comme des services stockant des données.

SCCM et Microsoft Configuration Manager

Microsoft Configuration Manager, encore couramment appelé SCCM ou MECM, constitue une cible particulièrement importante dans un environnement Windows. Sa fonction même consiste à administrer un grand nombre de postes et serveurs : déploiement de logiciels, installation de systèmes d’exploitation, distribution de contenus, gestion de configurations ou opérations d’administration.

La compromission de l’infrastructure de gestion peut donc fournir un niveau de contrôle bien supérieur à celui obtenu par la compromission d’un poste individuel.

Identifier l’architecture Configuration Manager

Un pentest doit commencer par identifier les différents composants présents : serveurs de site, management points, distribution points et autres rôles déployés dans l’environnement. Les permissions permettant d’administrer la plateforme sont particulièrement sensibles.

Un utilisateur disposant d’un rôle Configuration Manager trop important peut potentiellement agir indirectement sur un grand nombre de machines. L’analyse doit donc porter sur les rôles RBAC, les comptes ayant accès à la console et les délégations historiques qui peuvent avoir élargi progressivement les privilèges.

Comptes utilisés par Configuration Manager

Configuration Manager peut utiliser différents comptes techniques pour certaines opérations. Le Network Access Account constitue un exemple important dans les environnements où il est encore nécessaire. Il est utilisé dans certains scénarios où un client ne peut pas utiliser son propre compte machine pour accéder au contenu disponible sur un point de distribution.

Du point de vue du pentest, l’existence d’un tel compte est moins problématique que le niveau de privilèges qui lui a été attribué. Une identité de service conçue uniquement pour lire certains contenus devient dangereuse si des privilèges supplémentaires ont progressivement été ajoutés pour résoudre des contraintes opérationnelles.

Communications HTTP, HTTPS et Enhanced HTTP

Les mécanismes de communication entre clients et infrastructure Configuration Manager doivent également être examinés. Les déploiements récents doivent privilégier HTTPS ou Enhanced HTTP plutôt que les anciennes communications client HTTP non sécurisées.

Enhanced HTTP permet de sécuriser plusieurs communications sensibles et de réduire la nécessité d’utiliser un Network Access Account dans différents scénarios. Il ne signifie toutefois pas que l’intégralité des communications SCCM est automatiquement sécurisée : l’architecture réelle et les rôles utilisés doivent être vérifiés.

SCCM comme chemin de mouvement latéral

Le risque principal vient de la position de confiance de Configuration Manager. Si un attaquant prend le contrôle d’un compte ou composant disposant de capacités de déploiement sur de nombreux postes, il peut potentiellement transformer cette fonction légitime d’administration en mécanisme de propagation.

La plateforme doit donc être analysée comme une infrastructure d’administration privilégiée. Les comptes ayant accès à la console, les permissions RBAC, les comptes de service, les communications avec les clients et la segmentation des serveurs SCCM sont autant d’éléments qui déterminent si une première compromission peut être transformée en prise de contrôle beaucoup plus large.

IPv6, DHCP, DNS et mécanismes réseau fondamentaux

Les pentests internes se concentrent naturellement sur les services applicatifs et Active Directory, mais les mécanismes fondamentaux permettant aux machines de découvrir leur environnement réseau peuvent eux aussi devenir des vecteurs d’attaque. Cette problématique est particulièrement importante sur les réseaux locaux où un attaquant dispose déjà d’une présence sur le même segment que les utilisateurs.

DHCP et serveurs non autorisés

DHCP permet à un poste d’obtenir automatiquement une partie importante de sa configuration réseau. Cette confiance dans les informations distribuées représente également une surface d’attaque.

Un serveur DHCP malveillant ou incorrectement déployé peut fournir de fausses informations aux clients et perturber leur connectivité. Dans certaines circonstances, les paramètres distribués peuvent également faciliter le positionnement d’un attaquant sur le chemin des communications.

L’objectif d’un pentest n’est généralement pas de perturber la production en concurrençant agressivement les serveurs DHCP légitimes. Il consiste plutôt à vérifier si l’infrastructure de niveau 2 comporte des protections suffisantes pour empêcher un équipement connecté sur un port utilisateur de se comporter comme une infrastructure réseau de confiance.

DNS comme composant critique de l’infrastructure

DNS intervient dans presque toutes les phases de communication d’un environnement d’entreprise. Un attaquant capable d’influencer la résolution de noms peut donc potentiellement rediriger certains flux vers des systèmes qu’il contrôle.

Le pentest doit notamment examiner les serveurs DNS utilisés, les possibilités de mises à jour non autorisées, les zones accessibles, les informations exposées et les dépendances entre Active Directory et DNS. Dans un domaine Active Directory, cette analyse est particulièrement importante : de nombreux services utilisent DNS pour localiser les contrôleurs de domaine et différents services associés à l’authentification.

DNS ne doit donc pas être considéré uniquement comme une source d’information lors de la reconnaissance, mais comme un composant de sécurité à part entière.

Ne pas ignorer IPv6

Une erreur fréquente consiste à considérer qu’IPv6 n’est pas pertinent parce que l’organisation utilise principalement IPv4. En pratique, IPv6 peut rester activé sur les postes et équipements même lorsqu’il n’est pas explicitement utilisé par les équipes réseau.

Cela crée une surface d’attaque parallèle qui doit être prise en compte. IPv6 utilise notamment des Router Advertisements pour communiquer aux hôtes certaines informations nécessaires à l’autoconfiguration. Un équipement malveillant présent sur le même segment peut tenter d’émettre des annonces non autorisées et influencer la configuration des postes.

Dans un pentest moderne, IPv6 doit donc être intégré à la cartographie réseau plutôt que traité comme une technologie marginale. L’absence d’utilisation volontaire d’IPv6 n’est pas nécessairement une protection : un protocole activé mais non supervisé peut au contraire constituer une zone moins surveillée que l’infrastructure IPv4 principale.

RA Guard et protections de niveau 2

RA Guard a été conçu pour permettre aux équipements de niveau 2 de filtrer les Router Advertisements ne provenant pas de ports autorisés. Cette protection doit néanmoins être correctement implémentée et configurée.

D’autres protections de niveau 2 peuvent également être pertinentes selon les équipements utilisés, notamment pour limiter les serveurs DHCP non autorisés ou certains scénarios d’usurpation. L’audit doit donc tenir compte des fonctionnalités réellement disponibles sur les commutateurs et de leur activation effective.

Pentest des environnements hybrides Active Directory et Microsoft Entra ID

De nombreuses organisations utilisent aujourd’hui simultanément Active Directory on-premise et Microsoft Entra ID. Les identités, systèmes et services ne doivent alors plus être considérés comme appartenant à deux environnements totalement indépendants.

Des mécanismes de synchronisation ou d’authentification créent des dépendances entre le système d’information local et l’identité cloud. Le pentest réseau doit identifier ces composants et suivre les chemins d’attaque lorsque la compromission d’un actif on-premise peut avoir un impact sur l’environnement cloud.

Identifier les composants créant le lien entre les environnements

Selon l’architecture, le périmètre peut inclure Microsoft Entra Connect, des agents de Pass-through Authentication ou différents systèmes participant à la synchronisation et à l’authentification. Ces composants sont particulièrement sensibles, car ils se trouvent à la frontière entre deux plans d’identité.

Ils doivent être considérés comme des ressources d’administration critiques et bénéficier d’un niveau de segmentation, de durcissement et de contrôle des accès cohérent avec leur rôle.

Entra Connect comme actif critique

Un serveur Entra Connect n’est pas un simple serveur applicatif. Il participe à la synchronisation entre les identités locales et cloud et dispose donc de capacités et informations particulièrement sensibles.

Du point de vue du pentest réseau, il est important de déterminer qui peut atteindre ce serveur, quels comptes peuvent l’administrer, quels utilisateurs s’y connectent et si sa segmentation correspond réellement à son niveau de criticité. Un poste utilisateur standard ne devrait notamment pas disposer des mêmes possibilités d’accès à ce type de serveur qu’à une application métier ordinaire.

Agents de Pass-through Authentication

Les environnements utilisant Pass-through Authentication disposent également d’agents on-premise participant au processus de validation des connexions. Les serveurs hébergeant ces agents doivent eux aussi être considérés comme des composants très privilégiés.

Même si un composant n’est pas un contrôleur de domaine, son rôle dans la chaîne d’authentification peut justifier un niveau de protection comparable. Le pentest doit donc analyser les droits d’administration, les flux réseau et les chemins permettant éventuellement à un système moins sensible d’atteindre ces agents.

Chemins d’attaque entre on-premise et cloud

La compromission d’Active Directory ne signifie pas systématiquement la compromission de l’ensemble des ressources Entra ID. Inversement, la compromission d’une identité cloud n’implique pas automatiquement celle du domaine local. Tout dépend de l’architecture, des mécanismes de synchronisation, des comptes utilisés et des privilèges réellement attribués.

Cette nuance est essentielle. L’objectif d’un pentest n’est pas d’affirmer qu’un environnement hybride crée nécessairement un risque supplémentaire, mais de déterminer quelles relations concrètes transforment une compromission locale en compromission cloud, ou inversement.

Définir la frontière avec un pentest cloud

Un pentest réseau interne n’a pas vocation à remplacer un audit complet de Microsoft Entra ID ou de Microsoft 365. Il doit cependant suivre les chemins d’attaque lorsqu’un composant on-premise crée un impact sur le cloud.

Lorsqu’un scénario commence à nécessiter une analyse approfondie des rôles Entra, applications OAuth, permissions Microsoft Graph, Conditional Access ou workloads Azure, il devient pertinent de poursuivre les investigations dans le cadre d’un périmètre cloud ou Microsoft 365 spécifiquement autorisé. Cette distinction permet de conserver un guide réseau cohérent sans ignorer les interactions essentielles avec les architectures modernes.

Exemples de chemins d’attaque identifiés lors d’un pentest réseau

L’intérêt d’un pentest apparaît particulièrement lorsqu’on observe la manière dont plusieurs faiblesses peuvent être combinées. Les scénarios suivants sont volontairement simplifiés : dans un environnement réel, chaque étape dépend des configurations présentes et des autorisations définies pour la mission.

D’un accès réseau sans credentials à la compromission d’un compte

Imaginons un attaquant disposant uniquement d’un accès au réseau interne. La phase de découverte ne révèle aucune vulnérabilité critique directement exploitable, mais elle montre que LLMNR est encore utilisé sur plusieurs postes.

L’attaquant se place alors en situation de répondre à certaines requêtes de résolution erronées. Un poste tente finalement de s’authentifier auprès du service contrôlé par l’attaquant.

L’authentification obtenue ne donne pas automatiquement accès au compte. Cependant, elle fournit une nouvelle possibilité : tenter une attaque hors ligne contre le secret dérivé ou rechercher un service sur lequel cette authentification pourrait être relayée.

Si le mot de passe de l’utilisateur est suffisamment robuste et que les services sont correctement protégés contre le relay, l’attaque s’arrête à cette étape. Dans le cas contraire, l’attaquant peut obtenir un premier accès authentifié. Le scénario devient alors un pentest grey box et l’énumération Active Directory peut commencer.

Ce scénario montre pourquoi les vulnérabilités doivent être analysées en chaîne : LLMNR seul n’entraîne pas nécessairement une compromission, mais son association avec une politique de mots de passe faible ou un service relayable peut devenir beaucoup plus problématique.

D’un utilisateur standard à un compte privilégié

Prenons maintenant un utilisateur Active Directory classique compromis par phishing. L’énumération LDAP permet d’identifier plusieurs comptes de service disposant de SPN.

Un de ces comptes est associé à une application critique et possède des privilèges importants. Un ticket de service est récupéré dans le cadre d’un scénario de Kerberoasting. Le secret du compte de service se révèle insuffisamment robuste et peut être retrouvé hors ligne.

Le pentester dispose désormais des privilèges associés au compte de service. L’analyse BloodHound montre ensuite que ce compte dispose d’un contrôle indirect sur une GPO appliquée à plusieurs serveurs d’administration.

La compromission de cette GPO pourrait permettre d’obtenir des privilèges élevés sur ces systèmes et, selon les sessions et comptes présents, de progresser davantage dans le domaine. Aucune des faiblesses prises isolément ne raconte l’ensemble du risque : c’est la combinaison du secret du compte de service, de ses privilèges et de la délégation sur la GPO qui crée le chemin d’attaque critique.

Compromission via Active Directory Certificate Services

Dans un autre environnement, l’utilisateur standard ne dispose d’aucun droit particulièrement intéressant sur les groupes ou GPO. L’analyse d’AD CS révèle cependant un modèle de certificat utilisable pour l’authentification et insuffisamment restreint.

Les paramètres du template permettent à un utilisateur autorisé à s’enrôler d’influencer l’identité associée au certificat dans des conditions correspondant à un scénario ESC1. Le compte compromis peut alors obtenir un certificat permettant de s’authentifier sous une identité plus privilégiée.

Dans ce scénario, aucun mot de passe administrateur n’a été découvert et aucune vulnérabilité logicielle n’a été exploitée. La compromission repose entièrement sur une relation de confiance mal configurée au niveau de l’infrastructure PKI. C’est précisément ce type de scénario qu’un pentest réseau authentifié doit être capable d’identifier.

Coercition NTLM et compromission via AD CS

Imaginons un attaquant ayant déjà obtenu un compte standard dans le domaine. Aucune permission Active Directory directe ne permet à cet utilisateur d’élever ses privilèges. Les comptes de service utilisent des mots de passe robustes et aucun chemin BloodHound évident n’apparaît.

L’analyse montre toutefois qu’AD CS est déployé et qu’une interface HTTP d’enrôlement accepte une authentification NTLM sans protection suffisante contre le relay. L’attaquant recherche alors si un système possédant davantage de privilèges peut être amené à initier une authentification NTLM vers une ressource qu’il contrôle.

Si cette authentification peut être obtenue et relayée vers l’interface AD CS vulnérable, elle peut, selon le contexte, permettre d’obtenir un certificat associé à l’identité relayée. Le certificat devient alors un nouvel élément d’authentification indépendant du mot de passe initial.

Ce scénario illustre parfaitement l’intérêt d’analyser une chaîne plutôt qu’une série de vulnérabilités indépendantes. Aucune faiblesse n’est suffisante seule : la coercition, NTLM, la configuration du service HTTP AD CS et les privilèges de l’identité doivent tous être compatibles pour que le chemin soit exploitable.

D’un accès SQL à une infrastructure plus sensible

Un utilisateur compromis dispose d’un accès légitime à une instance SQL utilisée par une application métier. Son rôle sur cette première instance paraît relativement limité.

L’analyse révèle cependant qu’un linked server permet d’interroger une deuxième instance avec un contexte de sécurité spécifique. La configuration de cette relation attribue davantage de privilèges sur la deuxième instance que ceux dont dispose directement l’utilisateur. Cette deuxième instance possède elle-même des relations avec d’autres ressources.

L’accès initial à une base de données, qui aurait pu être considéré comme peu critique, devient ainsi le début d’un chemin de mouvement latéral. L’intérêt du pentest est alors d’identifier le niveau maximal de privilège réellement atteignable à travers ces relations et de déterminer quelle configuration doit être modifiée pour interrompre la chaîne.

Compromission d’une infrastructure d’administration

Prenons maintenant un compte disposant de droits limités sur certaines fonctions Configuration Manager. L’analyse des rôles montre qu’une délégation historique lui attribue davantage de possibilités que prévu sur un ensemble de machines.

Ces privilèges ne permettent pas nécessairement de compromettre Active Directory directement. Ils peuvent toutefois permettre d’interagir avec des systèmes administrés par la plateforme. Parmi ceux-ci se trouve un serveur sur lequel des administrateurs privilégiés interviennent régulièrement.

La compromission de la plateforme de gestion crée ainsi indirectement une opportunité de progression vers des identités plus sensibles. Ici encore, le problème principal ne réside pas dans une vulnérabilité logicielle de SCCM, mais dans le niveau de confiance associé à une plateforme d’administration centralisée et dans les conséquences d’une délégation trop large.

D’un serveur interne vers l’identité hybride

Enfin, imaginons qu’un attaquant obtienne des privilèges d’administration sur plusieurs serveurs internes. La segmentation limite correctement l’accès direct aux contrôleurs de domaine, ce qui freine la progression classique vers Active Directory.

La cartographie du réseau montre cependant qu’un de ces serveurs peut communiquer avec le serveur Entra Connect et que certains comptes d’administration sont utilisés sur plusieurs niveaux de l’environnement. Le pentester découvre alors un chemin indirect vers ce composant d’identité hybride.

Même sans prendre immédiatement le contrôle d’un contrôleur de domaine, l’accès à un composant participant à la synchronisation des identités peut modifier très fortement l’impact de la compromission. Ce scénario justifie pourquoi les serveurs d’identité hybride doivent être considérés comme des ressources privilégiées et segmentés en conséquence.

Comment réduire les risques identifiés lors d’un pentest réseau ?

Il n’existe pas de remédiation unique au risque de compromission réseau. La sécurité repose au contraire sur plusieurs couches complémentaires visant à empêcher l’accès initial, limiter les privilèges et réduire les possibilités de progression lorsqu’un système est compromis.

Réduire la surface d’attaque

Les services inutiles doivent être désactivés et les interfaces d’administration rendues accessibles uniquement depuis les réseaux qui en ont réellement besoin. Un service qui n’est pas accessible à un attaquant ne peut pas être directement exploité depuis son point de présence.

Cette logique vaut aussi bien pour les systèmes exposés sur Internet que pour les services internes. Les anciennes applications, interfaces de maintenance et équipements oubliés doivent faire l’objet d’un inventaire régulier.

Maintenir les systèmes et équipements à jour

Les systèmes obsolètes et équipements arrivés en fin de support doivent faire l’objet d’une attention particulière. Lorsque leur remplacement immédiat n’est pas possible, des mécanismes compensatoires doivent être utilisés afin de réduire leur exposition.

La segmentation est alors particulièrement importante. Un système legacy ne doit pas rester accessible depuis de larges portions du réseau simplement parce qu’il est nécessaire au fonctionnement d’une application historique.

Renforcer l’authentification

Les politiques de mots de passe doivent être adaptées aux méthodes d’attaque modernes. Le MFA doit être activé sur les accès distants et interfaces sensibles lorsque la technologie le permet.

Les comptes de service doivent utiliser des secrets longs et difficiles à attaquer hors ligne, ou des mécanismes de gestion automatisée lorsque ceux-ci sont disponibles. Les comptes privilégiés doivent faire l’objet d’un niveau de protection supérieur aux comptes utilisateurs standards.

Limiter NTLM et les mécanismes hérités

Lorsque les contraintes de compatibilité le permettent, l’utilisation de protocoles et mécanismes hérités doit être progressivement réduite. LLMNR et NBT-NS peuvent notamment être désactivés lorsqu’ils ne sont pas nécessaires.

La réduction de NTLM nécessite généralement une démarche progressive : inventaire des usages, journalisation, tests puis durcissement. Les protections des services susceptibles de recevoir une authentification doivent également être activées afin de limiter les attaques par relay pendant cette transition.

Exiger les protections contre les attaques de relay

La signature SMB, la signature LDAP, le channel binding et Extended Protection for Authentication jouent un rôle important selon les protocoles concernés. Les organisations utilisant des versions anciennes ou ayant conservé des configurations historiques doivent vérifier explicitement leurs paramètres plutôt que supposer que les protections sont actives.

Le durcissement doit également prendre en compte les services HTTP utilisant l’authentification intégrée Windows, notamment lorsqu’ils occupent une fonction sensible comme l’enrôlement de certificats.

Segmenter les réseaux selon les besoins réels

La segmentation doit empêcher un poste utilisateur compromis de communiquer librement avec toutes les ressources sensibles. Les flux vers les contrôleurs de domaine, consoles d’administration, serveurs de sauvegarde, hyperviseurs et autres composants critiques doivent être limités aux systèmes qui en ont besoin.

La qualité d’une segmentation se mesure à son efficacité réelle face à un scénario de compromission, pas uniquement à l’existence de VLAN. Les règles de filtrage doivent être régulièrement confrontées aux usages réels et aux chemins d’attaque observés lors des audits.

Appliquer le principe du moindre privilège

Les droits Active Directory doivent être régulièrement revus. Les groupes historiques, délégations inutiles et ACL héritées créent progressivement des chemins d’attaque difficiles à identifier.

La cartographie des relations de privilèges permet de détecter ces dépendances avant qu’un attaquant ne puisse les exploiter. Le même principe doit être appliqué aux plateformes d’administration, aux bases de données, aux environnements cloud et aux relations de confiance entre domaines.

Protéger les comptes privilégiés

Les comptes d’administration ne doivent pas être utilisés pour des opérations courantes. Il est notamment important d’éviter qu’un compte disposant de privilèges sur le domaine s’authentifie régulièrement sur des postes utilisateurs ou des serveurs moins sécurisés.

Une séparation claire des niveaux d’administration réduit la possibilité qu’une première compromission expose immédiatement des identifiants critiques. Les postes d’administration dédiés, la segmentation et les politiques de connexion font partie des contrôles permettant de matérialiser cette séparation.

Sécuriser les comptes administrateurs locaux et les comptes de service

Les mots de passe d’administration locale ne doivent pas être réutilisés sur l’ensemble du parc. Windows LAPS peut être utilisé pour automatiser leur rotation et limiter les conséquences d’une compromission locale.

Les comptes de service traditionnels doivent, lorsque cela est compatible avec les applications, être remplacés par des mécanismes permettant une gestion automatique des secrets. Les gMSA constituent déjà une amélioration importante, tandis que les environnements Windows Server 2025 peuvent également étudier l’utilisation des dMSA pour les scénarios compatibles.

Auditer régulièrement Active Directory, AD CS et les relations de confiance

Les permissions et configurations Active Directory évoluent constamment. Une délégation temporaire peut devenir permanente. Un ancien groupe peut conserver des droits. Un nouveau modèle de certificat peut introduire un chemin d’attaque.

Les trusts, SIDHistory, GPO, comptes de service et configurations AD CS doivent donc faire l’objet de revues régulières et pas uniquement d’un contrôle initial lors de leur déploiement.

Protéger les infrastructures d’administration et d’identité hybride

Configuration Manager, les hyperviseurs, les solutions de sauvegarde, les outils de supervision et les serveurs d’identité hybride doivent être traités comme des infrastructures privilégiées. Leur accès réseau et administratif doit être fortement restreint.

Leur criticité doit être évaluée en fonction de ce qu’ils permettent d’administrer. Un système qui peut déployer du code sur plusieurs centaines de postes ou participer au processus d’authentification peut représenter un actif aussi sensible qu’un serveur classiquement considéré comme Tier 0.

Sécuriser les mécanismes réseau de niveau 2

IPv6, DHCP et les mécanismes de découverte doivent faire partie de la politique de sécurité même lorsqu’ils ne constituent pas les technologies les plus visibles de l’organisation. Un protocole laissé actif mais non supervisé peut créer une surface d’attaque que les mécanismes de défense habituels surveillent moins efficacement.

Les protections disponibles sur les commutateurs doivent être activées lorsque cela est pertinent et la configuration IPv6 réelle des postes doit être comprise, même si l’organisation n’a pas déployé volontairement de services métiers sur IPv6.

Conclusion

Le pentest réseau ne consiste pas simplement à scanner des adresses IP à la recherche de ports ouverts ou de logiciels vulnérables. Son objectif est de comprendre comment un attaquant pourrait réellement progresser dans une infrastructure à partir d’un point d’accès donné.

Cette démarche nécessite d’analyser simultanément les services exposés, les mécanismes d’authentification, les permissions, la segmentation, les identités, les infrastructures d’administration et les relations de confiance entre les systèmes.

Dans les environnements Active Directory en particulier, les compromissions les plus importantes ne reposent pas toujours sur une vulnérabilité critique isolée. Elles résultent souvent de l’accumulation de permissions excessives, de comptes insuffisamment protégés, de protocoles hérités ou de configurations historiques qui créent progressivement des chemins d’attaque.

Les architectures modernes élargissent encore cette logique. Les infrastructures de certificats, plateformes d’administration centralisée, bases de données interconnectées, composants d’identité hybride ou protocoles IPv6 peuvent introduire de nouveaux chemins qui ne sont pas visibles dans une approche limitée aux vulnérabilités des postes et serveurs.

C’est précisément la valeur d’un pentest réseau : ne pas considérer chaque faiblesse indépendamment, mais vérifier comment elles peuvent être combinées dans un scénario réaliste. Un audit correctement mené permet ainsi de déterminer jusqu’où un attaquant pourrait progresser, quels actifs pourraient être atteints et, surtout, quelles mesures de sécurité permettront de casser les chemins d’attaque avant qu’ils ne puissent être exploités dans le cadre d’une compromission réelle.