En este caso debemos encontrar dos banderas ubicadas en la maquina Athenav1.9.

Donde a
partir del escaneo de puertos de Nmap pude saber que el servicio SMB se está ejecutando en
los puertos 139 y 445. Luego, enumerando los recursos compartidos del servidor Samba, pude
saber que hay un archivo de texto compartido donde encontré la ruta de un endpoint de una
API que ofrece una funcionalidad similar al comando ping. Luego, aprovechando que el
endpoint era vulnerable a Command Injection, logre inyectar un comando que genere un
reverse Shell. Luego, para la escalada privilegio horizontal, logre encontrar un script en Bash
que era ejecutado de manera automatizada y periódica con los privilegios del usuario athena,
logrando modificar su contenido y realizar una reverse Shell. Luego, en la escalada vertical,
aproveche que athena podía cargar un módulo kernel, que viene a ser un LKM rootkit, con los
privilegios del usuario root, logrando analizar su código fuente con Ghidra.
En este caso debemos acceder al sistema destino y obtener las banderas. Para
ello empezaremos utilizando el comando openvpn y el archivo de
configuración OpenVPN con el fin de establecer una conexión VPN y poder
acceder a los laboratorios donde están las máquinas virtuales y vulnerables.

Además, la plataforma de Tryhackme nos muestra la dirección IP de la máquina

Athenav1.9.

FASE ESCANEO Y ENUMERACION

Ahora pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear
los puertos del sistema destino. Además, obtendremos los servicios que se han
levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo
del sistema destino.
Los resultados que obtenemos son:

 Un programa servidor SSH que se ejecuta en el puerto 22.

 Un programa servidor HTTP que se ejecuta en el puerto 80.
 El servicio Samba que se ejecuta en el puerto 445 y 139.
Debido a que el servicio Samba se esta ejecutando en el sistema destino, lo primero
que haremos es enumerar los usuarios locales del sistema destino y los recursos
compartidos a traves del servicio Samba, y a los cuales podemos acceder de manera
anonima, es decir, sin proveer credenciales.
Podemos observar que logramos encontrar algunos usuarios locales, y un recurso
compartido de nombre public y que viene a ser un directorio. Luego, accedimos al
recurso compartido de manera anonima. Donde encontramos un archivo de texto, que
contiene la ruta de un endpoint de una API con cierta funcionalidad similar al comando
ping que conocemos.
Ahora accederemos al endpoint a traves del navegador web.
Podemos observar que la funcionalidad el endpoint de la API consiste en ejecutar el
comando ping con 4 mensajes eco Request ICMP y solo debemos proveerlo la
dirrecion IP de un sistema.
Ahora probaremos diversos payloads para testear si este endpoint es vulnerable a
Command Injection.

 10.8.123.194 ; whoami

 10.8.123.194 && whoami

 10.8.123.194 | whoami

 10.8.123.194 `whoami`
  10.8.123.194 $(whoami)

Podemos observar que se ha implementado un blacklist que nos impide ingresar

ciertos metacaracteres de Shell como ; o & o |. Pero los comandos de sustitucion
como $() o `` si estan permitodos, y los resultados de su ejecucion se estan
considerando como parametro del comando ping realizada por la API. Debido a esto
es que recibimos un mensaje de error que nos indico que fallo la ejecucion del
comando ping pero aun asi se estan ejecutando.Por lo tanto el endpoint si es
vulnerable a Command Injection.
Ahora inyectaremos un comando que nos generara una reverse shel a traves del
comando de sustitucion en formulario HTML del endpoint vulnerable.
De esta manera logramos obtener acceso al sistema destino siendo el usuario www-
data.
Ahora ejecutaremos los siguientes comandos para convertir nuestra reverse Shell más
interactiva y estable.
Ahora buscaremos vectores de escalada de privilegios en el sistema de archivos del
sistema destino.

