Recuperar un dominio secuestrado: revisa los certificados

La recuperación tras el secuestro de un dominio continúa después de restaurar DNS. Busca certificados inesperados en Certificate Transparency, pide a la autoridad de certificación emisora que revoque los no autorizados, restablece una política de emisión restrictiva y asigna a alguien la vigilancia continuada. Que la web funcione y que un navegador aplique un bloqueo de emergencia solo aclara una parte de la recuperación.

El 6 de octubre, Google informó de una manipulación del DNS autoritativo que afectó a los espacios de nombres .gh, .sl y .as, seguida de la emisión de certificados no autorizados para Google y otras organizaciones. Según Google, sus propios sistemas no se vieron comprometidos y no hay motivos para culpar a las autoridades de certificación emisoras. Chrome bloqueó certificados mediante CRLSets mientras Google coordinaba su revocación con los emisores. Esta es la versión de Google sobre el incidente, no una reconstrucción pública completa de su impacto. Informe del incidente de Google.

¿Qué queda pendiente después de restaurar DNS?

Recuperar el control de DNS no invalida un certificado existente. Certification Authority Authorization, o CAA, determina qué autoridades pueden emitir certificados; no determina cómo valida un cliente un certificado ya emitido. Cambiar esa política no puede anular una emisión de forma retroactiva. RFC 8659.

El dominio puede apuntar al servidor correcto y la web presentar su certificado habitual mientras un certificado emitido durante el control no autorizado sigue sin revocarse. Comprueba por separado el control del dominio y el estado de los certificados.

Abre un registro de recuperación con estas preguntas:

La misma distinción se aplica a los informes de credenciales filtradas: impedir futuros accesos y entender la actividad pasada son decisiones distintas.

Recupera el control y conserva los registros del periodo investigado

Colabora con el registrador, el registro y los proveedores de DNS correspondientes para recuperar el control. Conserva los registros de cambios disponibles y delimita el periodo que necesitas investigar antes de que las tareas habituales de limpieza dificulten reconstruir la secuencia.

Anota qué capa crees que se vio afectada y qué proveedor confirmó la recuperación. Una cuenta comprometida en el registrador, unos registros autoritativos alterados y un incidente en el registro pueden implicar a organizaciones distintas. El informe de Google trata sobre la manipulación del DNS autoritativo en tres espacios de nombres. Relato de Google.

Para cada dominio afectado, registra la delegación prevista, el proveedor de DNS y los servicios que dependen de él. Incluye dominios regionales, nombres que redirigen y dominios aparcados. Un dominio sin una web activa también puede formar parte de la investigación de certificados. Google recomienda expresamente vigilar todos los dominios propios, incluidos los aparcados y los regionales, y advierte de que su investigación puede haber pasado por alto dominios afectados. Recomendaciones de Google para propietarios.

Justifica el periodo investigado. Si conoces el primer cambio no autorizado confirmado y la hora de restauración confirmada por el proveedor, conserva ambos datos. Si los registros están incompletos, indica qué límite es incierto. Elegir un periodo cómodo alrededor de la primera alerta sirve como punto de partida, pero no demuestra que no hubiera actividad anterior.

Busca certificados inesperados en Certificate Transparency

Certificate Transparency, o CT, permite consultar certificados y precertificados en registros públicos que solo admiten nuevas entradas. Los sistemas de vigilancia revisan esos registros y pueden avisar a sus suscriptores de las entradas que encuentran. CT aporta pruebas de emisión que investigar; una entrada no demuestra interceptación ni robo de datos. Cómo funciona CT.

Busca el dominio afectado en crt.sh, una herramienta de consulta de CT enlazada desde las instrucciones de revocación de Let’s Encrypt. Abre los resultados pertinentes y contrasta los nombres cubiertos, el emisor, las fechas de validez y las marcas de tiempo del registro con el periodo investigado. Utiliza los datos del certificado y del registro conjuntamente; no tomes el inicio de validez como la hora exacta de emisión.

Compara los resultados con los registros de despliegue y renovación. Pregunta al responsable del servicio si cada certificado corresponde a una renovación habitual, una CDN u otro despliegue autorizado. Descarga los certificados sin explicación cuando estén disponibles, para que el emisor pueda investigar el mismo archivo.

Para cada resultado sin explicación, conserva un registro breve de las pruebas:

• Los nombres de dominio que cubre el certificado, incluidos sus nombres alternativos de sujeto.
• Emisor, número de serie y huella del certificado.
• Fechas de validez y referencia al registro correspondiente.
• Si la entrada observada es un certificado o un precertificado.
• Los registros de despliegue o renovación con los que lo comparaste.
• La persona que lo revisó y la conclusión a la que llegó.

