OSINT Framework : quel outil pour quelle brique de
la collecte

Vous cherchez par où commencer une reconnaissance, un lien vous amène sur OSINT Framework, vous dépliez la branche Domain Name : une quarantaine de services s'affichent d'un coup. Le réflexe qui suit est presque toujours le même, ouvrir le premier, revenir, ouvrir le deuxième, jusqu'à ce que la lassitude tranche à votre place. Et beaucoup de visiteurs repartent de cette page en cherchant encore le bouton "scanner" qui n'y est pas.

Le projet, maintenu par Justin Nordine, range des centaines de ressources de renseignement en sources ouvertes sous une trentaine de branches. C'est un annuaire, et un annuaire vous dit où chercher, jamais dans quel ordre, ni ce que chaque source rate, ni quand elle ment. Reprendre cette matière et la découper par objectif de collecte plutôt que par type de donnée d'entrée change ce qu'on en tire : six briques, chacune avec son rendement, son angle mort et sa limite juridique. Pour la définition du domaine et le cycle du renseignement qui structure une investigation, le socle est posé dans l'article OSINT, le renseignement en source ouverte.

Ce qu'est réellement OSINT Framework

Le projet se résume à un fichier de données et à une visualisation. Les ressources sont décrites dans un arbre JSON, publié sur le dépôt GitHub du projet, et rendues côté navigateur sous forme de dendrogramme dépliable. Chaque feuille porte un nom, une URL, et parfois un code entre parenthèses qui renseigne sur la nature de la ressource : un outil à installer et à lancer localement, une requête de type dork à recopier dans un moteur, un service qui exige une inscription, ou une URL à modifier manuellement pour y insérer votre terme de recherche.

OSINT Framework
├── Username
├── Email Address
│   ├── Email Search
│   ├── Common Email Formats
│   └── Email Verification
├── Domain Name
│   ├── Whois Records
│   ├── Subdomains
│   ├── Certificate Search
│   ├── Passive DNS
│   └── Web History
├── IP Address
├── Images / Videos / Docs
├── Social Networks
├── Instant Messaging
├── People Search Engines
├── Dating
├── Telephone Numbers
├── Public Records
├── Business Records
├── Dark Web
├── Digital Currency
├── Malicious File Analysis
├── Exploits & Advisories
└── OpSec

Cette organisation répond à une question précise : "j'ai cette donnée en main, où puis-je la faire fructifier ?". C'est le bon réflexe quand on a un pivot isolé et qu'on ne sait pas par où le prendre. En revanche, elle ne répond jamais à la question que se pose un pentester ou un RSSI : "je veux l'inventaire complet des actifs exposés de cette organisation, par quoi je commence et quand est-ce que je m'arrête ?". Les branches Domain Name, IP Address et Business Records contiennent chacune un morceau de la réponse, mais l'arbre ne dit pas qu'elles s'enchaînent, ni dans quel sens.

Pourquoi une arborescence de liens vieillit mal

Un annuaire est une photographie de l'écosystème à un instant donné, et l'écosystème OSINT bouge plus vite que sa documentation. Trois mécanismes usent ce type de ressource, et ils frappent tous les annuaires, pas seulement celui-ci.

• La mortalité des services gratuits : un service OSINT gratuit vit de la bonne volonté de son auteur ou d'un palier d'appel offert par un fournisseur. Quand l'un des deux s'arrête, le lien reste, la page renvoie un 404 ou, pire, un domaine racheté qui affiche autre chose. Un annuaire de plusieurs centaines d'entrées accumule mécaniquement ce genre de résidu.
• La fermeture des accès programmatiques : l'API publique de Twitter, socle d'une bonne moitié des outils d'OSINT social, a cessé d'être gratuite en février 2023, et une génération entière de scripts est morte avec elle. Côté moteurs d'appareils, les paliers communautaires se sont resserrés : les filtres de recherche Shodan sont réservés aux comptes payants, et Censys a progressivement restreint l'accès libre à son API de recherche. Le lien reste valide, l'usage ne l'est plus.
• La disparition de réflexes entiers : Google a retiré le lien "en cache" de ses résultats début 2024, puis l'opérateur cache: qui allait avec. Des années de tutoriels et de fiches mémo enseignent encore une manipulation qui ne produit plus rien. C'est le pire cas de figure : pas une erreur visible, juste un résultat vide qu'on interprète comme "il n'y a rien".

