Las 5 fases de un pentest, explicadas con un caso real

Un pentest no es sentarse a lanzar herramientas hasta que algo cae. Es un proceso con fases, y saltarse una se paga en la siguiente. Esto es cómo se hace, con lo que realmente ocurre en cada tramo.

Fase 0: alcance y autorización

Antes de tocar nada, papel. Y no es burocracia: es lo que separa el trabajo del delito.

En esta fase se define:

• Qué entra y qué no. Rangos de IP, dominios, aplicaciones. Lo que no está escrito, no se toca.
• Ventana temporal. Cuándo se puede atacar. Nadie quiere el escaneo agresivo durante el cierre contable.
• Qué está prohibido. Denegación de servicio, ingeniería social a empleados concretos, ataques sobre producción.
• Contactos de emergencia. Si tumbas un servicio sin querer, tiene que haber un teléfono al que llamar en dos minutos.
• La autorización firmada. Por alguien con capacidad para darla, no por el técnico que te abrió la puerta.

Un detalle que se olvida siempre: si el objetivo está alojado en un proveedor cloud, ese proveedor también tiene sus propias reglas sobre pruebas de intrusión. El contrato con el cliente no sustituye a las condiciones del proveedor.

Caso real, resumido: una empresa de logística contrata una auditoría de su infraestructura externa. Alcance: dos rangos públicos y todos los subdominios de su dominio principal. Fuera: cualquier cosa que afecte a la disponibilidad del sistema de seguimiento de envíos.

Fase 1: reconocimiento

Lo primero es saber qué hay. Y aquí, cuanto más pasivo, mejor: la información que se obtiene sin enviar un solo paquete al objetivo no genera alertas y suele ser la más reveladora.

Pasivo: certificados TLS, registros DNS históricos, la Wayback Machine, repositorios públicos, perfiles de empleados en LinkedIn, filtraciones de credenciales antiguas. Todo esto es OSINT, y es la fase que más determina el resto.

Activo: escaneo de puertos, identificación de versiones, enumeración de directorios web.

amass enum -passive -d logistica-ejemplo.com
nmap -p- --min-rate 5000 -oA completo 203.0.113.10
nmap -sVC -p 22,80,443,3389 -oA detalle 203.0.113.10

Qué apareció en el caso: 47 subdominios, de los cuales 11 no estaban en el inventario que la empresa nos había dado. Uno de ellos, pruebas-antiguo, respondía con un panel de administración de un gestor de contenidos sin actualizar desde hacía tres años.

Ese es el patrón más habitual del sector: el problema casi nunca es el servidor que vigilan. Es el que olvidaron.

Fase 2: análisis y explotación

Con el mapa delante, se buscan los fallos y se comprueba cuáles son reales.

La parte importante y la que distingue a un profesional: una vulnerabilidad no explotada es una hipótesis. Los escáneres automáticos generan falsos positivos a un ritmo notable, y entregar un informe lleno de hallazgos que no se sostienen destruye tu credibilidad con el cliente más rápido que no encontrar nada.

El orden de prioridad, cuando el tiempo es limitado:

1. Lo que da acceso directo: credenciales por defecto, servicios expuestos sin autenticación, ejecución remota de código conocida.
2. Lo que da acceso encadenado: una subida de ficheros más un directorio ejecutable, un SSRF más un servicio interno confiado.
3. Lo que da información: fugas de rutas, versiones, mensajes de error verbosos.

Qué pasó en el caso: el panel olvidado permitía subir un fichero con extensión doble. El servidor lo interpretó como PHP. Shell.

No hizo falta ningún exploit sofisticado. Casi nunca hace falta.

Fase 3: post-explotación

Estar dentro no es el final: es donde empieza a medirse el impacto real. Y el impacto es lo que el cliente va a leer.

• Escalada de privilegios. De www-data a root, de usuario de dominio a administrador.
• Movimiento lateral. Desde esa máquina, ¿a qué más se llega?
• Persistencia. Se documenta cómo se conseguiría, pero en un pentest normal no se deja instalada. Y si se deja algo por acuerdo expreso, se retira y se certifica su retirada.
• Acceso a datos. Aquí hay que tener mucho cuidado: se demuestra que se puede acceder, no se descarga la base de datos de clientes. Una captura de la estructura de la tabla y del número de registros prueba lo mismo sin convertirte en un problema de protección de datos.

sudo -l
find / -perm -4000 -type f 2>/dev/null
bloodhound-python -u usuario -p contrasena -d logistica.local -c all

En el caso: desde el servidor comprometido se alcanzaba la red interna por una VPN mal segmentada. Desde ahí, un servicio de copias de seguridad con credenciales de administrador de dominio guardadas en un fichero de configuración legible por cualquiera.

Del panel olvidado al dominio completo en seis horas.

Fase 4: el informe

Es la fase que decide si el trabajo sirvió de algo, y a la que menos tiempo dedica todo el mundo.

Un informe útil tiene dos mitades que se leen por separado:

Resumen ejecutivo — dos páginas, sin jerga, para quien firma el presupuesto. Qué riesgo tiene el negocio, cuánto costaría que pasara, y qué tres cosas hay que arreglar primero.

Detalle técnico — un hallazgo por página, cada uno con:

• Descripción y severidad, con la puntuación CVSS y por qué.
• Reproducción paso a paso, con las peticiones exactas.
• Evidencia: capturas, salida de comandos, con los datos sensibles tapados.
• Remediación concreta. No "aplicar buenas prácticas", sino "actualizar a la versión 4.2.1 o desactivar el módulo de subida en config/uploads.yml".

La prueba de fuego de un buen informe: ¿puede el administrador de sistemas del cliente arreglar el fallo leyendo solo la ficha, sin llamarte? Si la respuesta es no, el informe está a medias.

En el caso: 14 hallazgos, 3 críticos. El resumen ejecutivo cabía en una página y la conclusión era una sola frase: no había un problema de seguridad, había un problema de inventario. Nadie sabía que aquel subdominio seguía en pie.

Fase 5: la que no cuenta nadie

La reprueba. Semanas después se vuelve a comprobar que lo que dijiste que arreglaran está arreglado. Sorprende la frecuencia con la que no lo está, o con la que el parche ha introducido un fallo nuevo.

Y después, borrar. Toda la información del cliente que quedó en tu máquina se destruye en el plazo acordado. Un pentester con una carpeta llena de credenciales de clientes antiguos es, él mismo, el mayor riesgo de esos clientes.

Cómo practicar esto sin cliente

La metodología se aprende repitiéndola. Las plataformas de máquinas vulnerables son el sitio para hacerlo, y la clave es tratarlas como si fueran un encargo real: reconocimiento completo antes de tocar nada, notas desde el primer minuto, e informe al final aunque nadie lo vaya a leer.

Eso último es lo que casi nadie hace, y es lo que más te va a diferenciar cuando busques trabajo.

El curso de Hack The Box enseña exactamente esa metodología aplicada a máquinas reales, y el curso de Kali Linux —gratuito— recorre este mismo ciclo completo, informe incluido, en un laboratorio que montas tú.

Si estás empezando y quieres el mapa entero, lo tienes en cómo ser hacker ético desde cero.