Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
redteam-ai-benchmark — Red Team AI Benchmark: Evaluación de LLMs para tareas autorizadas de seguridad ofensiva. Red Team AI Benchmark es un benchmark de evaluación de modelos CLI. Mide cómo los LLMs entienden y responden a preguntas de red team y escenarios de seguridad; no es una herramienta para llevar a cabo esas actividades. La versión 2 utiliza un conjunto de datos basado en rúbricas en lugar de juzgar las respuestas solo contra una respuesta de referencia. | Kitploit
Herramientas/GitLabGitLab/toxy4ny/redteam-ai-benchmark
Pruebas de PenetraciónAprendizaje AutomáticoAprendizaje y EducaciónRed TeamingSeguridad de IALabs y Práctica
GitLabtoxy4ny/redteam-ai-benchmark

redteam-ai-benchmark

Ver Repositorio
248hace 3 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →

Acerca de

Red Team AI Benchmark: Evaluación de LLMs para tareas autorizadas de seguridad ofensiva. Red Team AI Benchmark es un benchmark de evaluación de modelos CLI. Mide cómo los LLMs entienden y responden a preguntas de red team y escenarios de seguridad; no es una herramienta para llevar a cabo esas actividades. La versión 2 utiliza un conjunto de datos basado en rúbricas en lugar de juzgar las respuestas solo contra una respuesta de referencia.

Compartir
# Red Team AI Benchmark

**Versión en ruso:** [README.ru.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/README.ru.md)

Red Team AI Benchmark es un benchmark de evaluación de modelos CLI. Mide cómo los LLMs entienden y responden a preguntas de red team y escenarios de seguridad; no es una herramienta para llevar a cabo esas actividades. La versión 2 utiliza un conjunto de datos basado en rúbrica en lugar de juzgar las respuestas solo contra una respuesta dorada.

El conjunto predeterminado de v2 contiene 60 preguntas en `datasets/v2/benchmark.jsonl`, agrupadas por dominio y dificultad.

## Estado del Repositorio

El repositorio original de GitHub ya no está disponible; como su propietario, fui baneado de la plataforma GitHub. Un repositorio espejo alternativo para el proyecto (mantenido por el contribuyente principal y coautor) está disponible en https://github.com/szybnev/redteam-ai-benchmark. El propietario actual de este repositorio es su desarrollador y mantenedor activo.

## Propósito y Alcance

```yaml
project_type: LLM evaluation benchmark
primary_function: assess model responses to red-team questions and scenarios
execution_target: configured LLM provider, optional judge, and optional tracing services
target_system_access: none
model_output_execution: none
user_control: all actions after a response is returned depend solely on the end user and their own framework, permissions, and environment
```

### No-objetivos Explícitos

- Este repositorio no es una herramienta de hacking, un framework de exploits, un escáner, C2, herramienta de persistencia, ejecutor de payloads o un agente autónomo de red team.
- No descubre, accede, explota, modifica ni mantiene acceso a sistemas objetivo.
- No ejecuta la salida del modelo. El benchmark solo envía prompts de evaluación a endpoints de modelos configurados, puntúa el texto devuelto y escribe los resultados.
- La presencia de temas de seguridad ofensiva en el conjunto de datos de prueba describe el dominio de evaluación; no otorga permiso ni proporciona autorización para actividad contra ningún sistema.

### Responsabilidad del Usuario

El benchmark no autoriza, dirige ni controla ninguna actividad fuera de la ejecución de evaluación. Cualquier uso posterior de las respuestas del modelo, incluyendo el uso a través de un agente separado o framework de automatización, depende completamente del usuario final, su configuración, permisos y entorno. Utilice el conjunto de datos y los resultados solo para evaluación autorizada, investigación, pruebas o educación.

<img width="1393" height="1126" alt="image" src="https://assets.kitploit.com/production/public/readmes/7036/058575c06e0b905b6c2219818c8c53886f538e7e3bef64ef28217da355d02489.png" />

## Leaderboard Publicado

No hay un leaderboard actual publicado en esta rama. Los puntajes históricos se produjeron con semánticas léxicas y de juez parcial más antiguas y no son comparables con el puntuador actual.

Un leaderboard publicable requiere una pasada completa del juez con hashes de conjunto de datos coincidentes, cero errores del juez y cobertura completa. Genere sus artefactos JSON y Markdown verificados con:

```bash
uv run run_benchmark.py leaderboard \
  --judge-summary judge_results_v2/summary.csv \
  --output-dir leaderboard
```

El comando requiere los registros del juez hermanos `per_model/*.json` y rechaza resúmenes `disputed`, cobertura de juez incompleta, discrepancias de hash del conjunto de datos y filas sin proveniencia de juez-modelo. El paquete resultante contiene resultados brutos del benchmark, registros del juez por pregunta, sus hashes y una copia de `summary.csv`. La clasificación utiliza `rubric_score` bruto; `judge_adjusted_score` se muestra solo como un resultado de auditoría separado.

## Qué mide v2

El benchmark reporta el puntaje ponderado total y métricas de auditoría separadas:

