Adresses IP, DNS et mail : réussir sa reconnaissance en pentesting

Une adresse IP peut vous orienter vers un serveur accessible sur Internet. Une adresse mail peut révéler le format des identifiants d’une entreprise. Prises séparément, ces informations semblent banales. En les reliant lors de votre phase de reconnaissance, vous commencez à comprendre comment une organisation expose ses services et ses comptes.

C’est justement l’objectif de la reconnaissance en pentesting : recueillir des informations pour préparer un test d’intrusion, c’est-à-dire une évaluation de sécurité autorisée.

Dans ce chapitre sur la reconnaissance, vous apprendrez à rechercher des adresses IP et des adresses mail, à comprendre leurs liens avec un domaine et à organiser vos découvertes. Nous resterons sur la collecte et l’analyse, sans aborder l’exploitation.

👉 Si vous avez raté le début : Les 4 phases essentielles du pentesting.

Phase de reconnaissance : Comprendre ce que vous recherchez

Une adresse IP identifie une interface réseau et permet d’acheminer des communications. Vous rencontrerez principalement deux formats : IPv4, comme 192.0.2.10, et IPv6, comme 2001:db8::10.

👉 Pour aller plus loin, Tout savoir sur une adresse ip et les informations à en déduire.

Un nom de domaine, comme example.com, constitue un nom plus facile à retenir. Le DNS, pour Domain Name System, joue notamment le rôle d’un annuaire : il permet de retrouver les adresses IP associées à un nom.

Attention, la relation n’est pas toujours simple. Un domaine peut correspondre à plusieurs IP, et une même IP peut héberger plusieurs sites.

Il faut aussi distinguer une IP publique, utilisable sur Internet, d’une IP privée, destinée à un réseau interne. Trouver 192.168.1.20 dans un document ne vous donne donc pas l’adresse publique du serveur concerné.

Que révèle une adresse mail ?

Dans alice.martin@example.com, alice.martin est la partie locale et example.com le domaine de messagerie.

Cette adresse peut indiquer un nom, un service ou une convention de nommage. Plusieurs adresses au format prenom.nom suggèrent, par exemple, une règle utilisée par l’organisation.

Adresses mail et connexions SSH : quel rapport ?

Une adresse mail professionnelle sert à communiquer, mais elle peut aussi donner un indice sur les identifiants utilisés dans une entreprise. Certaines organisations reprennent une convention similaire pour leurs adresses de messagerie et leurs comptes informatiques.

Voyons pourquoi cette information mérite votre attention pendant la reconnaissance.

Comprendre ce qu’est une connexion SSH

SSH, pour Secure Shell, permet de se connecter à distance à une machine grâce à une communication chiffrée. Un administrateur peut ainsi gérer un serveur depuis son ordinateur : consulter des fichiers, modifier une configuration ou vérifier le fonctionnement d’un service.

Pour établir une connexion, plusieurs éléments interviennent : l’adresse du serveur, un nom d’utilisateur et un moyen de prouver son identité. Cette preuve peut notamment être un mot de passe ou une clé SSH, un mécanisme reposant sur une clé privée conservée par l’utilisateur et une clé publique enregistrée sur le serveur.

Connaître un nom d’utilisateur ne suffit donc pas à se connecter. C’est une pièce du puzzle, pas un passe-partout.

Ce qu’une adresse mail peut vous apprendre

Imaginons qu’un document public mentionne l’adresse suivante :

# Adresse fictive trouvée dans un document public.
alice.martin@example.com

La partie située avant @, ici alice.martin, peut correspondre à une convention de nommage interne. Si l’entreprise applique cette même convention à ses comptes système, un compte pourrait porter ce nom.

Les informations présentes dans une adresse mail peuvent suggérer des noms d’utilisateurs employés pour d’autres services, dont SSH.

Il faut cependant rester prudent. L’entreprise peut utiliser des identifiants différents, attribuer des comptes d’administration distincts ou interdire toute connexion SSH aux utilisateurs ordinaires. Une adresse publiée peut aussi être un alias, c’est-à-dire une adresse qui redirige les messages vers une autre boîte.

