MrTux

MrTux

Security Analyst - Red Team

Forest - HackTheBox

15 minute read

En este post se explicarán los pasos que se han seguido para conseguir vulnerar la seguridad de la máquina Forest en Hack The Box, tal y como se refleja, es un sistema Windows con un nivel de dificultad fácil (5.4).

Ilustración 1: Forest.

Se procedió a realizar un escaneo de servicios y puertos haciendo uso de NMAP:

Ilustración 2: Comando de NMAP usado.

Ilustración 3: Resultados de NMAP parte 1.

Ilustración 4: Resultados de NMAP parte 2.

Ilustración 5: Resultados de NMAP parte 3.

Analizando los resultados de la primera ejecución de NMAP sobre la IP 10.10.10.161, se puede confirmar que es un sistema Windows. El cual únicamente parece tener abierto los puertos que corresponden a servicios propios de dicho sistema, como Kerberos, NetBios, LDAP, SMB y MSRPC entre otros, además de un servidor de DNS.

También la información que proporcionan los scripts que por defecto ejecuta NMAP, revelan que se trata de un Windows Server 2016 con Active Directory (AD), donde existe el dominio "htb.local", el grupo de trabajo (WorkGroup) "HTB" y el FQDN (Fully Qualified Domain Name) es "FOREST.htb.local" .

En este punto se probaron algunas conexiones por defecto a servicios conocidos, como SMB:

Ilustración 6: Intentando establecer conexión al puerto 445 mediante smbclient.

Pero ningún intento resultó fructífero, tan solo se descubrió que el usuario "Guest" parece estar deshabilitado. Por tanto, se optó por seguir enumerando, haciendo uso de NMAP para obtener más información y definir un vector de ataque.

Dado que existían puertos con servicios desconocidos, se ejecutó el script "dns-srv-enum" de NMAP, para que a través del registro SRV del servidor de DNS de la máquina víctima poder tener más información de qué servicios se ejecutan.

Ilustración 7: Segundo comando de NMAP usado.

Ilustración 8: Resultados del segundo comando NMAP.

Como se puede observar, se pudo identificar algunos servicios que anteriormente estaban en estado "tcpwrapped", son el caso de "ldapssl" en el puerto 636 y "globalLDAPssl" en el puerto 3269.

Identificados todos los servicios y puertos de los que aparentemente hace uso la máquina Forest, se llegó a la conclusión, ya que no existe ningún servicio web u otras aplicaciones externas, de que se debe vulnerar alguno de estos servicios propios de un sistema Windows para conseguir un acceso no privilegiado. Es por ello, que es importante tener conocimientos sobre los siguientes términos:

  • Active Directory (AD) o Directorio Activo: son los términos que utiliza Microsoft para referirse a su implementación de servicio de directorio (aplicación o un conjunto de aplicaciones que almacena y organiza la información sobre los usuarios de una red y los recursos compartidos en ésta) en una red distribuida de computadores. Utiliza distintos protocolos, principalmente LDAP, DNS, DHCP y Kerberos.

  • DNS : El servidor de nombres es necesario en un AD para las búsquedas de recursos y que los clientes del AD puedan encontrar al servidor que actúa como Domain Control (DC), por ejemplo, a través del registro SRV del DNS. (herramientas para realizar consultas: dig y nslookup)

  • Controlador de Dominio (Domain Control, DC): Los controladores de dominio tienen una serie de responsabilidades, y una de ellas es la autenticación, que es el proceso de garantizar o denegar a un usuario el acceso a recursos compartidos o a otra máquina de la red, normalmente a través del uso de una contraseña. Esto permite validar a los usuarios de una red para ser partes de la plataforma de clientes que recibirán los servicios de información.

  • LDAP (Lightweight Directory Access Protocol o Protocolo Ligero/Simplificado de Acceso a Directorios): Es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. Habitualmente, almacena la información de autenticación, usuario y contraseña, aunque es posible almacenar más información como datos de contacto del usuario, ubicación de diversos recursos de la red, permisos, certificados, etc. (herramientas para realizar consultas en LDAP: openldap y ldapsearch).

  • Kerberos : Es un protocolo de autenticación, pero no de autorización. Esto quiere decir que el protocolo se encarga de identificar a cada usuario, a través de una contraseña solo conocida por este, pero no determina a qué recursos o servicios puede acceder o no dicho usuario. Una fuente ideal para entender el funcionamiento de kerberos es : https://www.tarlogic.com/blog/como-funciona-kerberos/. (herramientas para realizar peticiones a kerberos: Heimdal Kerberos y MIT Kerberos).