Podemos verificar que si hay dos usuarios locales en el sistema destino que tienen sus
directorios home, pero no podemos acceder a ellos.
Ahora enumeraremos los archivos y directorios cuyos grupos primario sean el usuario
local athena o ubuntu. Ademas, estos archivos y directorios deben tener el permiso
habilitado de lectura para el usuario www-data.
Podemos observar que logramos encontrar un script en Bash que va crear un
subdirectorio backup en el directorio home del usuario local athena. Luego, va copiar
todo los archivos del subdirectorio notes en el subdirectorio backup. Luego, se
realizara una compresion recursiva de todo los subdirectorios y directorios del
directorio backup en el archivo notes_backup.zip. Luego, se eliminaran todos los
archivos con la extension txt y sh del directorio backup. Luego, se imprime el mensaje
Backup completed. Ademas, tenemos el permiso de modificar el contenido del script.
Ahora enumeraremos todos los procesos que se ejecutan en el sistema destino y en
tiempo real con el fin de saber si este script viene a ser como una tarea cron que se
ejecuta periodicamente con los privilegios de algun usuario local.

Podemos observar que nuestra suposicion estaba en el correcto. Ademas, el script es

ejecutado periodicamente con los privilegios del usuario athena.
Ahora modificaremos el contenido del script para que nos genere una reverse shell
cons los privilegios del usuario local athena.

De esta manera logramos realizar una escalada privilegio horizontal llegando a ser el
usuario athena.
Ahora buscaremos vectores de escalada de privilegio en el sistema de archivos del
usuario athena.
Podemos observar que el usuario athena puede cargar un modulo de kernel llamado
venom.ko mediante el comando insmod y con el privilegio del usuario root mediante el
comando sudo y sin proveer credenciales. Ademas, si enumeramos informacion del
modulo de kernel venom.ko, nos daremos cuenta de que el autor es monad y viene a
ser un LKM rootkit.
Ahora buscaremos informacin sobre el LKM rootkit y su autor, en en el motor de
busqueda de Google.
Podemos observar que logramos enconrar el repositorio Github del usuario monad
donde uno de los repositorio llamado Diamorphine, se trata de un LKM rootkit para
kernel de ciertas versiones en sistemas basados en Linux. Ademas, este LKM rootkit
se compila como un modulo de kernel que va estar invisble, es decir, si intentamos
enumerar todos los modulos cargados en el sistema Linux, no aparecera. Esto lo
podemos comprobar en la siguiente imagen, pero si lo queremos hacer visible,
podemos enviar una señal numero 63 a cualquier pid de cualquier proceso.

Una de las funcionalidades de este LKM rootkit viene a ser una forma de generar
persistencia ya que qnos permite ser el usuario root enviando una señal numero 64 a
cualquier proceso.
Podemos observar que si envamos una seña numero 64 al proceso con PID igual a 0,
se nos cierra automaticamente la sesion de nuestra reverse shell .
Ahora debido a que los modulos de kernel vienen a ser archivos binario compilados,
utilizaremos Ghidra para observar el codigo fuente escrito en lenguaje de
programacion C, y poder observar la modificacion que se ha hecho en la funcionalidad
de ser el usuario root.
Ademas, si observamos el codigo fuente original del script en C que le corresponde a
este rootkit en el respositorio Github, podremos observar que la funcionalidad de ser el
usuario root esta especificada en la funcion give_root.
Podemos observar que si la variable iVar3 es igual a 0x39, que viene a ser 57 en base
decimal, se ejecutara la funcion give_root. Por lo tanto, la señal numero 52 deberiamos
enviar para ser el usuario root.

Podemos observar que nuestro uid es igual a 0 por lo que ya somos el usuario root
mediante el uso de este LKM rootkit que viene a ser una formar interesante de generar
persistencia por el hecho de que el modulo kernel se vuelve invisible cuando se carga
al kernel del sistema operativo.
Ahora buscaremos las dos banderas en el sistema de archivos del usuario root.