En esta entrada voy a documentar cómo resolví la máquina Takeover de TryHackMe. No es un write-up “paso a paso” para seguir ciegamente, sino un repaso de lo que hice, lo que no funcionó, lo que aprendí y por qué tomé ciertas decisiones.
Levantando dnschef
El primer paso fue montar un servidor DNS local con dnschef:
sudo dnschef --fakeip 10.10.202.15 --fakedomains futurevera.thm --nameservers 9.9.9.9
Tengo pendiente profundizar más en dnschef, pero me parece una herramienta muy útil. Básicamente actúa como un proxy DNS: si una consulta coincide con las reglas que defines, devuelve la respuesta que indiques; si no, reenvía la petición a los nameservers que especifiques (por defecto, usa Google, pero aquí prefiero 9.9.9.9).
Necesita permisos de root. Por defecto resuelve también *.futurevera.thm, aunque puedes ponerlo explícitamente, y escucha en 127.0.0.1 salvo que indiques otra interfaz.
Con el servicio en marcha, configuré NetworkManager para que usara 127.0.0.1 como DNS IPv4. Esto me permite resolver todos los wildcard DNS sin tener que añadir entradas una a una en /etc/hosts. Importante: /etc/hosts no soporta comodines, por lo que esta aproximación es mucho más cómoda.
Por qué no usar Gobuster en modo DNS aquí
En esta máquina el modo DNS de Gobuster no funciona como herramienta de filtrado, porque yo mismo he configurado dnschef para que cualquier subdominio resuelva a la IP objetivo. Esto significa que todos los subdominios que pruebes con gobuster dns devolverán “válido” aunque no existan en el servidor web.
He visto este error de concepto en muchos writeups: ejecutan gobuster dns en un escenario así y piensan que la herramienta les está encontrando subdominios reales, cuando en realidad solo está devolviendo positivo por cómo está configurado su DNS local.
Modo DNS vs. modo VHost
- Modo DNS: hace consultas DNS para cada palabra de la lista y comprueba si hay resolución. No toca el servicio web.
- Modo VHost: apunta al servidor web ya resuelto y cambia la cabecera Host: para simular que solicita un vhost diferente. Esto permite detectar qué vhosts están realmente configurados y sirven contenido distinto, aunque el DNS siempre apunte a la misma IP.
En un entorno como este, con DNS local forzado, el modo correcto es VHost, porque es el único que puede discriminar entre nombres configurados en el servidor y falsos positivos.
Enumeración de vhosts
Usé el siguiente comando:
gobuster vhost -u http://futurevera.thm --append-domain -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt
El parámetro –append-domain es fundamental: añade automáticamente .futurevera.thm a cada palabra de la lista, por lo que puedes usar wordlists genéricas (admin, portal, support) (como las seclist) sin necesidad de tener los subdominios completos en el archivo. Esto ahorra tiempo y evita tener que generar listas específicas.
En la práctica, esto significa que si tu wordlist contiene admin, Gobuster, al usar --append-domain, probará la cabecera HTTP como Host: admin.futurevera.thm en cada petición. Lo mismo hará con portal (Host: portal.futurevera.thm), support (Host: support.futurevera.thm) y así con todos los términos de la lista, simulando solicitudes reales a esos virtual hosts sin que tengas que escribirlos completos en el diccionario.
Con esta enumeración encontré, entre otros:
Found: portal.futurevera.thm Status: 200 [Size: 69]
Found: payroll.futurevera.thm Status: 200 [Size: 70]
Al visitar estos vhosts, ambos devolvían el mensaje:
is only availiable via internal VPN
En este punto descarté seguir por aquí, porque implicaría técnicas más avanzadas como spoofing de IP o bypass por cabeceras, y la máquina parecía estar diseñada para una resolución más directa.
Enumeración adicional
Probé a buscar subdominios de segundo nivel, por ejemplo bajo blog.futurevera.thm y support.futurevera.thm, pero solo obtuve listas largas de entradas con Status: 421.
También hice enumeración de directorios y archivos con:
gobuster dir -u http://portal.futurevera.thm -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -t 50 --no-error No enconté ningun directorios o archivos relevante en esta enumeración DIR.
Interactuar con blog y support
Visitar las webs, navegar, echar un vistazo al código fuente, consola, pasar por burpsuite a ver si habia algo destacable…
No encontré nada relevante:
- No CMS.
- Sin formularios para probar inyecciones.
- Nada que llamara la atención.
El certificado TLS…
En este punto estaba atascado. Revisando otros writeups vi que la pista clave estaba en el certificado TLS de https://support.futurevera.thm. Para mí no era algo evidente, pero me ha quedado claro que inspeccionar el certificado TLS debe ser siempre parte del reconocimiento. Este puede incluir en el campo SAN (Subject Alternative Name) subdominios que de otra forma no aparecerían en enumeraciones.
En este caso, el SAN incluía:
DNS Name: secrethelpdesk934752.support.futurevera.thm
Gracias a dnschef, pude resolverlo automáticamente sin modificar /etc/hosts y acceder al recurso:
http://flag{beea0d6edfcee06a59b83fb50ae81b2f}.s3-website-us-west-3.amazonaws.com/
Conclusión
Esta máquina me ha enseñado varias cosas clave:
- En entornos con DNS forzado localmente, el modo dns de Gobuster no discrimina resultados; el correcto es vhost.
--append-domainsimplifica mucho la enumeración con listas genéricas.- dnschef es muy útil para wildcard DNS y evita mantener manualmente /etc/hosts.
- El certificado TLS es una fuente de información que siempre merece la pena revisar, ya que puede filtrar subdominios que no aparecerán en las técnicas de enumeración más habituales.
