Quartz 4

Práctica: Análisis de una Máquina Vulnerable con Docker

8 min read

Práctica: Análisis de una Máquina Vulnerable con Docker

Relacionado: NMAP. DICCIONARIOS. HashCat. Pivoting. Hydra.

En esta práctica vamos a desplegar una máquina vulnerable utilizando Docker, con el objetivo de analizarla y practicar técnicas de enumeración y escaneo de puertos. Utilizaremos herramientas como nmap y configuraciones específicas para interactuar con la máquina de forma efectiva.

1. Descarga del entorno vulnerable

El primer paso consiste en clonar el repositorio que contiene las máquinas vulnerables. Para ello, ejecutamos el siguiente comando:

git clone https://github.com/junquera/vuln-boxes

Este repositorio contiene diferentes escenarios preparados para ser desplegados en entornos controlados con fines educativos o de pentesting.

2. Configuración de Docker

Antes de levantar la máquina, es necesario asegurarnos de que nuestro usuario (en este caso kali) tenga los permisos necesarios para ejecutar Docker sin necesidad de usar sudo constantemente. Para otorgar estos permisos, utilizamos el siguiente comando:

sudo usermod -aG docker kali

Nota: Es recomendable cerrar sesión y volver a iniciarla después de aplicar este cambio para que los permisos se actualicen correctamente.

3. Acceso al escenario de práctica

Una vez clonado el repositorio, accedemos al directorio de la máquina vulnerable que deseamos utilizar. En este caso, trabajaremos con la máquina llamada biblioteca:

cd vuln-boxes/biblioteca

Este directorio contiene el entorno Docker necesario para desplegar el escenario.

4. Obtención de la IP de la máquina

Para interactuar con la máquina, primero necesitamos conocer su dirección IP dentro de la red Docker. Para ello inspeccionamos la red asociada al contenedor:

docker network inspect biblioteca_frontend

Este comando nos mostrará información detallada sobre la red, incluyendo las direcciones IP asignadas a los distintos contenedores.

5. Escaneo de puertos con Nmap

Opción 1: Escaneo en la red interna de Docker

Si se ha obtenido correctamente la IP de la máquina desde el paso anterior, podemos proceder a realizar un escaneo de puertos con nmap. El siguiente comando busca identificar el servicio que está escuchando en el puerto 2222 en la subred 172.18.0.1/24:

nmap -sV -p 2222 172.18.0.1/24

Este escaneo permite detectar la versión del servicio activo en ese puerto, lo cual es útil para identificar posibles vulnerabilidades asociadas.

Opción 2: Escaneo a través de localhost

En caso de que el escaneo anterior no funcione correctamente o que la máquina esté mapeando el puerto hacia el host, se puede realizar el escaneo directamente contra localhost:

nmap -sV -p 2222 localhost

Esta opción es útil cuando el contenedor redirige puertos hacia el sistema anfitrión y no es posible acceder directamente a la IP interna.

6. Enumeración de servicios

Una vez que hemos identificado que el puerto 2222 está abierto, es probable que se trate de un servicio SSH. Podemos comprobarlo e intentar acceder con el siguiente comando:

ssh localhost -p 2222

Esto intentará abrir una conexión SSH a través de localhost en el puerto especificado. Aunque todavía no disponemos de credenciales válidas, esta prueba nos permite verificar que el servicio está activo y accesible.

7. Obtención de diccionarios para fuerza bruta

Para preparar un ataque de fuerza bruta es necesario contar con listas de posibles nombres de usuario y contraseñas. Una fuente muy popular es el repositorio SecLists, mantenido por Daniel Miessler, donde se recopilan diccionarios ampliamente utilizados en pruebas de penetración:

GitHub – SecLists:
https://github.com/danielmiessler/SecLists

De este repositorio descargaremos dos listas concretas:

También puedes clonar todo el repositorio para tener acceso completo a los diccionarios:

git clone https://github.com/danielmiessler/SecLists

8. Ataque de fuerza bruta con Hydra

Una vez descargados los diccionarios, podemos utilizar la herramienta hydra para lanzar un ataque de fuerza bruta contra el servicio SSH que se encuentra corriendo en el puerto 2222.

El comando sería el siguiente:

hydra -L ~/home/kali/Downloads/top-usernames-shortlist.txt -P ~/home/kali/Downloads/500-worst-passwords.txt ssh://172.18.0.1:2222

  • -L indica el archivo con la lista de posibles nombres de usuario.

  • -P indica el archivo con la lista de contraseñas.

  • ssh://172.18.0.1:2222 define el objetivo: el protocolo, la IP y el puerto.

9. Escaneo de vulnerabilidades con Nmap

Además del ataque de fuerza bruta, es recomendable utilizar nmap para descubrir vulnerabilidades conocidas en los servicios expuestos.

Para ello, usamos el siguiente comando que lanza un conjunto de scripts de detección de vulnerabilidades:

nmap --script vuln 172.18.0.1 -p 2222

Este comando inspecciona si hay vulnerabilidades conocidas en el servicio SSH que corre en ese puerto.

También es útil ver qué métodos de autenticación acepta el servidor SSH:

nmap --script ssh-auth-methods 172.18.0.1 -p 2222

10. Inyección de comandos en first character

Durante el análisis de la máquina, observamos que existe una funcionalidad que evalúa lo que se introduce como “first character”. Este campo permite ejecutar comandos del sistema si se formatean dentro de una expresión como $(...).

Esto nos abre la puerta a una inyección de comandos, y por tanto, a una posible ejecución remota arbitraria.

Ejemplos de comandos útiles

A continuación se listan algunos comandos que se pueden probar inyectándolos directamente en el campo “first character”:

$(ls -l)

Lista los archivos del directorio actual con permisos y metadatos.

$(ls -la .ssh)

Muestra los archivos ocultos del directorio .ssh, que podrían incluir claves privadas, archivos de configuración o scripts.

$(cat /etc/ssh/sshd__config.d/*)

Extrae el contenido de los archivos de configuración del servicio SSH.

$(cat /etc/passwd)

Lee el archivo que contiene la lista de usuarios del sistema. No contiene contraseñas, pero sí información útil como rutas home y shells asignadas.

$(cat /etc/shadow)

Contiene las contraseñas hasheadas de los usuarios del sistema. Solo accesible si tenemos privilegios elevados.

$(cat .ssh/command.sh)

Este archivo es especialmente interesante: contiene un script que ejecuta cualquier entrada precedida por $. Si no se da ese caso, entonces lanza una conexión SSH al backend con la palabra introducida como argumento. Por tanto, si borramos este archivo con:

sudo rm .ssh/command.sh

… y después ejecutamos un comando arbitrario, podríamos obtener acceso directo o incluso una shell interactiva si se gestiona correctamente.

Consola mediante keymon

Si escribimos keymon como “first character”, obtenemos acceso a una consola directa:

first character: keymon

Esto puede permitir ejecutar comandos directamente, de forma mucho más cómoda.

11. Escalada de privilegios

Una vez dentro del sistema, buscamos elevar nuestros privilegios para obtener control completo sobre la máquina. En sistemas como Kali Linux, los usuarios creados por defecto suelen pertenecer al grupo sudo, lo que significa que pueden ejecutar comandos como administrador.

Estrategias:

  • Cambiar la contraseña de un usuario administrador existente.

  • Crear un nuevo usuario y añadirlo al grupo sudo.

12. Pivoting: paso del frontend al backend

El siguiente paso en la cadena de ataque es el movimiento lateral, también conocido como pivoting, con el objetivo de acceder desde la máquina actual (frontend) a otra máquina conectada en la red (backend).

Antes de hacerlo, conviene seguir enumerando servicios y accesos:

ssh test@backend

Podemos probar distintas combinaciones de usuario y contraseña. También resulta útil identificar los UIDs de los usuarios en el sistema, que pueden darnos pistas sobre cuentas activas, cuentas del sistema o cuentas con privilegios.

13. Recolección de hashes de contraseñas

Una técnica clásica de post-explotación es la lectura del archivo /etc/shadow, que contiene los hashes de las contraseñas de los usuarios. Este archivo solo es accesible con permisos elevados (por ejemplo, usando sudo).

cat /etc/shadow

Una vez obtenidos los hashes, podemos comparar con bases de datos públicas de contraseñas como CrackStation o usar herramientas como john o hashcat para intentar descifrarlos.

14. Guardado de credenciales para acceso posterior

De los resultados del archivo /etc/shadow, podemos copiar las líneas que correspondan a usuarios relevantes (por ejemplo test y admin) y pegarlas en un archivo llamado keys. Podemos crear o editar este archivo usando:

nano keys

Este archivo se puede usar más adelante para automatizar el crackeo de hashes o para futuras conexiones SSH.

Aquí tienes el nuevo fragmento completamente formateado, ampliado y organizado en

15. Crackeo de contraseñas con John the Ripper

Después de haber extraído el contenido del archivo /etc/shadow y guardado las entradas relevantes (por ejemplo, los usuarios test y admin) en un archivo llamado keys, podemos utilizar la herramienta John the Ripper para intentar descifrar las contraseñas.

Ejecución de John:

john keys

Este comando lanza el proceso de crackeo automático sobre los hashes almacenados en keys. John intentará comparar los hashes con su base de datos de contraseñas más comunes, realizando ataques por diccionario y otras técnicas.

Resultado:

El resultado nos mostrará los nombres de usuario y sus contraseñas en texto plano, una vez crackeadas con éxito. En este caso, conseguimos la contraseña del usuario admin.

16. Acceso remoto al backend

Una vez obtenida la contraseña de admin, podemos utilizarla para acceder al servidor backend mediante SSH:

ssh admin@backend

En nuestro caso concreto, la contraseña descubierta para admin fue:

123456789

Después de autenticarnos correctamente, accedemos al sistema remoto como el usuario admin.

Acceso mediante clave pública (.ssh/authorized_keys)

También es posible realizar el acceso sin necesidad de contraseña si conseguimos insertar una clave pública en el archivo:

~/.ssh/authorized_keys

Este archivo permite autenticar automáticamente a cualquier cliente SSH que posea la clave privada correspondiente. Es una técnica común para automatizar accesos, y a menudo se descuida en auditorías:

ssh admin@backend -i ~/.ssh/id_rsa

️ Importante: El archivo authorized_keys rara vez se revisa o se protege correctamente, lo que lo convierte en una vía potencial para persistencia o acceso silencioso.

17. Documentación y herramientas adicionales

Una vez completado el acceso y las fases principales del pentesting, lo siguiente sería generar un informe de auditoría técnica que incluya:

  • Enumeración inicial

  • Explotación de servicios

  • Escalada de privilegios

  • Movimiento lateral

  • Evidencias (pantallazos, comandos utilizados)

  • Recomendaciones de mitigación

Recursos recomendados

HackTricks
Sitio web excelente para técnicas de hacking ofensivo organizadas por tecnología:
https://book.hacktricks.xyz/

CTF Atenea (CCN-CERT)
Plataforma de entrenamiento en ciberseguridad del Centro Criptológico Nacional (España):
https://atenea.ccn-cert.cni.es/

Graph View

Backlinks