// Laboratorio de Forense de Red: PoisonedCredentials
// Envenenamiento LLMNR/NBT-NS, captura de credenciales y análisis SMB
// Dificultad: Easy
*DISCLAMER* -> Este writeup es con fines educativos y de práctica profesional. Las respuestas mostradas corresponden al laboratorio público de CyberDefenders. Las direcciones IP y artefactos pertenecen al escenario controlado del reto, no a infraestructura real en producción.
SERIE // CyberDefenders Labs #03
0x00 Introducción
Tercer post de la serie de laboratorios de CyberDefenders.
Esta vez nos metemos con PoisonedCredentials, un laboratorio de forense de red centrado en ataques de envenenamiento LLMNR y NBT-NS.
El equipo de seguridad de la organización ha detectado un aumento en la actividad sospechosa de red.
Existe la sospecha de que se están produciendo ataques de envenenamiento que explotan estos protocolos para interceptar tráfico y comprometer credenciales de usuario.
LLMNR y NBT-NS son protocolos diseñados para resolver nombres en redes locales cuando el DNS no está disponible.
El problema es que son inherentemente vulnerables: dependen de consultas broadcast y no tienen autenticación robusta.
Los atacantes explotan esto para posicionarse como man-in-the-middle, redirigir tráfico legítimo y capturar credenciales en hash.
Nuestra tarea: investigar los registros de red capturados con Wireshark, identificar la máquina maliciosa, descubrir el alcance del ataque, rastrear las cuentas comprometidas y determinar qué sistemas fueron accedidos.
0x01 El Escenario
| Elemento | Detalle |
|---|---|
| Tipo de ataque | Envenenamiento LLMNR / NBT-NS |
| Evidencia | Archivo .pcap (tráfico de red capturado) |
| Herramienta | Wireshark |
| Misión | Identificar máquina rogue, víctimas, credenciales comprometidas y sistemas accedidos |
0x02 Contexto Técnico
LLMNR (Link-Local Multicast Name Resolution) permite a los equipos de una red local resolver nombres a direcciones IP sin depender de un servidor DNS central.
Cuando un equipo no puede resolver un nombre de host, lanza una consulta broadcast a la red local.
NBT-NS (NetBIOS Name Service) funciona de manera similar, traduciendo nombres NetBIOS a direcciones IP.
Es un protocolo heredado del ecosistema Windows que sigue activo en muchas redes corporativas.
Cuando una máquina víctima no puede resolver un nombre de host lanza una consulta broadcast.
El atacante intercepta esa consulta y responde con su propia dirección IP, haciéndose pasar por el recurso legítimo.
La víctima, confiando en la respuesta, envía sus credenciales en hash al atacante, que puede descifrarlas offline.
0x03 Análisis
El atacante inició sus acciones aprovechando el tráfico de red benigno de máquinas legítimas. ¿Cuál es la consulta mal escrita específica realizada por la máquina 192.168.232.162?
Para encontrar la consulta que desencadenó todo, filtramos el tráfico LLMNR y NBNS desde la IP de la víctima en Wireshark:
llmnr and ip.src == 192.168.232.162
Tras aplicar el filtro, en los detalles del paquete, dentro del campo Queries, encontramos la consulta que desencadenó el ataque:
La máquina con IP 192.168.232.162 realizó una consulta NBNS broadcast (destino 192.168.235.255) intentando resolver el nombre FILESHAARE — un typo evidente de "FILESHARE". Esta consulta mal escrita fue precisamente lo que permitió al atacante responder de forma maliciosa.
Respuesta: FILESHAARE
Estamos investigando un incidente de seguridad de red. ¿Cuál es la dirección IP de la máquina que actúa como entidad rogue?
Para identificar la máquina rogue, necesitamos analizar quién respondió a la consulta broadcast mal escrita. Revisamos los paquetes posteriores a la consulta inicial buscando respuestas NBNS con direcciones IP que no correspondan a un servidor legítimo.
En el paquete 51, una respuesta NBNS se origina desde la dirección IP 192.168.232.215. Esta respuesta afirma resolver la consulta FILESHAARE<20>, lo que significa que esta máquina se está haciendo pasar por el host legítimo falsificando su identidad.
Este comportamiento es la firma de un ataque de envenenamiento LLMNR/NBT-NS. La máquina maliciosa responde a la consulta broadcast con una respuesta diseñada para redirigir el tráfico y capturar credenciales. La ausencia de autenticación en el protocolo NBNS hace posible este tipo de suplantación.
Respuesta: 192.168.232.215
Es esencial identificar todas las máquinas afectadas. ¿Cuál es la dirección IP de la segunda máquina que recibió respuestas envenenadas de la máquina rogue?
Para mapear el alcance del ataque, necesitamos identificar a todas las víctimas. Filtramos todo el tráfico NBNS asociado a la máquina rogue:
nbns.addr==192.168.232.215
Otra vía es ir a Statistics > Conversations y revisar la pestaña UDP, buscando entradas que involucren la IP envenenada pero excluyendo la primera víctima (192.168.232.162).
A partir de los resultados filtrados, la segunda máquina que recibió respuestas envenenadas se identifica por la dirección IP de destino 192.168.232.176. Las respuestas envenenadas intentan redirigir la actividad de red resolviendo falsamente consultas de nombres inexistentes, engañando a las máquinas legítimas para que interactúen con la máquina del atacante.
Respuesta: 192.168.232.176
Sospechamos que cuentas de usuario han sido comprometidas. ¿Cuál es el nombre de usuario de la cuenta comprometida?
Para determinar qué credenciales fueron interceptadas, analizamos el tráfico dirigido a la máquina rogue.
Primero aislamos todo el tráfico con destino a su IP:
ip.dst==192.168.232.215
El protocolo SMB (Server Message Block) es fundamental en este análisis. SMB facilita el intercambio de archivos, el acceso a recursos de red y la autenticación en entornos Windows.
Es ampliamente utilizado pero también frecuentemente explotado por atacantes debido a su integración con la autenticación NTLM (NT LAN Manager).
La máquina rogue aprovecha el envenenamiento para manipular las comunicaciones SMB, interceptando datos de autenticación.
También podemos usar el filtro ntlmssp.auth.username para localizar directamente los paquetes que contienen datos de autenticación NTLM.
En el paquete resaltado vemos una SMB2 Session Setup Response desde la máquina rogue.
El código de estado STATUS_MORE_PROCESSING_REQUIRED indica que el proceso de autenticación NTLM está en curso. Dentro de la carga del paquete, el protocolo NTLMSSP (NT LAN Manager Security Support Provider) revela el nombre de usuario janesmith, junto con el dominio cybercactus.local y el host WORKSTATION.
Respuesta: janesmith
Nuestro objetivo es comprender el alcance de las actividades del atacante. ¿Cuál es el nombre de host de la máquina a la que accedió el atacante a través de SMB?
Para encontrar el hostname de la máquina accedida, combinamos filtros para aislar tráfico SMB2 dirigido a la máquina rogue:
ip.dst==192.168.232.215 and smb2
También podemos usar ntlmssp.challenge.target_info para localizar paquetes relevantes directamente.
En la respuesta SMB2 Session Setup aparece un mensaje NTLMSSP Challenge como parte del proceso de autenticación NTLM.
Dentro de los detalles del paquete, el campo Target Info revela los atributos del sistema.
Específicamente, el DNS Computer Name aparece como AccountingPC.cybercactus.local, confirmando que el atacante accedió a esta máquina mediante el protocolo SMB utilizando las credenciales comprometidas.
Respuesta: AccountingPC
0x04 Resumen del Ataque
| Fase | Acción | Evidencia |
|---|---|---|
| Trigger | Víctima hace consulta broadcast con typo | FILESHAARE (192.168.232.162) |
| Poisoning | Máquina rogue responde a la consulta | 192.168.232.215 |
| Propagación | Segunda víctima recibe respuestas envenenadas | 192.168.232.176 |
| Credential Theft | Captura de autenticación NTLM vía SMB | janesmith @ cybercactus.local |
| Lateral Movement | Acceso a máquina vía SMB con credenciales robadas | AccountingPC |
0x05 Lecciones Aprendidas
Claves del laboratorio
1. Desactivar LLMNR y NBT-NS: Si no son estrictamente necesarios en tu entorno, desactívalos.
En la mayoría de redes corporativas modernas con DNS correctamente configurado, estos protocolos son un vector de ataque innecesario.
Se puede deshabilitar LLMNR via GPO y NBT-NS en la configuración de red de cada adaptador.
2. Las respuestas envenenadas son detectables.
Reglas de IDS/IPS que alerten sobre respuestas NBNS/LLMNR provenientes de IPs no autorizadas pueden revelar este tipo de ataques en tiempo real.
3. Configurar SMB Signing como obligatorio dificulta enormemente los ataques de relay, ya que el atacante no puede firmar los paquetes legítimamente sin las credenciales originales.
4.Si AccountingPC hubiera estado en un segmento de red separado con controles de acceso estrictos, el movimiento lateral del atacante habría sido mucho más difícil.
5. El ataque completo se desencadenó por una consulta mal escrita.
Esto demuestra que la seguridad no solo depende de la tecnología sino también de factores humanos.
La concienciación del usuario sigue siendo una capa de defensa crítica.
Los ataques de envenenamiento LLMNR/NBT-NS son de los más comunes en pentesting interno y siguen siendo efectivos en redes corporativas donde estos protocolos permanecen activos por defecto. Herramientas como Responder automatizan este proceso completamente.
[EOF] "A misspelled name, a poisoned response, a compromised network"