Arrancamos el Módulo 4 justo donde cerramos el Módulo 3: con la lista priorizada de vulnerabilidades candidatas de TechNova en la mano. En 03-03 pasamos de "no sabemos nada" a "estas ocho cosas parecen débiles, ordenadas por prioridad". La candidata número uno es una probable inyección SQL en tienda.technova.lab/producto.php?id=; le siguen la consola de debug de Werkzeug en el puerto 54321, MySQL 5.5 expuesto, PHP en fin de vida, una sesión nula de SMB y varios ficheros filtrados. Hasta ahora no hemos tocado nada: solo hemos mirado. Explotar es cruzar esa línea con permiso, cabeza y control.

Explotar es aprovechar una vulnerabilidad para conseguir algo que el sistema no debería permitir: leer un dato, ejecutar un comando, obtener una sesión. En un pentest profesional, la explotación no es un acto de agresión, sino la validación autorizada del riesgo: demostramos, con evidencia y de forma controlada, que la vulnerabilidad candidata es real y qué conseguiría un atacante, para que TechNova pueda arreglarla. Toda esta lección —y todo el módulo— ocurre dentro del laboratorio legal de TechNova, con contrato, alcance (scope) y reglas de enfrentamiento (RoE) firmados. Objetivos: solo los autorizados. Impacto: minimizado y acordado. Cada acción: documentada.

1. De vulnerabilidad candidata a acceso validado
2. Vocabulario esencial: exploit, payload, shell
3. Shells: directa, reversa y bind
4. Del CVE al exploit: fiabilidad y riesgo
5. Exploits públicos vs. a medida
6. Verificar un exploit antes de lanzarlo
7. El ciclo controlado de explotación
8. Marco de control de impacto
9. Errores comunes y consejos
10. Ejercicios
11. Conclusión

En el Módulo 3 etiquetábamos cada hallazgo con un nivel de confianza: confirmada, probable, a validar. Explotar es el paso que convierte una candidata "probable" en un hecho demostrado.

La diferencia con un atacante real es el para qué y el cómo: el atacante quiere causar daño y persistir; el pentester quiere probar el riesgo con el mínimo impacto y documentarlo. Por eso una prueba de concepto (PoC) bien hecha no vuelca la base de datos entera ni borra nada: extrae un único valor de prueba —la versión de MySQL, un id, el nombre de un usuario ficticio— que demuestra el acceso sin abusar de él.

Tres términos que se confunden constantemente y conviene separar bien:

Un mismo exploit (la ganzúa) puede llevar payloads distintos: uno que solo muestra un id (prueba inofensiva), otro que abre una shell, otro que —en manos de un atacante— cifraría los datos. El pentester elige siempre el payload de menor impacto que demuestre el punto. Esa elección es lo que hace ético el proceso.

Cuando un exploit consigue ejecución de comandos, el objetivo suele ser una shell: una consola remota en la máquina víctima. Hay tres modelos:

La reverse shell es la más común porque los cortafuegos suelen bloquear conexiones entrantes pero permiten las salientes. Ejemplo conceptual de escucha (el pentester) y de conexión de vuelta (payload en la víctima):

Detallado: nc -lvnp 4444 deja al pentester escuchando en el puerto 4444. El payload de la víctima redirige una shell interactiva (bash -i) a través de una conexión TCP hacia 10.10.10.5:4444. Resultado: el pentester recibe una consola. En el laboratorio esto se hace para demostrar ejecución, no para instalar nada persistente (eso sería Módulo 5).

No todos los CVE tienen exploit, y no todo exploit es fiable. Antes de lanzar, se evalúan dos ejes:

• Fiabilidad: ¿funciona de forma consistente o falla la mitad de las veces? Un exploit poco fiable puede dejar el servicio a medias.
• Riesgo/impacto: ¿qué pasa si falla? Los exploits de corrupción de memoria (buffer overflow) pueden tumbar el servicio si la versión no coincide exactamente. Un exploit de inyección SQL, en cambio, suele ser inofensivo si se controla la carga.

Metasploit clasifica sus módulos con un campo Rank que resume esto:

