Principales destacados
- Tres dominios fueron comprometidos: los atacantes tomaron el control de zonas DNS vinculadas a .gh, .sl y .as y consiguieron obtener certificados TLS no autorizados.
- Chrome ya bloquea los certificados: Google actualizó el navegador y trabajó con las autoridades de certificación para revocar los certificados emitidos para sus dominios.
- El problema fue el DNS, no el cifrado: los atacantes explotaron el control de los registros para superar las validaciones automáticas de dominio, sin necesidad de acceder a la infraestructura de las empresas afectadas.
Un certificado de seguridad debería funcionar como un documento digital capaz de demostrar que realmente estás hablando con el sitio web que crees estar visitando.
Pero esta semana, unos hackers encontraron una manera de conseguir documentos falsos.
Google afirmó el martes 6 de octubre que los atacantes tomaron el control de tres dominios de nivel superior correspondientes a códigos de país y utilizaron ese acceso para obtener certificados TLS no autorizados para varios dominios de la compañía, además de otras grandes marcas y servicios online.
Los dominios involucrados son .gh, de Ghana; .sl, de Sierra Leona; y .as, de Samoa Americana.
El ataque comenzó donde casi nadie mira 🔎
El punto central de la historia está en el DNS.
Según el informe de Ars Technica, los atacantes modificaron registros DNS autoritativos de dominios seleccionados dentro de los tres registros comprometidos. Con ello, consiguieron controlar temporalmente la información que indicaba hacia dónde debían apuntar determinados dominios.
Y eso fue suficiente para engañar a un mecanismo fundamental de seguridad de Internet.
🎯 La vulnerabilidad estaba en la validación: las autoridades de certificación comprueban si quien solicita un certificado puede controlar un determinado dominio. Al tomar el control del DNS, los atacantes pudieron responder a los desafíos utilizados durante esa validación.
En la práctica, no tuvieron que entrar en los servidores de Google.
Solo necesitaban conseguir que Internet creyera, durante un tiempo, que tenían el control de los dominios necesarios.
El certificado no estaba «roto» 🛡️
Un certificado TLS vincula criptográficamente un nombre de dominio con una clave pública.
Es una de las piezas que permiten al navegador establecer una conexión HTTPS y verificar la identidad del sitio.
El problema es que la validación de dominio tiene una limitación importante: demuestra que alguien controla el dominio en el momento en que se realiza la verificación.
Por sí sola, no puede determinar si esa persona u organización debería estar controlando el dominio.
Fue precisamente esa diferencia la que aprovecharon los atacantes.
💡 No fue necesario romper el cifrado. Bastó con controlar el camino utilizado para demostrar que el dominio estaba bajo control legítimo.
Google dice que sus servidores no fueron vulnerados
Google afirmó que la infraestructura de los propietarios de los dominios afectados no fue comprometida.
Según la compañía, las autoridades de certificación también siguieron los procedimientos previstos para validar el dominio antes de emitir los certificados.
El problema estaba en una etapa anterior: quien controlaba los registros DNS tenía la capacidad de responder correctamente a las verificaciones.
Con el control de las zonas, los atacantes podían modificar direcciones IP e incluso las delegaciones de servidores de nombres.
Esto les permitía redirigir el tráfico y responder a los desafíos utilizados por las autoridades de certificación.
¿Y qué ocurre cuando existe un certificado falso? ⚠️
Desde el punto de vista criptográfico, un certificado TLS no autorizado puede permitir que su poseedor se presente como el dominio legítimo.
Precisamente por eso, los certificados emitidos de manera incorrecta se consideran un problema grave.
Google no reveló cuáles de sus dominios fueron afectados. Tampoco informó qué otras organizaciones estaban involucradas ni cuántos certificados fueron emitidos.
La compañía, sin embargo, afirmó que ya había tomado medidas para bloquear los certificados identificados.
Chrome recibió una barrera adicional 🚧
Google actualizó Chrome para bloquear todos los certificados no autorizados que pudo identificar.
La compañía también trabajó con las autoridades de certificación responsables de las emisiones para que los certificados de sus propiedades fueran revocados.
Para los usuarios de Chrome, la orientación es sencilla: no es necesario hacer nada.
La protección ya fue implementada en el navegador.
Pero Google dejó un mensaje para los propietarios de sitios web
La compañía advirtió que el bloqueo realizado por Chrome no debería considerarse una solución completa para los propietarios de dominios.
🔐 La recomendación es preventiva: las empresas deberían supervisar los registros de transparencia de certificados para identificar emisiones inesperadas y configurar registros DNS de Autorización de Autoridades de Certificación, conocidos como CAA.
Estos registros permiten especificar qué autoridades de certificación están autorizadas a emitir certificados para un determinado dominio.
En la práctica, se trata de una capa adicional de seguridad.
Si alguien consigue tomar temporalmente el control del DNS, todavía habrá una barrera más para impedir que una autoridad de certificación autorizada sea utilizada de manera indebida.
No es la primera vez que ocurre
El episodio también llama la atención porque los ataques que involucran secuestro de dominios y certificados fraudulentos no son precisamente nuevos.
Según el material proporcionado, un certificado de Let’s Encrypt llegó a emitirse para google.tg a principios de 2026, después de que el registro .tg, de Togo, fuera comprometido.
También existe un precedente mucho más antiguo y conocido.
En 2011, unos atacantes que vulneraron la autoridad de certificación neerlandesa DigiNotar consiguieron obtener un certificado wildcard para google.com. Posteriormente, el certificado fue utilizado contra internautas en Irán.
La historia muestra una característica incómoda de la arquitectura de seguridad de Internet: una cadena de confianza puede ser bastante sólida y, aun así, depender de puntos administrativos mucho menos protegidos.
El fantasma de Sea Turtle 🐢
Los investigadores de amenazas de Google también han seguido una campaña conocida como Sea Turtle, que utilizó credenciales robadas para secuestrar dominios en diferentes registros de ccTLD y posteriormente obtener certificados para esos dominios.
La lógica es similar.
En lugar de intentar romper directamente los protocolos criptográficos, el atacante busca una parte más vulnerable de la infraestructura que sustenta la identidad digital.
Es una estrategia que sustituye la fuerza bruta por la ingeniería de la confianza.
El problema es mayor que un certificado falso
El episodio plantea una cuestión importante para la infraestructura global de Internet.
La emisión de un certificado TLS depende de una cadena de validaciones. Si una de esas etapas cree que un atacante es el responsable legítimo de un dominio, todo el resto del proceso puede funcionar perfectamente y, aun así, producir un resultado incorrecto.
🌐 La ironía es esta: la autoridad de certificación puede cumplir correctamente sus reglas, el navegador puede verificar correctamente el certificado y el cifrado puede permanecer intacto. Aun así, la identidad presentada al usuario puede ser incorrecta.
Esto ayuda a explicar por qué los registros DNS, los operadores de ccTLD y las autoridades de certificación son componentes tan importantes de la seguridad de la web.
Y también por qué un problema en un dominio nacional relativamente pequeño puede terminar afectando a servicios utilizados a escala global.
Internet sigue dependiendo del eslabón más débil
El caso relacionado con .gh, .sl y .as demuestra que la seguridad de Internet no depende únicamente de algoritmos criptográficos sofisticados.
También depende de quién administra registros, credenciales, DNS y procesos de validación.
No fue necesario encontrar una vulnerabilidad zero-day en OpenSSL. Tampoco fue necesario romper el cifrado de TLS.
Fue suficiente con conseguir modificar los registros que indicaban quién estaba al mando.
Y cuando un simple registro DNS puede ayudar a alguien a obtener las credenciales digitales de una gran empresa, queda claro que la batalla por la seguridad de la web comienza mucho antes de que el navegador muestre el candado en la barra de direcciones.
