Feroxbuster 2026 : Fuzzing Web et Directory Discovery — Guide Complet

Feroxbuster s'est imposé comme l'un des outils de référence en pentest web pour la découverte de répertoires et de fichiers cachés. Écrit en Rust, il se distingue par des performances brutes bien supérieures à ses concurrents historiques écrits en Python ou en Go : là où dirsearch plafonne à quelques centaines de requêtes par seconde, Feroxbuster expédie sans effort plusieurs milliers de requêtes simultanées grâce à son modèle asynchrone basé sur Tokio. Lors d'un engagement de test d'intrusion web, la phase de découverte de contenu est souvent décisive : elle révèle les panneaux d'administration oubliés, les fichiers de sauvegarde exposés (.bak, .old, .zip), les configurations accessibles (.env, web.config, .htaccess), et les endpoints d'API non documentés. Dans ce guide complet, Ayi NEDJIMI vous présente l'ensemble de l'écosystème Feroxbuster : installation sur différentes plateformes, sélection des wordlists SecLists adaptées, maîtrise des options avancées (filtres, récursion automatique, authentification, proxy Burp Suite), stratégies de bypass WAF, et positionnement clair face à gobuster, ffuf et dirsearch. Que vous débutiez en sécurité offensive ou que vous cherchiez à optimiser vos workflows de pentest, ce tutoriel couvre tout ce que vous devez savoir pour exploiter Feroxbuster à son plein potentiel en 2026.

Présentation de Feroxbuster : un scanner de répertoires web taillé pour la performance

Feroxbuster est un outil de directory and content discovery conçu pour les professionnels de la sécurité offensive. Développé initialement par epi052 et publié sur GitHub à partir de 2020, il a rapidement séduit la communauté pentest grâce à une architecture profondément différente de ses prédécesseurs. Là où la majorité des outils similaires reposent sur Python (dirsearch, wfuzz) ou Go (gobuster), Feroxbuster est entièrement écrit en Rust, un langage système qui offre des garanties de sécurité mémoire sans garbage collector, et surtout des performances d'exécution comparables au C.

Le principe de fonctionnement est simple : Feroxbuster envoie des requêtes HTTP/HTTPS vers une URL cible en substituant des entrées d'une wordlist dans le chemin de la requête, puis analyse les réponses pour identifier les ressources existantes. Ce processus, appelé fuzzing de répertoires ou directory brute-forcing, est fondamental lors d'un audit de sécurité web. Il permet de cartographier la surface d'attaque réelle d'une application, souvent bien plus étendue que ce que l'interface visible laisse supposer.

Ce qui distingue fondamentalement Feroxbuster des autres outils, c'est sa gestion native de la récursion automatique. Gobuster, par exemple, ne descend pas automatiquement dans les sous-répertoires découverts : il faut relancer manuellement l'outil sur chaque chemin trouvé. Feroxbuster gère cela nativement et peut explorer plusieurs niveaux de profondeur en une seule exécution. Sur un engagement de pentest réel contre une application complexe, cela représente un gain de temps considérable.

Du point de vue des performances brutes, des benchmarks réalisés en conditions réelles montrent que Feroxbuster avec 50 threads dépasse généralement 3 000 à 5 000 requêtes par seconde sur un réseau local, là où gobuster plafonne plus tôt et où dirsearch tourne souvent autour de 200 à 400 req/s. Cette différence est directement liée au modèle de concurrence : Rust avec Tokio (async/await) utilise un très petit nombre de threads OS pour gérer un grand nombre de connexions simultanées, ce qui est beaucoup plus efficace que le modèle thread-per-request.

Feroxbuster intègre également un résumé interactif en temps réel pendant l'exécution, avec la possibilité de modifier certains paramètres à chaud (pause, ajout de filtres) via le menu interactif. C'est un détail qui peut paraître anodin mais qui se révèle précieux lors de scans longs : on peut affiner les filtres sans interrompre et relancer.

