OSINT défensif : mesurer et réduire l’exposition publique

L’OSINT (Open Source Intelligence, renseignement d’origine sources ouvertes) désigne l’exploitation de l’information qu’une organisation et ses employés ont eux-mêmes rendue publique : documents, offres d’emploi, profils, enregistrements DNS, certificats, code. Un attaquant commence presque toujours par là, parce que c’est gratuit, silencieux et sans risque pour lui. La seule question défensive qui vaille est donc la suivante : que voit-il déjà, et que peut-on retirer, réduire ou compenser ?

→ Lire l’explication complète de la marmotte

OSINT : du renseignement d’État à la surface d’exposition externe

Le terme vient du renseignement militaire et étatique, où l’OSINT côtoie le HUMINT (Human Intelligence, renseignement humain) et le SIGINT (Signals Intelligence, interception des communications). Pendant la guerre froide, une part considérable du renseignement provenait déjà de la presse, des annuaires et des publications techniques de l’adversaire. Le principe n’a pas changé : l’information ouverte, recoupée, finit par produire un savoir que personne n’a jamais voulu divulguer.

Une équipe de sécurité pratique l’OSINT sur sa propre organisation pour trois raisons.

Gestion de la surface d’exposition externe. C’est ce que le marché vend sous le sigle EASM (External Attack Surface Management) : découvrir les actifs exposés que l’inventaire interne ignore. Le serveur de recette ouvert en 2019 « pour deux semaines » figure rarement dans la CMDB (Configuration Management Database, la base d’inventaire), et figure toujours dans les journaux de certificats.
Préparation d’un test d’intrusion. La phase de reconnaissance d’un pentest boîte noire est de l’OSINT. La réaliser en interne avant de payer un prestataire évite de lui faire facturer la découverte de ce qu’un tableur aurait suffi à recenser. Le cadrage d’un tel test est décrit dans Test d’intrusion : commander, cadrer et exploiter un pentest.
Sensibilisation. Une démonstration montrant à une direction son propre organigramme reconstitué depuis les réseaux professionnels, avec le format des adresses électroniques déduit et des cibles d’hameçonnage pré-triées, convainc davantage qu’un module de formation en ligne. Le lien avec le prétexte d’attaque est détaillé dans la page sur l’ingénierie sociale et l’accès initial.

Le compromis central du sujet se pose dès maintenant : une organisation ne peut pas devenir invisible. Elle doit être trouvée par ses clients, recruter, publier des enregistrements DNS, et obtenir des certificats qui sont journalisés publiquement par construction. Chaque réduction d’exposition coûte quelque chose : de l’attractivité pour les recrutements, du confort pour les équipes, parfois de la sécurité ailleurs. La cible n’est donc pas « zéro exposition ». La cible est zéro surprise : chaque élément visible de l’extérieur est connu, attribué à un responsable, et défendu en conséquence.

Sources ouvertes à passer en revue et ce qu’elles révèlent

Sites et documents publiés : les métadonnées

Un PDF (Portable Document Format) ou un document bureautique publié embarque souvent l’auteur, l’identifiant de session Windows, le nom de la société, le logiciel et sa version, parfois des chemins réseau internes (\\srv-fic02\direction\...). Sur un corpus de quelques centaines de documents, on reconstitue une liste de comptes valides et la convention de nommage des serveurs. Les images publiées peuvent conserver des coordonnées GPS (Global Positioning System) et le modèle de l’appareil.

Offres d’emploi : la pile technique

Une offre demandant « maîtrise de FortiGate 7.0, Citrix NetScaler et SAP ECC 6 » annonce à tout lecteur les équipements de bordure et leurs versions. Pour un attaquant, c’est une requête prête à croiser avec les CVE (Common Vulnerabilities and Exposures) exploitées activement. Les archives d’offres restent consultables longtemps après leur retrait, sur les agrégateurs et les sites d’archivage.

Réseaux sociaux professionnels : organigramme et format d’adresse