La conséquence pratique n'est pas d'abandonner l'annuaire, c'est d'arrêter de le lire comme une liste de courses. On garde les branches, qui elles ne périment pas, parce qu'un certificat TLS journalisé publiquement restera un certificat TLS journalisé publiquement, et on remplace les feuilles à mesure qu'elles tombent. Autrement dit : on retient les objectifs, pas les URL.

Brique 1 : l'empreinte de noms de domaine

Si vous ne deviez en travailler qu'une, ce serait celle-ci : elle coûte le moins et rapporte le plus. Depuis que les navigateurs exigent que tout certificat de confiance publique soit journalisé, chaque nom couvert par un certificat émis atterrit dans les journaux de Certificate Transparency, registres publics, en append-only, consultables par n'importe qui. Une machine de préproduction qu'on a protégée en TLS "pour bien faire" s'annonce ainsi au monde entier le jour de son déploiement.

L'interrogation de référence passe par crt.sh, le moteur opéré par Sectigo qui agrège les journaux CT. Son interface web suffit pour un coup d'œil, mais l'intérêt réel tient à ses deux accès programmatiques : une sortie JSON, et un endpoint PostgreSQL public en lecture seule qui accepte de vraies requêtes SQL.

# tous les noms couverts par un certificat émis pour exemple.com
curl -s 'https://crt.sh/?q=%25.exemple.com&output=json' \
  | jq -r '.[].name_value' \
  | tr 'A-Z' 'a-z' | sed 's/^\*\.//' | sort -u > ct.txt

# énumération passive, deux moteurs qui n'ont pas les mêmes sources
subfinder -d exemple.com -all -silent > sf.txt
amass enum -passive -d exemple.com -o amass.txt

sort -u ct.txt sf.txt amass.txt > noms.txt
wc -l noms.txt

Ce que ça trouve. Les sous-domaines qu'aucun lien public ne référence, les environnements de recette, les portails d'administration, les noms de filiales qu'on ne rattachait plus au groupe. C'est la source privilégiée du shadow IT et le premier endroit où repérer un sous-domaine vulnérable au takeover, parce que le nom survit toujours au service qu'il désignait.

Ce que ça rate. Trois angles morts, rarement mentionnés dans les tutoriels. D'abord, un organisme qui déploie un certificat wildcard unique n'expose qu'une seule ligne dans les journaux : *.exemple.com ne dit rien des cent noms qu'il couvre. Ensuite, les journaux CT sont en ajout seul : ils accumulent quinze ans de noms morts, et une liste brute de crt.sh contient couramment plus de fantômes que d'actifs vivants. Enfin, tout ce qui n'a jamais reçu de certificat de confiance publique reste invisible, à commencer par les services internes en HTTP nu ou en PKI privée.

Note d'outillage. Amass est un projet OWASP écrit en Go, et sa version 4 a réorganisé le fonctionnement interne autour d'une base de graphe, faisant disparaître au passage plusieurs sous-commandes que d'innombrables articles citent encore. Si une commande copiée sur un blog échoue, vérifiez la version avant de conclure à un problème d'installation. Subfinder, de ProjectDiscovery, est plus simple et plus rapide, mais son rendement dépend entièrement des clés d'API renseignées dans son fichier de configuration : sans elles, il tourne sur une poignée de sources gratuites et vous croirez, à tort, avoir fait le tour.

Brique 2 : l'infrastructure exposée

