! xhetic .. /

TakeOver - TryHackMe

xhetic

xhetic

@xhetic

TryHackMeLinuxEasy
TakeOver - TryHackMe

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

🚀TryHackMe Labs

TakeOver - TryHackMe Walkthrough

Bienvenido a mi writeup de TakeOver de TryHackMe.

Es una room bastante corta en la que el foco principal está en la enumeración de subdominios y en revisar los detalles de configuración TLS. La parte interesante no es una explotación compleja, sino encontrar el host correcto y observar su comportamiento en HTTP.

Room: TakeOver
Dificultad: Easy
OS: Linux
Objetivo: Obtener la flag

🎯 Información del Objetivo

IP Target: 10.113.155.166

🔍 Fase 1: Reconocimiento (RECON)

Comprobación de Conectividad

Primero verifico conectividad con la máquina:

ping -c1 10.113.155.166
  • -c1 → Envía un solo paquete ICMP para comprobar conectividad

La respuesta indica TTL cercano a 64, por lo que posiblemente estoy ante Linux.

💡 Referencia rápida de TTL:

  • TTL ≈ 64 → Linux/Unix
  • TTL ≈ 128 → Windows

Descubrimiento de Puertos

Hago un escaneo completo de puertos para localizar superficie de ataque:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.113.155.166
  • -p- → Escaneo de los 65535 puertos
  • --open → Muestra solo puertos abiertos
  • -sS → SYN scan (stealth)
  • --min-rate 5000 → Acelera el escaneo
  • -n → Sin resolución DNS
  • -Pn → Sin ping previo
▶ output
PORT    STATE SERVICE REASON
22/tcp  open  ssh     syn-ack ttl 62
80/tcp  open  http    syn-ack ttl 62
443/tcp open  https   syn-ack ttl 62

Amplío con detección de versiones:

nmap -p22,80,443 -sSV 10.113.155.166
  • -p22,80,443 → Escanea solo los puertos detectados como abiertos
  • -sS → SYN scan
  • -sV → Detección de versiones de servicios
▶ output
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     Apache httpd 2.4.41 ((Ubuntu))
443/tcp open  ssl/http Apache httpd 2.4.41 ((Ubuntu))

Consultando con searchsploit no encuentro nada especialmente explotable de forma directa en esas versiones.

📁 Fase 2: Enumeración

Enumeración Web Inicial

Antes de navegar, añado el dominio indicado por la room a /etc/hosts:

echo '10.113.155.166 futurevera.thm' | sudo tee -a /etc/hosts
  • echo 'IP dominio' → Genera la entrada de resolución local
  • | sudo tee -a /etc/hosts → Añade la línea al archivo hosts con privilegios

Al abrir https://futurevera.thm veo una web tipo blog.

Esta es la vista principal del dominio base:

Sitio principal futurevera.thm

Intento enumerar rutas con dirb:

dirb https://futurevera.thm/ /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
  • Primer argumento → URL objetivo
  • Segundo argumento → Wordlist para enumerar rutas y directorios

Solo aparecen rutas comunes (/assets, /css, /js) sin valor para avanzar.

Fuzzing de Subdominios

Paso a enumerar virtual hosts/subdominios con ffuf:

ffuf -u https://10.113.155.166 -H "Host: FUZZ.futurevera.thm" -w /usr/share/seclists/Discovery/Web-Content/common.txt -fs 4605
  • -u → URL objetivo
  • -H "Host: FUZZ.futurevera.thm" → Fuzzing de virtual hosts sustituyendo FUZZ
  • -w → Wordlist de candidatos para subdominios
  • -fs 4605 → Filtra respuestas por tamaño para eliminar falsos positivos
▶ output
Blog                    [Status: 200, Size: 3838, Words: 1326, Lines: 81]
Support                 [Status: 200, Size: 1522, Words: 367, Lines: 34]

Obtengo dos subdominios válidos: blog.futurevera.thm y support.futurevera.thm.

Añado ambos a /etc/hosts y reviso su contenido.

La siguiente captura corresponde al subdominio blog:

Subdominio blog.futurevera.thm

En support.futurevera.thm solo veo un mensaje de mantenimiento, sin funcionalidad adicional:

Subdominio support.futurevera.thm

Repito fuzzing de directorios en ambos y vuelvo a obtener únicamente rutas estáticas. También pruebo una wordlist mayor para subdominios, pero no encuentro nada nuevo.

Análisis del Certificado SSL

Como no consigo avanzar con rutas ni con subdominios comunes, reviso el certificado TLS para enumerar información.

En los Subject Alternative Names encuentro un host adicional:

secrethelpdesk934752.support.futurevera.thm

En esta captura se aprecia ese nombre dentro del certificado:

Subject Alternative Name en certificado SSL

Añado ese host a /etc/hosts y lo pruebo por HTTPS. La web parece la misma que el blog normal, así que por HTTPS no revela nada diferencial.

🚀 Fase 3: Explotación

Validación por HTTP y Hallazgo de la Flag

Recuerdo que el puerto 80 también está abierto. Pruebo todos los hosts descubiertos por HTTP en lugar de HTTPS.

En el host secrethelpdesk934752.support.futurevera.thm, el error de conexión muestra el nombre del backend y ahí aparece la flag en el hostname de un bucket S3.

La siguiente imagen muestra el hallazgo final:

Flag visible en error HTTP
Click para ver imagen

🚩 Flag capturada.

📊 Resumen

Cadena de Ataque

nmap → dominio base en /etc/hosts → ffuf subdominios (blog/support) → análisis certificado SSL → host oculto secrethelpdesk... → prueba por HTTP → flag en error de conexión

Herramientas Utilizadas

  • nmap — Reconocimiento de puertos y servicios
  • dirb — Enumeración de rutas web
  • ffuf — Fuzzing de subdominios mediante Host header
  • Navegador — Revisión de certificados SSL y respuestas HTTP

🛡️ Vulnerabilidades y Mitigaciones

VulnerabilidadSeveridadMitigación
Exposición de subdominios internos en certificados TLSMEDIAMinimizar SAN innecesarios y segmentar entornos internos/externos
Divulgación de información sensible en mensajes de error HTTPALTAConfigurar errores genéricos sin filtrar detalles de infraestructura
Superficie web ampliada por virtual hosts no gestionadosMEDIAInventario continuo de dominios/subdominios y hardening de cabeceras virtuales

📚 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