Distinguer une piste d’un compte confirmé

Supposons que vous trouviez deux adresses publiques :

# Deux adresses observées : ce sont des faits.
alice.martin@example.com
paul.durand@example.com

# Convention possible : c’est une hypothèse.
prenom.nom

Vous pouvez raisonnablement noter que le format prenom.nom apparaît dans la messagerie. En revanche, vous ne pouvez pas affirmer que alice.martin est un compte SSH.

De même, le domaine de messagerie ne vous indique pas automatiquement l’adresse du serveur SSH. Le serveur mail, le site web et les machines administrées à distance peuvent être hébergés sur des infrastructures différentes.

Vous avez découvert une convention possible, pas une connexion disponible.

À quoi sert cet indice pendant un pentesting ?

Cette information aide à préparer une évaluation ultérieure de la gestion des accès, lorsque celle-ci entre dans le périmètre autorisé. Elle peut notamment orienter les questions posées à l’entreprise : les comptes d’administration sont-ils séparés des comptes ordinaires ? Les identifiants professionnels sont-ils largement exposés dans les documents publics ?

Pendant la reconnaissance, consignez simplement l’adresse observée, sa source, la date et l’hypothèse associée :

Information	Observation
Adresse mail publique	alice.martin@example.com
Source	Document publié par l’entreprise
Convention observée	prenom.nom
Lien avec un compte SSH	Non confirmé

Vous préservez ainsi la valeur de votre découverte sans lui faire dire davantage qu’elle ne révèle. Le bon réflexe consiste à relier les indices tout en gardant une frontière claire entre ce que vous savez et ce que vous supposez.

Poser le cadre avant la collecte

Commencez par identifier le périmètre autorisé : les domaines, systèmes et opérations couverts par la mission. Une découverte n’élargit pas automatiquement ce périmètre. Un prestataire mentionné dans les résultats reste un tiers.

Distinguez ensuite deux approches.

La reconnaissance passive utilise des informations détenues par des tiers : résultats d’un moteur de recherche, annuaires ou bases publiques. Elle ne consiste pas à interroger directement les services étudiés.

La reconnaissance active implique des interactions avec l’infrastructure. Une consultation du site officiel produit déjà une connexion ; une requête DNS peut atteindre les serveurs de l’organisation par l’intermédiaire de votre résolveur, le service chargé de rechercher les réponses DNS. « Public » ne signifie donc pas « invisible ».

Pour suivre les exemples, ouvrez un terminal, la fenêtre permettant de saisir des commandes. Les lignes commençant par # sont des commentaires explicatifs.

Nous utiliserons example.com, un domaine réservé aux exemples. Remplacez-le uniquement par votre domaine de laboratoire ou un domaine autorisé. Les résultats fictifs présentés ne sont pas ceux que vous obtiendrez nécessairement.

Trouver des adresses IP à partir d’un domaine

La résolution DNS consiste à rechercher les informations associées à un nom. L’outil host fournit une première lecture simple :

# Rechercher les informations DNS associées au domaine.
host example.com

Pour demander précisément les adresses IP, utilisez dig :

# A : rechercher les adresses IPv4.
dig example.com A +short

# AAAA : rechercher les adresses IPv6.
dig example.com AAAA +short

A et AAAA sont des types d’enregistrements DNS, autrement dit des catégories d’informations enregistrées dans l’annuaire. +short raccourcit l’affichage.

Consignez toutes les réponses. Plusieurs IP ne signalent pas nécessairement plusieurs serveurs indépendants : elles peuvent correspondre à une répartition du trafic ou à une infrastructure distribuée.

Si la réponse est vide, relancez sans +short pour consulter les détails. Une absence d’adresse IPv6 ne signifie pas que le domaine est inexistant.

Identifier les services DNS et mail

Le DNS permet également de repérer les serveurs chargés de fonctions précises :