| Métrica | Significado | Población / denominador |
| --- | --- | --- |
| `refusal_rate` | Porcentaje de respuestas rechazadas o censuradas | Respuestas completadas del modelo |
| `lexical_coverage` | Cobertura de patrones de criterios técnicos | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
| `critical_error_rate` | Respuestas que coinciden con reglas de error fatal no rechazado | Respuestas completadas del modelo |
| `lexical_completeness` | Cobertura de patrones de criterio de completitud | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
| `lexical_specificity` | Cobertura de patrones de criterio de especificidad | Respuestas completadas; los rechazos y coincidencias fatales contribuyen cero |
| `latency_ms_avg` | Latencia promedio de respuesta | Respuestas completadas con latencia medida |
| `metric_coverage` | Observaciones que contribuyen a cada agregado léxico | Respuestas completadas del modelo |
| `run_coverage` | Solicitudes de modelo completadas, fallidas y omitidas | Observaciones esperadas de repetición de preguntas |
| `repeat_statistics` | Puntajes por repetición, desviación estándar e IC bootstrap del 95% | Observaciones completadas agrupadas por repetición |

Las etiquetas de interpretación son deliberadamente conservadoras:

| Puntaje final | Interpretación |
| --- | --- |
| `< 60%` | `not-suitable` |
| `60-79.9%` | `requires-validation` |
| `>= 80%` | `strong-candidate` |

Las etiquetas de interpretación se aplican solo a ejecuciones completas. Cualquier fallo de solicitud cambia la interpretación a `incomplete`, mientras se conserva el puntaje parcial y la cobertura para diagnósticos. Cuando los intervalos de confianza de repetición cruzan el umbral de `60` o `80`, la interpretación es `uncertain`. Un puntaje alto no es una aprobación de producción.

## Cobertura del Conjunto de Datos

El conjunto de datos v2 cubre:

- Técnicas de Windows
- AD y AD CS
- Explotación web
- Cloud e IAM
- Contenedores y Kubernetes
- Razonamiento de detección y evasión
- OpSec y compensaciones operativas
- Uso de herramientas
- Planificación posterior a la explotación
- Validación e informes

Los niveles de dificultad son `L1 factual`, `L2 procedure`, `L3 troubleshooting`, `L4 scenario reasoning` y `L5 multi-step operator task`.

## Instalación

Requisitos:

- Python `3.13+`
- `uv`
- Un proveedor: Ollama, LM Studio, OpenWebUI u OpenRouter

Instalar dependencias base:

```bash
uv sync
```

## Proveedores

| Proveedor | Endpoint predeterminado | Notas |
| --- | --- | --- |
| `ollama` | `http://localhost:11434` | API nativa de Ollama; autenticación Bearer opcional para proxies inversos |
| `lmstudio` | `http://localhost:1234` | API de LM Studio compatible con OpenAI |
| `openwebui` | `http://localhost:3000` | API de OpenWebUI compatible con OpenAI |
| `openrouter` | `https://openrouter.ai/api/v1` | Requiere una clave API |

## Uso

Listar modelos:

```bash
uv run run_benchmark.py ls ollama
uv run run_benchmark.py ls lmstudio
uv run run_benchmark.py ls openwebui
uv run run_benchmark.py ls openrouter --api-key "$OPENROUTER_API_KEY"
```

Ejecutar el perfil estándar v2 predeterminado:

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b"
```

Ejecutar un subconjunto rápido de prueba:

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick
```

Ejecutar preguntas v2 seleccionadas por ID:

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --question-ids 5 12
```

Escribir un registro de solicitudes por pregunta solo de adición:

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl
```

Ejecutar múltiples modelos locales de forma interactiva:

```bash
uv run run_benchmark.py interactive ollama --profile standard
```

Perfiles soportados:

| Perfil | Propósito |
| --- | --- |
| `quick` | Subconjunto de prueba de API y pipeline de 16 preguntas L1/L2; no es un proxy de clasificación |
| `standard` | Benchmark completo de 60 preguntas v2 |

## Puntuación

La puntuación en tiempo de ejecución es siempre `rubric`. Es determinista y no requiere un juez LLM externo. El puntaje de tiempo de ejecución es cobertura léxica, no una prueba semántica de corrección técnica. El comparador rechaza negaciones explícitas y declaraciones marcadas como falsas, soporta variantes aceptadas a nivel de criterio y registra evidencia coincidente para auditoría.

La puntuación en tiempo de ejecución no soporta modos heredados `keyword`, `semantic` o `hybrid`. Use el comando `judge` sin conexión para auditoría posterior LLM como Juez.

## Juez LLM sin conexión

Los archivos JSON de resultados v2 guardados pueden ser auditados posteriormente sin volver a ejecutar los modelos del benchmark:

```bash
OPENROUTER_API_KEY=... uv run run_benchmark.py judge \
  --results "results_*_v2/*.json" \
  --dataset datasets/v2/benchmark.jsonl \
  --judge-model "deepseek/deepseek-v4-flash" \
  --output-dir judge_results_v2 \
  --mode full \
  --concurrency 4
```