Hay otros protocolos que también entran en juego en un AD:

  • MS-RPC : Es la implementación de Microsoft del mecanismo DCE RPC (Remote Procedure Call, Llamada a Procedimiento Remoto, es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos). Además, MSRPC puede utilizar tuberías denominadas dentro del protocolo SMB (compartir archivo de red) para su transporte (transporte ncacn-np). Los servicios MSRPC proporcionan interfaces para el acceso y gestión del sistema de Windows de modo remoto. (herramienta para establecer una conexión mediante RPC: rpcclient y para atacar servicios MSRPC se puede usar: impacket (https://github.com/SecureAuthCorp/impacket)).

  • SMB : Server Message Block (SMB)​ es un protocolo de red que permite compartir archivos, impresoras, etcétera, entre nodos de una red de computadoras que usan el sistema operativo Microsoft Windows. SMB se puede ejecutar en la parte superior de las capas de red de varias maneras, directamente a través de TCP, en el puerto 445 o a través de la API de NetBIOS, que a su vez se puede ejecutar en varios puertos UDP 137, 138 y puertos TCP 137, 139. (herramienta para establecer una conexión mediante SMB: smbclient)

  • NetBIOS : Es una especificación de interfaz para acceso a servicios de red, es decir, una capa de software desarrollado para enlazar un sistema operativo de red con hardware específico. Resumiéndola de forma sencilla, NetBIOS permite a las aplicaciones 'hablar' con la red. Su intención es conseguir aislar los programas de aplicación de cualquier tipo de dependencia del hardware. En Windows suele usar los puertos 139 y 135.

  • NTLM Authentication : La autenticación NTLM es una familia de protocolos de autenticación que se incluyen en Windows Msv1_0.dll. Los protocolos de autenticación NTLM incluyen las versiones 1 y 2 de LAN Manager y, además, las versiones 1 y 2 de NTLM. Los protocolos de autenticación NTLM autentican a los usuarios y equipos en función de un mecanismo Challenge @ no__t-0response que demuestra a un servidor o a un controlador de dominio que un usuario conoce la contraseña asociada a una cuenta. NTLM es un protocolo de autenticación inventado por Microsoft (se usa en versionas antiguas), mientras que Kerberos es un protocolo estándar. La gran diferencia es cómo los dos protocolos manejan la autenticación. NTLM utiliza un protocolo de enlace de tres vías entre el cliente y el servidor y Kerberos utiliza un protocolo de enlace de dos vías mediante un servicio de concesión de tickets (KDC, centro de distribución de claves). En Kerberos, el cliente debe tener acceso a un controlador de dominio (que emite los tickets), mientras que en NTLM el cliente contacta al servidor que contacta al controlador de dominio.

Uno de los servicios interesantes que aparece en los resultados de la ejecución de NMAP es:

  • WinRM : Windows Remote Management es la implementación de Microsoft de WS-Management en Windows que permite a los sistemas acceder o intercambiar información de administración a través de una red común. Utilizando objetos de secuencias de comandos o la herramienta de línea de comandos incorporada, WinRM se puede usar con cualquier computadora remota que pueda tener controladores de administración de placa base (BMC) para adquirir datos. Se puede utilizar para recuperar información sobre un equipo remoto ejecutar los procesos de forma remota.

Una vez se llegó a la comprensión de cada uno de los servicios que se ejecutan en la máquina víctima, se comenzó a buscar información de cómo realizar ataques aprovechando vulnerabilidades conocidas. Para ello se hizo uso de las siguientes fuentes:

Para la realización de la mayoría de los ataques es necesario conocer como mínimo algún nombre de cuenta de usuario, por tanto, se hizo una enumeración más exhaustiva con diferentes herramientas:

  • enum4linux:

Ilustración 9: Ejecución de enum4linux.

Ilustración 10: Usuarios obtenidos usando enum4linux.

  • rpcclient:

Ilustración 11: Conexión como usuario anónimo haciendo uso de rpcclient.

Ilustración 12: Enumerando usuarios con rpcclient parte 1.

Ilustración 13: Enumerando usuarios con rpcclient parte 2.

Ilustración 14: Usando nullinux.

Ilustración 15: Resultados de nullinux almacenados en un fichero.

Conocidos los usuarios del sistema y los diferentes ataques que se pueden realizar a los servicios que se ejecutan en la máquina Forest, solo había dos posibilidades:

Ilustración 16: Ataque de diccionario a kerberos con el fichero de usuarios obtenidos por nullinux.

El ataque no se dejó finalizar porque requeriría mucho tiempo, ya que para cada usuario probaría todas las contraseñas almacenadas en el rockyou.txt, así que se decidió continuar con el siguiente ataque.

  • ASREPRoast se basa en encontrar usuarios que no requieren pre-autenticación de Kerberos. Lo cual significa que cualquiera puede enviar una petición AS_REQ en nombre de uno de esos usuarios y recibir un mensaje AS_REP correcto. Esta respuesta contiene un pedazo del mensaje cifrado con la clave del usuario, que se obtiene de su contraseña. Por lo tanto, este mensaje se puede tratar de crackear offline para obtener las credenciales de dicho usuario.

Se puede utilizar el script GetNPUsers.py de impacket (https://github.com/SecureAuthCorp/impacket) para recolectar mensajes AS_REP sin pre-autenticación:

Ilustración 17: Usando el script GetNPUsers.py de impacket.

Ilustración 18: Comprobación de usuarios que no requieran de pre-autenticación.

Ilustración 19: Hash NTLM del usuario svc-alfresco.

Como el usuario svc-alfresco no requiere de pre- autenticación, el ataque mediante GetNPUsers.py resultó exitoso y se obtuvo el hash NTLM de la contraseña del usuario. Pudiendo obtener la contraseña del usuario haciendo uso de JohnTheRipper y el diccionario rockyou.txt:

Ilustración 20: La contraseña de svc-alfresco es s3rvice.

Realmente el ataque de Kerberos brute-force hubiera funcionado si se hubiera dejado finalizar, dado que el hash de la contraseña de svc-alfresco se consiguió con el mismo diccionario que se usó en el ataque de kerbrute.py:

Ilustración 21: Probando kerbrute.py con la combinación exacta.

Teniendo una combinación correcta de usuario y contraseña, solo quedaba obtener una shell del sistema, para ello había que explorar las posibilidades que se tenían y que se investigaron en la fase de enumeración.

Tal y como se explicó anteriormente, la máquina tenía habilitado el servicio WinRM por el puerto por defecto 5985:

Ilustración 22: Ruta por defecto de WinRM en 10.10.10.161:5985/wsman.

Existe una herramienta llamada Evil-WinRM (https://github.com/Hackplayers/evil-winrm) que permite establecer una conexión haciendo uso de este servicio y obtener una Powershell del usuario (teniendo, obviamente, las credenciales):

Ilustración 23: Powershell con el usuario svc-alfresco.

Por tanto, ya se había obtenido la flag del usuario:

Ilustración 24: Flag user.txt.

Evil-WinRM permite subir ficheros al sistema con el que se ha establecido la conexión, así como también ejecutar binarios o ficheros con extensión "_._ps1" que se tengan almacenados en algún directorio de la máquina local.

Estando dentro del sistema, se procedió a realizar un reconocimiento y enumeración del entorno, para conocer las posibles vías de ataque que se podrían llevar a cabo para ejecutar una escalada de privilegios.

Para obtener la máxima información posible sobre el Active Directory, es decir, los grupos, usuarios, permisos y GPOs configuradas, hay una herramienta denominada BloodHound (https://github.com/BloodHoundAD/BloodHound), que en un uso básico, consiste en ejecutar en la máquina víctima un script (SharpHound.ps1) que recopilará toda la información y generará un fichero con extensión ".zip" como resultado. Posteriormente, de forma local se puede analizar la información con BloodHound y determinar cuál es el camino óptimo para obtener permisos como administrador.

Primero se decidió crear un directorio oculto en el sistema víctima, para intentar que los ficheros que se subiesen no fuesen visibles tan fácilmente, para el resto de los usuarios de la plataforma.

Ilustración 25: Creación de directorio oculto.

En el siguiente paso, se subieron los ficheros SharpHound.ps1 y SharpHound.exe (que se encuentran en el directorio "Ingestors" del repositorio https://github.com/BloodHoundAD/BloodHound) a la máquina Forest, ambos necesarios para la ejecución de los módulos de BloodHound que recopilarán la información en el sistema.

También se decidió subir netcat (nc.exe), porque después de varios intentos, se llegó a la conclusión de que la ejecución de los ficheros de BloodHound, no funcionaban correctamente si se lanzaban desde la shell que proporcionaba Evil-WinRM. Así que, una forma de resolverlo era abriendo una reverse shell y desde ahí, ejecutar los ficheros de BloodHound que recopilarían la información.

En un inicio todos los ficheros se subieron haciendo uso de la utilidad de upload de Evil-WinRM:

Ilustración 26: Subida de los ficheros necesarios para ejecutar BloodHound desde una conxión reversa.

Se abrió una reverse shell ejecutando netcat:

Ilustración 27: Ejecutando netcat.

Ilustración 28: Reverse shell con netcat establecida correctamente.

Se importaron los módulos necesarios para ejecutar BloodHound, haciendo:

Ilustración 29: Importando módulo de BloodHound haciendo: . .\SharpHound.ps1.

Se invocó a BloodHound:

Ilustración 30: Comando para recopilar toda la información posible del Active Directory con BloodHound.

Ilustración 31: Fichero con extensión zip generado.

Usando la librería "pyftpdlib" de Python, se abrió un servidor FTP en la máquina desde la cual se realizaban los ataques, con la finalidad de transferir los ficheros generados por BloodHound:

Ilustración 32: Abriendo servidor FTP y obteniendo el fichero con extensión ".zip".

Ilustración 33: Enviando desde la Powershell del usuario svc-alfresco el fichero generado por BloodHound vía FTP.

Con los recursos necesarios transferidos a la máquina en local, se procedió a la instalación de BloodHound, en el sistema desde el cual se analizaría la información:

Ilustración 34: Instalando BloodHound.

Ilustración 35: Creación de los directorios necesarios para que funcione correctamente neoj4 en la máquina local.

Ilustración 36: El servicio Neo4j funcionado correctamente.

Ilustración 37: Lanzando BloodHound una vez iniciado Neo4j.

Con BloodHound instalado y en ejecución, se pasó a importar el fichero zip y analizar la información:

Ilustración 38: Las posibles rutas que existen desde svc-alfresco hasta el Domain Admin del AD.

En BloodHound existen queries predefinidas, una de ellas señala el camino más corto que un usuario del AD tiene hasta llegar al Domain Admins:

Ilustración 39: Querie que indica el camino más corto para llegar al Domain Admins dentro del AD.

Ilustración 40: Ruta más corta desde el usuario svc-alfresco para llegar a ser Domain Admin.

Como se observa en todas las imágenes, existe un grupo llamado "EXCHANGE WINDOWS PERMISSIONS", al cual no pertenece scv-alfresco, y sí pertenece el usuario Administrator, miembro del grupo Domain Admins.

Por tanto, se deberá ejecutar la escalada de privilegios desde un usuario que sea miembro de dicho grupo:

Ilustración 41: Información del grupo EXCHANGE WINDOWS PERMISSIONS.

Porque tal y como refleja su descripción los miembros del grupo pueden modificar las cuentas y grupos del Active Directory.

Según la información del usuario svc-alfresco:

Ilustración 42: Información del usuario svc-alfresco.

Éste tiene permisos de administrador, por lo que podría crear usuarios y añadirlos a grupos existentes del dominio. Lo ideal hubiese sido añadir al usuario svc-alfresco al grupo "Exchange Windows Permissions", pero cuando posteriormente se ejecutaba el ataque para realizar la escalada de privilegios daba fallo, según fuentes del foro de HackTheBox era necesario crear un usuario nuevo y añadirlo al grupo, puesto que svc-alfresco salía del grupo automáticamente pasado un tiempo.

Así que se creó el usuario mrtux con contraseña s3rvice y se añadió al grupo "Exchange Windows Permissions", teniendo así los permisos que los miembros de ese grupo poseían:

Ilustración 43: Creación del usuario mrtux y miembro del grupo Exchange Windows Permissions.

NOTA: Otra forma de hacer lo descrito anteriormente, es usando el script PowerView.ps1 que se encuentra en el directorio Recon de la herramienta PowerSploit (https://github.com/PowerShellMafia/PowerSploit). Se debería importar el módulo tal y como se hizo con los scripts de BloodHound (en este caso: . .\PowerView.ps1) y usar las funciones que se encuentran en la documentación (https://powersploit.readthedocs.io/en/latest/). Un ejemplo de cómo usarlo, está en el siguiente WriteUp:

La principal vulnerabilidad aquí es que Exchange tiene altos privilegios en el dominio de Active Directory. El "Exchange Windows Permissions" tiene acceso WriteDacl en el AD, que permite a cualquier miembro de este grupo modificar los privilegios del dominio, entre los cuales se encuentra el privilegio de realizar operaciones DCSync. Los usuarios o las computadoras con este privilegio pueden realizar operaciones de sincronización que normalmente utilizan los controladores de dominio para replicar, lo que permite a los atacantes sincronizar todas las contraseñas hash de los usuarios en el Active Directory. Las fuentes principales para entender en que consiste este tipo de ataques y el que se realizará en concreto son:

Se inicia ntlmrelayx.py en modo retransmisión proporcionando el nombre del usuario mrtux que anteriormente se creó y añadió al grupo "Exchange Windows Permissions":

Ilustración 44: Iniciando ntlmrelayx.py.

Ahora yendo al navegador, a la dirección de localhost, se introducen las credenciales del usuario mrtux, que se autenticará en el Exchange:

Ilustración 45: Introduciendo las credenciales del usuario mrtux para autenticarse en el Exchange.

Después de unos segundos la conexión se realiza y otorga al usuario privilegios DCSync. Se genera un fichero y ntlmrealyx.py indica que se use secretdump.py para obtener todos los hashes:

Ilustración 46: Conexión realizada con éxito y fichero generado correctamente por ntlmrelayx.py.

Usando secretdump.py se obtuvieron todos los hashes de los usuarios, entre ellos el del Administrator:

Ilustración 47: secretdump.py proporciona todos los hashes de los usuarios a partir del fichero generado por ntlmrelayx.py.

Cuando se tiene el hash del administrador del sistema es tan fácil como usar psexec.py, también de impacket (https://github.com/SecureAuthCorp/impacket), para obtener una shell de administrador en el sistema:

Ilustración 48: Powershell de administrador del sistema usando psexec.py con el hash del usuario Administrator.

Ya una vez dentro se accede a la flag del fichero root.txt:

Ilustración 49: Fichero root.txt.

Como conclusión se puede decir que ha sido una máquina apasionante, porque es totalmente realista, se requieren muchos conocimientos del entorno Windows y saber cómo funcionan los servicios para poder explotarlos, así como también conocimientos de diferentes herramientas. Está catalogada como fácil, aunque sinceramente no considero que sea así, porque realmente, aunque se usan herramientas conocidas (si estás familiarizado con entornos Windows), se debe saber exactamente que se está haciendo para poder ir avanzando.