13. Explotación controlada, prueba de concepto y manejo de evidencias

13.1 Introducción

La explotación controlada es una de las fases más delicadas de una prueba de penetración. En esta etapa se intenta demostrar que una vulnerabilidad puede producir impacto real, pero sin convertir la validación en un incidente.

El objetivo no es obtener todos los datos posibles, modificar sistemas o demostrar superioridad técnica. El objetivo es reunir evidencia suficiente para que la organización entienda el riesgo y pueda corregirlo.

En este tema veremos cuándo explotar, cómo diseñar una prueba de concepto, qué límites respetar, cómo recolectar evidencias y cómo documentar resultados sin aumentar la exposición.

13.2 Qué es explotación controlada

Explotación controlada es la validación técnica de una vulnerabilidad bajo condiciones acordadas, con medidas para limitar impacto operativo y exposición de datos.

Una explotación controlada debe cumplir estas condiciones:

• Está dentro del alcance autorizado.
• Tiene un objetivo técnico claro.
• Usa el método menos intrusivo suficiente.
• No afecta disponibilidad salvo autorización explícita.
• No accede a más datos de los necesarios.
• Genera evidencia útil para remediar.
• Incluye plan de limpieza si crea artefactos.

13.3 Cuándo explotar y cuándo no

No todo hallazgo necesita explotación. A veces basta con evidencia indirecta, configuración vulnerable o documentación oficial. Otras veces, una prueba de concepto limitada es necesaria para demostrar impacto real.

13.4 Prueba de concepto

Una prueba de concepto, o PoC, demuestra que una vulnerabilidad existe y tiene impacto. En pentesting profesional, una PoC debe ser clara, reproducible, limitada y segura.

Una buena PoC incluye:

• Descripción breve de la condición vulnerable.
• Activo afectado.
• Precondiciones necesarias.
• Pasos mínimos para reproducir.
• Evidencia del impacto.
• Límites aplicados para evitar daño.
• Recomendación de remediación.

13.5 Características de una PoC segura

13.6 Definir el objetivo de la explotación

Antes de explotar hay que saber exactamente qué se quiere demostrar. Si el objetivo no está claro, la prueba puede volverse innecesariamente invasiva.

• Demostrar lectura no autorizada.
• Demostrar modificación controlada.
• Demostrar ejecución de comando inocuo.
• Demostrar bypass de autenticación.
• Demostrar escalada de privilegio con cuenta de prueba.
• Demostrar acceso a función o recurso restringido.
• Demostrar posibilidad de movimiento lateral, si está autorizado.

13.7 Explotación en aplicaciones web

En aplicaciones web, la explotación controlada suele trabajar con peticiones HTTP, sesiones, roles y entradas de usuario. Es importante usar cuentas y datos de laboratorio siempre que sea posible.

Ejemplos de validación segura:

• Control de acceso: acceder con usuario de prueba a un recurso de otro usuario de prueba.
• Inyección: usar payloads que demuestren diferencia de respuesta sin extraer datos reales.
• XSS: ejecutar una alerta o marcador inocuo en entorno controlado.
• CSRF: demostrar acción sobre cuenta de laboratorio.
• Subida de archivos: cargar archivo benigno permitido y retirarlo después.
• SSRF: apuntar a un endpoint controlado por el equipo evaluador.

13.8 Explotación en servicios de red

En servicios de red, la explotación puede tener más riesgo operativo. Algunas vulnerabilidades provocan caídas, corrupción de memoria o estados inestables. En producción, conviene preferir pruebas no destructivas.

• Confirmar versión, configuración y exposición.
• Revisar si el módulo vulnerable está habilitado.
• Usar módulos auxiliares antes de exploits intrusivos.
• Probar en laboratorio si existe riesgo de crash.
• Evitar payloads persistentes o destructivos.
• Documentar cualquier conexión, archivo o proceso creado.

13.9 Explotación autenticada

Muchas vulnerabilidades requieren usuario válido. En esos casos, se deben usar credenciales autorizadas, preferentemente cuentas de laboratorio con roles claros.

Aspectos a documentar:

• Usuario o rol utilizado.
• Permisos esperados de ese rol.
• Acción realizada.
• Resultado obtenido.
• Por qué el resultado excede lo permitido.
• Evidencia mínima del impacto.

13.10 Límites sobre datos sensibles

La explotación puede revelar datos sensibles. El manejo responsable exige reducir al mínimo la exposición durante la prueba y en el reporte.

• No descargar bases completas.
• No capturar datos personales si un identificador parcial alcanza.
• No guardar credenciales en texto claro.
• Enmascarar tokens, correos, documentos y claves en capturas.
• Usar datos de prueba cuando sea posible.
• Comunicar de inmediato exposiciones críticas.
• Eliminar evidencias sensibles según lo acordado.

13.11 Manejo de evidencias

La evidencia es el respaldo del hallazgo. Debe ser suficiente para convencer, reproducir y remediar, pero debe recolectarse y almacenarse de forma segura.

13.12 Calidad de evidencia

Una evidencia útil debe ser clara, trazable y contextualizada. Una captura aislada sin explicación puede ser insuficiente; una salida extensa puede exponer información innecesaria.

• Indicar activo afectado.
• Registrar fecha o ventana de prueba.
• Incluir rol o usuario de prueba si aplica.
• Mostrar condición vulnerable y resultado.
• Separar datos reales de datos de laboratorio.
• Explicar por qué la evidencia demuestra impacto.
• Proteger información sensible.

13.13 Cadena de custodia básica

En la mayoría de pentests comerciales no se aplica una cadena de custodia forense completa, pero sí conviene mantener trazabilidad básica sobre evidencias sensibles.