Une fois les noms résolus en adresses, la question devient : qu'y a-t-il derrière. Des moteurs balayent en permanence l'espace d'adressage et publient un index de ce qui répond. Shodan, lancé par John Matherly en 2009, reste la référence ; Censys, issu des travaux de l'équipe ZMap de l'université du Michigan, indexe avec une forte emphase sur les certificats ; FOFA et ZoomEye, chinois, couvrent parfois des plages et des ports que les précédents traitent mal ; Onyphe, français, vaut un test si la localisation des données compte pour vous. Le premier a sa syntaxe, ses fenêtres temporelles et ses filtres réservés aux plans payants : on a détaillé ce que Shodan indexe et comment l'interroger sur son propre périmètre à part, parce que cette brique-là justifie un article entier à elle seule.

Le rendement de la brique tient à des services qu'on croyait restreints au réseau interne, des interfaces d'administration sur des ports non standards, des bases de données sans authentification, des équipements réseau en fin de vie. La technique la plus sous-estimée porte sur les empreintes de favicon : le hachage de l'icône d'un site est un filtre de recherche à part entière, et il permet de retrouver l'ensemble des instances d'un même produit, y compris celles hébergées sous un nom que vous ne connaissiez pas.

Le piège, lui, est unique et concerne tous ces moteurs de la même façon : ils répondent depuis un index constitué en amont, pas depuis la machine. La mesure que vous lisez peut avoir plusieurs semaines, ce qui suffit à faire conclure à une régression qui n'existe pas ou à une absence d'exposition qui n'est qu'un retard d'indexation. Une conséquence pratique en découle : la date de l'enregistrement se lit avant son contenu.

Brique 3 : les personnes et le périmètre de l'organisation

C'est la brique la plus délicate, et celle où le registre change. Dans un travail défensif, l'objectif n'est pas de savoir qui fait quoi dans l'entreprise : c'est de déterminer deux choses, le format des adresses professionnelles et le périmètre juridique réel du groupe. Le premier conditionne l'exposition au hameçonnage ciblé, le second détermine quels domaines vous devez surveiller.

Le périmètre se reconstitue à partir de registres officiels et gratuits, ce qui, pour une organisation française, est nettement plus fiable que les réseaux sociaux : l'annuaire des entreprises publié par l'administration, les données du registre national des entreprises, les annonces du BODACC pour les opérations de croissance externe. Une filiale rachetée trois ans plus tôt apporte avec elle ses domaines, ses certificats et souvent son shadow IT ; elle n'apparaît dans aucun inventaire technique, mais elle figure dans les publications légales. C'est typiquement le genre de rattachement qui transforme un périmètre de vingt domaines en périmètre de soixante.

Ce que ça rate. Les profils publics sont déclaratifs et vieillissent : un organigramme reconstitué depuis un réseau social professionnel contient des départs, des intitulés de poste optimisés et des rattachements erronés. Le construire en croyant obtenir la réalité de l'entreprise est une erreur de méthode.

Brique 4 : le code publié et les secrets

Un accès obtenu par une clé oubliée ne demande aucune vulnérabilité. La recherche de code sur les grandes forges publiques, couplée à des scanners d'entropie et de motifs comme gitleaks ou TruffleHog, produit régulièrement des jetons d'API, des identifiants de service et des clés privées. Le point qui compte tient en une phrase : ces outils parcourent l'historique git, pas seulement l'état courant. Un secret supprimé dans un commit correctif reste parfaitement lisible dans le commit qui l'a introduit, et c'est ce qui explique la longévité de ce type de fuite de secrets.

Le gisement voisin, largement ignoré, ce sont les artefacts de build laissés en production. Un fichier de source map publié à côté du bundle JavaScript reconstitue le code source d'origine, commentaires compris, et expose au passage les routes d'une API qu'aucune documentation publique ne mentionne. Un paquet publié par erreur sur un registre npm ou PyPI produit le même effet, en pire, puisqu'il est versionné et souvent impossible à retirer proprement.

Ce que ça rate. Les dépôts privés, évidemment, mais aussi les historiques réécrits par force. Et il faut connaître un biais devenu structurant : les grandes forges détectent elles-mêmes les jetons au format reconnaissable des fournisseurs partenaires et les font révoquer automatiquement. Ce qui survit à ce filet, ce sont donc surtout les secrets maison, ceux de vos propres services internes, les moins surveillés et les plus longs à faire tourner.

Brique 5 : les archives et l'historique

