Máquina creada por: Oscar
Plataforma: The Hackers Labs
Sistema operativo: Linux
Dificultad: principiante

Sobre este CTF

Esta máquina la diseñé para trabajar una cadena de compromiso muy concreta: una intrusión inicial sobre un servicio web expuesto, la descarga de un stager, el establecimiento de un canal de mando y control mediante DNS y, a partir de ahí, movimiento lateral hacia un sistema interno con exfiltración de información.

El objetivo no era construir una colección de trucos aislados, sino una secuencia coherente de fallos y decisiones operativas que obligara a leer el incidente como lo haría un analista DFIR. La dificultad real del laboratorio no está en ejecutar una explotación especialmente compleja, sino en separar la señal del ruido y reconstruir la kill chain completa a partir de artefactos parciales.

La idea de fondo es sencilla: muchas intrusiones reales no destacan por su espectacularidad, sino por su normalidad aparente. Un único POST entre miles de peticiones legítimas, unas consultas DNS que pueden parecer anodinas y un acceso interno apoyado en credenciales reutilizadas bastan para comprometer más de un activo si nadie conecta los indicios.

Información técnica

Descubrimiento de la intrusión inicial

El primer punto importante del laboratorio está en el servidor web. Quise que la entrada inicial no dependiera de una firma evidente ni de una secuencia ruidosa, sino de una anomalía mínima dentro de un log con miles de eventos.

El artefacto access.log deja ver que casi toda la actividad corresponde a peticiones GET, mientras que solo aparece una petición POST. Ese desequilibrio no demuestra por sí solo una explotación, pero sí marca un punto de observación muy razonable para arrancar el análisis.

cat access.log | grep "GET " | wc -l && cat access.log | grep "POST " | wc -l
5001
1

A partir de ahí, la petición relevante aparece de forma nítida:

grep "POST" access.log
1.2.3.4 - - [10/nov/2025:09:10:13 +0100] "POST /upload.php HTTP/1.1" 200 150

El fichero PHP que actúa como punto de entrada más probable es upload.php.

Esta fase existe en el diseño para enseñar una idea muy repetida fuera del CTF: el valor analítico de una rareza estadística. No hacía falta un rastro de explotación exuberante. Bastaba con que el lector detectara qué evento rompe el patrón habitual del servicio. En un entorno real, muchos incidentes empiezan precisamente así: una funcionalidad de subida o procesado de contenido expuesta sin controles suficientes termina siendo el mejor punto de apoyo para la intrusión.

Descarga del stager y consolidación del acceso

Una vez localizada la entrada probable, la siguiente evidencia importante es la descarga del stager p.sh. Aquí quise enlazar la explotación con una acción de post-compromiso muy común: traer un script externo para preparar el siguiente paso del ataque.

La evidencia aparece directamente en el log de acceso:

cat access.log | grep p.sh
192.168.1.10 - - [10/nov/2025:09:10:13 +0100] "GET http://162.248.1.100/p.sh HTTP/1.1" 200 1024

La dirección IP externa que sirvió el stager fue 162.248.1.100.

Desde el punto de vista de diseño, esta fase representa dos aprendizajes. El primero es que no siempre hace falta un payload sofisticado para avanzar: un script descargado desde infraestructura externa puede ser suficiente para activar el resto de la cadena. El segundo es que el servidor comprometido empieza a comportarse como cliente de un recurso remoto, y esa inversión de rol suele ser una pista muy útil cuando se analizan logs de acceso web con mentalidad defensiva.

Beaconing DNS y establecimiento del canal C2

El corazón del laboratorio está en dns.log. La hipótesis del escenario ya anticipa uso de túneles DNS para C2 y exfiltración, así que la lectura de este artefacto debía confirmar dos cosas: primero, la existencia de un patrón de beaconing; después, el uso del mismo canal para transportar datos.

Las primeras consultas de C2 aparecen así:

cat dns.log | grep eltopo
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 1.beacon.c2.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 2.beacon.c2.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? 3.beacon.c2.eltopo.thl

La primera consulta de beaconing observada es 1.beacon.c2.eltopo.thl.

Aquí quería enseñar una lectura muy concreta: el DNS deja de ser solo un servicio de resolución y pasa a funcionar como transporte encubierto. El patrón numerado en los subdominios no pretende ser especialmente realista desde el punto de vista de evasión avanzada; pretende ser legible para que el participante entienda la transición entre compromiso inicial y control remoto. El foco está en reconocer el cambio de función del protocolo.

En operaciones reales, el DNS suele conservar una falsa pátina de normalidad porque casi todo sistema lo utiliza constantemente. Esa es precisamente la razón de incluir ruido en el artefacto: el reto no consistía en saber que “DNS puede usarse como C2”, sino en identificar cuándo deja de parecer resolución legítima y empieza a encajar con telemetría de control.

Exfiltración del fichero shadow por DNS

Una vez establecido el C2, el siguiente paso es la exfiltración. En el laboratorio la información robada procede de un artefacto del tipo shadow, y se fragmenta dentro de subdominios. No quería que esta fase dependiera de herramientas concretas, sino de leer el patrón: datos codificados en la etiqueta izquierda y dominio de control en la parte fija.

Las consultas relevantes son estas:

