3 feb 2020

NTLMv2 Hash Grabbing via Forced Authentication

Por el 3 feb 2020 con 0 comentarios
Buenos días a todos, hoy voy a hablaros de una de las técnicas más eficientes de compromiso con las que contamos nada más empezar una auditoría interna, y cuya magia comienza con la herramienta Responder. Responder se aprovecha del comportamiento de los protocolos LLMNR y NBT-NS en redes Windows para capturar hashes NTLMv2 (Net-NTLMv2), que posteriormente puedan ser atacados con hashcat. A partir de este momento, todo dependerá de lo débiles que sean las contraseñas de los usuarios, pero desgraciadamente lo habitual es conseguir relativamente rápido credenciales en claro que permiten escalar privilegios con gran facilidad.


Sin embargo, a veces podemos encontrar con redes en las que estos protocolos han sido deshabilitados, o simplemente, estamos en un proyecto en el que no queremos generar tanto ruido en la red. En estos casos, es interesante conocer otros métodos a través de los cuales podemos forzar a los usuarios a enviarnos sus hashes NTLMv2, y uno de los más interesantes es el uso de ficheros .lnk maliciosos. 

Los ficheros de enlace .lnk pueden ser modificados para que el icono del acceso directo cargue desde un recurso de la red. Con tan sólo ir a propiedades del acceso directo, cambiar el icono, y elegir el recurso de red en el que vamos a servir el icono es suficiente.


En el otro lado, debemos tener a la escucha el smbserver de Impacket, listo para capturar hashes.


Una vez que tengamos preparado el entorno, sólo tenemos que dejar el fichero modificado en una carpeta de red utilizada por los usuarios. Cuantos más usuarios tenga esa carpeta, más probable será que capturemos hashes, por lo que las carpetas públicas suelen ser buen sitio para comenzar el proceso.


En el mismo instante en que cualquier usuario abra esa carpeta, su navegador de Windows intentará cargar auomáticamente el icono del enlace desde nuestro recurso, enviándonos así su hash de usuario. 


Según alcancemos nuevos hashes y estos vayan cayendo en nuestra instancia de Hashcat, probablemente conseguiremos permisos sobre nuevas carpetas de red, momento que deberíamos aprovechar para depositar nuevos ficheros con el objetivo de alcanzar permisos sobre la mayor cantidad de recursos. 

Recordad que hoy en día, éste y otros tantos ataques siguen funcionando porque seguimos confiando incorrectamente en todo lo que está dentro de nuestro perímetro de red. La realidad es que deberíamos ser tan restrictivos como el negocio nos lo permita, y si la red y funcionalidades están correctamente implementadas, no existe ninguna necesidad de negocio real que requiera que los clientes se comuniquen entre sí directamente. Ningún cliente debería poder comunicarse con cualquier otro cliente, aún estando en la misma red. Por tanto, si todo tráfico entre clientes estuviese restringido, este tipo de ataques (y muchísimos otros) no sería posible.
No querría cerrar este post sin recordaros que esta técnica, clasificada como Forced Authentication en la matriz ATT&CK del MITRE, y que en este post hemos orientado a auditorías internas, ha sido utilizada numerosas veces para conseguir que los hashes atraviesen el perímetro hasta un recurso externo. Es decir, el recurso contra el que forzamos la autenticación podría estar perfectamente expuesto en Internet. Una vez obtenidas las credenciales válidas, estas podrán ser probadas en puntos de acceso remoto, como conexiones VPN o sobre Office 365, aunque como siempre exigimos doble factor de autenticación, el atacante no tendrá ninguna posibilidad, ¿verdad? ;-) En fin, por este motivo, este tipo de tráfico jamás debería atravesar nuestros sistemas perimetrales de red.

Y para terminar, una última recomendación. Si las contraseñas de los usuarios son realmente largas y seguras, no habrá diccionario ni fuerza bruta que sirva para obtener credenciales, haciendo que esta técnica y muchas otras queden obsoletas. Pero si seguimos utilizando contraseñas débiles, incluso para cuentas privilegiadas, los malos seguirán haciéndose dueños y señores del dominio en el primer día en que pongan un pie en vuestra oficina...

¡A disfrutar!
      editar

0 comentarios:

Publicar un comentario

< >