6. Fases de una prueba de penetración y gestión del alcance

6.1 Introducción

Un pentest no empieza cuando se ejecuta una herramienta ni termina cuando se encuentra una vulnerabilidad. Empieza con una necesidad de evaluación, continúa con definición de alcance, planificación, ejecución controlada, reporte, remediación y retesting.

El flujo de trabajo importa porque reduce riesgo operativo. Permite saber qué se puede probar, cuándo hacerlo, cómo comunicar problemas, qué evidencias conservar y cómo transformar hallazgos técnicos en decisiones de seguridad.

En este tema veremos las fases principales de una prueba de penetración y cómo gestionar el alcance para evitar ambigüedades, pruebas fuera de permiso o resultados difíciles de interpretar.

6.2 Visión general del ciclo de pentesting

Aunque cada metodología use nombres diferentes, la mayoría de pruebas profesionales siguen un ciclo similar. Las fases no siempre son lineales; a veces un hallazgo en enumeración obliga a volver al reconocimiento o a revisar el alcance.

1. Solicitud y definición de necesidad.
2. Pre-engagement y autorización.
3. Gestión del alcance y reglas de compromiso.
4. Planificación técnica.
5. Reconocimiento.
6. Enumeración.
7. Análisis y priorización de vulnerabilidades.
8. Validación y explotación controlada.
9. Post-explotación dentro del alcance.
10. Reporte y presentación de resultados.
11. Remediación y retesting.

6.3 Fase 1: solicitud y necesidad de negocio

Antes de definir técnicas, hay que entender por qué se solicita la prueba. No es lo mismo evaluar una aplicación antes de salir a producción que medir exposición externa después de un incidente o validar controles para un requisito de cumplimiento.

Preguntas útiles en esta fase:

• ¿Qué activo o proceso preocupa a la organización?
• ¿Qué decisión se tomará con los resultados?
• ¿Hay fechas críticas, auditorías o lanzamientos próximos?
• ¿Se busca una evaluación técnica, una simulación realista o validación de cumplimiento?
• ¿Qué nivel de interrupción es aceptable?
• ¿Qué riesgos son más importantes: datos, disponibilidad, fraude, privilegios o exposición pública?

6.4 Fase 2: pre-engagement

El pre-engagement es la etapa previa a la ejecución. Aquí se acuerdan condiciones, responsabilidades, límites, contactos, manejo de datos y criterios de éxito. Es una fase crítica porque define el marco de trabajo.

6.5 Fase 3: gestión del alcance

El alcance describe con precisión qué se puede evaluar. Debe estar escrito en términos técnicos y comprensibles: dominios, direcciones IP, aplicaciones, APIs, redes, credenciales de prueba, entornos, servicios cloud o procesos incluidos.

Un alcance bien definido evita errores como probar un subdominio perteneciente a un tercero, escanear una red completa cuando solo se autorizó un host o acceder a datos reales cuando se acordó usar usuarios de laboratorio.

• Incluido: activos permitidos para evaluación.
• Excluido: activos o técnicas prohibidas.
• Condicionado: actividades que requieren autorización adicional.
• Fuera de alcance por terceros: servicios usados por el cliente pero no controlados por él.

6.6 Fase 4: reglas de compromiso

Las reglas de compromiso convierten el alcance en instrucciones operativas. Indican cómo se ejecutará la prueba, qué intensidad se permite y cómo actuar ante eventos no previstos.

• Fechas y horarios de ejecución.
• Origen de las pruebas, como IPs del equipo evaluador.
• Restricciones de carga, fuerza bruta o pruebas destructivas.
• Uso de credenciales proporcionadas.
• Tratamiento de datos sensibles.
• Canales para comunicar hallazgos críticos.
• Criterios para pausar o detener la prueba.

6.7 Fase 5: planificación técnica

La planificación técnica traduce objetivos y alcance en un plan de trabajo. Define prioridades, herramientas, secuencia de pruebas, responsables, ventanas y entregables.

Una planificación razonable debería considerar:

• Tipo de prueba: black box, gray box o white box.
• Activos de mayor criticidad.
• Pruebas que requieren coordinación previa.
• Credenciales, usuarios y roles disponibles.
• Herramientas autorizadas y niveles de intensidad.
• Formato de evidencias y reporte.
• Dependencias con equipos de infraestructura, desarrollo o seguridad.

6.8 Fase 6: reconocimiento

El reconocimiento recopila información sobre el objetivo. Puede ser pasivo, usando fuentes públicas sin interactuar directamente con el sistema, o activo, interactuando con activos autorizados.

El reconocimiento permite entender superficie de ataque, tecnologías, dominios, rangos, proveedores, certificados, filtraciones, servicios expuestos y posibles puntos de entrada.

6.9 Fase 7: enumeración

La enumeración profundiza sobre lo descubierto. Si el reconocimiento identifica que existe un servicio, la enumeración intenta comprender qué versión usa, cómo responde, qué recursos expone y qué información entrega.

• Enumerar usuarios, grupos o recursos compartidos cuando esté autorizado.
• Identificar versiones de servicios y tecnologías.
• Detectar rutas web, endpoints de API y paneles administrativos.
• Probar respuestas con y sin autenticación.
• Revisar cabeceras, banners, certificados y mensajes de error.
• Documentar todo hallazgo con comandos, capturas o respuestas relevantes.

Una explotación mal preparada suele ser señal de una enumeración pobre. Cuanto mejor se enumera, más precisa y menos invasiva puede ser la validación.

6.10 Fase 8: análisis de vulnerabilidades

En esta fase se relaciona la información obtenida con posibles debilidades. Puede incluir herramientas automáticas, revisión manual, consulta de documentación, análisis de configuración y verificación de versiones.

El objetivo no es aceptar todo lo que diga un escáner, sino separar ruido de hallazgos relevantes.

• Confirmar si la versión detectada es real.
• Revisar si existen parches o mitigaciones aplicadas.
• Evaluar exposición del servicio vulnerable.
• Determinar si se requieren credenciales o condiciones especiales.
• Analizar impacto en el contexto del negocio.
• Decidir si corresponde validación explotable o basta con evidencia de configuración.

6.11 Fase 9: validación y explotación controlada

La explotación controlada busca demostrar impacto de forma segura. No siempre es necesaria ni siempre está permitida. Cuando se realiza, debe usar el menor nivel de intrusión suficiente para probar el hallazgo.

6.12 Fase 10: post-explotación controlada

La post-explotación responde qué significa el acceso obtenido. Puede incluir revisión de privilegios, alcance del usuario comprometido, rutas hacia otros sistemas, datos accesibles y controles que limitaron o permitieron el avance.

Debe mantenerse dentro del alcance. Tener acceso a un sistema no autoriza automáticamente a probar todo lo que ese sistema puede alcanzar.

• Identificar usuario, privilegios y contexto.
• Evaluar acceso a datos o recursos de prueba.
• Revisar si existen credenciales o secretos expuestos.
• Analizar posibilidades de movimiento lateral si está autorizado.
• Registrar evidencias mínimas y no destructivas.
• Limpiar artefactos creados durante la prueba.

6.13 Fase 11: documentación continua

La documentación no debe dejarse para el final. Durante la prueba se generan datos que luego son difíciles de reconstruir: comandos, horarios, respuestas, capturas, hipótesis descartadas y decisiones de alcance.

Una buena documentación incluye:

• Fecha y hora aproximada de acciones relevantes.
• Activo probado.
• Comando, petición o procedimiento usado.
• Resultado observado.
• Evidencia capturada.
• Impacto estimado.
• Notas sobre limitaciones, falsos positivos o restricciones.

6.14 Fase 12: comunicación de hallazgos críticos

Algunos hallazgos no deben esperar al reporte final. Si se detecta una exposición activa, una credencial válida, un acceso administrativo indebido o una vulnerabilidad explotable de alto impacto, debe comunicarse por el canal acordado.

La comunicación temprana permite reducir riesgo mientras la prueba continúa. El mensaje debe ser claro y accionable, sin exagerar ni ocultar incertidumbre.

• Qué se encontró.
• Qué activo afecta.
• Qué impacto podría tener.
• Qué evidencia mínima lo respalda.
• Qué acción inmediata se recomienda.
• Si la prueba debe pausarse, limitarse o continuar.

6.15 Fase 13: reporte técnico y ejecutivo

El reporte es el entregable principal del pentest. Debe servir tanto a equipos técnicos como a responsables de decisión. Un reporte profesional no se limita a copiar salidas de herramientas; explica riesgo, impacto, evidencia y remediación.

6.16 Fase 14: presentación de resultados

La presentación permite alinear interpretación, prioridades y próximos pasos. No siempre alcanza con enviar el reporte; los hallazgos importantes suelen requerir explicación, contexto y discusión con equipos técnicos y de negocio.

• Explicar el riesgo general sin tecnicismos innecesarios.
• Separar hallazgos críticos de mejoras de bajo impacto.
• Mostrar rutas de ataque cuando ayuden a entender impacto.
• Aclarar limitaciones del alcance.
• Responder dudas técnicas sobre evidencia y remediación.
• Acordar prioridades y responsables de corrección.

6.17 Fase 15: remediación

La remediación corresponde al equipo responsable del sistema, pero el reporte debe facilitarla. Una recomendación útil indica causa raíz, acción concreta, prioridad y validación esperada.

Las remediaciones pueden incluir:

• Aplicar parches o actualizar versiones.
• Corregir controles de acceso.
• Eliminar exposición innecesaria.
• Rotar credenciales o secretos comprometidos.
• Reconfigurar servicios, permisos o cabeceras.
• Agregar monitoreo, alertas o controles compensatorios.
• Modificar procesos de desarrollo o despliegue.

6.18 Fase 16: retesting

El retesting verifica si las correcciones aplicadas resolvieron los hallazgos. No debe confundirse con un nuevo pentest completo, salvo que el alcance así lo indique.

Un retesting efectivo revisa:

• Si el hallazgo original ya no se reproduce.
• Si la corrección no introdujo una falla nueva evidente.
• Si el control aplicado cubre todos los casos afectados.
• Si quedan riesgos residuales.
• Si se requieren acciones adicionales.

6.19 Control de cambios durante el pentest

Durante una prueba pueden aparecer cambios en el entorno: despliegues, reinicios, parches, nuevos activos, caídas o modificaciones de configuración. Estos cambios afectan resultados y deben documentarse.

• Registrar cambios comunicados por el cliente.
• Indicar si un hallazgo dejó de reproducirse por modificación durante la prueba.
• Pedir aprobación antes de evaluar activos agregados.
• No asumir que un nuevo subdominio o IP queda automáticamente dentro del alcance.
• Diferenciar fallas propias de la prueba de fallas causadas por cambios externos.

6.20 Gestión de alcance dinámico

A veces el alcance necesita cambiar: aparece un activo crítico relacionado, una API nueva, un entorno duplicado o una integración externa. El alcance puede ampliarse, pero no de palabra ni de forma improvisada.

Para gestionar cambios de alcance:

1. Documentar qué activo o técnica se quiere agregar.
2. Explicar por qué es relevante para la prueba.
3. Identificar riesgos operativos o legales.
4. Obtener aprobación explícita del responsable autorizado.
5. Actualizar reglas de compromiso si corresponde.
6. Registrar el cambio en el reporte final.

6.21 Criterios para pausar o detener una prueba

Una prueba debe poder pausarse si aparece riesgo operativo o legal. Detenerse a tiempo es una señal de profesionalismo, no de debilidad técnica.

• Degradación inesperada de disponibilidad.
• Acceso accidental a datos sensibles fuera de lo previsto.
• Detección de actividad maliciosa ajena durante la prueba.
• Ambigüedad sobre si un activo está autorizado.
• Herramienta comportándose de forma no esperada.
• Solicitud del cliente o del equipo operativo.
• Necesidad de aprobación adicional para continuar.

6.22 Matriz simple de alcance

Una matriz de alcance ayuda a visualizar qué está permitido y bajo qué condiciones.

6.23 Errores frecuentes

• Iniciar pruebas activas sin alcance escrito.
• No diferenciar entre activos incluidos, excluidos y condicionados.
• Ejecutar explotación sin validar impacto operativo.
• Guardar la documentación para el final y perder evidencia.
• Comunicar hallazgos críticos demasiado tarde.
• Confundir retesting con un nuevo pentest completo.
• Ampliar el alcance informalmente sin autorización documentada.
• No registrar limitaciones que afectan la cobertura de la prueba.

6.24 Qué debes recordar de este tema

• Un pentest profesional es un ciclo completo, no una secuencia de herramientas.
• El alcance define qué puede evaluarse y protege a todas las partes.
• Las reglas de compromiso indican cómo ejecutar la prueba de forma controlada.
• Reconocimiento, enumeración y análisis preparan la validación técnica.
• La explotación debe ser controlada, mínima y proporcional al objetivo.
• El reporte debe convertir hallazgos técnicos en decisiones de remediación.
• El retesting confirma si el riesgo fue realmente reducido.

6.25 Conclusión

Las fases de una prueba de penetración ordenan el trabajo y reducen improvisación. La gestión del alcance, por su parte, establece límites legales, técnicos y operativos. Juntas permiten ejecutar pruebas útiles sin perder control sobre el riesgo.

En el próximo tema entraremos en OSINT y reconocimiento pasivo, la primera etapa de recopilación de información donde se busca entender al objetivo sin interactuar directamente con sus sistemas.