Secuestro de los ccTLD .gh, .sl y .as: doce certificados válidos para Google y YouTube

Entre el 22 y el 27 de septiembre de 2026, Let's Encrypt y ZeroSSL emitieron al menos doce certificados TLS válidos para nombres de Google y YouTube que Google no había pedido. Los atacantes habían tomado el control de los operadores de tres dominios de país, .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana), y desde allí superaron la comprobación de control del dominio que precede a cada emisión.

Google lo comunicó el 6 de octubre en una nota de su equipo de seguridad web y de red de Chrome. Según la compañía, sus sistemas no fueron vulnerados y no tiene motivos para pensar que las autoridades emisoras actuaran mal. La nota no identifica a los autores ni explica cómo entraron, y advierte de que su análisis puede no haber localizado todos los dominios afectados.

Las empresas con dominios .es, .mx u otras extensiones de país dependen de un operador similar, al que pocas veces han evaluado y que no suele figurar en su inventario de proveedores.

¿Qué se sabe del secuestro de los ccTLD .gh, .sl y .as?

Según la nota que Google publicó el 6 de octubre, unos atacantes comprometieron a los operadores externos de los dominios de país (ccTLD) .gh, .sl y .as y modificaron registros DNS autoritativos. Con ese acceso obtuvieron certificados digitales para dominios de Google y de otras organizaciones. Chrome bloqueó los que pudo identificar mediante CRLSets, su mecanismo de bloqueo de urgencia, y Google trabajó con las autoridades emisoras para revocarlos.

Las fechas y las cifras proceden de The Hacker News, que buscó en los registros públicos de Certificate Transparency (CT) con ctlogs.dev y Cert Spotter. Localizó doce certificados para siete dominios, once de Let's Encrypt y uno de ZeroSSL. Personal de Let's Encrypt confirmó en el foro de su comunidad que se habían emitido certificados para Google y YouTube y que ya estaban revocados. The Hacker News reconstruye así la secuencia de anotaciones en CT:

• 22 de septiembre: aparecen dos certificados con comodín, uno para google.com.gh y otro para youtube.com.gh.
• 25 de septiembre: se anotan seis certificados para google.sl, google.com.sl y youtube.sl, cinco de Let's Encrypt y uno de ZeroSSL.
• 26 de septiembre: se revocan los dos de .gh y el de ZeroSSL.
• 27 de septiembre: se anotan cuatro certificados para google.as y youtube.as.
• 1 de octubre: se revocan los nueve restantes.
• 6 de octubre: Google publica su nota.

El primer certificado de .as se anotó un día después de que se revocaran los de .gh. El que menos duró estuvo vigente alrededor de un día y medio y el que más, casi una semana.

La búsqueda de The Hacker News se limitó a unos pocos nombres de Google y YouTube, de modo que doce es un mínimo. Google añade en su nota que entre los afectados hay varias marcas globales y servicios en línea de uso masivo, a los que no nombra. Chrome bloqueó también los certificados de esas organizaciones que pudo identificar, y Google avisó a sus titulares cuando le fue posible.

¿Cómo obtuvieron los atacantes certificados válidos para dominios de Google?

Los atacantes obtuvieron certificados para dominios de Google porque la validación de dominio solo comprueba que el solicitante controla el DNS o la web del dominio en el momento de pedirlo. La autoridad de certificación plantea un reto y el solicitante lo resuelve publicando un valor en el DNS o en el servidor web. ACME, el protocolo que automatiza la emisión, completa el intercambio en segundos y sin intervención humana.

El operador de un dominio de país decide a qué servidores de nombres se delega cada dominio que cuelga de su zona. Si un intruso altera esa delegación, las consultas sobre google.sl las contesta una infraestructura suya, y el reto de la autoridad de certificación también. La autoridad habría preguntado al DNS y habría recibido la respuesta que esperaba, sin indicio de que procediera de otro lugar.

Google no ha detallado qué registros se cambiaron ni durante cuánto tiempo, de modo que esta mecánica es una reconstrucción coherente con lo publicado y sin confirmar por la compañía. Ars Technica describe en los mismos términos la modificación de registros DNS y de delegaciones de servidores de nombres.

Con un certificado válido y el tráfico desviado, un atacante puede servir una copia de la web, o recibir el correo del dominio si además redirige los registros MX. El visitante vería el candado y la dirección correcta, sin señal visible de la suplantación.

¿Ha habido ataques anteriores contra registros de dominios de país?

En abril de 2019, ICS-Forth, la entidad que gestiona el dominio .gr, reconoció una intrusión que Cisco Talos vinculó a la campaña Sea Turtle. Talos documentó que los intrusos conservaron el acceso al menos cinco días después del comunicado. También detectó la redirección de dominios de tres entidades gubernamentales con dominios .gr, probablemente desde ese acceso, y el uso de certificados de un proveedor distinto del que tenía contratado la víctima.

Sea Turtle era una campaña de espionaje contra gobiernos atribuida a un grupo de amenaza persistente avanzada (APT), mientras que del caso de 2026 todavía se desconocen el autor y el objetivo.