cat dns.log | grep eltopo
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? Oio6MTgwMDA6MDo5OTk5OTo3Ojo6CmRhZW1vbjoqOjE4MDAwOjA6OTk5OTk6.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? Nzo6OgpkZXZ1c2VyOiQ2JHJvdW5kcz02NTYwMDAkYWJjZGVmZyRoaWprbG1u.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? cm9vdDokNiRzYWx0eSRULlVWcy4uLjoxODAwMDowOjk5OTk5Ojc6OjoKYmlu.data.eltopo.thl
[2025-11-10T09:10:13] 192.168.1.10 -> DNS_SERVER Query: A? b3AuLi46MTgwMDE6MDo5OTk5OTo3Ojo6CmZ0cHVzZXI6KjoxODAwMTowOjk5.data.eltopo.thl

El dominio utilizado para la exfiltración, sin contar los subdominios con datos, es data.eltopo.thl.

Esta parte del diseño refleja un problema defensivo muy habitual: cuando un sistema ya ha sido comprometido, la exfiltración no necesita abrir necesariamente un canal nuevo y evidente. Puede reciclar un protocolo imprescindible para la operación normal. El aprendizaje que me interesaba forzar aquí era que el analista no se quedara en el IOC superficial, sino que entendiera la lógica del canal: fragmentación, encapsulado en consultas y reutilización de infraestructura aparentemente inocua.

Movimiento lateral hacia el servidor interno

El siguiente salto en la cadena es deliberadamente poco glamuroso: una vez comprometido el frontal web, el atacante aprovecha conectividad interna para alcanzar 10.0.0.50. Elegí FTP porque es un protocolo fácil de leer en bruto y porque representa bien un problema muy real: servicios internos heredados o mal gobernados que siguen siendo utilizables por un atacante una vez pisa el perímetro.

El ftp.log muestra la secuencia completa:

cat ftp.log
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP 220 (vsFTPd 3.0.3)
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP USER devuser
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 331 Please specify the password.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP PASS developer123
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 230 Login successful.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP LIST
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 226 Directory send OK.
[09:10:13] 192.168.1.10 -> 10.0.0.50 FTP GET client_database_backup.zip
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 150 Opening BINARY mode data connection.
[09:10:13] 10.0.0.50 -> 192.168.1.10 FTP 226 Transfer complete.

De aquí se obtienen cuatro piezas clave de la investigación:

• El protocolo usado para pivotar al servidor interno fue FTP.
• El nombre de usuario utilizado fue devuser.
• La contraseña empleada para el movimiento lateral exitoso fue developer123.
• El fichero robado del servidor interno fue client_database_backup.zip.

En términos de diseño, esta fase buscaba que la intrusión no terminara en la propia máquina comprometida. El servidor web actúa aquí como cabeza de puente hacia la red interna. Eso refleja una situación muy común en entornos reales: el activo expuesto a Internet rara vez es el objetivo final; muchas veces solo es el primer sistema que ofrece al atacante una posición de ventaja.

Además, el uso de credenciales claras y un servicio interno accesible pretende subrayar algo muy concreto: la seguridad del perímetro importa menos en cuanto una máquina expuesta cae y puede “ver” recursos internos con controles débiles. El fallo ya no es solo la explotación inicial. La cadena funciona porque el entorno permite que ese compromiso se propague.

Lectura de la cadena completa

Una vez unidos los artefactos, la secuencia del incidente queda razonablemente cerrada:

1. Un actor externo realiza una petición POST a upload.php, que destaca como punto de entrada más probable.
2. Tras la intrusión, el servidor descarga el stager p.sh desde 162.248.1.100.
3. A continuación, la máquina comprometida comienza a emitir consultas de beaconing como 1.beacon.c2.eltopo.thl, estableciendo un canal de C2 sobre DNS.
4. Ese mismo mecanismo se reutiliza para exfiltrar contenido relacionado con shadow hacia data.eltopo.thl.
5. Con control operativo sobre el servidor expuesto, el atacante pivota internamente a 10.0.0.50 usando FTP.
6. La autenticación se realiza con devuser:developer123.
7. El impacto final es el robo de client_database_backup.zip.

Lo que me interesaba enseñar con esta máquina no era una explotación concreta, sino el valor de reconstruir contexto. Cada artefacto, aislado, dice poco. Juntos describen una intrusión completa con persistencia operativa, canal encubierto, movimiento lateral y robo de información.

Qué quería enseñar al diseñar El Topo DNS

El laboratorio está construido para que la resolución obligue a pensar en encadenamiento de fallos. No basta con detectar el vector inicial ni con reconocer un túnel DNS. La máquina solo tiene sentido cuando se entiende cómo una anomalía web mínima deriva en control remoto, cómo ese control se usa para exfiltrar datos y cómo el acceso a un servidor expuesto se convierte después en acceso a un activo interno.

La lección reutilizable es clara: una intrusión silenciosa no necesita técnicas especialmente sofisticadas si encuentra una cadena razonable de decisiones débiles. El atacante solo tiene que enlazarlas.

Recursos y referencias

• Registros de acceso web para detección de anomalías en métodos HTTP y recursos solicitados.
• Telemetría DNS para identificación de beaconing y exfiltración encubierta.
• Logs de protocolos internos como FTP para reconstrucción de movimiento lateral.
• Artefactos de sistema tipo shadow como indicador de acceso privilegiado y robo de credenciales o hashes.