La reconnaissance active en test d'intrusion : cartographier l'infrastructure cible

Introduction

La reconnaissance active constitue une phase charnière du test d'intrusion où le pentester interagit directement avec l'infrastructure cible pour obtenir des informations techniques précises sur les services, versions et vulnérabilités potentielles. Contrairement à la reconnaissance passive qui se limite à la collecte d'informations publiquement accessibles, cette approche génère du trafic vers le périmètre audité et permet d'obtenir une vision détaillée de l'environnement technique.

Cette phase s'avère cruciale car elle permet de transformer les informations générales collectées passivement en une cartographie précise de l'infrastructure, constituant ainsi la base solide nécessaire à une phase d'exploitation efficace.

Méthodologie de reconnaissance active

Scan de port

L'une des premières étapes consiste à faire un scan de port. Ce scan permettra de mettre en évidence les différents services exposés. Il peut être agrémenté d'une détection de bannière ainsi que les versions pour lesquelles ces services fonctionnent. Un outil comme nmap (https://nmap.org/) permet de faire ces différentes découvertes avec la commande suivante :

$ nmap -sV $IP -oA res_nmap_version_$IP
---
# -sV: détéction des versions
# -oA: export des résultats dans différents format

Exploration du site

Après le scan de port, celui-ci aura remonté les différents services disponibles. Pour les services web, la première étape est d'observer à quoi il ressemble. Dans le cas où de nombreuses instances sont découvertes un outil comme gowitness peut servir pour faire une capture de chacune des instances disponible avec la commande suivantes:

$ gowitness nmap -f res_nmap_version_$IP.xml --open --service-contains http
---
# -f: fichier de résultat nmap
# --open: check seulement les ports ouverts
# --service-contains: pour les ports ouverts ne prend que ceux identifiés comme étant des services web

Et ensuite les résultats sont consultables visuellement sur une interface web ce qui permet de faciliter les différentes observations :

$ gowitness report server

Ensuite, après la capture d'image de ces instances, il est temps de les consulter pour observer concrètement les applications web. Avant cela, il est intéressant d'utiliser l'extension de navigateur Wappalyzer (https://addons.mozilla.org/fr/firefox/addon/wappalyzer/) pour déterminer les technologies qui sont utilisées par l'application.

De plus, avant de rentrer l'URL dans le navigateur, il est important de proxyfier tout le contenu qui passera par celui-ci pour avoir un historique de chaque requête réalisée sur l'application. Ce proxy permettra également de rejouer les requêtes ou même d'intercepter des requêtes pour les modifier avant qu'elles ne soient reçues par le serveur audité.

Pour le choix du proxy, il en existe plusieurs. La plus connue étant Burp Suite qui propose une version pro avec un grand nombre de fonctionnalités. Une alternative gratuite est ZAP mis en avant par l'OWASP et aujourd'hui maintenu par Checkmarx. Un dernier projet qui a vu le jour récemment est Caido qui commence à se faire une place dans le monde offensif.

L'objectif de cette étape sera de se promener sur l'application pour visiter un maximum de page, découvrir tous les champs disponibles de l'application, ainsi que les différentes fonctionnalités comme les formulaires de contact ou les formulaires d'envoi de document. Ici, l'objectif n'est pas de tester ces éléments, mais juste de prendre note de leurs existences pour ensuite les tester à la phase d'exploitation.

Fuzzing orienté web

L'exploration du site permettra de découvrir une majorité des pages exposées par l'application, cependant certains éléments ne seront pas directement disponibles au consultable sur le site. Pour cela un fuzzer web pourra se charger de tester un grand nombre de fichiers et de répertoires pour observer ces éléments. Comme pour les proxys dans la section précédente, il en existe un grand nombre.
Les 3 suivants peuvent être mentionnés :
- Feroxbuster en rust
- gobuster en go
- dirsearch en python

Pour accompagner ces fuzzers, il faut également une liste d'éléments (fichiers et répertoires) à lui donner en entrée pour les tester sur l'application cible aussi communément appelée wordlist. L'une des listes les plus exhaustives est maintenue sur le repo github de Daniel Miessler sous le nom de seclist dans la catégorie Discovery/Web-Content: https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content.

Ici de nombreuses wordlists sont utilisables pour découvrir des éléments intéressants lors de test d'intrusion. Suivant les technos qui seront amenées à être auditées, il peut être intéressant d'utiliser des listes plus ciblées, par exemple visant un CMS particulier comme Wordpress ou Joomla. Un point pour trouver des pages plus ciblées serait d'effectuer de l'OSINT pour construire wordlist qui soit plus en accord avec le contexte métier de l'audité.

$ feroxbuster -u https://$IP --rate-limit 50 -w $wordlist --collect-extensions --collect-
backups -o res_feroxbuster_$IP -r
---
-u: URL cible
-r: suivre les redirections
--rate-limit: Limitation sur le nombre de requête par secondes
-w: wordlists qui contient 
--collect-extensions: récupérer les extensions
--collect-backups: récupere les fichiers de backup

https://epi052.github.io/feroxbuster-docs/docs/

$ gobuster dir  -u https://$IP -w $wordlist -r -x php,aspx,jsp -t 50 -o res_gobuster_$IP.txt
---
-u: URL à auditeur
-w: wordlist à utiliser pour le fuzzing de fichier/répertoire
-r: follow-redirect
-x: liste d'extension à cibler
-t: Nombre de requête concurrentes
-o: fichier de sortie pour enregistrer les résultats

$ dirsearch -r -u https://$IP -w $wordlist -o res_dirsearch_$IP.txt
---
-r: recursivité sur les répertoires
-u: cible à auditer
-w: wordlist à utiliser pour le fuzzing de fichier/répertoire
-o: fichier de sortie pour enregistrer les résultats

Scan de vulnérabilités

Pour compléter les éléments découverts jusqu'à présent, un scanner de vulnérabilité peut amener à découvrir d'autres informations concernant des failles publiques. L'un des plus connues qui existe depuis de nombreuses années étant nikto maintenu par Chris Sullo.

$ nikto -h https://$IP -o res_nikto_$IP.txt
---
-h: cible à auditer
-o: fichier qui va enregistrer les résultats de nikto

Ensuite, depuis quelques années maintenant, un autre scanner lui a fait de l'ombre. Il s'agit de nuclei maintenu par la société Project Discovery. Celui-ci est beaucoup plus complet et propose de nombreux templates pour trouver des vulnérabilités ou des pistes d'exploitations pour la phase suivante. Les templates officiels se trouvent ici : https://github.com/projectdiscovery/nuclei-templates. Typiquement à l'heure de l'écriture de cet article il recense 3197 templates concernant des CVEs. Il est également possible dans trouver sur d'autre repos pour compléter ce repo officiel ou encore de les écrire soi-même (https://www.youtube.com/watch?v=nFXygQdtjyw) si il n'existe pas.

$ nuclei -u https://$IP -o res_nuclei_$IP.txt
---
-u: cible à auditer
-o: fichier qui enregistre les résultats du scan nuclei

Conclusion

La reconnaissance active constitue le fondement d'un test d'intrusion efficace. Elle transforme les informations générales collectées passivement en une cartographie précise et exploitable de l'infrastructure cible. La maîtrise des outils et techniques présentés, combinée à une approche méthodique et documentée, permet d'optimiser significativement la phase d'exploitation qui suit.

Il convient cependant de garder à l'esprit que cette phase génère du trafic détectable par les équipes de sécurité. Dans le contexte d'un test d'intrusion autorisé, cet aspect peut être assumé, l'objectif étant l'exhaustivité plutôt que la discrétion. Cette approche permet d'identifier un maximum de vecteurs d'attaque pour évaluer au mieux la posture de sécurité de l'organisation auditée.

La transition vers la phase d'exploitation s'effectue ainsi avec une base solide d'informations techniques, permettant aux auditeurs de concentrer leurs efforts sur les vecteurs d'attaque les plus prometteurs et d'optimiser l'efficacité de leurs tests.

Cet article complète l’article sur la « Reconnaissance passive : comprendre la première phase d'un test de pénétration »