Haze
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Haze. Este resultado lo almacenaremos en un archivo llamado allPorts.
A través de la herramienta de extractPorts, la utilizaremos para extraer los puertos del archivo que nos generó el primer escaneo a través de Nmap. Esta herramienta nos copiará en la clipboard los puertos encontrados.
Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. Verificamos a través del resultado obtenido de que la máquina se trata de un Domain Controller (DC) por los puertos y servicios que se encuentran expuestos.
Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.
Accederemos a http://localhost y verificaremos el resultado en un formato más cómodo para su análisis.
Para empezar, crearemos una variable de entorno llamada IP en la cual el valor será la IP de la máquina Haze, para hacer referencia a esa dirección IP cada vez que pongamos $IP.
A través de la herramienta de netexec y ldapsearch enumeraremos el equipo para localizar más información. Entre la información obtenida, verificamos el hostname, versión del SO y el nombre del dominio.
Añadiremos en nuestro archivo /etc/hosts las entradas correspondientes para que a la hora de hacer referencia al dominio o el equipo nos responda correctamente a la dirección IP del equipo.
Por otro lado, también verificamos que el usuario guest se encuentra deshabilitado, con lo cual no podemos enumerar usuarios, recursos, etc.
Web Enumeration
En el resultado obtenido en Nmap, verificamos de la existencia de los puertos 8000 y 8089 que son puertos que normalmente utiliza Splunk para la interfaz web y la aomunicación entre instancias de Splunk.
Al realizar una enumeración de esos puertos con whatweb nos encontramos con las tecnologías que utiliza la aplicación web.
Al acceder a http://haze.htb:8000 nos encontramos con la interfaz administrativa de inicio de sesión a Splunk. Necesitamos credenciales de acceso para acceder a la interfaz, probamos con credenciales típicas pero no obtenemos reusltado.
Al acceder a http://haze.htb:8089 nos encontramos con la página web que utiliza Splunk para la comunicación entre las instancias que utiliza. Entre la información que disponemos, nos encontramos que utiliza la versión Splunk 9.2.1.
Esto puede proporcionar información adicional a un atacante debido que conoce la versión exacta de una aplicación, pudiendo buscar posibles vulnerabilidades reportadas que afecten a dicha versión.
Auth as paul.taylor
Splunk 9.2.1 Exploitation - Arbitrary Files Reads (CVE-2024-36991)
Realizando una búsqueda por Internet sobre esta versión para buscar posibles vulnerabilidades ya conocidas, nos encontramoscon diferentes vulnerabilidades. Entre las cuales la que más nos llama la atención es la reportada como CVE-2024-36991.
En Splunk Enterprise en Windows versiones por debajo de 9.2.2, 9.1.5, y 9.0.10, un atacante podría realizar un path traversal en el /modules/messaging/ endpoint en Splunk Enterprise en Windows. Esta vulnerabilidad sólo debería afectar a Splunk Enterprise en Windows.
Enel siguiente blog, nos detallan más en profundidad en relación a la vulnerabilidad de Path Traversal en la versión vulnerable de Splunk. Por otro lado, también ofrece un repositorio de GitHub en el que no smuestran un PoC para explotar dicha vulnerabilidad.
Durante la explotación de la vulnerabilidad CVE-2024-36991, logramos acceder al archivo passwd utilizado internamente por Splunk, ubicado en su directorio de instalación ($SPLUNK_HOME/etc/passwd). Aunque el sistema operativo es Windows, Splunk utiliza este archivo con un formato similar al clásico /etc/passwd de sistemas Unix/Linux para almacenar usuarios locales cuando no se utiliza LDAP como método de autenticación exclusivo.
Este archivo contiene los nombres de usuario locales, junto con sus hashes de contraseñas (SHA512-Crypt). Gracias a esto, pudimos extraer varios hashes y proceder a su análisis offline para intentar recuperar contraseñas válidas y acceder a la interfaz web de Splunk con privilegios administrativos.
Verificamos que el tipo de hash que obtenemos del $SPLUNK_HOME/etc/passwd se encuentra en SHA-512. Intentamos crackear estos hashes pero no logramos obtener resultado ninguno.
La vulnerabilidad de Path Traversal de esta versión de Splunk se realiza a través del siguiente PoC.
En este caso, pusimos a prueba para intentar listar un archivo del sistema Windows. En el resultado obtenido, verificamos que logramos obtener el archivo C:\Windows\win.ini realizando el Path Traversal.
También podemos listar otros archivos realizando el Path Traversal, como en este caso que pudimos listar el C:\Windows\System32\drivers\etc\hosts del sistema operativo Windows que levanta el servicio de Splunk, probablemente el mismo Domain Controller.
Leaking and Decrypting Splunk Credentials via Arbitrary File Read + splunksecrets
El siguiente objetivo será intentar listar archivos sensibles de configuración de Splunk para intentar obtener credenciales de acceso. El primer objetivo que teníamos presentes es el de server.conf ubicado normalmente en C:/Program Files/Splunk/etc/system/local/server.conf.
Dentro del archivo server.conf observamos parámetros como pass4SymmKey y sslPassword, los cuales están cifrados con una clave maestra interna de Splunk conocida como splunk.secret. Esta clave se genera automáticamente durante la instalación de Splunk y se guarda en el archivo:
En un blog que encontramos durante la fase de investigación, se mencionaba que el archivo splunk.secret suele estar ubicado en la ruta:
Con esta información, decidimos utilizar nuevamente la vulnerabilidad de Path Traversal para intentar acceder a dicho archivo. La petición fue exitosa y logramos obtener el contenido completo del archivo splunk.secret, el cual es utilizado por Splunk como clave maestra para cifrar y descifrar contraseñas en archivos de configuración internos:
Además del archivo server.conf, Splunk también utiliza otros archivos de configuración sensibles. Uno de ellos es authentication.conf, el cual nos resultó especialmente interesante ya que no solo contiene parámetros de autenticación, sino también credenciales asociadas a un usuario de dominio. Este archivo normalmente se encuentra ubicado en:
En este archivo se mostraba el usuario de dominio Paul Taylor, configurado como bindDN, junto con su contraseña cifrada. Esa contraseña estaba protegida con el sistema interno de Splunk, usando la clave maestra splunk.secret que ya habíamos conseguido antes.
Para desencriptar la contraseña cifrada, utilizamos la herramienta splunksecrets, la cual instalamos directamente desde su repositorio oficial en GitHub. Esta herramienta nos permite descifrar valores protegidos por Splunk utilizando el archivo splunk.secret como clave maestra.
Descargamos el archivo splunk.secret mediante Path Traversal y lo guardamos localmente para usarlo con la herramienta splunksecrets, la cual instalamos desde su repositorio oficial. Con esta herramienta, desencriptamos la contraseña cifrada del usuario Paul Taylor que habíamos encontrado previamente en el archivo authentication.conf.
El comando nos devolvió la contraseña en texto plano: Ld@p_Auth_Sp1unk@2k24.
Username Enumeration: NameMash Generation and Kerbrute Validation
Disponemos de unas credenciales que parecen estar relacionadas con LDAP, pero no disponemos del nombre de usuario válido de Paul Taylor, solamente su nombre y apellido. Por dicho motivo, crearemos un archivo employees.txt en el cual ingresemos el nombre y apellido del único usuario que disponemos para posteriormente crear un diccionario de posibles nombres de usuarios.
A través de la herramienta de namemash.py nos encargaremos de generar un listado de posibles usuarios a través de la combinación del nombre y apellido obtenido.
Para validar los posibles nombres de usuario generados previamente, utilizamos la herramienta Kerbrute, que dispone de un módulo específico para enumerar usuarios a través de fuerza bruta contra el servicio Kerberos (puerto 88). Esta técnica nos permite identificar usuarios válidos sin necesidad de conocer sus contraseñas.
Antes de ejecutar la herramienta, ajustamos el archivo de configuración /etc/krb5.conf para evitar problemas de resolución con el dominio y asegurar que Kerberos funcione correctamente. Dejamos el archivo con la siguiente configuración:
Además, para evitar el error KRB_AP_ERR_SKEW relacionado con la diferencia horaria en Kerberos, sincronizamos la hora de nuestra máquina con la del controlador de dominio (DC) utilizando el siguiente comando.
Este paso es clave en ataques relacionados con Kerberos, ya que una diferencia de tiempo superior a 5 minutos entre el cliente y el servidor puede bloquear la autenticación.
Con el diccionario generado previamente, ejecutamos Kerbrute para validar los posibles nombres de usuario contra el servicio Kerberos del dominio haze.htb. Utilizamos el módulo userenum, que nos permite comprobar qué usuarios existen en el dominio sin necesidad de conocer sus contraseñas.
La herramienta nos confirmó que el usuario paul.taylor@haze.htb era válido. Esto validaba que nuestra estrategia de generación de nombres había funcionado y nos daba una cuenta real sobre la cual enfocar los siguientes pasos del ataque.
Probamos de autenticarnos con NetExec mediante LDAP con las credenciales y el nombre de usuario obtenido, y verificamos que las credenciales son válidas para dicho usuario.
Por otro lado, también comprobamos que a través del usuario paul.taylor no podemos conectarnos al Domain Controller a través de WinRM, ya que probablemente no forme parte del grupo Remote Management Users o sea administrador local del equipo.
Shell as mark.adams
RID Cycling Attack (ridenum)
Como ya teníamos credenciales válidas del dominio (paul.taylor), lanzamos un ataque de RID Cycling con la herramienta ridenum para enumerar usuarios y equipos del dominio a través de los RIDs. Esta técnica se basa en que los identificadores de los objetos del dominio siguen un patrón secuencial dentro del SID base.
La herramienta identificó el SID base del dominio (S-1-5-21-323145914-28650650-2368316563) y, a partir de ahí, fue enumerando RIDs y recuperando cuentas reales del dominio. Entre los resultados obtenidos encontramos usuarios y equipos como Administrator, krbtgt, mark.adams, edward.martin, alexander.green y el equipo Haze-IT-Backup$, lo que nos permitió obtener un listado de usuarios válidos.
Nos copiaremos el resultado obtenido anteriormente en un archivo llamado users.txt, y a través de expresiones regulares nos quedaremos solamente con los nombres de usuarios.
Password Spraying using Kerbrute
A través de la herramienta de Kerbrute realizamos un Password Spraying para verificar si la contraseña obtenida anteriormente se reutilizaba para alguno de los usuarios obtenidos.
Como resultado, verificamos que las credenciales son válidas para el usuario paul.taylor (que disponíamos principalmente) y de un nuevo usuario mark.adams.
Abusing WinRM - EvilWinRM
Las credenciales son válidas, ya que a través de Kerbrute realiza la validación a través de la autenticación de Kerberos. Por otro lado, verificamos si a través de este usuario podíamos autenticarnos mediante WinRM al Domain Controller.
Comprobamos que podemos acceder al DC, pero con este usuario aún no obtenemos la flag user.txt.
Auth as Haze-IT-Backup$
BloodHound Enumeration
En este punto, buscamos continuar escalando privilegios dentro del dominio a través de movimiento lateral. Para ello, utilizamos BloodHound, una herramienta que nos permite mapear relaciones dentro del dominio y detectar posibles vectores de escalada de privilegios.
Con las credenciales válidas del usuario mark.adams, lanzamos la enumeración completa utilizando bloodhound-python, que se encarga de recolectar toda la información necesaria a través de LDAP y Kerberos
Al analizar la información recolectada con BloodHound, observamos que el usuario mark.adams@haze.htb formaba parte de varios grupos, entre ellos Remote Management Users, lo que nos explicaba por qué fue posible conectarnos mediante WinRM de forma remota.
Además, también era miembro del grupo gMSA_Managers, lo cual nos llamó la atención porque podría estar relacionado con la gestión de cuentas de servicio administradas (gMSA), y representar un posible vector de escalada lateral o privilegios si alguna de esas cuentas está mal configurada.
Desde el mismo Domain Controller autenticados como mark.adams verificamos la misma información de los grupos a los cuales pertenece dicho usuario.
Privilege Abuse via Set-ADServiceAccount and ACL Modification to Dump gMSA Password
Como formábamos parte del grupo gMSA_Managers, pensamos que quizás podríamos leer la contraseña de alguna cuenta gMSA del dominio. Para comprobarlo, utilizamos PowerView.py, una versión en Python de la herramienta PowerView, que permite realizar consultas LDAP de forma sencilla desde fuera del entorno Windows.
Nos conectamos con las credenciales de mark.adams y ejecutamos el módulo Get-GMSA, que automáticamente intenta recuperar las contraseñas de cuentas gMSA a las que tengamos permiso de lectura.
El resultado mostró una cuenta gMSA asociada al equipo Haze-IT-Backup$, pero en este caso el campo PrincipalsAllowedToRead indicaba que solo los Domain Admins tenían permisos para acceder a su contraseña, por lo que de momento no podíamos leerla directamente.
Más adelante veremos cómo aprovechamos nuestra pertenencia al grupo gMSA_Managers para modificar esta configuración y obtener acceso a esa cuenta.
El cmdlet Set-ADServiceAccount permite modificar las propiedades de una cuenta de servicio administrada (MSA o gMSA) dentro de Active Directory. Uno de sus parámetros más importantes es -PrincipalsAllowedToRetrieveManagedPassword, que define qué usuarios o grupos tienen permiso para leer la contraseña de una cuenta gMSA.
Esta propiedad es clave, ya que si un usuario tiene permiso de lectura sobre una gMSA, puede recuperar su contraseña en texto plano y utilizarla para autenticarse como esa cuenta. Por defecto, solo ciertos grupos privilegiados (como Domain Admins) tienen ese permiso. Sin embargo, si tenemos privilegios suficientes, podemos modificar esa propiedad y asignarnos como entidad autorizada para obtener la contraseña de la gMSA.
Como ya sabíamos que solo los Domain Admins tenían permisos para leer la contraseña de la cuenta gMSA Haze-IT-Backup$, aprovechamos nuestra posición en el dominio para modificarlos a nuestro favor. Subimos PowerView.ps1 a través de Evil-WinRM y lo importamos en la sesión.
Luego, utilizamos el cmdlet Set-ADServiceAccount para asignar al usuario mark.adams como principal autorizado para leer la contraseña de esa gMSA.
Para asegurarnos de que teníamos los permisos suficientes para que esto surtiera efecto, también agregamos una ACL personalizada sobre el objeto del equipo con el derecho ResetPassword.
Una vez modificados los permisos con Set-ADServiceAccount y aplicada la ACL con Add-DomainObjectAcl, volvimos a ejecutar PowerView.py con el usuario mark.adams. Esta vez, al lanzar el módulo Get-GMSA, conseguimos acceder correctamente a la contraseña de la cuenta gMSA Haze-IT-Backup$.
Verificamos que las credenciales de la cuenta gMSA Haze-IT-Backup$ son válidas para autenticarse por LDAP al dominio.
Shell as edward.martins
BloodHound Enumeration
Esta máquina está planteada para que vayamos recolectando información con BloodHound cada vez que consigamos nuevas credenciales. Esto nos permite ir ampliando la visibilidad sobre el dominio a medida que progresamos en el compromiso.
Después de obtener la contraseña en texto plano de la cuenta gMSA Haze-IT-Backup$, la utilizamos para lanzar una nueva recolección con BloodHound.py, esta vez autenticándonos con su hash NTLM directamente.
La enumeración se completó correctamente y nos devolvió información adicional del dominio, incluyendo nuevos usuarios, grupos y objetos que no habíamos visto en recolecciones anteriores. Esto reforzaba la idea de ejecutar BloodHound con cada cuenta obtenida, ya que cada una puede tener visibilidad distinta sobre el entorno.
Durante el análisis en BloodHound, detectamos un path interesante de movimiento lateral que podíamos aprovechar. La cuenta HAZE-IT-BACKUP$, que ya controlábamos, tenía el permiso WriteOwner sobre el grupo SUPPORT_SERVICES@HAZE.HTB. Esto nos permitía tomar control de dicho grupo.
A su vez, los miembros de SUPPORT_SERVICES tenían permisos sobre el usuario edward.martin@haze.htb, específicamente:
ForceChangePassword, lo que permitiría cambiarle la contraseña (aunque esto no es recomendable en un pentest real porque genera alertas).AddKeyCredentialLink, lo que nos permitía realizar un ataque de Shadow Credentials para autenticarnos como él sin modificar su contraseña.
Este path nos abría la posibilidad de escalar privilegios lateralmente hacia Edward Martin de forma sigilosa, usando la técnica de Shadow Credentials, sin necesidad de generar ruido en el entorno.
Abusing WriteOwner Privileges over a group (bloodyAD)
Tras identificar que la cuenta HAZE-IT-BACKUP$ tenía el privilegio WriteOwner sobre el grupo SUPPORT_SERVICES, decidimos abusar de esta configuración para tomar control total del grupo.
Primero cambiamos el propietario del objeto al propio HAZE-IT-BACKUP$, y luego le asignamos permisos GenericAll, lo que nos dio control total sobre el grupo. Esto fue clave, ya que SUPPORT_SERVICES tenía privilegios sobre el usuario edward.martin, permitiéndonos abusar de ellos más adelante para ejecutar un ataque de Shadow Credentials de forma silenciosa y sin cambiarle la contraseña
Abusing AddKeyCredentialLink to Perform Shadow Credentials Attack
Como comentamos anteriormente, el grupo SUPPORT_SERVICES tenía permisos sobre el usuario edward.martin, concretamente los privilegios ForceChangePassword y AddKeyCredentialLink. Aunque podríamos haber cambiado su contraseña directamente, en un entorno real esto no es recomendable ya que generaría alertas y el usuario podría darse cuenta de inmediato.
En su lugar, optamos por abusar del permiso AddKeyCredentialLink, que nos permite realizar un ataque de Shadow Credentials. Esta técnica consiste en asociar una clave pública controlada por nosotros al objeto del usuario, lo que nos permite autenticarnos como él mediante Kerberos (PKINIT) sin necesidad de conocer su contraseña, de forma totalmente silenciosa.
Antes de explotar el permiso AddKeyCredentialLink, lo primero que hicimos fue añadir la cuenta HAZE-IT-BACKUP$ como miembro del grupo SUPPORT_SERVICES, ya que este grupo era el que tenía los privilegios sobre el usuario edward.martin. Al formar parte del grupo, nuestra cuenta gMSA heredaría automáticamente esos permisos.
Con esto, ya teníamos los permisos necesarios para ejecutar el ataque de Shadow Credentials sobre edward.martin usando AddKeyCredentialLink.
Una vez que añadimos la cuenta HAZE-IT-BACKUP$ al grupo SUPPORT_SERVICES y obtuvimos los privilegios necesarios, ejecutamos el ataque de Shadow Credentials utilizando Certipy. Esta técnica nos permitió inyectar una clave controlada por nosotros al objeto del usuario edward.martin, y luego autenticarnos como él sin necesidad de conocer su contraseña.
Certipy generó un certificado, lo asoció al usuario objetivo y obtuvo satisfactoriamente un TGT (Ticket Granting Ticket) como edward.martin. Además, extrajo su hash NTLM.
Finalmente, Certipy restauró automáticamente los Key Credentials originales del usuario para no dejar rastros, lo que convierte esta técnica en una opción muy sigilosa para moverse lateralmente en entornos reales.
Abusing WinRM - EvilWinRM
Revisamos nuevamente en BloodHound y comprobamos que este nuevo usuario que disponemos, forma parte del grupo Remote Management Users con lo cual podríamos conectarnos al Domain Controller mediante WinRM.
Nos conectamos al DC a través de la herramienta evil-winrm realizando Pass-The-Hash (PtH) con el hash NTLM obtenido. Verificamos que finalmente obtenemos la flag user.txt
Shell as alexander.green
Abusing Backup_Reviewers Group Membership to Access Splunk Backup
Volviendo a BloodHound, nos encontramos que el usuario edward.martin forma parte de un grupo llamado Backup_Reviewers, un grupo de seguridad no nativo de Windows, que parece estar relacionado con algún tipo de acceso a backups.
Enumerando los directorios del Domain Controller, nos encontramos con un directorio ubicado en C:\Backups\Splunk en el cual contenía un archivo comprimido .zip de una copia de seguridad de Splunk. Nos descargaremos el comprimido a través de evil-winrm con el módulo download para verificar si en este backup habían credenciales que nos puedan servir o otra información útil.
Descomprimiremos el archivo comprimido descargado y verificamos que es una copia de seguridad de Splunk de la instalación. Posiblemente disponga de credenciales y archivos sensibles como authentication.conf y splunk.secret como obtuvimos anteriormente en la intrusión.
Accessing Splunk Admin Interface via Decrypted Backup Credentials using splunksecrets
Buscaremos a través del comando find partiendo desde el directorio actual si encontramos el archivo splunk.secret y authentication.conf. En el resultado obtenido, comprobamos la existencia de ambos archivos.
El archivo splunk.secret que disponemos es diferente al encontrado anteriormente en la fase inicial de la intrusión.
Por otro lado, también nos encontramos con otro archivo interesante: authentication.conf, ubicado en la ruta var/run/splunk/confsnapshot/baseline_local/system/local/authentication.conf. Este archivo contenía la configuración de autenticación LDAP utilizada por Splunk. Lo más relevante fue que, además del esquema de autenticación, se revelaba un nuevo usuario de dominio en la sección [Haze LDAP Auth].
Esto nos indicaba que la cuenta alexander.green se estaba utilizando como bindDN para el acceso LDAP, y que su contraseña estaba cifrada. Además, también quedaba claro que esta cuenta formaba parte del grupo Splunk_Admins, lo cual sugiere que tiene privilegios elevados dentro de la plataforma Splunk.
Teniendo en cuenta que ya habíamos recuperado previamente el archivo splunk.secret, podíamos ahora proceder a descifrar esta contraseña usando splunksecrets, tal como hicimos con el usuario Paul Taylor.
Accedemos al directorio donde encontramos el splunk.secret del backup de Splunk.
Con el archivo splunk.secret que habíamos obtenido previamente del backup de Splunk, y el valor cifrado encontrado en el authentication.conf, procedimos a desencriptar la contraseña del usuario alexander.green utilizando la herramienta splunksecret.
El proceso nos devolvió la contraseña en texto plano: Sp1unkadmin@2k24.
Esto nos daba acceso como el usuario alexander.green, quien además formaba parte del grupo Splunk_Admins, por lo que podíamos asumir que tenía permisos elevados dentro de la plataforma Splunk, permitiéndonos acceder a funciones sensibles o configuración crítica desde la interfaz web.
Comprobamos que estas credenciales no son válidas para autenticarse por LDAP con el usuario alexander.green.
Accederemos a http://haze.htb:8000/ y trataremos de ingresar a Splunk con las siguientes credenciales de acceso: admin:Sp1unkadmin@2k24
Verificamos que finalmente nos encontramos dentro de la interfaz administrativa de Splunk y nos encontramos como el usuario Administrator.
Splunk Reverse Shell through app
Nos encontramos un repositorio de GitHuben el cual nos ofrece la creación de un paquete de Splunk para lograr obtener una Reverse Shell.
Una vez descargado el repositorio de GitHub, veremos la estructura de los archivos que necesitaremos.
Modificaremos el archivo run.ps1 para indicarle nuestra dirección IP y el puerto donde estaremos en escucha.
Crearemos el archivo comprimido reverse_shell_splunk.tgz y lo renombraremos con extensión .spl.
Nos pondremos en escucha con nc para recibir la Reverse Shell.
Accederemos a http://haze.htb:8000/en-US/manager/search/apps/local para instalar nuestra app con la Reverse Shell. Dentro de este panel, le daremos a la opción de Install app from file.
Subiremos nuestro archivo reverse_shell_splunk.spl y le daremos a la opción de Upload para subirlo a Splunk la app maliciosa.
Verificaremos que nos indica que la aplicación se ha instalado correctamente dentro de Splunk.
Después de un breve tiemo, verificamos que se ha ejecutado la reverse shell de la app maliciosa a través del File Upload vulnerable de esta versión de Splunk. Nos encontramos en el Domain Controller autenticados como el usuario alexander.green.
Privilege Escalation
Abusing SeImpersonatePrivilege (EfsPotato)
Al revisar los privilegios habilitados para el usuario dentro del sistema, identificamos que disponía del privilegio SeImpersonatePrivilege, lo cual nos abría la posibilidad de realizar una escalada de privilegios local mediante técnicas conocidas como EfsPotato, PrintSpoofer o similares.
Realizando un systeminfo para ver la versión del Domain Controller, nos encontramos que tiene como sistema operativo un Microsoft Windows Server 2022 Standard. Por lo tanto, la herramienta de PrintSpoofer no nos servirá en este caso.
En este caso, podemos hacer uso de EfsPotato que abusa de este privilegio de SeImpersonatePrivilege.
En el repositorio del binario de EfsPotato, deberemos de compilar el binario desde el equipo. Para ello, primero revisaremos las versiones de Microsoft.Net que dispone el equipo víctima.
Nos descargaremos el archivo EfsPotato.cs del proyecto de GitHub y levantaremos un servidor web con Python para compartir este archivo al DC.
Desde el DC nos descargaremos el archivo EfsPotato.cs que estamos compartiendo y lo almacenaremos en C:\ProgramData.
Compilaremos elEfsPotato.cs y verificaremos que se ha creado el archivo EfsPotato.exe.
Por otro lado, también deberemos de disponer del binario nc.exe que compartiremos a través del servidor web.
Nos descargaremos el binario de nc.exe en la ruta de C:\ProgramData.
Nos pondremos en escucha con nc para recibir la Reverse Shell.
Ejecutaremos el EfsPotato.exe para convertirnos en usuario Administrador y ejecutaremos el nc.exe para enviarnos una Reverse Shell, este comando lo ejecutará el usuario Administrador.
Verificamos que hemos ganado acceso al equipo que nos encontrábamos y nos hemos convertido en usuario NT AUTHORITY\SYSTEM. Finalmente podemos leer la flag root.txt.
Dumping NTLM Hash of Administrator via DCSync using Mimikatz
En el punto anterior, nos encontramos como el usuario NT AUTHORITY\SYSTEM, que es la cuenta más privilegiada del sistema operativo local, pero aún no somos Domain Admin y es lo que nos interesa para obtener control total sobre el dominio haze.htb.
Con lo cual, podemos aprovecharnos que somos NT AUTHORITY\SYSTEM para utilizar Mimikatz y hacer un DCSync para obtener el hash NTLM del usuario Administrator que será el Domain Admin.
Teniendo esto presente, dispondremos del binario de Mimikatz.exe en nuestro equipo y lo compartiremos a través de un servidor web.
Nos descargaremos mimikatz que compartimos y lo almacenaremos en C:\ProgramData.
Con nuestra shell como NT AUTHORITY\SYSTEM, ejecutamos Mimikatz en la máquina víctima para llevar a cabo un ataque DCSync, con el objetivo de obtener el hash NTLM del usuario Administrator, quien es miembro del grupo Domain Admins. Esta técnica simula el comportamiento de un controlador de dominio y permite extraer los hashes de cualquier usuario del dominio si se tienen los privilegios adecuados.
La ejecución fue exitosa y nos devolvió múltiples credenciales asociadas a la cuenta Administrator, entre ellas su hash NTLM, que nos permitía autenticarnos directamente usando Pass-the-Hash.
Con este hash ya en nuestro poder, estábamos en condiciones de autenticarnos como Domain Admin en cualquier equipo del dominio haze.htb, consolidando completamente el compromiso del entorno y demostrando un control total sobre la infraestructura.
Gaining Administrator Access Using NTLM Hash Retrieved via DCSync
Con el hash NTLM del usuario Administrator obtenido previamente mediante el ataque DCSync con Mimikatz, realizamos un acceso remoto al controlador de dominio DC01 utilizando la técnica de Pass-the-Hash. Primero, verificamos el acceso con NetExec autenticándonos a WinRM, verificamos que es correcto el hash NTLM y nos sale como Pwn3d!.
Realizamos nuevamente Pass-The-Hash (PtH) para autenticarnos al WinRM como usuario Administrator y finalmente obtenemos el acceso al DC como Domain Admin, pudiendo leer la flag root.txt.
Última actualización
¿Te fue útil?