Instalar y configurar Microsoft LAPS para evitar movimientos laterales (Local Administrator Password Solution)

Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. 

Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones

En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local).

Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH).

Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. 

En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos.

Características de LAPS

LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.

• Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS.
• Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory.
• Las contraseñas de los administradores locales son únicas en cada máquina.
• Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx).
• Transmite las contraseñas al cliente de manera segura y cifrada.
• Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas.
• Dispone de sus propios ID de eventos para su análisis en auditorías.

Instalación de LAPS

Instalador de LAPS (Local Administrator Password Solution).

• https://www.microsoft.com/en-us/download/details.aspx?id=46899

Documentación oficial LAPS: https://download.microsoft.com/download/C/7/A/C7AAD914-A8A6-4904-88A1-29E657445D03/LAPS_OperationsGuide.docx

En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo.

GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado.

Figura 1: Instalar características para la gestión LAPS.

Figura 2: LAPS instalado.

Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS.

Import-Module AdmPwd.ps
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -Identity "<OU_AD>"

Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD.

El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada.

Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo.

Get-Command -Module AdmPwd.ps

Figura 4: Ver todos los cmdlets disponibles de un módulo.

Configuración GPO LAPS en Active Directory

Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración.

Computer Configuration > Polices > Administrative Templates > LAPS

Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración.

Figura 5: Crear y configurar GPO LAPS.

Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO

Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada.

La operativa de despliegue dependerá de la herramienta que se estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc.

msiexec /i <PATH>\LAPS.x64.msi /quiet

msiexec /i <PATH>\LAPS.x86.msi /quiet

Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO.

Computer Configuration > Policies > Software Settings > Software installation

Se indica la ruta donde está el instalador, el tipo de deployment será "Assigned" (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE).

Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. 

Funcionamiento y administración de LAPS

En los objetos tipo "Computer" de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: 

• ms-Mcs-AdmPwd: Almacena la password local del equipo.
• ms-Mcs-AdmPwdExpirationTime: Tiempo en la que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO.

A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos como se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc).

Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria.

LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente).

Otra forma de visualizar la passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS.

Get-AdmPwdPassword <HOSTNAME> | fl

Get-AdmPwdPassword <HOSTNAME>.Password

Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD.

También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell.

Reset-AdmPwdPassword -ComputerName:<HOSTNAME>

Establecer permisos específicos según roles (RBAC)

Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. 

En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular.

En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo "LAPS_R". Es posible conceder estos permisos de dos modos: 

Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU.

Set-AdmPwdReadPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Solo_Lectura>"

Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU.

Find-AdmPwdExtendedRights -Identity "<OU_AD>"

Figura 9: Establecer un grupo de permiso de lectura para LAPS. 

La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs "Read ms-Mcs-AdmPwd" y "Read ms-Mcs-AdmPwdExpirationTime".

Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD.

En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet.

Set-AdmPwdResetPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Lectura_Escritura>"

Comprobar los permisos establecidos

Para comprobar de los permisos asignados anteriormente, el usuario de dominio "user2" no forma parte del grupo "LAPS_R" por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo "PC10D2".

Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD.

Para cambiar esto y conceder permisos de lectura. Se asigna el usuario "user2" al grupo "LAPS_R" de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. 

Figura 12: Comprobación de lectura correcta en el atributo de password de AD

Auditoría de eventos LAPS

La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. 

Set-AdmPwdAuditing -OrgUnit: <OU_AD> -AuditedPrincipals: <GRUPO/USUARIO>

Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio.

Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña.

Saludos!

Hydra, Medusa y Ncrack: Password cracking a servicios por fuerza bruta en profundidad y en anchura (Password spraying)

THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.

Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio.

nmap -p 21 10.0.0.16      # Windows 7 servicio FTP
nmap -p 3389 10.0.0.16    # Windows 7 servicio RDP
nmap -p 445 10.0.0.16     # Windows 7 servicio SMB/CIFS
nmap -p 22 10.0.0.40      # Linux servicio SSH

Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB.

THC-Hydra

Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos comprometer mediante un intento de autenticación de credenciales.

Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas.

Principalmente se pueden definir 3 tipos de ataques:

• Fuerza bruta por diccionario con múltiples usuarios y passwords
• Fuerza bruta en profundidad
• Fuerza bruta en anchura o Password spraying

Fuerza bruta por diccionario con múltiples usuarios y passwords

Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros "users" y "wordlist" respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP.

hydra -L users -P wordlist -vV 10.0.0.16 ftp

• -L: Fichero que contiene la lista de usuarios.
• -P: Fichero que contiene la lista de passwords.
• -v: Modo verbose
• -V: Muestra el intento por cada login+pass
• 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio.

El usuario "ventas" y la password "Pa$$w0rd123" serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas.

Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP.

Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario "luis" y su password en el servidor FTP remoto.

Figura 3: Log en el servidor FTP del intento de autenticación.  

