El candado era válido, el sitio era falso: los secuestros de los registros .gh, .sl y .as explicados

El 6 de octubre de 2026, el equipo de seguridad de Chrome en Google publicó una entrada breve con un título seco y un contenido alarmante: unos atacantes habían tomado el control de tres registros de dominios de país, el .gh de Ghana, el .sl de Sierra Leona y el .as de Samoa Americana, modificaron registros DNS autoritativos y obtuvieron certificados HTTPS válidos para dominios de Google y para “varias marcas globales líderes” que no nombró. Cualquiera que hubiera aterrizado en uno de los sitios falsos habría visto un candado de navegador sin nada raro.

El incidente merece entenderse bien, porque se sitúa en el punto exacto donde el modelo mental de seguridad web de la mayoría de la gente está equivocado. El candado no significa “este es el sitio real”. Significa algo mucho más estrecho, y a finales de septiembre la distancia entre ambas cosas se convirtió en un ataque operativo.

Una definición sostiene toda esta página: un certificado de validación de dominio prueba una sola cosa, que en el momento de la emisión el solicitante controlaba el DNS del dominio. Cuando el registro que está por encima del DNS es robado, el ladrón es, para todas las comprobaciones automáticas del mundo, el dueño.

¿Qué pasó con .gh, .sl y .as?

Un registro de país es la organización que administra la base de datos maestra de todo lo que vive bajo su dominio de dos letras: el .gh lo opera Network Computer Systems en Accra, el .sl la telco Sierratel, el .as el AS Domain Registry. Comprometa esa base de datos y no necesita hackear ningún sitio web concreto, porque puede redelegar cualquier nombre bajo el TLD hacia servidores que usted controla.

Eso fue lo que ocurrió, un registro cada vez. Los certificados aparecieron en los logs públicos para nombres .gh el 22 de septiembre, .sl el 25 de septiembre y .as el 27 de septiembre, lo que se lee como un equipo bajando por una lista. Google dice que los atacantes “modificaron registros DNS autoritativos y obtuvieron certificados HTTPS no autorizados que cubren varios dominios de Google, así como dominios pertenecientes a otras organizaciones”, y que sus propios sistemas no fueron tocados.

Una cantidad notable de cosas sigue sin revelarse: cómo se vulneraron los registros, quién lo hizo, si algún certificado se usó contra usuarios reales y la lista completa de víctimas. Ninguno de los tres operadores de registro había publicado un comunicado al cierre de esta página. Decimos “no revelado” allí donde ese es el estado de las cosas, y lo mismo debería hacer cada crónica que usted lea.

¿Cómo consiguieron los atacantes certificados válidos para dominios de Google?

Pidiéndolos educadamente. The Hacker News, trabajando sobre el historial público de Certificate Transparency, contó al menos 12 certificados que cubren 7 dominios de Google y YouTube, google.com.gh, google.sl, google.as y variantes entre ellos: 11 emitidos por Let’s Encrypt y 1 por ZeroSSL, todos de validación de dominio. Un miembro del equipo de Let’s Encrypt confirmó la emisión y las revocaciones en el foro del proyecto.

Aquí está la parte incómoda: las CA siguieron sus reglas. El propio Google escribió que no tiene “ninguna razón para creer que las autoridades de certificación (CA) que emitieron los certificados afectados hicieran nada mal”. La validación de dominio pide al solicitante demostrar el control del DNS del dominio, normalmente publicando un registro. Los atacantes eran el DNS. Cada comprobación automática a la que se enfrentaron la pasaron honestamente, en el sentido estrecho en que las máquinas entienden la honestidad.

Un detalle muestra cómo es la vigilancia en esta capa: en los registros de los logs revisados, desde al menos el 10 de septiembre, todos los demás certificados para google.com.gh, google.sl y google.as habían salido de Google Trust Services, la CA del propio Google. Doce certificados de dos CA sin relación eran en sí mismos la anomalía, sentada en un log público, esperando a que alguien mirara.

¿Quién lo detectó y cómo se detuvo?

