Détournement de nom de domaine : 6 protections pour PME

Fin septembre 2026, des pirates ont pris la main sur les registres de trois extensions pays (.gh, .sl et .as). Résultat : des certificats HTTPS parfaitement valides pour google.com.gh, youtube.sl ou google.as, et pour d’autres grandes marques. Google n’a pas été piraté, les autorités de certification n’ont rien fait de travers. Et pourtant, le cadenas s’affichait bien sur des domaines contrôlés par les attaquants.

Quand j’ai lu l’annonce de Google le 6 octobre, ma première pensée n’a pas été pour Google. Elle a été pour les comptes registrar de mes clients.

Parce que ce que montre cette affaire, je le répète depuis des années en maintenance : la sécurité d’un site ne commence pas sur le serveur, elle commence au nom de domaine. Vous pouvez avoir un WordPress à jour, un pare-feu, des sauvegardes tous les jours. Si quelqu’un redirige votre domaine ailleurs, tout ça ne sert à rien.

Alors on va voir ce qui s’est passé, pourquoi les protections habituelles n’ont rien empêché, et surtout ce que vous pouvez faire dès cette semaine pour vos propres domaines.

Que s’est-il passé avec les .gh, .sl et .as ?

Les attaquants n’ont pas visé Google. Ils ont visé les opérateurs qui gèrent ces trois extensions pays, ce qui mettait en danger tous les domaines en .gh, .sl ou .as, quel que soit leur propriétaire. Une fois dans la place, ils ont modifié les DNS autoritatifs et demandé des certificats HTTPS (annonce de Google).

Un chercheur a épluché les journaux publics de certificats (Certificate Transparency) et publié son analyse sur la liste sécurité de Mozilla (groups.google.com). Il compte 102 certificats frauduleux, émis en trois vagues :

Date	Extension	Durée observée	Certificats émis
22 septembre	.gh (Ghana)	environ 3 heures	23
25 septembre	.sl (Sierra Leone)	au moins 11 heures	69
27 septembre	.as (Samoa américaines)	au moins 19 heures	10

Les certificats sortaient de chez Let’s Encrypt et ZeroSSL, avec des réglages proches de ceux de Certbot par défaut. Rien d’exotique. Google les a bloqués dans Chrome via ses listes de révocation (CRLSets), et les révocations ont suivi le 26 septembre et le 1er octobre (SecurityWeek).

Le détail qui m’a le plus marqué : avant l’attaque, tous les certificats de google.com.gh, google.sl et google.as venaient de Google Trust Services, l’autorité de Google. Un certificat Let’s Encrypt qui débarque d’un coup, c’était une anomalie visible. Encore fallait-il regarder.

Pourquoi le cadenas HTTPS n’a rien protégé ?

C’est la question que mes clients me posent le plus souvent, et la réponse surprend : un certificat SSL valide ne prouve pas qu’un site est le bon. Il prouve juste que le demandeur contrôlait le domaine au moment de la demande.

Pour délivrer un certificat, l’autorité vérifie que vous contrôlez le domaine : un enregistrement DNS TXT à créer, ou un fichier à déposer sur le serveur. Celui qui tient les DNS passe ce test les doigts dans le nez. Les autorités de certification ont donc fait exactement leur travail.

Et deux protections qu’on cite souvent n’ont servi à rien ici :

DNSSEC : il ne protège pas contre un registre compromis, puisque c’est justement le registre qui publie la clé de confiance (l’enregistrement DS) de votre domaine.
La validation depuis plusieurs points du réseau : inutile, puisque la fausse délégation est servie de la même façon partout dans le monde.

Votre domaine est-il concerné, même en .fr ou .com ?

Par cette attaque précise, non. Rien n’indique que les registres du .fr ou du .com aient été touchés, et l’Afnic comme Verisign n’ont pas grand-chose à voir avec l’opérateur d’une petite extension pays.

Mais ne vous arrêtez pas là. Le même scénario arrive en version miniature, et bien plus souvent : c’est votre compte chez le registrar qui se fait pirater. OVH, Gandi, Infomaniak, o2switch, IONOS, peu importe. Un mot de passe réutilisé, une boîte mail compromise, et l’attaquant change vos DNS en deux clics.

Petit aparté sur les extensions « tendance » (.io, .ly, .ai, .me…) : leur sécurité dépend du registre du pays concerné, et vous n’avez aucune prise dessus. Oui, digitalcorner.me est en .me, je suis donc le premier concerné. Pour un site vraiment stratégique, je conseille quand même de garder le .fr ou le .com en domaine principal.

