Changement inattendu de serveurs de noms ou de registrar : les premiers signes d'un détournement de domaine
Le détournement de domaine signifie qu'une autre personne que vous prend le contrôle de la destination de votre domaine. Les moyens les plus directs : changer les serveurs de noms, transférer le domaine vers un autre bureau d'enregistrement (registrar) ou modifier les enregistrements DNS dans votre compte chez le fournisseur DNS. Chacune de ces actions est une opération d'administration normale, c'est pourquoi un changement inattendu est le signal d'alerte le plus précoce et le plus clair.
Qui contrôle votre DNS peut envoyer les visiteurs de votre site et vos e-mails entrants vers ses propres serveurs. Comme il contrôle le domaine, il peut aussi obtenir des certificats TLS valides pour celui-ci : les visiteurs ne voient alors aucun avertissement du navigateur.
La bonne nouvelle : ces changements sont visibles de l'extérieur, et registrars et registres proposent des verrous qui les rendent beaucoup plus difficiles à réaliser.
Comment se produit un détournement DNS en pratique
En janvier 2019, la CISA a publié l'Emergency Directive 19-01 après une campagne au cours de laquelle des attaquants ont obtenu les identifiants de comptes permettant de modifier des enregistrements DNS. Ils ont modifié des enregistrements A, MX et NS pour faire transiter le trafic web et la messagerie par une infrastructure sous leur contrôle, et ont obtenu des certificats valides pour les domaines concernés. La directive (depuis levée) imposait aux agences d'auditer leurs enregistrements DNS, de changer les mots de passe des comptes DNS, d'ajouter l'authentification multifacteur et de surveiller les journaux Certificate Transparency. Ces 4 mesures restent une bonne base pour toute organisation.
Les points d'entrée courants sont :
- Un identifiant compromis chez le registrar ou le fournisseur DNS, souvent via un mot de passe réutilisé ou hameçonné.
- Un compte e-mail compromis qui reçoit les messages de réinitialisation de mot de passe du registrar.
- L'ingénierie sociale envers le support du registrar.
- Un domaine expiré réenregistré par quelqu'un d'autre, sujet traité dans ce qui se passe quand votre domaine expire.
À quoi ressemble un changement inattendu
Gardez une trace de ce qui est normal pour votre domaine, puis comparez :
- Serveurs de noms (NS) : un passage de votre fournisseur DNS habituel à des serveurs inconnus.
- Registrar : le domaine désormais géré par un registrar que vous n'avez jamais utilisé.
- Enregistrements A, AAAA et CNAME : votre site pointe soudain vers une adresse IP d'un réseau que vous n'utilisez pas.
- Enregistrements MX : la messagerie passe par un serveur que vous n'avez pas configuré.
- Codes de statut EPP : des verrous de protection comme
clientTransferProhibitedretirés sans raison. - Nouveaux certificats : un certificat pour votre domaine émis par une autorité de certification que vous n'utilisez pas.
Comment vérifier vous-même votre domaine
Lisez directement les valeurs actuelles :
dig NS example.com +short
dig A example.com +short
dig MX example.com +short
whois example.com | grep -i -E "registrar:|name server|status"
Conservez le résultat. Lancez régulièrement les mêmes commandes et comparez. Une différence que vous ne savez pas expliquer mérite une question immédiate à la personne qui gère votre DNS.
Pour les certificats, recherchez votre domaine dans les journaux Certificate Transparency sur crt.sh et regardez les émetteurs. Voir les journaux Certificate Transparency expliqués.
Les verrous : verrou registrar et verrou registre
La référence des codes de statut EPP de l'ICANN décrit les statuts qui protègent un domaine :
clientTransferProhibited: posé par votre registrar. Le registre refuse les demandes de transfert du domaine vers un autre registrar. C'est le « verrou registrar » courant, qui doit être actif sur chaque domaine que vous n'êtes pas en train de transférer.clientUpdateProhibitedetclientDeleteProhibited: le registre refuse les modifications ou la suppression tant que votre registrar n'a pas retiré le statut.- Verrou registre (registry lock) : certains opérateurs de registre proposent un service qui pose
serverUpdateProhibited,serverTransferProhibitedetserverDeleteProhibited. Ces statuts sont posés au niveau du registre et non dans votre compte registrar, et l'ICANN précise que le retrait d'un statut server prend généralement plus de temps, ce qui est justement le but. Demandez à votre registrar s'il est disponible pour votre extension.
Un verrou registrar seul n'aide pas si l'attaquant se connecte à votre compte registrar, car il peut le retirer. Un verrou registre ajoute une étape en dehors de ce compte : un mot de passe registrar volé ne suffit plus.
Renforcer les comptes qui contrôlent le DNS
- Authentification multifacteur sur les comptes du registrar et du fournisseur DNS, de préférence une clé de sécurité ou une passkey plutôt que le SMS.
- Une adresse de contact dédiée pour le registrar, sur une boîte aux lettres protégée aussi fortement que le compte registrar lui-même.
- Peu de personnes avec un accès, et des accès retirés lorsque quelqu'un part.
- Un enregistrement CAA qui liste les autorités de certification que vous utilisez, défini dans la RFC 8659. Par exemple :
example.com. CAA 0 issue "letsencrypt.org"
CAA n'empêche pas un attaquant qui contrôle votre DNS de le modifier, mais il complique l'émission imprévue par d'autres autorités, et un changement de CAA devient lui-même un signal.
Si vous constatez un changement que vous n'avez pas fait
- Contactez votre registrar et votre fournisseur DNS par un canal connu, pas via un lien reçu par e-mail.
- Rétablissez les bons enregistrements NS, A et MX et réactivez les verrous.
- Changez les mots de passe et réinitialisez l'authentification multifacteur de ces comptes et du compte e-mail qui reçoit leurs notifications.
- Vérifiez dans les journaux Certificate Transparency les certificats émis pendant la période concernée et demandez à l'autorité émettrice de révoquer ceux que vous n'avez pas demandés.
- Considérez comme potentiellement exposés les mots de passe et sessions utilisés sur votre site et votre messagerie pendant cette période.
Liste de contrôle
- Référence des NS, A, MX, registrar et codes de statut enregistrée.
- Verrou registrar actif, verrou registre envisagé.
- Authentification multifacteur sur le registrar, le DNS et la boîte aux lettres associée.
- Enregistrement CAA publié.
- Comparaison régulière avec la référence.
La place de Datahorses
Datahorses surveille votre entreprise depuis l'extérieur et vérifie les changements de vos serveurs de noms, de votre registrar, de vos enregistrements DNS et des certificats nouvellement émis. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès. Un changement inattendu est examiné par un spécialiste et vous est transmis avec ce qui a changé, quand, et ce qu'il faut faire en premier. Découvrez comment nous surveillons et ce qui se passe lorsque nous trouvons quelque chose.
Plus d’articles
Prise de contrôle de sous-domaine : comment un enregistrement DNS oublié devient le site de quelqu'un d'autre
Un sous-domaine qui pointe encore vers un service cloud supprimé peut être revendiqué par quiconque crée ce service. Voici comment cela arrive et comment vérifier votre DNS.
Ce qui se passe quand le nom de domaine de votre entreprise expire, et comment l'éviter
Quand un domaine expire, le site et la messagerie s'arrêtent généralement en premier, puis le nom peut être perdu pour de bon. Voici le calendrier et comment l'éviter.
PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre
Le projet PHP a corrigé 2 failles critiques le 21 octobre 2026. Voici les versions qui contiennent le correctif, comment voir ce qu'annonce votre serveur et quoi demander à votre hébergeur.