Fondamentaux de la reconnaissance
Cartographier la surface d'attaque pour trouver ce que les autres ratent
Ce que vous allez découvrir
🎯 Pourquoi c'est important
Les meilleurs bugs se cachent sur des actifs que les autres ne savent pas exister. Un sous-domaine oublié, une ancienne version d'API, un serveur de staging - c'est là que vous trouvez des vulnérabilités critiques. Alors que des centaines de chasseurs se font concurrence sur le site principal, une reconnaissance minutieuse vous permet de trouver des cibles rien que pour vous. Une bonne recon fait souvent la différence entre des duplicatas constants et des primes régulières.
🔍 Ce que vous apprendrez
- Énumération de sous-domaines (passive et active) et pourquoi ça fonctionne
- Techniques de découverte de contenu et d'endpoints
- Fingerprinting technologique pour guider vos tests
- Analyse de données historiques (Wayback Machine et autres sources)
- Construire un workflow de recon complet avec des exemples pratiques
🚀 Votre première victoire
À la fin de ce chapitre, vous aurez une méthodologie de reconnaissance complète qui découvre la surface d'attaque cachée - et vous comprendrez POURQUOI chaque technique fonctionne.
🔧 Essayez maintenant
Lancez une reconnaissance de base sur n'importe quelle cible dans le scope (utilisez example.com pour vous entraîner) :
# ÉTAPE 1 : Trouver les sous-domaines (passif - utilise des sources de données publiques)
subfinder -d <target> -o subdomains.txt
# Attendu : Liste de sous-domaines sauvegardée dans subdomains.txt
# Exemple de sortie : api.target.com, staging.target.com, dev.target.com
# ÉTAPE 2 : Vérifier quels sous-domaines sont actifs (ont des serveurs web)
cat subdomains.txt | httpx -o live.txt
# Attendu : Seuls les hôtes qui répondent sont sauvegardés dans live.txt
# Ce sont vos vraies cibles
# ÉTAPE 3 : Trouver les répertoires et fichiers cachés
ffuf -u https://<target>/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt
# Attendu : Liste de chemins découverts comme /admin, /api, /backup
# ÉTAPE 4 : Vérifier les URLs historiques (ce qui existait dans le passé)
echo "<target>" | waybackurls | tee wayback.txt
# Attendu : URLs archivées par la Wayback Machine au fil des ansIndicateur de succès : Vous verrez des sous-domaines, des hôtes actifs, des chemins cachés et des URLs historiques - des actifs que vous ne trouveriez jamais en cliquant sur le site web.
Compétences que vous maîtriserez
Énumération de sous-domaines
Trouver tous les sous-domaines avec des techniques passives et actives
Découverte de contenu
Découvrir les répertoires, fichiers et endpoints API cachés
Analyse historique
Trouver les endpoints oubliés avec les données archivées
Construction de workflow
Combiner les outils en un processus efficace et reproductible
Comprendre la reconnaissance
"Vous ne pouvez pas hacker ce que vous ne savez pas exister. La recon est là où le bug bounty se gagne ou se perd."
Reconnaissance passive vs active
Il existe deux approches fondamentalement différentes de la reconnaissance :
Recon passive — Collecter des informations sans toucher directement la cible. Vous interrogez des bases de données tierces, des moteurs de recherche et des registres publics. La cible ne sait pas que vous faites des recherches car vous ne lui envoyez jamais de trafic.
Recon active — Interagir directement avec la cible pour découvrir des informations. Cela inclut le scan de ports, le brute-force de répertoires et le brute-force de sous-domaines. La cible peut voir ce trafic dans ses logs.
Pourquoi c'est important : La recon passive est toujours sûre et dans le scope. La recon active peut être restreinte par les règles du programme (certains interdisent le scan automatisé). Vérifiez toujours la politique du programme, et en cas de doute, commencez en passif.
Pourquoi l'énumération de sous-domaines fonctionne
Vous vous demandez peut-être : comment les outils peuvent-ils trouver des sous-domaines sans interroger la cible ? Internet laisse des traces partout :
- Logs de Certificate Transparency : Quand une entreprise obtient un certificat SSL pour api.company.com, il est enregistré publiquement. Les outils interrogent ces logs.
- Enregistrements DNS : Certains fournisseurs DNS permettent les transferts de zone ou ont des bases de données interrogeables.
- Moteurs de recherche : Google indexe des pages, et ces pages font souvent des liens vers des sous-domaines.
- Archives web : La Wayback Machine crawle internet et enregistre les URLs qu'elle trouve, y compris les sous-domaines.
- Recherche en sécurité : Des services comme Shodan et Censys scannent activement internet et enregistrent ce qu'ils trouvent.
Des outils comme subfinder interrogent toutes ces sources simultanément, vous donnant des sous-domaines qui prendraient des heures à trouver manuellement - en quelques secondes.
Pourquoi les URLs historiques comptent
La Wayback Machine (archive.org) crawle internet depuis 1996, sauvegardant des snapshots de sites web. Quand les développeurs suppriment une fonctionnalité d'un site web, ils :
- Suppriment le lien du frontend
- Oublient de supprimer le code backend
L'endpoint existe toujours et fonctionne toujours - ils supposent qu'il est sûr parce que personne ne peut le trouver. Mais la Wayback Machine se souvient. Des outils comme waybackurls vous permettent de voir chaque URL qui a existé sur un domaine, révélant des endpoints "cachés" qui peuvent encore être vulnérables.
Workflow de reconnaissance
Étape 1 : Énumération de sous-domaines
Trouvez tous les sous-domaines appartenant à votre cible. Commencez en passif, puis passez en actif si le scope le permet.
# ÉNUMÉRATION PASSIVE (sûre, pas de contact direct avec la cible)
# Ces outils interrogent des bases de données publiques, pas la cible elle-même
# Subfinder - rapide, interroge de nombreuses sources
subfinder -d <target> -o subs_subfinder.txt
# Ce qu'il fait : Interroge les logs de certificats, bases DNS, moteurs de recherche
# Sortie attendue : 50-500+ sous-domaines selon la taille de la cible
# Amass - minutieux, prend plus de temps mais trouve plus
amass enum -passive -d <target> -o subs_amass.txt
# Ce qu'il fait : Interroge encore plus de sources que subfinder
# Sortie attendue : Trouve souvent des sous-domaines supplémentaires que subfinder rate
# Note : Peut prendre 5-15 minutes pour les grosses cibles
# Assetfinder - rapide et simple
assetfinder <target> >> subs_assetfinder.txt
# Ce qu'il fait : Recherche rapide depuis les sources communes
# Sortie attendue : Chevauche avec ci-dessus mais trouve occasionnellement des uniques
# Combiner tous les résultats et supprimer les doublons
cat subs_*.txt | sort -u > all_subdomains.txt
# Ce que ça fait : Fusionne tous les fichiers, trie alphabétiquement, supprime les doublons
# Sortie attendue : Une liste propre de sous-domaines uniques
# ─────────────────────────────────────────────────────────
# ÉNUMÉRATION ACTIVE (vérifiez le scope d'abord !)
# Ceci envoie du trafic à la cible - ne faites que si le programme le permet
# Brute-force de devinette de sous-domaines
ffuf -u https://FUZZ.<target> \
-w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
-mc 200,301,302,403
# Ce qu'il fait : Essaie les noms de sous-domaines courants (admin, api, dev, staging...)
# -mc : N'afficher que ces codes de statut (filtrer les réponses "not found")
# Sortie attendue : Sous-domaines qui existent mais n'étaient pas dans les bases publiques
# IMPORTANT : Le brute-forcing actif peut déclencher du rate limiting ou des alertes
# Soyez respectueux, utilisez un nombre de threads raisonnable, vérifiez les règlesÉtape 2 : Découverte des hôtes actifs
Tous les sous-domaines n'ont pas de serveurs web actifs. Filtrez pour ne garder que les hôtes qui répondent vraiment.
# Sonder les serveurs web actifs
cat all_subdomains.txt | httpx -o live_hosts.txt
# Ce qu'il fait : Envoie des requêtes HTTP à chaque sous-domaine, garde ceux qui répondent
# Sortie attendue : Sous-ensemble de sous-domaines avec des serveurs web actifs
# C'est votre vraie liste de cibles
# Obtenir plus de détails sur chaque hôte actif
cat all_subdomains.txt | httpx -status-code -title -tech-detect -o detailed_hosts.txt
# Infos supplémentaires :
# -status-code : Montre le statut HTTP (200, 301, 403, etc.)
# -title : Montre le titre de page (révèle ce qu'est l'app)
# -tech-detect : Identifie les technologies (WordPress, React, nginx, etc.)
# Cela aide à prioriser - les titres intéressants comme "Admin Panel" ou "API Docs" ressortent
# Vérifier les ports non-standard (beaucoup d'apps ne tournent pas sur 80/443)
cat all_subdomains.txt | httpx -ports 80,443,8080,8443,8000,3000,9000 -o all_ports.txt
# Ce qu'il fait : Vérifie les ports web courants au-delà des défauts
# Pourquoi : Les serveurs de développement tournent souvent sur le port 3000, 8080, etc.
# Trouver un serveur dev sur le port 8080 est souvent plus précieux que le site principalÉtape 3 : Découverte de contenu
Trouvez les répertoires, fichiers et endpoints cachés qui ne sont pas liés depuis les pages principales.
# FUZZING DE RÉPERTOIRES
# "Fuzzing" signifie essayer beaucoup d'entrées pour voir ce qui existe
# Trouver les répertoires cachés
ffuf -u https://<target>/FUZZ \
-w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
-fc 404
# Ce qu'il fait : Remplace FUZZ par chaque mot de la wordlist
# Exemple : essaie /admin, /backup, /config, /api, etc.
# -fc 404 : Filtrer (cacher) les réponses 404 "Not Found"
# Sortie attendue : Répertoires qui existent mais ne sont liés nulle part
# Trouver les fichiers cachés
ffuf -u https://<target>/FUZZ \
-w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt \
-fc 404
# Cherche des fichiers comme : config.php, .htaccess, backup.sql, .git/config
# Ceux-ci peuvent contenir des informations sensibles
# DÉCOUVERTE D'ENDPOINTS API
ffuf -u https://<target>/api/FUZZ \
-w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt
# Patterns API courants : /api/users, /api/v1/accounts, /api/admin
# Les APIs sont souvent moins protégées que les interfaces web
# DÉCOUVERTE DE PARAMÈTRES
# Une fois que vous trouvez un endpoint, découvrez quels paramètres il accepte
arjun -u https://<target>/endpoint
# Ce qu'il fait : Essaie les noms de paramètres courants pour voir lesquels l'endpoint accepte
# Exemple : Découvre que /search accepte ?q=, ?page=, ?debug=
# Trouver des paramètres cachés comme ?debug=true peut révéler des vulnérabilités
# NOTE SUR LES WORDLISTS :
# SecLists est la collection de wordlists standard de l'industrie
# Installation : git clone https://github.com/danielmiessler/SecLists.git /usr/share/seclists
# Ou : apt install seclists (sur Kali/Debian)Étape 4 : Analyse historique
Trouvez les URLs qui existaient dans le passé - des endpoints oubliés qui peuvent encore fonctionner.
# URLs WAYBACK MACHINE
echo "<target>" | waybackurls | tee wayback_urls.txt
# Ce qu'il fait : Interroge la Wayback Machine pour toutes les URLs archivées pour ce domaine
# Sortie attendue : Des centaines à des milliers d'URLs historiques
# Ce sont des URLs qui existaient à un moment donné - beaucoup peuvent encore fonctionner
# GAU - Get All URLs (interroge plusieurs sources)
gau <target> | tee gau_urls.txt
# Ce qu'il fait : Interroge Wayback Machine + Common Crawl + autres archives
# Trouve souvent plus d'URLs que waybackurls seul
# FILTRER LES ENDPOINTS INTÉRESSANTS
# Trouver les types de fichiers potentiellement vulnérables
cat wayback_urls.txt | grep -E '\.(php|asp|aspx|jsp|json|xml|txt|log|bak|old)' | sort -u
# Pourquoi : Ces types de fichiers traitent souvent des entrées (vuln aux injections) ou contiennent des données
# Trouver les URLs avec paramètres (points d'injection potentiels)
cat wayback_urls.txt | grep '=' | sort -u
# Pourquoi : Les paramètres sont là où vont les entrées utilisateur - cibles principales pour XSS, SQLi, IDOR
# Exemples trouvés : /search?q=, /user?id=, /download?file=
# Trouver les endpoints API
cat wayback_urls.txt | grep -E '/api/|/v1/|/v2/|/graphql' | sort -u
# Pourquoi : Les APIs ont souvent des problèmes d'autorisation, surtout les anciennes versions
# Trouver les chemins admin/sensibles
cat wayback_urls.txt | grep -iE 'admin|backup|config|debug|test|staging' | sort -u
# Pourquoi : Ces chemins ont souvent une sécurité plus faible ou exposent des infos sensibles
# IMPORTANT : Une URL dans l'archive ne garantit pas qu'elle fonctionne encore
# Testez chaque URL intéressante pour voir si elle répond encoreVraies victoires de recon
🏆 Le serveur de staging oublié
Un chasseur a lancé subfinder et trouvé staging.company.com dans les résultats. Le site principal était sécurisé, mais le serveur de staging avait le mode debug activé. Les messages d'erreur exposaient les identifiants de base de données, menant à une prime de 5 000$ pour divulgation d'informations.
Leçon : Les environnements non-production (staging, dev, test, uat) ont souvent une sécurité plus faible parce que les développeurs supposent qu'ils sont cachés. Ils ne le sont pas. Énumérez toujours les sous-domaines.
🏆 La mine d'or Wayback Machine
Les URLs historiques ont révélé un ancien endpoint API /api/v1/users/export qui avait été retiré du frontend il y a deux ans. Le chasseur l'a essayé - l'endpoint fonctionnait encore et n'avait pas d'authentification. Il a dumpé toute la base de données utilisateurs. Prime de 15 000$.
Leçon : Les développeurs suppriment les liens de l'interface mais oublient de supprimer le code backend. La Wayback Machine se souvient de ce qu'ils ont oublié. Vérifiez toujours les URLs historiques.
🏆 La découverte du port non-standard
Après n'avoir rien trouvé sur le site principal, un chasseur a lancé httpx avec scan de ports. Le port 8443 avait un panneau admin pour l'outillage interne de l'application - avec des identifiants par défaut. Capacité de prise de contrôle de compte complète, évalué Critique.
Leçon : Ne supposez pas que toutes les apps web tournent sur les ports 80/443. Les outils de développement, panneaux admin et apps internes tournent souvent sur des ports non-standard. Vérifiez 8080, 8443, 3000 et d'autres.
Questions fréquemment posées
Combien de temps la recon devrait-elle prendre ?
Recon initiale : 1-2 heures pour une nouvelle cible est raisonnable. Lancez vos outils, examinez les résultats, identifiez les actifs intéressants.
Recon continue : Mettez en place une surveillance automatisée pour détecter les nouveaux sous-domaines et changements (couvert dans le chapitre Automatisation).
Équilibre : Ne passez pas des semaines en recon avant de tester. L'objectif est de trouver des vulnérabilités, pas de construire un inventaire parfait des actifs. Alternez entre recon et tests.
Le brute forcing de sous-domaines est-il autorisé ?
Énumération passive (subfinder, amass mode passif) : Toujours sûre. Vous interrogez des bases de données tierces, pas la cible.
Brute forcing actif : Vérifiez les règles du programme. La plupart des programmes avec scope wildcard (*.target.com) l'autorisent, mais certains interdisent explicitement le scan automatisé. En cas de doute, demandez ou restez aux méthodes passives.
Rate limiting : Même quand c'est autorisé, soyez respectueux. Utilisez un nombre de threads raisonnable, ajoutez des délais si nécessaire. Vous faire bloquer n'aide personne.
Et si je ne peux pas installer ces outils ?
Des alternatives en ligne existent :
- Sous-domaines : crt.sh (recherche de certificate transparency), dnsdumpster.com
- URLs historiques : web.archive.org (site web Wayback Machine)
- Détection de technologies : extension navigateur Wappalyzer
Les outils sont plus rapides et plus complets, mais vous pouvez faire de la recon utile avec rien qu'un navigateur web si nécessaire.
Comment savoir ce qui est vraiment dans le scope ?
Lisez attentivement la politique du programme. Patterns de scope courants :
*.company.com - Tout sous-domaine est dans le scope
www.company.com uniquement - Seulement le site principal, rien d'autre
URLs spécifiques listées - Seulement ces cibles exactes
Quand un sous-domaine que vous trouvez n'est pas explicitement mentionné, vérifiez s'il correspond au wildcard ou demandez au programme. Tester des actifs hors scope retire votre protection légale.
Où trouver des wordlists ?
SecLists est le standard - une collection organisée de wordlists pour tous les besoins de tests de sécurité :
git clone https://github.com/danielmiessler/SecLists.git
Il inclut des wordlists pour l'énumération de sous-domaines, le fuzzing de répertoires, les noms de paramètres, les mots de passe courants et bien plus. La plupart des exemples de ce cours supposent que vous avez SecLists installé.
🎯 Vous maîtrisez la recon !
Vous avez maintenant un workflow de reconnaissance complet et comprenez pourquoi chaque technique fonctionne. Énumération de sous-domaines, découverte d'hôtes actifs, fuzzing de contenu, analyse historique - vous trouverez une surface d'attaque que les autres chasseurs ratent.
Prêt à construire votre méthodologie de test →