Ce qu’un pirate peut faire avec vos DNS

Concrètement, quelqu’un qui contrôle vos DNS peut :

Obtenir un certificat HTTPS valide et afficher une copie de votre site, cadenas compris.
Modifier vos enregistrements MX et recevoir vos emails. Y compris les liens « mot de passe oublié » de votre WordPress, de votre banque ou de vos outils en ligne.
Se déclarer propriétaire de votre domaine dans Google Search Console avec un simple enregistrement TXT, puis demander des suppressions d’URL ou fouiller vos données.
Plomber votre référencement en servant du spam à Googlebot. J’en ai fait les frais sur mon propre site, je raconte tout dans mon retour d’expérience sur un piratage WordPress. Nettoyer l’index Google prend des semaines.

Et quand vous récupérez la main, ce n’est pas fini. Google le rappelle : les autorités de certification peuvent réutiliser une validation de domaine déjà faite pendant un certain temps. Un pirate qui a validé votre domaine pendant le détournement peut donc, en théorie, obtenir de nouveaux certificats après coup.

Les 6 protections que j’applique sur les domaines de mes clients

Rien de tout ça n’est réservé aux grands groupes. Comptez moins d’une heure par domaine pour l’essentiel.

1. Faites l’inventaire de tous vos domaines

On ne protège pas ce qu’on a oublié. Et des domaines oubliés, j’en trouve chez presque tous les clients que j’audite : l’extension achetée « pour protéger la marque », l’ancien nom de l’entreprise, le domaine d’un salon d’il y a cinq ans. Google insiste d’ailleurs là-dessus : la surveillance doit couvrir tout le portefeuille, domaines parqués compris.

Pour chaque domaine, notez le registrar, le compte associé, l’email de contact et la date d’expiration. Un simple tableur suffit.

2. Verrouillez votre compte registrar

Si vous ne deviez faire qu’une chose dans cet article, ce serait celle-là :

Double authentification (2FA) obligatoire, avec une application type Google Authenticator ou une clé de sécurité. Pas par SMS si vous pouvez l’éviter.
Un email de récupération qui n’est pas sur le domaine lui-même. Sinon, perdre le domaine, c’est aussi perdre l’accès au compte qui permet de le récupérer. Je le vois régulièrement.
Le verrou de transfert activé (statut clientTransferProhibited).
Pour les domaines vraiment critiques, le Registry Lock proposé par certains registres, dont l’Afnic pour le .fr : toute modification des serveurs DNS demande alors une validation manuelle.

3. Publiez un enregistrement CAA restrictif

L’enregistrement CAA dit quelles autorités ont le droit de délivrer un certificat pour votre domaine. Toutes les autres doivent refuser. C’est LA recommandation de Google après cet incident.

Exemple pour un site en Let’s Encrypt :

exemple.fr.  CAA 0 issue "letsencrypt.org"
exemple.fr.  CAA 0 issuewild ";"
exemple.fr.  CAA 0 iodef "mailto:securite@exemple.fr"

On peut aller plus loin avec la norme RFC 8657 et limiter l’émission à un compte ACME précis et à une méthode de validation donnée :

exemple.fr.  CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

C’est ce paramètre accounturi qui empêche un pirate de réutiliser une validation en cache une fois le détournement terminé.

Attention, piège classique : sur un hébergement mutualisé, c’est souvent l’hébergeur qui génère le certificat avec son propre compte ACME. Si vous ajoutez un accounturi sans vérifier lequel il utilise, le renouvellement automatique va échouer, et votre site affichera une belle erreur de certificat dans 60 à 90 jours. Demandez d’abord à votre hébergeur.

Pour voir le CAA actuel de votre domaine :

# Linux / macOS
dig CAA exemple.fr +short

# Windows PowerShell
Resolve-DnsName exemple.fr -Type CAA

Soyons honnêtes : CAA ne bloque pas une attaque en cours, puisque celui qui tient les DNS peut le modifier ou le supprimer. Son intérêt, c’est de limiter la casse une fois que vous avez repris la main.

4. Surveillez les journaux Certificate Transparency

Tout certificat reconnu par les navigateurs est publié dans des journaux publics. En les surveillant, vous êtes prévenu presque en temps réel dès qu’un certificat est émis pour votre domaine. C’est exactement ce qui a permis de reconstituer l’attaque des .gh, .sl et .as.

Les outils que j’utilise ou que je recommande :

