HackNet HackTheBox (Intermediate)
Escaneo de puertos
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>nmap -sCV -p<PORTS> <IP>Info:
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-05 05:00 EDT
Nmap scan report for 10.10.11.85
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0)
| ssh-hostkey:
| 256 95:62:ef:97:31:82:ff:a1:c6:08:01:8c:6a:0f:dc:1c (ECDSA)
|_ 256 5f:bd:93:10:20:70:e6:09:f1:ba:6a:43:58:86:42:66 (ED25519)
80/tcp open http nginx 1.22.1
|_http-server-header: nginx/1.22.1
|_http-title: Did not follow redirect to http://hacknet.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.09 secondsVeremos que hay varios puertos interesantes, entre ellos el puerto 80 que vemos que esta redirigiendo a un dominio llamado hacknet.htb, por lo que vamos añadirlo a nuestro archivo hosts.
Lo guardamos y entramos a la pagina:
Dentro veremos unas opciones de crearnos una cuenta o iniciar sesion, como no tenemos cuenta vamos a crearnos una, una vez echo eso nos iremos al login e iniciaremos sesion con las credenciales creadas, entrando dentro veremos lo siguiente:

Veremos un perfil de nuestro usuario nada mas entrar, si nos vamos a Explore veremos una seccion de varios usuarios en los que le podemos dar like o comentarlos, si nosotros abrimos BurpSuite y vamos interceptando las peticiones de todo lo que hacemos veremos que a la hora de dar like es bastante interesante lo que vemos y como responde el servidor.
Estando a la escucha con BurpSuite le daremos like a un comentario y veremos la siguiente peticion:
Vemos que aparece el numero de likes en este caso 10 que se han dado mas el que estoy dando yo, si lo cambio a 20 por ejemplo me responde esto el servidor:
Parece que no ha fallado nada, que se lo ha tragado, pero si volvemos a la pagina veremos que no se ha incrementado como el valor que hemos puesto, pero es interesante saberlo.
Algo importante que tambien vemos es que esta utilizando Django gracias a Wappalizer:

Si probamos este otro endpoint (likes):
No responde el servidor:
Vemos que nos responde con las imagenes de los usuarios que le han dado like a la publicacion (Tiene que ser un numero que exista de likes), tambien vemos que esta mostrando el ID del usuario, la ID de la imagen de perfil y por ultimo en el title muestra el nombre de usuario.
Aqui lo que se nos ocurre es que como esta utilizando Django podremos probar inyeccion de SSTI en el nombre de usuario nuestro, para que cuando enviemos un like se quede registrado y que cuando nosotros desde el parametro likes nos muestre la informacion, muestre tambien el renderizado de la informacion inyectada del nombre de usuario.
Vamos a irnos a nuestro perfil, editarlo y poner algo asi:


Ahora si nos vamos a Explore, le damos like a una publicacion, se incrementara dicho numero, pues con ese numero sabiendo que existe y que esta incrementado, vamos a utilizar el likes de la peticion con BurpSuite para enviarla donde le hemos dado like.
En la respuesta veremos...

Veremos que esta funcionando, esta renderizando el email de un usuario, por lo que la inyeccion esta funcionando, ahora vamos a probar con otra cosa como este payload.
Quedando nuestro nombre de usuario como ese anterior payload, ahora si volvemos a enviar la peticion de likes para que lo renderice, veremos lo siguiente:

Vemos que ha funcionado tambien, por lo que tendremos estas credenciales:
Si las probamos en el login...

