Ciberseguridad

Secuestro de dominios ccTLD: cómo detectar certificados HTTPS falsos

Google confirma secuestros de registros ccTLD con certificados HTTPS no autorizados. Cómo proteger el registrador, vigilar DNS, usar CAA y monitorizar Certificate Transparency.

Google ha confirmado una cadena de secuestros en los registros de los dominios territoriales .gh, .sl y .as que permitió modificar DNS autoritativos y obtener certificados HTTPS no autorizados. El incidente no comprometió los sistemas de Google: afectó a una capa anterior de confianza, la infraestructura que decide a qué servidores apunta un dominio.

Chrome bloqueó certificados sospechosos mediante CRLSets y colaboró con las autoridades certificadoras para revocarlos. Sin embargo, la lección práctica va más allá de esos tres ccTLD: un candado HTTPS no demuestra por sí solo que el DNS, el registrador o el registro estén bajo control legítimo. Los propietarios de dominios deben vigilar cambios DNS y emisiones de certificados, proteger la cuenta del registrador y preparar una respuesta rápida.

Qué ha ocurrido con los ccTLD .gh, .sl y .as

El 6 de octubre de 2026, el equipo de seguridad de Chrome explicó que atacantes habían comprometido los registros de tres dominios territoriales: .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Un registro ccTLD gestiona la zona de nivel superior de un país o territorio. Si esa infraestructura pierde el control, el problema no se limita a una web concreta: puede afectar a cualquier dominio situado bajo ese sufijo.

Los registros públicos de Certificate Transparency ayudaron a descubrir certificados de otras organizaciones que también podrían estar afectadas. Chrome señala que sus usuarios no necesitan realizar una acción específica para beneficiarse del bloqueo aplicado por el navegador. Los dueños de dominios, en cambio, no deberían depender únicamente de una mitigación del navegador, porque otros clientes, APIs y sistemas pueden seguir rutas distintas.

Cómo un secuestro de registro puede producir certificados HTTPS válidos

El flujo habitual de confianza combina varias piezas. El registro mantiene la delegación del dominio de nivel superior; el registrador administra la cuenta del titular; los servidores DNS autoritativos publican los registros de cada dominio; y una autoridad certificadora valida el control del nombre antes de emitir un certificado TLS.

Si un atacante consigue alterar la delegación en el registro o los DNS autoritativos, puede dirigir temporalmente un dominio a una infraestructura propia. Esa posición le permite superar algunos métodos de validación de control de dominio y solicitar un certificado que los navegadores reconocerían como criptográficamente válido. El candado seguiría apareciendo, aunque el servicio estuviera respondiendo desde un destino ilegítimo.

Capa	Función	Riesgo si se compromete
Registro ccTLD	Gestiona la zona del sufijo territorial.	Puede cambiar delegaciones para muchos dominios bajo el mismo ccTLD.
Registrador	Gestiona titularidad, bloqueo, contactos y nameservers.	Un acceso no autorizado permite transferir o reconfigurar el dominio.
DNS autoritativo	Responde con IP, correo y otros registros oficiales.	El tráfico puede redirigirse a servidores controlados por un tercero.
Autoridad certificadora	Emite certificados tras validar el dominio.	Puede emitir legítimamente si la validación observa el DNS manipulado.
Navegador o cliente	Valida la cadena TLS y las revocaciones.	No todos los clientes reciben o aplican las mismas mitigaciones al mismo tiempo.

Por eso conviene separar dos preguntas: “¿la conexión está cifrada?” y “¿el destino pertenece realmente a quien espero?”. TLS protege la conexión con el servidor presentado, pero la identidad depende de que DNS, la validación y la emisión no hayan sido manipulados.

Qué riesgos crea para una organización

La consecuencia más visible es el phishing con un dominio legítimo y un certificado aceptado. También puede producirse interceptación de sesiones, sustitución de descargas, desvío de APIs, manipulación de correo si cambian los registros MX o fallos de disponibilidad. En una empresa con varios dominios regionales, un activo poco usado puede convertirse en el punto de entrada si queda fuera del inventario y la monitorización.

