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

Sobre este CTF

Esta máquina la diseñé como un laboratorio de análisis de infección con una idea muy concreta: mostrar cómo una intrusión relativamente simple puede degradar un sistema sin necesidad de desplegar una cadena especialmente sofisticada.

El objetivo no era construir una colección de trucos aislados, sino una secuencia coherente de acciones que obligara a leer el sistema como lo haría alguien en una tarea de respuesta ante incidentes. Por eso el foco no está en “llegar a una flag”, sino en reconstruir qué ha hecho el atacante, cómo ha mantenido presencia en la máquina y de qué forma ha alterado el comportamiento normal del equipo.

En este caso quise representar tres decisiones típicas dentro de una infección con impacto operativo claro:

1. la creación masiva de cuentas para introducir ruido y dificultar el análisis;
2. la existencia de una cuenta privilegiada oculta entre ese ruido;
3. la persistencia mediante un servicio malicioso que altera la conectividad redirigiendo tráfico.

La gracia del laboratorio no está en resolver preguntas sueltas, sino en entender la intención de cada fase. Cada evidencia está puesta para forzar una lectura técnica: no basta con ver que algo falla, hay que explicar por qué falla y qué decisión de diseño hay detrás.

Información técnica

Contexto del laboratorio

El escenario parte de algo cotidiano: un usuario doméstico que instala o ejecuta algo que no debería y, a partir de ahí, el sistema deja de comportarse con normalidad. Elegí este enfoque porque obliga a pensar menos en la explotación clásica y más en el análisis posterior: qué ha cambiado, qué artefactos permanecen y cómo distinguir ruido de evidencia útil.

Ese planteamiento también ayuda a salir del patrón habitual de muchos retos técnicos en los que toda la atención se la lleva la intrusión inicial. Aquí lo importante es lo que queda después. La máquina está construida para que el participante tenga que responder preguntas concretas, pero el aprendizaje real aparece al relacionarlas entre sí.

Revisión de cuentas creadas

Una de las primeras piezas que quise introducir en este laboratorio fue la creación masiva de usuarios con un patrón común. A nivel técnico, esto permite detectar que el sistema ha sido manipulado; a nivel didáctico, sirve para enseñar que no todas las cuentas nuevas tienen el mismo valor analítico.

La evidencia más evidente aparece al revisar los directorios personales:

jony@jony-VirtualBox:~$ ls /home/
challangue00  challangue07  challangue14  challangue21  challangue28  challangue35  challangue42  challangue49
challangue01  challangue08  challangue15  challangue22  challangue29  challangue36  challangue43  challangue50
challangue02  challangue09  challangue16  challangue23  challangue30  challangue37  challangue44  jony
challangue03  challangue10  challangue17  challangue24  challangue31  challangue38  challangue45
challangue04  challangue11  challangue18  challangue25  challangue32  challangue39  challangue46
challangue05  challangue12  challangue19  challangue26  challangue33  challangue40  challangue47
challangue06  challangue13  challangue20  challangue27  challangue34  challangue41  challangue48

Pero el diseño no se queda en lo visible. La intención era obligar a no confiar solo en el listado de /home/, sino a contrastarlo con la base real de cuentas del sistema. Por eso la comprobación relevante está en /etc/passwd:

awk -F: '/^challangue/ {print $1, $6}' /etc/passwd
challangue00 /home/challangue00
challangue01 /home/challangue01
challangue02 /home/challangue02
challangue03 /home/challangue03
challangue04 /home/challangue04
challangue05 /home/challangue05
challangue06 /home/challangue06
challangue07 /home/challangue07
challangue08 /home/challangue08
challangue09 /home/challangue09
challangue10 /home/challangue10
challangue11 /home/challangue11
challangue12 /home/challangue12
challangue13 /home/challangue13
challangue14 /home/challangue14
challangue15 /home/challangue15
challangue16 /home/challangue16
challangue17 /home/challangue17
challangue18 /home/challangue18
challangue19 /home/challangue19
challangue20 /home/challangue20
challangue21 /home/challangue21
challangue22 /home/challangue22
challangue23 /home/challangue23
challangue24 /home/challangue24
challangue25 /home/challangue25
challangue26 /home/challangue26
challangue27 /home/challangue27
challangue28 /home/challangue28
challangue29 /home/challangue29
challangue30 /home/challangue30
challangue31 /home/challangue31
challangue32 /home/challangue32
challangue33 /home/challangue33
challangue34 /home/challangue34
challangue35 /home/challangue35
challangue36 /home/challangue36
challangue37 /home/challangue37
challangue38 /home/challangue38
challangue39 /home/challangue39
challangue40 /home/challangue40
challangue41 /home/challangue41
challangue42 /home/challangue42
challangue43 /home/challangue43
challangue44 /home/challangue44
challangue45 /home/challangue45
challangue46 /home/challangue46
challangue47 /home/challangue47
challangue48 /home/challangue48
challangue49 /home/challangue49
challangue50 /home/challangue50
challangue1O /home/.hidden_challangue1O

La clave de esta fase está en esa última entrada. No me interesaba solo que el jugador contara usuarios, sino que detectara que entre decenas de cuentas aparentemente homogéneas hay una distinta: su home no sigue el mismo patrón visible y, además, el nombre está pensado para provocar errores de lectura rápida.

El recuento final queda así:

jony@jony-VirtualBox:~$ awk -F: '/^challangue/ {print $1}' /etc/passwd | wc -l
52

La respuesta correcta es 52, pero lo importante es el porqué del diseño: quería representar una técnica sencilla de ocultación basada en volumen y naming engañoso. En entornos reales no siempre se esconde algo sofisticado; muchas veces basta con enterrarlo entre artefactos repetitivos para que pase desapercibido en una revisión superficial.