Tres mecanismos, por orden de velocidad.

Primero, Certificate Transparency hizo que los certificados fueran visibles, para empezar. Desde el 30 de abril de 2018, Chrome rechaza cualquier certificado no divulgado en los logs públicos de CT, de modo que un atacante que quiera un certificado que funcione en el navegador más usado del mundo debe entregarle también al mundo una confesión firmada de que ese certificado existe. El contador público del ecosistema supera los 2.500 millones de certificados consignados, y Let’s Encrypt cruzó por sí solo los diez millones de certificados emitidos en un solo día a finales de septiembre de 2025; encontrar 12 malos en ese pajar es exactamente para lo que existe la infraestructura de logs.

Segundo, Chrome bloqueó los certificados mediante los CRLSets, su lista de bloqueo de emergencia, que se distribuye por el actualizador de componentes del navegador y surte efecto sin actualización ni reinicio. El equipo de seguridad de Chrome lleva años sosteniendo que las comprobaciones de revocación en línea fallan justo cuando se las necesita, porque el atacante en medio puede bloquear la propia comprobación; la lista de bloqueo viaja con el navegador en su lugar. Google después minó los datos de CT en busca de más víctimas, bloqueó también esos certificados y dice que contactó a las organizaciones afectadas donde pudo.

Tercero, la vía lenta que cubre a todos los demás: las CA revocaron los 12 certificados, los dos certificados .gh y el único de ZeroSSL el 26 de septiembre, los otros nueve el 1 de octubre. La ventana más corta entre la aparición de un certificado en el log y su muerte fue de un día y medio; la más larga, de casi una semana. La cláusula de honestidad del propio Google merece cita: “no podemos garantizar que nuestro análisis identificara todos los dominios afectados, ni las intervenciones de Chrome protegen de forma fiable a los usuarios de otros navegadores”.

¿Habrían evitado esto DNSSEC o los registros CAA?

Este incidente es la demostración más limpia en años de qué compran y qué no compran estas dos siglas.

DNSSEC primero. Consultando la zona raíz publicada: .gh y .sl no están firmados en absoluto, lo que los coloca entre los muchos ccTLD que nunca desplegaron DNSSEC, una tecnología con un 99 por ciento de adopción entre los registros de Europa pero un 65 por ciento en África. Y .as está firmado, y fue secuestrado igualmente. DNSSEC permite a un resolutor verificar que una respuesta coincide con lo que el registro publicó. Cuando el propio registro es hostil, publica los datos del atacante, claves incluidas. La firma sobre una mentira sigue siendo una firma válida.

Los registros CAA, que permiten al dueño de un dominio declarar qué CA pueden emitir para él, tienen una forma más sutil. Durante el secuestro son inútiles, porque el registro CAA vive en el mismo DNS que el atacante controla; el propio estándar CAA admite que un atacante capaz de editar el DNS puede eliminar el registro. Después del secuestro importan mucho, porque las CA pueden reutilizar una validación completada hasta 200 días bajo las reglas actuales del CA/Browser Forum, una ventana que cae a 100 días en marzo de 2027 y a 10 días en 2029, así que un atacante que ya perdió el DNS aún podría acuñar certificados frescos a partir de comprobaciones en caché. Para el 7 de octubre, los siete dominios de Google víctimas conocidos llevaban todos registros CAA que nombran únicamente a la CA del propio Google. Esa es la cerradura que uno instala después de este robo concreto, y es una cerradura real.

¿Ha pasado esto antes?

Los ataques a registros y a la infraestructura DNS son un género, no una novedad. El historial con fechas:

Hay 316 TLD de país entre los aproximadamente 1.400 dominios de la zona raíz, cada uno ligado a un país o territorio, cada uno con su presupuesto, su gobernanza y su postura de seguridad, y algunos gestionados por operadores privados. La propia autoridad estatutaria de dominios de Ghana lleva años en una disputa pública sobre quién debería siquiera operar .gh. El modelo de confianza de la web descansa, en parte, en que la menos financiada de estas organizaciones tenga un buen equipo de seguridad.