¿Por qué CAA, DNSSEC y HSTS no frenaron la emisión?

CAA, DNSSEC y HSTS no frenaron las emisiones porque dependen de respuestas DNS que, durante el secuestro, servía el atacante desde el nivel superior. Lo mismo vale para la validación desde varios puntos de red.

¿Sirve el registro CAA cuando el atacante controla el DNS?

El registro CAA, que indica qué autoridades pueden emitir para un dominio, no sirve durante un secuestro porque se publica en el mismo DNS que controla el atacante. The Hacker News comprobó el 7 de octubre que los siete dominios tenían un CAA estricto que solo autorizaba a Google Trust Services. Se ignora si ese registro ya existía antes del ataque. Si existía, Let's Encrypt y ZeroSSL emitieron pese a él.

¿Protege DNSSEC si se compromete el registro del ccTLD?

DNSSEC no protege frente a un registro comprometido, porque el registro DS que ancla las claves de cada dominio delegado lo publica la zona del ccTLD. Quien controla esa zona puede sustituirlo o retirarlo. Desde el 15 de marzo de 2026, las autoridades públicas deben validar DNSSEC cuando está presente en las consultas de CAA y de control del dominio, según la votación SC-085v2 del CA/Browser Forum. Un atacante con acceso al registro tendría que cambiar o retirar el DS para superar esa validación. Las fuentes publicadas no aclaran si los dominios afectados usaban DNSSEC.

¿Detecta la validación multipunto un secuestro del registro?

La validación desde varios puntos de red no detecta un secuestro en el registro, porque la delegación falsa llega igual a todas las ubicaciones. Las autoridades públicas están obligadas a aplicarla desde 2025 (MPIC, por sus siglas en inglés). Está pensada para desvíos de rutas como el secuestro BGP que sirvió para distribuir actualizaciones troyanizadas de Virtualizor, en los que la respuesta cambia según el punto desde el que se pregunta.

¿Qué protección ofrecen HSTS y el bloqueo de Chrome?

HSTS obliga al navegador a exigir HTTPS con un certificado válido, y el del atacante lo es. El bloqueo por CRLSets protege a quien usa Chrome y solo frente a los certificados que Google ha identificado. La compañía reconoce que sus intervenciones no protegen de forma fiable a los usuarios de otros navegadores y pide a los titulares de dominios que no confíen la protección de sus usuarios al navegador.

Las aplicaciones móviles que publica la empresa pueden añadir la fijación de certificados (certificate pinning), que hace que la app rechace todo certificado distinto del esperado, aunque sea técnicamente válido.

¿Cómo se detecta un certificado TLS emitido sin autorización?

Un certificado emitido sin autorización se detecta vigilando Certificate Transparency, los registros públicos en los que las autoridades anotan cada certificado. Con esos datos localizó Google a los demás afectados y encontró The Hacker News los doce certificados. La primera recomendación de Google es dar de alta en un monitor de CT todos los dominios de la organización, incluidos los aparcados y las variantes regionales bajo extensiones de país.

El monitor debería generar una alerta inmediata en estos casos:

• Un certificado emitido por una autoridad con la que la organización no trabaja. Según The Hacker News, desde al menos el 10 de septiembre todos los demás certificados de google.com.gh, google.sl y google.as procedían de Google Trust Services.
• Emisiones con comodín para dominios que solo sirven una redirección.
• Varias emisiones en pocos minutos para el mismo nombre desde autoridades distintas, como ocurrió con google.com.sl.
• Todo certificado emitido para un dominio que no aloja servicio alguno.

Los cambios en la delegación son otra señal que CT no recoge. La empresa puede consultar de forma periódica, desde fuera de su red, los servidores de nombres y el registro DS que el dominio de país publica para cada uno de sus dominios. Una diferencia con los valores esperados puede adelantarse al certificado, aunque con poco margen si la emisión es automática. La comprobación cuesta poco, pero muchas empresas solo la aplican al dominio principal y dejan fuera los secundarios.

Los dominios secundarios también forman parte de la superficie de ataque, y un servicio de gestión de la superficie de ataque debe incluirlos. La guía para comprobar la seguridad de un dominio explica cómo revisar desde fuera su configuración pública.

Una vez detectado el certificado, hay que pedir su revocación a la autoridad que lo emitió. Los requisitos básicos del CA/Browser Forum, las reglas que rigen a las autoridades públicas, obligan a investigar un aviso de certificado problemático y a dar un primer informe en 24 horas. Tener localizado de antemano el canal de aviso de cada autoridad ahorra tiempo cuando el plan de respuesta a incidentes se activa por un certificado que la organización no pidió.

¿Qué debe revisar una empresa en su cartera de dominios?

El inventario de dominios debería recoger, para cada uno, el registrador, el operador del dominio de nivel superior y la autoridad de certificación autorizada. A partir de ese inventario se revisan el CAA, la vigilancia y la relación con cada operador.

¿De quién depende cada dominio de la cartera?

Es habitual que una empresa registre su marca bajo varias extensiones para adelantarse al typosquatting, el registro de variantes de la marca por terceros, y las deje aparcadas durante años. Cada extensión depende de un operador distinto, con recursos y prácticas muy desiguales.