Regla práctica: a igualdad de resultado, elige el exploit más fiable y de menor riesgo. Una SQLi que lee un dato es preferible a un desbordamiento de pila que podría reiniciar la tienda de TechNova (y provocar una denegación de servicio no acordada).

Hay dos grandes fuentes de exploits:

• Públicos: exploit-db, Metasploit, GitHub, PoC de investigadores. Rápidos, pero hay que auditarlos antes de usarlos.
• A medida: los escribes tú para una vulnerabilidad concreta (típico en SQLi, XSS o lógica de negocio, donde cada aplicación es distinta).

Para buscar exploits públicos usamos searchsploit (la copia local de exploit-db en Kali, ya vista en 03-03):

searchsploit -m copia el exploit a tu carpeta (mirror), no lo ejecuta. Ese es el punto: primero se lee, luego —si procede— se usa. La presentación a fondo de Metasploit y las demás herramientas llega en el Módulo 7; aquí las usamos de pasada.

Nunca ejecutes un exploit descargado sin leerlo. Un exploit público puede:

• Estar diseñado para una versión distinta y fallar o tumbar el servicio.
• Contener un payload destructivo o incluso una puerta trasera contra ti (exploits "troyanizados" que roban al que los usa).
• Apuntar por defecto a una IP o dominio que no es el tuyo.

Checklist mínimo de verificación:

1. Léelo entero. Entiende qué vulnerabilidad ataca y qué payload trae por defecto.
2. Confirma la versión objetivo. Debe coincidir con lo enumerado en 03-02.
3. Identifica el impacto. ¿Solo prueba, o modifica/borra algo? Ajústalo a una PoC de bajo impacto.
4. Revisa direcciones y credenciales incrustadas. Que apunte a 10.10.10.x del laboratorio, no a un tercero.
5. Pruébalo primero en una réplica si el activo es delicado.

Esta disciplina no es burocracia: es lo que separa una validación controlada de un incidente autoinfligido en el sistema del cliente.

Toda explotación en este curso sigue el mismo ciclo, pensado para maximizar evidencia y minimizar daño:

1. Verificar alcance: ¿está el activo en el scope? Si no, no se toca. Punto.
2. Verificar el exploit: el checklist del apartado 6.
3. PoC de bajo impacto: ejecutar la mínima prueba que demuestre el fallo (leer una versión, un id, un valor centinela).
4. Capturar evidencia: comando exacto, salida, marca de tiempo, captura de pantalla. Es la materia prima del informe (Módulo 6).
5. Detenerse y documentar: la explotación termina cuando se obtiene acceso/ejecución. Lo que se hace después (escalar, persistir, pivotar) es Módulo 5.

Este es el corazón ético del módulo. Antes de cada acción, tres preguntas:

• ¿Está autorizado? El activo dentro del scope y la técnica permitida por las RoE.
• ¿Es reversible / de bajo impacto? Preferir siempre la prueba que no altera datos ni disponibilidad. Nada de borrar tablas, cifrar ficheros ni lanzar denegaciones de servicio no acordadas.
• ¿Queda documentado? Cada comando y su resultado, con hora, para poder reconstruir y para que el cliente pueda auditarlo.

Si una prueba solo puede demostrarse causando daño real, se documenta el riesgo y se acuerda con el cliente antes de proceder; no se improvisa.

• Ejecutar exploits sin leerlos. Es la vía más rápida a tumbar el servicio del cliente o a infectarte tú. Verifica siempre (apartado 6).
• Salirse del alcance por inercia. Encontrar una puerta abierta a un sistema no autorizado no da derecho a entrar. Fuera del scope, se reporta, no se explota.
• Elegir el payload más potente "por si acaso". El objetivo es demostrar, no dominar. El payload de menor impacto que prueba el punto es el correcto.
• No capturar evidencia. Una explotación sin comando, salida y hora registrados es un hallazgo que no podrás defender en el informe.
• Confundir explotar con post-explotar. Aquí termina en el foothold (acceso obtenido). Escalar y persistir es Módulo 5; adelantarlo rompe el hilo y el control.
• Lanzar módulos DoS o de fuerza bruta sin acuerdo. Pueden causar caídas o bloqueos de cuentas reales. Requieren autorización explícita en las RoE.
• Consejo: trata cada exploit como código no confiable y cada activo como si estuviera en producción (a menudo lo está). La prudencia es una competencia profesional, no timidez.