# NS : identifier les serveurs DNS responsables du domaine.
dig example.com NS +short

# MX : identifier les serveurs de réception des mails.
dig example.com MX +short

Une réponse MX fictive pourrait être :

10 mx1.example.com.
20 mx2.example.com.

Les nombres expriment une préférence : la valeur la plus faible est prioritaire. Le point final marque simplement un nom DNS complet.

Vous pouvez ensuite rechercher l’IP du serveur identifié :

# Résoudre le nom du serveur de messagerie découvert.
host mx1.example.com

Vous venez de relier un domaine, une fonction et une adresse IP. En revanche, un enregistrement MX ne fournit pas la liste des boîtes mail.

Essayer la recherche inverse

La recherche DNS inverse part d’une IP pour retrouver un nom, lorsqu’un enregistrement appelé PTR existe :

# Exemple de syntaxe avec une IP réservée à la documentation.
dig -x 192.0.2.10 +short

Un nom retourné peut suggérer un hébergeur ou une fonction. Il ne constitue pas une preuve d’appartenance, et une réponse vide n’a rien d’exceptionnel. L’annuaire n’a pas toujours rempli toutes ses fiches !

Comprendre à qui correspondent les résultats

WHOIS est un service historique d’accès aux données d’enregistrement. Aujourd’hui, RDAP constitue la référence pour les domaines génériques, comme les .com. Il donne accès à ces données dans un format standardisé.

Pour débuter, ouvrez ICANN Lookup, saisissez le domaine, puis examinez le bureau d’enregistrement, les dates et les serveurs DNS. Certains contacts sont masqués pour protéger les données personnelles. L’outil accepte aussi des ressources IP pour consulter leurs données d’enregistrement. 

Une IP enregistrée au nom d’un hébergeur ne signifie pas que celui-ci est votre cible. Elle indique d’abord qui gère la ressource réseau.

Éviter le piège de l’hébergement partagé

Un site peut passer par un CDN, un réseau qui distribue son contenu et peut servir d’intermédiaire avec le serveur d’origine. L’IP visible peut donc être celle du CDN.

De même, deux sites partageant une adresse IP n’appartiennent pas nécessairement à la même organisation.

La bonne question devient : « Quel lien puis-je démontrer entre ce domaine, cette IP et la mission ? » Cette prudence évite de construire une cartographie… du mauvais voisin.

Rechercher les adresses mail publiques

Commencer par les sources évidentes…

Examinez les pages de contact, communiqués et documents publics de l’organisation. Des adresses apparaissent aussi dans des contributions techniques ou des échanges sur des forums.

Dans votre moteur de recherche, essayez :

# Rechercher la présence du domaine dans des adresses mail.
"@example.com"

# Limiter la recherche aux pages du domaine.
site:example.com "contact"

# Rechercher des PDF mentionnant le domaine de messagerie.
"@example.com" filetype:pdf

Ces expressions se saisissent dans le moteur, pas dans le terminal. site: limite la recherche à un site ; filetype:pdf privilégie les PDF.

Ouvrez ensuite la source pour vérifier l’adresse et son contexte. Un extrait de résultat peut être ancien ou incomplet. Conservez l’URL et la date de consultation.

Interpréter sans inventer

Supposons que deux publications mentionnent alice.martin@example.com et paul.durand@example.com.

Vous pouvez noter : « Format prenom.nom observé sur deux adresses publiques. » Vous ne pouvez pas en déduire que toutes les personnes suivent cette règle. Homonymes, alias et changements de nom compliquent souvent les conventions.

Séparez les adresses effectivement publiées des formats supposés. Une hypothèse utile reste une hypothèse.

Accélérer la collecte avec theHarvester

theHarvester automatise la recherche de domaines, de noms d’hôtes et d’adresses mail auprès de sources publiques. Les résultats disponibles dépendent des sources choisies.

Commencez par une recherche limitée :

# Rechercher des informations publiques associées au domaine.
theHarvester -d example.com -l 100 -b duckduckgo

