Metodología y ética del pentesting
Antes de tocar una sola herramienta, un pentester profesional necesita dos cosas que no se aprenden con un exploit: un marco de trabajo ordenado y un límite ético y legal claro. Este módulo sienta esa base; el resto del curso da por hecho que la conoces.
- Explicar qué es un test de intrusión y en qué se diferencia de otras pruebas de seguridad.
- Conocer las fases habituales de una metodología de pentesting.
- Entender qué autoriza legalmente a realizar un ataque simulado, y qué no.
- Distinguir hacking ético, bug bounty y actividad delictiva.
- Aplicar un código de conducta profesional a lo largo de todo el curso.
1. ¿Qué es un test de intrusión?
Un test de intrusión (pentest) es un ataque simulado y autorizado contra un sistema, con el objetivo de encontrar vulnerabilidades explotables antes de que lo haga alguien sin autorización. No es lo mismo que:
| Actividad | Qué hace | Cómo se diferencia del pentest |
|---|---|---|
| Escaneo de vulnerabilidades | Detecta fallos conocidos de forma automática. | No explota nada; el pentest sí confirma el impacto real. |
| Auditoría de seguridad | Revisa configuración, políticas y cumplimiento normativo. | Es más amplia y no siempre incluye ataque activo. |
| Red team | Simula un adversario avanzado, con sigilo y sin avisar a todo el mundo. | Objetivo distinto: medir detección y respuesta, no encontrar todos los fallos. |
| Bug bounty | Recompensa a quien encuentra fallos, sin alcance ni fecha cerrados. | El alcance lo define un programa público, no un contrato con fechas fijas. |
2. Fases de una metodología de pentesting
Distintos marcos (PTES, OSSTMM, la metodología de OWASP) usan nombres algo distintos, pero comparten la misma columna vertebral:
- Acuerdo previo y alcance — qué se prueba, qué no, con qué autorización, en qué ventana de tiempo, con qué límites.
- Recopilación de información — reconocimiento pasivo y activo del objetivo (módulo 3).
- Modelado de amenazas y escaneo — identificar qué merece la pena atacar y con qué prioridad (módulo 4).
- Análisis de vulnerabilidades — confirmar qué fallos son explotables de verdad, no solo teóricos.
- Explotación — demostrar el impacto real, de forma controlada (módulos 5 a 20).
- Post-explotación — hasta dónde se podría llegar desde ahí: más datos, más máquinas, más privilegios.
- Informe — el entregable que de verdad importa al cliente: qué se encontró, qué riesgo supone y cómo se arregla.
3. Qué autoriza un pentest (y qué no)
Ninguna técnica de este curso es legal ni ética fuera de estos supuestos:
- Autorización explícita y por escrito del propietario del sistema, antes de empezar. Un correo vale; un "me lo dijeron por teléfono" no.
- Alcance definido: qué activos, qué rangos de IP, qué técnicas están permitidas y cuáles expresamente prohibidas (por ejemplo, ataques de denegación de servicio).
- Ventana de tiempo acordada, con un contacto de emergencia por si algo sale mal.
- Confidencialidad de todo lo encontrado, antes y después del informe.
Probar contra un sistema sin ese acuerdo, aunque sea "solo para mirar" o "no voy a hacer nada malo", es un delito en la gran mayoría de legislaciones, con independencia de la intención. La autorización no se presume: se demuestra por escrito.
4. Hacking ético, bug bounty y el límite con el delito
| Autorización | Alcance | |
|---|---|---|
| Pentest contractual | Contrato firmado con el cliente | Cerrado y detallado de antemano |
| Programa de bug bounty | Política pública del programa | Definido por el programa, hay que leerlo entero |
| Programa de divulgación (VDP) | Política pública, a veces sin recompensa | Suele ser más amplio, pero igual de vinculante |
| Sin ninguno de los anteriores | Ninguna | No existe: es intrusión no autorizada |
En un programa de bug bounty o VDP, el alcance (dominios incluidos, técnicas prohibidas, si se permite ingeniería social, si hay que usar una cuenta de pruebas) sustituye al contrato, pero es igual de vinculante. Salirse de él, aunque el hallazgo sea real, puede convertir una buena intención en un problema legal.
5. Divulgación responsable
Encontrar una vulnerabilidad fuera de un encargo (por ejemplo, en un sitio que usas como cliente) no da derecho a explotarla. La práctica correcta es la divulgación responsable: contactar al propietario o a su programa de seguridad, dar un plazo razonable para corregir el fallo antes de publicarlo, y no acceder a más datos de los estrictamente necesarios para demostrar el problema.
6. Código de conducta para este curso
- Todo lo que practiques en los laboratorios de GhostOffensive ocurre dentro de contenedores propios: son tuyos, están pensados para esto y no salen a Internet.
- Ninguna técnica de este curso se traslada a un sistema real sin autorización explícita.
- Cuando practiques en programas de bug bounty o CTF externos, lee siempre las reglas antes de la primera petición.
- El objetivo final de todo esto es mejorar la seguridad, no demostrar que puedes romper algo.
Autoevaluación
- ¿Qué diferencia a un pentest de un simple escaneo de vulnerabilidades?
- ¿Por qué el informe se considera parte central del trabajo y no un trámite final?
- ¿Qué documento tienes que tener antes de lanzar la primera petición contra un objetivo?
- Encuentras por casualidad una vulnerabilidad grave en un sitio que no forma parte de ningún encargo. ¿Qué haces?