> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/writes-ups/tryhackme/hard/k2.md). # K2 ## Información de la máquina

En esta ocasión exploramos la **sala K2 de TryHackMe**, una room categorizada como de dificultad **difícil**, compuesta por **tres máquinas**: una máquina **Linux** y dos correspondientes a un entorno de **Active Directory (AD)**. Cada máquina representa un campamento en una expedición hacia la cima: **Base Camp**, **Middle Camp**, y **Summit Camp**. A través de este write-up, documentamos todas las fases clásicas de un pentest: reconocimiento, explotación, escalada de privilegios, post-explotación y movimientos laterales, utilizando una combinación de técnicas web, enumeración en entornos Windows y explotación de vulnerabilidades en aplicaciones personalizadas y servicios comunes. Cada máquina ofrece desafíos variados: desde la explotación de vulnerabilidades web como **XSS y SQLi**, hasta el abuso de **servicios de dominio Active Directory** como **Kerberos** y **WinRM**, sin dejar de lado la importancia del reconocimiento, la creación de diccionarios personalizados y el aprovechamiento de malas prácticas administrativas. *** ## 1. Base Camp ### Reconocimiento Base Camp Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

**1. `-p-` → Escaneo de todos los puertos (1-65535)** Por defecto, `nmap` solo escanea los **1000 puertos más comunes**.\ Con `-p-`, forzamos a que escanee **los 65,535 puertos** de la máquina objetivo, lo que puede ser útil para encontrar servicios que corren en puertos poco convencionales. **2. `--open` → Filtrar solo los puertos abiertos** Cuando escaneamos un sistema, muchos puertos pueden estar cerrados o filtrados por un firewall.\ Este parámetro hace que `nmap` **solo muestre los puertos abiertos**, reduciendo el ruido y facilitando el análisis. **3. `-sS` → Stealth Scan (Escaneo Sigiloso con SYN)** Es conocido como **"TCP SYN Scan"**, y funciona de la siguiente manera: * `nmap` envía un paquete **SYN** (solicitud de conexión). * Si el puerto está abierto, el servidor responde con **SYN-ACK**. * En lugar de completar la conexión con un **ACK**, `nmap` responde con un **RST (Reset)**, interrumpiendo la comunicación. **4. `--min-rate 5000` → Velocidad mínima de paquetes (5000 por segundo)** Por defecto, `nmap` ajusta dinámicamente la velocidad de los paquetes según la respuesta de la red.\ Con `--min-rate 5000`, obligamos a `nmap` a **no enviar menos de 5000 paquetes por segundo**, acelerando el escaneo. **5. `-n` → Deshabilitar resolución DNS** Normalmente, `nmap` intenta resolver el nombre de dominio de las IPs escaneadas (DNS lookup).\ Con `-n`, evitamos esta resolución de nombres, lo que **acelera el escaneo** y evita que los servidores DNS registren nuestra actividad. **6. `-Pn` → Omitir detección de host (Host Discovery Off)** Por defecto, `nmap` envía paquetes ICMP (ping) para ver si un host está activo antes de escanearlo.\ Si un firewall bloquea los pings, `nmap` puede marcarlo como "host down" y no escanearlo. **7. `-oG`** **→ Exportar el contenido en formato grepeable** Todo el resultado del escaneo lo exportaremos en un archivo llamado **`allPorts` .** El escaneo revela dos puertos abiertos

**1. `-p22,80` → Escaneo de puertos específicos** Con `-p22,80`, le indicamos que **solo** escanee los puertos que queremos **2. `-sCV` → Escaneo de versiones y scripts básicos** Este parámetro en realidad es **dos combinaciones en una**: * **`-sC`** → Activa los **NSE scripts por defecto** en `nmap` (similar a usar `--script=default`).\ Ejecuta scripts básicos para enumerar información del servicio detectado, como banners, versiones, etc. * **`-sV`** → Realiza **fingerprinting de versiones**, intentando identificar la versión exacta del software en cada puerto abierto. **3. `-oN` → Guardar el resultado en formato Normal** Por defecto, `nmap` muestra los resultados en pantalla, pero con **`-oN targeted`**, guardamos el resultado en un archivo en **formato legible para humanos**. Al acceder a la web, vemos que se nos redirige a `k2.thm`, por lo que añadimos el dominio al /etc/hosts y ya obtenemos acceso a la página.

