En bref

  • Les registres des ccTLD .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines) ont été compromis, permettant à des attaquants de modifier les DNS de tout domaine sous ces extensions.
  • Les attaquants ont exploité ce contrôle DNS pour obtenir des certificats TLS frauduleux pour des domaines appartenant à Google et d'autres grandes organisations mondiales.
  • Google Chrome a réagi en révoquant immédiatement les certificats via CRLSets et appelle tous les propriétaires de domaines à publier des enregistrements CAA restrictifs.

Comment trois registres de domaines nationaux ont été compromis

Entre le 7 et le 9 octobre 2026, la communauté de la sécurité Internet a découvert une série d'incidents coordonnés visant les opérateurs de trois extensions de domaines nationaux : le .gh (Ghana), le .sl (Sierra Leone) et le .as (Samoa américaines). Des attaquants non identifiés ont réussi à compromettre ces registres ccTLD tiers, mettant en danger l'intégralité des domaines enregistrés sous ces extensions, soit plusieurs centaines de milliers d'adresses actives. L'incident a été documenté par Help Net Security, The Register et GBHackers dès le 7 octobre 2026.

La mécanique de l'attaque repose sur une chaîne de confiance fondamentale dans l'architecture du Web : le lien entre le contrôle DNS d'un domaine et la capacité à obtenir un certificat TLS pour ce domaine. Les autorités de certification — Digicert, Let's Encrypt, Sectigo et autres — vérifient qu'un demandeur contrôle bien le domaine pour lequel il réclame un certificat. Cette vérification s'effectue souvent en demandant au requérant de publier un enregistrement DNS spécifique. Si un attaquant contrôle les serveurs DNS autoritaires d'un domaine, il peut satisfaire ces vérifications sans jamais avoir accès aux serveurs réels de l'organisation cible.

C'est exactement ce mécanisme qu'ont exploité les attaquants. En modifiant les enregistrements DNS autoritaires via les registres ccTLD compromis, ils ont pu se faire passer pour les propriétaires légitimes de domaines en .gh, .sl et .as appartenant à de grandes organisations, dont Google. Des demandes de certificats TLS ont alors été soumises à des autorités de certification qui, ne voyant aucune anomalie dans les réponses DNS (pourtant falsifiées à la source), ont émis des certificats techniquement valides pour ces domaines.

La découverte de l'incident a été rendue possible grâce au système de Certificate Transparency (CT), un mécanisme créé précisément pour détecter ce type d'émissions non autorisées. Les journaux CT, accessibles publiquement, enregistrent chaque certificat émis par les autorités de certification participantes. Google surveille ces journaux en temps réel pour détecter toute émission suspecte sur ses propres domaines. C'est cette surveillance automatisée qui a déclenché l'alerte, permettant une réaction rapide de l'équipe Chrome Security.

En réponse, Google Chrome a immédiatement révoqué les certificats frauduleux en les ajoutant à ses CRLSets — un mécanisme de mise à jour rapide des listes de révocation intégré au navigateur, qui ne nécessite pas de mise à jour complète de Chrome pour être déployé. Les autorités de certification impliquées ont également procédé à la révocation formelle de l'ensemble des certificats émis de manière non autorisée. Selon le billet de blog officiel de Google Security, la réaction de bout en bout — de la détection à la révocation — a pris moins de 48 heures.

L'ampleur exacte de l'attaque reste en cours d'évaluation. Si Google figure parmi les organisations dont des certificats frauduleux ont été forgés, des sources proches du dossier indiquent que d'autres grandes marques mondiales — dans les secteurs des télécommunications, de la finance et des services cloud — pourraient également être concernées. Les opérateurs des registres ccTLD .gh, .sl et .as ont confirmé avoir perdu temporairement le contrôle de leurs systèmes DNS autoritaires, sans divulguer à ce stade le vecteur d'attaque initial.

