Parte: 3 — Hacking ético y pentesting: metodología · Fuente: Penetration Testing Execution Standard (PTES) y OSSTMM 3 (ISECOM) ⏱️ Duración estimada: 90 min · Nivel: Fundamentos
Entender por qué un pentest necesita una metodología formal y dominar las dos referencias más usadas de la industria: el PTES (siete fases de ejecución) y el OSSTMM (medición de la superficie de ataque y controles). Al final, el alumno sabrá encuadrar cualquier trabajo ofensivo dentro de un proceso auditable, repetible y comparable entre engagements.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Qué es una metodología y por qué no basta con "hackear" | Sin proceso no hay repetibilidad ni defensa legal |
| 2 | Las 7 fases del PTES | Es el estándar de facto para estructurar el trabajo |
| 3 | OSSTMM y el concepto de superficie de ataque medible | Aporta métricas (RAV) y rigor científico |
| 4 | NIST SP 800-115 y OWASP WSTG como complementos | Marcos oficiales para cumplimiento y web |
| 5 | Tipos de test: black/gray/white box | Definen cuánta información recibe el equipo |
| 6 | Red team vs. pentest vs. análisis de vulnerabilidades | Confundirlos genera expectativas erróneas |
| 7 | Entregables por fase | El cliente paga por evidencia y remediación, no por "acceso" |
| 8 | Madurez del programa de seguridad (CMM aplicado a seguridad) | Determina si conviene un pentest puntual o un programa continuo |
| 9 | El rol del defensor durante el pentest | Un equipo azul que sabe qué esperar detecta antes y mejora sus alertas |
La diferencia entre un pentester y alguien que simplemente sabe usar herramientas es el método. Un proceso repetible da tres cosas que el acceso aislado no da: cobertura (la garantía de no dejar zonas sin mirar por ir a lo llamativo), defensa jurídica (un registro de qué se hizo, cuándo y con qué autorización) y valor para el cliente, que no paga por un "estoy dentro" sino por un mapa de su riesgo y una ruta de remediación. Un hallazgo espectacular sin proceso alrededor es una anécdota; el mismo hallazgo dentro de una metodología es un informe accionable.
Por eso existen marcos estandarizados. El PTES (Penetration Testing Execution Standard) es el más usado para estructurar el trabajo de principio a fin; el OSSTMM aporta rigor científico y métricas; NIST SP 800-115 es la referencia para cumplimiento en el ámbito público; y OWASP WSTG es el equivalente detallado para aplicaciones web (la Parte 4). No compiten: se combinan según el encargo.
El PTES ordena el trabajo en una secuencia que va de lo administrativo a lo entregable, y cada fase alimenta a la siguiente. Recorrerlas fija el mapa de toda la parte.
El bucle entre post-explotación y recolección es lo que distingue un pentest real de una lista de comprobación: cada host comprometido abre una red nueva que reconocer, y el proceso itera hasta agotar el alcance. La fase que más se infravalora es la última: el informe es el producto, y un acceso perfecto mal documentado no vale nada.
Confundir servicios distintos genera expectativas equivocadas y contratos mal escritos. Un análisis de vulnerabilidades identifica y cataloga debilidades, normalmente con un escáner, sin explotarlas: da amplitud, no profundidad. Un pentest explota esas debilidades para demostrar impacto real y encadenar hallazgos, con un alcance y un tiempo acotados. Un red team es un ejercicio distinto en propósito: no busca cobertura sino emular a un adversario concreto contra objetivos concretos ("llegar a los datos de nóminas") poniendo a prueba también la detección y respuesta del equipo azul, con sigilo y sin avisar de cuándo ni cómo. Un cliente que pide un pentest cuando necesita un análisis de vulnerabilidades —o al revés— recibe algo que no le sirve.
El tipo de acceso previo también cambia el trabajo: black box (sin información, simula un externo), white box (acceso total a código y arquitectura, maximiza cobertura por unidad de tiempo) y gray box (un punto intermedio, el más común, con credenciales de usuario estándar). No hay uno mejor; hay uno adecuado a la pregunta que el cliente quiere responder.
Un detalle que la metodología moderna subraya: el pentest no ocurre contra un vacío, sino contra un equipo azul. Decidir si el SOC sabe o no que hay un test en marcha (announced vs. unannounced) es una decisión de la metodología, no un detalle. Un test anunciado mejora la cobertura y evita incidentes; uno no anunciado mide de verdad la capacidad de detección. Y en cualquier caso, el mejor pentest deja al defensor con alertas nuevas y mejores, no solo con una lista de agujeros. Esa conexión con la detección es la que enlaza esta parte con las Partes 7 y 8.
| Término | Definición concisa |
|---|---|
| Metodología | Proceso repetible que da cobertura, defensa legal y valor |
| PTES | Estándar de facto en siete fases para estructurar un pentest |
| OSSTMM | Metodología con métricas (RAV) y enfoque científico |
| NIST SP 800-115 | Guía oficial de pruebas de seguridad para cumplimiento |
| OWASP WSTG | Guía de pruebas de seguridad para aplicaciones web |
| Análisis de vulnerabilidades | Identificar debilidades sin explotarlas; amplitud |
| Pentest | Explotar debilidades para demostrar impacto; profundidad acotada |
| Red team | Emular a un adversario y poner a prueba la detección |
| Black box | El equipo no recibe información previa |
| White box | Acceso total a código y arquitectura |
| Gray box | Información parcial, como un usuario estándar |
| Announced / unannounced | Si el equipo azul sabe o no del test |
| Entregable | Producto de cada fase; el informe es el final |
| Modelado de amenazas | Decidir qué atacar y por qué antes de atacar |
Esta clase es metodológica, no ofensiva: no se ataca ningún sistema. Prepara:
⚠️ Nota ética: aunque esta clase no incluye explotación, sienta la base de que todo lo que viene después se realiza únicamente sobre sistemas propios o con autorización explícita y por escrito. La metodología existe, en parte, para dejar constancia de esa autorización.
Como esta clase es conceptual, el laboratorio es un ejercicio de planificación.
Produce un documento de plan de engagement de una página para un caso a tu elección que incluya: las 7 fases PTES con actividades, el tipo de test, el alcance con exclusiones, una métrica OSSTMM y el entregable.
Criterio de aceptación: el documento contiene las siete fases nombradas correctamente, un alcance con al menos una exclusión explícita y una métrica cuantitativa; otra persona podría leerlo y saber qué se hará y qué no.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| "Empecé a escanear sin plan y me perdí" | Falta de fase de threat modeling; define objetivos antes de tocar teclas |
| Cliente enfadado por un servicio caído | No se documentaron técnicas prohibidas; añade DoS a exclusiones del RoE |
| Informe sin priorización | Se saltó la fase de análisis; correlaciona hallazgos con impacto de negocio |
| "El test no es comparable con el del año pasado" | No se usó una métrica; adopta el RAV de OSSTMM para tener línea base |
| Confundir pentest con escaneo de vulnerabilidades | No hubo explotación ni prueba de impacto; aclara el tipo de servicio en el contrato |
| Plan copiado de otro cliente sin adaptar | Se saltó el modelado de amenazas específico; identifica activos y actores propios de cada organización |
| El equipo defensivo se entera del test por el informe final | No hubo coordinación purple team; define de antemano si el SOC será informado en tiempo real o a ciegas |
❓ ¿PTES y OSSTMM son excluyentes? No. PTES te da el proceso y OSSTMM te da las métricas. Muchos equipos usan PTES como columna vertebral y toman de OSSTMM la forma de cuantificar la superficie de ataque.
❓ ¿Necesito seguir una metodología si es solo un lab personal? Sí, por hábito. Practicar el proceso en el laboratorio hace que en un engagement real no improvises. Además te obliga a documentar, que es donde muchos principiantes fallan.
❓ ¿Qué metodología pide un cliente que busca cumplimiento PCI-DSS? Suele bastar con alinear el trabajo a NIST SP 800-115 y documentar cobertura; PTES organiza la ejecución. Confirma siempre el marco exigido antes de empezar.
❓ ¿El black box es "más realista" y por tanto mejor? Es más parecido a un atacante externo, pero por tiempo limitado cubre menos. Para madurez interna, el gray/white box suele dar más valor por hora.
❓ ¿Cómo elijo entre PTES/OSSTMM y un framework de cumplimiento como PCI-DSS? No son excluyentes: PCI-DSS exige que exista un test periódico, pero no dicta cómo ejecutarlo técnicamente. Usa PTES/OSSTMM para la ejecución y cita el marco de cumplimiento en el alcance y en el informe final.
❓ ¿Vale la pena avisar al equipo de detección antes del pentest? Depende del objetivo: si quieres medir la capacidad de detección real (purple teaming), no avisas al SOC y comparas después qué detectaron. Si el objetivo es solo validar vulnerabilidades técnicas, avisar reduce fricción operativa y evita respuestas de incidente innecesarias.
Clase 065 — Implementaciones seguras y errores criptográficos comunes