• Web: redirección de visitantes a una copia maliciosa del sitio.
• Correo: cambios de MX, SPF, DKIM o DMARC que faciliten suplantación o interceptación.
• APIs: clientes automáticos pueden confiar en un certificado válido sin detectar el cambio de infraestructura.
• Software: una descarga o repositorio asociado al dominio puede distribuir archivos alterados.
• Marca: dominios regionales, aparcados o de campañas antiguas pueden usarse para engañar a clientes.

El incidente también muestra por qué el inventario de dominios debe incluir más que la web principal. Un equipo necesita saber qué ccTLD, subdominios, dominios aparcados y nombres defensivos posee, quién puede modificarlos y qué autoridad certificadora está autorizada para emitir en cada caso.

Cómo proteger el dominio antes de un incidente

Los controles no eliminan todos los escenarios de compromiso del registro, pero reducen ataques más frecuentes y mejoran la capacidad de reacción. ICANN recomienda medidas como autenticación multifactor, bloqueo de transferencia, control de accesos administrativos, revisión de registros DNS y DNSSEC cuando esté correctamente soportado.

1. Activa MFA resistente al phishing. Una llave FIDO2 o passkey ofrece mejor protección que códigos enviados por SMS.
2. Aplica registrar lock y, si procede, registry lock. El primero dificulta transferencias; el segundo puede exigir verificación manual para cambios críticos.
3. Separa cuentas y permisos. Evita compartir una cuenta general y limita quién puede tocar nameservers, contactos y transferencias.
4. Protege el correo de recuperación. Si el buzón administrativo cae, muchos controles del registrador pueden quedar anulados.
5. Mantén contactos vigentes. Las alertas y renovaciones deben llegar a responsables que puedan actuar.
6. Revisa historial y alertas. Conserva evidencia de cambios de nameserver, DS, contactos, bloqueo y emisión de certificados.
7. Documenta la emergencia. Anota contactos 24/7 del registrador, proveedor DNS y autoridad certificadora.

DNSSEC añade firmas a los datos DNS y ayuda a detectar respuestas manipuladas cuando la cadena de confianza está bien configurada. No debe presentarse como una solución universal: una mala operación puede causar indisponibilidad y un compromiso en una capa superior del registro exige analizar el alcance concreto. Nuestra guía sobre 1.1.1.1, EDE 33 y fallos DNSSEC explica cómo interpretar esos errores sin desactivar la validación a ciegas.

Certificate Transparency, CAA y vigilancia DNS

Google recomienda monitorizar continuamente Certificate Transparency para todo el inventario. Los certificados que Chrome confía deben aparecer en registros CT públicos, de modo que una alerta puede avisar casi en tiempo real de una emisión inesperada. La cobertura debe incluir dominios regionales, aparcados y variantes que no reciben tráfico habitual.

Los registros CAA permiten indicar qué autoridades certificadoras pueden emitir para un dominio. Google aconseja una política restrictiva y, cuando sea viable, vincularla a cuentas ACME y métodos de validación autorizados. CAA no impide necesariamente una emisión durante un secuestro DNS activo, pero ayuda a limitar el conjunto de emisores y a evitar nuevas emisiones con validaciones reutilizadas después de recuperar el control.

Una vigilancia razonable combina cuatro señales:

• certificados nuevos o renovados en CT;
• cambios de nameservers, DS, A/AAAA, CNAME, MX, CAA y TXT;
• modificaciones de contactos, bloqueo o códigos EPP en el registrador;
• variaciones de rutas, IP, proveedor y huella TLS observadas desde varias redes.

Para implantar alertas de emisión, consulta también nuestra guía sobre Cloudflare Certificate Transparency Monitoring. La herramienta concreta importa menos que cubrir todos los dominios y asignar a alguien la revisión de cada alerta.

Qué hacer si detectas un certificado o cambio DNS no autorizado

Una alerta debe activar un procedimiento corto y verificable. Evita empezar borrando evidencias o cambiando varias capas sin registrar qué estaba ocurriendo.