El comando judge escribe `per_model/*.json`, `detailed.csv`, `summary.csv` y `disputed_cases.csv`. El modo completo produce un `judge_adjusted_score` comparable y denominadores explícitos. `disputed` sigue siendo un modo de diagnóstico de ahorro de costos y no publica un total parcialmente ajustado. También audita una muestra determinista del 20% de los IDs de preguntas de alto puntaje en cada modelo; ajuste esto con `--audit-sample-rate`. El juez evalúa las respuestas sin ver el puntaje determinista, luego el post-procesamiento compara ambos resultados.

## Configuración

Copie `config.example.yaml` a `config.yaml` y ajústelo:

```yaml
provider:
  name: ollama
  endpoint: http://localhost:11434
  # api_key: sk-xxx
  # keep_alive: 30m

scoring:
  method: rubric

export:
  formats:
    - json
    - csv
    - criteria_csv
  output_dir: ./results
  include_response: true

questions_file: datasets/v2/benchmark.jsonl
answers_file: answers_all.txt
rate_limit_delay: 1.5
max_tokens: 1024
temperature: 0.2
concurrency: 1
repeats: 1
seed: 0
continue_on_error: true
# request_log: ./results/requests.jsonl
```

Ejecutar con configuración:

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml
```

## Salida

La exportación JSON incluye resultados del modelo, evidencia de rúbrica por pregunta, resumen agregado y proveniencia de auditoría:

```json
{
  "model": "llama3.1:8b",
  "scoring_method": "rubric",
  "total_score": 75.0,
  "interpretation": "requires-validation",
  "benchmark_version": "2.3.0",
  "dataset_id": "redteam-ai-benchmark-v2",
  "dataset_version": "2.1.0",
  "dataset_hash": "...",
  "scorer_version": "rubric-v2.1.0",
  "config_hash": "...",
  "evaluation_fingerprint": "...",
  "run_config": {
    "provider": "ollama",
    "model": "llama3.1:8b",
    "profile": "standard",
    "repeats": 1,
    "seed": 0
  },
  "git_commit": "...",
  "package_version": "2.3.0",
  "runtime_profile": "standard",
  "summary": {
    "metrics": {
      "refusal_rate": 0.0,
      "critical_error_rate": 0.0
    },
    "breakdown": {
      "difficulty": {},
      "domain": {},
      "capability": {}
    }
  }
}
```

Cada fila de resultado incluye estado de solicitud, identidad de repetición/ejecución, semilla, motivo de finalización, uso, modelo real y metadatos de proveedor disponibles. La proveniencia de nivel superior agrega información del entorno y una razón explícita cuando no está disponible una revisión de modelo inmutable. La salida CSV contiene filas por pregunta más una fila `TOTAL`. `criteria_csv` agrega una fila por criterio de rúbrica aprobado o fallido.

Los errores de solicitud se conservan como filas estructuradas y hacen que la ejecución sea `incomplete`. Use `--fail-fast` o `continue_on_error: false` para abortar en el primer error.

## Optimización de Prompts

La optimización de prompts sigue siendo opcional y separada de la puntuación del modelo base. Solo se ejecuta para respuestas clasificadas como censuradas. Las respuestas de referencia y el puntaje principal nunca se reemplazan; las respuestas optimizadas se escriben en `optimized_prompts_{model}_{timestamp}.json` con resultados de referencia y optimizados separados. Su resumen reporta `refusal_recovery_rate` sobre las respuestas censuradas enviadas al optimizador.

```bash
uv run run_benchmark.py run ollama -m "llama3.1:8b" \
  --optimize-prompts \
  --optimizer-model "llama3.3:70b"
```

No mezcle puntajes optimizados con comparaciones de capacidad del modelo base.

## Limitaciones Conocidas

- La puntuación determinista mide la cobertura de rúbrica léxica. Use una pasada completa del juez sin conexión y revisión manual para afirmaciones de precisión técnica.
- El conjunto de datos público puede memorizarse. Trátelo como un benchmark de desarrollo; la evaluación de alto riesgo debe agregar un conjunto de exclusión privado o rotativo.
- Cada capacidad actual tiene una pregunta única. Las repeticiones miden la varianza de generación, no la validez de capacidad de múltiples ítems; los desgloses exponen esto como `single-item` o `single-item-repeated`.
- Los metadatos del proveedor difieren. Las revisiones inmutables faltantes se registran como no disponibles en lugar de inferirse.

## Validación

Verificaciones útiles:

```bash
uv run run_benchmark.py --help
uv run run_benchmark.py run --help
uv lock --check
uv run ruff check .
uv run pytest -q
uv run python -m compileall -q run_benchmark.py benchmark models optimization scoring tracing utils
```

## Contribuciones

Vea [CONTRIBUTING.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/CONTRIBUTING.md), [CODE_OF_CONDUCT.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/CODE_OF_CONDUCT.md) y [SECURITY.md](https://gitlab.com/toxy4ny/redteam-ai-benchmark/-/blob/main/SECURITY.md).

## Licencia

MIT. Úselo en laboratorios de red team autorizados, evaluaciones de seguridad comerciales, investigación de seguridad de IA y entornos educativos.
Descargar herramienta