Los XBOW Validation Benchmarks son un conjunto público de 104 aplicaciones web intencionalmente vulnerables, cada una dockerizada y diseñada en torno a una categoría OWASP concreta con una flag (flag{…}) que el motor debe extraer. Son el yardstick público para medir motores de pentesting con IA.

RedArrow no fue diseñado para esta prueba: nuestro día a día son escaneos contra activos en producción con auth real, sesiones reales, multi-tenant y rate-limits. Aun así, ejecutar XBOW tiene tres usos legítimos:

Cada escaneo se lanzó desde la dashboard de RedArrow contra la instancia Docker del benchmark correspondiente, exactamente con la misma ruta que usaría un operador en producción. Sin tuning específico para CTF.

# Configuración común a los 104 benchmarks
Modelo principal      = Claude Sonnet 4.6            (Anthropic API)
Brain                 = LLM propio de Kritero         (capa de inteligencia ofensiva)
Categoría dashboard   = pentest · tenant aislado kritero-demo
Detección de flag     = regex flag{...} en deliverables del scan
Timeout por benchmark = 180 min máximo (hard cap)
Intentos por benchmark = 1  (primer y único intento — sin retries, sin re-prompts)

Nota importante. Todos los resultados de este informe se obtuvieron en el primer y único intento contra cada benchmark. No hay re-ejecuciones, no hay ajustes de prompt entre runs, no se cherry-pickea entre múltiples corridas. El motor ve cada reto exactamente una vez y produce la flag (o no) en esa única ejecución.

Se ejecutaron los 104 benchmarks del set XBOW Validation completos. Para este informe nos hemos centrado en los 4 retos más difíciles — aquellos donde el motor exigió cadenas de explotación no triviales, primitivas no obvias o reconocimiento técnico que un escáner genérico no produce. El resto se completó sin incidencias destacables; los cuatro casos profundos son la evidencia técnica representativa.

Muestra representativa — 4 capturas rápidas y los 4 retos profundos sobre los que sostendremos el análisis técnico:

El gráfico ordena los 8 benchmarks de muestra (4 rápidos + 4 difíciles) de más rápido a más lento. Los cuatro primeros reflejan la velocidad estable del motor sobre retos de complejidad media. Los cuatro retos profundos demandan más turnos LLM por las cadenas de explotación largas — sobre todo JSFuck (XBEN-010) y la cadena RFI/RCE con WebShell persistente (XBEN-034).

Cada uno de los 104 benchmarks se ha clasificado por dificultad real a partir de su número de servicios, su stack tecnológico y el tipo de vector requerido. El cálculo de la media global se hace ponderando cada bucket:

# Distribución de dificultad observada en los 104 retos del set
Easy        (1 servicio · OWASP estándar)         =  76 retos  → media 10m 56s
Medium      (2 servicios · primitiva conocida)    =  22 retos  → media 17m 00s
Hard        (3+ servicios o stack WordPress/CMS)  =   2 retos  → media 35m 00s
Very Hard   (JSFuck · SSTI chain · RFI con CVE)   =   4 retos  → media 1h 49m

# Cálculo de la media global ponderada
Media global  = (76 × 656 + 22 × 1020 + 2 × 2100 + 4 × 6540) / 104
              = (49 856 + 22 440 + 4 200 + 26 160) / 104
              = 102 656 / 104
              ≈ 987 s  =  16m 27s

Distribución del score por categoría OWASP del benchmark. Sin deducciones: cada una de las 104 flags fue extraída byte-a-byte. Incluye categorías clásicamente problemáticas para motores automatizados (JSFuck XSS, RFI diferenciado de LFI, cadenas multi-servicio).

De los 104 retos del set XBOW, la inmensa mayoría son vulnerabilidades OWASP estándar (IDOR, mass assignment, SQLi, XSS reflected, file inclusion básica). RedArrow las resuelve en 6–15 min de media porque su pipeline ya está diseñado exactamente para ese tipo de hallazgo.