Outil	Usage	Prix
crt.sh	Vérification ponctuelle : `https://crt.sh/?q=%25.exemple.fr`	Gratuit
Cert Spotter (SSLMate)	Alerte email à chaque nouveau certificat	Offre gratuite limitée
Cloudflare CT Monitoring	Alertes intégrées si votre DNS est chez Cloudflare	Inclus

Ce qu’il faut repérer : un certificat émis par une autorité que vous n’utilisez pas, ou un certificat wildcard (*.exemple.fr) que personne n’a demandé.

5. Surveillez les changements DNS

Une modification inattendue des serveurs de noms (NS) ou des MX, c’est le signal d’alerte le plus précoce. Pas besoin d’un outil compliqué : un contrôle quotidien qui compare les enregistrements NS, A, MX et CAA à une valeur de référence suffit. Je l’ai ajouté aux contrôles de maintenance WordPress que je fais pour mes clients, au même niveau que les mises à jour.

6. Préparez votre plan de réaction

Le jour où ça arrive, vous n’aurez pas le temps de chercher. Voici l’ordre que je suis :

Reprendre la main sur le compte registrar (avoir le contact du support sous la main, c’est du temps gagné).
Remettre les serveurs DNS et les enregistrements d’origine.
Lister les certificats émis pendant l’incident sur crt.sh et demander leur révocation à l’autorité concernée.
Publier ou durcir le CAA avec accounturi.
Changer les mots de passe de tous les services dont les emails ont pu être interceptés.
Vérifier dans Google Search Console la liste des propriétaires et supprimer ceux que vous ne connaissez pas.

Mon avis : le domaine, le grand oublié des audits de sécurité

Quand on parle sécurité de site, tout le monde pense plugins, mots de passe admin et pare-feu. Le compte registrar, lui, passe presque toujours à la trappe. C’est pourtant lui qui contrôle tout le reste : le site, les emails, les certificats, la Search Console.

Ma recommandation est simple : commencez par la 2FA sur le registrar et le CAA, c’est une demi-heure de travail. La surveillance CT et DNS viennent ensuite, et c’est typiquement le genre de chose qu’on intègre une bonne fois pour toutes dans un contrat de maintenance.

Questions fréquentes

Un certificat SSL valide garantit-il qu’un site est authentique ?

Non. Il garantit que la connexion est chiffrée et que le demandeur contrôlait le domaine au moment de l’émission. Si les DNS sont détournés, un pirate peut obtenir un certificat parfaitement valide, comme l’a montré l’attaque sur les extensions .gh, .sl et .as en septembre 2026.

Qu’est-ce qu’un enregistrement CAA ?

C’est un enregistrement DNS qui liste les autorités de certification autorisées à délivrer un certificat pour votre domaine. Les autres doivent refuser. Avec les paramètres accounturi et validationmethods, on peut même limiter l’émission à un compte précis.

DNSSEC protège-t-il contre le détournement de nom de domaine ?

DNSSEC protège contre la falsification des réponses DNS en transit, mais pas contre la compromission du registre ou de votre compte registrar. Celui qui contrôle ces éléments peut aussi modifier ou désactiver la signature.

Comment savoir si un certificat a été émis pour mon domaine sans mon accord ?

Consultez les journaux Certificate Transparency, par exemple sur crt.sh, ou activez une alerte automatique avec Cert Spotter ou le monitoring CT de Cloudflare.

Un détournement de domaine peut-il impacter mon référencement ?

Oui. Un pirate qui contrôle vos DNS peut servir du contenu malveillant à Google, déclencher des avertissements de sécurité dans les résultats et même valider la propriété du domaine dans Search Console. Le nettoyage de l’index prend ensuite plusieurs semaines.

3 choses à faire cette semaine

Activez la 2FA sur tous vos comptes registrar, avec un email de récupération hors du domaine.
Publiez un enregistrement CAA (après avoir vérifié qui génère vos certificats).
Créez une alerte Certificate Transparency pour vos domaines principaux.

Vous ne savez pas où en sont vos domaines ? Je propose un audit de sécurité à partir de 490 € HT, qui passe en revue votre WordPress mais aussi la configuration de votre nom de domaine : 2FA registrar, CAA, verrou de transfert, surveillance CT.

👉 Demander mon audit de sécurité

Sources

Article rédigé par Florian Verrine, développeur WordPress freelance et consultant digital depuis 20 ans. Digitalcorner accompagne les TPE, PME et e-commerçants sur la création, la sécurité et le référencement de leurs sites, avec plus de 250 sites accompagnés en France.