1 Introduction
Quand vous ouvrez un compte Google Workspace, Microsoft 365, Atlassian ou l'un des centaines d'autres outils cloud, le fournisseur vous demande de prouver que le domaine est à vous. La méthode habituelle : ajouter un court enregistrement texte dans votre DNS, du genre atlassian-domain-verification=.... Le fournisseur le vérifie, et l'enregistrement reste en place, souvent pendant des années.
Ces enregistrements sont publics. N'importe qui peut les lire en une commande, et mis bout à bout ils forment la liste des éditeurs de logiciels de votre entreprise. Le bloc « Third-party services » d'un scan de domaine lit cette liste pour vous, et le bloc « Raw TXT records » affiche chaque valeur TXT telle que publiée. Cette fiche explique ce que la liste révèle, pourquoi elle facilite le phishing, et comment la garder courte et à jour.
3
Signaux DNS lus par le rapport pour nommer un fournisseur : jetons TXT, includes SPF, serveurs MX
1
Commande suffit à n'importe qui pour lister vos enregistrements TXT : dig TXT
Public
Le DNS n'a pas de contrôle d'accès : ce que vous y publiez, tout attaquant peut le lire
2 Comment ça marche
La vérification de domaine est une poignée de main toute simple. Seul celui qui contrôle le DNS d'un domaine peut y ajouter des enregistrements, donc un enregistrement avec une valeur aléatoire prouve ce contrôle. Le rapport reconnaît ensuite chaque fournisseur à trois endroits de votre DNS :
TXT
Un jeton de vérification : vous avez prouvé à ce fournisseur que le domaine est à vous, vous y avez donc (ou avez eu) un compte.
SPF
Un include: dans votre SPF : ce fournisseur a le droit d'envoyer des emails au nom de votre domaine.
MX
Vos serveurs de mail : ce fournisseur reçoit tous les emails adressés à votre domaine.
Pourquoi une liste de fournisseurs aide un attaquant
Le phishing générique (« votre boîte mail est pleine ») se repère facilement. Le phishing ciblé s'appuie sur un prétexte que la victime attend. Si votre DNS indique que vous utilisez Atlassian, l'attaquant envoie à vos équipes une copie parfaite d'une notification Jira ou Confluence, avec un lien vers une fausse page de connexion Atlassian. S'il indique DocuSign, le prétexte devient un contrat à signer. Vos salariés reçoivent tous les jours de vrais emails de ces outils, le faux ne se remarque pas. C'est de l'ingénierie sociale à bas coût : la reconnaissance est déjà faite.
3 Analyse détaillée
Jetons de vérification : ce que chacun révèle
Le bloc « Third-party services » regroupe les fournisseurs reconnus par catégorie, et indique pour chacun où il a été vu (TXT, SPF, MX). Quelques jetons courants et ce qu'ils disent :
google-site-verification=... ; Google (Search Console, Workspace)
MS=ms12345678 ; Microsoft 365
atlassian-domain-verification=... ; Atlassian (Jira, Confluence)
facebook-domain-verification=... ; compte Meta Business
apple-domain-verification=... ; services Apple
docusign=... ; DocuSign
Un jeton prouve qu'un compte a existé, pas qu'il sert encore
Personne ne retire un jeton en arrêtant de payer un outil. Une longue liste mélange souvent les fournisseurs actuels, des essais d'il y a des années et des outils testés une fois. Vous seul pouvez faire le tri.
Un jeton est lié au compte qui l'a créé
Chez certains fournisseurs (Google Search Console est l'exemple classique), celui qui a créé le jeton reste propriétaire vérifié de votre domaine tant que le jeton est publié. Un jeton créé par le compte personnel d'un ancien salarié ou par une ancienne agence maintient cet accès.
Les fournisseurs SPF et MX pèsent plus lourd
Un fournisseur présent dans votre SPF peut envoyer des emails qui passent pour les vôtres ; votre fournisseur MX lit tout le courrier entrant. Ce sont ceux dont la sécurité compte le plus. Voir SPF, DKIM et DMARC pour garder la liste SPF courte.
Enregistrements TXT bruts
Ce bloc replié affiche chaque valeur TXT de votre domaine exactement telle que le DNS la renvoie, y compris celles que le rapport ne reconnaît pas. Vous obtenez la même liste avec :
dig +short TXT exemple.fr
nslookup -type=TXT exemple.fr # sous Windows
Ce que vous devriez y trouver
Un seul enregistrement SPF (v=spf1 ...) et les jetons des outils que vous utilisez vraiment. DMARC et DKIM vivent sur d'autres noms (_dmarc. et selecteur._domainkey.), ils n'apparaissent donc pas à la racine.
Ce qui ne doit jamais y être
Les TXT servent parfois de bloc-notes : une IP interne, un nom de contact, un mot de passe, une clé d'API, une licence. Tout secret dans un TXT est publié au monde entier. Supprimez-le et changez le secret, car les services d'historique DNS en ont peut-être déjà une copie.
Des valeurs non reconnues
Une valeur que le rapport ne nomme pas n'est pas suspecte en soi : il existe des milliers de fournisseurs. Cherchez le préfixe (la partie avant le =) pour savoir à qui il appartient.
Faire le ménage, dans l'ordre
Urgent : retirez tout secret (clé, mot de passe, jeton d'API) trouvé dans un TXT, et renouvelez-le à la source.
Rapidement : retirez l'include SPF de chaque fournisseur qui n'envoie plus d'emails pour vous. C'est une vraie autorisation, pas une simple information.
Hygiène : listez chaque jeton, associez-le à un fournisseur et à un responsable, et supprimez ceux des outils abandonnés. Avant de supprimer le jeton d'un outil encore utilisé, lisez la documentation du fournisseur : certains revérifient l'enregistrement régulièrement (c'est le cas de Google Search Console) et retirent la vérification s'il disparaît, d'autres n'en ont besoin qu'une fois.
Processus : ajoutez « supprimer les enregistrements DNS » à la procédure de sortie d'un fournisseur, à côté de la résiliation du contrat et de la fermeture des comptes.
De la liste des fournisseurs au risque fournisseur
Ce bloc est aussi un bon point de départ pour une revue des risques tiers : c'est la liste des sociétés qui détiennent vos données ou agissent en votre nom.
Protégez les comptes, pas seulement le DNS
Pour chaque fournisseur encore utilisé, imposez le SSO ou la double authentification sur les comptes administrateurs. Masquer le jeton n'arrêterait pas le phishing ; une connexion solide, si.
Prévenez vos équipes avec la vraie liste
Une sensibilisation au phishing porte davantage quand elle cite vos outils réels : « les attaquants savent que nous utilisons Atlassian et DocuSign ; vérifiez la barre d'adresse avant de vous connecter ».
Suivez les incidents de vos fournisseurs
Quand l'un des fournisseurs listés annonce une fuite, vous savez déjà que vous êtes concerné. Abonnez-vous à leurs pages sécurité ou statut.
Découvrez ce que votre DNS dit de vous sur mlab.sh
Un scan de domaine reconnaît les fournisseurs désignés par vos jetons de vérification, vos includes SPF et vos serveurs de mail, et affiche chaque enregistrement TXT brut que vous publiez.
Scanner votre domaine sur mlab.sh4 Red Flags
Un secret dans un enregistrement TXT
Une clé d'API, un mot de passe ou une adresse interne publiés dans le DNS sont publics. Supprimez-les et renouvelez-les aujourd'hui.
Un include SPF pour un fournisseur quitté
La plateforme de ce fournisseur peut toujours envoyer des emails qui passent pour les vôtres. Retirez l'include.
Des jetons que personne ne sait expliquer
Une vérification pour un outil qu'aucune équipe ne reconnaît peut être du shadow IT, ou un compte qui a survécu à son propriétaire. Trouvez qui l'a créé.
Plusieurs jetons pour le même fournisseur
Deux valeurs google-site-verification peuvent signifier que deux comptes distincts ont vérifié le domaine. Assurez-vous que les deux appartiennent à l'entreprise.
Des emails « de » l'un de vos fournisseurs qui demandent de se connecter
Attendez-vous à en recevoir : votre liste de fournisseurs est publique. Ouvrez l'outil depuis un favori plutôt que par le lien, et signalez le message.
Modules connexes
SPF, DKIM et DMARC pour votre domaine
Empêcher un attaquant d'envoyer des emails en votre nom : le rôle de SPF, DKIM et DMARC, lire un résultat de scan et atteindre p=reject sans casse.
C'est quoi le DNS ?
L'annuaire d'Internet : comprendre comment le DNS traduit les noms de domaine en adresses IP.
C'est quoi l'ingénierie sociale ?
L'ingénierie sociale : comment les attaquants piratent des humains plutôt que des systèmes, et les signaux d'alerte.
Source : mlab Academy — Plateforme de sensibilisation à la cybersécurité
URL : https://academy.mlab.sh/fr-FR/page/services-tiers
Module : Les services tiers visibles dans votre DNS — Sécuriser son domaine
Avertissement : Ce contenu est à des fins de sensibilisation uniquement.