Cartographier l'empreinte numérique avant un pentestCartographier l'empreinte numérique avant un pentest

01La carte précède l'attaque

Un test d'intrusion réussi se joue rarement au moment de l'exploitation. Il se joue avant, quand on comprend mieux la cible qu'elle ne se comprend elle-même. Une organisation accumule des domaines, des sous-domaines, des adresses, des services, des comptes, au fil des projets et des équipes. Personne n'en tient la liste complète. Le travail de reconnaissance consiste à la reconstituer.

Cette carte a deux vertus. Elle dit par où commencer, et surtout par où l'on aurait tort de commencer : un service oublié, laissé en ligne après une migration, vaut souvent mieux qu'un assaut frontal sur la façade durcie. Et elle borne l'effort : on ne teste pas ce qu'on n'a pas cartographié.

02Le périmètre, d'abord

Rien de ce qui suit n'existe sans un mandat écrit. Un test d'intrusion est une activité autorisée, encadrée par un document qui nomme les cibles permises, les plages horaires, les techniques exclues, et les contacts à prévenir. En anglais on parle de rules of engagement. Sans lui, la même reconnaissance qui rend service devient une reconnaissance hostile, et sortir du périmètre expose le testeur autant que le client.

La première question n'est donc pas « que puis-je trouver ? » mais « qu'ai-je le droit de tester ? ». La carte se dessine à l'intérieur de cette frontière. Ce qui déborde est signalé au client, jamais touché.

03Passif contre actif

On distingue deux régimes. La reconnaissance passive n'interroge que des tiers : registres publics, journaux de transparence, moteurs qui ont déjà scanné Internet. La cible ne voit rien passer, parce qu'on ne lui parle pas. La reconnaissance active, elle, envoie des requêtes à l'infrastructure cible : résolution de ses noms, sondage de ses ports, appels à ses applications. Elle est plus riche et plus bruyante.

L'ordre compte. On épuise le passif avant d'ouvrir l'actif : c'est gratuit en discrétion, ça oriente le reste, et ça évite de sonder à l'aveugle une surface qu'on aurait pu cartographier sans bruit.

04Les sources qui parlent

Les registres. Le protocole RDAP, successeur de WHOIS, peut fournir les informations d'enregistrement d'un domaine ou d'une plage d'adresses (contacts, dates, statuts), quand elles ne sont ni masquées ni restreintes. Le chemin habituel part du domaine : on le résout vers une adresse, on remonte de cette adresse au numéro de système autonome (ASN) qui l'annonce, puis aux plages associées à cet ASN. Un domaine peut toutefois pointer vers une infrastructure tierce (CDN, hébergeur mutualisé, SaaS) : l'ASN est alors celui du prestataire, pas celui de l'organisation, ce qui est déjà une information en soi.

import httpx

def rdap_domaine(domaine: str) -> dict:
    # RDAP renvoie du JSON structuré, là où WHOIS renvoyait du texte libre.
    # C'est de la donnée publique de registre : aucune requête vers la cible.
    reponse = httpx.get(f"https://rdap.org/domain/{domaine}", timeout=10)
    reponse.raise_for_status()
    donnees = reponse.json()
    return {
        "nom": donnees.get("ldhName"),
        "statuts": donnees.get("status", []),
        "serveurs": [ns["ldhName"] for ns in donnees.get("nameservers", [])],
    }

La transparence des certificats. Chaque certificat TLS émis est inscrit dans des journaux publics et vérifiables (Certificate Transparency). Les interroger révèle des sous-domaines qu'aucun lien ne mentionne : vpn., preprod., admin., le portail d'un prestataire oublié. C'est l'une des sources passives les plus productives, et elle ne parle qu'à un journal, jamais à la cible.

import httpx