Installation de Feroxbuster : toutes les méthodes

L'installation de Feroxbuster est documentée de manière exhaustive dans son dépôt GitHub officiel, et plusieurs méthodes sont disponibles selon votre environnement de travail.

Via Cargo (recommandé si Rust est installé)
Si vous disposez de la chaîne d'outils Rust sur votre système, l'installation via le gestionnaire de paquets Cargo est la méthode la plus simple et garantit d'obtenir la version la plus récente compilée pour votre architecture :

cargo install feroxbuster

Cette commande télécharge les sources depuis crates.io, les compile et installe le binaire dans ~/.cargo/bin/. Assurez-vous que ce répertoire est dans votre $PATH. La compilation prend quelques minutes la première fois. Pour mettre à jour :

cargo install feroxbuster --force

Via les releases GitHub (binaire précompilé)
Si vous ne souhaitez pas installer Rust, vous pouvez télécharger directement le binaire précompilé depuis la page Releases du projet sur GitHub. Des binaires sont disponibles pour Linux (x86_64, ARM64), macOS et Windows. Téléchargez l'archive correspondant à votre OS, extrayez le binaire et déplacez-le dans votre PATH :

tar -xzf feroxbuster_linux.tar.gz
sudo mv feroxbuster /usr/local/bin/
chmod +x /usr/local/bin/feroxbuster

Sur Kali Linux (méthode apt)
Feroxbuster est inclus dans les dépôts officiels de Kali Linux depuis 2021. L'installation se fait simplement avec :

sudo apt update && sudo apt install feroxbuster

La version disponible dans les dépôts Kali peut légèrement être en retard sur la dernière release GitHub, mais reste généralement récente. Pour les pentesteurs qui travaillent principalement sur Kali, c'est la méthode la plus pratique car elle gère aussi les mises à jour via apt.

Sur Arch Linux / BlackArch
Feroxbuster est également disponible dans le dépôt BlackArch et dans l'AUR pour les utilisateurs d'Arch Linux :

sudo pacman -S feroxbuster  # BlackArch
yay -S feroxbuster          # AUR

Vérification de l'installation
Quelle que soit la méthode utilisée, vérifiez l'installation et la version avec :

feroxbuster --version

En octobre 2026, la branche stable est dans la série 2.x. Consultez le changelog GitHub pour connaître les nouveautés de la version installée. Une installation réussie affiche le numéro de version et confirme que le binaire est correctement dans votre PATH.

Wordlists recommandées : SecLists et au-delà

Un scanner de répertoires est aussi efficace que la wordlist qu'on lui fournit. Le choix de la wordlist est souvent plus important que le choix de l'outil lui-même. La collection SecLists, maintenue par Daniel Miessler sur GitHub, est devenue le standard de facto pour les pentesteurs : elle regroupe des centaines de listes de mots pour toutes les phases d'un audit (répertoires, paramètres, sous-domaines, mots de passe, etc.).

Installation de SecLists
Sur Kali Linux, SecLists est disponible dans les dépôts :

sudo apt install seclists

Les listes sont alors disponibles dans /usr/share/seclists/. Sur d'autres systèmes, clonez le dépôt directement dans /opt/SecLists.

Les wordlists de référence pour le directory fuzzing

• raft-medium-directories.txt (/usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt) : environ 30 000 entrées, basée sur les données de Common Crawl. Excellent rapport qualité/temps, c'est souvent la première wordlist à utiliser.
• directory-list-2.3-medium.txt (/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt) : environ 220 000 entrées, l'une des listes les plus complètes pour les répertoires. Plus lente mais plus exhaustive. Préférer pour les scans approfondis.
• common.txt (/usr/share/seclists/Discovery/Web-Content/common.txt) : environ 4 700 entrées, pour un scan rapide initial. Idéal pour une reconnaissance préliminaire.
• raft-large-files.txt : pour la découverte de fichiers spécifiques (configs, backups). À combiner avec des extensions via -x.
• api/api-endpoints-res.txt : spécialisée pour les endpoints d'API REST. Indispensable sur les applications modernes.