### Fuzzing vhost Tras la fase de enumeración web, se realiza un fuzzing de subdominios utilizando **ffuf**, identificando dos hosts virtuales configurados en el servidor: `admin.k2.thm` e `it.k2.thm`.

Para poder resolver estos subdominios desde la máquina atacante, se añaden al archivo `/etc/hosts` asociándolos a la IP correspondiente de la víctima

Al visitar `admin.k2.thm`, se presenta un formulario de login que no es accesible sin credenciales válidas.

En cambio, en `it.k2.thm` se ofrece una opción de registro de usuarios.

Tras completar el registro, se obtiene acceso a la aplicación.

La aplicación permite la creación de tickets mediante un formulario sencillo. Esto sugiere que dichos tickets podrían ser revisados por un administrador

### XSS cookie hijacking WAF bypass Se realizaron varios intentos de inyección XSS en el formulario de creación de tickets, pero fueron bloqueados por el **WAF (Web Application Firewall)**. El WAF es un sistema de defensa que protege las aplicaciones web frente a ataques como XSS, SQL Injection, o CSRF, mediante el análisis y filtrado del tráfico HTTP. Investigando alternativas, se encontró un payload que consigue evadir la protección del WAF: ```html ``` Este script crea un objeto de tipo **Image** que no es bloqueado por el WAF. La propiedad `src` envía una petición al servidor controlado por el atacante, incluyendo en la URL la cookie actual codificada en base64 mediante `btoa`

Iniciando un servidor HTTP en la máquina atacante con y pudemos capturar la cookie de sesión del administrador cuando visualiza el ticket malicioso.

Posteriormente, se decodifica la cookie obtenida en base64 para obtenerla en texto plano y reutilizarla en el navegador.

Para utilizar la cookie robada, se crea una cookie de sesión en el navegador(no existente) cuando se accede a `admin.k2.thm` por la que se ha capturado y descifrado previamente.

Al recargar la página, se accede directamente al panel de administración sin necesidad de pasar por el formulario de login. El panel muestra una tabla con tres registros, lo que indica que la información mostrada probablemente proviene de una base de datos.

### SQLi Dentro del panel de administración, se encuentra un campo de búsqueda que permite filtrar tickets por su título. Al introducir el nombre exacto de un ticket, la tabla solo muestra el registro correspondiente, lo que evidencia que se ejecuta una consulta SQL basada en el input proporcionado por el usuario. ``` i got it ```

Para comprobar la presencia de una inyección SQL, se introduce el siguiente payload: ```sql i got it'OR '1'='1'-- - ``` Esta inyección modifica la consulta original añadiendo una condición que siempre será verdadera (`'1'='1'`), y el doble guion seguido de un espacio (`-- -`) comenta el resto de la consulta. Como resultado, se muestran todos los registros existentes, confirmando la existencia de una vulnerabilidad de tipo SQLi.

Para validar el número de columnas y la posibilidad de realizar una inyección con **UNION**, se utiliza el siguiente payload: ```sql i got it' UNION SELECT 1,2,3 -- - ``` Esto permite verificar que la consulta original tiene tres columnas, ya que no se genera error y se muestran los valores `1`, `2`, `3` en la tabla.

Una vez confirmado el número de columnas, se explora el esquema de la base de datos con la siguiente inyección: ``` i got it' UNION SELECT table_name,2,3 FROM information_schema.tables WHERE table_schema=database() -- - ``` Esto devuelve el nombre de todas las tablas presentes en la base de datos actual, resultando en tres tablas: * `admin_auth` * `auth_users` * `tickets`

Para enumerar las columnas de la tabla `admin_auth`, se utiliza: ```sql i got it' UNION SELECT column_name,2,3 FROM information_schema.columns WHERE table_name='admin_auth' -- - ``` Esto devuelve el nombre de las columnas contenidas en dicha tabla.

Finalmente, se extraen los datos almacenados en la tabla con: ```sql i got it' UNION SELECT email, admin_password, admin_username FROM admin_auth -- - ``` Obteniendo así los correos electrónicos, contraseñas y nombres de usuario administradores registrados en la aplicación.

