Hoy vamos a hablar de algunos aspectos de los mecanismos de autenticación básicos de los sistemas Microsoft que por comentarios y experiencia sospecho que no todo el mundo conoce.

Es importante conocer en profundidad los sistemas que manejamos, porque si todo va bien, es muy sencillo administrar un “guindo” pero si algún día tienes problemas, o sufres un incidente o tienes que estudiar si estás sufriendo un incidente… conocer estos términos te será fácil.

Vamos a empezar con el proceso de login, el denominado login interactivo. Es el que se produce cuando nos “sentamos” delante del equipo, cuando pulsamos Ctrl+Alt+Supr. Dentro del login interactivo podemos incluir el que realizamos por RDP, podemos imaginar el RDP como un “túnel” en el que nos sitúa delante del pc. Realmente podemos denominarlo login remoto interactivo.

Cuando realizamos este login, estamos accediendo a la SAM (Security Account Manager) o a un dominio. Es muy importante entender esto. Si usamos un pc de empresa por ejemplo, podemos autenticarnos contra el propio pc, o contra el dominio. Esto se puede modificar, ya lo sabemos, pero es importante entender estos conceptos. Si haces login en la SAM, en local, si entras a una carpeta de red de un pc de dominio, tendrás que autenticarte en el equipo destino. Otro tipo de login interactivo es el que realizamos con una tarjeta, una smart card.

El siguiente grupo de logins es el denominado de red. El que realizas cuando te conectas a un recurso de red, como pueda ser una carpeta compartida o una GPO. Otro tipo de login puede ser como proceso Batch y como servicio.

Otro tipo de login muy interesante es el de la cache. Imagina un portátil corporativo que se inicia en casa del empleado sin haber levantado VPN contra la empresa. Usa las credenciales almacenadas en el equipo, por defecto 10 veces máximo, para autenticarse dentro de un entorno de dominio. Este comportamiento se debe cambiar, si los procesos de la empresa lo permiten, para evitar esta funcionalidad. Imagina un caso muy sencillo: se resetea la clave porque se ha comprometido. El atacante tendría 10 logins “locales” en el equipo hasta que sea obligado a autenticarse contra el DC con la nueva contraseña.

Otro tipo de login, denominada 10 es el que se produce cuando ejecutamos Runas/netonly. Con este parámetro el equipo se ejecutará en local con el usuario que levanta la consola, es decir, el que se logueo en el sistema local, pero si el programa accede a la red, usará el equipo usuario proporcionado con el comando runas.

Una vez explicados los logins, vamos a hablar de los dos grandes proveedores de autenticación en los sistemas Microsoft, NTLM y KERBEROS.

Imagina que un equipo cliente se conecta a un servidor de archivos. Mediante el handshake NTLM se establece una conexión entre PC y cliente, con un desafío o challenge que se cifra con el hash de la contraseña del archivo. El servidor de archivos comprueba la contraseña del cliente consultando al controlador de dominio, quien es el jefazo de la organización y conoce las claves de los usuarios (el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector)

El proceso con Kerberos es algo distinto, ya que el el servidor de archivos no se conecta al DC. El cliente solicita al DC un ticket de servicio para conectarse a un servidor destino, el DC le concede el ticket (el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector) y cuando el cliente se quiere conectar con el dichoso fileserver, le enseña ese ticket.

Voy a poner el ejemplo del parque de atracciones. Una persona entra al parque, y en la caseta le dan una pulsera. Cuando vas a la atracción, enseñas la pulsera. No va el tipo de la atracción a preguntar al de la caseta si realmente esa pulsera es válida. Entiende que si.

Un apunte sobre esta diferencia, cuando hacemos “barra barra” para conectarnos a un recurso de red, si usamos IP en vez de Nombre, estaremos usando NTLM en vez de Kerberos. Existen ataques muy conocidos para NTLM basados en Man-in-the-Middle por lo que es una buena práctica generalizada usar siempre nombres DNS, no direcciones IP.

Tenemos otros proveedores de autenticación en los sistemas Microsoft, estos se denominan SSPI (Security Support Provider Interface) y aquí tienes todos los disponibles.

Esta imagen es la típica para explicar qué son estos interfaces.

Aquí aparece el famoso LSASS, el sistema local de autenticación, el encargado de recibir las credenciales del login y según el caso, equipo local (SAM) o dominio (DC) comprobar las credenciales. Otra función básicas del sistema LSA es proporcionar la “cache” de autenticación, es decir, lo que proporciona el Single Sign On del cliente.

De esta manera, las credenciales “suelen” cachearse en memoria, en ese proceso. Haciendo Debug a ese proceso conseguimos obtener las credenciales en memoria con herramientas como Mimikatz.

Una de las guías que más mecanismos de protección presenta es esta del SANS.