El secuestro de DNS permitió emitir certificados no autorizados para Google y YouTube en tres ccTLD

Atacantes alteraron DNS autoritativo en ccTLD afectados y obtuvieron certificados no autorizados para Google y YouTube, sin uso confirmado contra usuarios.

El secuestro de DNS permitió emitir certificados no autorizados para Google y YouTube en tres ccTLD
Vulnerabilidades

Imagen ilustrativa generada con IA

Los atacantes comprometieron a operadores externos vinculados a los dominios de nivel superior geográficos .gh, .sl y .as, modificaron registros DNS autoritativos y obtuvieron certificados HTTPS no autorizados para dominios de Google y YouTube.

Google afirmó que el incidente no implicó una brecha en sus sistemas. También señaló que no tenía motivos para creer que las autoridades de certificación que emitieron los certificados hubieran actuado de forma indebida.

No se indicó la fecha de los secuestros. Google tuvo conocimiento de la actividad durante la semana anterior a su publicación del 6 de octubre y afirmó que respondió de inmediato. La noticia se publicó el 7 de octubre de 2026.

Un análisis de Certificate Transparency realizado por The Hacker News encontró al menos 12 certificados con validación de dominio que cubrían siete dominios de Google y YouTube. Los certificados aparecieron por primera vez en registros públicos el 22, el 25 y el 27 de septiembre.

Las pruebas disponibles confirman que se emitieron certificados sin autorización, pero no que se usaran para atacar a los usuarios. Ni Google ni el análisis de los certificados confirmaron que los atacantes los utilizaran para suplantar un sitio web, interceptar tráfico o recopilar información.

Los cambios en el DNS autoritativo precedieron a la emisión de los certificados

Las autoridades de certificación emiten certificados con validación de dominio después de comprobar que el solicitante controla el dominio en cuestión. La validación mediante DNS es uno de los métodos posibles, pero la información publicada no permite determinar con exactitud cómo se realizaron las comprobaciones en este incidente.

Lo que sí está confirmado es que, tras comprometer a operadores externos vinculados a los tres ccTLD, los atacantes modificaron registros DNS autoritativos. Los cambios dirigieron los dominios afectados a infraestructura bajo el control de los atacantes y, posteriormente, se emitieron certificados no autorizados para dominios de Google y YouTube.

Un certificado válido podría permitir que un destino controlado por un atacante estableciera una conexión cifrada para el dominio cubierto sin mostrar el aviso de discrepancia del certificado que normalmente verían los usuarios. El operador podría entonces servir cualquier contenido, incluso una imitación convincente del sitio legítimo.

Ese es el impacto potencial, no un resultado confirmado. Las fuentes no indican que se desplegara ningún certificado para suplantar a Google o YouTube, ni que se expusieran datos privados.

Google no identificó a los atacantes ni explicó cómo comprometieron a los operadores externos. Tampoco indicó si se habían protegido los dominios afectados.

El riesgo no se limitaba necesariamente a Google. Según la empresa, los datos de Certificate Transparency revelaron certificados que parecían estar relacionados con los mismos ataques y que afectaban a organizaciones que se creía que habían sido comprometidas, entre ellas grandes marcas internacionales y servicios en línea de uso extendido. Google no las identificó.

Esta afirmación no significa que se vieran comprometidos todos los dominios bajo .gh, .sl o .as.

Los registros públicos revelaron al menos 12 certificados

El 7 de octubre, The Hacker News buscó información en ctlogs.dev y Cert Spotter. Su análisis, de alcance limitado, identificó 12 certificados para youtube.com.gh, google.com.gh, google.sl, google.com.sl, youtube.sl, google.as y youtube.as, incluidas entradas comodín y con www.

Let’s Encrypt emitió 11 certificados y ZeroSSL, uno. Matthew McPherrin, miembro del equipo de Let’s Encrypt, confirmó el 7 de octubre en el foro de la comunidad de la autoridad de certificación que se habían emitido y revocado certificados para Google y YouTube.

Nombres incluidos en el certificado Emisor Primer registro Revocado
*.youtube.com.gh, youtube.com.gh Let’s Encrypt 22 de septiembre, 11:03 26 de septiembre, 02:41
*.google.com.gh, google.com.gh Let’s Encrypt 22 de septiembre, 11:59 26 de septiembre, 02:41
*.google.sl, google.sl Let’s Encrypt 25 de septiembre, 04:36 1 de octubre, 19:36
google.sl, www.google.sl Let’s Encrypt 25 de septiembre, 04:36 1 de octubre, 19:36
google.com.sl, www.google.com.sl ZeroSSL 25 de septiembre, 04:51 26 de septiembre, 14:56
*.google.com.sl, google.com.sl Let’s Encrypt 25 de septiembre, 04:51 1 de octubre, 19:36
www.youtube.sl, youtube.sl Let’s Encrypt 25 de septiembre, 06:06 1 de octubre, 19:36
*.youtube.sl, youtube.sl Let’s Encrypt 25 de septiembre, 06:07 1 de octubre, 19:36
google.as, www.google.as Let’s Encrypt 27 de septiembre, 03:33 1 de octubre, 19:18
*.google.as, google.as Let’s Encrypt 27 de septiembre, 03:43 1 de octubre, 19:18
google.as, www.google.as Let’s Encrypt 27 de septiembre, 04:17 1 de octubre, 19:18
*.youtube.as, youtube.as Let’s Encrypt 27 de septiembre, 04:37 1 de octubre, 19:18