Los datos obtenidos se guardan en un archivo local para analizarlos y separarlos en credenciales y usuarios

### Auth SSH Utilizando la herramienta **hydra**, se realiza un ataque de fuerza bruta contra el servicio SSH de la máquina. A partir de las credenciales extraídas anteriormente, se consigue acceso como el usuario **james**.

Se establece una sesión SSH exitosa, obteniendo así acceso al sistema como el usuario **james**.

### Privilege escalation Al enumerar el sistema, se identifica la existencia de otro usuario llamado **rose**. También se verifica que el usuario **james** pertenece al grupo **adm**, lo que permite leer ciertos archivos de logs ubicados en `/var/log/`.

Revisando el archivo `/var/log/auth.log`, se encuentran credenciales en texto plano que han sido registradas por error en un login.

Aunque las credenciales obtenidas no permiten iniciar sesión directamente como **rose**, sí funcionan para escalar privilegios a **root**, consiguiendo el control total del sistema.

### Post-Explotación Consultando el archivo `/etc/passwd`, se obtienen los nombres completos de los usuarios presentes en el sistema: * **Rose Bud** * **James Bold**

Además, al revisar el archivo `.bash_history` del usuario **rose**, se encuentra su contraseña en texto claro, evidenciando una mala práctica de seguridad

*** ## 2. Middle Camp ### Reconocimiento Middle Camp Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

**1. `-p` → Escaneo de puertos específicos** Con `-p`, le indicamos que **solo** escanee los puertos que queremos **2. `-sCV` → Escaneo de versiones y scripts básicos** Este parámetro en realidad es **dos combinaciones en una**: * **`-sC`** → Activa los **NSE scripts por defecto** en `nmap` (similar a usar `--script=default`).\ Ejecuta scripts básicos para enumerar información del servicio detectado, como banners, versiones, etc. * **`-sV`** → Realiza **fingerprinting de versiones**, intentando identificar la versión exacta del software en cada puerto abierto. **3. `-oN` → Guardar el resultado en formato Normal** Por defecto, `nmap` muestra los resultados en pantalla, pero con **`-oN targeted`**, guardamos el resultado en un archivo en **formato legible para humanos**.

### Discover Usernames A partir de la máquina anterior ya conocíamos los nombres completos de dos usuarios: **Rose Bud** y **James Bold**.

Para generar posibles combinaciones de nombres de usuario a partir de sus nombres completos, se utiliza la herramienta **username-anarchy**, que automatiza la creación de patrones comunes (como iniciales, nombres completos, combinaciones con puntos, etc.). {% embed url="" %} Todos los nombres generados se almacenan en un archivo de texto para facilitar pruebas posteriores.

A continuación, se emplea la herramienta **kerbrute** para validar qué nombres de usuario existen realmente en el dominio mediante el método de enumeración por Kerberos. {% embed url="" %} El resultado confirma la existencia de dos usuarios válidos: * `r.bud` * `j.bold`

### Auth r.bud Se prueban las credenciales descubiertas anteriormente junto con las contraseñas de la máquina previa. De esta forma, se consigue acceso válido para el usuario **r.bud**, utilizando la contraseña previamente obtenida de **rose**. Al verificar los servicios disponibles, se observa que el puerto **WinRM** está abierto y se permite el acceso mediante estas credenciales, confirmado por el mensaje típico de éxito `(Pwned!)`.

Utilizando la herramienta **Evil-WinRM**, que permite la conexión remota a través de WinRM en sistemas Windows, se establece acceso interactivo como **r.bud**.

### Discover password j.bold Se encuentran dos archivos `.txt` que contienen pistas o patrones para deducir la contraseña del usuario **j.bold**. Se indica que la contraseña se construye a partir de ciertas combinaciones definidas en dichos archivos.

Para automatizar la generación de todas las combinaciones posibles basadas en estos patrones, se crea un script en Python que produce un archivo `passwords.txt` con todas las variantes.

Posteriormente, se realiza un ataque de fuerza bruta dirigido con **kerbrute**, especificando el usuario `j.bold` y probando todas las contraseñas generadas.

