> 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/internal.md). # Internal ## Información de la máquina

**Internal** es una máquina Linux de nivel *Hard* en TryHackMe que simula una infraestructura interna expuesta parcialmente a internet, con varios vectores de ataque encadenados. Desde un servicio web aparentemente básico, el atacante deberá profundizar en la enumeración hasta comprometer un sitio WordPress, obtener acceso como usuarios del sistema, pivotar a servicios internos como Jenkins mediante port forwarding, y finalmente escalar privilegios hasta obtener acceso como **root**. A lo largo del proceso, se emplean técnicas como fuerza bruta de credenciales, explotación de ejecución remota de comandos (RCE), análisis de configuraciones mal gestionadas y abuso de consolas administrativas. Esta máquina exige una comprensión sólida del movimiento lateral en sistemas Linux, así como la capacidad de detectar y aprovechar múltiples debilidades dentro de un entorno mal asegurado. *** ## Reconocimiento 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 65535 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 **`puertos` .** El escaneo revela 2 puertos abiertos, puerto 22(SSH) y puerto 80(HTTP). Ahora realizamos un escaneo más avanzado sobre estos 2 puertos

**1. `-p22,80` → Escaneo de puertos específicos** Con `-p22,80`, le indicamos que **solo** escanee los puertos **22 (SSH)** y **80 (HTTP)** **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**. Esta es la página web que se presenta inicialmente.

Utilizamos **Gobuster** para enumerar directorios accesibles en la web. Descubrimos uno llamado **/blog**.

Al acceder a **/blog**, notamos que algunos recursos no se cargan correctamente, lo que sugiere que el sitio podría estar utilizando **virtual hosting** y dependiendo de un **subdominio**.

Al inspeccionar el código fuente de la página, identificamos el **subdominio** correspondiente. Además, observamos rutas típicas de un **WordPress**, como **/wp-content/**.

Agregamos el dominio **internal.thm** al archivo **/etc/hosts** para poder acceder correctamente al subdominio.

## Enumerate Wordpress Procedemos a enumerar el sitio **WordPress** utilizando **wpscan**, enfocándonos en detectar tanto usuarios como plugins instalados.

Descubrimos un usuario existente con el nombre de **admin**.

Como no se encontraron plugins vulnerables ni configuraciones relevantes, realizamos un ataque de **fuerza bruta** sobre el usuario **admin** para intentar descubrir su contraseña.

Logramos identificar la contraseña **my2boys** para el usuario **admin**.

Iniciamos sesión en el panel de administración utilizando las credenciales obtenidas.

Accedemos satisfactoriamente al **panel de administración** de WordPress.

## Shell www-data Explorando el panel de administración, encontramos en la sección **Apparience** una subsección llamada **Editor de temas (Theme Editor)**. Desde allí es posible modificar los archivos PHP del tema activo. Identificamos la plantilla **404.php**, y al editarla con un payload de **ejecución remota de comandos (RCE)**, la actualización se aplica sin restricciones.

Basta con acceder a la ruta de la plantilla modificada e incluir el parámetro **cmd** con el comando deseado. Al ejecutar `whoami`, confirmamos que la RCE funciona correctamente.

Ahora establecemos una **reverse shell** utilizando un oneliner clásico.

Ponemos **netcat** en escucha y obtenemos acceso inicial a la máquina como el usuario **www-data**.

## Auth aubreanna Enumerando el sistema, encontramos el archivo de configuración típico de wordpress, wp-config.php. Este archivo contiene credenciales para la base de datos. Después de encontrar esto, enumeré los directorios nuevamente, encontrando un phpmyadmin.

Inicio sesion en phpmyadmin y tenemos una base de datos llamada wordpress

Encontramos una tabla llamada wp-users, pero solo contiene el usuario admin.

Enumerando de nuevo el sistema, encontré en /opt un archivo llamado wp-save.txt con credenciales para el usuario aubrenna.

Con ssh utilizaremos las credenciales obtenidas y obtenemos acceso como este usuario.

Con ello podemos visualizar la primera flag.

Tambien encontramos otro archivo llamado jenkins.txt que nos dice que está corriendo internamente por el puerto 8080.

## PortForwarding El **Port Forwarding** (reenvío de puertos) consiste en redirigir el tráfico de red desde un puerto local a un puerto de una máquina remota a través de un túnel, generalmente SSH.\ Usamos SSH para establecer el túnel y acceder a un servicio que solo era accesible internamente en la red del objetivo.

Gracias al túnel SSH, ahora podemos visualizar en nuestra máquina Kali una página web que originalmente solo era accesible desde el propio servidor.

Utilizamos la herramienta **WhatWeb** para identificar la versión exacta de **Jenkins**, lo que será útil para planear una posible explotación.

## Jenkins Brute Force login Intentamos evitar el login de Jenkins buscando métodos de bypass o formas de registrarse. Probamos credenciales por defecto como **admin:password**, pero no fueron válidas.

Decidimos lanzar un ataque de **fuerza bruta** contra el usuario **admin**, y conseguimos descubrir una contraseña válida.

Ingresamos las credenciales encontradas y accedemos exitosamente al panel de **Jenkins**.

## Shell user jenkins Dentro del panel de administración, encontramos en **Manage Jenkins** una sección llamada **Script Console**, que permite ejecutar código en **Java**. Buscamos un payload de reverse shell en Java, lo ejecutamos desde allí y conseguimos una conexión.

Colocamos **netcat** en escucha y obtenemos acceso al sistema como el usuario **jenkins**.

## Root access Durante la enumeración del sistema, encontramos un archivo llamado **note.txt** en el directorio **/opt**, el cual contiene las credenciales del usuario **root**.

Usamos **SSH** junto con las credenciales obtenidas y conseguimos acceso como el usuario **root**.

Finalmente, accedemos a la **flag final**.

*** ## Conclusión La resolución de **Internal** nos muestra la importancia de una correcta configuración de servicios accesibles públicamente, el peligro de credenciales débiles y la exposición innecesaria de interfaces administrativas. Desde un WordPress vulnerable a malas prácticas en Jenkins y almacenamiento inseguro de credenciales, el atacante logra moverse lateralmente por el sistema hasta alcanzar privilegios de root. Esta máquina no solo nos enseña técnicas ofensivas como RCE a través de la edición de plantillas en WordPress o ejecución remota en Jenkins, sino también buenas prácticas que deberían evitarse en entornos reales. Un reto exigente pero sumamente enriquecedor para cualquier profesional de la ciberseguridad.