No se indicó la zona horaria de esas marcas de tiempo. El 7 de octubre, Cert Spotter mostraba los 12 certificados como revocados.

Los registros analizados se remontaban al menos al 10 de septiembre. En el caso de google.com.gh, google.sl y google.as, todos los demás certificados encontrados en esos registros habían sido emitidos por Google Trust Services, la autoridad de certificación de Google.

La búsqueda abarcó solo una selección limitada de dominios de Google y YouTube. Por tanto, la cifra de 12 corresponde a los certificados encontrados en ese análisis, no al alcance total del incidente.

Google recurrió al sistema de bloqueo de emergencia de Chrome

Google afirmó que bloqueó los certificados no autorizados en sus propiedades mediante CRLSets, el mecanismo de Chrome que permite rechazar rápidamente certificados revocados o no confiables seleccionados. También colaboró con las autoridades emisoras para revocarlos, ampliando así la respuesta a otros navegadores y aplicaciones que procesan la información de revocación pertinente.

Tras analizar los registros de Certificate Transparency, Google bloqueó otros certificados que parecían estar relacionados con los ataques. Cuando fue posible, se puso en contacto con las organizaciones que se creía que habían sido afectadas.

Google indicó que los usuarios de Chrome no tenían que hacer nada. Sin embargo, advirtió que su análisis podría no haber identificado todos los dominios afectados y que las medidas de Chrome no protegen de forma fiable a quienes usan otros navegadores.

Las revocaciones limitan la utilidad de los certificados en los clientes que reciben y aplican el estado actualizado. No permiten determinar si se utilizó algún certificado antes de su revocación.

No se informó de cuántos usuarios resultaron afectados ni se confirmó un total de víctimas.

Las huellas digitales de los certificados pueden ayudar en las búsquedas defensivas

Los equipos de seguridad pueden utilizar las siguientes huellas SHA-256 para localizar los 12 certificados mencionados en servicios de Certificate Transparency, inventarios de certificados o telemetría pertinente. El orden coincide con el de la tabla anterior.

0357032e1214ae11d7da8e00f6b89fb7694e240b17d05f2f47feaf43e96aa7d8
8886ca2b71501a6729f1ae868bd7d7b9b53c5cb6b5c7d851d041db4d6206945d
986d36b1c68c3e800596c4680dd6c67c42118955e08b472f641793c59dcd347b
2e1f6d7f24650b0720636efe48f2ccf59704ee6f11ffa52b5a4c4afcc474fe91
e1667fe4e4ea98427960ea2eda7c53af1246ec58ac22282a6877d394a0957065
e1e4fd74f673f1df9c039ae6424b36868a0475a043abea2dedd1f6f12a365ebf
5b7c491c8784eb438b1634981f1ea6333d3557431268233c2a7a92173ca17122
a10d3b5dbc142d040e6ae772ab41dc44b0e94659237709d1241fdefdd36f7b35
491f453d208bbb7923626c208df93c95fdfae3b78b738b996c8dafda9d00619a
798079c762496d26ce99d3a9113cb24715e31ec8a69a6cdcffa70f5001e19df0
607afd2745b84c4332e028262937be35f25316aadf584340269d23a3dbcd37ef
b7ea8c77695cf9791a9d45f17c33ebb9bd5f68d4c96df6f56136dc6a834576d2

Una coincidencia identifica uno de los certificados incluidos en el análisis. No demuestra que un usuario se conectara a un sitio de suplantación ni que se interceptara información.

Los propietarios de dominios deberían revisar los nombres regionales y aparcados

Google recomendó supervisar los registros de Certificate Transparency para carteras de dominios completas, incluidos los dominios aparcados y los registros regionales de ccTLD. Los propietarios de dominios bajo .gh, .sl o .as deberían revisar las entradas recientes en busca de certificados que no hayan solicitado.

Un certificado no solicitado puede notificarse a la autoridad de certificación emisora mediante un «Certificate Problem Report». Según los requisitos de referencia de las autoridades de certificación, la entidad debe investigar el caso y proporcionar resultados preliminares en un plazo de 24 horas.

Google también recomendó configurar registros CAA restrictivos. CAA puede limitar la emisión a autoridades de certificación aprobadas y, cuando se admita, a cuentas ACME y métodos de validación autorizados.

CAA no puede impedir la emisión durante un secuestro activo del DNS autoritativo si el atacante puede eliminar o falsificar el registro. Su protección resulta pertinente una vez restablecido el control legítimo del DNS, ya que una autoridad de certificación puede reutilizar una validación de dominio anterior que haya sido satisfactoria para solicitudes posteriores.

Google afirmó que una política CAA estricta puede impedir que se emitan más certificados mediante esa validación almacenada en caché. El 7 de octubre, Google Public DNS devolvía registros CAA para los siete dominios identificados que solo autorizaban a pki.goog, el dominio de Google Trust Services. La información publicada no permite determinar cuándo se añadieron esos registros.

El periodo máximo de reutilización de la validación sigue siendo de 200 días, según el calendario aprobado por el CA/Browser Forum en abril de 2025. Se reducirá a 100 días en marzo de 2027 y a 10 días en marzo de 2029. En diciembre de 2025, Let’s Encrypt afirmó que reutilizaba una comprobación de dominio durante 30 días y que tenía previsto reducir ese periodo a 7 horas para 2028.

Lee también

Fuentes

Este artículo es una reelaboración original basada en las siguientes fuentes.

Volver al inicio

Últimas noticias de ciberseguridad

Todas las noticias de ciberseguridad →