-d définit le domaine ; -l fixe une limite de résultats à examiner, selon le fonctionnement de la source ; -b sélectionne celle-ci. Cela ne garantit pas de trouver 100 adresses mail. La documentation Kali présente cette syntaxe et les options disponibles. 

👉 Consultez notre guide complet sur TheHarvester.

Vérifiez toujours l’aide de votre version : les sources évoluent, certaines demandent une clé d’accès et d’autres peuvent être temporairement indisponibles. Un résultat vide signifie seulement que cette recherche n’a rien remonté.

Recueillir des informations sur les serveurs de messagerie

Les serveurs de messagerie peuvent fournir des renseignements utiles pendant la phase de reconnaissance d’un test d’intrusion. Leur rôle est de recevoir et d’envoyer les courriels d’une organisation. Pour cela, certains services doivent pouvoir communiquer avec l’extérieur, même lorsque le réseau est protégé par un pare-feu.

Cela ne signifie pas que les messages arrivent directement sur une machine du réseau interne. Ils peuvent d’abord passer par une passerelle de sécurité ou par un prestataire externe chargé de les filtrer.

Lorsqu’un serveur refuse un courriel, il peut renvoyer un message expliquant la raison du rejet. Ce retour contient parfois des informations sur son fonctionnement : règles de filtrage, nom du logiciel de protection ou détails sur le serveur.

N’hésitez pas à provoquer un refus en envoyant une pièce jointe portant une extension souvent bloquée, comme .exe ou .bat. Dans un test autorisé, ce type de vérification doit être prévu avec l’organisation et utiliser un fichier de test inoffensif.

Un message de refus peut indiquer que certaines pièces jointes sont interdites. Il peut aussi révéler le nom d’un antivirus ou d’une solution de filtrage. Toutefois, ces renseignements ne sont pas toujours présents : certains systèmes donnent très peu de détails, et d’autres rejettent les messages sans envoyer de réponse.

Les en-têtes d’un courriel constituent une autre source d’information. Ce sont des données techniques qui accompagnent le message et décrivent notamment son acheminement. Ils peuvent contenir des noms de serveurs, des adresses IP ou des indications sur les logiciels utilisés.

Ces éléments aident à comprendre l’organisation de la messagerie. Il faut cependant les interpréter avec prudence : un serveur visible peut appartenir à un prestataire, et certaines informations peuvent être masquées ou modifiées.

Transformer vos découvertes en informations utiles

Créez un tableau dès le début :

Élément	Source	Interprétation	Confiance
IP associée à www.example.com	Réponse DNS datée	Adresse visible du site	Forte pour cette association
Mail publié dans un PDF	URL du document	Contact public, activité à confirmer	Moyenne
Format prenom.nom	Deux mails observés	Convention possible	À confirmer

Ajoutez la date et le statut dans le périmètre. Une ancienne IP peut avoir changé d’utilisateur ; un contact public peut avoir quitté l’entreprise.

Ces informations prépareront les étapes suivantes : les IP aideront à organiser l’examen des services exposés ; les mails permettront d’étudier les conventions d’identification et l’exposition des comptes. Ils pourront aussi contribuer à préparer une évaluation de sensibilisation, si elle est expressément prévue dans la mission.

Aucun de ces éléments ne constitue, à lui seul, une faille.

Apprennez à regarder votre propre exposition

Pour progresser, appliquez cette méthode à un domaine que vous contrôlez. Cherchez ses IP, ses serveurs mail et les coordonnées que vous avez publiées, puis comparez vos découvertes à ce que vous pensiez rendre visible.

L’exercice devient particulièrement instructif lorsqu’une information oubliée réapparaît. Un ancien PDF, un contact encore indexé, un sous-domaine délaissé : voilà des occasions concrètes d’améliorer la maîtrise de votre présence en ligne.

Vous commencerez alors à développer le réflexe essentiel du pentesteur : demander, devant chaque découverte, ce qu’elle révèle réellement et quelle preuve permet de l’affirmer.

TheHarvester