Tras un tiempo de ejecución, se consigue obtener la contraseña correcta: ``` j.bold : #8rockyou ``` ### Bloodhound Una vez se dispone de credenciales válidas, se procede a enumerar el dominio Active Directory utilizando la herramienta **BloodHound**, junto con **nxc** (una herramienta para recolectar datos de un dominio), ejecutando el parámetro `--bloodhound` para generar los archivos necesarios que luego se analizarán en la interfaz de BloodHound.

Siguiendo la documentación oficial, se instala y configura BloodHound para procesar la información obtenida. {% embed url="" %} Durante el análisis, se detecta que el usuario **j.bold** es miembro de un grupo que tiene el permiso **GenericAll** sobre el usuario **j.smith**. El permiso **GenericAll** en Active Directory otorga **control total sobre un objeto**, lo que permite modificar propiedades como la contraseña o la pertenencia a grupos.

### Force Change Password El permiso **GenericAll** sobre un usuario en Active Directory permite, entre otras acciones, modificar su contraseña sin necesidad de conocer la anterior. Esto se debe a que el propietario de este permiso posee control total sobre ese objeto AD. Utilizando esta ventaja, se cambia la contraseña del usuario **j.smith** por una nueva definida por nosotros.

Tras modificarla, se intenta iniciar sesión mediante **WinRM** con la nueva contraseña y se confirma el acceso exitoso, visualizando el mensaje `(Pwned!)`.

Ahora se dispone de acceso como **j.smith**, lo que permite obtener la primera flag del sistema.

### Auth Administrator -> Group Backup Operator Para la escalada final de privilegios, se realiza una enumeración de los grupos a los que pertenece **j.smith**, y se descubre que es miembro del grupo **Backup Operators**. En entornos Windows, los miembros de este grupo tienen la capacidad de **realizar backups de cualquier archivo, incluso aquellos protegidos o restringidos como el registro del sistema o la SAM**, sin necesidad de ser administradores.

Aprovechando este privilegio, se extraen los archivos del registro necesarios: * **SAM**: contiene los hashes de las contraseñas de los usuarios locales. * **SYSTEM**: contiene las claves de cifrado para descifrar esos hashes.

Estos archivos se exportan en formato `.reg`, se transfieren a la máquina Kali y se procesan con la herramienta **impacket-secretsdump**, que permite extraer los hashes NTLM de las contraseñas.

Con el hash NTLM del usuario **Administrator**, se ejecuta un **Pass-The-Hash (PTH)** usando **Evil-WinRM**, lo que permite autenticarse como administrador sin necesidad de conocer la contraseña en texto claro. Finalmente, se obtiene acceso como **Administrator**, alcanzando el máximo privilegio en la máquina.

*** ## 3. The Summit ### Reconocimiento The Summit

### Shell j.smith Probamos el hash NTLM del usuario administrador que conseguimos en una máquina anterior, pero en lugar de usarlo con ese mismo usuario, lo utilizamos con el usuario **j.smith**.\ Para verificar si las credenciales son válidas, usamos la herramienta **NetExec (nxc)** contra el servicio **WinRM (Windows Remote Management)**. Esto permite comprobar autenticaciones remotas en Windows.\ Al hacerlo, el resultado muestra el mensaje **(Pwned!)**, lo que indica que la autenticación fue exitosa.

Con las credenciales válidas de j.smith, accedemos al sistema utilizando **evil-winrm**, una herramienta común para obtener una shell remota en sistemas Windows a través de WinRM.\ Al enumerar los usuarios en el sistema, descubrimos la presencia de **o.armstrong** y **Administrator**, que pueden ser relevantes para próximos movimientos

### Shell o.armstrong Mientras exploramos el sistema, encontramos en el disco C: una carpeta llamada **scripts**, que contiene el archivo **backup.bat**, un script por lotes de Windows.

Aunque no tenemos permisos para modificar directamente **backup.bat**, sí contamos con permisos de escritura sobre la carpeta **scripts**. Esto nos permite eliminar el archivo actual y crear uno nuevo en su lugar.

