Active reconnaissance, understanding the first phase of a penetration test

Active recognition in penetration testing: mapping the target infrastructure

Introduction

Active reconnaissance is a key phase in penetration testing, where the pentester interacts directly with the target infrastructure to obtain precise technical information on services, versions and potential vulnerabilities. Unlike passive reconnaissance, which is limited to gathering publicly accessible information, this approach generates traffic to the audited perimeter and provides a detailed view of the technical environment.

This phase is crucial, as it transforms the passively collected general information into a precise mapping of the infrastructure, providing the solid basis for an efficient operation phase.

Active recognition methodology

Port scan

One of the first steps is to perform a port scan. This scan will highlight the various services exposed. It can be enhanced with banner detection, as well as the versions for which these services work. A tool such as nmap (https://nmap.org/) can be used to make these discoveries with the following command:

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

Site exploration

Once the port scan has been completed, it will be able to identify the various services available. For web services, the first step is to observe what they look like. If many instances are found, a tool like gowitness can be used to capture each of the instances available with the following command:

$ 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

The results can then be consulted visually on a web interface, which facilitates the various observations:

$ gowitness report server

Once you've captured the image of these instances, it's time to consult them for a closer look at the web applications. Before doing so, it's a good idea to use the Wappalyzer browser extension (https://addons.mozilla.org/fr/firefox/addon/wappalyzer/) to determine which technologies are used by the application.

What's more, before entering the URL into the browser, it's important to proxyfy all content passing through it, so as to have a history of every request made to the application. This proxy can also be used to replay requests or even intercept requests to modify them before they are received by the audited server.

When it comes to choosing a proxy, there are several to choose from. The best known is Burp Suite which offers a pro version with a wide range of features. A free alternative is ZAP highlighted by the OWASP now maintained by Checkmarx. A final project recently launched is Caido who is beginning to make a name for himself in the attacking world.

The aim of this stage is to around the application to visit as many pages as possible, to discover all the fields available in the application, as well as the various functions such as contact forms and document submission forms. The aim here is not to test these elements, but simply to take note of their existence and then test them in the operational phase.

Web-oriented fuzzing

Exploration of the site will reveal most of the pages displayed by the application, but some elements will not be directly available for consultation on the site. For this purpose, a web fuzzer can test a large number of files and directories to observe these elements. As with the proxies described in the previous section, there are a large number of them.
The following 3 can be mentioned:
- Feroxbuster in rust
- gobuster en go
- dirsearch in python

To accompany these fuzzers, you also need a list of items (files and directories) to give it as input for testing on the target application, also commonly known as a wordlist. One of the most exhaustive lists is maintained on Daniel Miessler's github repo under the name seclist in the Discovery/Web-Content category: https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content.

Here, a number of wordlists can be used to uncover interesting items during the intrusion test. Depending on the technology to be audited, it may be worthwhile to use more targeted lists, for example targeting a particular CMS such as Wordpress or Joomla. One way of finding more targeted pages would be to use OSINT to build a wordlist that's more in tune with the audited company's business context.

$ 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

Vulnerability scanning

In addition to the elements discovered so far, a vulnerability scanner can uncover other information about public vulnerabilities. One of the best-known of these, which has been around for many years, is nikto maintained by Chris Sullo.

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

Then, for some years now, another scanner has been overshadowing it. This is the nuclei maintained by the company Project Discovery. This one is much more complete, with numerous templates for finding vulnerabilities or exploits for the next phase. The official templates can be found here : https://github.com/projectdiscovery/nuclei-templates. Typically, at the time of writing this article, there are 3197 templates for CVEs. It's also possible to find them on other repos to complement this official repo, or to write them yourself (https://www.youtube.com/watch?v=nFXygQdtjyw) if it doesn't exist.

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

Conclusion

Active reconnaissance is the foundation of effective penetration testing. It transforms the general information gathered passively into a precise, usable map of the target infrastructure. Mastery of the tools and techniques presented, combined with a methodical, documented approach, significantly optimizes the exploitation phase that follows.

It should be borne in mind, however, that this phase generates traffic that can be detected by security teams. In the context of an authorized penetration test, this aspect can be assumed, the objective being completeness rather than discretion. This approach makes it possible to identify as many attack vectors as possible, so as to best assess the security posture of the organization being audited.

The transition to the operational phase is thus made with a solid base of technical information, enabling auditors to focus their efforts on the most promising attack vectors and optimize the effectiveness of their tests.

This article completes the article "Passive reconnaissance: understanding the first phase of a penetration test"