Buenas prácticas:

• Guardar evidencias en repositorio controlado.
• Limitar acceso al equipo autorizado.
• Registrar quién recolectó la evidencia.
• No modificar archivos originales sin conservar referencia.
• Usar nombres claros y fechas.
• Proteger reportes y anexos con datos sensibles.
• Eliminar o devolver evidencias según el acuerdo.

13.14 Pruebas de escritura controlada

Algunos hallazgos requieren demostrar capacidad de escritura. Esto debe hacerse con mucho cuidado para no afectar integridad de datos.

• Usar un recurso de prueba acordado.
• Crear archivos con nombres identificables y contenido inocuo.
• No sobrescribir archivos existentes.
• No modificar registros reales.
• Capturar evidencia de creación y eliminación.
• Informar si no fue posible limpiar por falta de permisos.

13.15 Pruebas de ejecución de comandos

Si se valida ejecución remota de comandos, deben usarse comandos inocuos que no cambien el sistema. La evidencia debe demostrar contexto, usuario y alcance sin alterar operación.

13.16 Pruebas de control de acceso

Las fallas de control de acceso se validan comparando lo que diferentes usuarios pueden hacer. Este tipo de prueba debe usar cuentas de laboratorio y recursos no sensibles.

• Definir usuarios A y B con roles conocidos.
• Identificar un recurso de prueba perteneciente a cada usuario.
• Intentar acceso cruzado controlado.
• Registrar petición, respuesta y rol usado.
• No acceder a datos reales de otros usuarios.
• Demostrar impacto por permiso indebido, no por volumen de datos.

13.17 Manejo de sesiones obtenidas

Si la explotación genera una sesión, shell o acceso interactivo, debe manejarse con límites estrictos. La sesión no es una invitación a explorar sin rumbo.

• Registrar hora de inicio y cierre.
• Confirmar identidad y privilegios con comandos inocuos.
• No persistir acceso salvo autorización explícita.
• No moverse lateralmente si no está dentro del alcance.
• No extraer datos sensibles innecesarios.
• Cerrar sesión al completar evidencia.
• Documentar artefactos creados.

13.18 Limpieza posterior

La limpieza es parte del proceso, no una tarea opcional. Si durante la explotación se crearon archivos, usuarios, tokens, sesiones o cambios, deben revertirse según el plan acordado.

• Eliminar archivos de prueba.
• Cerrar sesiones abiertas.
• Revocar tokens o credenciales temporales.
• Retirar reglas, tareas o artefactos creados.
• Informar elementos que no pudieron limpiarse.
• No borrar logs defensivos salvo autorización explícita.

13.19 Comunicación de hallazgos críticos

Si una explotación controlada confirma un riesgo crítico, debe comunicarse antes del reporte final. Esto permite contención rápida.

El aviso debe incluir:

• Activo afectado.
• Condición vulnerable.
• Impacto demostrado.
• Evidencia mínima.
• Recomendación inmediata.
• Riesgo de continuar probando.
• Artefactos creados, si los hubo.

13.20 Severidad después de explotar

La explotación controlada puede cambiar la severidad de un hallazgo. Una vulnerabilidad teórica puede bajar si no es explotable en contexto, o subir si permite acceso real a datos, privilegios o sistemas críticos.

13.21 Redacción de la PoC en el reporte

La PoC debe explicar cómo se validó el hallazgo sin convertir el reporte en un manual de abuso. Debe ser suficiente para que el equipo responsable reproduzca y corrija.

• Incluir pasos claros y acotados.
• Indicar usuario o rol de prueba.
• Mostrar petición o acción relevante.
• Truncar secretos y datos sensibles.
• Explicar resultado observado.
• Relacionar resultado con impacto.
• Agregar recomendación concreta.

13.22 Errores frecuentes

• Explotar sin objetivo técnico claro.
• Continuar después de haber demostrado impacto suficiente.
• Usar datos reales cuando existían datos de prueba.
• Ejecutar payloads persistentes sin autorización.
• Descargar información masiva como evidencia.
• No documentar artefactos creados.
• No limpiar archivos o sesiones de prueba.
• Esperar al reporte final para comunicar un riesgo crítico.

13.23 Flujo práctico de explotación controlada

Un flujo responsable puede ser:

1. Confirmar alcance y autorización para la técnica.
2. Definir el impacto que se busca demostrar.
3. Elegir método mínimo de validación.
4. Preparar datos, usuarios o recursos de prueba.
5. Ejecutar la PoC con control de intensidad.
6. Recolectar evidencia suficiente y mínima.
7. Detenerse cuando el riesgo esté demostrado.
8. Limpiar artefactos y cerrar sesiones.
9. Comunicar hallazgos críticos si corresponde.
10. Documentar pasos, impacto, evidencia y remediación.

13.24 Qué debes recordar de este tema

• Explotar en pentesting significa demostrar impacto de forma controlada.
• La PoC debe ser mínima, reproducible, limitada y segura.
• No todas las vulnerabilidades requieren explotación directa.
• La evidencia debe ser suficiente para remediar, pero mínima para no exponer datos.
• Las sesiones, archivos y cambios generados deben limpiarse o documentarse.
• Los hallazgos críticos deben comunicarse antes del cierre formal.

13.25 Conclusión

La explotación controlada es una herramienta de validación, no un fin en sí misma. Su calidad se mide por la claridad de la evidencia, el respeto del alcance y la utilidad del resultado para reducir riesgo.

En el próximo tema entraremos en vulnerabilidades web, OWASP Top 10 y metodología de pruebas, donde aplicaremos estos principios sobre aplicaciones, APIs y flujos de usuario.