Seguridad en Sistemas Operativos Windows e Introducción al Software y Exploit Mimikatz, Parte I

Mimikatz es una aplicación Open Source escrita en C que permite extraer y guardar credenciales como pueden ser los Tickets que utiliza el Protocolo de Autenticación de Kerberos. Para saber más sobre la Seguridad de Windows sigue leyendo.

Un atacante utilizará Mimikatz con el propósito de robar nuestras credenciales e intentar escalar privilegios, aunque también puede ser utilizada en ciberseguridad como herramienta Pentesting para encontrar vulnerabilidades.

Para estar protegidos contra este Exploit además de tener un Sistema Operativo actualizado, es recomendable disponer de un buen EndPoint o Antivirus que lo detectará y eliminará.

Autenticación y Credenciales

Antes de comenzar a utilizar Mimikatz debemos entender cómo opera la seguridad en  Sistemas Operativos Windows. Para empezar tenemos que saber que las  credenciales en Sistemas Operativos Windows se almacenan de diferentes formas:

• En Bases de datos locales SAM (Security Account Manager) que administran y almacenan tanto cuentas de usuario como grupos de seguridad locales. Las claves de usuario están cifradas en formato Hash.
• Proceso LSASS (Local Security Authority Subsystem Service) que es un proceso de Windows que se encarga del cumplimiento de las Políticas de Seguridad del sistema, tanto para las cuentas locales y de dominio.
• LSA Secrets, es una bóveda que almacena datos importantes de LSA. Todos los datos sensibles de los usuarios son guardados en estos Secrets.
  • Son encriptados y almacenados en el registro de Windows en HKEY_LOCAL_MACHINE/Security/Policy/Secrets.
  • El directorio Policy contiene todos los datos necesarios para acceder y desencriptar estos Secrets.
• Bases de Datos de AD (Active Directory) en el fichero NTDS.dit que almacena datos importantes del Directorio Activo.
  • Incluye los hashes de las contraseñas de los usuarios.
  • Está localizado en el DC (Domain Controller) en el directorio %SystemRoot%\ntds\ 
• El Administrador de Credenciales (Credential Manager Store) que almacena credenciales web de Windows y otras aplicaciones.

Cómo funciona LSA

El proceso lsass.exe (Local Security Authority Subsystem Service) de Windows se encuentra en el directorio Windows\System32\ y es el responsable de:

• Imponer las Directivas de Seguridad del sistema.
• Verificar los inicios de sesión de Windows.
• Administrar cambios en contraseñas.
• Crear los llamados Tokens de acceso (Access Tokens).

Los identificadores de Seguridad (SID)

Los identificadores de Seguridad SID (Security Identifier) se utilizan para identificar de forma única Entidades de Seguridad, son de longitud variable y se almacenan en una Base de Datos. Estas entidades de seguridad pueden ser:

• Usuarios
• Grupos
• Máquinas
• Dominios
• Procesos
• Etc …

Cada vez que un usuario inicia sesión correctamente, LSA (Local Security Authority) genera un Token de Acceso que cotiene el SID del usuario, sus privilegios y los SID de los grupos a los que pertenece.

Si disponemos de un SID y no sabemos a quien o qué entidad corresponde, podemos utilizar la utilidad de Windows PsGetId que nos permite traducir los SID a su nombre real y viceversa. Funciona tanto para cuentas locales y de dominio, así como con nombres de máquinas.

Podemos descomponer un SID y sacar nuestras propias conclusiones sobre que significa cada parte que lo compone. Si requieres más información sobre las diferentes partes que componen un SID, puedes seguir este enlace:

• La S indica que la cadena corresponde a un SID.
• 1 es nivel de revisión del SID.
• 5  corresponde al identificador de autoridad (SECURITY_NT_AUTHORITY)
• 21 corresponde a SECURITY_NT_NON_UNIQUE que indica que el siguiente valor será el de un nombre del dominio.
• Los siguientes valores son subautoridades.
• 1001 equivale a un identificador relativo.

Una vez LSAS recupera el SID del usuario lo almacena en un Token de acceso (Access Token) cuyo objetivo de identificar al usuario en todas las interacciones posteriores que requieran un mínimo de seguridad en Windows.

Los Tokens de Acceso

