Forgotten Portal
Ejercicio de pentesting en un laboratorio controlado, hecho durante el acelerador de ciberseguridad de Nodo EAFIT: siete hallazgos documentados, un informe técnico y uno ejecutivo.
Por Valentina Ramírez
Publicado: 16 de junio de 2026 · Actualizado: 2 de octubre de 2026
Cotizar un proyecto así
- Problema
- Entender qué tan lejos llega alguien sin credenciales contra un servidor mal configurado, y explicar ese riesgo a quien decide el presupuesto.
- Solución
- Un ejercicio de pentesting en un laboratorio controlado, con cada hallazgo documentado y dos informes, uno técnico y uno ejecutivo.
- Resultado
- Siete hallazgos documentados en dos informes, uno técnico y uno ejecutivo.
- Nmap
- Gobuster
- Netcat
- Python
- MITRE ATT&CK
- PTES
- Linux
- DockerLabs
El problema
Qué tan lejos llega alguien sin credenciales contra un servidor mal configurado, y cómo se le explica ese riesgo tanto a un equipo técnico como a quien decide el presupuesto.
Información de más en el código público
Un comentario olvidado en el HTML dejaba ver un usuario del sistema y una ruta no publicada. Todo lo que el servidor envía al navegador es superficie de ataque.
Una carga de archivos sin control real
El formulario aceptaba tipos ejecutables y los guardaba dentro de la raíz web. Validar solo la extensión no basta.
Secretos donde no deben estar
Credenciales codificadas en un registro, una clave SSH repetida en todas las cuentas y su contraseña escrita en un documento interno. Codificar no es proteger.
Permisos de administración demasiado amplios
Una cuenta podía ejecutar como administrador una utilidad común sin contraseña. Un permiso de sudo sobre un binario que ejecuta comandos equivale a un acceso total.
Resultados
- Siete hallazgos documentados, con tres críticos, dos altos y dos medios, cada uno con CVSS, evidencia y remediación.
- Un informe técnico de 18 páginas y uno ejecutivo de 14, con matriz de riesgo, mapeo a MITRE ATT&CK y hoja de ruta de remediación.
- 28 capturas de evidencia ligadas al writeup, publicadas con licencia MIT junto al repositorio.
Ver detalle técnico AbrirOcultar detalle técnico
Qué construí
- 01
Alcance: un único contenedor Docker de DockerLabs (Ubuntu con Apache en el puerto 80 y OpenSSH en el 22), ejecutado el 23 de marzo de 2026. Nada fuera del contenedor entra en el alcance.
- 02
Metodología PTES en seis fases: preparación, exploración, análisis, ataque, acceso profundo y documentación. La documentación corre en paralelo con el resto, con una captura por paso.
- 03
Reconocimiento y enumeración con Nmap, Gobuster y la inspección del código fuente de la página, sin credenciales.
- 04
Siete hallazgos, ordenados por severidad: tres críticos, dos altos y dos medios, cada uno con vector y puntaje CVSS v3.1, componente afectado, probabilidad e impacto.
- 05
Clasificación CWE en el writeup, mapeo de las acciones a técnicas de MITRE ATT&CK y matriz de riesgo con el esquema de probabilidad por impacto de ISO/IEC 27005.
- 06
Dos entregables: un informe técnico de 18 páginas para el equipo de seguridad y un informe ejecutivo de 14 páginas con riesgo de negocio, exposición financiera y hoja de ruta de remediación priorizada.
- 07
Evidencia reproducible: 28 capturas anotadas en el repositorio, ligadas a cada paso del writeup. El material está bajo licencia MIT.
Writeup paso a paso
Recorrido técnico en español con una captura por paso, publicado en el blog y en el repositorio.
Informe técnico
Siete hallazgos con CVSS, componente afectado, evidencia, remediación, mapeo a MITRE ATT&CK y matriz de riesgo.
Informe ejecutivo
El mismo trabajo traducido a riesgo de negocio, costo estimado de remediar frente al de una brecha y orden de prioridades.
Mapeo MITRE ATT&CK
Tácticas y técnicas ligadas a cada acción del ejercicio, en un archivo aparte.
Evidencia
28 capturas anotadas que cubren el ejercicio de principio a fin.
Cómo se encadenan los hallazgos
- 01 Información interna en el código fuente público (medio).
- 02 Carga de archivos sin restricción real, con ejecución de código en el servidor (crítico).
- 03 Directorio de cargas visible para cualquiera (medio).
- 04 Credenciales en un registro legible por el servicio web (alto).
- 05 Una misma clave SSH en todas las cuentas (crítico) y su contraseña en un documento interno (alto).
- 06 Permiso de sudo sin contraseña sobre un binario que ejecuta comandos (crítico).
Decisiones de arquitectura
01 PTES como estructura VerCerrar
- Contexto
- Un ejercicio sin método se vuelve una lista de trucos y no se puede repetir ni comparar.
- Trade-off
- Seguir seis fases exige documentar aunque el ejercicio sea de laboratorio y de una sola máquina.
- Decisión
- PTES en seis fases, con la documentación en paralelo y una captura por paso.
02 Dos informes para dos públicos VerCerrar
- Contexto
- Un equipo técnico necesita el detalle de cada hallazgo y quien decide necesita saber qué hacer primero y cuánto cuesta.
- Trade-off
- Mantener dos documentos duplica la revisión, y cualquier cambio en un hallazgo debe reflejarse en ambos.
- Decisión
- Un informe técnico con CVSS, evidencia y remediación, y uno ejecutivo con riesgo de negocio, costos y prioridades.
03 Cada hallazgo con severidad y remediación VerCerrar
- Contexto
- Una lista de debilidades sin prioridad ni solución no ayuda a corregir nada.
- Trade-off
- Puntuar con CVSS y probabilidad por impacto añade criterio propio que otra persona podría ver distinto.
- Decisión
- Cada hallazgo lleva CVSS v3.1, probabilidad e impacto, clasificación CWE y una remediación concreta.
04 Un entorno controlado y sin datos reales VerCerrar
- Contexto
- Practicar técnicas ofensivas solo es válido dentro de un alcance autorizado.
- Trade-off
- Una máquina de laboratorio no tiene usuarios ni tráfico reales, así que el impacto de negocio del informe ejecutivo es estimado.
- Decisión
- Un único contenedor de DockerLabs como alcance, con las cifras de impacto tomadas de una fuente publicada (IBM Cost of a Data Breach 2024).
Aprendizajes
Ningún hallazgo del ejercicio dependía de una vulnerabilidad desconocida: eran errores de configuración y hábitos de trabajo que se repiten en entornos reales.
Un solo error rara vez basta; el daño sale de encadenar varios hallazgos pequeños, así que corregir el eslabón más barato ya corta la cadena.
El mismo hallazgo se explica distinto según quién lo lee: el detalle técnico y el riesgo de negocio son dos documentos, no uno.