Le web garde la mémoire de ce que vous avez retiré. L'Internet Archive expose une API d'index, la CDX, qui liste toutes les URL capturées pour un domaine, avec leurs dates et leurs codes de retour. C'est un inventaire de vos anciennes routes, y compris celles qui ont été "supprimées" en retirant simplement le lien qui y menait.

# toutes les URL archivées pour un domaine, dédoublonnées
curl -s 'http://web.archive.org/cdx/search/cdx?url=exemple.com/*&output=text&fl=original&collapse=urlkey' \
  | sort -u > archive.txt

# les mêmes, agrégées depuis plusieurs sources d'archives
gau exemple.com | sort -u > gau.txt

# le fichier le plus instructif du lot : les robots.txt d'époque,
# c'est-à-dire la liste de ce qu'on ne voulait pas voir indexé
grep -i 'robots.txt' archive.txt

On en tire des chemins d'administration abandonnés mais toujours servis, des paramètres d'URL révélant la structure d'une application, des versions antérieures de bundles JavaScript qui référencent des points d'entrée d'API depuis supprimés de la documentation. Et les anciens robots.txt, qui sont un aveu écrit : on y liste, pour les moteurs, les répertoires qu'on souhaitait discrets.

Restent hors de portée toutes les pages qu'aucun robot d'archivage n'a explorées : celles derrière authentification, les réponses à des requêtes POST, les applications monopages dont le contenu n'apparaît qu'après exécution du JavaScript. La couverture est aussi très inégale selon la notoriété du domaine : un site vitrine régional peut n'avoir que quelques dizaines de captures sur dix ans.

Brique 6 : les métadonnées de documents

Les fichiers publiés sur un site institutionnel, rapports, plaquettes, formulaires, transportent leur contexte de fabrication. ExifTool, l'outil de Phil Harvey, lit à peu près tous les formats et sort ces champs en une commande.

# récupérer les documents publiés puis lire leurs métadonnées
exiftool -Author -Creator -Producer -Software -CreateDate -ModifyDate *.pdf

# ce qui sort le plus souvent :
#   Author   -> un identifiant de compte, donc le format de login interne
#   Producer -> le logiciel ET sa version, donc l'état du parc bureautique
#   Creator  -> parfois un chemin réseau complet, donc un nom de serveur

La prise la plus utile est le format des comptes internes, souvent différent du format des adresses de messagerie, donc une information que la brique 3 ne donne pas. Viennent ensuite des versions logicielles qui datent le parc, et parfois un chemin de partage réseau resté dans le champ de création, avec un nom de serveur au bout.

Autant le dire franchement, c'est la brique que vous traiterez en dernier : son rendement s'est effondré depuis dix ans. Les chaînes de publication modernes réencodent les documents, les systèmes de gestion de contenu retraitent les images et les outils de génération de PDF côté serveur n'écrivent plus de nom d'auteur. Quant à l'outillage historique de cette discipline, il faut être honnête : FOCA, l'interface graphique Windows qui a popularisé la technique, n'est plus activement développée, et les moissonneurs de documents de la même génération sont pour la plupart à l'abandon. ExifTool, lui, reste solide.

Ce que les outils ne font pas à votre place

Additionnez les six briques et vous obtenez quelques milliers de lignes. Ce n'est pas un inventaire, c'est un tas. La valeur se crée à l'étape suivante, celle qu'aucune arborescence de liens ne mentionne : l'attribution. Décider qu'un nom trouvé appartient bien à l'organisation, qu'il pointe vers un service vivant, et qu'il relève de son périmètre de responsabilité.

Les deux erreurs coûtent, mais pas de la même façon. Rattacher à tort un actif tiers à votre périmètre vous fait tester ce qui ne vous appartient pas : c'est du temps perdu au mieux, un problème juridique au pire. Le cas classique vient du typosquatting, où un domaine ressemblant au vôtre appartient justement à quelqu'un qui vous veut du mal. À l'inverse, écarter un actif réel parce qu'il est hébergé chez un prestataire laisse un trou béant, et c'est le mode de défaillance le plus fréquent. Le sujet est traité en détail dans l'article sur la découverte d'actifs.

