Por Ícaro César: En este informe seguirás una Investigación de Seguridad - Emulación y Detección, con la técnica de LLMNR(Link Local Multicast Name Resolution) y NBT-NS(Servicio de Nombres NetBIOS), Spoofing e Envenenamientoque son dos métodos muy eficaces para capturar NTLMv1, NTLMv2 o LM(Lan Manager). Este tipo de ataque se clasifica como Man-in-the-Middle.
En primer lugar, tenemos que entender: ¿qué es LLMNR y NBT-NS Spoofing/Poisoning? LLMNR es el sucesor de NBT-NS y se introdujo en el ecosistema Windows a partir de Windows Vista.
Tanto LLMNR como NBT-NS permiten que las máquinas de una red Windows se encuentren entre sí, y es esencialmente un protocolo "alternativo" utilizado para la resolución de nombres de host en una red cuando falla la resolución de nombres de host a través de DNS.
Este proceso de hosts que revierten el flujo a transmisiones LLMNR o NBT-NS para encontrar hosts concretos en la red tiene como resultado el envío de hashes NTLMv1/v2 a través de la red, lo que ofrece a un adversario en el mismo segmento de red la oportunidad de interceptar y reproducir ataques como Pass-The-Hash en otros dispositivos, o bien, crackear los hashes interceptados fuera de línea.
Un escenario típico para atacar las transmisiones LLMNR o NBT-NS, estas funcionan de la siguiente manera:
1. El host A solicita un recurso compartido SMB en la red identificado como "intranet"pero en lugar de escribir "intranet"escribe por error "intrnet".
2. Como "intrnet" no puede ser resuelto por DNS, ya que se trata de un host y recurso compartido que no existe, el Host A envía de nuevo un mensaje de difusión LLMNR o NBT-NS, solicitando a todo el segmento de red la dirección IP del host/compartido"intrnet", previamente solicitada de forma errónea.
3. El Adversario(Host B) responde a este mensaje de difusión afirmando ser el sistema que contiene la "intrnet".
4. El Host A, al recibir la respuesta del Adversario(Host B), envía al Host B (el adversario) su nombre de usuario y el hash NTLMv1 o v2 para que el Host B pueda realizar el proceso de validación de autorización de acceso al"recurso solicitado".
Técnica de emulación - T1557.001
Para llevar a cabo los Procedimientos de esta Técnica, podemos utilizar las herramientas Respuestadesarrollada en Pythono la herramienta Inveighdesarrollada en Powershell. En esta emulación, utilizamos la herramienta Responder para ejecutar este procedimiento, pero independientemente de la herramienta utilizada para ejecutar los procedimientos, el ataque LLMNR y NBT-NS Poisoning/Spoofing sigue teniendo el mismo resultado.
El laboratorio en el que realizaremos la emulación de esta técnica contiene la siguiente topología:
El Responder contiene un archivo de configuración que nos permite configurar qué servicios se ejecutarán para realizar la captura, Spoofing y Poisoning de los paquetes traficados en ese segmento de red. Esto permite al atacante cargar exactamente los servicios que necesita para ejecutar el ataque Man-in-the-Middle.
Al ejecutar Responder en la red (como se ilustra en la imagen inferior), el adversario ejecutará servidores de varios servicios especificados en el archivo de configuración, que escucharán determinadas peticiones de difusión en la red para luego poder responder y hacerse pasar por el recurso de dicha petición con el fin de capturar información relativa a los usuarios. En el contexto de nuestra emulación, el objetivo del adversario es capturar hash hash NTLMv2 de los usuarios.
Como se ilustra en las imágenes anteriores, el adversario ha ejecutado Responder en su dispositivo, en el que ha cargado varios servidores, incluido un servidor SMB, y envenenadores que"envenenarán" los paquetes de los protocolos indicados en la imagen anterior.
Ejecutando un simple Responder, el adversario ahora sólo necesita esperar a que algún usuario escriba un nombre de host/sharing erróneo para que el dispositivo del usuario envíe broadcasts LLMNR y/o NBT-NS, con el fin de encontrar ese host/sharing. A continuación, el adversario que escucha el tráfico de difusión capturará este paquete y responderá a él, con el fin de pasar él mismo del host/sharing solicitado, y finalmente capturar el hash del usuario.
Otra forma de ejecutar esta Técnica sería mediante el desarrollo de una campaña de phishing por parte del adversario, en la que puede inducir al usuario a hacer clic en un enlace que puede abrir un recurso compartido inexistente en la red, o ejecutar código malicioso a través de un documento para que el dispositivo del usuario envíe difusiones LLMNR y NBT-NS a través del segmento de red.
En nuestro caso, la adquisición del hash se debió a un error tipográfico del usuario.
En la imagen anterior, podemos ver que hay un recurso compartido activo en DC01 al que se puede acceder a través de '{DC01\Production}'.
Por falta de atención, el usuario para acceder a este recurso compartido tecleó en su Explorador de Windows sólo 's\Production\'. Este simple error proporcionó al adversario su hash NTLMv2.
A partir de este momento, el oponente puede intentar realizar hash cracking offline, o realizar procedimientos de Técnica de Movimiento Lateral como Pasar el hashdonde el adversario intentará realizar autenticaciones en otros dispositivos, utilizando el hash capturado.
Detección de la ejecución de la técnica
La técnica que estamos abordando es extremadamente compleja de detectar a través de Event IDs, ya que teóricamente se trata de un comportamiento normal de la red, siendo el adversario el que subvierte su funcionamiento para conseguir sus objetivos.
En este tema, abordaremos las soluciones de detección, demostrando la importancia de la captura de paquetes, y la detección a través de la Caza pro activa, con el fin de encontrar dispositivos que estén ejecutando Servidores con Servicios Falsos para capturar información crítica de los usuarios.
NOTA: Este ejercicio de detección y caza también se realizó en la misma infraestructura de laboratorio ilustrada anteriormente.
Captura de paquetes
La captura de paquetes es importante una vez que nos permite identificar el comportamiento de la ejecución de esta Técnica, analizando las peticiones DNS y, durante el fallo de resolución de nombres, el envío de broadcast LLMNR al segmento de red, lo que consecuentemente nos lleva a la respuesta del adversario.
A continuación podemos observar el comportamiento del intento de resolución de nombre para el host/recurso\\Production\, solicitado accidentalmente por el usuario. Como en la imagen anterior, podemos identificar que él intenta hacer la resolución a través de DNS y, como este host/recurso no existe, el dispositivo envía un broadcast LLMNR para el segmento de red, solicitando que el host/recurso responda.
Es entonces cuando entra en juego nuestro adversario. Al recibir el broadcast (por estar en el mismo segmento de red), podemos observar en la imagen superior que responde al del dispositivo del usuario y, justo después de su respuesta, éste intenta una conexión a través del puerto 445 (SMB).
En la imagen superior, vemos la segunda fase de la ejecución de esta técnica. Podemos observar que, después de que el adversario responda al broadcast, se inicia una negociación a través del protocolo SMB, donde el adversario informa al dispositivo del usuario que necesitará un NTLM Challenge para que el dispositivo de usuario pueda acceder al recurso solicitado. Al recibir este Desafío NTLMel usuario envía su hash al host de destino para validar si el usuario está autorizado a acceder al recurso solicitado.
Tras recibir el hash del usuario, el adversario informa de que el usuario no tiene permiso para acceder al recurso y, a continuación, finaliza la conexión.
Para el usuario, esto parece un inconveniente menor, pero acaba de entregar sus credenciales a su oponente.
Posible detección mediante captura de paquetes
Para crear detecciones para esta técnica utilizando la captura de paquetes, su SIEM debe estar habilitado primero para realizar este tipo de actividad. También debe ser consciente de qué dispositivos tiene en su infraestructura, para poder identificar cuándo un dispositivo responde a una solicitud de un recurso que no existe.
Sugerimos que la detección se realice analizando el proceso no resuelto a través de DNS, siendo seguido por el envío de LLMNR broadcast al segmento de red y luego detectando el dispositivo que responde a este broadcast.
Si el servidor DNS no realizó la resolución de nombres para un dispositivo que aloja un recurso compartido en la red, es porque no debería existir o responder de otra manera. Por lo tanto, el análisis para desarrollar la detección debe centrarse en este aspecto del ataque.
Conveigh - herramienta de caza de amenazas
Si no dispone de la infraestructura necesaria para realizar capturas de paquetes grandes, o si el Hunter desea adoptar un enfoque más proactivo durante su proceso de validación de hipótesis, la solución Conveigh es una gran compra para detectar dispositivos que alojan servidores con servicios falsos en la red, con el fin de capturar hashes de tantos usuarios como sea posible.
A continuación, vamos a visualizar cómo esta herramienta puede ayudarnos a encontrar al adversario que realiza la Técnica en su infraestructura.
Hunter crea la hipótesis de que un adversario puede estar realizando la técnica de Request Poisoning y Spoofing LLMNR y/o NBT-NS, y el analista puede utilizar herramientas diseñadas para enviar peticiones SOLICITUDES LLMNR y/o SOLICITUDES NBT-NS peticiones.
Este es un ejemplo de uso de la herramienta Conveigh. Sin embargo, la misma herramienta puede ser utilizada en varios contextos como durante la fase de Identificación y Análisis en una Respuesta a Incidentes, o la ejecución periódica de esta herramienta en un dispositivo que se encuentre en un punto estratégico de la red, con su tarjeta de red en modo promiscuo, ya sea para realizar captura de paquetes, o bien, para ejecutar herramientas como Conveigh para enviar peticiones falsas para ese segmento de red, y luego realizar el registro de logs para su futuro análisis o reenvío a un Servidor de Logs.
Para poner en marcha Conveigh, primero debemos seguir algunos procedimientos:
- Ejecute Powershell como Administrador;
- Habilitar la ejecución de scripts en Powershell, utilizando las opciones '-ep bypass';
- Importe el módulo Conveigh, en el contexto de la sesión Powershell;
- Ejecuta Conveigh mediante el comando 'Invoke-Conveigh ' sin parámetros, por defecto.
En la siguiente imagen, podemos observar la ejecución de los procedimientos detallados anteriormente, y en consecuencia la detección de nuestro adversario identificado con la dirección IP 10.0.0.107.
A continuación podemos ver que el adversario recibió y respondió a las falsas peticiones LLMNR y NBT-NS, enviadas por Conveigh, denunciando su presencia en la infraestructura.
Mitigación
Las mitigaciones para la ejecución de la Técnica T1557. 001 se basan en deshabilitar características de Windowsy en la adquisición de software de seguridad para ordenadores de sobremesa que realicen inspección de ataques a nivel de paquetes. A continuación, se presentan nuestras sugerencias de mitigación:
- Desactive LLMNR y NetBIOS en la configuración de seguridad del equipo local o mediante una política de grupo si no es necesario en un entorno.
- Activar Firma SMB para detener los ataques de retransmisión NTLMv2 (Pass-The-Hash, retransmisión SMB etc).
- Adquisición e implantación de software de seguridad para ordenadores de sobremesa, con el fin de bloquear el tráfico LLMNR/tráfico NetBIOS.
- Llevar a cabo una revisión relativa a la segmentación de la red puede ser útil para aislar los dispositivos de infraestructuras críticas y los dispositivos que no requieren un amplio acceso a la red. Esto puede mitigar, o al menos aliviar, los ataques Man-in-the-Middle.
- También es posible que un EDR detecte la presencia de software conocido como Responder. Es importante crear políticas de bloqueo de hashes de herramientas conocidas.
Referencias
- Conveigh: https://github.com/Kevin-Robertson/Conveigh
- Pirámide del dolor: http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
- Envenenamiento LLMNR/NBT-NS y retransmisión SMB: https://attack.mitre.org/techniques/T1557/001/
- Kit de herramientas de respuesta: https://github.com/lgandx/Responder
- Resolución de nombres de multidifusión local de enlace: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e
- Firma SMB: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
- Wireshark: https://www.wireshark.org/