Test d’intrusion : commander, cadrer et exploiter un pentest

Un test d’intrusion (pentest) est une attaque réelle, menée par des spécialistes mandatés, sur un périmètre et pendant une période définis par écrit. Son livrable est la liste des portes mal fermées, avec la preuve qu’elles s’ouvrent et ce qu’il y a derrière. Le test se gagne ou se perd surtout côté commanditaire, avant et après les jours de test, bien plus que pendant.

→ Lire l’explication complète de la marmotte

Test d’intrusion, scan, audit, red team, bug bounty : cinq exercices distincts

La confusion la plus coûteuse du sujet consiste à payer le prix d’un pentest pour recevoir un scan avec un logo. Les cinq exercices ne répondent pas à la même question.

Exercice	Question posée	Ce qu’il produit	Ce qu’il ne fait pas
Scan de vulnérabilités	Quelles failles connues sont visibles ?	Liste automatique de CVE (Common Vulnerabilities and Exposures) et de mauvaises configurations	Pas d’exploitation, pas d’enchaînement, beaucoup de faux positifs
Audit de configuration	Les systèmes respectent-ils un référentiel de durcissement ?	Écarts mesurés sur un échantillon, ligne à ligne	Ne prouve pas qu’un écart est exploitable
Test d’intrusion	Jusqu’où un attaquant va-t-il sur ce périmètre, en ce temps ?	Vulnérabilités exploitées, chaînes d’attaque, preuves	Pas d’exhaustivité, pas de mesure de la détection
Red team	L’organisation détecte-t-elle et contient-elle une attaque ciblée ?	Scénario de bout en bout contre un objectif, évaluation de la défense	Pas d’inventaire des failles, discrétion avant couverture
Bug bounty	Que trouvent des chercheurs extérieurs, payés au résultat ?	Signalements au fil de l’eau	Aucune garantie de couverture ni de date

Le scan trouve ce qui ressemble à une faille ; le pentest prouve ce qui en est une, et surtout ce que trois faiblesses moyennes donnent une fois enchaînées. Aucun scanner ne comprend qu’un compte de service lisible sur un partage de fichiers, plus une délégation Kerberos mal posée, valent un domaine Active Directory entier.

La red team n’est pas un « pentest en mieux ». Elle sacrifie l’exhaustivité à la discrétion et ne sert à rien tant que le centre de supervision ne sait pas ce qu’il cherche : lancer une red team sur une organisation qui n’a jamais corrigé un rapport de pentest revient à tester l’alarme d’une maison sans porte. Le bug bounty, lui, complète un pentest sur une surface exposée et déjà mûre ; il ne le remplace pas, car personne n’est payé pour chercher là où les primes sont maigres.

Position assumée : pour une organisation qui n’a pas encore de gestion des vulnérabilités en régime, l’ordre utile est scan outillé en continu, puis pentest ciblé, puis bug bounty ou red team. Inverser l’ordre fait payer cher des trouvailles qu’un outil gratuit aurait listées. Les écarts de configuration se traitent avec la méthode décrite dans la préparation d’un audit de sécurité externe, et les failles applicatives récurrentes relèvent de la rubrique Failles.

Mandat écrit, périmètre et article 323-1 : le cadre qui sépare l’audit de l’infraction

Techniquement, un pentest et une intrusion criminelle utilisent les mêmes outils et les mêmes gestes. Seul le mandat les distingue. L’article 323-1 du Code pénal réprime le fait d’accéder ou de se maintenir frauduleusement dans tout ou partie d’un système de traitement automatisé de données ; dans sa rédaction en vigueur, la peine est de trois ans d’emprisonnement et 100 000 euros d’amende, aggravée quand des données sont supprimées ou modifiées. L’article 323-3-1 vise par ailleurs la détention et la mise à disposition d’outils offensifs sans motif légitime, la recherche et la sécurité informatique étant citées comme motifs légitimes. Le texte fait foi sur Légifrance ; savoir si une situation donnée tombe sous ces articles relève d’un avocat, pas de cette page.