Distingue los precertificados. Un precertificado participa en el proceso de registro de CT y no es, por sí mismo, un certificado de servidor utilizable. Un resultado etiquetado como precertificado debe conservar esa etiqueta cuando lo comuniques al emisor y en el informe. No lo conviertas en una afirmación de que observaste un servidor presentando ese certificado. Descripción de los precertificados de CT.

La vigilancia de CT tiene límites de tiempo y cobertura. El proceso de registro incluye un plazo máximo de incorporación de entradas, y el sistema de vigilancia solo ve los registros que consulta. No prometas detección instantánea ni trates la ausencia de alertas como una investigación completa. El proyecto CT publica un directorio de sistemas de vigilancia, pero aparecer allí no garantiza una cobertura completa ni supone una recomendación adaptada a tus necesidades.

Solicita la revocación a la autoridad de certificación emisora

Comunica la emisión no autorizada a la autoridad que emitió el certificado y sigue su procedimiento de revocación documentado. Restaurar DNS, sustituir un certificado y aplicar un bloqueo de emergencia en el navegador son hechos distintos; ninguno debe sustituir la respuesta del emisor.

Envía los identificadores y las pruebas reunidas, explica por qué la emisión no estaba autorizada y conserva la solicitud y las respuestas posteriores. Si un certificado contiene varios nombres, indícalo desde el principio. Puede que necesites ayuda del emisor, en lugar de dar por hecho que controlar un dominio basta para el procedimiento que pretendes utilizar.

Let’s Encrypt documenta un ejemplo útil: tras recuperar el control del dominio, el propietario puede utilizar otra cuenta autorizada para solicitar la revocación demostrando el control de todos los identificadores del certificado. Por tanto, disponer de la clave privada del atacante no es la única vía de autorización. Este es el procedimiento de Let’s Encrypt; consulta las instrucciones del emisor real de tu caso. Documentación de revocación de Let’s Encrypt.

Haz un seguimiento de cada solicitud hasta obtener un resultado documentado. «Hemos enviado un correo a la CA» describe una acción pendiente. La respuesta del emisor y las pruebas del estado del certificado permiten una afirmación más sólida. Anota a qué certificado corresponde el resultado, para que una respuesta sobre un número de serie no cierre por accidente varias entradas sin explicación.

¿Qué demuestra un bloqueo de Chrome?

Los CRLSets de Chrome permiten bloquear certificados en situaciones de emergencia e incluyen una parte de las revocaciones recopiladas de las listas de las autoridades de certificación. No son una copia completa de todas las revocaciones. En su respuesta, Google recurrió al bloqueo en Chrome y a la coordinación con las CA como acciones distintas. Documentación de CRLSet de Chromium, respuesta de Google al incidente.

Google advierte de que sus intervenciones no protegen de forma fiable a quienes no usan Chrome. Si compruebas el comportamiento de navegadores o clientes de API, registra los clientes, versiones o entornos examinados, la hora y el resultado observado. Mantén ese alcance separado de la respuesta de revocación del emisor.

Restablece CAA sin interrumpir las renovaciones legítimas

CAA controla la emisión y debe revisarse después de recuperar DNS. No puede impedir emisiones no autorizadas mientras un atacante controle la propia política de DNS, ni revocar un certificado existente. Google recomienda restablecer una política CAA restrictiva con vinculaciones a cuentas y métodos de validación compatibles con el emisor, para limitar emisiones posteriores basadas en validaciones almacenadas en caché. Recomendaciones de Google.

Las validaciones almacenadas en caché importan porque el fin del control no autorizado de DNS no necesariamente elimina todas las oportunidades de emisión creadas durante ese periodo. Trata la revisión como una tarea de configuración específica del proveedor. No supongas que un registro CAA genérico elimina ese riesgo sin comprobar cómo admite el emisor las restricciones correspondientes.

RFC 8657 define dos parámetros: accounturi, que vincula la autorización al URI de una cuenta, y validationmethods, que limita los métodos de validación autorizados por ese registro. Su efecto depende de que la autoridad de certificación indicada los admita expresamente. Dar por supuesta la compatibilidad con cualquiera de ellos puede dejar sin aplicar la restricción prevista. RFC 8657.

Antes de cambiar registros de producción, identifica los emisores legítimos y las cuentas de emisión de producción. Confirma el URI exacto de la cuenta con el emisor o con el sistema que gestiona los certificados. El correo con el que inicia sesión una persona no sustituye ese identificador. Incluye el proceso de renovación y la última emisión manual, porque pueden depender de sistemas distintos.

Revisa la política completa:

1. Confirma que cada emisor indicado admite las vinculaciones que piensas utilizar.
2. Comprueba el URI de la cuenta de producción y los métodos de validación permitidos.
3. Revisa por separado la autorización de certificados comodín cuando corresponda.
4. Examina los alias, los nombres delegados y la política de subdominios.
5. Revisa todos los registros de autorización por si permiten una vía alternativa no prevista.
6. Verifica que la emisión y la renovación legítimas siguen funcionando con las restricciones previstas.

Let’s Encrypt documenta su compatibilidad con las restricciones de métodos http-01, dns-01 y tls-alpn-01, y con las vinculaciones a cuentas ACME. Comprueba CAA antes de cada emisión y explica que varios registros de autorización suman permisos. Su documentación también describe cómo las políticas de los subdominios pueden sustituir a las heredadas y cómo se resuelven los CNAME. Utiliza esos detalles cuando tu emisor sea Let’s Encrypt, sin suponer que todas las autoridades se comportan igual. Documentación de CAA de Let’s Encrypt.

Conviene comprobar expresamente esa suma de permisos. Un registro muy restrictivo puede coexistir con otra autorización que permita la emisión que querías prohibir. No basta con leer el registro nuevo. Revisa la política efectiva para los nombres que cubre el certificado, incluido el comportamiento pertinente de delegaciones y alias.

Conserva la prueba operativa junto al cambio de configuración. Registra qué se emitió correctamente, con qué cuenta y método, y qué proceso de renovación verificaste. Comprueba el proceso de renovación antes de aceptar el cambio, para que la política no bloquee tu próximo certificado legítimo.

Asigna la vigilancia de certificados para todos tus dominios

Mantén la vigilancia después de la recuperación inmediata y asigna a alguien que pueda contrastar las alertas y contactar con la autoridad emisora. Google recomienda cubrir todos los dominios propios porque una respuesta central puede pasar por alto nombres afectados. Recomendación de vigilancia de Google.

Define el alcance a partir del inventario de dominios, no solo de las webs activas. Incluye marcas regionales, redirecciones, dominios aparcados y nombres delegados a otros equipos. Para cada dominio, conserva quién debería operarlo y cuál es su proceso legítimo de emisión. Así se puede investigar una alerta nueva aunque no esté disponible quien atendió el incidente original.

Decide dónde llegan las alertas y qué ocurre si nadie responde. Para un equipo pequeño, contar con un responsable principal y un suplente claramente identificados puede resultar más útil que un buzón compartido que nadie lee. El procedimiento debe permitir conservar la entrada, contactar con el responsable del servicio y comunicar una emisión sin explicación sin tener que inventar el proceso durante el incidente.

La vigilancia no autoriza a realizar pruebas activas contra cualquier destino asociado a un dominio. Si la investigación pasa a comprobar activamente un servicio, verifica quién lo opera y qué permiso tienes. Nuestra guía sobre el alcance de los análisis de seguridad explica por qué una relación de DNS no basta para acreditar permiso.

Conserva las pruebas de recuperación junto al informe

Cierra el informe con resultados explícitos: control restaurado, pruebas de certificados revisadas, respuestas de emisores documentadas, política de emisión comprobada y trabajo pendiente asignado. Indica los límites junto a los resultados para que otra persona pueda valorar la decisión sin repetir la investigación.

Una nota de cierre útil podría decir: «El proveedor confirmó la recuperación del control de estos dominios. Contrastamos estos resultados de CT con los registros de despliegue y comunicamos dos entradas sin explicación a sus emisores. Sus respuestas están enlazadas aquí. Verificamos la política CAA indicada y el proceso de renovación. Las comprobaciones de clientes abarcaron estos entornos; la revisión de actividad sigue asignada a este responsable».

Sustituye cada referencia genérica por tus pruebas reales, incluidas las respuestas pendientes de los emisores y las lagunas del periodo investigado.

En Kit, un informe de seguridad puede reunir un responsable identificado, archivos adjuntos de apoyo, notas internas y enlaces a tickets del proveedor o de corrección. Su cronología agrupa cambios de estado, asignaciones y correspondencia. En un análisis posterior al incidente puedes registrar la causa raíz, las medidas correctivas y las conclusiones que aún quedan por extraer. Mantén el trabajo técnico de recuperación y sus resultados enlazados a ese informe.

Así tu equipo tiene un lugar donde revisar el relevo y la decisión de cierre. Consulta el proceso de Security de Kit y compáralo con tu proceso actual: ¿puede la siguiente persona identificar al responsable, encontrar las pruebas de certificados y ver qué afirmaciones de recuperación aún necesitan verificarse?