Detectar cambios en el registro de dominio antes de que causen danos

Un atacante accede a una cuenta de registrador a través de una dirección de correo comprometida. Cambia los nameservers. El tráfico que debería llegar a tus servidores se redirige a los suyos. El propietario legítimo del dominio lo nota 48 horas después porque "algo parece raro" en el sitio. Si hubiera habido un sistema de detección de cambios de dominio, el cambio de nameservers habría disparado una alerta pocas horas después de producirse, la diferencia entre dos días de daño y dos horas.

Este artículo cubre qué puede cambiar en los datos de registro de un dominio, qué significa cada tipo de cambio, y cómo configurar la detección automática.

Qué puede cambiar en los datos de registro de un dominio

No todos los cambios conllevan el mismo riesgo. Categorizarlos ayuda.

Campos operativos, impacto inmediato posible:

• Nameservers: determina dónde se resuelven las consultas DNS. Un cambio de nameservers no autorizado redirige todo el tráfico, tu sitio web, tu correo, cualquier servicio que use ese dominio. Es el indicador más claro de un hijacking de dominio activo.
• Estados EPP: la eliminación de clientTransferProhibited suele ser el primer paso para iniciar una transferencia. La aparición de clientHold significa que la resolución DNS ya se ha detenido.
• Registrador: un cambio de registrador fuera de una transferencia que hayas autorizado es una señal fuerte de hijacking. Es relativamente raro pero grave cuando ocurre.

Campos informativos, señales estratégicas o administrativas:

• Nombre u organización del registrante: cambio de propietario.
• Email del registrante: cambio de contacto. Si no está autorizado, suele ser un precursor de una toma de control de la cuenta.
• Fecha de vencimiento: avance o postergación de la fecha de vencimiento.

Campos transitorios, normales, indican una operación en curso:

• pendingTransfer: se ha iniciado una transferencia.
• pendingUpdate: una modificación de datos está siendo procesada.

Anatomía de un hijacking de dominio en datos RDAP

Así es como se desarrolla un hijacking típico, mapeado sobre lo que RDAP mostraría en cada paso:

1. El atacante compromete la cuenta de correo asociada a la cuenta del registrador. Nada aparece aún en RDAP, este paso es invisible a nivel de dominio.
2. El atacante cambia el email de la cuenta del registrador. Si el registrador actualiza WHOIS con el nuevo email del registrante, esto aparece en RDAP como un cambio en los datos de contacto del registrante.
3. El atacante elimina clientTransferProhibited e inicia una transferencia a otro registrador, o cambia directamente los nameservers. RDAP muestra ahora: cambio de estado, nuevos nameservers, posiblemente pendingTransfer.
4. El DNS se propaga a los nuevos nameservers. Dependiendo de los valores TTL, esto puede tardar minutos u horas.

Los pasos 3 y 4 son detectables mediante diff de RDAP. Los pasos 1 y 2 pueden no aparecer inmediatamente, pero en cuanto el atacante avanza al paso 3, hay una señal detectable.

Hijacking de cuenta vs. hijacking de dominio: la diferencia

Un compromiso de cuenta de registrador no aparece inmediatamente en RDAP. La cuenta podría ser vulnerada sin que ningún cambio a nivel de dominio sea visible. La detección de cambios de dominio captura las consecuencias de un compromiso de cuenta (cuando se modifican nameservers o estados) no el compromiso en sí. Es una capa de defensa complementaria, no un sustituto de la seguridad de la cuenta (contraseñas fuertes, 2FA en tu cuenta de registrador).

Razones legítimas por las que los datos RDAP cambian

Antes de tratar cada cambio como sospechoso, conviene conocer los patrones de cambio esperados. Los falsos positivos hacen perder tiempo y erosionan la confianza en el sistema de alertas.

Cambios legítimos frecuentes:

• La renovación anual actualiza la fecha de vencimiento.
• Una migración de hosting planificada cambia los nameservers.
• Transferencia entre registradores autorizada.
• Actualización de los datos de contacto del registrante (nueva dirección, empresa fusionada).
• Activar o desactivar la protección de privacidad WHOIS.

El consejo práctico: lleva un registro de las operaciones de dominio planificadas. Cuando se dispare un alert, consulta primero ese registro. Si el cambio coincide con una operación prevista, confírmalo. Si no, investiga de inmediato.

Cómo Domain Sentinel detecta los cambios de datos

En cada ciclo de verificación, Domain Sentinel consulta RDAP para cada dominio de tu watchlist y almacena el resultado. En el siguiente ciclo, compara la nueva respuesta con el snapshot almacenado campo por campo. Cualquier campo que difiera del valor anterior genera un evento de cambio.

El alert contiene el campo específico que cambió, el valor anterior y el nuevo valor. Con eso es suficiente para evaluar de inmediato si el cambio era esperado.

Qué compara Domain Sentinel (y qué ignora)

No toda diferencia de campo es significativa. Los registros a veces actualizan marcas de tiempo internas o formatos sin que cambie de forma significativa el estado real del dominio. La comparación se centra en los campos operativamente significativos: nameservers, estados EPP, registrador, fecha de vencimiento y datos de contacto del registrante. Las actualizaciones rutinarias de marcas de tiempo que los registros añaden a los registros no generan alertas.

Cómo responder a un cambio sospechoso

Cuando se dispara un alert y no reconoces el cambio, el tiempo es la variable crítica. Cuanto más rápido actúes, menos daño se produce.

1. Nameservers cambiados de forma inesperada: comprueba si tu resolver DNS todavía devuelve las respuestas de los nameservers anteriores, esto te indica si el cambio se ha propagado. Registra los nuevos valores de nameservers. Si no autorizaste el cambio, contacta de inmediato al equipo de seguridad/abuso de tu registrador.
2. clientTransferProhibited eliminado: contacta a tu registrador ahora mismo y solicita que se restablezca el bloqueo de transferencia. Si ya hay una transferencia en curso, tienes una ventana para rechazarla (típicamente 5 días para .com).
3. Registrador cambiado sin transferencia autorizada: contacta al Ombudsman de Registradores de ICANN y a tu registrador original con prueba de propiedad. Es el escenario más grave y puede requerir escalada formal.
4. Email del registrante cambiado: suele ser señal de una toma de control de cuenta en curso. Inicia la recuperación de emergencia de la cuenta a través del canal de soporte de tu registrador, no a través de la dirección de correo de la cuenta comprometida.

La detección de cambios de dominio funciona como una cámara de seguridad sobre tus dominios. No previene ataques, pero reduce la ventana de detección de días a horas. Para el hijacking de dominio, esa diferencia es con frecuencia la diferencia entre un incidente recuperable y una pérdida permanente.