Comment choisir sa wordlist selon le contexte
La stratégie recommandée est d'adopter une approche progressive. Commencez avec common.txt pour une première cartographie rapide, puis relancez avec raft-medium-directories.txt pour approfondir. Réservez directory-list-2.3-medium.txt aux scans exhaustifs quand vous avez du temps devant vous ou que la cible est critique. Pour les applications qui exposent des APIs, ajoutez toujours un passage avec une wordlist spécifique aux endpoints API.

Il est aussi recommandé de créer ses propres wordlists personnalisées selon le contexte de la cible : si vous savez que la cible utilise WordPress, utilisez les wordlists WordPress spécifiques de SecLists. Si c'est une application Java, incluez des chemins typiques comme /struts/, /spring/, /actuator/.

Commandes de base : premiers pas avec Feroxbuster

La syntaxe de Feroxbuster est intuitive et suit les conventions des outils GNU standard. Voici les commandes essentielles pour débuter.

Commande minimale
La commande la plus simple requiert uniquement l'URL cible et la wordlist :

feroxbuster -u http://cible.exemple.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

Par défaut, Feroxbuster utilise 50 threads, une profondeur de récursion de 4, et affiche les réponses avec les codes 200, 204, 301, 302, 307, 308, 401, 403, 405. L'outil affiche en temps réel chaque ressource trouvée avec son code HTTP, la taille de la réponse, le nombre de mots, et le temps de réponse.

Scan HTTPS avec vérification TLS ignorée
Pour les cibles HTTPS dont le certificat est auto-signé ou invalide (fréquent en environnement de lab ou de développement) :

feroxbuster -u https://cible.exemple.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -k

Scan avec extensions de fichiers
Pour rechercher non seulement des répertoires mais aussi des fichiers avec des extensions spécifiques :

feroxbuster -u https://cible.exemple.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -x php,html,js,txt,bak,old,zip,conf,env -k

Cette commande va tester chaque entrée de la wordlist avec et sans chacune des extensions spécifiées, ce qui multiplie le nombre de requêtes. Soyez conscient de cet effet multiplicateur : avec une wordlist de 30 000 entrées et 9 extensions, vous générez jusqu'à 300 000 requêtes.

Limitation du scan à un seul niveau (pas de récursion)
Pour désactiver la récursion automatique et ne scanner que le premier niveau :

feroxbuster -u https://cible.exemple.com -w /usr/share/seclists/Discovery/Web-Content/common.txt -d 1

Options avancées : filtres et performances

La véritable puissance de Feroxbuster réside dans ses options avancées qui permettent de contrôler précisément le comportement du scan et d'éliminer le bruit dans les résultats.

Contrôle des threads (-t)
Le paramètre -t contrôle le nombre de threads concurrents. La valeur par défaut est 50, ce qui est déjà agressif pour beaucoup de cibles. Augmenter prudemment :

feroxbuster -u https://cible.exemple.com -w wordlist.txt -t 100

Attention : un nombre de threads trop élevé peut saturer la connexion réseau, déclencher des mécanismes de protection côté serveur, ou rendre les résultats moins fiables. En pratique, entre 50 et 150 est un bon compromis selon la cible et votre bande passante.

Profondeur de récursion (-d)
La récursion automatique est l'une des fonctionnalités clés de Feroxbuster. Le paramètre -d (depth) contrôle jusqu'à quelle profondeur l'outil descend dans les sous-répertoires découverts. La valeur par défaut est 4. Pour une application complexe avec une arborescence profonde :

feroxbuster -u https://cible.exemple.com -w wordlist.txt -d 6

Pour désactiver complètement la récursion : -d 1. Notez que la récursion peut exponentiellement augmenter le nombre de requêtes si l'application a beaucoup de sous-répertoires.

