Nuestra metodología de pentesting web, paso a paso

Después de más de 27 auditorías de aplicaciones web, APIs y plataformas móviles, en Veritus Code tenemos algo claro: las herramientas no encuentran las vulnerabilidades graves; las encuentra la metodología. Nuclei te dirá que falta una cabecera de seguridad. No te dirá que un usuario normal puede aprobar sus propias facturas cambiando un ID.

En este artículo explicamos, fase por fase, cómo trabajamos. La metodología se basa en PTES para la estructura, en OWASP (WSTG y Top 10) para la cobertura de pruebas y en MITRE ATT&CK para pensar como un atacante real.

Todo lo que aparece aquí se aplica solo a sistemas para los que se tiene autorización por escrito. Sin alcance firmado no hay pentest: hay un delito.

0. Alcance y reglas de enfrentamiento

Antes de lanzar un solo paquete, dejamos por escrito con el cliente:

Qué entra y qué no: dominios, subdominios, rangos IP, APIs, apps móviles. Si aparece un subdominio nuevo durante el reconocimiento, preguntamos antes de tocarlo.
Cuentas de prueba: al menos dos usuarios por cada rol (dos normales, dos administradores). Sin esto no se puede probar bien el control de acceso.
Ventanas y límites: horarios, límite de peticiones por segundo y si se permiten pruebas de denegación de servicio (casi nunca en producción).
Contacto de emergencia: si encontramos algo crítico, como un RCE o una fuga masiva de datos, avisamos de inmediato, sin esperar al informe final.

Esta fase parece burocracia, pero es lo que separa un trabajo profesional de uno amateur. También firmamos un acuerdo de confidencialidad antes de empezar.

1. Reconocimiento

El objetivo es conocer la superficie de ataque mejor que el propio cliente. Casi siempre aparece algo que “ya no se usaba”.

Pasivo

Sin tocar el objetivo: certificados públicos, DNS histórico, buscadores y repositorios.

# Subdominios desde fuentes pasivas
amass enum -passive -d objetivo.com -o subs_amass.txt
subfinder -d objetivo.com -silent -o subs_subfinder.txt

# Certificados emitidos (Certificate Transparency)
curl -s "https://crt.sh/?q=%25.objetivo.com&output=json" \
  | jq -r '.[].name_value' | sort -u > subs_crt.txt

sort -u subs_*.txt > subdominios.txt

También revisamos GitHub en busca de fugas (claves, endpoints internos) y la Wayback Machine para encontrar rutas antiguas que siguen vivas.

Activo

Ya dentro del alcance, confirmamos qué está vivo y qué expone:

# ¿Qué subdominios responden por HTTP/HTTPS?
httpx -l subdominios.txt -title -tech-detect -status-code -o vivos.txt

# Puertos y servicios del servidor principal
nmap -sC -sV -p- --min-rate 1000 -oA nmap_full objetivo.com

# Descubrimiento de contenido
ffuf -u https://app.objetivo.com/FUZZ -w raft-medium-directories.txt \
     -mc 200,204,301,302,307,401,403 -rate 50 -o ffuf.json

El -rate 50 no es un detalle menor: respetar los límites acordados es parte del trabajo.

2. Mapeo de la aplicación

Aquí es donde más tiempo invertimos, y de donde salen después la mayoría de los hallazgos. Con Burp Suite como proxy navegamos la aplicación como un usuario real, con cada rol:

Recorremos todas las funcionalidades: registro, recuperación de contraseña, perfil, pagos, exportaciones, subida de archivos…
Revisamos el JavaScript del frontend: suele revelar endpoints de la API que la interfaz no muestra y parámetros ocultos.
Construimos un mapa: qué hace cada endpoint, qué datos recibe, qué rol debería poder usarlo y qué identificadores maneja.

Ese mapa es la base de todo lo demás. Si no se entiende cómo funciona el negocio, no se pueden encontrar fallos de lógica de negocio.

3. Análisis de vulnerabilidades

Combinamos dos enfoques, y el orden importa.

Automatizado: lo rápido y lo obvio