Le cas des agrégateurs

Trois outils prétendent recoller ces morceaux, et il faut regarder leur état réel plutôt que leur réputation. Maltego reste le meilleur outil de mise en relation quand l'enquête est fortement relationnelle ; son édition communautaire plafonne toutefois le nombre de résultats renvoyés par transform, ce qui la rend inadaptée à un périmètre de taille industrielle. SpiderFoot automatise réellement l'enchaînement des modules, mais le rythme de développement de sa version libre a nettement ralenti depuis le rachat du projet par un éditeur commercial. recon-ng, enfin, a une ergonomie modulaire toujours agréable, mais son activité de développement est devenue faible et une partie des modules de sa place de marché ne fonctionnent plus, victimes des fermetures d'API décrites plus haut.

Le constat n'est pas un jugement sur leurs auteurs, c'est une propriété du domaine : un agrégateur dépend de dizaines de sources tierces qu'il ne contrôle pas, donc il se dégrade tout seul dès qu'on cesse de l'entretenir. C'est la même mécanique qui périme un annuaire de liens, un cran plus haut.

De la collecte ponctuelle à la surveillance continue

Toutes ces briques partagent un défaut commun : elles produisent un résultat daté du jour où on les a lancées. Or un certificat émis ce soir crée un nom demain, une équipe métier ouvre un service la semaine prochaine, et un développeur pousse un dépôt le mois prochain. Une collecte menée correctement en août est fausse en octobre, et personne ne vous préviendra.

La gestion de surface d'attaque externe s'attaque à ce défaut-là : mêmes sources, même logique d'attribution, mais la collecte tourne en boucle et chaque passage est comparé au précédent, de sorte que la sortie devienne un différentiel. La plateforme EASM d'own2pwn applique ces briques à votre périmètre, ce qui vous évite surtout d'entretenir vous-même une trousse d'outils dont la moitié se périmera dans l'année.

Questions fréquentes sur OSINT Framework et les outils OSINT

À retenir

• OSINT Framework est un annuaire, pas un outil : une arborescence de liens maintenue par Justin Nordine, rangée par type de donnée d'entrée. Elle sert au cadrage, elle ne collecte rien.
• Un annuaire se périme par ses feuilles, pas par ses branches : services gratuits qui ferment, API qui deviennent payantes, réflexes qui disparaissent comme l'opérateur de cache Google retiré en 2024. Retenez les objectifs, remplacez les URL.
• Organisez la collecte par objectif : empreinte de noms, infrastructure exposée, personnes et périmètre, code publié, archives, métadonnées. Certificate Transparency est la brique la plus rentable ; un certificat wildcard en annule presque tout le bénéfice.
• Chaque source a un angle mort à connaître : les journaux CT accumulent les noms morts, les moteurs d'appareils répondent avec une donnée datée, les archives ignorent tout ce qui exige une authentification.
• La ligne juridique est l'accès, pas la lecture : l'article 323-1 du code pénal punit l'accès et le maintien frauduleux, et la Cour de cassation a jugé en 2015 qu'un document atteignable via un moteur ne donne aucun droit d'y accéder. Le RGPD et l'article 226-18 encadrent tout ce qui touche aux personnes.
• L'attribution est le vrai travail : décider qu'un actif trouvé vous appartient, qu'il est joignable et qu'il est exposé. Aucun outil de la liste ne le fait pour vous.

Gardez de tout ça une seule habitude : avant d'ouvrir un outil, dire à voix haute quelle brique vous traitez et ce qu'elle ne vous montrera pas. Cette phrase-là ne se périme pas, contrairement à l'annuaire d'où vous tirerez l'outil. Si vous voulez voir ce que ces six briques donnent sur votre propre périmètre, sans monter la chaîne vous-même, c'est le métier de la plateforme EASM. Et si vous préférez que quelqu'un pousse la reconnaissance jusqu'à l'exploitation, en conditions réelles et sous mandat, cela s'appelle un pentest web en boîte noire. Un doute sur votre exposition ? La page contact est ouverte.