# HexThink Silent Shadow: lo que aprendí diseñando una cadena de compromiso entre base de datos, secretos ocultos y privilegios mal delegados
Table of Contents
Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: avanzada
Sobre este CTF
HexThink Silent Shadow es una máquina que diseñé para The Hackers Labs con una idea muy concreta: enseñar cómo varios fallos que, por separado, podrían parecer asumibles, terminan abriendo el sistema por completo cuando se conectan entre sí.
No planteé este laboratorio como una colección de trucos ni como una máquina pensada para impresionar por complejidad artificial. La construí para que cada fase tuviera una lógica clara y una lección detrás: una base de datos expuesta, una autenticación débil, información útil escondida donde no debería estar y privilegios delegados de forma peligrosa.
Más que un writeup de explotación, esta entrada quiere dejar claro qué quise enseñar al diseñar la máquina y por qué esa cadena tiene sentido fuera del laboratorio.
Información técnica
| Campo | Valor |
|---|---|
| Nombre | HexThink Silent Shadow |
| IP objetivo | 10.0.2.16 |
| Servicios | SSH (22), HTTP (80), MySQL (3306), servicio custom (9090) |
| Cadena principal | acceso inseguro a MySQL → extracción de datos → esteganografía → autenticación en servicio 9090 → acceso SSH → abuso de sudo python3 |
| Dificultad | avanzada |
Punto de partida: una superficie expuesta con varias puertas posibles
La máquina arranca mostrando varios servicios interesantes desde el primer escaneo:
sudo nmap -p- --open -sCV -Pn --min-rate 5000 10.0.2.16Resultado relevante:
PORT STATE SERVICE VERSION22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.1180/tcp open http Apache httpd 2.4.58 (Ubuntu)3306/tcp open mysql MariaDB 5.5.5-10.11.119090/tcp open zeus-admin? (Protocolo no HTTP identificado)Cuando diseñé este arranque, no quería que la máquina empujara a un único camino obvio. Quería que el atacante viera varias piezas expuestas y tuviera que decidir cuál merecía más atención.
La más importante no era el puerto raro. Era MySQL en red.
Lo primero que quería enseñar: una base de datos expuesta ya es un problema serio
En la parte web aparece un posible usuario:
ctf_userEsa pista sirve para probar acceso a MySQL:
mysql -h 10.0.2.16 -u ctf_user --skip-sslLa conexión se acepta sin contraseña.
Qué quería enseñar aquí
La primera lección de esta máquina es simple: una base de datos accesible desde red con autenticación débil o inexistente ya es una brecha de seguridad, aunque todavía no haya shell, RCE o privilegios elevados.
En muchos entornos se minusvalora este tipo de exposición porque “solo es la base de datos”. Precisamente por eso quise usarla como punto de entrada. Desde ahí ya puedes:
- enumerar estructura interna
- recuperar usuarios y hashes
- leer contenido que no debía ser accesible
- encontrar pistas operativas que acaban conectando con otros servicios
No hace falta explotar el motor si la propia configuración ya te deja entrar.
Lo segundo: no toda la información valiosa está en la tabla que parece más obvia
Una vez dentro, se enumeran bases de datos y tablas:
SHOW DATABASES;USE ctf_db;SHOW TABLES;SELECT * FROM usuarios;En usuarios aparecen hashes MD5. Se pueden crackear, pero en esta máquina no eran la clave real del compromiso.
La pieza importante estaba en otro sitio: la tabla noticias, donde había un mensaje y una imagen que invitaban a mirar “un poco más allá”.
Qué quería enseñar aquí
Quise romper una expectativa muy común: entrar en una base de datos, ver hashes y asumir que el camino bueno pasa por crackearlos y reutilizarlos.
A veces sí. Aquí no.
Aquí quería enseñar que la información verdaderamente útil no siempre está en la tabla de usuarios, sino en contenido auxiliar, comentarios, ficheros embebidos o piezas que el equipo considera “inofensivas”.
En la práctica real, eso pasa mucho. Los secretos no siempre viven donde deberían. A veces están en una nota, una imagen, un adjunto, una tabla de noticias o una ruta aparentemente secundaria.
Lo tercero: ocultar secretos no es protegerlos
Para inspeccionar la imagen a fondo, se descargó y se analizó con esteganografía:
stegseek imagen.jpgResultado:
- passphrase:
hello - archivo revelado:
instrucciones.txt
Qué quería enseñar aquí
La idea aquí no era hacer un “reto de estego” por meter variedad. La intención era otra: mostrar que esconder información sensible no equivale a protegerla.
Muchas veces los equipos hacen esto con otro formato:
- credenciales en imágenes de documentación
- secretos en adjuntos internos
- instrucciones operativas embebidas en recursos estáticos
- datos “disimulados” pero no realmente protegidos
En esta máquina, la imagen sirve para enseñar justo eso: cuando alguien ya ha comprometido una capa, todo lo que parecía “oculto” deja de estarlo.
Lo cuarto: un servicio no estándar no deja de ser una superficie crítica
Con la información recuperada desde la imagen, se interactúa con el servicio del puerto 9090:
echo -e "LOGIN whisper\nKEY whisper9090" | nc 10.0.2.16 9090Esa autenticación permite avanzar y obtener acceso útil para continuar la cadena.
Qué quería enseñar aquí
Aquí la lección es muy importante: los servicios custom o no estándar suelen recibir menos revisión que SSH, Apache o MySQL, y precisamente por eso son peligrosos.
No quería que el puerto 9090 fuera un simple adorno raro. Quería que representara un patrón real:
- servicio interno con lógica propia
- autenticación apoyada en secretos débiles
- confianza excesiva en que “nadie sabrá cómo hablarle”
Ese tipo de backend auxiliar, protocolo casero o servicio administrativo aparece mucho más de lo que parece. Y cuando se conecta con otros sistemas, el riesgo escala muy rápido.
Lo quinto: cuando conectas piezas débiles, ya no necesitas una gran vulnerabilidad
Con las credenciales obtenidas, se accede por SSH como whisper:
ssh whisper@10.0.2.16A partir de ahí, el sistema ya está comprometido a nivel de usuario.
Qué quería enseñar aquí
Hasta este punto de la máquina no hay una CVE espectacular, ni un exploit llamativo, ni una escalada rara. Y, sin embargo, el atacante ya está dentro.
Eso es deliberado.
La enseñanza aquí es que muchos compromisos reales no nacen de un gran fallo aislado, sino de varias debilidades medianas bien conectadas:
- un dato útil expuesto en web
- una base de datos accesible sin control suficiente
- una imagen con información sensible
- un servicio custom que acepta secretos débiles
- una reutilización operativa que termina en acceso SSH
Eso es mucho más representativo de la realidad que una máquina basada solo en un exploit famoso.
La fase final: privilegios mal delegados siguen rompiendo sistemas
Una vez dentro como whisper, se revisan permisos sudo:
sudo -lLa vía de escalada permitía abusar de python3 con privilegios elevados:
sudo python3 -c 'import pty, os; os.execv("/bin/bash", ["bash"])'Con eso se obtiene shell como root.
Qué quería enseñar aquí
La última lección de la máquina es una de las más importantes para entornos reales: no hace falta que un binario sea “peligroso” por sí mismo para convertirse en una vía de root. Basta con ejecutarlo con más privilegios de los que debería tener.
Aquí usé python3 precisamente porque es una herramienta común, legítima y presente en muchos sistemas. Eso refuerza el aprendizaje:
- delegar
sudosobre herramientas interpretadas o muy versátiles es peligroso - conceder privilegios “por comodidad” suele abrir más de lo que se pretendía
- la confianza excesiva en binarios comunes es un error recurrente
No quería una escalada exótica. Quería una escalada creíble.
Qué quería enseñar al diseñar HexThink Silent Shadow
Si tuviera que resumir el aprendizaje central de esta máquina, sería este:
el sistema no cae por un único fallo crítico, sino por la suma de varias decisiones malas que se refuerzan entre sí.
Ese era el objetivo del diseño.
Resumen de la cadena
| Fase | Qué enseña | Error representado |
|---|---|---|
| Web inicial | filtrar contexto útil | exposición innecesaria de información operativa |
| MySQL sin contraseña | acceso indebido a datos internos | base de datos expuesta y mal protegida |
Tabla noticias | valor de contenido auxiliar | secretos o pistas fuera de los lugares obvios |
| Esteganografía | falsa sensación de protección | ocultación sin seguridad real |
| Servicio 9090 | riesgo en servicios custom | protocolos internos con autenticación débil |
SSH como whisper | impacto de encadenar piezas | compromiso por correlación de fallos |
sudo python3 | abuso de privilegios legítimos | delegación peligrosa de permisos |
Lo que me interesa al crear estos CTF
Al diseñar máquinas como HexThink Silent Shadow, no busco que el reto sea solo “llegar a root”. Busco que quien lo resuelva entienda por qué ha llegado ahí.
Me interesa construir laboratorios donde la cadena tenga lógica, donde cada paso responda a una mala decisión concreta y donde el aprendizaje sea reutilizable fuera del CTF.
Porque al final, ese es el valor real de crear estos escenarios: no demostrar que algo puede romperse, sino mostrar cómo se rompe cuando se normalizan prácticas inseguras.