1. Confirma desde una vía independiente. Consulta CT, DNS autoritativo, panel del registrador y resolución desde distintas redes.
2. Preserva evidencia. Guarda tiempos, certificados, cadenas, registros DNS, IP, logs y capturas del panel.
3. Contacta con el registrador y el proveedor DNS. Solicita bloqueo de cambios, restauración de delegación y revisión de accesos.
4. Revoca certificados no autorizados. Informa a la autoridad emisora y aporta la evidencia requerida.
5. Rota credenciales y tokens. Incluye API, paneles, correo y cualquier secreto expuesto a través del dominio afectado.
6. Revisa correo y subdominios. No limites la investigación a la página principal.
7. Restablece CAA y controles. Verifica que la política correcta está publicada después de recuperar el DNS.
8. Comunica con precisión. Informa a usuarios y socios de qué dominios, periodos y servicios están afectados.

Si el incidente afecta a sesiones o datos, la recuperación técnica no cierra el caso. Conviene invalidar sesiones, revisar accesos posteriores, analizar si hubo descargas o cambios de configuración y valorar las obligaciones de notificación aplicables.

Podcast: el incidente explicado en diez minutos

El episodio “Cleartext – October 08, 2026”, publicado por Cleartext, dedica su primer bloque al secuestro de los registros ccTLD, la relación entre DNS y certificados y el valor de CT y CAA. Es un resumen breve para ampliar el contexto operativo; la fuente primaria para los hechos técnicos sigue siendo el aviso de Google.

Ver notas, fuentes y transcripción del episodio.

Preguntas frecuentes

¿El candado HTTPS garantiza que una web es legítima?

No. Confirma que existe una conexión cifrada con un servidor cuyo certificado supera la validación del cliente. Si el DNS o la validación de dominio fueron comprometidos, un atacante puede llegar a presentar un certificado aceptado.

¿Chrome protege automáticamente frente a este incidente?

Google indica que Chrome bloqueó certificados no autorizados relacionados con los incidentes conocidos. Esa mitigación no sustituye la revisión del propietario ni garantiza protección idéntica en todos los navegadores, clientes, APIs o sistemas.

¿CAA evita cualquier certificado no autorizado?

No. CAA limita qué autoridades pueden emitir y puede reforzarse con vínculos de cuenta ACME, pero Google advierte que no bloquea necesariamente una emisión durante un secuestro DNS activo. Debe combinarse con monitorización CT y controles del registrador.

¿DNSSEC habría impedido el ataque?

DNSSEC protege la integridad de los datos DNS cuando la cadena de confianza funciona correctamente. Su eficacia depende del punto comprometido y de la operación del registro, registrador y proveedor DNS; no sustituye MFA, bloqueos, CAA ni monitorización.

¿Qué dominios deben vigilarse?

Todos: principal, regionales, aparcados, defensivos y subdominios relevantes. Los activos poco usados suelen quedar fuera de alertas y pueden seguir siendo válidos para phishing, correo o validaciones automáticas.

Fuentes oficiales y recursos

• Chrome Security: respuesta a los secuestros de registros ccTLD, 6 de octubre de 2026.
• ICANN: medidas preventivas ante ataques al DNS.
• ICANN: recomendaciones para titulares de nombres de dominio.
• Certificate Transparency: documentación y funcionamiento.

Conclusión: la confianza del dominio necesita varias capas

Los secuestros de .gh, .sl y .as demuestran que HTTPS puede fallar por debajo de la aplicación. Chrome reaccionó ante los certificados conocidos, pero el propietario del dominio sigue siendo quien mejor puede reconocer qué emisor, nameserver y cambio son legítimos.

La defensa práctica combina inventario completo, MFA resistente al phishing, bloqueo del dominio, contactos actualizados, DNSSEC bien operado, CAA restrictivo, alertas de Certificate Transparency y un procedimiento de recuperación probado. Ninguna capa basta por separado; juntas reducen el tiempo durante el que un cambio no autorizado puede pasar inadvertido.