Cómo el secuestro de un código de país rompió la cadena de confianza de Internet

Recuerdo estar sentado en un centro de datos sin ventanas en 2011 cuando estalló la noticia de DigiNotar. En aquel entonces, una sola autoridad de certificación comprometida en los Países Bajos permitió a los atacantes acuñar credenciales fraudulentas para Google. Se sintió como una traición fundamental a las matemáticas que mantienen segura la web. Avancemos hasta finales de 2026, y la industria se enfrenta a una versión de la misma pesadilla, aunque el punto de entrada ha cambiado. Un aparato de seguridad de miles de millones de dólares fue derrotado por el equivalente digital de un cerrajero que roba las llaves maestras de una ferretería de un pueblo pequeño.

Google confirmó recientemente que atacantes secuestraron tres dominios de nivel superior de código de país (ccTLD): .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Al obtener el control de estos espacios de nombres, los actores modificaron los registros DNS autoritativos para objetivos específicos de alto valor. Este control les permitió eludir las comprobaciones de validación automatizadas que las autoridades de certificación utilizan para verificar la propiedad. El resultado fue la emisión de certificados TLS no autorizados para varios dominios de Google y otras grandes marcas globales. Esta es la paradoja arquitectónica de la seguridad moderna: una empresa puede gastar millones en "zero trust" y llaves de seguridad de hardware, pero su identidad digital sigue vinculada a la seguridad administrativa de un registro distante.

La mecánica de la elusión del control de dominio

Para entender por qué sucedió esto, tenemos que observar cómo un sitio web demuestra quién es. Cuando una organización solicita un certificado TLS, la Autoridad de Certificación (CA) emisora debe verificar que el solicitante realmente controla el dominio. El estándar de la industria para esto es la Validación de Control de Dominio (DCV). La CA le pide al solicitante que realice una tarea específica, como alojar un archivo único en una URL específica o, más comúnmente, crear un registro DNS específico. Si la CA ve el registro correcto en los servidores de nombres autoritativos, emite el certificado.

En este incidente, los atacantes no necesitaron hackear a Google. Hackearon la infraestructura del TLD en sí. Una vez que controlaron los servidores de nombres para .gh, .sl y .as, apuntaron los registros DNS de los subdominios objetivo a sus propios servidores. Cuando la CA realizó la comprobación automatizada, el servidor de los atacantes proporcionó la respuesta correcta. La CA siguió su protocolo a la perfección, pero estaba hablando con un impostor. El sistema es una bóveda digital que funciona solo si el portero en la puerta realmente sabe cómo se ve el dueño real.

Por qué los bloqueos de los navegadores son una solución temporal

Google actualizó Chrome para bloquear estos certificados no autorizados de inmediato. Esta es una medida reactiva que protege a millones de usuarios, pero resalta una debilidad sistémica. El proceso de revocación de un certificado es notoriamente lento. Los métodos tradicionales como las Listas de Revocación de Certificados (CRL) o el Protocolo de Estado de Certificados en Línea (OCSP) a menudo fallan debido a preocupaciones de privacidad o latencia de red. En consecuencia, los fabricantes de navegadores han optado por listas de bloqueo codificadas para proporcionar protección inmediata.

Desde una perspectiva de riesgo, esta intervención es un parche. Google admitió que las intervenciones de Chrome no protegen a los usuarios en otros navegadores, ni la empresa puede estar segura de haber identificado cada dominio afectado. Si un atacante posee un certificado firmado válidamente que un navegador aún no ha bloqueado, puede realizar un ataque de "man-in-the-middle". Pueden interceptar el tráfico, descifrar datos sensibles y presentar un icono de candado "seguro" a la víctima. La integridad de la conexión desaparece y el usuario no tiene forma de notar la diferencia.

La materia oscura de la red corporativa

El DNS es a menudo la materia oscura de la seguridad empresarial. Es invisible, omnipresente y frecuentemente se pasa por alto hasta que algo se rompe. Muchas organizaciones tratan sus relaciones con los TLD como un simple asunto de facturación en lugar de una dependencia de seguridad de misión crítica. Cuando registra un dominio en un TLD de código de país, está depositando su confianza en la seguridad del registro de esa nación, la estabilidad de su gobierno y su resiliencia técnica.

