Ataques a registros ccTLD obtienen certificados TLS válidos para Google

Compromisos confirmados en los registros de .gh, .sl y .as permitieron emitir certificados HTTPS legítimos mediante DNS falsificado. La misma exposición estructural aplica a cualquier ccTLD, incluido el .cl que usa buena parte de la web chilena.

Qué pasó

Este análisis parte de una nota de investigación de Cloud Security Alliance (CSA Labs), publicada el 8 de octubre de 2026, que a su vez sintetiza el aviso que Chrome Security publicó el 6 de octubre y la cobertura posterior de The Hacker News, Help Net Security y The Register. CSA Labs no es fuente primaria: es un equipo de investigación que correlaciona reportes de terceros, así que cada dato de este resumen se atribuye a quien lo originó.

Según Google, atacantes comprometieron a los operadores de los registros de .gh, .sl y .as —no a Google ni a las autoridades certificadoras— y alteraron las respuestas DNS autoritativas para dominios bajo esos ccTLD. Con control sobre esas respuestas, lograron superar la validación de control de dominio (DCV) que exige cualquier CA antes de emitir un certificado, y obtuvieron certificados para nombres como google.com.gh, google.sl y google.as. Logs de Certificate Transparency muestran al menos 12 certificados fraudulentos: once emitidos por Let's Encrypt y uno por ZeroSSL, según confirmó un representante de Let's Encrypt a la prensa especializada.

Las fechas importan porque muestran que la revocación siempre llegó después: los certificados de .gh y el de ZeroSSL se revocaron el 26 de septiembre, y los de .sl y .as recién el 1 de octubre — es decir, ninguna revocación fue anterior al compromiso del registro correspondiente. La divulgación pública fue el 6 de octubre.

Google fue explícito en un punto poco habitual para un fabricante: dijo que la intervención del navegador "no debe ser el mecanismo en que confíen" para protegerse, y que no puede garantizar haber identificado todos los dominios afectados. También indicó que los datos de CT apuntan a otras marcas y servicios ampliamente usados que no nombró. No hay evidencia pública de que los certificados fraudulentos se hayan usado efectivamente para interceptar tráfico; lo que está confirmado es la emisión, no el uso.

Por qué importa acá

Separemos dato de evaluación, porque aquí es fácil mezclarlos.

Dato: no existe ningún reporte, de CSA ni de la prensa citada, que indique que NIC Chile o el registro .cl hayan sido comprometidos. No hay IOC, no hay certificado fraudulento reportado bajo .cl.

Evaluación (confianza alta): el patrón expuesto —un registro ccTLD comprometido permite a un atacante superar la DCV y obtener certificados válidos para cualquier dominio bajo esa zona, sin que la CA cometa ningún error— es estructural, no específico de Ghana, Sierra Leona o Samoa Americana. El .cl es, en lo técnico, el mismo tipo de pieza: un registro nacional que publica la delegación DNS de todo lo que termina en .cl. Si ese registro fuera comprometido, el resultado sería idéntico al descrito en la nota, independiente de cuán bien configurada esté la seguridad de cada organización chilena individual.

Lo que no sabemos: si NIC Chile tiene registry-lock habilitado, qué controles de autenticación rigen el acceso administrativo a su infraestructura, o si opera DNSSEC con custodia de claves separada del resto de la operación. Son preguntas razonables de hacer al registro o de documentar como riesgo aceptado, no afirmaciones que podamos hacer con la información disponible.

Para una organización chilena, el punto accionable no es '¿están atacando el .cl?' sino 'si alguien emitiera hoy un certificado fraudulento para mi dominio .cl, ¿me entero antes que un cliente o antes que la prensa?'. La respuesta de Google es que el navegador no te va a avisar de forma confiable; el monitoreo de Certificate Transparency sobre los propios dominios es, hoy, la única señal temprana que no depende de terceros.

Sobre marco regulatorio: si una entidad calificada como Operador de Importancia Vital bajo la Ley 21.663 detectara un certificado no autorizado emitido para uno de sus dominios de producción, eso constituye un incidente de ciberseguridad potencialmente reportable a ANCI — no confirmamos plazos específicos porque la ley y su reglamento los definen caso a caso y no los vamos a citar sin verificarlos contra el texto vigente. Y si ese certificado fraudulento llegó a interceptar tráfico con datos personales, entra también el deber de notificación de la Ley 21.719 ante una posible vulneración de seguridad de datos personales. Ninguna de las dos aplica hoy porque no hay incidente confirmado en Chile; ambas aplicarían el día en que lo hubiera.

Además hay una exposición indirecta: cualquier organización chilena que dependa de un proveedor SaaS, acortador de enlaces o portal regional que use un ccTLD de terceros país hereda ese riesgo sin haber cambiado nada en su propia configuración. Vale la pena preguntarle a esos proveedores cómo monitorean CT y cómo protegen su cuenta de registrador.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

• T1588.004 — El atacante no robó un certificado existente: usó el control sobre las respuestas DNS autoritativas del registro para superar legítimamente la validación de control de dominio y que una CA pública le emitiera un certificado válido a su nombre de interés.
• T1584.002 — El compromiso del operador del registro ccTLD —no del dominio objetivo ni del resolver del usuario— es lo que le dio al atacante autoridad sobre las respuestas DNS para toda la zona, incluidos los dominios de Google y de otras organizaciones no identificadas.

google[.]com[.]gh
google[.]sl
google[.]as

title: Emisión de certificado no autorizado para dominio propio (CT monitor)
id: a3f1e6d2-8c4b-4f1a-9e3d-726b5a1c9f04
status: experimental
description: Detecta eventos de un poller de Certificate Transparency donde se registra un certificado para un dominio propio emitido por una CA fuera de la lista aprobada o en discrepancia con el registro CAA vigente.
references:
  - https://labs.cloudsecurityalliance.org/research/csa-research-note-cctld-registry-hijack-certificate-trust-20/
logsource:
  category: application
  product: ct_monitor
detection:
  selection:
    EventType: 'certificate_logged'
    OwnedDomain: true
  filter_approved:
    IssuerCA|in:
      - 'approved_ca_list'
  condition: selection and not filter_approved
fields:
  - Domain
  - IssuerCA
  - SerialNumber
  - LoggedAt
falsepositives:
  - CA recién incorporada que aún no está en la lista de emisores aprobados
  - Certificados internos de prueba emitidos por error bajo un subdominio productivo
  - Migración de proveedor de certificados sin actualizar la lista de CA aprobadas
level: high

CTMonitorAlerts_CL
| where OwnedDomain_b == true
| where IssuerCA_s !in ("LetsEncrypt-Aprobada", "DigiCert-Aprobada", "Sectigo-Aprobada")
| project TimeGenerated, Domain_s, IssuerCA_s, SerialNumber_s
| order by TimeGenerated desc

index=ct_monitor OwnedDomain=true
| search NOT [| inputlookup approved_ca_list.csv | fields IssuerCA]
| table _time Domain IssuerCA SerialNumber

Fuentes

• Cloud Security Alliance (CSA Labs)Registries as the Weak Link: ccTLD Hijacks and Certificate Trust · 2026-10-08
• Google Chrome Security BlogChrome's Response to Recent ccTLD Registry Hijacks · 2026-10-06
• The Hacker NewsAttackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains · 2026-10-07
• Help Net SecurityHackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains · 2026-10-07
• The RegisterAttackers hijacked top-level domains, minted fake security certs for Google and other orgs · 2026-10-07
• CA/Browser ForumBallot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods · 2025-04-01
• Let's EncryptMulti-Perspective Validation Improves Domain Validation Security · 2020-02-19

Relacionado