Hola, hoy terminatemos la seria de las notas sobre el protocolo NTLM:

• Entendiendo el protocolo NTLM: Auditor�a y restricci�n del uso [Parte1].
• Entendiendo el protocolo NTLM: Escenarios admitidos para restringir NTLM en un dominio [Parte2]
• Entendiendo el protocolo NTLM: Evaluaci�n de su entorno para la reducci�n de NTLM [Parte3]

Resumiendo un poco lo que vimos, podemos decir que es el protocolo NTLM se utiliza para la autenticacion de usuarios y computadoras, bas�ndose en un mecanismo�de pedido/respuesta�.�Esto implica que el usuario demuestre al servidor o controlador de dominio que conoce la contrase�a asociada con la cuenta, pero sin transmitirla a trav�s de la red.

Si bien a partir de Windows 2000, NTLM fue reemplazado por Kerberos como protocolo de autenticaci�n est�ndar para dominios de Active Directory (AD) y a pesar de las vulnerabilidades conocidas, las distintas versiones de NTLM todav�a est�n disponibles en los sistemas inform�ticos actuales por motivos de compatibilidad.�NTLMv2 tambi�n se sigue utilizando para inicio de sesi�n local, inicio de sesi�n de red para GRUPOS DE TRABAJO, algunos servidores http y tambi�n para inicio de sesi�n �nico (SSO).

NTLM no env�a contrase�as a trav�s de la red que puedan ser interceptadas, pero NTLMv1 es un protocolo de autenticaci�n muy d�bil seg�n los est�ndares actuales. Y aunque la v2 es m�s segura que la v1, todav�a est� muy lejos de su sucesor Kerberos.

Tipicos ataques de seguridad

Con la autenticaci�n NTLM, el hash de la contrase�a es un elemento crucial de la autenticaci�n.�Entonces, si un atacante descubre el nombre de usuario y el hash de la contrase�a, puede iniciar los procedimientos directamente con la autenticaci�n NTLM.�No es necesario conocer la contrase�a real. Esta t�cnica se conoce como�Pass the Hash�y existe desde hace m�s de 20 a�os.

Los nombres de usuario son bastante f�ciles de obtener desde el punto de vista del atacante, por ejemplo, sin cifrar en el tr�fico de la red.�Los hashes de contrase�as tambi�n son bastante f�ciles de obtener.�En los sistemas de usuario final, los hash de contrase�a se pueden encontrar en el archivo

C:\Windows\System32\config\SAM

El archivo SAM puede ser le�do por cualquier usuario con privilegios administrativos. Asimismo, los hashes de contrase�as tambi�n se almacenan en cach� en la memoria.�De ah� se pueden extraer con herramientas como�Mimikatz�.

En el lado del servidor, los hashes de contrase�as para los controladores de dominio se almacenan en el archivo

C:\Windows\ntds\ntds.dit

Estas ubicaciones son super conocidad y se pueden utilizar para realizar ataques de DC Sync.

Tambien podemos sufrir ataques de fuerza bruta, ataques en la retransmision del protocolo y tampoco soporta la utilizacion de doble factor de authenticacion, por lo que las desventajas son muchas.

Una de las�diferencias m�s importantes�entre NTLM y Kerberos es un proceso de autenticaci�n modificado. El proceso de autenticaci�n en s� ya no se ejecuta�como un pedido/respuesta de dos pasos�, sino que est� dise�ado para ser�de tres pasos. Asimismo, Kerberos tiene propiedades criptogr�ficas diferentes a las de NTLM.�La funci�n hash que utiliza NTLM para crear el hash de contrase�a ha sido reemplazada por una funci�n de cifrado. En resumen, Kerberos es el�protocolo claramente m�s seguro�.�Pero ni siquiera Kerberos est� completamente libre de problemas de seguridad.

Entonces que hacemos para asegurar nuestros ambientes? la recomendacion segun la documentacion es evaluar tu ambiente para minimizar el impacto, sobre todo en ambientes complejos donde tenemos varios servidores y servicios que pueden ser afectados.

Debemos utilizar la GPO Network security: Restrict NTLM: Audit NTLM authentication in this domain (). Cuando habilita esta pol�tica de auditor�a, funciona de la misma manera que�Seguridad de red: Restringir NTLM: autenticaci�n NTLM en esta�configuraci�n de pol�tica de dominio, pero en realidad no bloquea ning�n tr�fico.�Por lo tanto, puede usarlo de manera efectiva para comprender el tr�fico de autenticaci�n a sus controladores de dominio y cuando est� listo para bloquear ese tr�fico, puede habilitar Seguridad de red�: Restringir NTLM: Autenticaci�n NTLM en esta�configuraci�n de pol�tica de dominio y seleccionar�Denegar para cuentas de dominio. a servidores de dominio�,�Denegar para servidores de dominio�o�Denegar para cuentas de dominio�.

Tambien se recomienda realizar un hardening de los clientes, para extremar la seguridad de los equipos, y si es posible a nivel de servidores deshabilitarse por completo los protocolos NTLMv1 y NTLMv2 mediante la pol�tica de grupo.�Es posible configurar una lista de excepciones si las aplicaciones no se pueden actualizar y a�n as� se requiere NTLM.

Para deshabilitarlo por politica

• Ejecutamos el comando �gpmc.msc��para abri la consola �Group Policy Management Editor�.

1. Una vez iniciada, vamos a la ubicacion �Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options�.

• Buscamos la entrada �Network Security: LAN Manager authentication level��y seleccionamos �Send NTLMv2 response only. Refuse LM & NTLM�

Espero les sirva y les aclare el panorama, cualquier cosa pregunten que les ire contestando. Saludos.