Secuestro de dominios .gh, .sl y .as: certificados de Google
Atacantes tomaron los registros .gh, .sl y .as y obtuvieron certificados válidos de Google. Qué implica este secuestro de dominios y cómo proteger el tuyo.
Basado en fuentes. Escrito a partir de los documentos, reportes y reseñas enlazados en el texto. The Ruling Desk no probó nada de esto en persona. Cómo trabajamos
Atacantes entraron a las empresas que administran tres dominios de código de país, .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana), y con ese acceso obtuvieron certificados HTTPS reales, aceptados por los navegadores, para varios dominios de Google y de otras marcas grandes. Google reveló este secuestro de dominios en los registros ccTLD el 6 de octubre de 2026, en una publicación de su equipo de seguridad de Chrome, y dice que Chrome ya bloquea esos certificados. La pregunta más grande es qué pasa con todos los demás: quienes usan otros navegadores y cualquiera que tenga un dominio.
Puntos clave
- La brecha fue en el registro, no en Google: Google dice que los atacantes comprometieron a los operadores externos de .gh, .sl y .as, lo que puso en riesgo cada dominio con esas terminaciones. Los sistemas de Google no fueron vulnerados.
- Los certificados eran técnicamente válidos: al cambiar los registros DNS autoritativos, los atacantes pudieron pasar las verificaciones de dominio que hacen las autoridades certificadoras (CA). Google dice que no tiene motivos para pensar que las CA hicieron algo mal.
- Quienes usan Chrome están cubiertos; los demás quizá no: Chrome bloquea los certificados con su lista CRLSets y las CA los revocaron, pero Google advierte que sus medidas no protegen de forma confiable a quienes no usan Chrome.
- Los dueños de dominios tienen dos tareas: vigilar los registros de Certificate Transparency de cada dominio que tengas y publicar registros CAA restrictivos que indiquen tu CA y tu cuenta.
Qué pasó en el secuestro de dominios de los registros ccTLD
Cada dominio que termina en un código de país depende de un registro que guarda sus registros DNS autoritativos, las respuestas en las que confía el resto de internet para saber a dónde apunta un dominio. Google dice que se enteró "la semana pasada" de secuestros en los espacios .gh, .sl y .as, en los que los atacantes modificaron esos registros. No ha dicho cómo se comprometieron los registros ni quién está detrás.
Controlar el DNS basta para obtener un certificado. La mayoría de las CA emite un certificado validado por dominio a quien demuestre que controla el dominio, por lo general respondiendo a un reto por DNS o por web. Con los registros reescritos, los atacantes pudieron pasar esa verificación y obtener certificados de Google para nombres bajo esas terminaciones. Un miembro del equipo de Let's Encrypt confirmó en el foro de la comunidad de esa CA el 7 de octubre que "se emitieron certificados para Google y YouTube, y ya fueron revocados".
Google no publicó una cifra. iTnews informa, con base en datos públicos de Certificate Transparency, que el registro .gh fue comprometido el 22 de septiembre, .sl el 25 de septiembre y .as el 27 de septiembre (UTC), y que encontró 32 certificados emitidos a los atacantes entre el 22 y el 27 de septiembre. iTnews dice que contactó a los tres operadores de los registros y no recibió respuesta.
Quién sigue expuesto
Google dice que bloqueó en Chrome los certificados de sus propios servicios mediante CRLSets, una lista de certificados revocados que Chrome envía a los navegadores, y que trabajó con las CA emisoras para revocarlos. Después, los datos de Certificate Transparency revelaron "varias marcas globales líderes y servicios en línea muy usados" afectados por los mismos ataques, y Chrome también bloqueó esos certificados. Google no dio sus nombres.
Google es directo sobre los límites: "no puede garantizar" que encontró cada dominio afectado, y las medidas de Chrome no protegen de forma confiable a quienes usan otros navegadores. Firefox revisa las revocaciones con CRLite, que según Mozilla cubre todas las revocaciones registradas en Certificate Transparency y se actualiza cada 12 horas en la versión de escritorio. Al 9 de octubre de 2026, no encontramos ninguna declaración pública de Mozilla, Apple o Microsoft sobre este incidente. Nuestra lectura: la revocación es lo que protege a los usuarios fuera de Chrome, así que las apps y los dispositivos que no revisan revocaciones son el hueco más probable.
Qué deben hacer ahora los dueños de dominios
Los consejos de Google son para cualquiera que tenga dominios, no solo para quienes usan .gh, .sl o .as.
- Vigila Certificate Transparency para cada dominio que tengas. Chrome exige que los certificados de confianza se publiquen en registros CT públicos, así que un monitor te avisa cuando aparece uno para tu nombre. Incluye los dominios estacionados y los regionales de código de país. El proyecto CT mantiene una lista de servicios de monitoreo, y si tienes un dominio .gh, .sl o .as, Google recomienda revisar ya las entradas recientes.
- Publica registros CAA restrictivos. Un registro CAA les dice a las CA cuáles de ellas pueden emitir certificados para tu dominio. El RFC 8657 agrega la cuenta y el método de validación, por ejemplo
example.com. CAA 0 issue "letsencrypt.org; accounturi=<URL de tu cuenta ACME>; validationmethods=dns-01". - Ten claro lo que CAA no puede hacer. Google aclara que CAA no puede detener la emisión durante un secuestro de DNS activo, porque el atacante controla los registros. Importa después: las CA pueden reutilizar una verificación de dominio ya completada, y una política CAA estricta impide que un atacante use esa verificación guardada para obtener certificados nuevos cuando recuperes el control.
Google también menciona soluciones de largo plazo: certificados con vigencia más corta y menos reutilización de las verificaciones de dominio, algo que ya programó el CA/Browser Forum en su votación SC-081v3.
Para más sobre ataques contra la infraestructura en la que confían las organizaciones, lee nuestra nota sobre el bloqueo de administradores de FortiGate y la de la brecha de datos de ASOS.
En resumen
El secuestro de dominios en los registros ccTLD muestra que quien controla el DNS de un dominio puede obtener un certificado válido para él, incluso de Google. Si usas Chrome, Google dice que no tienes que hacer nada. Si usas otro navegador, las revocaciones de las CA son tu protección, y ningún otro fabricante de navegadores había comentado al 9 de octubre de 2026. Si tienes dominios, configura hoy el monitoreo de CT y registros CAA restrictivos. Falta ver si los registros explican cómo los vulneraron. Más en nuestra sección de software.
Preguntas frecuentes
¿Qué es un secuestro de un registro ccTLD?
Un ccTLD es un dominio de nivel superior de código de país, como .gh para Ghana. En el secuestro de un registro, los atacantes toman el control del operador que administra esa terminación y cambian sus registros DNS, lo que les permite redirigir los dominios que dependen de él y pasar las verificaciones que usan las CA para emitir certificados.
¿Los usuarios de Chrome tienen que hacer algo?
No. Google dice que Chrome bloquea los certificados no autorizados mediante CRLSets y que "los usuarios de Chrome no necesitan hacer nada para estar protegidos".
¿Un registro CAA detiene este ataque?
No mientras está ocurriendo, según Google, porque el atacante controla el DNS. Un registro CAA restrictivo que indique tu cuenta de la CA y el método de validación ayuda cuando recuperas el control, porque bloquea certificados nuevos basados en verificaciones de dominio guardadas.