Cet incident n'est pas isolé dans l'histoire de la sécurité Internet. En 2019, une campagne similaire ciblant des ccTLD du Moyen-Orient et d'Afrique du Nord avait permis à des attaquants présumés iraniens de détourner du trafic gouvernemental pendant plusieurs semaines. En 2021, des compromissions de registres de domaines de territoires insulaires avaient temporairement mis en danger des milliers de domaines d'entreprises technologiques. Le schéma se répète : les ccTLD de petits pays ou territoires disposent souvent de ressources limitées pour sécuriser leur infrastructure, ce qui en fait des cibles attractives pour des attaquants sophistiqués.

Sur le plan technique, l'incident souligne une limite structurelle du modèle de validation des certificats TLS par méthode DNS-01 : la sécurité du certificat ne dépend pas uniquement de la CA et du propriétaire du domaine, mais aussi de tous les intermédiaires dans la chaîne DNS. Un registre ccTLD compromis peut potentiellement invalider la sécurité TLS de l'ensemble des domaines qu'il gère, quel que soit le niveau de sécurité déployé par les propriétaires individuels de ces domaines. Cette fragilité est connue, mais peu de solutions systémiques ont été déployées à grande échelle pour y remédier.

Pourquoi cet incident remet en question la confiance dans le Web

La compromission de registres ccTLD pour forger des certificats TLS valides est l'un des scénarios les plus préoccupants pour la sécurité du Web. Un certificat TLS valide — même obtenu frauduleusement — est visuellement indiscernable d'un certificat légitime pour l'utilisateur final. Le cadenas dans la barre d'adresse d'un navigateur signifie uniquement que la connexion est chiffrée et que le certificat a été émis par une autorité de certification reconnue ; il ne garantit pas que l'entité derrière le serveur est bien celle qu'elle prétend être si la validation DNS a été compromise à la source.

Ce type d'attaque ouvre la voie à des scénarios d'interception du trafic (man-in-the-middle) extrêmement difficiles à détecter pour les utilisateurs finaux. Un attaquant capable de combiner un certificat TLS frauduleux pour google.gh avec une redirection DNS du trafic correspondant pourrait intercepter des sessions authentifiées pour les utilisateurs locaux, y compris des connexions à Gmail, Google Workspace ou Google Cloud, sans déclencher d'alerte visuelle dans le navigateur.

L'incident illustre également les limites du modèle de gouvernance des ccTLD. Contrairement aux gTLD (.com, .org, .net) gérés par des registres structurés et audités selon les standards ICANN, de nombreux ccTLD de petits pays ou territoires sont opérés par des entités locales avec des ressources techniques et financières réduites. La mise à niveau de leur sécurité — notamment la mise en place de DNSSEC, de la MFA sur les interfaces d'administration et d'une surveillance en temps réel des modifications DNS — devrait être une priorité pour l'écosystème Internet global.

La publication d'enregistrements CAA (Certification Authority Authorization) par les propriétaires de domaines constitue aujourd'hui la principale défense disponible contre ce type d'attaque. Un enregistrement CAA correctement configuré liste explicitement les autorités de certification autorisées à émettre des certificats pour un domaine donné. Toute CA respectueuse des standards doit vérifier cet enregistrement avant d'émettre. Si les enregistrements CAA avaient été en place pour les domaines Google ciblés, même un registre ccTLD compromis n'aurait pas pu permettre l'émission de certificats frauduleux par la plupart des CA.

Ce qu'il faut retenir

  • Trois registres ccTLD (.gh, .sl, .as) ont été compromis, permettant de forger des certificats TLS valides pour des domaines de Google et d'autres grandes organisations.
  • La Certificate Transparency a permis la détection rapide ; Chrome a révoqué les certificats frauduleux via CRLSets en moins de 48 heures.
  • Tout propriétaire de domaine devrait publier immédiatement des enregistrements CAA restrictifs pour limiter l'impact d'une éventuelle compromission de son registre DNS.

Un enregistrement CAA suffit-il à se protéger contre ce type d'attaque ?

L'enregistrement CAA est une protection importante mais partielle. Il empêche les CA qui respectent les standards de valider une demande frauduleuse, mais n'empêche pas la compromission DNS elle-même. Pour une protection complète, combinez CAA avec DNSSEC (qui signe cryptographiquement les enregistrements DNS), la surveillance des journaux Certificate Transparency pour vos domaines, et une gestion stricte des accès aux interfaces d'administration de vos DNS.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact