Saltar al contenido
Lección 2 de 8

Metodología de un Pentest

9 min read

Por Qué Importa la Metodología

Un pentest sin metodología es solo un conjunto de pruebas aleatorias. La metodología te da un proceso repetible, medible y defendible que garantiza cobertura completa y resultados consistentes. Cuando sigues un marco reconocido, puedes explicar a tu cliente exactamente qué hiciste, por qué y cómo, lo que aumenta la confianza y la calidad del entregable.

La metodología también te protege. Si documentas cada fase y cada decisión, puedes demostrar que actuaste de forma profesional y dentro del scope. En caso de que algo salga mal — un servicio que se cae, un dato que se expone — tu registro metódico es la evidencia de que seguiste un proceso responsable.

Además, la consistencia permite comparar evaluaciones a lo largo del tiempo. Si el cliente repite el test cada año con la misma metodología, puede medir su progreso de seguridad de forma objetiva.

Marco ético: la metodología también documenta que operaste dentro del alcance autorizado y las reglas de enfrentamiento.

Las Fases Clásicas

Aunque los nombres varían según el estándar, casi todos los pentests siguen las mismas fases lógicas. La primera es el reconocimiento, donde recopilas información sobre el objetivo sin (o con mínima) interacción directa. Le sigue el escaneo y enumeración, donde identificas hosts vivos, puertos abiertos, servicios y versiones.

A continuación viene el análisis de vulnerabilidades, donde correlacionas lo descubierto con fallas conocidas y configuraciones incorrectas. Luego la explotación, donde intentas aprovechar esas vulnerabilidades de forma controlada para demostrar impacto real. Después de obtener acceso, la post-explotación evalúa qué tan lejos podría llegar un atacante: escalada de privilegios, persistencia y movimiento lateral, siempre dentro del scope.

Finalmente, el reporte consolida todo en un documento profesional con hallazgos, evidencia, severidad y recomendaciones de remediación. Esta última fase suele ser la que más valor aporta al cliente, porque convierte el esfuerzo técnico en mejoras concretas.

Pre-engagement: El Trabajo Antes del Trabajo

Antes de la fase técnica existe una etapa crítica de pre-engagement. Aquí se define el scope, se firman las autorizaciones, se establecen las reglas de engagement y se acuerdan los objetivos. También se determina la modalidad — black box, grey box o white box — y se intercambian contactos de emergencia.

Esta etapa incluye fijar expectativas realistas. Un pentest tiene un tiempo limitado; no es una auditoría exhaustiva infinita. Acordar qué se prioriza, qué se considera fuera de límites y cómo se manejarán los hallazgos críticos en tiempo real evita fricciones después. Por ejemplo, si encuentras una vulnerabilidad crítica activamente explotable, ¿esperas al reporte final o notificas de inmediato? Eso se decide aquí.

Un pre-engagement bien hecho ahorra horas de confusión y protege tanto al pentester como al cliente. Es la base sobre la que se apoya todo el resto del proceso.

El Estándar PTES en Detalle

El PTES (Penetration Testing Execution Standard) es uno de los marcos más usados en la industria. Define siete fases que vale la pena desarrollar una por una, porque cada una responde a una pregunta distinta del engagement.

  1. Pre-engagement interactions. Se acuerdan alcance, reglas de enfrentamiento, ventanas de tiempo, contactos y autorización escrita. Sin esta fase no hay pentest legal: es la que convierte una prueba en un trabajo autorizado.
  2. Intelligence gathering. Se recolecta información del objetivo (OSINT, footprinting, enumeración) para entender la superficie de ataque real antes de tocar nada. Cuanto mejor el reconocimiento, más certero el resto.
  3. Threat modeling. Se identifican los activos valiosos y los adversarios plausibles, y se priorizan los vectores según el impacto para el negocio. Acá dejas de "probar todo" y empiezas a probar lo que importa.
  4. Vulnerability analysis. Se correlaciona lo enumerado con vulnerabilidades y configuraciones débiles, validando manualmente para descartar falsos positivos del escáner.
  5. Exploitation. Se demuestra impacto real explotando de forma controlada y reversible, evitando denegación de servicio salvo que el scope lo autorice explícitamente.
  6. Post-exploitation. Se evalúa el valor del acceso: qué datos alcanza, si hay escalada de privilegios o movimiento lateral, y cuánto tiempo pasaría inadvertido un atacante.
  7. Reporting. Se traduce todo a un lenguaje que el cliente pueda accionar: hallazgos priorizados, evidencia reproducible y remediación concreta.

PTES no es una receta rígida, sino una guía estructurada. Su valor está en ofrecer un lenguaje común y un nivel de detalle técnico que guía al pentester en cada etapa, y en modelar amenazas relevantes para el negocio del cliente en vez de disparar herramientas sin criterio.

Otros Estándares y Cuándo Elegirlos

Ningún marco es universal; elegir bien es parte de la metodología.

  • OSSTMM (Open Source Security Testing Methodology Manual) aporta un enfoque medible y científico. Define métricas como el RAV (Risk Assessment Value) para cuantificar la superficie de ataque, y separa controles operativos de vectores. Sirve cuando necesitas resultados numéricos, comparables y auditables más que una narrativa.
  • NIST SP 800-115 es la guía técnica del gobierno de EE. UU. para pruebas de seguridad. Es más liviana que PTES y muy útil como referencia oficial en entornos que exigen cumplimiento; estructura el trabajo en planificación, descubrimiento, ataque y reporte.
  • OWASP WSTG (Web Security Testing Guide) es el referente para aplicaciones web: ofrece checklists detallados por categoría para probar de forma sistemática y sin improvisar.
  • OWASP Top 10 lista las categorías de riesgo más críticas — inyección, autenticación rota, control de acceso defectuoso, configuraciones inseguras — y sirve como marco de comunicación de riesgo compartido con desarrolladores. Para APIs, el OWASP API Security Top 10 cubre riesgos específicos de interfaces modernas.

