Un site web, vu depuis un navigateur, ne montre jamais qu'une fraction de ce qu'il contient réellement. Derrière la page d'accueil et le menu de navigation se cachent souvent des répertoires jamais liés, des fichiers de sauvegarde oubliés, des interfaces d'administration ou des sous-domaines de test qui n'apparaissent nulle part. Trouver ce contenu invisible, avant qu'un attaquant ne le fasse, est l'un des réflexes les plus concrets d'un test d'intrusion. C'est exactement le rôle de Gobuster, un outil de brute force de répertoires et de sous-domaines que l'équipe Piirates intègre à chacune de ses missions de test d'intrusion.
1. Gobuster en une phrase : du brute force HTTP écrit en Go
Gobuster est un outil open source écrit en Go, un langage compilé réputé pour sa rapidité d'exécution et sa gestion native de la concurrence. Son principe est simple à comprendre : à partir d'une liste de mots (wordlist), il teste chacun d'entre eux contre une cible et observe la réponse obtenue. Un mot testé comme chemin d'URL qui répond avec un code de statut pertinent révèle un répertoire ou un fichier existant. Un mot testé comme sous-domaine qui se résout correctement révèle un hôte jusque-là invisible.
Ce principe de brute force par dictionnaire n'a rien de nouveau en soi. Ce qui distingue Gobuster, c'est sa capacité à tester plusieurs dizaines de milliers de mots en quelques minutes plutôt qu'en plusieurs heures, grâce à des workers concurrents gérés nativement par Go plutôt que par des threads système plus lourds. Une liste de 50 000 entrées, avec un niveau de concurrence adapté à la cible, se teste généralement en quelques minutes sur un hébergement qui répond correctement.
2. Les six modes de Gobuster, une seule logique appliquée à six contextes
Gobuster ne se limite pas à chercher des pages cachées sur un site. Chaque mode correspond à une sous-commande dédiée.
Mode dir : découverte de répertoires et fichiers. Le mode le plus utilisé explore le contenu d'une application web à la recherche de chemins non liés depuis la navigation normale.
gobuster dir -u https://cible.exemple -w wordlist.txt -x php,html,txt,bak -t 50Mode dns : énumération de sous-domaines. Ce mode teste un grand nombre de préfixes contre le domaine cible pour révéler des sous-domaines absents de toute documentation publique.
gobuster dns -d cible.exemple -w subdomains.txt -t 50Mode vhost : découverte de virtual hosts. Sur un hébergement mutualisé où plusieurs sites cohabitent derrière la même adresse IP, ce mode identifie les noms d'hôtes qui répondent différemment de l'hôte par défaut.
gobuster vhost -u https://ip-cible -w vhosts.txt --append-domainMode fuzz : fuzzing générique par mot-clé FUZZ. Ce mode généralise le principe à n'importe quelle position d'une requête HTTP (paramètre, en-tête, corps de requête), en remplaçant le mot-clé FUZZ par chaque entrée de la wordlist.
gobuster fuzz -u https://cible.exemple/api?id=FUZZ -w wordlist.txtMode s3 : recherche de buckets Amazon S3 mal protégés. Ce mode teste l'existence et l'accessibilité de buckets S3 à partir d'une liste de noms probables, souvent dérivés du nom de l'entreprise ou du projet.
Mode gcs : recherche de buckets Google Cloud Storage. Équivalent du mode s3 pour l'écosystème Google Cloud.
Cette polyvalence explique pourquoi Gobuster occupe une place centrale dans la boîte à outils d'un testeur : une seule logique de brute force par dictionnaire, appliquée à six contextes différents, couvre une grande partie de ce qu'une organisation expose sans toujours en avoir pleinement conscience.
Toutes nos missions sont spécifiques
Parce que vos enjeux le sont !
Le test d'intrusion est avant tout une philosophie qui, couplé avec nos compétences techniques multiples peut s'adapter aux diffférentes cibles.
Indépendance totale
Expertise
Professionnalisme
3. Les options qui changent réellement le résultat d'une mission
Lancer Gobuster avec une wordlist générique et les réglages par défaut produit rarement un résultat exploitable. Certaines options font la différence entre un bruit inutile et une découverte décisive.
-w : le choix de la wordlist, le facteur le plus déterminant. Une wordlist mal adaptée au contexte de la cible (technologie, secteur, conventions de nommage) réduit drastiquement le taux de découverte, quelle que soit la puissance de l'outil.
-x : les extensions à tester. Préciser les extensions attendues (php, html, txt, bak, zip, env, config) démultiplie le nombre de requêtes mais permet de révéler des fichiers de configuration ou des sauvegardes oubliées invisibles autrement.
-t : le niveau de concurrence. Un nombre de threads trop élevé sature la cible et déclenche des protections anti-DDoS ou des limitations applicatives ; un nombre trop faible allonge inutilement la durée du test. Ce réglage se dose selon la tolérance réelle de l'infrastructure cible, jamais selon un chiffre générique.
-b et --exclude-length : le filtrage des faux positifs. Un site mal configuré peut répondre avec un code de succès (HTTP 200) même sur une ressource qui n'existe pas, ce qui noie le testeur sous des milliers de résultats inutiles. Exclure les codes de statut non pertinents (-b 404,403) et surtout filtrer par longueur de réponse (--exclude-length) permet d'éliminer ce bruit en identifiant la signature des réponses génériques.
-k : ignorer les erreurs de certificat TLS. Utile sur les environnements de recette ou les cibles internes utilisant des certificats auto-signés, à ne jamais utiliser sans discernement en dehors d'un cadre de mission autorisé.
-o : l'export des résultats. Conserver une trace structurée des résultats est indispensable pour la phase d'analyse manuelle qui suit systématiquement l'énumération automatisée.
4. Quelles wordlists utiliser selon le contexte
La qualité d'un résultat Gobuster dépend directement de la wordlist utilisée, bien plus que des réglages de performance.
Pour une découverte de répertoires généraliste, la wordlist common.txt du projet SecLists offre un bon compromis rapidité/couverture pour une première passe.
Pour une découverte de répertoires exhaustive, directory-list-2.3-medium.txt ou raft-large-directories.txt (également issues de SecLists) couvrent un spectre plus large, au prix d'un temps d'exécution plus long.
Pour l'énumération de sous-domaines, subdomains-top1million-5000.txt ou subdomains-top1million-20000.txt couvrent la grande majorité des préfixes couramment utilisés en entreprise (dev, staging, admin, vpn, mail, api).
Pour un contexte spécifique (CMS identifié, framework connu, secteur d'activité particulier), une wordlist générée sur mesure à partir du vocabulaire métier de la cible surpasse presque toujours une wordlist générique, aussi volumineuse soit-elle.
5. Gobuster face à ffuf, feroxbuster et dirsearch
Gobuster n'est pas le seul outil de brute force de contenu web, et le choix entre ces alternatives dépend du contexte de la mission.
Gobuster vs ffuf. ffuf (Fuzz Faster U Fool) offre une flexibilité supérieure pour le fuzzing multi-paramètres et la personnalisation fine des filtres de réponse, mais avec une courbe d'apprentissage un peu plus longue. Gobuster reste plus direct pour une découverte de répertoires ou de sous-domaines standard.
Gobuster vs feroxbuster. feroxbuster ajoute une récursivité automatique (il explore automatiquement les sous-répertoires découverts), ce qui peut faire gagner du temps sur une arborescence profonde, au prix d'un volume de requêtes plus difficile à maîtriser sur une cible sensible.
Gobuster vs dirsearch. dirsearch, écrit en Python, propose une détection de faux positifs plus automatisée par défaut, mais reste généralement plus lent que Gobuster sur de gros volumes du fait de la nature interprétée du langage.
Dans la pratique, nos pentesters ne s'enferment pas dans un outil unique : le choix se fait selon la nature de la cible, la nécessité de récursivité, et le niveau de discrétion recherché.
6. À quel moment un test d'intrusion s'appuie sur Gobuster
Un test d'intrusion sérieux ne commence jamais par l'attaque directe d'un système. Il commence par une phase de reconnaissance, qui vise à comprendre ce que la cible expose réellement sur Internet. Une première étape, passive, s'appuie sur des sources publiques (DNS, certificats, réseaux sociaux, moteurs de recherche spécialisés). Gobuster prend le relais dans une seconde étape, plus active, qui consiste à interroger directement les systèmes identifiés pour révéler ce que la reconnaissance passive ne peut pas voir.
Concrètement, chez Piirates, cette étape produit régulièrement des découvertes qui orientent la suite complète d'une mission. Un fichier de configuration laissé accessible sur un sous-domaine de test peut contenir les identifiants d'accès à une base de données de production. Une archive de sauvegarde oubliée dans un répertoire non lié peut révéler le code source d'une application entière, avec toutes les failles qu'il contient. Un espace de stockage cloud mal nommé, découvert via le mode s3 ou gcs, peut se retrouver accessible en lecture, parfois même en écriture, sans qu'aucune authentification ne soit demandée.
Ces situations ne relèvent pas de scénarios improbables. Elles reviennent avec une régularité qui surprend souvent les équipes techniques concernées, précisément parce que ce contenu ne figure dans aucun inventaire officiel et échappe donc à tout processus de sécurisation classique.
7. Un usage strictement encadré
Contrairement à un simple outil de consultation, Gobuster envoie des requêtes actives directement vers l'infrastructure ciblée. Son utilisation sans autorisation explicite constitue une infraction pénale en France, au même titre que toute tentative d'accès non autorisé à un système informatique (article 323-1 du Code pénal). Dans le cadre d'un test d'intrusion, chaque utilisation de cet outil s'inscrit dans un périmètre et une fenêtre temporelle précisément définis avec le client, en amont de toute intervention.
Cette rigueur n'est pas une contrainte accessoire. Elle constitue le socle qui distingue un test d'intrusion légitime d'une intrusion réelle, et elle garantit que les découvertes réalisées servent uniquement à renforcer la sécurité de l'organisation concernée.
8. L'approche Piirates
La phase de découverte de contenu n'est jamais traitée comme une simple formalité avant les tests les plus techniques. C'est une étape qui produit, mission après mission, certaines des découvertes les plus décisives d'un audit. Un fichier oublié, un sous-domaine non documenté, un espace de stockage mal protégé, ouvrent souvent la voie la plus directe vers les vulnérabilités les plus critiques.
Cette conviction guide la méthodologie appliquée à chaque test d'intrusion système d'information mené par nos équipes : ne rien laisser au hasard dans l'exploration du périmètre réel d'une organisation, au-delà de ce que celle-ci pense exposer. C'est cette exigence de rigueur, appuyée sur une maîtrise technique éprouvée, qui fait la différence entre un audit de surface et un test d'intrusion qui révèle ce qui compte vraiment.
Évaluer votre périmètre
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Nikto analyse une application web à la recherche de signatures de vulnérabilités connues sur des chemins déjà identifiés. Gobuster, lui, ne connaît rien des vulnérabilités : sa seule mission est de découvrir des chemins, des sous-domaines ou des ressources qui existent mais qui ne sont pas visibles depuis la navigation normale du site. En pratique, les deux outils sont complémentaires : Gobuster élargit la surface connue, puis un scanner ou une analyse manuelle vient l'examiner en détail.
Gobuster convainc par sa simplicité pour une découverte de répertoires ou de sous-domaines standard. ffuf devient préférable dès que le fuzzing doit cibler un paramètre spécifique, un en-tête HTTP, ou nécessite des filtres de réponse plus fins. De nombreux pentesters utilisent les deux selon l'étape de la mission.
La vitesse dépend du nombre de requêtes lancées en parallèle (option -t) et de la capacité de la cible à les absorber. Avec un réglage adapté, une liste de plusieurs dizaines de milliers d'entrées peut être testée en quelques minutes. Cette vitesse doit toujours être ajustée à la tolérance réelle de l'infrastructure cible, dans le respect strict du périmètre défini pour le test d'intrusion.
Oui. Un volume important de requêtes provenant d'une même adresse, sur des chemins variés en peu de temps, correspond exactement au profil qu'un pare-feu applicatif (WAF) est conçu pour détecter et bloquer. Dans un test d'intrusion, cette détection fait souvent partie des éléments évalués, et le rythme des requêtes est alors ajusté selon que l'objectif est la discrétion ou l'évaluation de la capacité de détection du client.
En combinant l'exclusion de codes de statut non pertinents (option -b) et surtout le filtrage par longueur de réponse (--exclude-length), qui permet d'identifier et d'ignorer la signature des pages génériques renvoyées par un site mal configuré, même lorsque celui-ci répond systématiquement avec un code de succès.
La méthode la plus fiable consiste à faire réaliser un test d'intrusion incluant une phase de découverte de contenu sur son propre périmètre, avec l'autorisation explicite requise même sur ses propres infrastructures hébergées par un tiers. Cette démarche donne une image concrète de ce qui est réellement accessible, au-delà de ce que montre la navigation normale du site.
Découvrez comment Gobuster révèle le contenu caché d’un site web et pourquoi cet outil est essentiel dans un test d’intrusion mené par Piirates.