¿Qué habría visto usted, y qué le protege de verdad?

Si le hubieran dirigido a uno de los sitios falsos durante la ventana, no habría visto nada. Un certificado válido, un candado normal, ninguna advertencia de ningún tipo; como lo expresó Ars Technica, la posesión de tales certificados “permite a los atacantes suplantar criptográficamente la infraestructura afectada”. Si alguien fue dirigido realmente allí es uno de los hechos no revelados.

Lo que protegió a los usuarios no fue nada que un usuario hiciera. El rastro escrito obligatorio de CT expuso los certificados, los CRLSets los mataron en Chrome sin exigir acción alguna, y la revocación cubrió el resto. Una capa más merece mención: las aplicaciones nativas que fijan sus claves. En el caso de Togo de 2017, el pinning de Chrome habría rechazado de todos modos el certificado google.tg fraudulento, y las aplicaciones del propio Google y muchas apps bancarias siguen fijando claves hoy. La defensa en profundidad no es aquí un eslogan; es una pila concreta, y a finales de septiembre cada capa de esa pila soportó carga.

¿Protege una VPN contra esto?

Una página de seguridad honesta responde a esta pregunta con precisión, así que aquí va la respuesta precisa: no para esta clase de ataque, sí para sus primas mucho más comunes, y saber cuál es cuál es todo el juego.

Una VPN no participa en TLS. Su navegador valida los certificados contra su almacén de confianza exactamente igual en cualquier red, y estos certificados eran válidos. Peor para cualquier herramienta aguas abajo del DNS: los atacantes envenenaron los registros autoritativos en el propio registro, así que todos los resolutores honestos del planeta, los de un proveedor de VPN incluidos, servían las respuestas del atacante. Ninguna VPN, la nuestra incluida, habría bloqueado esto. Lo que lo detuvo fue la cadena de CT, CRLSets y revocación descrita arriba.

Lo que una VPN sí defiende es su lado de la conexión. En una red local hostil, un punto de acceso trucado o un ISP que manipula el tráfico, el atacante se sitúa entre su dispositivo e internet, inyectando respuestas DNS o redirigiendo el tráfico. Una VPN traslada su resolución DNS y la ruta de su tráfico a un túnel cifrado que, como dice la guía de la EFF, esconde su tráfico de “su ISP y del dueño de la red local (como una cafetería o un hotel)”. Esa es la superficie de ataque común, la de todos los días, la que cubrimos en nuestras guías sobre el cifrado de la VPN y la seguridad en el Wi-Fi público, y es exactamente la capa que los atacantes de los registros nunca necesitaron tocar. Las dos protecciones son complementarias, no intercambiables, y por eso mantenemos también una página honesta aparte sobre lo que los sitios aún pueden ver con la VPN activada.

¿Qué deberían hacer ahora los dueños de dominios?

El consejo de Google a las organizaciones son dos pasos, y vale igual para una empresa con tres dominios que para una con tres mil. Vigile los logs de Certificate Transparency de cada dominio que posea, aparcados y regionales incluidos; los 12 certificados fraudulentos pasaron días en logs públicos, visibles para cualquiera que mirara. Y publique registros CAA restrictivos que nombren a su CA, idealmente con vinculación de cuenta ACME, para que incluso su propia CA emita solo hacia su cuenta. El reglamento de las CA añade un tercer paso: si aparece un certificado no solicitado, presente un Certificate Problem Report, que los Baseline Requirements del sector obligan a la CA a investigar, con primeras conclusiones en 24 horas.

Para todos los demás, las lecciones son más pequeñas pero reales. Mantenga su navegador actualizado, porque la lista de bloqueo que salvó a los usuarios de Chrome viaja con él. Trate el candado como lo que es, una afirmación sobre el cifrado en tránsito, no sobre quién está al otro lado. Y coloque cada herramienta en su propia capa: el sistema de certificados autentica sitios, una VPN protege la ruta que toma su tráfico, y el incidente de septiembre necesitó que el primero fallara de forma segura mientras la segunda nunca estuvo en juego.