DNS, DHCP y nombres de red envenenados

Las tres piezas comparten una debilidad de diseño: nacieron para redes de confianza. Una respuesta DNS clásica viaja por UDP y el cliente acepta la primera que encaja con su pregunta; una consulta LLMNR (resolución local de nombres por multidifusión, UDP 5355) se envía a todos los vecinos y se queda con el primero que conteste; una oferta DHCP se acepta, normalmente, la primera que llega. El RFC de LLMNR advierte de que quien está en el mismo segmento puede falsificar una respuesta sin siquiera adivinar un identificador, porque la pregunta la oyen todos.

ATT&CK las cataloga como T1557.001 (envenenamiento de resolución de nombres) y T1557.003 (suplantación de DHCP). El daño suele venir después: el equipo engañado intenta conectarse al impostor y le entrega, por ejemplo, el material con el que se autentica. Para la defensa, la pregunta común es la misma: ¿quién debería estar contestando, y quién contestó?

En el laboratorio, el sensor del segmento vio llegar dos respuestas DNS a una misma consulta de agu-pc22 (identificador 41822). Las dos dicen venir del resolutor, 10.30.10.5, pero la dirección IP de origen es lo más fácil de escribir en un paquete. Fíjate en la MAC de origen de cada trama: el resolutor está en otra red, así que sus respuestas llegan a la oficina a través de la puerta de enlace y deberían traer la MAC de la puerta de enlace. Una respuesta con la MAC de un puesto de usuario no la mandó el resolutor.

El cliente usa la que llegó primero. Lo que importa para el informe es a dónde habría ido a parar el usuario.

DNSSEC añade al DNS autenticación del origen de los datos e integridad: la zona se firma y un resolutor que valida puede comprobar que lo recibido es lo que se firmó. Pero el estándar es explícito en lo que no hace: no da confidencialidad, no protege de la denegación de servicio y, en la práctica, solo sirve para las zonas que alguien firmó. Ni toca ARP, ni LLMNR, ni DHCP, y tampoco impide que alguien en el segmento intercepte tráfico.

La tabla de zonas del laboratorio dice cuáles de las que consulta Aguaclara están firmadas. Una respuesta falsa sobre una zona firmada se rechazaría en un resolutor que valida; sobre una zona sin firmar, no hay nada que comparar y la falsa pasa. El hallazgo correcto no es «activar DNSSEC y listo», sino decir exactamente a qué zona protege.

LLMNR y NetBIOS sobre TCP/IP existen para resolver nombres cuando el DNS no sabe. Y eso suele pasar con un error de tecleo. En el laboratorio, agu-pc22 pregunta por un nombre al DNS, que contesta que no existe, y un segundo después lo pregunta por multidifusión a todo el segmento. Contesta un puesto de usuario que no es el servidor de archivos.

Esa secuencia (fallo en DNS y pregunta a los vecinos con un nombre que no existe) es el rastro que una defensa debe saber leer. La fila de la impresora, en cambio, es una consulta que contesta su dueño y no es sospechosa.

La última pieza: dos ofertas a la misma petición DHCP, con la misma transacción. Una viene del servidor autorizado, agu-dns01; la otra, del puesto 10.30.20.71, que se ofrece como puerta de enlace y trae un DNS de fuera. Quien controla esos dos datos decide por dónde sale y a quién pregunta el cliente, que es mucho más que una dirección IP.

Una consulta que cruce las ofertas con la lista de servidores autorizados deja solo la que no debería existir. Anota qué DNS ofrece.