Ce que le mandat doit contenir, au minimum :

Le signataire : quelqu’un qui a réellement autorité sur les systèmes visés. Une direction métier ne peut pas autoriser un test sur l’infrastructure d’une filiale juridiquement distincte.
Le périmètre : adresses IP, plages, noms de domaine, URL, applications, environnements (production ou recette), comptes fournis. Tout ce qui n’est pas listé est exclu.
Les dates et plages horaires, avec les adresses IP sources des auditeurs, pour que la supervision puisse distinguer le test d’une attaque réelle simultanée (cela arrive, et c’est le pire moment pour confondre les deux).
Les techniques exclues : déni de service, ingénierie sociale, modification de données de production, persistance. Le référentiel d’exigences PASSI demande d’ailleurs que les vulnérabilités susceptibles de rendre le système instable ou de provoquer un déni de service ne soient exploitées qu’avec l’accord écrit du commanditaire.
Les contacts d’urgence des deux côtés, joignables pendant les plages de test, et la règle d’arrêt : qui peut stopper le test, comment, en combien de temps.
Le traitement des données rencontrées : les auditeurs verront des données personnelles. Durée de conservation des preuves, chiffrement du rapport, destruction en fin de mission, conformément au RGPD vu depuis l’architecture.

L’oubli le plus fréquent concerne les tiers. Un mandat signé par le client ne vaut pas autorisation de l’hébergeur, de l’infogéreur ou de l’éditeur SaaS (Software as a Service) qui exploite réellement la machine. Les grands fournisseurs cloud publient des politiques de test d’intrusion qui autorisent certains tests sur les ressources du client et en interdisent d’autres (attaque de l’infrastructure partagée, déni de service) ; un hébergeur mutualisé ou un infogéreur exige souvent une notification ou un accord explicite. La vérification se fait dans le contrat ; les clauses de sécurité des contrats fournisseurs gagnent à prévoir ce droit d’audit dès la signature, et non la veille du test.

Ce schéma se lit de haut en bas : aucune flèche ne part du prestataire vers les systèmes tant que toutes les autorisations ne sont pas revenues. Le SOC (Security Operations Center, centre de supervision) est prévenu en dernier mais avant le premier paquet.

Boîte noire, grise ou blanche : ce que chaque approche trouve et rate

L’approche définit l’information donnée aux auditeurs au départ.

Boîte noire : aucune information, aucun compte. On simule un attaquant extérieur anonyme. Elle mesure l’exposition réelle depuis Internet, mais brûle une part du budget en reconnaissance, et tout ce qui se cache derrière une authentification reste hors d’atteinte. Un rapport de boîte noire « sans vulnérabilité critique » sur une application avec page de connexion signifie souvent « l’équipe n’a pas passé la page de connexion ».
Boîte grise : comptes de test fournis (un par rôle métier, idéalement deux par rôle pour tester l’isolation entre utilisateurs), documentation fonctionnelle. Elle trouve les contrôles d’accès cassés, l’élévation de privilèges et l’accès aux données d’un autre client, c’est-à-dire ce que l’OWASP (Open Worldwide Application Security Project) classe en tête de son Top 10 sous le nom de contrôle d’accès défaillant.
Boîte blanche : code source, schémas d’architecture, configurations. Elle trouve le plus par jour facturé, y compris des chemins qu’aucun test dynamique n’atteint, mais elle teste aussi ce que l’organisation croit avoir déployé, qui n’est pas toujours ce qui tourne.

Recommandation : la boîte grise par défaut, pour tout ce qui comporte une authentification. Le vrai attaquant dispose de temps, d’identifiants volés ou achetés et de comptes créés en libre-service ; l’auditeur dispose de quelques jours. Lui faire passer ces jours à deviner un mot de passe revient à payer un spécialiste pour mesurer la patience de l’organisation. La boîte noire se justifie pour une question précise (« que voit Internet de notre surface exposée ? »), la boîte blanche pour une application critique dont le code est disponible.