Extensions (-x)
Comme mentionné, -x permet de spécifier les extensions de fichiers à tester. Un ensemble pertinent pour la majorité des applications web :

feroxbuster -u https://cible.exemple.com -w wordlist.txt -x php,txt,html,js,bak,old,zip,conf,env,xml,json,sql

Filtrage par codes de statut
Par défaut, Feroxbuster affiche les codes 200, 204, 301, 302, 307, 308, 401, 403, 405. Pour inclure uniquement certains codes :

feroxbuster -u https://cible.exemple.com -w wordlist.txt -s 200,301,302,403

Pour filtrer et ne pas afficher certains codes (par exemple, ignorer tous les 404 et les 301 de redirection vers HTTPS) :

feroxbuster -u https://cible.exemple.com -w wordlist.txt --filter-status 404,301

Filtrage par taille de réponse (--filter-size)
Très utile quand le serveur retourne un faux 200 pour toutes les URL inconnues (soft 404). Identifiez d'abord la taille de la réponse pour une URL inexistante, puis filtrez :

feroxbuster -u https://cible.exemple.com -w wordlist.txt --filter-size 1234

Il est possible de spécifier plusieurs tailles séparées par des virgules.

Filtrage par nombre de mots (--filter-words)
Similaire au filtrage par taille, mais basé sur le nombre de mots dans la réponse :

feroxbuster -u https://cible.exemple.com -w wordlist.txt --filter-words 42

Sauvegarde des résultats (-o)
Pour sauvegarder les résultats dans un fichier (utile pour les rapports et le traitement ultérieur) :

feroxbuster -u https://cible.exemple.com -w wordlist.txt -o resultats_ferox.txt

Le fichier de sortie contient toutes les informations affichées à l'écran, dans un format facilement parsable.

Options avancées : authentification et proxy

Dans un contexte de pentest réel, de nombreuses applications nécessitent une authentification pour accéder aux zones intéressantes. Feroxbuster gère nativement l'injection d'en-têtes HTTP personnalisés, de cookies et le routage via proxy.

En-têtes HTTP personnalisés (-H)
L'option -H permet d'ajouter n'importe quel en-tête HTTP à toutes les requêtes. C'est la méthode la plus flexible pour gérer l'authentification :

# Token Bearer
feroxbuster -u https://app.exemple.com/api/ -w wordlist.txt -H "Authorization: Bearer eyJhbGc..."

# Session cookie via en-tête
feroxbuster -u https://app.exemple.com -w wordlist.txt -H "Cookie: session=abc123def456"

# User-Agent personnalisé pour se faire passer pour un navigateur
feroxbuster -u https://app.exemple.com -w wordlist.txt -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Il est possible d'enchaîner plusieurs -H dans une même commande.

Cookies (-b)
Pour passer des cookies de session capturés depuis Burp Suite ou les DevTools du navigateur :

feroxbuster -u https://app.exemple.com -w wordlist.txt -b "PHPSESSID=abc123; auth_token=xyz789"

Proxy vers Burp Suite (--proxy)
L'intégration avec Burp Suite est l'une des fonctionnalités les plus précieuses pour les pentesteurs. Toutes les requêtes de Feroxbuster peuvent être routées à travers Burp Suite pour analyse détaillée :

feroxbuster -u https://app.exemple.com -w wordlist.txt --proxy http://127.0.0.1:8080 -k

Le -k est nécessaire pour ignorer les erreurs de certificat TLS générées par le proxy Burp. Cette configuration vous permet de voir dans l'historique Burp toutes les requêtes envoyées par Feroxbuster.

Replay proxy (--replay-proxy)
Une option plus avancée et très pratique : n'envoyer vers Burp Suite que les requêtes qui ont obtenu une réponse "intéressante" (selon les codes de statut configurés). Cela évite de noyer l'historique Burp avec des milliers de 404 :

feroxbuster -u https://app.exemple.com -w wordlist.txt --replay-proxy http://127.0.0.1:8080 -k

