Usos típicos de Burp Collaborator: guía completa y práctica

Home » Python » Usos típicos de Burp Collaborator: guía completa y práctica

Burp Collaborator es la pieza que te permite ver más allá de la respuesta HTTP en un pentest web. Cuando una aplicación no muestra errores, no cambia su contenido y tampoco introduce retrasos detectables, aún puede estar filtrando señales fuera de banda. Ahí es donde entra en juego este servicio: detecta vulnerabilidades invisibles provocando y monitorizando interacciones externas que el objetivo realiza sin que las veas en su respuesta in‑band.

Dentro del ecosistema de Burp Suite (Professional y DAST), Collaborator automatiza y facilita pruebas OAST (Out‑of‑band Application Security Testing). Burp genera cargas útiles atadas a subdominios únicos del servidor de Collaborator, las inyecta en el objetivo y sondea el servidor a la espera de interacciones. Cuando algo «pica», tienes una pista sólida de fallo, desde SSRF hasta XXE ciego, pasando por XSS diferido y SQLi completamente ciego.

Qué es Burp Collaborator y por qué importa

En pocas palabras, Burp Collaborator es un servicio de red capaz de recibir tráfico vía DNS, HTTP(S) y SMTP(S). A diferencia de las pruebas tradicionales centradas en lo que devuelve la app, Collaborator se fija en las conexiones que la aplicación inicia hacia fuera cuando procesas entradas controladas. Esas interacciones externas constituyen evidencias de vulnerabilidades que no se manifiestan en la respuesta directa.

El servidor de Collaborator opera con un dominio dedicado del que es autoridad DNS, dispone de un certificado wildcard válido para HTTPS y contesta consultas DNS devolviendo su propia IP para cualquier subdominio generado. Además, escucha correo y peticiones web, de modo que puede capturar cabeceras, rutas, cuerpos y metadatos que confirman el impacto del fallo.

La mecánica general es sencilla pero potente: Burp compone una carga con un identificador único (normalmente un subdominio), la envía a la app objetivo y, si ésta intenta resolver DNS, descargar un recurso o enviar un correo hacia ese identificador, el servidor de Collaborator registra la interacción. Burp, que está sondeando periódicamente, recupera los detalles y los presenta con contexto.

Cómo funciona en la práctica

Un caso típico es la interacción con servicios externos. El flujo sería: 1) la app recibe una URL con un subdominio de Collaborator; 2) realiza un lookup DNS y luego una petición HTTP; 3) el servidor de Collaborator registra ambos eventos; 4) Burp consulta (poll) y muestra los mensajes completos de la interacción. Analizando esos detalles se pueden detectar incluso vulnerabilidades específicas de servicios, como inyección de cabeceras de correo.

Otro patrón muy útil es la carga de recursos fuera de banda (OOB). Si logras inducir que la app recupere un contenido externo e inserte parte de ese contenido en su propia respuesta, Burp puede: 1) hacer que el servidor de Collaborator devuelva un token único; 2) buscar ese token en la respuesta in‑band. Si aparece, has probado una inclusión de recursos externos que puede tener implicaciones serias.

En escenarios de SQLi ciega, donde no hay errores ni diferencias de tiempo/longitud, las cargas pueden invocar funciones de base de datos que disparen una interacción externa. Que el servidor de Collaborator reciba la llamada es la confirmación de que la inyección ha sido efectiva. Este enfoque aplica a distintos motores; el principio es el mismo: si la base de datos «sale a Internet», la has pillado.

También brilla con XSS ciego o almacenado. Envías un payload que, al renderizarse en el navegador de un tercero (por ejemplo, un admin horas después), intenta cargar un recurso bajo tu identificador de Collaborator. Cuando el usuario privilegiado abre la vista, su navegador realiza la solicitud, Collaborator la captura y Burp te notifica la interacción diferida. Perfecto para detectar fallos de segunda orden.

La automatización está integrada: Burp Scanner incluye pruebas que usan Collaborator sin que tengas que mover un dedo. Y si prefieres la vía manual, el cliente de Collaborator dentro de Burp te permite generar y copiar payloads, y luego hacer poll para ver si hay actividad. En Repeater puedes insertar un payload de Collaborator desde el menú contextual; en Intruder, seleccionar el tipo de payload Collaborator. Con la extensión adecuada, existe incluso un placeholder como $collabplz (vía Taborator) para acelerar el proceso.

Usos típicos y escenarios clave

Interacción con servicios externos

Si la aplicación consulta DNS y luego hace HTTP contra un subdominio que controlas, tienes evidencia de que procesa nombres o URLs proporcionadas por el usuario. Esto sirve tanto para confirmar comportamientos esperados como para descubrir rutas de explotación inesperadas (por ejemplo, SSRF encubiertas).

Carga de recursos fuera de banda (OOB)

Cuando la aplicación recupera contenido remoto y lo incorpora en su respuesta, se abre la puerta a ataques de inclusión de contenido, filtrado de información o contaminación de respuestas. Collaborator devuelve marcadores específicos y Burp los busca en la respuesta in‑band para atar cabos con precisión.

