Réseaux et infrastructures
Particuliers et entreprisesDétournement ou empoisonnement DNS
DNS hijacking / DNS poisoning / Pharming
Le nom du site est correct, mais la recherche de son adresse envoie au mauvais serveur.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Une personne saisit la bonne adresse d’un site, mais son appareil reçoit une mauvaise indication sur le serveur à joindre. L’attaque peut toucher son routeur, un service de résolution ou le compte qui gère le nom de domaine.
Comment cela fonctionne
Le DNS permet notamment de trouver l’adresse réseau correspondant au nom d’un site. Un attaquant peut changer les réglages d’un appareil, falsifier une réponse DNS ou prendre le contrôle des enregistrements du domaine. Vous pouvez alors être envoyé au mauvais endroit, perdre l’accès à un service ou subir un détournement de messagerie. HTTPS peut signaler que l’identité ne correspond pas, mais certains piratages de domaine permettent aussi d’obtenir un certificat valide.
- Le nom du service est demandé
L’appareil cherche son adresse.
- La réponse est détournée
Réglage, résolution ou domaine compromis.
- La connexion part ailleurs
Site, messagerie ou autre service.
Les signes qui doivent attirer l’attention
- Des enregistrements ou serveurs de noms changent sans validation.
- Le site répond différemment selon le réseau utilisé.
- La messagerie est perturbée ou des certificats inconnus sont émis.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Mettez votre routeur à jour et protégez son administration. Si une bonne adresse mène à une page inhabituelle ou une erreur de certificat, n’y saisissez pas de données sensibles.
Si vous êtes responsable du service ou de l’organisation
Protégez les comptes de gestion des domaines et du DNS. Surveillez les modifications des adresses, serveurs de noms et destinations du courrier.
Chiffrer les requêtes DNS ne protège pas un compte de gestion de domaine compromis.
À vous de décider
Vous avez saisi l’adresse habituelle, mais une page inattendue réclame votre mot de passe. La bonne orthographe de l’adresse suffit-elle pour continuer ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Le serveur vers lequel vous êtes dirigé, ou le service lui-même, peut avoir changé. Gardez vos données sensibles pour vous et signalez le changement par un contact connu. La page inhabituelle doit être vérifiée, mais ne prouve pas à elle seule un détournement DNS.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Le même nom de domaine conduit les utilisateurs à des destinations différentes
Le résolveur DNS R1 donne une destination différente de R2. Le serveur qui fait autorité confirme la réponse de R2, et la configuration de transfert de R1 a changé. Commencez donc par examiner R1 et les serveurs qu’il interroge. Les indices pointent vers cette partie du parcours plutôt que vers la zone publique.
Avant de conclure, vérifier les explications ordinaires : répartition géographique, DNS interne différent du DNS public, cache et durée de vie des réponses. Comparer le nom exact, le type d’enregistrement et l’heure. Un TTL différent n’est pas une preuve de fraude.
Le bit AD indique une validation DNSSEC rapportée par le résolveur, dans un contexte où l’on peut faire confiance à cette réponse. Son absence ne suffit pas à prouver un détournement. DNSSEC protège les données signées contre certaines falsifications, mais ne corrige pas un changement autorisé avec un compte de gestion compromis. Examiner aussi le bureau d’enregistrement, les délégations, les comptes d’administration et l’historique de zone. Le retour à la bonne réponse doit être vérifié depuis les réseaux touchés.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Question A / AAAA
Client vers Résolveur R1
Trace résolveur effectif
- Action
Résolution attendue
Résolveur R1 vers DNS faisant autorité
Trace délégation et alias
- Réponse
Adresse officielle
DNS faisant autorité vers Résolveur R1
Trace TTL et validation
- Réponse
Réponse divergente
Résolveur R1 vers Client
Trace 198.51.100.24
- Action
Connexion vers la réponse
Client vers Destination
Trace certificat reçu
- Action sur place
Audit du redirecteur
Résolveur R1
Trace changement 08:42
- Action
Comparaison indépendante
Client vers DNS faisant autorité
Trace zone inchangée
Comment repérer cette attaque
Indices à rechercher
Rechercher les réponses DNS divergentes, les changements non reconnus de configuration ou de délégation et les connexions vers des destinations inattendues.
Quelles informations comparer
Confronter la réponse du résolveur suspect à la zone faisant autorité, en tenant compte des caches et de l’heure. Localiser le changement : domaine, zone, résolveur ou configuration du poste.
Ce que ces indices ne permettent pas de conclure
Des réponses différentes peuvent venir d’un CDN, d’une zone interne ou d’une mise à jour en cours. L’absence du bit AD ne prouve pas une falsification ; elle ne signifie pas nécessairement que la réponse est invalide.
Comment réagir
Corriger la configuration ou la zone touchée, sécuriser ses comptes d’administration et vérifier les délégations ainsi que les accès API. Purger les caches concernés après correction. Rechercher les connexions, messages et sessions qui ont utilisé la mauvaise destination.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Comparer autorité et résolveurs après expiration ou purge contrôlée des caches.
- Tester la validation DNSSEC avec un outil adapté sans accepter aveuglément le seul bit AD.
- Vérifier A, AAAA, CNAME, MX et les paramètres DNS des clients concernés.
À vous de raisonner
Un seul résolveur renvoie une mauvaise destination ; l’autorité et un autre résolveur concordent. Où poursuivre la recherche, sans conclure trop vite ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Examinez le cache, la configuration et les serveurs amont du résolveur divergent. Comparez le même nom, le même type et la même période, en tenant compte du DNS interne et de la répartition géographique. Cette divergence ne prouve pas à elle seule que la zone publique a été compromise.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
forwarder- Redirecteur du résolveur modifié dans le cas ; ce changement se recherche dans l’historique de configuration, pas dans la seule réponse DNS.
AD=0- Absence d’indication de validation DNSSEC dans cette réponse, pas verdict d’attaque.
Réponses comparées et audit de zone
JournalRelevé synthétique à un même instant ; conserver les réponses complètes et l’identité du résolveur.
authoritative A service.example -> 203.0.113.8 TTL=300 serial=2026091701
resolver-R1 A service.example -> 198.51.100.24 TTL=180 AD=0
resolver-R2 A service.example -> 203.0.113.8 TTL=240 AD=1
zone_audit change_since_08:00=false
resolver-R1 config_changed=08:42 forwarder=unknown
registrar nameservers_changed=falsePréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Sonde réseau Zeek — dns.log
- Où les trouver
- Dans les journaux dns.log de la sonde : examiner query, qtype_name, rcode_name, answers et TTLs avec l’heure et les adresses de la connexion.
- Quoi relever
- Comparer pour le même nom et type les réponses, codes d’erreur, TTL et résolveurs contactés. Distinguer réponse observée pendant l’incident et résolution de contrôle faite plus tard.
- Accès et prérequis
- Les requêtes doivent passer devant la sonde sous une forme observable. Le DNS chiffré peut nécessiter les journaux du résolveur ; une capture commencée après les faits ne restitue pas l’ancienne réponse.
BIND 9 — journaux du résolveur DNS
- Où les trouver
- Dans les destinations définies par le bloc logging de named.conf : les canaux et catégories configurés déterminent quels journaux existent et où ils sont écrits.
- Quoi relever
- Sur le résolveur concerné, demander les journaux configurés et l’historique des changements de redirecteurs. Auprès du gestionnaire de domaine, comparer séparément les modifications de zone et de serveurs DNS.
- Accès et prérequis
- Accès au résolveur ou export par son exploitant. La journalisation des requêtes n’est pas un historique des modifications de configuration ; conserver séparément ces changements et leurs approbations.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àCampagneSea Turtle
Détourner le DNS pour intercepter les connexions
Les attaquants modifient des enregistrements DNS pour envoyer les utilisateurs vers leurs propres serveurs. Ils y imitent les services attendus et capturent les identifiants, puis relaient la connexion au vrai service pour rendre le détournement moins visible.
Ce qu’établit la source. Cisco Talos nomme cette campagne Sea Turtle et estime avec une confiance élevée qu’elle relève d’un acteur soutenu par un État. Le rapport de 2019 ne nomme pas cet État.
Consulter le rapport DNS Hijacking Abuses Trust In Core Internet ServiceCisco Talos · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Vérifiez la résolution depuis plusieurs sources et l’historique des changements.
- Récupérez les comptes concernés puis restaurez les enregistrements fiables.
- Évaluez les sites, courriels et certificats affectés pendant la période.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Adversary-in-the-Middle — attack.mitre.org
- ICANN — DNSSEC — icann.org
- CISA — détournement DNS (directive historique de janvier 2019) · PDF sur ECRAN — CISA3 pages · anglais · édition : 22 janvier 2019 · Provenance et copie
- RFC 4033 — DNSSEC — www.rfc-editor.org