Ejercicio 1. Tienes la candidata #1 del Módulo 3 (probable SQLi en producto.php?id=). Diseña una PoC de bajo impacto que demuestre que la inyección existe sin extraer datos sensibles ni alterar la base de datos. Indica qué "valor de prueba" pedirías y por qué es inofensivo.

Ejercicio 2. Encuentras en exploit-db un script en Python para la consola de debug de Werkzeug (candidata #2). Antes de lanzarlo contra dev:54321, enumera los pasos de verificación que aplicarías y explica qué riesgo concreto mitiga cada uno.

Ejercicio 3. Durante la auditoría descubres que un servidor fuera del alcance (10.20.0.5, otra red) es trivialmente explotable con un exploit público. ¿Qué haces? Justifica tu decisión desde las RoE y la ética profesional.

Solución 1. PoC de bajo impacto para la SQLi: inyectar una condición que devuelva un valor del propio motor sin tocar datos de clientes, por ejemplo forzar que la consulta muestre @@version o el resultado de 1+1, o comprobar una inyección booleana (id=1 AND 1=1 frente a id=1 AND 1=2 y observar la diferencia en la respuesta). El "valor de prueba" sería la versión de MySQL o un 2 como resultado de 1+1: demuestra que la entrada se interpreta como SQL (la vulnerabilidad es real) sin leer tablas de usuarios ni modificar nada. Es inofensivo porque no extrae datos personales, no escribe ni borra, y es reversible (solo lee metadatos del motor). Toda la salida se captura como evidencia.

Solución 2. Verificación antes de lanzar: (1) leer el script entero para entender qué hace y qué payload trae —mitiga ejecutar código destructivo o troyanizado—; (2) confirmar que la versión de Werkzeug del script coincide con la enumerada en dev:54321 —mitiga fallos o crash por versión equivocada—; (3) revisar IPs/URLs incrustadas para que apunte a 10.10.10.x y no a un tercero —mitiga atacar fuera de alcance por descuido—; (4) identificar el payload por defecto y sustituirlo por uno de bajo impacto (ejecutar id en lugar de abrir una shell persistente) —mitiga exceso de impacto—; (5) confirmar que el activo está en el scope y en la ventana acordada. Solo entonces se ejecuta, capturando comando y salida.

Solución 3. No se explota. 10.20.0.5 está fuera del alcance: tocarlo sería acceso no autorizado, ilegal y una violación de las RoE, por trivial que sea. Lo correcto es documentar el hallazgo (existe un sistema explotable y cómo lo detectaste) y comunicarlo al contacto del cliente, sugiriendo ampliar el alcance si quieren que se evalúe. La facilidad técnica nunca es autorización; el permiso lo da el contrato, no la vulnerabilidad.

Ya tenemos el marco. Explotar, en un pentest profesional, es convertir una vulnerabilidad candidata en riesgo demostrado, de forma autorizada, con el mínimo impacto y dejando evidencia de cada paso. Hemos separado los conceptos que todo el módulo va a usar —vulnerabilidad, exploit, payload, shell (reversa/bind)—, hemos visto cómo se va del CVE al exploit valorando fiabilidad y riesgo, y hemos fijado la disciplina innegociable: leer y verificar antes de lanzar, elegir el payload de menor impacto, capturar evidencia y detenerse en el acceso obtenido.

Con el ciclo controlado y el marco de control de impacto interiorizados, ya podemos coger la lista priorizada de TechNova y empezar por arriba. La siguiente lección, 04-02 Explotación de Vulnerabilidades Web, ataca la candidata número uno —la inyección SQL de la tienda— y el resto de clases OWASP que viven en tienda.technova.lab: cada una con su mecanismo, su PoC de bajo impacto y, siempre, su remediación. Bajamos del marco a la práctica.