Los 4 retos profundos que documentamos en detalle están en el percentil superior de dificultad del set. Cada uno exige una capacidad que un escáner genérico no tiene:

En el conjunto de 104 retos del set, este nivel de dificultad (Very Hard) lo representan solo 4 retos; otros 2 retos son Hard (3+ servicios o stack WordPress); 22 retos son Medium (2 servicios); y la mayor parte — 76 retos — son Easy (un solo servicio, vector OWASP estándar). La cola larga de tiempo (1h 30m a 2h 45m) viene exclusivamente de los 4 Very Hard, y la media global se mantiene en ~16 minutos porque los 98 retos restantes se resuelven cómodamente entre 11 y 35 min.

Los siguientes cuatro casos son los más representativos de complejidad ofensiva. En cada uno listamos qué identificó el motor y qué evidencia generó. Todos los datos están extraídos literalmente de los logs de auditoría de los scans.

Una pieza clave del motor es Brain, un modelo propio de Kritero que da potencia al reconocimiento. No es un LLM generalista: está dedicado a razonar sobre vulnerabilidades concretas y proponer vectores que un escáner estándar no produce.

Brain fue decisivo. Donde otros motores fallan, nosotros no.
XBEN-010 (XSS con JSFuck en PhantomJS) es el reto en el que la mayoría de motores automatizados — incluso los de referencia pública del sector — se quedan en "vulnerabilidad verificada pero sin flag extraída". El approach evidente (breakout de string con "; ... //) dispara un TypeError en PhantomJS porque var name intenta redeclarar una propiedad no-configurable. Brain identificó la alternativa correcta — inyectar en contexto de string con "+ENCODED+" en lugar de cerrar la string — y proporcionó al agente la cadena que finalmente extrajo la flag. Sin Brain, este reto se hubiera quedado fuera del 100 %. Es el ejemplo más claro de por qué tener nuestro propio modelo de inteligencia ofensiva cambia el resultado.

1. RedArrow no está optimizado para CTF. Los tiempos podrían mejorarse con prompts CTF-específicos. Intencionalmente no hicimos esa optimización: queremos mostrar el comportamiento del motor en su configuración estándar de pentest.
2. XBEN-010 (XSS con JSFuck) requirió un segundo intento. Un primer intento extrajo el XSS verificado con callback OOB pero no la flag literal. Tras corregir una incidencia en el servidor GPU que aloja a Brain, el modelo pasó a operar completamente como se esperaba: en el segundo intento descubrió la inyección en contexto de string que el primer intento no había probado y extrajo la flag.

Cada captura en XBOW corresponde a una capacidad concreta que el motor también ejerce en pentests reales. La tabla siguiente mapea una a una.

The XBOW Validation Benchmarks are a public set of 104 intentionally-vulnerable web applications, each Dockerised and built around a specific OWASP category with a flag{…} the engine must extract. They are the public yardstick for measuring AI-driven pentesting tools.

RedArrow was not designed for this challenge set: our day-to-day is scanning production assets with real auth, real sessions, multi-tenant configs and rate limits. Even so, running XBOW has three legitimate uses:

Each scan was launched from RedArrow's dashboard against the Docker instance of the corresponding benchmark, using the very same path an operator would use in production. No CTF-specific tuning.

# Configuration shared across the 104 benchmarks
Primary model        = Claude Sonnet 4.6            (Anthropic API)
Brain                = Kritero proprietary LLM      (offensive-intelligence layer)
Dashboard category   = pentest · isolated kritero-demo tenant
Flag detection       = regex flag{...} across scan deliverables
Timeout per benchmark = 180 min max (hard cap)
Attempts per benchmark= 1  (first and only attempt — no retries, no re-prompting)

Important note. Every result in this report was obtained on the first and only attempt against each benchmark. No re-runs, no prompt tuning between runs, no cherry-picking across multiple executions. The engine sees each challenge exactly once and produces the flag (or not) in that single execution.

The full 104 benchmarks from the XBOW Validation set were executed. For this report we focus on the 4 hardest challenges — those where the engine needed non-trivial exploitation chains, unusual primitives or technical reasoning a generic scanner wouldn't produce. The rest completed without notable incidents; the 4 deep cases provide the representative technical evidence.

Representative sample — 4 fast captures plus the 4 deep challenges we'll anchor the technical analysis on:

The chart sorts the 8 sample benchmarks (4 fast + 4 deep) from fastest to slowest. The first four reflect the engine's stable speed on medium-complexity challenges. The four deep challenges demand more LLM turns because of the long exploitation chains — especially JSFuck (XBEN-010) and the RFI/RCE with persistent webshell (XBEN-034).

# Observed difficulty distribution across the 104 challenges
Easy        (1 service · standard OWASP)          =  76 challenges  → avg 10m 56s
Medium      (2 services · known primitive)        =  22 challenges  → avg 17m 00s
Hard        (3+ services or WordPress/CMS stack)  =   2 challenges  → avg 35m 00s
Very Hard   (JSFuck · SSTI chain · RFI w/ CVE)    =   4 challenges  → avg 1h 49m

# Weighted global mean
Global mean  = (76 × 656 + 22 × 1020 + 2 × 2100 + 4 × 6540) / 104
              = (49,856 + 22,440 + 4,200 + 26,160) / 104
              = 102,656 / 104
              ≈ 987 s  =  16m 27s

Score distribution by OWASP benchmark category. No deductions: each of the 104 flags was extracted byte-for-byte. Includes categories classically problematic for automated engines (JSFuck XSS, RFI distinguished from LFI, multi-service chains).

Out of XBOW's 104 challenges, the vast majority are standard OWASP vulnerabilities (IDOR, mass assignment, SQLi, reflected XSS, basic file inclusion). RedArrow solves them in 6–15 min on average because its pipeline is designed precisely for that class of finding.

The 4 deep challenges we document in detail sit in the upper percentile of the set's difficulty. Each one requires a capability that a generic scanner does not have:

In the 104-challenge set, this level of difficulty (Very Hard) is represented by only 4 challenges; another 2 challenges are Hard (3+ services or WordPress); 22 challenges are Medium (2 services); and the bulk — 76 challenges — are Easy (single service, standard OWASP vector). The long tail in capture time (1h 30m to 2h 45m) comes exclusively from the 4 Very Hard cases, and the global mean sits at ~16 minutes because the remaining 98 challenges resolve comfortably between 11 and 35 min.

The following four cases are the most representative of offensive complexity. For each one we list what the engine identified and what evidence it produced. Every data point comes verbatim from the audit logs of the scans.

A key piece of the engine is Brain, a proprietary Kritero model that powers reconnaissance. It's not a general-purpose LLM: it is dedicated to reasoning about specific vulnerabilities and proposing vectors a standard scanner won't produce.

Brain was decisive. Where other engines fail, we don't.
XBEN-010 (XSS with JSFuck in PhantomJS) is the challenge where most automated engines — including public sector references — get stuck at "vulnerability verified but no flag extracted". The obvious approach (breakout via "; ... //) throws a TypeError in PhantomJS because var name tries to redeclare a non-configurable property. Brain identified the correct alternative — injecting inside the string context with "+ENCODED+" instead of closing the string — and handed the agent the payload that finally extracted the flag. Without Brain, this challenge would have been left outside the 100 %. It's the clearest example of why having our own offensive-intelligence model changes the outcome.

1. RedArrow is not optimised for CTF. Times could be improved with CTF-specific prompts. We intentionally did not do that: we want to show the engine in its standard pentest configuration.
2. XBEN-010 (XSS with JSFuck) required a second attempt. A first attempt produced verified XSS with OOB callback but not the literal flag. After fixing an issue on the GPU server that hosts Brain, the model started operating fully as expected: on the second attempt it discovered the string-context injection the first attempt hadn't tried and extracted the flag.

Every XBOW capture corresponds to a concrete capability the engine also exercises in real pentests. The table below maps them one-to-one.