Seules les ressources découvertes (codes dans votre liste d'inclusion) seront visibles dans Burp.

Limitation du parallélisme (--scan-limit)
Lors d'un scan récursif sur une cible avec beaucoup de sous-répertoires, Feroxbuster peut lancer un grand nombre de scans parallèles, ce qui risque de saturer la cible ou votre réseau. L'option --scan-limit permet de limiter le nombre de scans actifs simultanément :

feroxbuster -u https://app.exemple.com -w wordlist.txt --scan-limit 3

Récursion automatique et fichier de configuration

Feroxbuster se distingue par sa gestion sophistiquée de la récursion et sa capacité à être configuré via un fichier de configuration persistant, ce qui simplifie considérablement les workflows répétitifs.

Récursion automatique en détail
Lorsque Feroxbuster découvre un sous-répertoire (généralement signalé par un code 301 ou une réponse 200 pour un chemin terminant par /), il lance automatiquement un nouveau scan de ce sous-répertoire avec la même wordlist et les mêmes options. Ce comportement est contrôlé par le paramètre -d (profondeur maximale).

Exemple de sortie typique avec récursion active :

200      GET      45l     123w    2345c   https://app.exemple.com/admin/
200      GET      12l      34w     567c   https://app.exemple.com/admin/login.php
301      GET       0l       0w       0c   https://app.exemple.com/admin/uploads/
200      GET      89l     234w    4567c   https://app.exemple.com/admin/uploads/temp/

Le résumé final affiché en fin de scan donne les statistiques complètes : nombre total de requêtes, ressources découvertes, durée totale.

Fichier de configuration ferox-config.toml
Pour éviter de retaper constamment les mêmes options, Feroxbuster supporte un fichier de configuration au format TOML. L'emplacement par défaut est $HOME/.config/feroxbuster/ferox-config.toml (Linux/macOS) ou le répertoire courant.

Exemple de configuration type pour un pentesteur :

# ferox-config.toml
wordlist = "/usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt"
threads = 50
depth = 4
timeout = 7
user_agent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
status_codes = [200, 204, 301, 302, 307, 308, 401, 403, 405, 500]
filter_size = []
output = "/tmp/ferox_results.txt"
insecure = false
extensions = []
no_recursion = false

Avec ce fichier de configuration en place, une commande minimale comme feroxbuster -u https://cible.exemple.com héritera de toutes les options définies. Les paramètres passés en ligne de commande écrasent toujours les valeurs du fichier de configuration.

Bypass WAF : techniques et stratégies

Les applications web de production sont souvent protégées par un Web Application Firewall (WAF) ou des mécanismes de rate-limiting qui peuvent bloquer les scans de répertoires agressifs. Feroxbuster offre plusieurs options pour contourner ces protections, mais gardez toujours à l'esprit que ces techniques ne doivent être utilisées que dans le cadre d'un engagement de pentest autorisé.

User-Agent personnalisé
De nombreux WAF bloquent les requêtes dont le User-Agent est celui de Feroxbuster (qui contient par défaut "feroxbuster"). Le remplacer par un User-Agent de navigateur légitime est souvent suffisant pour éviter ce filtre :

feroxbuster -u https://cible.exemple.com -w wordlist.txt \
  -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"

Limitation du débit (--rate-limit)
Pour les cibles avec du rate-limiting strict, réduire le nombre de requêtes par seconde permet d'éviter les blocages :

feroxbuster -u https://cible.exemple.com -w wordlist.txt --rate-limit 100

La valeur représente le nombre maximum de requêtes par seconde. Combiné à une réduction du nombre de threads (-t 10), cela permet d'être très discret.

Rotation via proxy
Si vous disposez de plusieurs adresses IP (via des proxies rotatifs ou un réseau de VPN), vous pouvez router le trafic différemment à chaque scan. Feroxbuster supporte les proxies SOCKS5 :

feroxbuster -u https://cible.exemple.com -w wordlist.txt --proxy socks5://127.0.0.1:9050

Ceci route tout le trafic via Tor, ce qui offre une rotation IP automatique, mais au prix de performances très dégradées.

En-têtes supplémentaires pour imiter un navigateur
Certains WAF vérifient la présence d'en-têtes typiques d'un navigateur. Ajouter des en-têtes comme Accept, Accept-Language, ou Referer peut améliorer la discrétion :

feroxbuster -u https://cible.exemple.com -w wordlist.txt \
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7" \
  -H "Referer: https://www.google.com/"

Fragmentation des scans
Au lieu d'un seul scan massif, découpez le scan en plusieurs petites sessions réparties dans le temps. Utilisez des wordlists plus petites et lancez plusieurs sessions avec des intervalles de quelques minutes entre chaque lot. Cette approche "low-and-slow" est particulièrement efficace contre les WAF basés sur le comportement plutôt que sur la signature.

Comparaison avec les outils concurrents

Le choix entre Feroxbuster, gobuster, ffuf et dirsearch dépend du contexte du test, des préférences personnelles et des contraintes de l'engagement. Voici une comparaison factuelle pour vous aider à faire le bon choix.

Feroxbuster vs Gobuster
Gobuster, écrit en Go, est l'un des outils de directory fuzzing les plus populaires et précède Feroxbuster historiquement. Les principales différences :

• Performances : Feroxbuster est généralement plus rapide en pratique grâce au modèle asynchrone de Rust/Tokio vs le modèle goroutines de Go. Les benchmarks varient selon les conditions réseau, mais Feroxbuster maintient de meilleures performances à haute concurrence.
• Récursion : Feroxbuster gère la récursion nativement. Gobuster ne récurse pas et nécessite des scripts shell ou des outils tiers pour ce comportement.
• Gestion mémoire : Rust garantit l'absence de fuites mémoire et de race conditions, un avantage sur les scans très longs.
• Interface interactive : Feroxbuster propose une interface interactive pendant le scan. Gobuster est plus basique mais reste fiable.
• Quand utiliser gobuster : Si vous êtes habitué à son interface et que vous n'avez pas besoin de récursion, gobuster reste un excellent outil simple et fiable.

Feroxbuster vs ffuf
ffuf (Fuzz Faster u Fool) est peut-être l'outil de fuzzing le plus polyvalent de l'écosystème pentest. Écrit en Go, il supporte le fuzzing de toutes les parties d'une requête HTTP (URL, en-têtes, body, paramètres POST).

• Flexibilité : ffuf est beaucoup plus flexible. Il peut fuzzer des paramètres GET/POST, des en-têtes, des sous-domaines via Host header, etc. Feroxbuster est spécialisé pour le directory/content discovery.
• Récursion : Feroxbuster gagne nettement sur ce point. ffuf ne récurse pas nativement.
• Sortie : ffuf a une sortie plus configurable (JSON, CSV) et de meilleures options de filtrage avancé pour certains cas d'usage.
• Recommandation : Utilisez Feroxbuster pour le directory discovery récursif, et ffuf pour le fuzzing de paramètres, de sous-domaines (VHost fuzzing), et les cas où vous avez besoin de fuzzer des parties non-URL de la requête.

Feroxbuster vs Dirsearch
Dirsearch est un outil Python classique, très populaire il y a quelques années. Il reste utilisé mais montre son âge face aux outils modernes.

• Performances : Feroxbuster est significativement plus rapide. Python, même avec asyncio, ne peut pas rivaliser avec Rust pour ce type de charge I/O intensif. Feroxbuster peut être 10 à 20 fois plus rapide selon les configurations.
• Récursion : Les deux supportent la récursion, mais l'implémentation Feroxbuster est plus robuste et plus rapide.
• Facilité d'installation : Dirsearch ne nécessite que Python (pip install dirsearch), ce qui le rend accessible. Feroxbuster nécessite soit Rust, soit de télécharger un binaire.
• Recommandation : Sauf contrainte spécifique, préférer Feroxbuster pour ses meilleures performances et sa récursion plus efficace.

Workflow pentest complet : Feroxbuster dans l'écosystème offensif

Feroxbuster est rarement utilisé seul. En pratique, il s'intègre dans un workflow de test d'intrusion web plus large qui combine plusieurs outils pour une couverture maximale. Voici comment Ayi NEDJIMI structure typiquement cette phase de reconnaissance dans un engagement de pentest.

Phase 1 : Scan initial rapide avec common.txt
Avant de lancer un scan long, faites un premier passage rapide pour identifier la structure générale de l'application :

feroxbuster -u https://app.exemple.com \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -x php,html,txt \
  -d 2 \
  -t 30 \
  -o /tmp/scan_initial.txt

Phase 2 : Scan approfondi avec raft-medium
Sur la base des résultats initiaux, lancez un scan plus complet sur les zones identifiées comme intéressantes :

feroxbuster -u https://app.exemple.com \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -x php,js,html,bak,old,zip,conf,env,json,xml,sql \
  -d 4 \
  -t 50 \
  --filter-size 1234 \
  --replay-proxy http://127.0.0.1:8080 \
  -k \
  -o /tmp/scan_approfondi.txt

Phase 3 : Analyse avec Burp Suite
Toutes les ressources intéressantes découvertes via le replay-proxy se trouvent dans l'historique de Burp Suite. Vous pouvez alors approfondir l'analyse manuellement : tester les paramètres d'authentification, vérifier les droits d'accès, rechercher des injections, etc. Pour les tests plus systématiques des vulnérabilités applicatives, utilisez Nessus et Greenbone en complément pour couvrir les CVEs connues.

Phase 4 : Compléter avec Nikto
Nikto est un scanner web qui teste spécifiquement les configurations dangereuses et les fichiers connus comme potentiellement vulnérables. Là où Feroxbuster découvre des chemins, Nikto teste leur contenu :

nikto -h https://app.exemple.com -useproxy http://127.0.0.1:8080

Cas d'usage réels : ce que Feroxbuster trouve en pratique

• Panneaux d'administration cachés : /admin/, /administrator/, /wp-admin/, /phpmyadmin/, /adminer/, /cpanel/ — des dizaines de frameworks exposent des interfaces d'administration sous des chemins standards facilement découvrables.
• Fichiers de sauvegarde : config.php.bak, wp-config.php.old, database.sql.zip, backup.tar.gz — des développeurs qui font des sauvegardes directement dans le répertoire web, une erreur plus fréquente qu'on ne le pense.
• Fichiers de configuration exposés : .env (credentials base de données, clés API), web.config, .htaccess, config.yml, application.properties — des informations critiques qui ne devraient jamais être accessibles publiquement.
• Endpoints d'API non documentés : /api/v1/, /api/internal/, /api/admin/, /graphql, /swagger.json — souvent des versions anciennes d'API oubliées mais encore fonctionnelles, parfois sans authentification.

Blue Team : détection des scans Feroxbuster
Du côté défensif, les scans Feroxbuster génèrent des signatures reconnaissables dans les logs web. Un SIEM bien configuré peut alerter sur les patterns suivants :

• Volume anormalement élevé de requêtes 404 provenant d'une même IP en peu de temps
• User-Agent contenant "feroxbuster" dans les logs
• Séquences de requêtes correspondant à des wordlists connues (patterns alphabétiques ou ordres de mots caractéristiques)
• Variations systématiques de chemins avec les mêmes paramètres de base

Des outils comme fail2ban peuvent automatiquement bannir les IPs générant trop d'erreurs 404 en peu de temps. Pour une protection plus avancée, les WAF modernes disposent de règles spécifiques pour détecter et bloquer le directory fuzzing. Pour les tests de ces protections réseau, des outils comme Bettercap et Ettercap permettent de simuler des scénarios d'attaque réseau complémentaires.

Questions fréquentes sur Feroxbuster