Les profils publics donnent l’organigramme, les arrivées récentes (moins méfiantes, plus faciles à piéger), les prestataires et les fonctions sensibles : comptabilité fournisseurs, administration système, assistanat de direction. Il suffit de deux adresses connues pour déduire le format (prenom.nom@), ce qui transforme une liste de noms en liste de cibles pour l’hameçonnage et l’attaque par pulvérisation de mots de passe.

Registres de noms de domaine et DNS

Depuis le RGPD (Règlement général sur la protection des données), les données d’enregistrement WHOIS (service historique d’interrogation des registres de noms) et RDAP (Registration Data Access Protocol) sont largement masquées pour les personnes physiques. Les bases historiques, en revanche, conservent les anciennes données. Le DNS (Domain Name System) reste bavard par nature :

les enregistrements MX et l’enregistrement SPF (Sender Policy Framework) désignent la messagerie et chaque service autorisé à envoyer au nom du domaine ;
les enregistrements TXT de vérification (MS=, google-site-verification=, atlassian-domain-verification=) dressent l’inventaire des SaaS (Software as a Service) utilisés ;
un CNAME pointant vers une ressource cloud supprimée ouvre une prise de contrôle de sous-domaine : n’importe qui recrée la ressource et sert du contenu sous le nom de l’organisation.

Journaux Certificate Transparency : les noms d’hôtes

Tout certificat TLS (Transport Layer Security) émis par une autorité publiquement reconnue est inscrit dans des journaux CT (Certificate Transparency) en ajout seul (RFC 6962), et les navigateurs majeurs refusent les certificats non journalisés. Chaque nom présent dans le certificat devient public au moment de l’émission, souvent avant même la mise en service : vpn-test, jenkins-old, admin-preprod. Le mécanisme est détaillé dans Surveiller Certificate Transparency pour son domaine. Ce journal est aussi l’outil défensif le plus rentable du sujet, puisqu’il permet de repérer un certificat émis frauduleusement pour son propre domaine.

Dépôts de code publics : les identifiants publiés par erreur

Clés d’API (Application Programming Interface), jetons d’accès cloud, chaînes de connexion, fichiers .env : tout se retrouve dans les dépôts publics, ceux de l’organisation comme ceux, personnels, des développeurs et des prestataires. Les robots qui balaient les plateformes publiques exploitent une clé cloud en quelques minutes après sa publication. Supprimer le commit ne sert à rien : l’historique, les clones, les forks et les flux d’événements de la plateforme l’ont déjà capturée. La prévention en amont est traitée dans Prévenir les secrets codés en dur dans Git.

Conversations d’assistants IA partagées et indexées

Une conversation avec un assistant d’IA (intelligence artificielle) partagée par un lien public devient une page web. Si elle est rendue découvrable, ou simplement liée depuis une page indexée, les moteurs de recherche la référencent. On y trouve du code interne collé « pour le corriger », des extraits de configuration, des comptes rendus de réunion. Supprimer le lien de partage ne purge ni les caches des moteurs ni les archives. Le sujet est traité dans Liens de partage de conversations IA indexés par les moteurs.

Audit d’exposition : périmètre, inventaire, qualification, correction, suivi

Prérequis avant la première requête

Un mandat écrit de la direction, qui fixe le périmètre (entités, marques, domaines, filiales) et exclut explicitement toute interaction active avec des systèmes tiers.
La liste des domaines possédés, avec l’accès aux comptes des bureaux d’enregistrement. Sans elle, impossible de distinguer un actif oublié d’un typosquat.
Le délégué à la protection des données (DPO, Data Protection Officer) dans la boucle avant la collecte, pas après (voir plus bas).
Un responsable désigné pour chaque famille d’actifs, faute de quoi les trouvailles s’accumulent dans un rapport que personne n’ouvre.

Le cycle

Le schéma suivant montre que l’audit n’est pas un livrable mais une boucle : la surveillance réalimente l’inventaire à chaque nouveau certificat, nouvelle offre ou nouveau dépôt.

Qualifier chaque trouvaille

La qualification est l’étape qui sépare un audit utilisable d’un inventaire de curiosités. On tranche par une grille à quatre niveaux, dans cet ordre de priorité :