Vemos que seremos dicho usuario, pero no habra nada interesante, por lo que vamos a realizar un barrido de IDs para ver que credenciales sacamos gracias a esta vulnerabilidad.
Escalate user mikey
Para no tener que estar dandole like uno por uno y despues enviar la segunda peticion para comprobarlo, vamos a montarnos un script que haga todo esto de forma automatica.
fuzzIDs.py
Vamos a probar primero con el primer payload de nombre de usuario.
payload (username)
Ahora ejecutamos la herramienta asi:
Info:
Veremos varios usuarios que hemos podido filtrar, ahora vamos a probar con este payload y lo volveremos a ejecutar:
payload (email)
Info:
Vemos varios correos filtrados, ahora por ultimo vamos a intentar filtrar las contraseñas con este ultimo payload.
payload (password)
Info:
Ya con toda esta informacion vamos a crear un diccionario de usuarios y contraseñas para intentar tirar fuerza bruta por SSH con hydra a ver si hay suerte.
Hydra
users.txt
En el listado de usuarios añadi mikey ya que es el unico correo que es diferente al del usuario propio.
pass.txt
Teniendo los listados vamos a utilizarlos de esta forma:
Info:
Veremos que ha funcionado, por lo que vamos a entrar por SSH.
SSH
Metemos como contraseña mYd4rks1dEisH3re...
Vemos que ha funcionado, por lo que leeremos la flag del usuario.
user.txt
Escalate user sandy
Vamos a realizar un find para ver archivos y directorios del usuario sandy que sabemos que existe en el sistema a ver que vemos:
Info:
Veremos muchisima informacion, pero todo sera de /var/www/ cosa que no nos interesa, pero es curiosa la siguiente ruta encontrada que es /var/tmp, si nos vamos ahi veremos lo siguiente:
Vemos un directorio llamado django_cache que pertenece a sandy pero que es del grupo www-data, si entramos dentro del mismo no veremos ningun archivo ni nada, es muy interesante esto.
Sabiendo el nombre de este archivo y tambien sabiendo que hay un Django podemos deducir que puede tener una vulnerabilidad llamada Django FileBasedCache Poisoning vamos a utilizar un Pickle Inseguro (Cuando Django lee el caché, automáticamente reconstruye los objetos usando pickle.loads()), vamos a explotarla de esta forma:
Vamos a montarnos un script que genere este archivo malicioso que vamos a utilizar y que lo sobreescriba a la vez con los permisos necesarios.
Info:
createPickle.py
Establecemos los permisos de ejecuccion:
Ahora tendremos que realizar una peticion para que se caché de esta forma:
Echo esto se deberia de guardar los archivos djcache en dicha carpeta:
Info:
Ahora si tendremos que ejecutar el script, pero antes nos pondremos a la escucha:
Si ejecutamos el script veremos lo siguiente:
Info:
Ahora seguidamente en otra terminal ejecutaremos lo siguiente de nuevo para que cargue el cache sobreescrito:
Nos mostrar la pagina en codigo HTML, pero si vamos a donde tenemos la escucha, veremos lo siguiente:
Veremos que ha funcionado, por lo que tendremos que sanitizar la shell.
Sanitización de shell (TTY)
Escalate Privileges
Si nos vamos a la siguiente carpeta:
Info:
Veremos estos archivos bastante interesantes, nos vamos a pasar el archivo armored_key.asca nuestra maquina atacante para crackearlo de esta forma:
En la maquina atacante:
Una vez que nos lo descarguemos vamos a obtener el hash de la contraseña y crackearlo de esta forma:
Info:
Veremos que ha funcionado, por lo que ahora teniendo esta clave podemos decodificar cualquier archivo que este cifrado con esta clave.
Si nos vamos a la siguiente ruta veremos estos archivos:
Info:
Vemos que algunos estan cifrados con dicha clave, por lo que vamos a probar a decodificarlos de esta forma:
Antes tendremos que importarnos la clave:
Info:
Ahora teniendola importada en esta sesion, podremos hacer esto:
Metemos como contraseña sweetheart y veremos que funciona, vamos a comprobar el /tmp para ver que se decodifico bien:
Veremos que si, ahora si los leemos veremos lo siguiente:
Si vemos esas lineas en concreto nos pone lo que parece la password del usuario root, por lo que vamos a probar a utilizarla:
Metemos como contraseña h4ck3rs4re3veRywh3re99...
Veremos que ha funcionado, por lo que leeremos la flag de root.
root.txt
Last updated