Réseaux et infrastructures
Particuliers et entreprisesDétournement ou empoisonnement DNS
DNS hijacking / DNS poisoning / Pharming
La résolution d’un nom de domaine conduit vers une mauvaise destination.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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 associe notamment les noms des sites à leurs adresses réseau. Le détourner revient à modifier cette orientation. Les variantes diffèrent : changer les réglages d’un appareil, falsifier une réponse ou prendre le contrôle des enregistrements d’un domaine. Le résultat peut être une redirection, une panne ou un détournement de messagerie. HTTPS peut encore signaler une incohérence d’identité, mais certaines compromissions de domaine permettent aussi d’obtenir des certificats valides.
- 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.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. L’orientation vers le serveur ou le service lui-même peut avoir été modifié. N’y saisissez pas de données sensibles et signalez ce changement par un canal connu. Une page inhabituelle est un indice à vérifier, pas une preuve suffisante de détournement DNS.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Le même nom de domaine conduit les utilisateurs à des destinations différentes
Le résolveur R1 renvoie une destination différente de R2. Le serveur faisant autorité répond comme R2, tandis que la configuration de transfert DNS de R1 a changé. Ces éléments orientent l’enquête vers le résolveur ou son amont, plutôt que vers une modification de 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.
Éléments à croiser
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.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àCampagneSea Turtle
Détourner le DNS pour intercepter les connexions
Des enregistrements DNS modifiés dirigent les utilisateurs vers des serveurs contrôlés par les attaquants. Ceux-ci imitent les services attendus, capturent les identifiants puis transmettent la connexion au vrai service, ce qui rend le détournement discret.
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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 qualifier votre situation et être orienté : 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