La cuenta privilegiada dentro del ruido

Una vez introducido el ruido, la siguiente decisión de diseño era colocar dentro de él la cuenta realmente relevante. No quería que el hallazgo dependiera de una vulnerabilidad, sino de una buena lectura de atributos del sistema: UID, GID y grupos suplementarios.

La comprobación que deja clara esa diferencia es esta:

jony@jony-VirtualBox:~$ id challangue1O
uid=65000(challangue1O) gid=65000(hidden_group) grupos=65000(hidden_group),27(sudo)

La respuesta pedida por el laboratorio es 65000, pero el punto interesante no es solo el número. Lo importante es que esa cuenta, aparentemente una más dentro del patrón challangueXX, tiene privilegios efectivos al pertenecer al grupo sudo.

Diseñé esta fase para enseñar dos cosas. La primera es que revisar únicamente nombres de usuario no basta; hay que mirar contexto de privilegios. La segunda es que un atacante no necesita crear una cuenta con un nombre escandalosamente evidente para mantener acceso útil. Le basta con incrustarla en una estructura que parezca desordenada pero inocua.

También me interesaba reflejar un error operativo bastante real: organizaciones que revisan altas de cuentas por volumen, pero no cruzan bien esa información con memberships privilegiados. En ese tipo de escenarios, el problema no es la cuenta en sí, sino su capacidad efectiva dentro del sistema.

Persistencia mediante systemd

La siguiente pieza del laboratorio era la persistencia. Aquí quise evitar mecanismos excesivamente rebuscados y optar por uno muy reconocible y, precisamente por eso, muy útil como aprendizaje: un servicio systemd malicioso.

La evidencia aparece al listar unidades de servicio:

systemctl list-units --type=service --all
● che.service                              loaded    failed   failed  Disable DNS on boot

El nombre del servicio malicioso es che.service.

La decisión de dejarlo en estado fallido no es casual. Está pensada para que el participante no busque solo servicios activos, sino también unidades cargadas o fallidas que sigan siendo relevantes dentro del historial del sistema. En muchos análisis rápidos se filtra demasiado pronto por “lo que está corriendo ahora” y se pierde contexto de persistencia o sabotaje.

Además, el texto descriptivo del servicio apunta a una narrativa engañosa: algo que aparentemente “deshabilita DNS” cuando, en realidad, el comportamiento observado tiene que ver con una manipulación de tráfico más amplia. Ese pequeño desajuste entre descripción y efecto también forma parte del aprendizaje. No todo lo que declara un artefacto malicioso coincide con su función real.

Sabotaje de red y redirección de tráfico

La fase final de la cadena se centra en el impacto visible para el usuario. En el relato del reto, el problema aparente es que “internet no funciona”. No quise plantearlo como una caída abstracta, sino como una consecuencia directa de un mecanismo de sabotaje que el analista puede reconstruir.

El script responsable aparece en el home oculto de la cuenta relevante:

sudo ls -l /home/.hidden_challangue1O/
total 4
-rwxr-xr-x 1 root root 167 mar 10 12:26 redirect.sh

Su contenido explica el síntoma:

jony@jony-VirtualBox:~$ sudo cat /home/.hidden_challangue1O/redirect.sh
#!/bin/bash
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 0.0.0.0
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 0.0.0.0

Aquí las respuestas del reto son directas:

• script de redirección: redirect.sh
• IP de destino: 0.0.0.0

Pero la parte que me interesaba enseñar va más allá de esos valores. Esta fase representa un sabotaje operativo muy simple: alterar la salida HTTP y HTTPS para inutilizar la conectividad desde la propia máquina. No hace falta un malware complejo para generar impacto visible; con tocar reglas de iptables en el punto adecuado basta para romper comportamiento crítico de usuario y, al mismo tiempo, desviar la investigación hacia una falsa “caída de internet”.

También quise que el laboratorio obligara a relacionar persistencia e impacto. El servicio no existe de forma aislada: tiene sentido porque apunta a un script concreto, y ese script tiene sentido porque explica el síntoma que motiva toda la investigación. Esa continuidad es importante. La máquina está construida para que cada artefacto responda a una decisión de diseño y no parezca una colección arbitraria de indicadores.

Qué quería enseñar al diseñar el amigo

Este laboratorio lo construí para enseñar una cadena pequeña pero coherente de post-infección en Linux. No hace falta una intrusión especialmente aparatosa para comprometer la operativa de un sistema y dejar persistencia útil. De hecho, uno de los aprendizajes más reutilizables es precisamente ese: muchas incidencias “menores” esconden cambios muy básicos pero bien colocados.

La secuencia que quise reflejar fue esta:

1. el atacante crea volumen artificial mediante cuentas repetitivas;
2. inserta entre ellas una cuenta con privilegios;
3. deja persistencia mediante systemd;
4. ejecuta sabotaje de conectividad con reglas NAT sobre tráfico saliente.

Esa cadena tiene sentido fuera del CTF porque combina tres categorías de fallo muy comunes en incidentes reales: falta de control sobre identidades locales, escasa revisión de persistencia en servicios del sistema y visibilidad insuficiente sobre cambios en reglas de red del host.

Si tuviera que resumir la intención del laboratorio en una sola idea, sería esta: quise construir una máquina en la que el participante no “explota” nada, sino que aprende a leer una infección sencilla con criterio. Ese era el valor real del reto.

Recursos y referencias

• Documentación de systemd para revisión de unidades y persistencia.
• Manual de iptables para interpretar reglas NAT en salida.
• Revisión de /etc/passwd, grupos y memberships como parte básica de análisis de compromiso en Linux.