Les types de tests découpent le périmètre :

Application web et API (Application Programming Interface) : logique métier, contrôles d’accès, injections, gestion de session. Une API sans interface graphique est souvent moins testée que le front web qui l’appelle, alors qu’elle expose exactement les mêmes données sans les garde-fous de l’interface.
Réseau interne : le scénario du poste compromis ou du stagiaire branché sur une prise réseau. Sur un parc Windows, il aboutit très souvent à l’annuaire ; les faiblesses typiques (authentification NTLM, annuaire LDAP interrogeable anonymement) sont détaillées dans les pages sur NTLM et sur l’énumération LDAP anonyme.
Wi-Fi : séparation entre réseau invité et réseau interne, robustesse de l’authentification, points d’accès pirates. Le test se fait sur site, avec les contraintes physiques que cela suppose.
Ingénierie sociale : hameçonnage, appels au support, intrusion physique. Elle touche des personnes, pas des machines : cadrage avec les ressources humaines et respect des règles décrites dans la surveillance des salariés. Un rapport qui nomme les personnes ayant cliqué ne sert qu’à produire de la rancune ; un taux par population et un délai de signalement servent à quelque chose.

Déroulé d’un test d’intrusion : de la reconnaissance au rapport

Les méthodologies publiques décrivent le même squelette : le PTES (Penetration Testing Execution Standard) pour l’ensemble de la mission, l’OWASP WSTG (Web Security Testing Guide) pour le détail des tests applicatifs. Elles servent de référence de couverture : un prestataire qui les cite doit pouvoir dire quels contrôles il a exécutés et lesquels il a écartés, et pourquoi.

La boucle entre exploitation et post-exploitation est le cœur de la valeur : chaque accès obtenu ouvre une nouvelle recherche. La flèche vers le contact d’urgence est celle que les contrats oublient.

Trois règles encadrent les phases sensibles :

Exploitation limitée à la preuve. Lire une ligne d’une table suffit à prouver une injection SQL ; extraire la table entière n’ajoute aucune information et crée un incident de données. La preuve attendue est la plus petite action qui démontre l’impact.
Post-exploitation encadrée. Le rebond vers d’autres systèmes reste dans le périmètre signé, et toute trace laissée (compte créé, fichier déposé, tâche planifiée) est consignée puis supprimée, avec une liste remise au commanditaire. Une porte dérobée de test oubliée en production est une vraie porte dérobée.
Alerte immédiate. Une vulnérabilité critique exposée sur Internet, ou des traces d’une compromission antérieure (un attaquant arrivé avant les auditeurs, ce qui n’a rien d’exotique) n’attendent pas le rapport. Le mandat fixe le canal et le délai.

Choisir un prestataire : qualification PASSI, références et méthode

En France, la qualification PASSI (Prestataire d’Audit de la Sécurité des Systèmes d’Information) est délivrée par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) sur la base d’un référentiel d’exigences publié, qui couvre plusieurs activités : audit d’architecture, de configuration, de code source, d’organisation, et tests d’intrusion. La qualification porte sur des activités précises : un prestataire qualifié pour l’audit de configuration ne l’est pas forcément pour les tests d’intrusion. La liste des prestataires qualifiés et leurs portées est publiée par l’ANSSI ; c’est elle qui fait foi, pas la plaquette.

La qualification ne s’impose pas à tout le monde. Elle est exigée dans certains contextes réglementaires, et dans le secteur financier le règlement DORA prévoit, pour les entités désignées, des tests de pénétration fondés sur la menace (TLPT, Threat-Led Penetration Testing) au moins tous les trois ans, avec leurs propres exigences sur les testeurs ; voir DORA et la résilience opérationnelle. Hors de ces cas, PASSI reste un filtre efficace sur l’encadrement juridique, la gestion des données d’audit et la compétence des auditeurs.

Ce qu’il faut demander, qualification ou non :