Fuerza bruta en profundidad

Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata utilizar muchas contraseñas para una sola cuenta de usuario.

Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada "maria" y probar un wordlist con varias contraseñas posibles.

hydra -l maria -P wordlist -vV 10.0.0.16 rdp

• -l: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. 

Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP.

Al igual que el servicio anterior RDP también dejará un evento registrado en equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como que usuario intentó autenticarse.

Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP.

Fuerza bruta en anchura o Password spraying

Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario.

Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. 

hydra -L users -p M4ria.12 -vV 10.0.0.16 smb

• -L: Fichero de lista de usuarios.
• -p: Contraseña única.

Haciendo referencia a un fichero llamado "users" que contiene una lista de usuarios se le especifica una misma contraseña única.

Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB.

Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. 

Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB.

En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula.

Fuerza bruta en servicios web como Facebook o Instagram

Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques.

Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple "ping facebook.com" o "ping insgram.com" obtendremos la IP en ese momento.

Para protocolo HTTPS puerto 443 (https-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 443 -f https-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 443 -f https-get /accounts/login/

Para protocolo HTTP puerto 80 (http-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 80 -f http-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 80 -f http-get /accounts/login/ 

Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram.

Medusa

Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. 

Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos a parte de los que trae por defecto. 

Estos módulos están disponibles en el path.

/usr/lib/x86_64-linux-gnu/medusa/modules

Repositorio: https://github.com/jmk-foofus/medusa

Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords.

medusa -U users -P wordlist -h 10.0.0.40 -M ssh

• -U: Fichero de lista de usuarios
• -P: Fichero de lista de contraseñas
• -h: Host remoto
• -M: Tipo de módulo.

En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. 

Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH.

Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación.

Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH.

Ncrack

Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap. 

• Manual de referencia: https://nmap.org/ncrack/man.html
• Repositorio: https://github.com/nmap/ncrack

Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas.

ncrack -p 22 --user pepe -P wordlist 10.0.0.40

• -p: Puerto estándar usando por el servicio.
• --user: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa como en un primer intento con el usuario juan no fue posible realizar la conexión con el usuario juan pero si con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos.

Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. 

Saludos!

Password cracking en hashes Linux (John The Ripper y Hashcat)

En otro artículo comentara el proceso y técnicas para realizar Passwords cracking de hashes NTLM ntds.dit de Active Directory en sistemas Windows.

En esta ocasión para poder llevar a cabo un ataque por fuerza bruta, diccionario o Rainbow tables a los hashes de contraseñas de sistemas Linux. Es necesario obtener un acceso root para copiar o volcar el contenido de los ficheros /etc/passwd y /etc/shadow.

Si tenemos acceso físico a la máquina o un entorno de hipervisor donde podemos elevarnos a root abriendo una terminal usando Grub, explotar una vulnerabilidad que nos permita conseguir acceso con root o en una fase de post-explotación crear un usuario y hacerlo miembro del grupo sudo o colocarlo en /etc/sudoers.

Extracción de los ficheros /etc/passwd y /etc/shadow

Una vez accedido al sistema como root. Podemos realizar la extracción de los ficheros /etc/passwd y /etc/shadow. Podríamos copiarlos a una unidad externa USB.

fdisk -l                           # Vemos los discos conectados al sistema

mkdir /mnt/usb                     # Creamos directorio para montar la unidad USB

mount -t vfat /dev/sda1 /mnt/usb/    # Montamos la unidad USB

df -h                             # Nos aseguramos de que está montado

cp /etc/passwd /mnt/usb/passwd.txt   # Copia del fichero /etc/passwd

cp /etc/shadow /mnt/usb/shadow.txt   # Copia del fichero /etc/shadow

umount /mnt/usb                    # Desmontamos la unidad USB

Si en el momento de desmontar la unidad USB nos muestra un mensaje del tipo "umount: /mnt/usb: device is busy". Podemos ver que proceso está siendo usado para /mnt/usb, finalizarlo e intentar desmontar de nuevamente la unidad.

fuser -vm /mnt/usb # Ver los procesos existentes.

fuser -k /mnt/usb # Matar los procesos existentes.

umount /mnt/usb # Desmontar la unidad (forzar con el argumento -l).

unshadow: Combinar los ficheros passwd y shadow

Una vez conseguidos ambos ficheros y volcados en una máquina controlada y aislada sin riesgo a ser bloqueados o detectados, podemos tomarnos más tiempo para el proceso de descifrado de passwords. 

# tail -n 3 /etc/passwd

pepe:x:1005:1005::/home/pepe:/bin/bash

maria:x:1006:1006::/home/maria:/bin/bash

admin:x:1007:1007::/home/admin:/bin/bash

# tail -n 3 /etc/shadow

pepe:$6$yQVL/XM8/ZZ9S2IR$yOiJozomFYVYkdeOiXO7OGrceqiVdc6aBeb9yO4QnW.DiQQf9yEBKtm8J4F0Vu2JDXwIJtTKWfUyqMoqKqDNv/:18420:0:99999:7:::

maria:$6$2t4URKFkY/8Maj.I$mo2yfY0iAMXE60qWxiuKwXMOhexJiPIHYPVL6A7iBNBqV7H5IRLySeTc6dqREkBSflbjuQJlZO2tXEFXYidkK/:18420:0:99999:7:::

admin:$6$0tr5dcVdjueqvQna$LQu.ul4LmYbaNG8/lnx7LBwlW5RxFBEUqjE.sLRlYHeeGkKzz5TZHZ5foe.HEW2hrjNw0Q3sxTMRHFkYmp9uN0:18419:0:99999:7:::

Debemos fusionarlos en un mismo fichero. Este fichero será el que le pasaremos a las herramientas de cracking para el descifrado de passwords.

Para combinar el fichero /etc/passwd y /etc/shadow usamos el comando unshadow.

unshadow passwd.txt shadow.txt > passwords

Password cracking con John The Ripper

John The Ripper es una de las herramientas más populares usada para el cracking de contraseñas.

Con el fichero único creado anteriormente. Sin indicar ningún diccionario previamente, con John podemos realizar un ataque por fuerza bruta por defecto. Dependiendo la complejidad de la contraseña esto puede tardar unos minutos o muchas horas. 

john passwords

Si no disponemos de un buen diccionario. John cuenta con el modo --incremental se trata del modo más potente y también el más costoso en tiempo de procesamiento. Es aconsejable establecer a este modo un límite de longitud y comprobaciones de contraseñas (dígitos, mayúsculas, minúsculas, símbolos, etc.) para intentar que el proceso no tarde exageradamente tanto tiempo. Donde "passwords" sería el fichero creado con unshadow.

john --incremental passwords

Podemos consultar los logs de John para ver a tiempo real el proceso de cracking.

tail -f /root/.john/john.log                   # Opción con tail

less /root/.john/john.log (pulsar shift + f)   # Opción con less

John crea un directorio oculto ~/.john en el home de usuario donde es ejecutado. Aquí almacena varios ficheros.

• ~/.john/john.log: Almacena el proceso de cracking, podemos consultarlo en tiempo real.
• ~/.john/john.pot: Almacena los hashes y las passwords encontradas. Podemos ver su contenido ejecutando "john --show <fichero_passwords_hashes>'.
• ~/.john/john.rec: Guarda el estado del proceso de cracking en el que caso de que sea interrumpido ('q' o 'ctrl+c' pulsado una sola vez, si lo pulsamos dos veces el proceso se abortará por completo), de todos modos John realiza un autoguardado del proceso en este fichero cada 10 minutos.

Para mostrar o visualizar las contraseñas encontradas. Donde "passwords" sería el fichero creado con unshadow.

john --show passwords

Para mostrar el estado del proceso.

john --status

Obtener una lista de los tipos de formatos de cifrado compatibles en el caso de especificar uno concreto dependiendo tipo de hashes.

john --list=formats
john --format=sha512crypt

 Para realizar un ataque por diccionario y aplicar el estilo de reglas por defecto.

john --wordlist=diccionario.lst --rules password

En la siguiente captura se puede ver un proceso de craking por defecto y de contraseñas débiles a través de John The Ripper.

Figura 1: Password cracking en Linux con John The Ripper.

Password cracking con Hashcat

Hashcat es otra herramienta archiconocida para el craking a una amplia variedad de tipos de hashes de passwords.

Código Hashcat del tipo de hash de cifrado comunes en sistemas Linux

• DES (Unix) = 1500
• MD5 = 0
• MD5 (Unix $1$) = 500
• Blowfish (Unix $2*$) = 3200
• SHA1 = 100
• SHA-256 = 1400
• SHA-256 (Unix $5$) = 7400
• SHA-512 = 1700
• SHA-512 (Unix $6$) = 1800 (usado en la mayoría de distribuciones actualizadas a día de hoy)

Ejemplo de uso en un ataque por diccionario con Hashcat.

hashcat -m 1800 -a 0 passwords diccionario.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule -o cracked.txt --force

• -m (--hash-type): Tipo de hash de cifrado (https://hashcat.net/wiki/doku.php?id=example_hashes)
• -a (--attack-mode): Modo de ataque. 0 como el modo directo predeterminado (ataque por diccionario).
• passwords: Fichero que contiene los hashes generado con unshadow.
• diccionario.txt: Diccionario -wordlist-.
• -r (--rules-file): Reglas de combinación que aplicará a cada palabra del diccionario. Intenta encontrar contraseñas candidatas aplicando funciones para modificar, cortar o extender palabras y tiene operadores condicionales para omitir algunas, etc. (https://hashcat.net/wiki/doku.php?id=rule_based_attack). Reglas disponibles en el paquete de Hashcat https://github.com/hashcat/hashcat/tree/master/rules.
• -o (--outfile): Fichero de salida
• --force: Ignora las advertencias.

Referencia: https://hashcat.net/wiki

En la siguiente captura se muestra un ataque por diccionario, estableciendo el formato del tipo de hash de cifrado 1800 (sha-512 - unix $6$), añadir el fichero de reglas "InsidePro-PasswordsPro.rule" incluido en el paquete de Hashcat y guardar el resultado de las contraseñas encontradas en un fichero de salida llamado cracked.txt.

Figura 2: Password cracking en Linux con Hashcat.

Password hash cracking Online

Existen multitud de sitios web en Internet que contienen grandes bases de datos con todo tipo de hashes donde pueden comparar y obtener un match en base al hash introducido. Algunas webs usan servidores potentes para realizar consultas a tablas Rainbow consiguiendo resultados más rápidamente.

• https://crackstation.net/
• https://gpuhash.me/
• https://www.onlinehashcrack.com/ (de pago para una mayor rapidez, dispone de la posibilidad de usar rainbow tables muy efectivas).

Figura 3: Descifrar hashes SHA512crypt (Unix) en sitios web online.

Saludos!

FakeLogonScreen: Conseguir credenciales locales o Active Directory a través de un inicio de sesión en un bloqueo de pantalla falso

FakeLogonScreen es una utilidad desarrollada por @bitsadmin que simula un bloqueo de pantalla de inicio de sesión de Windows 10 falso que se ejecute en el lado del usuario y tiene como finalidad obtener su contraseña de acceso. La contraseña ingresada se valida con Active Directory o la máquina local para asegurarse de que sea correcta.

El usuario y las contraseñas introducidas se envían a la consola (FakeLogonScreen.exe) o se almacenan en un archivo en disco (FakeLogonScreenToFile.exe). Si el usuario configura un fondo personalizado, muestra ese fondo en lugar del predeterminado.

En una fase de post-explotación, donde disponemos de una sesión con una Shell remota, podemos copiar este binario a la máquina comprometida e invocarlo. En consola se mostrarán todas las contraseñas introducidas (en el caso de que la contraseña se escribiese mal) y nos marcará la contraseña con la que se hizo una correcta validación.

Github: https://github.com/bitsadmin/fakelogonscreen

Figura 1: (gif) FakeLogonScreen Windows.

Saludos!

Gestión de política de contraseñas en Linux: login.defs y pam_pwquality (pam_cracklib)

Antes de entrar en materia y comentar donde se definen las directivas de contraseñas en entornos Linux, es necesario conocer los campos que estructuran al fichero donde almacenan cifradas las contraseñas de usuarios locales /etc/shadow.

Este fichero nos muestra el estado actual de como se están aplicando estas directivas a los usuarios y que nos resulta útil en procesos de auditoria interna para conocer esta información.

Estructura del fichero /etc/shadow

Figura 1: Estructura del fichero /etc/shadow.

• 1. Nombre de usuario.
• 2. Contraseña cifrada. Se establece con la estructura $id$salt$hashed. El tipo de algoritmo utilizado se define en el inicio en números entre los símbolos $.
• $1$ - MD5.
• $2a$ - Blowfish.
• $2y$ - Blowfish.
• $5$ - SHA-256.
• $6$ - SHA-512.
• 3. Último cambio de contraseña desde el 1/Enero/1970 (epoch).
• 4. Cantidad de días restantes para que el usuario cambie su contraseña. -1 significa que nunca expira.
• 5. Número máximo de días que la contraseña es válida después del cambio de contraseña por parte del usuario.
• 6. Días antes de que caduque la contraseña, advierte al usuario para que la cambie.
• 7. Días después de que caduque la contraseña, esa cuenta estará deshabilitada.
• 8. Días desde el 1/Enero/1970. Fecha absoluta que especifica cuando ya no se pueda usar el inicio de sesión para esa cuenta.

Comando chage (caducidad en las contraseñas)

Con el comando chage (change age) podemos establecer la caducidad de contraseñas y cuentas de usuario. Esto no afecta a los nuevos usuarios, se establece de forma nominal a usuarios existentes.

Para aplicar estas opciones a nuevos usuarios y así generar estas directivas por defecto habría que hacer uso de login.defs que se comenta más adelante en este artículo.

Opciones del comando chage:

• -d, --lastday: Establece el día del último cambio de la contraseña.
• -E, --expiredate: Establece la fecha de caducidad.
• -I, --inactive: Deshabilita la cuenta después inactividad de días de la fecha de caducidad.
• -l, --list: Muestra la información de la edad de la cuenta.
• -m, --mindays: Establece el número mínimo de días antes de cambiar la contraseña.
• -M, --maxdays: Establece el número máximo de días antes de cambiar la contraseña.
• -R, --root: Directorio en el que hacer chroot.
• -W, --warndays: Establece los días de aviso de expiración.

Con el parámetro -l podemos ver información sobre las cuentas.

# chage -l pepe
Last password change                                    : Apr 18, 2020
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 5 

Más información sobre el comando chage: https://linux.die.net/man/1/chage

Cumplimiento de directivas de seguridad en la calidad de contraseñas seguras de usuarios

Al igual que en sistemas Windows es necesario implementar un mínimo cumplimiento de seguridad en el hardening de contraseñas estableciendo directivas a nivel de dominio para definir la complejidad de contraseña, longitud mínima, días de expiración, contraseñas no repetidas respecto a las anteriores, etc.

En sistemas Linux, aplicaciones de terceros o servicios exógenos que hacen uso de usuarios Linux, también es necesario establecer políticas de seguridad estrictas al tratarse de cuentas que pueden tener el mismo riesgo de ser vulneradas y poder pivotar a otros sistemas que sean de un mayor interés para los atacantes.

Lógicamente también dependerá de la infraestructura y su ecosistema. En entornos de producción no sería conveniente provocar la desactivación o bloqueo de una cuenta de usuario y dejar inoperativo un servicio crítico que dependa de dicha cuenta. Independientemente de estos casos es recomendable y diría que necesario establecer este tipo de criterios para garantizar y elevar un poco más las medidas de seguridad de los sistemas de la empresa.

Se pueden establecer políticas por defecto en el momento de creación de nuevas cuentas en el sistema, sin la necesidad de usar chage nominalmente a cada usuario como vimos anteriormente.

login.defs

Se trata de un fichero de texto situando en /etc/login.defs de forma nativa se encuentra en cualquier entorno Linux. Se definen las políticas de gestión de contraseñas para la creación de nuevos usuarios. También podemos establecer otros directivas como el valor umask por defecto, si el usuario tendrá un home para el si no se le especifica en su creación (useradd -m), cambiar la secuencia de ID (por defecto suelen ser 1000 y algo para usuarios normales), mensaje de bienvenida del inicio de sesión del usuario (motd_file), etc.

El motivo de este artículo será enfocado únicamente a las que tengan que ver con las políticas de contraseñas.

Algunas de las directivas más comunes que podemos establecer:

• PASS_MAX_DAYS: Número máximo de días que se puede usar una contraseña.
• PASS_MIN_DAYS: Número mínimo de días permitido entre cambios de contraseña
• PASS_WARN_AGE: Número de días de advertencia antes de que caduque una contraseña.
• PASS_MIN_LEN y PASS_MAX_LEN: Número mínimo y máximo de caracteres que debe tener la contraseña.
• PASS_ALWAYS_WARN: Advierte sobre contraseñas débiles.
• PASS_CHANGE_TRIES: Número máximo de intentos de cambiar la contraseña si se rechaza por que es demasiado "fácil".
• ENCRYPT_METHOD: Tipo de cifrado que tendrá la contraseña (SHA256 $5$ o SHA512 $6$).
• LOGIN_RETRIES: Número máximo de reintentos de inicio de sesión en el caso de que la contraseña sea incorrecta.
• LOGIN_TIMEOUT: Tiempo máximo en segundos para iniciar sesión

Más información sobre login.defs: https://linux.die.net/man/5/login.defs

pam_cracklib y pam_pwquality

Si queremos tener una mayor nivel de detalle en la personalización de las directivas en la complejidad de contraseñas para las cuentas de usuarios sería más interesante hacer uso de los módulos PAM (Pluggable Authentication Modules) pam_cracklib y pam_pwquality.

pwquality es una versión más actual y mejorada de cracklib. pwquality llama a una rutina cracklib para verificar si la contraseña es parte de un diccionario si este se especifica en la directiva dictpath. En este caso haré referencia siempre a pam_pwquality.

En entornos RHEL/Centos se incorpora de forma nativa, es compatible con derivados Debian pero será necesario instalarlo.

sudo apt install -y libpam-cracklib libpam-pwquality libpwquality-tools

Una vez instalado el módulo de libpwquality podemos editar sus opciones en el fichero "/etc/security/pwquality.conf".

Opciones para definir las políticas: 

• difok: Número de caracteres en una nueva contraseña que no deben estar presentes en la contraseña anterior.
• minlen: Tamaño mínimo aceptable para la nueva contraseña.
• dcredit: Crédito máximo por tener dígitos en la nueva contraseña.
• ucredit: Crédito máximo por tener letras mayúsculas en la nueva contraseña.
• lcredit: Crédito máximo por tener letras minúsculas en la nueva contraseña.
• ocredit: Crédito máximo por tener otros caracteres en la nueva contraseña.
• minclass: Número mínimo de clases de caracteres requeridas para la nueva contraseña
• maxrepeat: Número máximo de caracteres repetidos.
• maxclassrepeat: Número máximo de caracteres consecutivos en la misma clase.
• gecoscheck: Verifica si las palabras individuales de más de 3 caracteres del campo passwd GECOS (campo de comentarios) del usuario están contenidas en la nueva contraseña.
• dictpath: Ruta a los diccionarios de clacklib.
• badwords: Lista de palabras separadas por espacios que no deben incluirse en la contraseña.

Sistema de créditos, valores negativos y clases en pwquality

Créditos

Para definir la calidad y complejidad de las contraseñas se utiliza un sistema de créditos. Esto es muy interesante, básicamente se obtienen créditos por la complejidad. Una contraseña más corta podría ser aceptable si es más compleja en otras formas.

Por ejemplo una contraseña "ahwouwtdye" podría pasar una prueba minlen = 10. Si dcredit se establece en 2, una contraseña "ahwouw12" pasaría la prueba por que obtendríamos 2 créditos por cada dígito, entonces 8 caracteres más 2 créditos se valoran como 10 caracteres. Esto dependerá de como se establezcan los parámetros ucredit, lcredit, dcredit y ocredit.

Valores negativos

Establecer valores de créditos negativos significa que debe tener al menos ese tipo de carácter. Por ejemplo, establecer dcredit a -1 significaría que debe incluir al menos un dígito para que se acepte una contraseña. Es decir, no se trata de una suma de créditos sino de un requerimiento obligatorio.

Clases (minclass)

Otra configuración interesante es minclass. Determina cuántas clases diferentes de caracteres se deben usar para que una contraseña sea aceptable. Hay 4 tipos de clases: minúsculas, mayúsculas, dígitos, caracteres especiales (símbolos o signos).

Por ejemplo, un minclass = 2 exige que una contraseña contenga la combinación de dos tipos de clases. Ya sean mayúsculas o minúsculas, mayúsculas y caracteres especiales, minúsculas y dígitos, etc. Lo mismo pasaría si se establece a minclass = 4, la contraseña debería contener

También se puede establecer un límite al número máximo de caracteres de cualquier tipo de clase. Por ejemplo, con el parámetro maxclassrepeat = 4 indicamos que las contraseñas no pueden contener más de 4 minúsculas, mayúsculas, dígitos y otros caracteres especiales. 

Más información sobre el uso de directivas del fichero de pwquality: https://linux.die.net/man/8/pam_pwquality

Probando el cumplimiento de requisitos con varias contraseñas.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña tiene menos de 8 caracteres.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - No contiene suficientes caracteres DIFERENTES.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática.

# passwd pepe
Nueva contraseña:
CONTRASEÑA INCORRECTA: La contraseña contiene más de 3 caracteres de la misma clase en forma consecutiva

pwscore

pwquality (libpwquality-tools) dispone de una herramienta llamada pwscore que podemos usar para comprobar la complejidad de una contraseña en base a los criterios establecidos en pwquality. Algunos ejemplos de uso.

# echo 123 | pwscore
Falló la comprobación de calidad de la contraseña:
 La contraseña tiene menos de 8 caracteres

# echo abc123.. | pwscore
Falló la comprobación de calidad de la contraseña:

 La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática.

# echo L3h5as/2a$-ls=72 | pwscore
100

Conclusiones

Estos módulos PAM también pueden comprobar si las contraseña son un palíndromo o si solamente se cambió un solo carácter de mayúscula a minúscula o viceversa, si las contraseñas anteriores son similares o ya han sido usadas anteriormente, si contiene el nombre del usuario, o si hay alguna coincidencia con el campo passwd GECOS (campo de comentarios) de /etc/passwd. Dependiendo el nivel de complejidad que se establezca sería difícil establecerse una mala contraseña.

En definitiva, ofrecen una serie de comprobaciones que ayudan a garantizar un nivel de robustez y calidad de las contraseñas. Así como en la mayoría de compañías se aplican para entornos Windows, intentar aplicar estas políticas de seguridad en sistemas Linux y que no habiten en el olvido.

Saludos!

Post-Explotación: Movimiento lateral usando técnicas Pass the hash (PtH)

En las fases de explotación de un pentest interno y dando continuidad al artículo de Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit. Hoy quiero comentar diversas técnicas que se pueden emplear para realizar movimiento lateral o también conocido como Pass the hash (PtH).

¿Qué es un movimiento lateral usando técnicas Pass the hash?

Movimiento lateral (pivoting) usando Pass the hash es una de la técnicas empleadas para pivotar de una máquina a otra. Una vez que se ha comprometido una máquina, hemos escalado privilegios y conseguimos realizar un volcado de hashes. Podemos utilizar estos hashes para autenticarse en otra máquina que tenga las mismas credenciales que la máquina origen.

Concepto del "Principio de localidad"

En las organizaciones suele ser habitual que el usuario Administrador local u otro usuario que pertenece al grupo de Administradores locales utilice la misma contraseña para todas las máquinas de la empresa o departamento facilitando así el movimiento lateral entre máquinas con la misma cuenta de usuario. Esto se conoce como principio de localidad y suele ser así por motivo de facilitar la administración y gestión de las máquinas corporativas por parte de los departamento de IT de las compañías.

Precisamente por esta razón obtener la información de hashes NTLM es muy importante para un pentester por que nos ayudaría a movernos lateralmente pivotando por las máquinas de la organización intentando encontrar debilidades en otras máquinas.

En el siguiente artículo mostraré varios técnicas de ejemplo en distintos escenarios para lograr el movimiento lateral a través de la obtención de un hash NTLM de un entorno Windows.

• WCE - Windows Credentials Editor
• Mimikatz (pth)
• Módulo Metasploit psexec/smb-pass
• PowerShell: Invoke-TheHash - Función Invoke-WMIExec

WCE - Windows Credentials Editor

WCE o Windows Credentials Editor es una herramienta desarrollada por Amplia Security en la que podemos obtener un volcado de los hashes NTLM almacenados en memoria y usarlos para técnicas de Pass the hash.

En el siguiente escenario existen dos máquinas: 

• Windows 7: PCW7 - 10.0.0.7
• Windows 10: PCW10 10.0.0.10

Tenemos acceso a la máquina Windows en la que tenemos privilegios pero no conocemos la contraseña en plano.

Abrimos una consola e intentamos ejecutar una cmd remota al equipo Windows 10 usando psexec de la suite de PsTools. Como vemos en la captura de pantalla el acceso a sido denegado, esto ocurre por que intenta autenticarse con con usuario/password distintos al que inició el proceso de la cmd.exe.

Con WCE acompañado del argumento -l se listan de sesiones de inicio de sesión y credenciales NTLM. En este caso admin:PCW7:LM:NT (user:hostname:hashLM:hashNT).

Mimikatz: Volcado de hashes NTLM del fichero SAM

Para obtener el hash NTLM del usuario por defecto Administrador local usaremos Mimikatz para realizar un volcado de hashes del fichero SAM. 

Iniciamos Mimikatz, entramos en el modo privilegiado, impersonamos al usuario admin (que forma parte del grupo Administradores locales) para obtener el token de NT AUTHORITY/SYSTEM y poder realizar el volcado de hashes.

mimikatz # privilege::debug

mimikatz # token::elevate

mimikatz # lsadump::sam

Hay que tener en cuenta que si un usuario carece de contraseña, es decir, una password en blanco. Obtendremos un LM hash null: AAD3B435B51404EEAAD3B435B51404EE.

Figura 1: WCE y Mimikatz - Listado de hashes NTLM de las sesiones actuales y volcado de hashes NTLM del fichero SAM. 

Una vez disponemos del hash NTLM del usuario Administrador, salimos de Mimikatz y ejecutamos WCE con el argumento -s para cambiar las credenciales NTLM de la sesión de inicio actual.

Según la sintaxis del comando hay que completar el espacio del hash LM, bastará con rellenar su tamaño con números valor 0 seguido del valor hash NT.

wce.exe -s USER:WORKGROUP:LM:NT

Una vez cambiado el hash para el usuario Administrador si volvemos a listar los usuarios de inicio de sesión con wce -l veremos dos inicios de sesión actuales almacenados, el usuario Admin y el nuevo usuario Administrador.

Para comprobar su funcionalidad probaremos a conectarnos ejecutando una cmd remota a través de psexec este utilizará las credenciales almacenadas del usuario Administrador para autenticarse en el sistema remoto Windows 10.

En la siguiente captura se puede ver como se creó un fichero de prueba C:\pwned.txt en el disco local de la máquina remota Windows 10 (PCW10) donde solo se podemos escribir si somos usuarios privilegiados.

Figura 2: WCE - PoC the PtH y conexión con privilegios hacia el host remoto.

Otra prueba interesante que podemos realizar es montar una unidad del disco local C:\ del equipo remoto Windows 10 haciendo uso del recurso compartido por defecto C$.

net use x: \\IP_remota\c$

Donde x: sería una letra la asignación disponible para la unidad a montar. 

Si listamos la estructura de directorios (dir) podemos ver el fichero pwned.txt creado anteriormente y podremos eliminarlo, verificando así que seguimos teniendo privilegios de modificación en el disco C:\.

Figura 3: Autenticación con privilegios para montar como unidad el recurso compartido C$ de la máquina remota. 

Mimikatz

Con Mimikatz podemos realizar Pass the hash de una forma muy sencilla. Una vez obtenemos el hash NTLM y teniendo acceso físico o una shell remota hacia la máquina. Ejecutamos en la consola de Mimikatz lo siguiente:

sekurlsa::pth /user:<USER> /ntlm:<HASH_NTLM> /domain:WORKGROUP

Esto nos lanzará un nuevo proceso cmd.exe con el usuario que lo hayamos invocado (administrador como se puede ver en la screenshot).

La máquina en la que se realiza al técnica es un equipo Windows 7 llamado PCW7. Con las pstools ejecutamos un psexec para intentar ejecutar una cmd en la máquina remota que será un Windows 10 llamado PCW10 (10.0.0.10). 

Vemos que conseguimos una sesión autenticándonos gracias al access token que hemos definido en Mimikatz para la ejecución de este proceso (cmd.exe). Si la contraseña del administrador local fuera otra y por lo tanto su hash NTLM, esta autenticación fallaría.

Figura 4: Mimikatz (sekurlsa::pth) - Utilizando Pass the hash para autenticarse desde una máquina hacia otra remota.

Metasploit (módulo psexec - SMB)

En Metasploit existe un módulo llamado exploit/windows/smb/psexec. El cual usa algo muy similar a la utilidad de comandos psexec de Sysinternals para poder autenticarse por medio del recurso compartido por defecto ADMIN$ de la máquina remota. Este recurso hace uso del protocolo SMB (Service Message Block) puerto 445. Después de autenticarse, ejecutará el Payload que le indiquemos. 

smbexec: https://sourceforge.net/projects/smbexec/
CVE-1999-0504: https://www.cvedetails.com/cve/CVE-1999-0504/

Antes de poner en práctica esta técnica de movimiento lateral, conseguimos desde otra máquina un movimiento vertical (escalada de privilegios) para realizar un volcado de hashes NTLM usando el módulo "post/windows/gather/smart_hashdump" indicando la sesión comprometida (el script hashdump que se utilizaba dentro de Meterpreter, actualmente se encuentra obsoleto).

Figura 5: Metasploit - Volcado de hashes NTLM usando el módulo /post/windows/gather/smart_hashdump.

Para la prueba de concepto se eliminarán las sesiones previas establecidas (sessions -K). Usamos el módulo tipo exploit "exploit/windows/smb/psexec".

En este módulo es necesario establecer el host remoto en el que queremos hacer target (RHOSTS víctima), el usuario local Administrador y su hash NTLM obtenidos anteriormente desde otra máquina. La sintaxis sería <LM:NTLM> podemos establecer un LM hash null (AAD3B435B51404EEAAD3B435B51404EE) seguido del NTLM hash.

Establecemos un Payload tipo meterpreter/reverse_tcp, indicamos el host local donde obtendremos la shell inversa (la maquina Kali) y finalmente ejecutamos el exploit.

Figura 6: Metasploit - PoC Pass the hash usando el módulo "exploit/windows/smb/psexec".

El módulo usará psexec para autenticarse a través del recurso compartido ADMIN$ ejecutando el payload definido, estableciendo una sesión como Administrador y finalmente obtener el token de "NT AUTHORITY/SYSTEM".

Figura 7: Metasploit - Exploit con éxito a través de la autenticación de recursos compartidos smb (PtH).

PowerShell: Invoke-TheHash - Función Invoke-WMIExec

Otra técnica es empleando la función Invoke-WMIExec del repositorio de Github Invoke-TheHash desarrollada por Kevin Robertson.

Es necesario desactivar la política de restricción de ejecución de scripts. "Set-ExecutionPolicy Unrestricted". Una vez descargado el repositorio e importada la función "Invoke-WMIExec" en PowerShell, simplemente tendremos que indicar el hash NTLM, la IP remota destino, el usuario será el Administrador de la máquina y la instrucción del comando a ejecutar.

Invoke-WMIExec -Hash <hash_NTLM> -Target <IP_remota> -Username Administrador -Command "<instrucción_comando_a_ejecutar>"

En el siguiente escenario no solo realizamos un pass the hash desde la máquina Windows 10 a la máquina Windows 7 sino que también hacemos un movimiento vertical, escalada de privilegios, gracias al hash. Abriendo Powershell con un usuario distinto al cual después ejecutamos indicándole el hash a Invoke-WMIExec, que sería el Administrador local (RID = 500).

Figura 8: PowerShell - Pass the hash usando la función Invoke-WMIExec.

pth-winexe: Pass the hash winexe ejecutando un cmd

pth-winexe es parte de las utilidades que forman la suite de pth-toolkit. Se trata de un pequeño script sh que permite por ejemplo ejecutar un binario conociendo unas credenciales de acceso de una máquina remota que tenga el protocolo SMB a la escucha.

Con el parámetro -U podemos indicarle el dominio o hostname, usuario, passoword o en su defecto el LM hash null (aad3b435b51404eeaad3b435b51404ee) seguido del NTLM hash indicando la IP de la máquina remota y un binario a ejecutar como puede ser un cmd.exe. 

pth-winexe -U <DOMAIN>/<USER>%<HASH_LM:HASH_NTLM> //<Remote_IP> cmd.exe

En la siguiente captura se muestra un ejemplo de Pass the hash a una máquina Windows 10 en un contexto de integridad alta con un usuario administrador indicando su hash y ejecutando una cmd.

Figura 9: pth-winexe - Pass the hash ejecutando un cmd.

Saludos!