Manager
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Manager es una máquina Windows de dificultad media que aloja un entorno de Active Directory con AD CS (Active Directory Certificate Services), un servidor web y un servidor SQL. El punto de apoyo implica enumerar usuarios mediante ciclos RID y realizar un ataque de rociado de contraseñas para obtener acceso al servicio MSSQL. Luego se utiliza el procedimiento xp_dirtree para explorar el sistema de archivos y descubrir una copia de seguridad del sitio web en la raíz web. Al extraer la copia de seguridad, se revelan las credenciales que se reutilizan para WinRM en el servidor. Finalmente, el atacante aumenta los privilegios a través de AD CS mediante la explotación de ESC7.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Manager.
Comprobaremos el nombre del dominio con el cual nos enfrentamos a través del siguiente comando.
Verificaremos también a qué tipo de máquina nos enfrentamos a través de netexec.
Procederemos a enumerar el sitio web que se encuentra alojado en puerto 80 (HTTP). Primero de todo, probaremos con la herramienta de whatweb de revisar qué tecnologías se utilizan en el sitio web.
A través de la herramienta de gobuster, enumeraremos posibles directorios que se encuentren disponibles en el sitio web.
Comprobromamos el acceso a uno de ellos y nos aparece error 403 Forbidden. De momento descartamos seguir por aqui, no hemos encontrado nada interesante en el sitio web.
A través de la herramienta NSrpcenum probaremos de enumerar los usuarios del dominio, ya que no disponemos de credenciales válidas. Nos indica que al parecer no podemos acceder por tema de permisos.
Procederemos a realizar con netexec sobre el SMB un ataque de RID Brute Force Attack.
Un ataque de fuerza bruta RID consiste en probar diferentes valores de RID (Relative Identifier) para identificar usuarios en un sistema Windows, utilizando el hecho de que los RIDs suelen ser consecutivos a partir de un valor conocido, como el administrador (500) o el invitado (501).
Del resultado anterior, extraeremos los campos que nos interesa, los nombres de los usuarios y nos lo guardaremos en "users.txt".
Otra de las maneras para ir enumerando usuarios del dominio válidos a través de un diccionario es empleando la herramienta de Kerbrute.
Debido que disponemos de una potencial lista de usuarios válidos del dominio, podemos plantearnos en efectuar un AS-REP Roast Attack para solicitar un Ticket Granting Ticket (TGT). En este caso ningún usuario disponía de la configuración de (DONT_REQ_PREAUTH) de Kerberos
Probaremos de realizar ataque de fuerza bruta con netexec para probar si los usuarios disponen de contraseña su mismo nombre de usuario en minúsculas.
Realizaremos con netexec y el parámetro (--no-bruteforce) y encontramos el usuario "operator" que su contrraseña es la misma del nombre del usuario.
Validaremos nuevamente las credenciales son válidas correctamente y si podemos autenticarnos mediante WinRM.
Verificamos que las credenciales si son válidas pero no tenemos permisos de conectarnos vía WinRM.
Ya que disponemos de unas credenciales válidas, podemos intentar realizar un Kerberoasting Attack para intentar solicitar un Ticket Granting Service (TGS).
Probaremos de realizar una enumeración con la herramienta de ldapdomaindump.
Comprobaremos qué usuarios forman parte del grupo "Remote Management Users", esto es interesante debido que actualmente tenemos credenciales pero aún no tenemos acceso a la máquina como tal, por lo tanto, nos interesa conectarnos con algún usuario a la máquina remota y así luego escalar privilegios como usuario Administrator.
Ya que tenemos credenciales válidas, probaremos de utilizar la herramienta de rpcenum para listar posible información de usuarios, grupos, etc.
Ya que hemos visto que el puerto de MSSQL se encuentra expuesto, procederemos a autenticarnos con las credenciales del usuario "operator" para probar si podemos a ganar acceso. El primer comando no nos sirvió, pero podemos utilizar el parámetro (-windows-auth) y ver si con este parámetro ganamos acceso. Comprobamos que efectivamente hemos ganado acceso al servicio MSSQL.
Probaremos de habilitar el componente xp_cmdshell pero no podemos activarlo por falta de permisos.
El compontente xp_dirtree si lo tenemos habilitado, probaremos de comprobar si podemos interceptar un hash NTLMv2.
Para ello, des de nuestra Kali nos levantaremos un servidor SMB y des de la terminal de MSSQL procederemos a ejecutar el comando de xp_dirtree en el servidor SMB que hemos montado, por parte de nuestra Kali, hemos recibido el hash NTLMv2.
Con la herramienta de hashid comprobaremos qué tipo de hash tenemos, en este caso, un hash NTLMv2.
Y con hashcat procederemos a crackear el hash para obtener la contraseña.
Comprobamos que no hemos obtenidor resultado para crackear la contraseña.
Volviendo a la terminal de MSSQL, volvermeos a aprovecharnos del componente xp_dirtree para listar archivos y directorios del sistema.
Comprobamos que dentro de la ruta (C:\inetpub\wwwroot\) hay un comprimido .zip de lo que parece ser el backup del sitio web, que si bien recordamos, el sitio web es el que enumeramos al principio, ya que vimos que estaba montado con IIS, y la ruta por defecto que utiliza este servidor web es la indicada.
Como este archivo se encuentra en la raíz directamente de donde están alojadas las páginas web, lo que haremos es lo siguiente.
Nos lo descargaremos directamente des de la misma URL con wget.
Procederemos a descromprimir el comprimido .zip
Revisando los archivos que disponemos, nos encontramos un archivo oculto nombrado ".old-conf.xml". Verificando el contenido del archivo, nos encontramos unas supuestas credenciales para el usuario "raven@manager.htb" que si mal no recordamos, este usuario formaba parte del grupo de "Remote Management Users", por lo tanto si estas credenciales son válidas, podríamos llegar a acceder al equipo a través de evil-winrm aprovechándonos que WinRM se encuentra expuesto.
A través de netexec validaremos que con estas credenciales podemos acceder al WinRM, comprobamos que sí ya que nos aparece.
Procederemos de realizar una enumeración del AD a travñes de la herramienta adPEAS.ps1 que es un script de Powershell (parecido a winPEAS) pero en vez de buscar malas configuraciones de Windows, hace exactamente lo mismo pero en el entorno del AD.
Nos lo descargaremos en nuestra Kali, levantaremos un servidor web con Pyton y a través de IEX en el equipo Windows, lo importaremos en memoria.
ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.
Algunas de las posibles vulnerabilidades que puede tener ADCS son:
Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.
Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.
NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.
Al ejecutar este comando, Certipy escanea el entorno de AD buscando posibles configuraciones de ADCS que sean vulnerables a explotación. Esto puede incluir permisos indebidos, configuraciones débiles de plantillas de certificado, o cualquier ajuste que permita abuso de privilegios en el entorno de Active Directory. Localizamos que existe una vulnerabilidad ESC7.
La vulnerabilidad ESC7 en ADCS permite que usuarios con pocos privilegios puedan obtener certificados que luego pueden usar para autenticarse como usuarios con más permisos. Esto ocurre porque ciertas plantillas de certificados están configuradas de forma insegura, permitiendo solicitudes de certificados que otorgan acceso elevado.
En pocas palabras: ESC7 permite a un atacante aprovechar plantillas mal configuradas para ganar privilegios y moverse en el dominio con más permisos de los que debería.
Primero, añadimos a Raven como officer en la autoridad de certificación 'manager-DC01-CA', lo que le da permisos para gestionar certificados. Luego, habilitamos la plantilla de certificados SubCA, permitiéndonos solicitar certificados basados en esa plantilla.
Solicitamos un certificado para administrator@manager.htb usando la plantilla SubCA, apuntando al Domain Controller dc01.manager.htb. Después, emitimos la solicitud de certificado con el comando correspondiente.
Finalmente, ejecutamos el comando para recuperar el certificado emitido con el ID 22, lo que nos da el certificado solicitado y nos permite usarlo para autenticar como administrator@manager.htb o realizar otras acciones para escalar privilegios dentro del dominio.
Conprobaremos que se nos ha generado un archivo (administrator.pfx)
Con este comando autenticamos al usuario administrator usando un archivo de certificado PFX previamente obtenido, en este caso 'administrator.pfx'. El archivo PFX contiene tanto el certificado como la clave privada, lo que nos permite autenticarnos como el usuario administrator en el dominio manager.htb.
Especificamos la dirección IP del Domain Controller (DC) con la opción -dc-ip 10.10.11.236, que es el servidor al que se conectará para realizar la autenticación.
Ejecutamos el comando Impacket psexec para ejecutar comandos remotamente en 10.10.11.236 como administrator del dominio manager.htb, usando los NTLM hashes en lugar de la contraseña. Esto nos permite autenticar como administrador sin necesidad de conocer la contraseña en texto claro y ejecutar tareas remotas con privilegios elevados.
Comprobamos la flag de root.txt
Accederemos a y con Wappalyzer comprobaremos también las tecnologías del sitio web.
Dentro del resultado del análisis nos encuentra información sobre Active Directory Certificate Services en el cual nos reporta de posiblemente sea vulnerable, y nos indica que revisemos
Para consultar cómo funciona certipy-ad y las diferentes vulnerabilidades existentes podemos revisar en la siguiente página ->