Un rapport anonymisé d’une mission comparable. C’est le seul échantillon du livrable réel. Un rapport de quatre-vingts pages de sorties d’outils sans chaîne d’attaque annonce la suite.
Les noms et profils des auditeurs affectés, et l’engagement qu’ils restent sur la mission. Le commercial qui a fait la soutenance n’est pas toujours celui qui teste.
La méthode de cotation : CVSS (Common Vulnerability Scoring System) brut, ou gravité ajustée au contexte avec sa justification.
La part de test manuel. Un devis de deux jours pour une application métier complexe signifie, au mieux, un scanner bien configuré.
Le contre-test : inclus, à quel délai, sur quel périmètre.

Le moins-disant en jours est presque toujours le plus cher en résultat. Le compromis central se situe là : à budget fixe, on achète soit de la largeur (beaucoup de cibles, survolées), soit de la profondeur (peu de cibles, chaînes d’attaque prouvées). Pour un premier pentest, la profondeur sur les deux ou trois actifs les plus exposés vaut mieux qu’un balayage de tout le système d’information ; la largeur relève du scan continu, qui coûte une fraction du prix.

Exemple : une gravité qui dépend du contexte

Le rapport cote chaque vulnérabilité ; la cotation n’a de sens qu’avec la chaîne dans laquelle elle s’inscrit. L’exemple suivant montre trois constats qui, isolés, paraîtraient moyens ou faibles, et dont l’enchaînement mène à une compromission totale.

Lu ligne par ligne, chaque constat se corrige en une heure et ne justifierait pas une réunion. Lu comme une chaîne, il donne le contrôle de l’ensemble du parc Windows depuis une prise réseau. La correction efficace ne se limite donc pas à effacer le mot de passe du champ description : elle porte sur le maillon qui casse la chaîne le plus en amont et le plus durablement, ici l’interdiction du bind anonyme (voir la page dédiée) et le cloisonnement des comptes privilégiés. La preuve finale illustre la règle de l’exploitation minimale : une commande en lecture seule, pas une création de compte.

Lire et exploiter le rapport de pentest

Un rapport exploitable contient : une synthèse pour la direction (les chaînes d’attaque, pas la liste), la méthode et la couverture réelle (ce qui a été testé, ce qui ne l’a pas été et pourquoi), puis chaque constat avec sa preuve, sa gravité justifiée et une recommandation actionnable. Une recommandation du type « appliquer les bonnes pratiques de durcissement » n’en est pas une.

Pour exploiter le rapport :

Recoter la gravité dans le contexte. Le prestataire voit le système ; l’organisation connaît la valeur des données et les compensations existantes. Une injection sur une application de recette sans données réelles ne pèse pas comme la même injection en production. Un ajustement se documente, il ne se négocie pas pour faire baisser les chiffres.
Traiter les causes, pas les instances. Si le rapport signale trois injections, le code en contient probablement trente : la correction porte sur la couche d’accès aux données, pas sur trois paramètres. Corriger le symptôme produit le même rapport l’année suivante, ce qui a au moins le mérite de rassurer sur la constance du prestataire.
Inscrire chaque constat dans la gestion des vulnérabilités existante, avec responsable, échéance et statut, plutôt que dans un tableur propre au pentest. Ce qui n’est pas corrigé s’accumule en dette de sécurité, et cette dette doit être vue et acceptée explicitement.
Exiger le contre-test. Seul le prestataire qui a trouvé la faille peut confirmer qu’elle ne s’exploite plus de la même façon. Une correction déclarée sans contre-test reste une hypothèse.

Les pièges classiques :

Le périmètre trop étroit, choisi pour obtenir un rapport propre. L’attaquant ne lit pas le mandat ; il passera par l’application de facturation oubliée du périmètre.
Le test annuel rituel, même périmètre, même date, même prestataire, commandé pour cocher une case. Il mesure la mémoire du prestataire bien plus que la sécurité ; le test se déclenche plutôt sur événement : mise en production majeure, changement d’architecture, nouvelle exposition Internet. Cocher la case a un coût réel, voir les indicateurs utiles et ceux de façade.
Le rapport utilisé comme certificat. « Pentest réussi » ne veut rien dire ; un auditeur sérieux demandera ce qui a été corrigé, pas ce qui a été testé (preuve de conformité).