Los Tokens de acceso son Objetos que contienen información sobre entidades, así como los privilegios del usuario al que están asociados. Por lo que cuando un proceso interactúa con otros objetos protegidos del sistema que requieren un nivel mínimo de seguridad, el sistema comprobará el Token de acceso, para determinar si el usuario dispone de privilegios suficientes.

• Si la cuenta del usuario es Local, LSA (Local Security Authority) verifica las credenciales del usuario en una Base de datos local llamada SAM (Security Account Manager) que almacena las contraseñas del usuario en formato hash.
• Si la cuenta del usuario es de Dominio (Active Directory) la autenticación se remite al Controlador de Dominio (Domain Controller) que se encargará de procesar la solicitud para autenticar al usuario.

Resumiendo… con cada sesión autenticada correctamente LSA (Local Security Authority) genera un Token de Acceso (Access Token), que podrá ser duplicado para utilizarse por otros procesos que necesiten unos requisitos mínimos de seguridad.

Cada Token de acceso debe contener un Authentication Id  (Logon ID) que identifica el origen de la sesión.

A continuación vamos a ver con detalle los 2 Protocolos de autenticación de Windows que pueden crear Tokens de acceso: NTLM y Kerberos.

El protocolo de autenticación NTLM

El Protocolo de autenticación NTLM (New Technology LAN Manager) permite autenticar a Usuarios y Equipos utilizando un mecanismo de desafío/respuesta, que indica a un Servidor o a un Controlador de Dominio (DC), que el usuario conoce la contraseña asociada a su cuenta:

1. Para empezar el cliente introduce sus credenciales.
2. El cliente establece la conexión con el servidor enviando un mensaje (NEGOTIATE_MESSAGE) indicando sus credenciales.
3. A continuación el servidor responde con un desafío (CHALLENGE_MESSAGE) que será utilizado para establecer la identidad del cliente.
4. El cliente responde al desafío (AUTHENTICATE_MESSAGE).
5. El servidor envía el Dominio, Usuario, el desafío y la respuesta al Controlador de Dominio.
6. El Controlador de Dominio (Domain Controller) comprueba la validez de la respuesta e informará al servidor.

Hoy en día se sigue utilizando la autenticación NTLM, pero esta tan sólo debería utilizarse para la autenticación de Windows con sistemas configurados como miembros de un Grupo de Trabajo.

Y aunque NTLM se puede utilizar para la autenticación de inicio de sesión local en Controladores de Dominio (DC) se recomienda utilizar el protocolo de  autenticación Kerberos recomendado en entornos de Active Directory.

¿Cómo podemos atacar el protocolo de autenticación NTLM?. Se puede realizar la extracción de Hashes de 2 formas diferentes: atacando directamente la Base de Datos local SAM almacenada en el disco del equipo o atacando el proceso LSASS, extrayendo las credenciales de la memoria:

• SAM (Security Accounts Manager): Cada ordenador que ejecuta un Sistema Operativo Windows dispone de su propio Dominio Local, que contiene una Base de Datos local con las cuentas de Usuario, Grupos y Políticas de Seguridad del equipo. Cada Objeto de esta Base de Datos SAM incluye la siguiente información:
  • SAM_ALIAS: Grupo local.
  • SAM_GROUP: Grupo local.
  • SAM_USER: Cuenta de Usuario.
  • SAM_DOMAIN: Dominio.
  • SAM_SERVER: Cuenta del ordenador.
• LSASS (Local Security Authority Subsystem Service): Asumiendo que tengamos acceso a la máquina y privilegios elevados podemos utilizar Mimikatz y el módulo Sekurlsa, que se encarga de extraer Passwords, Identificadores, códigos pin y tickets de la memoria. Este sería un ejemplo pero lo veremos con detalle más adelante en la Parte II de este tutorial:

Una gran desventaja de NTLM es que puede recibir tanto Relay como Replay Attacks , haciendo de este protocolo de autenticación, menos seguro que otros. En este tipo de ataques denominados man-in-de-middle, un atacante intercepta las comunicaciones de autenticación entre Cliente y Servidor:

1. La victima envía una petición para conectarse.
2. El atacante reenvía la petición al servidor objetivo.
3. A continuación el servidor envía el desafío para ser cifrado.
4. El atacante reenvía el mismo desafío.
5. La victima envía su respuesta con el desafío cifrado (con privilegios de administrador).
6. El atacante reenvía la respuesta de la victima.