Varias extensiones que se comercializan como genéricas, entre ellas .io, .ai, .co y .tv, son dominios de país según la IANA. Ningún dato publicado indica que estén afectadas por esta campaña, aunque las gestiona un operador designado para ese territorio o la empresa que este haya contratado, igual que en los tres casos de septiembre.

¿Cómo se vincula el registro CAA a una cuenta ACME con accounturi?

Vincular el registro CAA a una cuenta ACME es la segunda recomendación de Google, y su efecto se nota cuando el titular ya ha recuperado el DNS. Las autoridades pueden reutilizar una validación de dominio ya superada para emitir más certificados sin repetir el reto. Las reglas actuales lo permiten hasta 200 días. En Let's Encrypt, el perfil por defecto reutiliza la validación durante 30 días y los perfiles tlsserver y shortlived durante 7 horas, según su página de perfiles. Un atacante que validó durante el secuestro podría seguir pidiendo certificados cuando el DNS ha vuelto a manos de su titular.

El RFC 8657 define dos parámetros que cierran esa vía en las autoridades que los admiten. El parámetro accounturi limita la emisión a una cuenta ACME determinada, y validationmethods restringe el método de validación admitido. Como Let's Encrypt consulta el CAA antes de cada emisión, rechaza una cuenta que no figure en el registro aunque conserve una validación vigente. Un registro de este tipo tiene esta forma:

• example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890; validationmethods=dns-01"

Let's Encrypt documenta ambos parámetros. Hay que confirmar el soporte con cada autoridad antes de publicar el registro. El identificador de cuenta del ejemplo es ficticio.

¿Reducirán el riesgo los certificados de 47 días?

Los plazos más cortos aprobados por el CA/Browser Forum no habrían cambiado este caso, porque los certificados de septiembre duraron como mucho una semana. La votación SC-081, aprobada el 11 de abril de 2025, reduce la vigencia máxima a 200 días desde el 15 de marzo de 2026, a 100 días desde el 15 de marzo de 2027 y a 47 días desde el 15 de marzo de 2029. La reutilización de validaciones baja a 100 días en 2027 y a 10 días en 2029, según resume Let's Encrypt en la misma página de perfiles.

Los nuevos plazos acortan el tiempo durante el que una validación obtenida en un secuestro sirve para emitir más certificados. Google cita la reducción de la vigencia y de la reutilización de validaciones entre sus trabajos a largo plazo, a través de sus programas de raíces de Chrome.

¿Protege el bloqueo de registro frente a un registro comprometido?

El bloqueo de registro (registry lock) que ofrecen algunos operadores protege frente al compromiso del registrador o de la cuenta del cliente, pero no frente a un ataque contra el operador del registro. Incluir a registradores y operadores de extensiones en el análisis de riesgo de terceros sirve para decidir con datos qué dominios alojan servicios críticos y cuáles deben limitarse a redirigir.

En la Unión Europea, NIS2 incluye a los registros de nombres de dominio de primer nivel entre las entidades de infraestructura digital. Fuera de la Unión las obligaciones varían de un país a otro, de modo que quien elige una extensión queda sujeto al marco regulatorio de su operador, o a la falta de él.

¿Quién está detrás del ataque y qué se desconoce todavía?

Google no ha identificado a los autores del secuestro de .gh, .sl y .as ni ha explicado cómo se comprometieron los operadores. Tampoco ha detallado para qué se usaron los certificados, si es que se usaron. No consta si los tres registros han recuperado el control completo de sus zonas, cuántas organizaciones resultaron afectadas ni si algún certificado sirvió para interceptar tráfico de usuarios.

Google afirma que supo de los secuestros la semana anterior a su comunicado del 6 de octubre, sin precisar el día. Las primeras revocaciones llevan fecha del 26 de septiembre, y ninguna de las fuentes explica esa diferencia.

Google vigila Certificate Transparency de forma sistemática y dispone de su navegador para bloquear lo que detecta, y aun así hubo certificados a su nombre vigentes durante días. Las organizaciones que todavía no vigilan CT pueden empezar por dar de alta en un monitor los dominios que solo redirigen, que suelen quedar fuera de la vigilancia.

Fuentes y atribución: este artículo se basa en la comunicación pública de Google del 6 de octubre de 2026, en el análisis de registros de Certificate Transparency publicado por The Hacker News, en la confirmación de Let's Encrypt en su foro. También recoge la documentación del CA/Browser Forum y de Let's Encrypt. La información está actualizada a 8 de octubre de 2026. La mención de Let's Encrypt, ZeroSSL, Google o los operadores de los dominios .gh, .sl y .as no implica un fallo de seguridad en sus productos ni en sus procedimientos de emisión. No se ha atribuido el ataque a ningún grupo y los datos pueden cambiar.

Aviso: el registro CAA de ejemplo es orientativo. Un CAA mal definido puede impedir la renovación de certificados legítimos, por lo que debe probarse antes con cada autoridad de certificación y cada cuenta ACME en uso.