Ce qu’un test d’intrusion ne garantit pas

Photographie à un instant. Le rapport décrit le système des jours de test. Le déploiement du lundi suivant ne s’y trouve pas, ni la CVE publiée le mois d’après. La couverture continue vient du scan outillé, de la veille sur les composants et, pour les surfaces exposées mûres, du bug bounty.
Pas de mesure de la détection. L’auditeur cherche à entrer, pas à rester discret, et la supervision est prévenue. Que personne n’ait rien vu ne dit rien de la capacité de détection ; savoir si l’alerte serait levée et traitée relève d’un exercice red team ou purple team, où défense et attaque travaillent ensemble.
Pas d’exhaustivité. Un temps borné couvre ce que des humains compétents trouvent dans ce temps. L’absence de constat critique n’est pas une absence de vulnérabilité critique.
Pas de couverture hors périmètre. Fournisseurs, sous-traitants, applications SaaS : leur exposition relève de la gestion des risques tiers.

Conditions d’exploitation à prévoir dès la commande : sauvegardes vérifiées avant tout test en production, avec une procédure de restauration testée ; comptes de test créés pour la mission puis supprimés ; identifiants révoqués et secrets découverts par les auditeurs renouvelés après la mission, même s’ils jurent ne pas les avoir conservés ; rapport classé et chiffré, car il constitue la meilleure carte d’attaque qui existe sur l’organisation, et sa diffusion se limite à ceux qui corrigent.

🐝 Ce qui arrive si on s’en passe

Sans test d’intrusion, l’exploitabilité réelle des failles reste inconnue : les priorités de correction se fixent sur des scores isolés, et l’effort va aux constats les mieux notés plutôt qu’au maillon qui couperait une chaîne d’attaque. Les défauts d’autorisation (accès aux données d’un autre utilisateur, fonction réservée appelable par un rôle inférieur) échappent aux outils automatiques, car la requête fautive renvoie une réponse valide que rien ne distingue d’un usage normal. Le premier enchaînement complet est alors réalisé par un attaquant, sans limite à la preuve et sans liste des traces laissées. Pendant l’incident, l’équipe de réponse doit reconstituer le chemin d’entrée sous pression, sans carte préalable. Les comptes et secrets exposés ne sont jamais renouvelés, puisque personne ne sait qu’ils le sont.

🦫 Explication de la marmotte 🍫

Une entreprise demande à des spécialistes d’attaquer ses propres ordinateurs pour découvrir ses failles avant les vrais pirates. Tout commence par un contrat écrit : il dit quelles machines peuvent être attaquées, à quelles dates, ce qui est interdit (par exemple faire tomber un service), et qui appeler en cas de problème. Sans ce papier, les mêmes gestes sont un délit puni par la loi. Si les machines sont louées chez un hébergeur, celui-ci doit aussi être d’accord. Les spécialistes observent d’abord ce qui est visible, cherchent ensuite les faiblesses, puis essaient d’en utiliser quelques-unes, juste assez pour prouver qu’elles marchent, sans voler ni casser. Chaque accès obtenu peut en ouvrir un autre : trois petites erreurs mises bout à bout peuvent suffire à prendre le contrôle de tout le réseau. Si l’entreprise donne des comptes de test et des documents, les spécialistes vont plus loin dans le temps payé. À la fin, ils remettent un rapport avec des preuves et des conseils. L’entreprise doit corriger la vraie cause de chaque erreur, pas seulement l’endroit où elle a été vue, puis demander une seconde vérification. Le test a des limites : il ne regarde qu’une période courte, ne trouve pas tout, et ne dit pas si l’équipe de surveillance aurait repéré une vraie attaque.

Pages voisines

La citent

EBIOS RM : analyse de risque et limites pratiques

Test d'intrusion : commander, cadrer et exploiter un pentest

Elle cite