En la práctica se combinan: PTES para el flujo del engagement, WSTG para el detalle web, y OSSTMM o NIST cuando el cliente pide métricas o cumplimiento formal.

OWASP y el Testing de Aplicaciones Web

Cuando el objetivo es una aplicación web, la WSTG y el OWASP Top 10 guían la cobertura. La WSTG ofrece checklists detallados para probar cada categoría de riesgo de forma sistemática, de modo que no dependas de tu memoria ni de la suerte.

Herramientas como Burp Suite y OWASP ZAP son centrales en esta fase: actúan como proxy entre tu navegador y la aplicación, permitiéndote interceptar, analizar y manipular peticiones de forma controlada. Combinadas con la guía OWASP, te aseguran cubrir los vectores web más relevantes sin improvisar.

MITRE ATT&CK y la Cyber Kill Chain

Además de los marcos de proceso, el pentester moderno usa marcos de modelado de amenazas para pensar como el adversario.

MITRE ATT&CK es una base de conocimiento de comportamientos reales de atacantes, organizada en tácticas (el por qué — el objetivo, como Initial Access, Privilege Escalation, Lateral Movement, Exfiltration) y técnicas (el cómo — el método concreto, cada una con un identificador como T1078). Mapear tus hallazgos a técnicas ATT&CK le da al cliente un lenguaje estándar para entender el riesgo y para verificar si sus defensas detectan esa técnica.

La Cyber Kill Chain (de Lockheed Martin) modela un ataque como una secuencia de etapas — reconnaissance, weaponization, delivery, exploitation, installation, command & control, y actions on objectives. Es más lineal que ATT&CK y útil para comunicar en qué punto de la cadena una defensa podría cortar el ataque.

El pentester los usa en la fase de threat modeling: en vez de probar al azar, elige vectores que un adversario real usaría contra ese negocio, y luego, en el reporte, expresa cada hallazgo en términos de la táctica y técnica que habilita.

Mini-escenario: Aplicando la Metodología

Imagina un engagement autorizado, en scope, sobre una aplicación interna. Durante la enumeración descubres que un panel de administración acepta credenciales por defecto que nunca se cambiaron. En vez de anotar "login débil", aplicas la metodología:

  • Fase: el hallazgo aparece en vulnerability analysis y se valida (sin causar daño) en exploitation.
  • Mapeo ATT&CK: corresponde a Valid Accounts (T1078), bajo la táctica de Initial Access / Privilege Escalation.
  • Kill Chain: habilita la etapa de exploitation y, potencialmente, actions on objectives si esas credenciales dan acceso a datos sensibles.
  • Impacto de negocio: documentas qué alcanzaría un atacante con ese acceso, respetando el scope y sin exfiltrar datos reales.
  • Remediación: rotar credenciales, forzar cambio en primer login y habilitar MFA.

Ese mismo hallazgo, expresado con fase, técnica y kill chain, es mucho más accionable que una línea suelta en un checklist.

Estructura del Engagement y Documentación Continua

Una metodología sólida exige documentar mientras trabajas, no después. Cada comando ejecutado, cada hallazgo, cada captura de pantalla y cada decisión debe registrarse en tiempo real. Una carpeta ordenada desde el día cero hace que el reporte casi se escriba solo. Un esquema ilustrativo, no un ataque:

# Estructura base del engagement (solo organización, nada ofensivo)
mkdir -p engagement/{recon,scans,loot,report,notes}

# Registrar contexto y autorización junto a la evidencia
echo "Cliente: ACME | Scope: 10.0.0.0/24 | Autorizado: 2026-07-01" > engagement/notes/scope.txt

# Diario de actividad con marca de tiempo (trazabilidad)
echo "$(date -u +%FT%TZ) - inicio de enumeración de servicios" >> engagement/notes/activity.log

Herramientas como CherryTree, Obsidian o plataformas dedicadas de pentesting ayudan a organizar notas, evidencia y cronología. Etiquetar cada hallazgo con su host, servicio, severidad y prueba de concepto desde el inicio hace que el reporte casi se escriba solo. La disciplina de documentar es lo que separa a un pentester profesional de un aficionado talentoso.

Checklist de Cierre

Antes de dar por terminada una fase — o el engagement completo — verifica que la cobertura y la documentación estén al día:

  • [ ] Cada fase de PTES tiene notas, comandos y evidencia asociados.
  • [ ] Todo hallazgo está etiquetado con host, servicio, severidad y prueba de concepto.
  • [ ] Los hallazgos relevantes están mapeados a una táctica y técnica de ATT&CK.
  • [ ] Ninguna acción salió del scope ni violó las reglas de enfrentamiento.
  • [ ] Los hallazgos críticos se comunicaron según lo acordado en el pre-engagement.
  • [ ] La cronología (activity log) permite reproducir qué se hizo y cuándo.
  • [ ] El entregable incluye impacto de negocio y remediación concreta, no solo el hallazgo técnico.