nuclei -l vivos.txt -severity medium,high,critical -rl 30 -o nuclei.txt

Nuclei y el escáner de Burp encuentran configuraciones inseguras, versiones vulnerables y paneles expuestos. Todo resultado automático se valida a mano: los falsos positivos en un informe destruyen la credibilidad.

Manual: donde están los hallazgos críticos

Estas son las pruebas que ningún escáner hace bien:

Control de acceso roto (IDOR / BOLA): con el usuario A pedimos los recursos del usuario B. Con un usuario normal llamamos a los endpoints de administrador. La extensión Autorize de Burp ayuda a sistematizarlo.
Lógica de negocio: ¿se puede aplicar un cupón dos veces? ¿Poner una cantidad negativa? ¿Saltarse un paso del flujo de compra? ¿Qué pasa con dos peticiones simultáneas (race condition)?
Inyecciones: SQLi, XSS, inyección de plantillas (SSTI) y de comandos, en cada parámetro que llega al servidor, incluidas cabeceras y JSON anidado.
SSRF: cualquier funcionalidad que reciba una URL (webhooks, importar desde URL, generar PDF, previsualizar enlaces).
Autenticación y sesiones: recuperación de contraseña, JWT (algoritmo, firma, expiración), MFA que se puede saltar, sesiones que no se invalidan al cerrar sesión.
Subida de archivos: extensiones, tipo MIME, contenido, y dónde y cómo se sirve el archivo después.

4. Explotación controlada

Encontrar una vulnerabilidad no basta: hay que demostrar su impacto real sin causar daño. Nuestras reglas:

Mínimo impacto: en un SQLi extraemos la versión de la base de datos y el nombre de una tabla, no la tabla de clientes. sqlmap se usa con cuidado (--level y --risk bajos y --technique acotado) y nunca contra formularios que escriben datos sin permiso.
Pruebas de concepto reproducibles: la petición exacta, la respuesta y los pasos, para que el equipo del cliente pueda verificarlo por su cuenta.
Encadenar: un XSS de impacto bajo junto con un token de sesión sin HttpOnly y un endpoint que cambia el email de la cuenta dan como resultado toma de cuentas. Encadenar fallos es lo que convierte hallazgos medios en críticos, y lo que más valoran nuestros clientes.

5. Informe: la parte que el cliente paga

El cliente no compra “un pentest”. Compra saber qué riesgo tiene y cómo arreglarlo. Cada informe que entregamos tiene dos niveles:

Resumen ejecutivo para dirección: pocas páginas, sin jerga, con el riesgo expresado en impacto de negocio (“un usuario registrado puede descargar las facturas de cualquier cliente”).
Hallazgos técnicos para el equipo de desarrollo, cada uno con:

Campo	Contenido
Severidad	CVSS y justificación en contexto
Descripción	Qué es y dónde está
Evidencia	Peticiones, respuestas y capturas
Pasos para reproducir	Numerados y exactos
Impacto	Qué puede hacer un atacante
Recomendación	Cómo corregirlo, con referencias (OWASP, CWE)

Después hacemos un retest gratuito: verificar que las correcciones funcionan de verdad es lo que cierra el ciclo, y lo entregamos con una carta de verificación.

Lo que hemos aprendido en más de 27 auditorías

El mapeo manual rinde más que cualquier escáner. Las horas dedicadas a entender la aplicación se recuperan con creces.
El control de acceso es la vulnerabilidad más común y más grave que encontramos. Casi siempre hay al menos un endpoint que no comprueba quién hace la petición.
Un buen informe vale tanto como un buen hallazgo. Si el equipo no entiende cómo reproducirlo, no se arregla.
Automatizar lo repetitivo (reconocimiento, validaciones), no lo que requiere pensar.

En los próximos artículos entraremos en detalle en cada fase: nuestro flujo de reconocimiento en Bash y Python, cómo probamos el control de acceso en APIs REST y los fallos que aparecen en casi todas las auditorías.

¿Quieres saber cómo resistiría tu aplicación esta metodología? Solicita una cotización y te respondemos en menos de 24 horas.