def sous_domaines_via_ct(domaine: str) -> set[str]:
    # crt.sh interroge les journaux de transparence. On lit un registre
    # public de certificats déjà émis, pas l'infrastructure du client.
    url = f"https://crt.sh/?q=%25.{domaine}&output=json"
    entrees = httpx.get(url, timeout=30).json()
    noms = set()
    for entree in entrees:
        for ligne in entree["name_value"].splitlines():
            nom = ligne.strip().lstrip("*.").lower()
            if nom.endswith(domaine):
                noms.add(nom)
    return noms

Le DNS. Une fois la liste des noms constituée, leur résolution donne les adresses, les enregistrements MX (messagerie), TXT (SPF, DMARC, vérifications de services tiers). Les enregistrements SPF et les CNAME trahissent souvent la pile utilisée : hébergeur, fournisseur de messagerie, CDN, outils SaaS. Chacun est une dépendance, et une dépendance mal configurée, comme un CNAME qui pointe vers un service désactivé, peut ouvrir la voie à une prise de contrôle de sous-domaine.

Les moteurs de scan. Shodan, Censys et leurs semblables ont déjà cartographié l'Internet exposé. Les interroger sur les plages d'adresses de la cible liste les services visibles, leurs bannières, leurs versions, leurs certificats, sans qu'un seul paquet ne parte vers la cible. Ces données sont déjà indexées, donc ni forcément exhaustives ni forcément récentes : elles orientent le travail, elles ne dispensent pas d'une vérification active plus tard. On y trouve les oublis : une base de données ouverte, une interface d'administration exposée, un service de test resté en ligne.

05Les personnes

Une organisation, ce sont aussi des gens, et leurs adresses suivent presque toujours un format déductible (prenom.nom@). On reconstitue ce format à partir de quelques adresses publiques, puis on le confronte aux fuites de données déjà publiques : un identifiant d'entreprise apparu dans une brèche ancienne ne prouve pas qu'un mot de passe soit encore valide ni réutilisé, mais il signale un compte à surveiller et une cible possible d'ingénierie sociale si le mandat l'autorise.

Ici la prudence est double : on ne travaille que sur le périmètre autorisé, et on manipule des données personnelles, donc sous le régime du RGPD. Ce qu'on collecte, on le protège et on le restreint à l'usage de la mission.

06Structurer et livrer

La reconnaissance ne vaut que rangée. On construit un inventaire d'actifs : pour chaque nom, son adresse, ses services, sa pile, son propriétaire présumé, son statut. De cet inventaire se dégage la surface d'attaque, c'est-à-dire l'ensemble des points par lesquels un attaquant pourrait entrer.

from dataclasses import dataclass, field

@dataclass
class Actif:
    nom: str
    adresses: list[str] = field(default_factory=list)
    services: list[str] = field(default_factory=list)
    pile: list[str] = field(default_factory=list)
    dans_perimetre: bool = True
    remarques: str = ""

# La carte est un objet, pas une intuition : elle se relit, se trie par
# risque, et se remet au client telle quelle.
surface = [
    Actif("preprod.exemple.fr", ["203.0.113.10"], ["443/https"],
          ["nginx", "app interne"], remarques="préproduction exposée"),
]

Cet inventaire est un livrable. Le client doit ressortir du test avec la carte de ce qu'il expose, pas seulement avec la liste de ce qui a cédé. Souvent, la carte elle-même est le résultat le plus utile : elle nomme des actifs que personne ne surveillait plus.

07Côté défense

La même démarche, tournée vers l'intérieur, porte un nom : la gestion de la surface d'attaque externe (EASM). Une organisation gagne à s'auto-cartographier en continu, exactement comme le ferait un attaquant : surveiller les journaux de transparence pour repérer un certificat émis sans qu'on le sache, inventorier ses plages d'adresses, chasser les sous-domaines qui pointent vers des services désactivés, et retirer ce qui n'a plus de raison d'être en ligne.

La leçon de la reconnaissance vaut donc pour les deux camps : on ne défend que ce qu'on a cartographié, et l'attaquant, lui, prend toujours le temps de le faire.