Hackean tres dominios de país para falsificar certificados TLS de Google

Un grupo de atacantes consiguió tomar el control de tres dominios de nivel superior con código de país —.gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana)— y utilizó ese acceso para obtener certificados TLS no autorizados para varios dominios de Google y de otras grandes marcas globales. La compañía lo confirmó el 6 de octubre de 2026, dejando claro que el incidente no implicó una brecha en sus propios sistemas: el fallo se produjo mucho más arriba en la cadena, en los registros de DNS sobre los que descansa toda la confianza de los certificados.

• El punto de entrada fue el DNS, no la criptografía: los atacantes comprometieron a los operadores de los ccTLD y modificaron los registros DNS autoritativos de dominios concretos para superar las validaciones automáticas de control de dominio.
• Los certificados eran legítimos a ojos del navegador: las autoridades de certificación los emitieron siguiendo sus procedimientos habituales, sin indicios de irregularidades, lo que convierte este caso en un problema de confianza estructural y no en un error puntual de una CA.
• La limpieza tiene límites reconocidos: Google bloqueó en Chrome los certificados identificados y coordinó su revocación, pero admitió que no puede garantizar haber detectado todos los dominios afectados.

Cómo se falsificaron los certificados sin romper ninguna CA

Los certificados x.509 funcionan mediante una firma digital que vincula un nombre de dominio, como google.com, a una clave pública. La clave pública es accesible para cualquiera; la privada solo la posee el operador del sitio. Cuando ambas encajan, el visitante sabe que habla con el sitio auténtico y no con un impostor. Tener un certificado no autorizado permite a un atacante suplantar criptográficamente la infraestructura afectada.

Para emitir un certificado, las autoridades de certificación comprueban automáticamente que quien lo solicita controla el dominio. Los atacantes no necesitaron vulnerar criptografía alguna: les bastó con controlar durante unos minutos los registros DNS autoritativos y responder así al desafío de validación. Al comprometer los registros de tres ccTLD, cualquier dominio terminado en esas extensiones quedó expuesto mientras duró el secuestro.

El patrón no es nuevo. En 2011, el incidente de DigiNotar produjo certificados fraudulentos para Google y más de 200 dominios adicionales, que se utilizaron contra cientos de miles de usuarios en Irán, y la matriz de la compañía acabó declarándose en bancarrota semanas después. Años más tarde se emitió un certificado de Let’s Encrypt para google.tg tras el compromiso del registro de Togo, aunque el anclaje de claves preconfigurado en Chrome evitó que los navegadores lo aceptaran. Investigadores de Cisco Talos también han documentado la campaña Sea Turtle, de presunto patrocinio estatal, que usaba credenciales robadas para entrar en paneles de administración de proveedores de DNS y emitir certificados para dominios secuestrados.

La respuesta de Chrome y sus límites

Google bloqueó los certificados no autorizados de sus propiedades mediante CRLSets, el mecanismo que Chrome descarga en segundo plano para distribuir de forma rápida información sobre certificados revocados, sin necesidad de actualizar el navegador completo. Además, trabajó con las autoridades emisoras para revocar esos certificados, lo que extiende la protección a otros clientes que respetan los datos de revocación.

Al revisar los registros de Certificate Transparency, la compañía amplió el bloqueo a certificados vinculados con otras organizaciones y contactó con las entidades afectadas siempre que le fue posible. No obstante, fue explícita sobre los límites de su actuación. Sobre los sistemas propios, la empresa señaló:

«Estos incidentes no implicaron un compromiso de los sistemas de Google. Debido a la naturaleza de los ataques, no tenemos razones para creer que las autoridades de certificación que emitieron los certificados afectados hicieran algo incorrecto».

Y sobre su alcance, añadió: «no podemos garantizar que nuestro análisis haya identificado todos los dominios afectados». La compañía también advirtió de que el bloqueo desde el navegador no protege de forma fiable a quienes usan otros navegadores, y recordó que los usuarios de Chrome no necesitan tomar ninguna medida para los certificados ya identificados.

Qué deben vigilar los propietarios de dominios

La recomendación de Google traslada parte de la carga a quien posee el dominio. La primera práctica es monitorizar de forma continua los registros de Certificate Transparency, un registro público y solo añadible en el que queda constancia de cada certificado de confianza pública emitido: una emisión inesperada puede revelar que un atacante ha superado la validación de control de dominio. La vigilancia debe abarcar todo el portafolio, incluidos dominios aparcados y propiedades regionales con extensión de país.

La segunda es publicar registros CAA restrictivos, con vinculaciones de cuenta y de método de validación cuando el estándar lo permita. Estos controles no impiden la emisión durante un secuestro de DNS activo, pero limitan emisiones adicionales una vez restaurado el control legítimo. Como medidas de fondo, la compañía apuesta por reducir la validez de los certificados y la reutilización de la validación de control de dominio a través del Chrome Root Program y del nuevo programa de raíces resistentes a la computación cuántica.

El episodio deja una conclusión incómoda: HTTPS confirma que la conexión está cifrada, no que cada capa intermedia de la cadena de confianza siga bajo control legítimo. El ecosistema de autoridades de certificación conoce esta debilidad desde hace más de quince años sin resolver la suposición de fondo, y arreglarla implica renunciar a la validación automática o construir una verificación capaz de resistir un registro comprometido. Mientras eso no llegue a escala, cada registro de dominio de nivel superior seguirá siendo un punto único de fallo para toda la seguridad de la web.