OSINT technique : cartographie des surfaces d'attaque

OSINT technique : cartographie des surfaces d'attaque

Cadre éthique et légal : les techniques décrites dans cet article distinguent deux catégories. La reconnaissance passive (consultation de données publiques sans interaction avec la cible) est légale dans la quasi-totalité des juridictions. La reconnaissance active (scan de ports, brute-force DNS direct) nécessite une autorisation explicite du propriétaire des systèmes. La section défensive de cet article relève exclusivement de l'auto-inventaire de sa propre surface d'exposition — elle ne doit jamais être appliquée sur des systèmes tiers sans mandat écrit.

Avant de lancer un seul paquet sur un réseau cible, un attaquant compétent passe des heures — parfois des semaines — en reconnaissance passive. Cette phase ne génère aucune trace dans les logs de la cible. Elle produit pourtant une carte précise de la surface d'attaque : domaines, sous-domaines, technologies exposées, credentials leakés, employés et leurs accès.

Comprendre cette méthodologie est indispensable pour réduire sa propre surface d'attaque.

La reconnaissance passive : aucune interaction avec la cible

La reconnaissance passive consiste à collecter des informations publiquement disponibles sans jamais interagir directement avec les systèmes cibles. Sans interaction directe avec la cible, cette phase ne génère généralement pas de logs côté cible — des services intermédiaires (WHOIS, CT logs, moteurs de recherche) conservent néanmoins des traces de consultation.

Sources primaires :

• Registres DNS publics et historiques
• Logs de transparence des certificats TLS
• Moteurs de recherche de surfaces exposées (Shodan, Censys, FOFA)
• Registres WHOIS et RDAP
• Dépôts de code publics (GitHub, GitLab, Bitbucket)
• Archives web (Wayback Machine, CommonCrawl)
• Réseaux sociaux professionnels (LinkedIn pour cartographier les équipes et technologies)

Énumération DNS : bien plus que les A records

Un enregistrement DNS est une déclaration d'intention publique. L'agrégation des enregistrements d'un domaine révèle l'architecture complète d'une organisation.

# Énumération passive via sources tierces (CT logs, DNS passif, APIs publiques)
# Aucune interaction directe avec target.com
amass enum -passive -d target.com -o subdomains.txt
 
# Certificate Transparency pour trouver tous les sous-domaines certifiés
curl "https://crt.sh/?q=%.target.com&output=json" | \
  jq '.[].name_value' | sort -u
 
# DNS over HTTPS — contourne les blocages locaux
curl "https://dns.google/resolve?name=_dmarc.target.com&type=TXT"

Les enregistrements MX révèlent le provider email (Google Workspace, O365, Proofpoint). Les TXT exposent les politiques DMARC, SPF, et parfois des clés de validation de services tiers. Les CNAME pointent vers des services cloud qui peuvent être takeover-ables si mal configurés.

Certificate Transparency Logs

Depuis 2018, chaque certificat TLS émis par une CA de confiance est enregistré dans des logs publics. Ces logs sont irréversibles et interrogeables publiquement.

# Via crt.sh — tous les certificats pour un domaine
https://crt.sh/?q=target.com
 
# Via Censys — recherche avancée avec filtres
https://search.censys.io/certificates?q=parsed.names%3Atarget.com

Un attaquant trouve ainsi les sous-domaines internes exposés sur internet, les environnements de développement/staging, et les services tiers intégrés — avant même de scanner quoi que ce soit.

Shodan et Censys : l'internet scanné en permanence

Shodan indexe en permanence l'ensemble des ports et services exposés sur internet. Une recherche prend deux secondes et retourne des résultats qui ont demandé des semaines de scan actif dans les années 2000.

# Requêtes Shodan utiles pour la reconnaissance
org:"Target Company" port:22          # SSH exposé
org:"Target Company" http.title:"GitLab"  # GitLab interne exposé
ssl.cert.subject.cn:"*.target.com"   # Tous les certs wildcard

Les informations exposées : versions des services (et donc CVE applicables), banners d'applications, configurations par défaut non modifiées, interfaces d'administration publiques.

GitHub Dorking : le coffre-fort mal fermé

Les développeurs committent régulièrement des secrets : clés API, credentials de base de données, tokens OAuth, clés privées SSH. GitHub Search permet de chercher ces fuites avec des requêtes précises.

# Recherches GitHub Dork
org:target-company "api_key" OR "secret_key" OR "password"
org:target-company filename:.env
org:target-company "AWS_ACCESS_KEY_ID"
org:target-company "-----BEGIN RSA PRIVATE KEY-----"

Même après suppression, les commits restent accessibles via l'historique Git. La rotation des credentials leakés est urgente mais ne suffit pas sans rotation des secrets actifs.

Réduire sa propre surface d'attaque

Checklist de réduction de surface d'attaque

• DNS : supprimer les enregistrements obsolètes (sous-domaines de projets terminés, CNAMEs orphelins)
• Certificats : auditer via crt.sh, révoquer les certificats émis pour des environnements non-production
• Exposed services : scanner son propre périmètre avec Shodan org: régulièrement
• GitHub : activer le secret scanning natif, configurer des push protection rules
• OSINT employés : vérifier ce que LinkedIn révèle sur votre stack technique
• Wayback Machine : chercher des versions archivées exposant des endpoints anciens
• Emails : politique DMARC en mode reject, SPF strict, DKIM configuré
• Sous-domaines : inventaire complet avec vérification des CNAMEs actifs
• Credentials leakés : monitorer Have I Been Pwned Enterprise pour les emails corporate
• Registres cloud : s'assurer que les registres de containers privés ne sont pas énumérables publiquement

La surface d'attaque d'une organisation n'est pas définie par ce qu'elle sait qu'elle expose — elle est définie par ce qu'un attaquant peut trouver. Ces deux ensembles ne se recoupent jamais complètement. L'OSINT régulier sur sa propre organisation est la seule façon de réduire l'écart.