El protocolo de autenticación Kerberos

El Protocolo de Autenticación Kerberos se encarga de identificar Usuarios y Equipos, proporcionando un método de autenticación mutua, donde tanto el cliente como el servidor tienen que verificar su identidad.

A diferencia de NTLM que puede recibir Relay/Replay Attacks, Kerberos protege los mensajes de autenticación transmitidos entre Cliente y Servidor.

Kerberos utiliza Tickets para llevar a cabo las tareas de autenticación cliente-servidor. Sus componentes más importantes son:

• KDC (Key Distribution Center), es un proceso de Kerberos, encargado de las tareas de autenticación (generalmente será el Controlador de Dominio). Dispone de una Base de Datos con las claves (Secrets) utilizadas por clientes y servidores registrados.
• KAS (Kerberos Authentication Service) aloja el KDC y se compone de:
  • AS (Authentication Service) es el Servicio de Autenticación que autentica al cliente y encargado de autorizar y denegar la autenticidad de los Tickets.
  • TGS (Ticket Granting Service) que se encarga de proporcionar los Tickets. Entre ellos está el TGT (Ticket Granting Ticket) que corresponde a un Ticket de autenticación de Usuario.

Un TGT (Ticket Granting Ticket) es la prueba de que un usuario se ha autenticado correctamente a través de un KDC y contiene:

• El ID del Usuario.
• La dirección de red del cliente.
• El periodo de validez del ticket.
• La clave de sesión TGS (Ticket Granting Service).

Pero … ¿Qué es un Ticket? Un Ticket (también llamado Service Ticket) es un mensaje encriptado que proporciona información del usuario, con acceso a una entidad o objeto. Los Tickets de Kerberos tendrán un periodo de validez y utilizan parámetros por lo que una vez expira el ticket, el usuario tendrá renovarlo o solicitar uno nuevo, para poder seguir comunicándose con el Servidor.

Kerberos requiere de una Base de Datos de cuentas como Servicio de Directorio, utilizado para intercambiar Tickets entre Clientes, Servidores y el KDC con el único fin de probar la identidad (autenticar) y proveer autorizaciones.

Veamos visualmente cómo funciona el mecanismo de autenticación mutua del protocolo de autenticación de Kerberos:

El flujo de todo el proceso de autenticación de Kerberos lo tenemos explicado con detalle a continuación:

1. El usuario introduce su nombre y clave de acceso en el equipo cliente.
2. El equipo del cliente encripta su clave (Secret) y transmite los datos al KDC.
3. El KDC verifica el usuario en su Base de Datos de Credenciales.
4. El KDC genera una clave simétrica encriptada, que será utilizada por el Cliente y el Servidor Kerberos. La encripta en forma de Hash con la clave del usuario y genera una marca de tiempo TGT.
5. A continuación el KDC transmite dicha clave encriptada y el TGT al cliente.
6. El cliente guarda el TGT para poder utilizarlo hasta que este expire y tendrá que desencriptar la clave simétrica utilizando el hash generado a partir de su clave.

Siempre que el cliente necesite acceder a un objeto o entidad, como puede ser un recurso, deberá solicitar un Ticket a través del Servidor Kerberos (KDC).

1. El cliente envía su TGT de vuelta al KDC con la solicitud de acceso al recurso.
2. EL KDC verifica si el TGT es válido y comprueba en sus ACL (Access Control List) si dispone de los privilegios necesarios para acceder a dicho recurso.
3. A continuación el KDC genera un TGS y se lo envía al cliente.
4. El Cliente envía el Ticket al servidor que hostea el recurso.
5. El Servidor que hostea el recurso verifica la validez del ticket con el KDC.
6. Una vez se verifica la identidad y autorización, el servidor abre una sesión con el cliente para que este pueda comenzar a comunicarse y transmitir datos.

Kerberos se distribuye bajo licencia MIT, para que todos aquellos que quieran estudiar su código puedan comprobar si este es de confianza.

Bibliografía

• CISSP (ISC) Certified Information Systems Security Professional Official Study Guide
• Security Identifier
• Entidades de Seguridad en Windows
• Introduction to Windows tokens for security practitioners
• What is NTDS.it