Mirando el panorama de amenazas, este incidente demuestra que los atacantes se están moviendo hacia arriba en la cadena de suministro. En lugar de atacar un perímetro reforzado, se dirigen a los componentes descentralizados de la infraestructura central de Internet. Una brecha a nivel de TLD es sigilosa porque no activa alarmas internas. Los servidores de la organización están bien, los empleados no están haciendo clic en enlaces de phishing y el firewall está en silencio. Sin embargo, la identidad de la marca está siendo falsificada en otro lugar.

Implementación de la autorización de la autoridad de certificación

Google está aconsejando a los propietarios de dominios que publiquen registros DNS de Autorización de Autoridad de Certificación (CAA) como contramedida. Un registro CAA es una declaración de política que le dice al mundo qué CAs específicas tienen permiso para emitir certificados para un dominio. Si un actor malintencionado intenta obtener un certificado de la CA "A", pero el registro CAA solo enumera la CA "B", la solicitud debe ser denegada.

Sin embargo, los registros CAA solo son efectivos si son restrictivos y si las CAs los respetan. Más importante aún, si un atacante secuestra el DNS, simplemente puede eliminar o modificar el registro CAA antes de solicitar el certificado fraudulento. Google sugiere que estos registros pueden evitar que los atacantes reutilicen datos de validación almacenados en caché, pero no son una solución milagrosa. Son una herramienta granular que añade una capa de fricción para el atacante, pero que aún dependen de la integridad del propio DNS.

La importancia de los registros de transparencia de certificados

Entre bastidores, la forma más eficaz de detectar este tipo de actividad es a través de los registros de Transparencia de Certificados (CT). El CT es un sistema de registros públicos, de solo adición, que registra cada certificado TLS emitido por las CAs participantes. Cada vez que se acuña un certificado para su dominio, aparece en estos registros.

Hablando proactivamente, cada equipo de seguridad debería monitorear estos registros para sus dominios. Si aparece un certificado de una CA que no utiliza, o en un momento en que no solicitó uno, es probable que esté ante un secuestro en curso. Utilizo varias herramientas automatizadas que me alertan vía Signal en el momento en que se emite un nuevo certificado para cualquier propiedad que administro. Esta visibilidad forense es la única forma de detectar un secuestro a nivel de TLD antes de que resulte en una brecha de datos masiva.

Lecciones de la era DigiNotar

Este incidente es un recordatorio de que el sistema de certificados tiene fallas sistémicas. En 2011, la brecha de DigiNotar fue una situación de rehenes digitales para el pueblo de Irán, cuyo tráfico fue interceptado por su gobierno utilizando certificados falsificados. Si bien el secuestro actual de TLD parece centrado en marcas y servicios, la vulnerabilidad técnica es idéntica. Seguimos utilizando un modelo de confianza centralizado en un mundo descentralizado.

El cifrado es una bóveda digital irrompible solo si las llaves se manejan con absoluta integridad. Cuando la infraestructura que valida esas llaves se ve comprometida, la puerta de la bóveda queda abierta de par en par. Los atacantes en este caso demostraron que no es necesario romper el cifrado para ganar. Solo necesitas convencer al sistema de que eres el propietario legítimo de la bóveda.

Conclusiones prácticas para líderes de seguridad

La seguridad a menudo consiste en gestionar dependencias que uno no controla. Si bien no puede asegurar la infraestructura de un registro TLD extranjero, puede controlar cómo responde su organización a estos riesgos.

• Audite su cartera de dominios e identifique qué dominios están registrados bajo ccTLDs con protocolos de seguridad menos estrictos.
• Publique registros CAA para todos los dominios de misión crítica para limitar qué autoridades pueden emitir credenciales.
• Configure el monitoreo en tiempo real de los registros de Transparencia de Certificados para detectar emisiones no autorizadas en cuestión de minutos.
• Habilite las Extensiones de Seguridad de DNS (DNSSEC) donde sea posible para añadir firmas criptográficas a sus datos DNS, dificultando la ejecución de secuestros.
• Revise su plan de respuesta a incidentes para incluir un protocolo de revocación rápida de certificados y coordinación con los proveedores de navegadores.

Como contramedida, estos pasos aseguran que incluso si el registro TLD falla, su equipo tenga la visibilidad para reaccionar antes de que el daño se vuelva sistémico. El objetivo es pasar de una postura reactiva a una resiliente. La seguridad no es un estado que se alcanza, sino un proceso que se mantiene.

Fuentes:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Descargo de responsabilidad: Este artículo tiene fines informativos y educativos únicamente y no reemplaza una auditoría de ciberseguridad profesional ni un servicio de respuesta a incidentes.