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.
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
Q1
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?
Vale, primero toca encontrar la consulta que originó todo. Filtro 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
Q2
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?
Toca identificar quién contestó a esa consulta broadcast. Filtro NBNS y reviso los paquetes posteriores buscando una IP que no pinta nada en el segmento.
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.
Clásico poisoning de NBT-NS: cero autenticación en el protocolo, así que cualquiera responde y la víctima se lo traga. La 192.168.232.215 no es un servidor legítimo — es el atacante.
Respuesta: 192.168.232.215
Q3
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?
Toca ver el alcance. Filtro todo el NBNS que pasó por 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).
Filtrando, la segunda víctima sale sola: 192.168.232.176. El atacante le metió respuestas falsas a consultas que no existían y la máquina picó.
Respuesta: 192.168.232.176
Q4
Sospechamos que cuentas de usuario han sido comprometidas. ¿Cuál es el nombre de usuario de la cuenta comprometida?
Ahora toca ver qué credenciales se mandaron al atacante. Aíslo todo el tráfico con destino a la rogue:
ip.dst==192.168.232.215
Aquí es donde el ataque da sus frutos. El poisoning redirige a la víctima al atacante, y como Windows autentica por NTLM en SMB, el hash viaja directamente al rogue.
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
Q5
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?
Ahora quiero el hostname de la máquina a la que llegó el atacante por SMB. Combinamos filtros para aislar SMB2 con destino a la 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
- 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.
- 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.
- 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.
- 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”