ccTLD .gh, .sl y .as secuestrados: certificados de Google

📌 Novedades posteriores: Node.js: diez vulnerabilidades corregidas, cuatro de alto riesgo (21 de octubre de 2026) · eMudhra: claves de CA triviales, revocaciones y parches (20 de octubre de 2026)

El 6 de octubre de 2026 el Chrome Secure Web and Networking Team de Google dio a conocer una serie de ataques contra tres dominios de primer nivel nacionales (ccTLD): .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Durante los secuestros, los atacantes modificaron registros DNS autoritativos y obtuvieron certificados HTTPS no autorizados para varios dominios de Google y para dominios de otras organizaciones. Google afirma que tuvo conocimiento de los ataques la semana anterior.

No hay CVE: el problema no es un fallo de un producto, sino el control de la resolución de nombres por encima de los sitios afectados.

Qué ha pasado

Según Google, sus sistemas no fueron comprometidos y, dada la naturaleza de los ataques, no hay motivos para pensar que las autoridades de certificación (CA) que emitieron los certificados hicieran algo mal. Google no ha indicado qué dominios se vieron afectados ni cuántos certificados se obtuvieron.

Sobre cómo los atacantes tomaron el control del DNS, las fuentes son genéricas: Infosecurity Magazine y The Hacker News hablan de un compromiso de los registros de los tres ccTLD, mientras que las declaraciones de Google recogidas por la prensa hablan de secuestros con modificación de registros DNS autoritativos, sin detalles sobre la técnica.

La respuesta de Google, según Infosecurity Magazine:

• Chrome bloqueó los certificados no autorizados de las propiedades de Google mediante los CRLSets, el mecanismo con el que el navegador bloquea certificados rápidamente en caso de emergencia;
• Google trabajó con las CA emisoras para revocar los certificados, de modo que también quedaran protegidos los usuarios de otros clientes;
• los logs de Certificate Transparency (CT) revelaron después otras organizaciones afectadas, entre ellas grandes marcas globales y servicios en línea muy utilizados: también esos certificados se bloquearon en Chrome, y Google contactó con las organizaciones cuando fue posible.

Detalles técnicos: por qué basta con un DNS secuestrado

Antes de emitir un certificado, una CA comprueba que quien lo solicita controla el dominio. Quien controla los registros DNS autoritativos puede interferir en esa comprobación y obtener un certificado válido sin vulnerar los sistemas del sitio. Como subraya The Register, el atacante dispone entonces tanto del enrutamiento del tráfico (a través del DNS) como de la clave privada del certificado:

1. los usuarios que escriben la dirección correcta pueden acabar en una copia del sitio;
2. el navegador no muestra avisos, porque el certificado lo emite una CA de confianza;
3. el atacante puede interceptar o modificar los datos enviados al sitio suplantado y aprovechar la marca para phishing o distribución de malware.

Hay además un efecto que dura más que el ataque. Las CA pueden reutilizar durante cierto tiempo una validación del control del dominio ya superada: según Google, incluso después de que el propietario recupere el control del DNS, el atacante podría aprovechar esa validación en caché para obtener nuevos certificados.

MITRE ATT&CK (clasificación nuestra, las fuentes no la indican): T1584.001 (Compromise Infrastructure: Domains) para el secuestro y T1588.004 (Obtain Capabilities: Digital Certificates) para los certificados obtenidos.

Impacto para las empresas europeas e italianas

El riesgo directo afecta a quien tenga dominios bajo .gh, .sl o .as, incluidos los registros regionales o defensivos, a menudo aparcados y poco vigilados. Pero la lección es general: la confianza en HTTPS depende de la seguridad de toda la cadena DNS, desde el registro hasta el proveedor que gestiona la zona, y un secuestro por encima no deja rastro en los sistemas del sitio suplantado.

La propia Google advierte que la intervención en el navegador no debe considerarse una protección: su análisis podría no haber identificado todos los dominios afectados y los bloqueos de Chrome no protegen de forma fiable a quien usa otros clientes.

Para las entidades sujetas a NIS2, los registradores y los proveedores de DNS forman parte de la cadena de suministro que debe cubrir la gestión de riesgos. Un certificado emitido sin autorización para uno de tus dominios es un evento que hay que analizar, también a efectos de la notificación al CSIRT nacional.

Qué hacer ya

1. Haz un inventario de tus dominios, incluidos los aparcados y los ccTLD regionales: no se puede vigilar lo que no se conoce.
2. Vigila de forma continua los logs CT de todos tus dominios: es la forma de saber, casi en tiempo real, que alguien ha obtenido un certificado a tu nombre.
3. Si tienes dominios bajo .gh, .sl o .as, revisa enseguida las entradas CT recientes en busca de certificados inesperados.
4. Publica registros CAA restrictivos, que indican qué CA pueden emitir certificados para el dominio. Google recomienda limitarlos también a cuentas ACME y métodos de validación concretos (extensiones accounturi y validationmethods), por ejemplo: 0 issue "ca.example; accounturi=https://ca.example/acct/123; validationmethods=dns-01". Durante un secuestro activo, los CAA no bloquean la emisión, porque el atacante controla también esos registros; una vez restablecidos, en cambio, impiden reutilizar las validaciones en caché para obtener nuevos certificados.
5. No confíes en el navegador como única defensa, sobre todo para usuarios y aplicaciones que no usan Chrome.

Google también ha anunciado que seguirá trabajando en cambios en todo el ecosistema HTTPS, entre ellos la reducción de la validez de los certificados y de la reutilización de la validación del control del dominio.

Cómo ayuda ARXDOME

ARX Expose parte de los dominios declarados para tu empresa y muestra su superficie de ataque, incluidos nombres y certificados, con una comprobación diaria; también señala los dominios parecidos al tuyo registrados por otros, a menudo usados para phishing. Con ARX Horizon puedes consultar desde el portal los indicadores de compromiso y la reputación de una dirección.

Última actualización: 8 de octubre de 2026