SQL injection ciega

En SQLi sin señales visibles, las funciones que provocan llamadas externas del motor de base de datos permiten detectar el fallo. Si la interacción llega al servidor de Collaborator, la inyección ha sido ejecutada aunque la aplicación «parezca» normal.

XSS ciego o de segunda orden

Los payloads almacenados que sólo ejecuta otro usuario más tarde pueden forzar una petición hacia tu identificador. Burp queda a la escucha y, cuando el navegador del tercero hace la interacción, reporta el vector con detalles (cabeceras, ruta, momento, etc.).

SSRF y recuperación arbitraria de URLs

Si puedes hacer que el servidor descargue recursos de direcciones que tú indicas, es fácil comprobarlo con Collaborator. Un hit contra el subdominio único es una señal inequívoca de SSRF. A partir de ahí, el trabajo consiste en delimitar alcance e impacto.

XXE ciego y DTD externas

En inyecciones XXE donde no hay eco, una DTD que referencie tu endpoint de Collaborator confirma si el parser XML ha procesado entidades externas. La llamada registrada por el servidor indica que existe la vulnerabilidad aunque la respuesta HTTP no lo delate.

Interacciones DNS sospechosas

Los lookups DNS inesperados hacia tu subdominio muchas veces son el primer indicio de fallos como plantillas del lado servidor inseguras o procesado peligroso de datos. Son una pista para investigar en profundidad.

• Inyección de cabeceras de correo: con un servidor SMTP colaborador, puedes ver si un formulario termina enviando emails manipulados.
• Comportamientos diferidos: interacciones que aparecen minutos u horas después del envío original revelan fallos almacenados.

Privacidad y seguridad de los datos en Collaborator

El diseño de Collaborator prioriza la minimización y el control de acceso a los datos. Por defecto, lo que se almacena es efímero: detalles de interacciones en memoria de proceso, sin volcados a disco, bases de datos ni logs persistentes. Los eventos se descartan tras su recuperación por Burp o pasado un intervalo fijo si no se consultan.

Sólo la instancia de Burp que generó un payload puede recuperar sus interacciones. ¿Cómo? Cada instancia crea un secreto aleatorio; los identificadores de payload se derivan de un hash unidireccional de ese secreto. Cuando Burp hace poll por HTTPS, envía el secreto al servidor, que calcula el mismo hash y devuelve únicamente los eventos asociados. Sin ese secreto, nadie puede ver tus datos.

Adicionalmente, el servidor no recibe información que identifique al usuario (nada de licencias o cuentas), no hay funciones administrativas para listar interacciones y la comunicación de polling va cifrada salvo que lo desactives a propósito. En entornos sensibles, este modelo reduce superficie de exposición.

Opciones de uso y despliegue

Como tester tienes tres caminos. Primero, usar el servidor público de PortSwigger, compartido por la comunidad. Es práctico, aunque su disponibilidad no está garantizada y algunas organizaciones lo bloquean. Segundo, levantar un servidor privado si cuentas con Burp Suite Professional: ideal para redes internas, pruebas aisladas o cuando no puedes exponer datos a terceros. Tercero, desactivar Collaborator en escenarios donde no se permite tráfico externo; eso sí, asume que perderás detecciones OAST.

Si eliges desplegarlo en privado, lo óptimo es contar con un host dedicado, un dominio propio y un wildcard TLS firmado por CA. Aunque incluso con limitaciones (por ejemplo, sólo con IP interna) es útil para ciertos flujos. Puedes separar interfaces para recibir interacciones y para el polling, además de filtrar IPs según dónde estén el objetivo y el equipo auditor.

Un detalle práctico: los pingbacks no tienen por qué usar el dominio por defecto. Puedes apuntar tu dominio a la IP del Collaborator público y colocar el identificador único en otra parte de la petición (por ejemplo, en una cabecera como User‑Agent). Esto ayuda cuando el dominio habitual está en listas de bloqueo, siempre respetando la legalidad y las políticas del cliente.

Y un consejo de operativa: genera los payloads dentro de proyectos guardados en disco. Si lo haces en un proyecto temporal y reinicias Burp, perderás el acceso a esos identificadores y, con ello, a sus interacciones asociadas.

Colaboración con Burp Suite y el ecosistema

En Burp Suite Professional y en Burp Suite DAST, Scanner automatiza pruebas que se apoyan en Collaborator y reporta los hallazgos. Además, hay extensiones y BApps que lo integran de forma creativa para ampliar cobertura. En manual, el cliente de Collaborator y herramientas como Repeater e Intruder te dan control fino para probar hipótesis y confirmar impacto real.

En el día a día del pentest, el proxy interceptador de Burp te deja ver y modificar cada solicitud/respuesta HTTP(S). Combinado con Intruder (fuzzing y fuerza bruta), Comparer (diferencias sutiles) y Decoder (codificaciones), tienes un laboratorio completo para tantear entradas, manipular sesiones y modelar ataques. Collaborator añade la capa OAST que faltaba.