Transferimos **nc.exe** (Netcat) a la carpeta **C:\Temp**.\ Le damos permisos de ejecución al archivo y eliminamos el **backup.bat** original en la carpeta **scripts**.\ Creamos un nuevo **backup.bat** que ejecuta Netcat para abrir una **reverse shell**, es decir, una conexión que envía una shell del sistema al atacante que escucha en su máquina.

En nuestra máquina atacante, nos ponemos en escucha usando **Netcat** con **rlwrap**, que mejora la experiencia de la terminal.\ Cuando el backup.bat se ejecuta en el sistema víctima, se establece la reverse shell y obtenemos acceso como el usuario **o.armstrong**.

Ya con la shell como o.armstrong, navegamos por el sistema y localizamos la primera **flag.**

### Responder -> Hash NTLM Ahora vamos a usar la herramienta **Responder**, que sirve para realizar ataques de **envenenamiento de red (NBNS/LLMNR)** en entornos Windows.\ Cuando un usuario intenta acceder a un recurso inexistente, Responder intercepta esa petición y responde haciéndose pasar por el servidor solicitado, logrando que la víctima le envíe su hash NTLM.

Para forzar esta interacción, en la shell víctima solicitamos un recurso que no existe, por ejemplo:\ `\\10.21.221.129\test`\ Responder captura la petición y nos devuelve el **hash NTLM** del usuario que la generó.

Con el hash capturado, usamos la herramienta **John the Ripper** con un diccionario para intentar romper el hash.\ Finalmente, logramos obtener la **contraseña en texto plano** del usuario.

Probamos la contraseña descubierta junto al usuario en el servicio **WinRM** usando nxc, y confirmamos que funciona al ver el mensaje **Pwned!**, lo que nos da acceso al sistema.

### BloodHound Usamos las credenciales actuales para recolectar información con **BloodHound**, una herramienta que mapea relaciones y permisos en entornos Active Directory para identificar posibles rutas de escalada de privilegios.\ La recolección se realiza con **NetExec (nxc)** igual que en otras máquinas, y una vez que tenemos los datos, los cargamos en la interfaz de BloodHound. Al analizar los datos en BloodHound, descubrimos que **o.armstrong** pertenece a un grupo con el permiso **GenericWrite** sobre el **Controlador de Dominio (Domain Controller)**.\ Este permiso permite modificar ciertos atributos de un objeto en Active Directory, lo que puede facilitar un ataque conocido como **RBCD (Resource-Based Constrained Delegation)**.

### RBCD -> Shell Administrator BloodHound nos sugiere un camino de ataque: primero creamos un nuevo objeto tipo **computer** en el dominio. Esto lo hacemos **Impacket**, que permiten agregar objetos al dominio si se tiene el permiso necesario.

Con la herramienta **impacket-addcomputer** creamos el nuevo equipo. Luego, usamos **impacket-rbcd** para asignar permisos al nuevo objeto que permitan la **impersonación de usuarios** a través de RBCD. Esto implica modificar el atributo **msDS-AllowedToActOnBehalfOfOtherIdentity**.

Usamos la herramienta **impacket-getST** para generar un ticket TGS en el que nos hacemos pasar por el **usuario Administrator**. El resultado es un archivo **.ccache**, que contiene el ticket Kerberos.

Para usar el ticket Kerberos, exportamos la variable de entorno

Finalmente, ejecutamos **impacket**-**wmiexec** de Impacket, que aprovecha el ticket Kerberos para autenticarse directamente como **Administrator** en el Domain Controller, otorgándonos una shell con privilegios de administrador.

Con acceso como **Administrator**, buscamos y encontramos la **flag final de la máquina**.

*** ## Conclusión La sala **K2** de TryHackMe ofrece una experiencia integral que combina la explotación de entornos **Linux** con técnicas enfocadas en **Active Directory**, simulando un entorno realista de infraestructura empresarial comprometida por múltiples vectores de ataque. Durante el recorrido: * Explotamos vulnerabilidades en aplicaciones web, como **XSS con bypass de WAF** y **inyección SQL**. * Capturamos credenciales tanto en bases de datos como en archivos de logs y bash history. * Abusamos de servicios como **Kerberos** para validar usuarios y realizar ataques de fuerza bruta controlados. * Aprovechamos herramientas como **BloodHound** para mapear el entorno de dominio y trazar rutas de escalada.