Cambios de DNS como indicadores de incidentes
Durante un incidente cibernético, los cambios en los registros DNS pueden ser tanto una causa como un síntoma. Un registro MX modificado puede redirigir el correo entrante de una organización a un servidor controlado por un atacante como parte de un compromiso de correo electrónico empresarial. Un registro NS o A modificado puede ser una señal de que una cuenta de registrador de dominio fue comprometida y el atacante redirigió el dominio por completo, a veces para servir malware o una página de inicio de sesión falsa desde infraestructura que controlan. En otros casos, la evidencia DNS simplemente ayuda a reconstruir qué infraestructura estaba en uso en el momento del incidente, sin que el DNS mismo fuera el vector de ataque.
Construyendo una línea de tiempo DNS
Recopile los registros DNS lo antes posible una vez que se sospeche un incidente, ya que los registros pueden ser modificados por un atacante o corregidos por el administrador legítimo antes de que comience una investigación completa. Cuando estén disponibles, compárelos con cualquier instantánea anterior que la propia organización haya guardado, como un resultado de monitoreo previo o una copia de seguridad de la configuración, para identificar específicamente qué registros cambiaron y aproximadamente cuándo, utilizando los valores de TTL de DNS y cualquier registro de cambios o registro de auditoría del registrador disponible como prueba de apoyo de la temporalidad.
Contraste la cronología de DNS con otras pruebas del incidente: encabezados de correo electrónico que muestran cuándo el correo comenzó a llegar a un servidor diferente, registros de transparencia de certificados que muestran cuándo se emitió un nuevo certificado para el dominio, y registros de servidor o aplicación que muestran cuándo cambiaron los patrones de tráfico. La evidencia de DNS es más útil cuando corrobora o contradice estas otras fuentes, en lugar de presentarse de forma aislada.
Evidencia a nivel de registrador y de registro
Más allá de los propios registros DNS, los datos de registro RDAP pueden mostrar si el registrador, los servidores de nombres o el contacto del registrante del dominio cambiaron aproximadamente al mismo tiempo, lo que apuntaría a un compromiso a nivel de cuenta en el registrador en lugar de un problema limitado a un único archivo de zona DNS. Los códigos de estado como clientTransferProhibited eliminados poco antes de una transferencia no autorizada son un patrón específico que vale la pena verificar en los datos de registro.
Documentación para respuesta y recuperación
Registre cada observación de DNS y RDAP con su marca de tiempo y fuente como parte del registro del incidente, ya que esta evidencia a menudo necesita ser compartida con el registrador, el proveedor de alojamiento, las fuerzas del orden o un proveedor de ciberseguro, cualquiera de los cuales puede solicitar detalles sobre qué cambió exactamente y cuándo. La restauración de registros correctos es un paso de respuesta operativa y debe documentarse por separado de la recopilación de evidencia de cuáles eran los registros incorrectos.
- Capture los registros DNS y RDAP actuales inmediatamente al sospechar un incidente.
- Comparar con cualquier instantánea previamente guardada para aislar lo que cambió.
- Coteje con los encabezados de correo electrónico, la emisión del certificado y los registros del servidor.
- Verificar los códigos de estado a nivel del registrador y los cambios de contacto, no solo los registros DNS.
- Mantenga la recopilación de pruebas separada de los pasos de remediación.