Des attaquants ont modifié les DNS faisant autorité de trois extensions nationales et en ont profité pour obtenir de vrais certificats HTTPS au nom de Google, de YouTube et d’autres organisations. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : déroulé connu, correspondance avec MITRE ATT&CK, rôle des journaux Certificate Transparency dans la détection, questions d’audit ISO 27001 et pistes de sensibilisation. Les détails techniques publics sont limités : le point d’entrée chez le registre et l’usage réel des certificats ne sont pas documentés, et nous le signalons à chaque fois.
Pour une lecture orientée dirigeant, voir notre décryptage « Faux certificats Google : quand les pirates attaquent les registres de noms de domaine ».
Contexte
- Victimes : les opérateurs des extensions nationales .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines) ; par ricochet, Google et YouTube, ainsi que d’autres organisations non nommées (« plusieurs grandes marques mondiales et services en ligne très utilisés », selon Google cité par BleepingComputer).
- Dates : certificats inscrits dans les journaux Certificate Transparency le 22 septembre (.gh), le 25 septembre (.sl) et le 27 septembre (.as) ; révocations entre le 26 septembre et le 1er octobre ; annonce de Google le 6 octobre 2026 (The Hacker News).
- Type : détournement DNS en amont (registre ou opérateur tiers), puis obtention frauduleuse de certificats.
- Attaquant : non identifié. Information non confirmée à ce stade.
- Point de vocabulaire sur la cible exacte : The Hacker News parle de « registres compromis » ; BleepingComputer parle de « compromission d’opérateurs tiers » (BleepingComputer). Les deux s’accordent sur la modification des DNS faisant autorité.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| 1. Prise de contrôle de l’infrastructure DNS | Compromission du registre ou d’un opérateur tiers ; modification des enregistrements DNS faisant autorité pour des domaines sous .gh, .sl et .as. Méthode inconnue. | T1584.002 Compromise Infrastructure: DNS Server ; T1584.001 Compromise Infrastructure: Domains |
| 2. Validation auprès des autorités de certification | Comme il contrôle le DNS, l’attaquant répond aux défis de validation de domaine (par exemple un enregistrement DNS TXT). Il obtient des certificats DV, y compris des certificats « joker » (du type *.google.sl). |
T1588.004 Obtain Capabilities: Digital Certificates |
| 3. Enchaînement par extension | Une extension à la fois : .gh, puis .sl, puis .as. Le premier certificat .as est apparu environ un jour après la révocation des certificats .gh : l’attaquant a continué malgré la première réaction. | – |
| 4. Usage des certificats | Non documenté. Google ne dit pas si les certificats ont servi à usurper un site ou à intercepter des données. Le risque théorique est une interception (homme du milieu) ou un faux site en HTTPS. | T1557 Adversary-in-the-Middle (potentiel, non confirmé) |
La colonne MITRE est une lecture de notre part, à partir des éléments publiés. Aucune exfiltration ni aucun chiffrement ne sont documentés. Il ne s’agit pas d’une attaque contre le système d’information de Google : c’est une attaque contre la confiance, celle qu’on accorde au DNS et aux certificats.
Ce que ça change concrètement
- L’enregistrement CAA ne protège pas pendant le détournement. En revanche, il empêche la réutilisation d’une validation déjà acquise une fois le DNS récupéré. Cette réutilisation est autorisée aujourd’hui jusqu’à 200 jours, puis 100 jours en mars 2027 et 10 jours en mars 2029, selon le calendrier du CA/Browser Forum cité par The Hacker News.
- Notre lecture, non issue des sources : DNSSEC n’aurait probablement pas aidé si c’est le registre lui-même qui est compromis, puisque c’est lui qui signe la zone. De même, un « verrou registre » (registry lock) posé chez son bureau d’enregistrement ne protège pas contre une compromission du registre. La surveillance Certificate Transparency reste donc la mesure la plus réaliste pour une organisation cliente.
Ce qu’on ne sait pas
Le point d’entrée précis chez le registre ou l’opérateur (compte d’administration, prestataire technique, faille logicielle), l’identité de l’attaquant, l’usage réel des certificats obtenus et la liste complète des organisations touchées. Nous ne spéculons pas sur ces points.
Détection : ce sont les journaux Certificate Transparency qui ont parlé
- Ce qui a permis de voir l’attaque : les journaux Certificate Transparency (CT). Tout certificat reconnu par les navigateurs doit y être inscrit publiquement. C’est par ce biais que The Hacker News a retrouvé les 12 certificats, et que Google a identifié d’autres organisations touchées. Google dit avoir été informé « la semaine précédant » son billet du 6 octobre, sans préciser par qui ni comment.
- Délais observés : entre l’inscription d’un certificat et sa révocation, d’environ 1,5 jour à près d’une semaine (The Hacker News).
- Pourquoi l’attaque peut passer inaperçue : le propriétaire du domaine n’a rien changé chez lui, ses serveurs ne voient rien, et l’autorité de certification a appliqué correctement sa procédure. Sans surveillance CT, la seule trace visible est un certificat valide de plus.
- Limites rappelées par Google : le blocage dans Chrome (CRLSets) ne protège pas les autres navigateurs, et l’analyse n’a peut-être pas trouvé tous les domaines touchés.
Questions d’audit ISO 27001:2022
- A.5.9, A.8.20 et A.8.21 (inventaire, sécurité des réseaux et des services réseau) : « Montrez-moi l’inventaire de vos noms de domaine, y compris les domaines parkés, les déclinaisons pays et les domaines de marque défensifs. Pour chacun : qui est le bureau d’enregistrement, qui héberge le DNS, et qui est responsable en interne ? »
- A.8.16 et A.5.7 (surveillance, renseignement sur les menaces) : « Surveillez-vous l’émission de certificats à votre nom dans les journaux Certificate Transparency ? Qui reçoit l’alerte, et quelle est la procédure si un certificat non demandé apparaît ? Montrez-moi la dernière alerte traitée. »
- A.8.24 (utilisation de la cryptographie) : « Vos domaines publient-ils un enregistrement CAA ? Est-il limité aux autorités que vous utilisez réellement (et, si possible, à votre compte ACME) ? Qui l’a validé, et quand a-t-il été revu ? »
- A.5.19 à A.5.22 (relations avec les fournisseurs) : « Le bureau d’enregistrement et l’hébergeur DNS figurent-ils dans votre liste de fournisseurs critiques ? Avez-vous évalué leur sécurité (MFA sur le compte, verrouillage des transferts, procédure de notification d’incident) ? »
Pistes de sensibilisation
- Pour tous : casser l’idée « cadenas = site de confiance ». Le cadenas dit seulement que la connexion est chiffrée vers quelqu’un qui a prouvé contrôler le DNS. Exemple concret à montrer : un vrai certificat google.sl émis au profit d’un attaquant.
- Pour les équipes IT et web : atelier pratique de 30 minutes. On recherche ses propres domaines dans un service de recherche Certificate Transparency (Cert Spotter, crt.sh ou équivalent), on repère les certificats inconnus, puis on vérifie la présence d’un enregistrement CAA. On découvre souvent des certificats émis par d’anciens prestataires ou pour des domaines oubliés.
À lire aussi : notre décryptage pour les dirigeants, « Faux certificats Google : quand les pirates attaquent les registres de noms de domaine », et le bulletin de veille du 8 octobre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.