Directement exploitable (secret publié, interface d’administration exposée, sous-domaine orphelin) : traitement dans l’heure, révocation d’abord, nettoyage ensuite.
Actif inconnu (hôte présent dans les journaux CT, absent de l’inventaire) : attribuer un responsable ou éteindre. Un actif sans propriétaire n’est jamais patché.
Aide au ciblage (versions dans les offres, métadonnées, organigramme détaillé) : réduire à la source, sans urgence opérationnelle.
Irréductible (format d’adresse, existence de la messagerie, noms des dirigeants) : ne pas perdre de temps à cacher, compenser par des contrôles.

L’arbre de décision ci-dessous applique cette grille à une trouvaille isolée ; la première question posée est toujours celle de l’exploitabilité immédiate, jamais celle de la gravité perçue.

Arbre de décision pour qualifier une trouvaille. Première question : est-elle exploitable sans autre information ? Si oui, révoquer, puis nettoyer. Si non, deuxième question : l'actif est-il présent dans l'inventaire ? Si non, attribuer un responsable ou éteindre. Si oui, troisième question : est-il retirable à la source ? Si oui, réduire la publication ; si non, compenser et documenter.

Erreur fréquente : classer le format d’adresse électronique en « critique » et passer trois réunions à envisager son changement. Il est déductible en deux minutes, quoi qu’on fasse. La compensation est ailleurs : authentification multifacteur résistante à l’hameçonnage (MFA, Multi-Factor Authentication, de type FIDO2), politique DMARC (Domain-based Message Authentication, Reporting and Conformance) en p=reject, procédure de vérification hors bande pour les changements de coordonnées bancaires.

Cadre légal de l’OSINT défensif en France et en Europe

Une donnée personnelle publique reste une donnée personnelle. Collecter les profils, adresses et fonctions des salariés, même depuis des sources ouvertes, constitue un traitement soumis au RGPD.

Base légale : l’intérêt légitime (article 6, paragraphe 1, point f) est la base habituellement invoquée pour la sécurité des systèmes. Il impose une mise en balance documentée avec les droits des personnes.
Finalité et minimisation (article 5) : on collecte ce qui sert à mesurer l’exposition de l’organisation, pas la vie privée des salariés. Le compte personnel d’un administrateur qui publie ses photos de vacances est hors sujet ; un dépôt personnel contenant un jeton d’accès professionnel ne l’est pas.
Information des personnes : l’article 14 encadre l’information due lorsque les données ne sont pas collectées auprès de la personne. Côté droit du travail, l’article L1222-4 du Code du travail interdit de collecter une information personnelle sur un salarié par un dispositif qui n’a pas été porté préalablement à sa connaissance, et l’article L2312-38 prévoit l’information et la consultation du CSE (comité social et économique) sur les moyens de contrôle de l’activité des salariés.
Proportionnalité et conservation : durée limitée, accès restreint, purge à la clôture de chaque campagne.

La frontière avec l’intrusion est nette : l’OSINT lit ce qui est publié. Tester un identifiant trouvé, s’authentifier, balayer activement des systèmes sort de l’OSINT et peut tomber sous l’article 323-1 du Code pénal, même avec de bonnes intentions et même sur un système qui s’avère appartenir à un prestataire. Les références de la CNIL et la page sur la surveillance des salariés complètent ce cadre ; l’application à une situation particulière relève d’un juriste.

Réduire l’exposition : hygiène de publication et surveillance

Hygiène de publication. Un circuit de relecture avant mise en ligne, avec une règle : aucun nom de serveur, chemin réseau, capture d’écran de console ou version de produit dans un document public. Les captures d’écran de « notre belle supervision » dans les présentations de conférence restent une source inépuisable de noms d’hôtes.

Offres d’emploi. Nommer des familles de compétences (« pare-feu nouvelle génération », « ERP (progiciel de gestion intégré) du marché »), jamais les produits de bordure ni leurs versions. Le compromis est réel : une offre vague attire moins de profils ciblés. La règle tranchée : les produits applicatifs peuvent être cités, les équipements exposés à Internet jamais.

Métadonnées. Nettoyage automatisé dans la chaîne de publication, pas confié à la vigilance de chacun. Attention au piège PDF détaillé dans l’exemple ci-dessous.

Certificats. Surveillance continue des journaux CT pour tous les domaines possédés, avec alerte sur tout certificat émis par une autorité inattendue, et enregistrements CAA (Certification Authority Authorization) pour restreindre les autorités habilitées. Le certificat générique (*.example.com) masque les noms d’hôtes, mais une seule clé privée compromise couvre alors tous les sous-domaines. Le bon arbitrage : certificat générique pour les environnements internes ou de recette dont les noms trahissent la fonction, certificats nominatifs pour les services critiques exposés. Sinon, on cache le nom du serveur de recette au prix de la clé du site de paiement.

Dépôts publics. Analyse de secrets au moment du push et dans l’intégration continue, plus surveillance des plateformes publiques sur les domaines et préfixes de jetons de l’organisation. Les principaux fournisseurs cloud et plateformes de code participent à des programmes de détection qui révoquent ou signalent automatiquement certains jetons ; ce filet ne couvre pas les secrets maison.

Révocation immédiate. Un identifiant publié est compromis, point. On révoque et on régénère avant toute discussion, on consulte ensuite les journaux d’accès sur toute la période d’exposition, puis on nettoie l’historique. L’ordre inverse (« d’abord réécrire l’historique Git proprement ») laisse le secret valide pendant la seule fenêtre qui compte. Les traces d’usage éventuel relèvent de la détection de persistance.

Conversations IA. Désactiver le partage public au niveau du tenant quand l’offre entreprise le permet, et l’inscrire dans la politique d’usage. Les assistants grand public relèvent de la sensibilisation, faute de levier technique.

Exemple : auditer et nettoyer ses propres métadonnées et certificats

Les commandes suivantes s’appliquent aux documents et au domaine de l’organisation elle-même. example.com est un domaine de documentation à remplacer par le domaine possédé.

# 1. Lister les noms d'hôtes journalisés en CT pour son propre domaine
#    (requête publique au service crt.sh, sortie dédoublonnée)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u > hotes-ct.txt

# 2. Comparer avec l'inventaire interne : ce qui sort ici est un actif inconnu
comm -23 hotes-ct.txt inventaire-hotes.txt

# 3. Auditer les métadonnées d'un document avant publication
exiftool -a -G1 -Author -Creator -Producer -Company rapport.pdf

# 4. Nettoyer : exiftool seul ajoute une révision au PDF, l'ancienne
#    reste récupérable ; qpdf réécrit le fichier sans les objets orphelins
exiftool -all:all= -overwrite_original rapport.pdf
qpdf --linearize rapport.pdf rapport-publie.pdf
exiftool -a -G1 rapport-publie.pdf   # vérifier le résultat

L’étape 4 contient le piège classique : sur un PDF, exiftool -all:all= procède par mise à jour incrémentale, et les métadonnées d’origine restent dans le fichier, restaurables par n’importe qui. Sans la réécriture par qpdf, le document « nettoyé » ment. Les images incorporées dans le PDF conservent par ailleurs leurs propres métadonnées : un outil comme mat2 (Metadata Anonymisation Toolkit) ou une ré-exportation depuis la source traite ce cas.

Ce que l’OSINT défensif ne garantit pas, et comment l’exploiter

Limites. L’audit voit ce qui est indexé aujourd’hui. Il ne voit pas les forums fermés, les listes d’accès revendues (voir l’économie des courtiers d’accès), les fuites chez les prestataires, ni la menace interne. Une absence de trouvaille ne prouve aucune absence d’exposition. Et rien de ce qui a été archivé ne disparaît vraiment : on réduit l’exposition future, on ne réécrit pas le passé. L’exposition des fournisseurs, elle, relève des attaques par la chaîne d’approvisionnement.

Surface d’attaque de l’audit lui-même.

Le livrable est une carte d’attaque prête à l’emploi. Classification restreinte, stockage chiffré, diffusion nominative.
Les services en ligne : téléverser un document interne dans un afficheur de métadonnées en ligne pour « vérifier » est une fuite en soi. On analyse localement.
Les clés d’API des services de recherche et de plateformes EASM sont des secrets à placer dans le coffre, avec rotation.
Le fournisseur EASM détient la cartographie complète de ses clients : clauses de localisation, de réversibilité et de suppression à vérifier avant signature.
Les faux profils sur les réseaux professionnels violent leurs conditions d’utilisation et posent un problème de loyauté vis-à-vis des salariés. Un audit défensif s’en passe.

Conditions d’exploitation. La surveillance CT et l’analyse de dépôts tournent en continu, avec des alertes routées vers le SOC (Security Operations Center) et un responsable par domaine. Une campagne complète d’inventaire se rejoue au minimum annuellement et à chaque événement structurant : fusion, changement de nom de domaine, migration cloud. L’inventaire est sauvegardé et versionné : c’est la comparaison entre deux campagnes qui révèle les dérives. Les résultats nourrissent aussi les hypothèses de threat hunting : un hôte oublié découvert en CT mérite une vérification de ses journaux d’accès. Vingt ans de métier apprennent d’ailleurs qu’un audit d’exposition sans surveillance continue a une durée de validité inférieure à celle du certificat qu’il vient de découvrir.

🐝 Ce qui arrive si on s’en passe

Sans cet inventaire, l’attaquant est le seul à cartographier l’exposition de l’organisation, et il le fait sans contact direct : ses requêtes aux journaux CT, aux moteurs de recherche et aux archives ne laissent aucune trace dans les journaux de l’organisation. La première alerte possible arrive donc avec sa première action active. Un sous-domaine orphelin non repéré donne plus qu’une page usurpée. Celui qui recrée la ressource contrôle le contenu servi : il réussit la validation HTTP d’une autorité de certification, obtient un certificat valide à ce nom et reçoit les cookies émis avec l’attribut Domain du domaine parent. Enfin, sans campagne antérieure versionnée, une enquête après incident ne peut pas dater le début de l’exposition d’un actif ou d’un secret. Elle ne peut donc pas délimiter la période de journaux d’accès à examiner.

🦫 Explication de la marmotte 🍫

Une entreprise laisse beaucoup d’informations visibles par n’importe qui sur Internet. Les documents publiés sur son site contiennent souvent, cachés à l’intérieur, le nom de la personne qui les a écrits et le nom de ses ordinateurs. Les offres d’emploi citent les logiciels utilisés, et donc ceux qu’un pirate peut chercher à attaquer. Les profils des salariés sur les réseaux professionnels montrent qui travaille où et permettent de deviner les adresses mail. Les noms des ordinateurs accessibles depuis Internet apparaissent dans des registres publics obligatoires, tenus à chaque fois qu’un certificat de sécurité est créé. Des mots de passe se retrouvent parfois dans du code publié par erreur, ou dans des conversations avec un assistant d’intelligence artificielle partagées en ligne.

L’équipe de sécurité fait donc le tour de ces sources, dans l’ordre : elle liste ce qui est visible, elle classe chaque découverte, puis elle corrige. Un mot de passe publié est désactivé immédiatement, avant tout le reste, car des programmes automatiques le testent en quelques minutes. Un ordinateur oublié reçoit un responsable ou il est éteint. Une information gênante est retirée à la source. Ce qui ne peut pas être caché, comme le format des adresses mail, est compensé par des protections supplémentaires. Ensuite, une surveillance permanente repère toute nouvelle fuite. La loi encadre ce travail : les informations sur les salariés restent protégées même publiques, et ceux-ci doivent être prévenus. Si la surveillance s’arrête, de nouvelles fuites passent inaperçues jusqu’à ce qu’un attaquant les trouve.

Pages voisines

La citent

OSINT défensif : mesurer et réduire l'exposition publique

Elle cite

: les deux pages se citent l’une l’autre.