Burp Suite en campaña real

01Objetivo

Pasar de "sé usar Burp Suite" a "tengo un flujo de trabajo en Burp que escala a una campaña de semanas sobre varios programas", que es una habilidad distinta.

02Teoría

Por qué el flujo de trabajo importa más que conocer cada botón

Saber qué hace Repeater o Intruder no sirve de mucho si cada sesión de caza empieza desde cero: configurar el proxy, volver a hacer login, volver a mapear lo ya mapeado. El coste de fricción de "arrancar" una sesión de caza, multiplicado por decenas de sesiones a lo largo de una campaña, es más tiempo perdido que cualquier vulnerabilidad individual que se tarde en encontrar.

Organización por proyecto, no por "una ventana de Burp para todo"

• Un proyecto de Burp por programa, nunca mezclado. Mezclar el tráfico de dos programas en el mismo proyecto es además un riesgo de scope: es fácil repetir por error una petición de un dominio en el contexto de otro.
• Scope de Burp configurado explícitamente al dominio/subdominios del programa, para que Target y los logs no se llenen de ruido de terceros (analítica, CDNs, fuentes de letras) que no vas a probar nunca.
• Sitemap guardado y anotado con los hallazgos de priorización del módulo 5/6 directamente como comentarios en los items del Target, para no tener el mapa de superficie en un documento separado que se desincroniza del proyecto real.

Match & Replace para fricción recurrente

Los programas con apps móviles o APIs que exigen cabeceras específicas (firma de petición, versión de app, token de dispositivo) generan fricción constante si hay que añadirlas a mano en cada Repeater. Una regla de Match & Replace que inyecta automáticamente esas cabeceras en todo el tráfico del proyecto elimina ese coste de forma permanente para toda la campaña sobre ese programa.

Sesiones autenticadas que no se caen a mitad de prueba

Configurar el manejo de sesión (Session Handling Rules) para que Burp renueve automáticamente el token/cookie cuando caduque, en vez de descubrir a mitad de un Intruder de 500 peticiones que las últimas 400 fallaron porque la sesión expiró a la petición 100. Esto es especialmente crítico en pruebas de condiciones de carrera (módulo 8) y en Intruder/Turbo Intruder contra endpoints de autenticación.

Extensiones que de verdad rinden en campaña (no "coleccionar extensiones")

• Turbo Intruder — imprescindible para condiciones de carrera que requieren precisión de milisegundos, donde Repeater manual no basta.
• JWT Editor — para el checklist completo del módulo 9 sin reescribir tokens a mano byte a byte (ver nota de fricción más abajo).
• Autorize / Auto Repeater (o equivalente) — automatiza la repetición de cada petición con las credenciales de una segunda cuenta, acelerando brutalmente la caza de IDOR del módulo 7 sobre todo el mapa de superficie del módulo 4/6.

Una advertencia operativa real: editar tokens a mano es frágil

Editar un JWT u otro token complejo a golpe de clics y coordenadas de interfaz, repitiendo el proceso a mano cada vez, es una fuente de errores silenciosos: un clic fuera de sitio corrompe el token sin aviso claro, y la prueba "falla" por un motivo que no tiene nada que ver con la vulnerabilidad que se está buscando. Siempre que la herramienta lo permita, genera la petición ya forjada mediante su función correspondiente (firmar con una clave, aplicar una regla guardada) en lugar de editar campo a campo manualmente cada vez.

03Resumen operativo

1. Un proyecto de Burp por programa, con scope explícito. Nunca mezclar tráfico de dos programas.
2. Match & Replace y Session Handling Rules eliminan la fricción que se repite cientos de veces en una campaña larga.
3. Turbo Intruder, JWT Editor y un automatizador de IDOR son las tres extensiones con mejor retorno real.
4. Automatiza la generación de payloads complejos (tokens) en vez de editarlos a mano repetidamente.