Explotación
La explotación comprueba si una condición vulnerable puede convertirse en una capacidad útil: leer, escribir, autenticarse, ejecutar código, alterar una decisión o cruzar un límite de confianza. El resultado importa tanto como el mecanismo. Dos exploits que terminan en una shell pueden necesitar prerrequisitos distintos, dejar artefactos diferentes y ejecutar bajo identidades con capacidades muy desiguales.
Las condiciones operativas del engagement ya se fijan en Alcance y reglas de enfrentamiento. Esta página se centra en preparar, ejecutar e interpretar la técnica.
De hipótesis a ruta de explotación
Sección titulada «De hipótesis a ruta de explotación»Antes de elegir una PoC, concreta la cadena que se espera observar:
entrada controlada → componente vulnerable → primitive obtenida → contexto de ejecución → capacidadUna inyección de comandos puede proporcionar una primitive de ejecución, pero todavía importa qué proceso interpreta la entrada, bajo qué usuario, dentro de qué contenedor y con qué salida de red. Una deserialización puede ejecutar antes de la autenticación o depender de una sesión privilegiada. Una file write solo conduce a ejecución si existe una ruta que consuma el archivo.
Para cada ruta registra:
- versión, configuración y estado que sostienen la hipótesis
- punto de entrada y formato exacto de los datos
- primitive esperada, como read, write, SSRF, authentication bypass o code execution
- arquitectura, usuario, integridad, namespace y restricciones del proceso
- conexión de retorno, listener o canal necesario
- archivos, procesos, cuentas, servicios y logs que puede crear o modificar
- señales que distinguen éxito, fallo parcial, crash y bloqueo defensivo
CVSS ayuda a describir una vulnerabilidad publicada, pero no sustituye este análisis del target.
Adaptar una PoC
Sección titulada «Adaptar una PoC»Una PoC pública es código no confiable y una implementación para un escenario concreto. Revísala antes de usarla:
- localiza el trigger y separa la lógica imprescindible del código auxiliar
- identifica payloads, callbacks, downloads, rutas, credenciales y comandos hardcodeados
- comprueba arquitectura, endianness, versiones, offsets y dependencias
- determina qué estado deja si falla a mitad de ejecución
- añade output y timeouts que permitan distinguir cada etapa
- prueba el mecanismo en una réplica cuando el failure mode pueda afectar al servicio
La réplica debe reproducir las condiciones que importan para el exploit, no parecerse superficialmente al target. Un mismo número de versión con distinta build, mitigaciones, módulos o configuración puede cambiar por completo el resultado.
Payload y canal de acceso
Sección titulada «Payload y canal de acceso»El exploit obtiene una primitive. El payload decide cómo aprovecharla. Puede ejecutar un comando, escribir un archivo, crear una sesión, cargar código en memoria o conectar con un listener. Esa elección cambia:
- compatibilidad con el sistema y las herramientas disponibles
- dirección de la conexión y reachability necesaria
- estabilidad e interactividad de la sesión
- indicadores de red, proceso, memoria y filesystem
- dependencia del proceso vulnerable y supervivencia ante un reinicio
Una reverse shell necesita egress desde el target hacia el listener. Una bind shell necesita ingress hacia el puerto abierto. Una web shell reutiliza el canal HTTP del servidor, pero depende del runtime, el webroot y los permisos del proceso. La rama técnica de acceso desarrollará estas variantes con sus comandos y mecanismos.
Interpretar el resultado
Sección titulada «Interpretar el resultado»Un exploit puede fallar antes del trigger, alcanzar la primitive sin ejecutar el payload, ejecutar bajo un contexto inesperado o abrir una sesión que se pierde de inmediato. Registra por separado cada etapa. La ausencia de una shell no demuestra que la vulnerabilidad no exista.
También conserva los efectos laterales: reinicios, conexiones, child processes, archivos temporales, cambios de configuración y eventos del endpoint. Estos artefactos permiten reconstruir el intento, limpiar el entorno y entender qué controles lo observaron.
Cuando se obtiene una posición nueva, anota host, identidad, integridad, hora, vía de acceso y dependencias de la sesión. Esa información es la entrada de post-explotación. Si el resultado contradice la hipótesis, vuelve al análisis con el punto exacto de fallo en lugar de rotar payloads sin cambiar el modelo.
La prueba de concepto convierte la ruta validada en una reproducción comprensible. No necesita ocultar prerrequisitos ni automatizar pasos que ayudan a explicar la causa.