Si comparas con otras herramientas: OWASP ZAP es una alternativa estupenda para empezar, pero Burp Professional ofrece más personalización y un ecosistema de extensiones más maduro. Frente a Nmap o Nessus/OpenVAS, que rastrean redes o vulnerabilidades a nivel sistema, Burp se centra en lógica de aplicaciones web y en explotación controlada. Y contra Wireshark, que opera a nivel de paquete, Burp vive en la capa de aplicación para modificar y orquestar tráfico.

Para sacarle partido, conviene seguir buenas prácticas: configura bien el proxy, instala el certificado de Burp en el navegador, organiza el proyecto con etiquetas y guarda el estado con frecuencia. Automatiza tareas repetitivas con macros o reglas de match & replace, y valida los hallazgos automáticos con pruebas manuales en Repeater/Intruder para evitar falsos positivos. Todo ello, siempre con autorización y en entornos controlados.

En Integración y DevSecOps, la API de Burp y su encaje en CI/CD permiten lanzar escaneos y orquestar pruebas durante el desarrollo. Es fácil combinarlo con SIEM/SOAR para correlación y respuesta, y con herramientas como Metasploit o scanners de APIs. En aplicaciones modernas, su manejo de tokens, sesiones y endpoints encaja de maravilla con pipelines ágiles.

Extensiones útiles para potenciar pruebas

La BApp Store y los repositorios de la comunidad aportan complementos que agilizan el trabajo y, en muchos casos, aprovechan Collaborator como canal OAST. Estas son algunas extensiones destacadas que suelo usar:

• ATOR: automatiza el inicio de sesión y mantiene vivas las sesiones para no perder el contexto durante el test.
• Backslash Powered Scanner: añade pruebas poco convencionales al escáner activo para detectar comportamientos anómalos del servidor.
• Collabfiltrator: facilita la exfiltración vía DNS en escenarios de ejecución remota, aprovechando Burp Collaborator.
• Hackvertor: conversión rápida entre HTML5, hex, octal, Unicode y URL encoding.
• HTTP Request Smuggler: busca contrabando de solicitudes y desincronizaciones entre proxies/servidores.
• Java Deserialization Scanner: localiza fallos de deserialización en entornos Java.
• J2EEScan: suma decenas de pruebas específicas para ecosistemas J2EE.
• JSON Web Tokens: decodifica y manipula JWTs, validando firmas y automatizando ataques comunes.
• JS Miner: rastrea archivos JavaScript y JSON en busca de secretos, rutas o endpoints interesantes.
• .NET Beautifier: mejora la legibilidad de peticiones .NET.
• OAUTH Scan: detecta debilidades en flujos OAuth2/OpenID.
• Param Miner: descubre parámetros ocultos que la app procesa sin documentar.
• RegexFinder: escaneo pasivo de patrones con regex en respuestas.
• Request Timer: mide y compara tiempos de respuesta para análisis de comportamiento.
• Retire.js: integra con el repositorio de Retire.js para librerías JS vulnerables.
• SAML Raider: pruebas sobre infraestructuras SAML.
• Turbo Intruder: envía grandes volúmenes de peticiones y analiza correlaciones.
• Upload Scanner: automatiza pruebas de subida de ficheros.
• Autorize: localiza errores de autorización comparando perfiles.
• AutoRepeater: reenvío automatizado de solicitudes con mutaciones controladas.
• Hopla: añade autocompletados y cargas útiles frecuentes desde el menú contextual.

Mejores prácticas y flujo de trabajo con Collaborator

No todo entorno permite tráfico hacia servicios externos. En esos casos, sopesa bien si desactivar Collaborator o levantar una instancia privada. Donde sí puedas usarlo, define criterios de prueba claros para no inundar de hits sin valor tu cola de interacciones.

Integra Collaborator con Repeater e Intruder para verificar hipótesis: ejecuta variantes sobre la misma solicitud, observa qué cambios provocan actividad fuera de banda y documenta los correlatos (DNS vs HTTP, cabeceras, tiempos). Así reduces falsos positivos y entiendes la raíz del fallo.

Si trabajas con terceros, algunos proveedores ofrecen listeners propios similares al de Collaborator para uso manual; pueden ser útiles como alternativa de laboratorio. Y recuerda que hay extensiones como Collaborator Everywhere o Taborator que inyectan y gestionan payloads automáticamente en posiciones estratégicas.

Por último, combina OAST con técnicas in‑band. Collaborator confirma que «algo sale», pero con el proxy, Comparer y el escáner puedes demostrar impacto real en la lógica de negocio. Esa mezcla de señales es la que mejor convence a equipos de desarrollo y de cumplimiento.

Dominar Burp Collaborator supone pensar como atacante y medir como analista: disparas una semilla, esperas la interacción y unes evidencias con método. Con su integración nativa en Burp, su enfoque en privacidad de los datos y las opciones de despliegue público/privado, se convierte en la herramienta decisiva para descubrir vulnerabilidades que el canal in‑band jamás mostrará.