Detecter les changements de données d'enregistrement de domaine

Un attaquant accède à un compte registrar via une adresse email compromise. Il change les nameservers. Le trafic qui devrait atteindre vos serveurs est redirigé vers les siens. Le propriétaire légitime du domaine s'en aperçoit 48 heures plus tard parce que "quelque chose semble bizarre" avec le site. Si un système de détection de changements avait été en place, le changement de nameservers aurait déclenché une alerte dans les heures suivant son occurrence, la différence entre deux jours de dommages et deux heures.

Cet article couvre ce qui peut changer dans les données d'enregistrement d'un domaine, ce que chaque type de changement signifie, et comment configurer la détection automatique.

Ce qui peut changer dans les données d'enregistrement d'un domaine

Tous les changements ne présentent pas le même risque. Il est utile de les catégoriser.

Champs opérationnels, impact immédiat possible :

• Nameservers : détermine où les requêtes DNS sont résolues. Un changement de nameservers non autorisé redirige tout le trafic, votre site, vos emails, tout service utilisant ce domaine. C'est l'indicateur le plus clair d'un hijacking de domaine actif.
• Statuts EPP : le retrait de clientTransferProhibited est souvent la première étape d'un transfert. L'apparition de clientHold signifie que la résolution DNS s'est déjà arrêtée.
• Registrar : un changement de registrar en dehors d'un transfert que vous avez autorisé est un fort indicateur de hijacking. C'est relativement rare mais grave quand ça arrive.

Champs informatifs, signaux stratégiques ou administratifs :

• Nom ou organisation du registrant : changement de propriétaire.
• Email du registrant : changement de contact. Si non autorisé, c'est souvent un précurseur d'une prise de contrôle du compte.
• Date d'expiration : avancement ou report de la date d'expiration.

Champs transitoires, normaux, signalent une opération en cours :

• pendingTransfer : un transfert a été initié.
• pendingUpdate : une modification de données est en cours de traitement.

Anatomie d'un hijacking de domaine dans les données RDAP

Voici comment un hijacking typique se déroule, mappé sur ce que RDAP montrerait à chaque étape :

1. L'attaquant compromet le compte email associé au compte registrar. Rien n'apparaît encore dans RDAP, cette étape est invisible au niveau du domaine.
2. L'attaquant change l'email du compte registrar. Si le registrar met à jour WHOIS avec le nouvel email du registrant, ce changement apparaît dans RDAP comme une modification des coordonnées du registrant.
3. L'attaquant retire clientTransferProhibited et initie un transfert vers un autre registrar, ou change directement les nameservers. RDAP montre maintenant : changement de statut, nouveaux nameservers, potentiellement pendingTransfer.
4. Le DNS se propage vers les nouveaux nameservers. Selon les valeurs TTL, cela peut prendre des minutes à des heures.

Les étapes 3 et 4 sont détectables via un diff RDAP. Les étapes 1 et 2 peuvent ne pas apparaître immédiatement, mais dès que l'attaquant passe à l'étape 3, il y a un signal détectable.

Hijacking de compte vs. hijacking de domaine : la différence

Une compromission de compte registrar n'apparaît pas immédiatement dans RDAP. Le compte peut être violé sans qu'aucun changement au niveau du domaine ne soit visible. La détection de changements de domaine capte les conséquences d'une compromission de compte (quand les nameservers ou les statuts sont modifiés) pas la compromission elle-même. C'est une couche de défense complémentaire, pas un remplacement de la sécurité du compte (mots de passe forts, 2FA sur votre compte registrar).

Causes légitimes de changements dans les données RDAP

Avant de traiter tout changement comme suspect, il est utile de connaître les patterns de changement attendus. Les faux positifs font perdre du temps et érodent la confiance dans le système d'alertes.

Changements légitimes courants :

• Le renouvellement annuel met à jour la date d'expiration.
• Une migration d'hébergeur planifiée change les nameservers.
• Un transfert inter-registrar autorisé.
• Mise à jour des coordonnées du registrant (nouvelle adresse, fusion d'entreprise).
• Activation ou désactivation de la protection vie privée WHOIS.

Le conseil pratique : tenez un journal des opérations planifiées sur vos domaines. Quand une alerte se déclenche, consultez d'abord ce journal. Si le changement correspond à une opération prévue, acquittez-le. Sinon, enquêtez immédiatement.

Comment Domain Sentinel détecte les changements de données

À chaque cycle de vérification, Domain Sentinel interroge RDAP pour chaque domaine de votre watchlist et stocke le résultat. Au cycle suivant, il compare la nouvelle réponse au snapshot stocké champ par champ. Tout champ qui diffère de la valeur précédente génère un événement de changement.

L'alerte contient le champ spécifique qui a changé, la valeur précédente, et la nouvelle valeur. C'est suffisant pour évaluer immédiatement si le changement était attendu.

Ce que Domain Sentinel compare (et ce qu'il ignore)

Toute différence de champ n'est pas significative. Les registres mettent parfois à jour des horodatages internes ou du formatage sans que l'état réel du domaine change de façon significative. La comparaison se concentre sur les champs opérationnellement significatifs : nameservers, statuts EPP, registrar, date d'expiration, et données de contact du registrant. Les mises à jour de timestamps de routine que les registres ajoutent aux enregistrements ne déclenchent pas d'alertes.

Comment réagir à un changement suspect

Quand une alerte se déclenche et que vous ne reconnaissez pas le changement, le temps est la variable critique. Plus vite vous agissez, moins il y a de dommages.

1. Nameservers changés de façon inattendue : vérifiez si votre résolveur DNS renvoie encore les anciennes réponses de nameservers, cela vous indique si le changement s'est propagé. Notez les nouvelles valeurs de nameservers. Si vous n'avez pas autorisé le changement, contactez immédiatement l'équipe de sécurité/abus de votre registrar.
2. clientTransferProhibited retiré : contactez votre registrar maintenant et demandez le rétablissement du verrou de transfert. Si un transfert est déjà en cours, vous avez une fenêtre pour le rejeter (généralement 5 jours pour .com).
3. Registrar changé sans transfert autorisé : contactez l'Ombudsman des registrars de l'ICANN et votre registrar d'origine avec une preuve de propriété. C'est le scénario le plus grave et peut nécessiter une escalade formelle.
4. Email du registrant changé : c'est souvent le signe d'une prise de contrôle de compte en cours. Initiez une récupération d'urgence via le canal de support de votre registrar, pas via l'adresse email du compte compromis.

La détection de changements de domaine fonctionne comme une caméra de sécurité sur vos domaines. Elle ne prévient pas les attaques, mais elle réduit la fenêtre de détection de jours à heures. Pour le hijacking de domaine, cette différence est souvent celle entre un incident récupérable et une perte permanente.