io.github.26zl/cybersec-toolkit

    /\   /\        ______      __              _____
   (o ) ( o)      / ____/_  __/ /_  ___  _____/ ___/___  _____
    \ \_/ /      / /   / / / / __ \/ _ \/ ___/\__ \/ _ \/ ___/
  <==\   /==>   / /___/ /_/ / /_/ /  __/ /   ___/ /  __/ /__
     \ V /      \____/\__, /_.___/\___/_/   /____/\___/\___/
     /_ _\           /____/                          by 26zl
      |_|                     Toolkit

Kit de herramientas de ciberseguridad con integración de IA incorporada. Un servidor MCP (Model Context Protocol) integrado permite a los clientes compatibles con MCP consultar el registro de herramientas, comprobar el estado de instalación, recomendar herramientas para una categoría de CTF o un objetivo de bug bounty y ejecutar las herramientas instaladas a través de una ruta de ejecución gobernada. Ir a Servidor MCP (integración de IA).

Incluye un instalador modular para Linux y Termux (Android) que cubre 670+ herramientas, 18 módulos, 14 perfiles y 12 métodos de instalación.

Qué lo hace diferente: la mayoría de los kits se limitan a instalar herramientas. Aquí una IA también puede manejarlas: inferir el tipo de problema, elegir las herramientas adecuadas de todos los módulos/perfiles y trabajar contigo como compañero interactivo. Cuando lo autorizas explícitamente, la misma cadena de herramientas MCP puede entrar en un bucle autónomo de resolución. Compañero por defecto; autónomo solo cuando lo pides.

Funciona con

Consulta docs/AI_CLIENTS.md para la configuración detallada por cliente y docs/ORCHESTRATION.md para coordinar múltiples agentes en cualquier cliente MCP.

Cómo funciona

Dos puntos de entrada comparten un único registro de herramientas. Un operador ejecuta el instalador bash para instalar las herramientas en el disco; un agente de IA se comunica con el servidor MCP para descubrir, recomendar y ejecutar esas mismas herramientas a través de su ruta de herramientas gobernada. tools_config.json es la fuente única de verdad que definen los módulos y que leen los asesores MCP, y los validadores de CI mantienen sincronizadas las partes de Python y bash.

Fuente de Mermaid: assets/how-it-works.mmd.

Lectura del diagrama: las flechas sólidas son acciones de ejecución o instalación; las flechas discontinuas son relaciones de validación y contexto. Las configuraciones de los clientes entran a través del lanzador con detección de root antes de llegar a FastMCP. security.py gobierna run_tool y run_pipeline mediante la lista blanca, las comprobaciones de argumentos y la política de red sin invocar un shell. run_script sigue siendo una capacidad separada de ejecución de código completo, deshabilitada por defecto. Las Agent Skills permanecen fuera de la ruta de ejecución: .claude/skills/ es la canónica y scripts/sync-skills.sh genera .agents/skills/ para los clientes que usan el espejo portátil.

Related MCP server: Enterprise MCP Gateway and Tool Registry

¿Por qué no simplemente Kali (u otro instalador)?

Kali/Parrot/BlackArch incluyen las herramientas; esto es complementario, no un sustituto. Se ejecuta en el equipo que ya tienes (incluido Termux) y añade un plano de control de IA que puede descubrir, recomendar, encadenar y ejecutar las herramientas instaladas a través de una única interfaz gobernada. ¿Quieres todas las herramientas? Una distro es suficiente. ¿Quieres un cliente MCP que pueda seleccionarlas y ejecutarlas bajo una política explícita? Ese es el vacío que cubre.

Confianza y seguridad

Los usuarios de seguridad deberían ser paranoicos: esto es exactamente lo que se ejecuta y lo que está restringido:

• MCP seguro por defecto. De serie, CYBERSEC_MCP_ALLOW_EXTERNAL=0 rechaza los objetivos de red que no se resuelven a rangos privados/de bucle local, y CYBERSEC_MCP_ALLOW_SCRIPTS=0 deshabilita run_script. Tú decides explícitamente habilitar los ámbitos externos / scripting.

• La ejecución de herramientas gobernada pasa por una única puerta (mcp_server/security.py): lista blanca del registro, sin shell (create_subprocess_exec, nunca shell=True), saneamiento de argumentos, una lista negra de banderas bloqueadas por herramienta (p. ej. sqlmap --os-shell, nmap -iL, banderas de lista de archivos/inyección de objetivos), política de objetivos/red, limitación de velocidad, límites de salida y tiempos de espera.

• La política de ejecución no es un sandbox del sistema operativo. Las herramientas permitidas se ejecutan con los permisos del usuario del proceso MCP, y algunas herramientas de seguridad pueden lanzar procesos secundarios o cargar plugins. Deshabilitar run_script solo deshabilita ese endpoint; ejecuta el servidor MCP como un usuario con privilegios mínimos o dentro de un límite de aislamiento adecuado para objetivos no confiables.

• La política con conocimiento de herramientas no es una solución codificada. El solucionador elige las herramientas del registro/asesores; la capa de política solo entiende la gramática CLI suficiente para distinguir un objetivo real de un encabezado, una wordlist, una ruta de salida, un archivo de configuración o una bandera de lista de objetivos. Eso mantiene los comandos normales utilizables sin permitir que las banderas de lista de archivos/configuración omitan las comprobaciones de alcance.

• Registro de auditoría, no fugas. Las acciones se registran como JSON en un log rotativo solo para el propietario (0600) en el directorio de estado del usuario (~/.local/state/cybersec-tools-mcp/audit.log por defecto). Los cuerpos de los scripts nunca se persisten: solo se registran un SHA256 irreversible y la longitud para su correlación, y las cadenas con forma de credencial se enmascaran en los argumentos de las herramientas.

• Privilegio mínimo en el instalador. Se ejecuta como root, pero se rebaja al usuario que lo invoca ($SUDO_USER) para las compilaciones de repositorios clonados y las instalaciones con pip/cargo/gem; las versiones binarias se verifican con SHA256 cuando se publican sumas de comprobación.

• Las herramientas de doble uso están restringidas. Los frameworks de C2 y phishing (Sliver, Caldera, gophish, evilginx, …) están desactivados por defecto y solo se instalan con --include-c2 (los perfiles redteam/full); la capa MCP refleja esto y nunca los ejecuta automáticamente.

• Solo uso autorizado. Consulta SECURITY.md, el Modelo de cadena de suministro y el Aviso legal.

Instalación

Todos los runtimes necesarios (Python, Go, Ruby, Java, Rust, Node.js), las bibliotecas de desarrollo, pipx y las herramientas de compilación se instalan automáticamente. El único requisito previo es una distro de Linux compatible. Windows y macOS no son compatibles (usa WSL o Docker).

Docker es la única excepción: instálalo manualmente si quieres frameworks C2, MobSF, BeEF, BloodHound, TheHive o Cortex (--enable-docker). Consulta la documentación de instalación de Docker. Se recomienda la autenticación de GitHub. El instalador descarga ~30 versiones binarias y realiza ~30+ llamadas a la API de GitHub. Sin autenticación, estás limitado a 60 solicitudes/hora y algunas descargas pueden fallar. Con autenticación, el límite es de 5.000/hora. La forma más sencilla:

# Install gh CLI and log in (one-time) — the installer auto-detects it
sudo apt install gh && gh auth login

Alternativamente, exporta un token de acceso personal (no se necesitan ámbitos):

export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

Desde la última versión (fijada y estable, recomendada):

# Newest tag is on the Releases page: https://github.com/26zl/cybersec-toolkit/releases
git clone --depth 1 --branch v1.1.0 https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit && sudo ./install.sh

Desde main (herramientas más recientes, correcciones y cambios; puede incluir trabajo no publicado):

git clone https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit && sudo ./install.sh

Eso instala las herramientas estándar de los 18 módulos. Las herramientas de C2/phishing y las imágenes de Docker siguen siendo opcionales; usa --profile full --enable-docker cuando quieras explícitamente el registro completo compatible con la plataforma actual. Para instalar un subconjunto:

sudo ./install.sh --profile ctf                      # CTF tools only
sudo ./install.sh --profile redteam --enable-docker   # Red team + Docker C2
sudo ./install.sh --module web --module recon          # Specific modules
sudo ./install.sh --tool sqlmap --tool nmap            # Individual tools
sudo ./install.sh --dry-run --profile ctf              # Preview without installing

¿No estás seguro de que la máquina está lista? Ejecuta primero una comprobación previa de solo lectura: no necesita root y no instala nada:

./install.sh --doctor                                  # Distro, prerequisites, MCP server, tool registry

Probar con Docker

Descarga la imagen precompilada (sin compilación local):

docker run --rm ghcr.io/26zl/cybersec-toolkit --profile ctf

O compílala tú mismo:

docker build -t cybersec-toolkit .
docker run --rm cybersec-toolkit --profile ctf

Podman funciona como sustituto directo: cambia docker por podman (o alias docker=podman); se admiten compilaciones y ejecuciones sin root. Para el ejemplo de Compose que aparece a continuación, usa podman compose (necesita un proveedor de compose instalado).

O usa el archivo Compose incluido (compila y ejecuta el servicio installer):

docker compose run --rm installer --profile ctf

La imagen concede al usuario toolkit acceso sudo sin contraseña para que el instalador pueda gestionar los paquetes del sistema. Trata el código dentro del contenedor como capaz de actuar como root; la imagen no es un sandbox de seguridad, especialmente cuando run_script está habilitado o se montan rutas sensibles del host.

macOS (Apple Silicon): añade --platform linux/amd64 a ambos comandos para ejecutarlo mediante emulación x86:

docker build --platform linux/amd64 -t cybersec-toolkit .
docker run --rm --platform linux/amd64 cybersec-toolkit --profile ctf

Termux (Android):

pkg install git
git clone https://github.com/26zl/cybersec-toolkit.git
cd cybersec-toolkit
./install.sh --profile lightweight

sudo ./install.sh --help                # Full help
sudo ./install.sh --list-profiles       # Show profiles
sudo ./install.sh --list-modules        # Show modules
sudo ./install.sh --skip-heavy          # Skip large/slow packages
sudo ./install.sh --skip-pipx           # Skip all pipx (Python) installs
sudo ./install.sh --skip-go             # Skip all Go tool installs
sudo ./install.sh --skip-cargo          # Skip all Cargo (Rust) installs
sudo ./install.sh --skip-gems           # Skip all Ruby gem installs
sudo ./install.sh --skip-git            # Skip all git clone installs
sudo ./install.sh --skip-binary         # Skip all binary release downloads
sudo ./install.sh --skip-source         # Skip build-from-source, snap, npm, and curl-pipe installs
sudo ./install.sh --fast                # Skip checksum verification (see Security note below)
sudo ./install.sh --require-checksums   # Fail if binary release has no checksum file
sudo ./install.sh --production          # Strict checksum preset for release downloads
sudo ./install.sh --upgrade-system      # Upgrade system packages before installing
sudo ./install.sh --list-sessions       # List install sessions and exit
sudo ./install.sh --rollback <id|last>  # Rollback tools installed in a session
sudo ./install.sh --version             # Show installer version and exit
sudo ./install.sh --enable-docker       # Pull Docker images
sudo ./install.sh --include-c2          # Include C2 frameworks (needs --enable-docker)
sudo ./install.sh -j 8                  # 8 parallel install jobs (default: 4)
sudo ./install.sh -v                    # Verbose / debug output

--tool instala solo la herramienta especificada sin ejecutar la configuración completa de dependencias. Las estimaciones de tiempo de la prueba en seco cuentan las entradas de instalación entre métodos, por lo que la estimación puede ser mayor que el registro de 670+ herramientas sin duplicados.

El instalador orquesta 670+ herramientas en 12 métodos de instalación diferentes. El tiempo se emplea en operaciones limitadas por E/S que ningún lenguaje de scripting puede acelerar:

Para ver el recuento actual de herramientas por método, ejecuta ./install.sh --dry-run: imprime el desglose en vivo para que las cifras no queden desactualizadas aquí. Las etapas más lentas son las que compilan o desempaquetan más (apt/dnf y Go), no el recuento bruto de herramientas: Cargo compila desde el código fuente, pero solo cubre unas pocas herramientas.

El instalador ya paraleliza cuando es posible (-j 4 por defecto). Los métodos con bloqueos compartidos (apt, pipx, cargo) deben ejecutarse secuencialmente. Para reducir el tiempo de instalación:

• Usa --profile lightweight o --module <nombre> para instalar solo lo que necesites

• Usa --skip-cargo para omitir la compilación de Rust (el método más lento por herramienta)

• Aumenta el paralelismo con -j 8 para descargas más rápidas de Go/git/binarios

• Configura un proxy apt-cacher-ng para instalaciones repetidas

Perfiles

Módulos

Métodos de instalación

Scripts de post-instalación

Todos los scripts requieren root en Linux (sudo) y admiten --help. En Termux, no se necesita root.

--deep-clean elimina la caché de módulos/compilación de Go, el registro de Cargo, las cachés de pip/pipx/npm/gem, los venvs huérfanos de pipx, los enlaces simbólicos obsoletos y los archivos de registro. Añade --remove-deps para purgar también los toolchains de Rustup.

Servidor MCP (Integración con IA)

MCP (Model Context Protocol) es un estándar abierto que permite a los asistentes de IA usar herramientas externas. Este proyecto incluye un servidor MCP que da a cualquier IA compatible con MCP (Claude Code, Claude Desktop, Cursor, etc.) acceso de lectura completo al registro de más de 670 herramientas, además de la capacidad de comprobar instalaciones, recomendar perfiles y ejecutar herramientas. La IA se convierte en un socio interactivo para el hacking ético: conoce todas las herramientas, cuáles tienes instaladas y puede ejecutarlas por ti.

Lo que la IA puede hacer

El cliente MCP puede consultar cada herramienta y su estado de instalación, encadenar llamadas de herramientas gobernadas, analizar la salida y orientarse sobre lo que encuentra. La ejecución de scripts requiere un opt-in por separado.

Reconocimiento externo → superficie de ataque (requiere CYBERSEC_MCP_ALLOW_EXTERNAL=1, solo con alcance autorizado)

• "Enumera la superficie de ataque de target.com y marca cualquier cosa explotable" — despliega amass / subfinder → resuelve y sondea con httpx → identifica la huella con whatweb → ejecuta plantillas de nuclei → descubrimiento de contenido con ffuf, y luego prioriza los hosts por exposición y propone siguientes pasos

• "Encontré un open redirect en /go?url= — conviértelo en un arma" — verifica con curl, luego construye un PoC de SSRF / robo de token de OAuth y busca un callback explotable

Explotación web

• "Confirma y explota el SQLi en el endpoint de login" — sqlmap para confirmar y volcar (los flags destructivos --os-shell/--os-cmd están bloqueados por política), después run_script para automatizar el bypass de autenticación y extraer solo lo necesario para un PoC

• "La introspección de GraphQL está activada — mapéala y busca IDOR" — obtiene el esquema, genera queries, fuzzee los IDs de objeto y compara respuestas autenticadas vs no autenticadas

Active Directory / interno

• "Credenciales de bajo privilegio en 10.10.0.0/24 — busca un camino hasta Domain Admin" — obtiene datos con bloodhound, hace kerberoast con impacket (GetUserSPNs.py), crackea el TGS con hashcat y valida el movimiento lateral con netexec — todo en la VM Kali por SSH

• "Comprueba los derechos de DCSync y vuelca credenciales si existe el camino" — enumera las ACLs de replicación y luego ejecuta secretsdump.py contra el DC

Explotación de binarios e ingeniería inversa

• "Construye un exploit ret2libc para este binario de 64 bits" — analiza con checksec / readelf, encuentra gadgets con ROPgadget, filtra libc mediante una llamada a puts@plt, luego escribe la cadena completa pwntools en venv="pwntools" y obtiene un shell local

• "Recupera el algoritmo de este binario stripado" — tuberías el desensamblaje de objdump / radare2 hacia el análisis dirigido, con una reimplementación en run_script para verificar el comportamiento

Criptografía

• "Rompé este RSA — e pequeño, varios ciphertexts" — detecta el ataque (Håstad / módulo común / Wiener) y lo resuelve con pycryptodome + sympy en un venv, devolviendo el plaintext

• "Este JWT es HS256 con clave débil" — crackear el secreto de firma y forja un token de admin

Equipo azul · detección y respuesta

• "Escribe una regla Sigma para esta técnica y conviértela a mi SIEM" — redacta la regla y la emite para el backend de destino (Splunk / Elastic) vía sigma-cli

• "Busca movimiento lateral en estos eventos de archivo de Windows" — ejecuta chainsaw sobre los EVTX con reglas Sigma y resume los hits por host y línea temporal

• "Crea reglas YARA a partir de estas muestras y escanea el árbol" — genera firmas yara y las ejecuta recursivamente

DFIR · triaje de malware

• "Línea temporal de este volcado de memoria" — recorre los plugins de volatility3 (pslist, netscan, malfind) y los encadena en una sola narrativa

• "Busca balizas de C2 en este pcap" — extracción con tshark / tcpdump → reglas de suricata → marca callbacks periódicos

• "Haz triaje estático de este archivo sospechoso" — file → strings → capa / yara, y extrae IOCs para enriquecimiento

Nube · contenedores · operaciones

• "Audita esta cuenta AWS por un S3 público y IAM de riesgo" — ejecuta prowler / scoutsuite y saca a la luz solo los hallazgos de gravedad alta

• "Scan tactic de esta imagen y los manifies de k8s antes del deploy" — escaneo de imagen con grype y cheques de configuración con kubescape

• "¿Cuál es mi cobertura de redteam? — y corrige las brechas" — compara get_profile_tools("redteam") contra el estado de instalación y emite los comandos exactos de instalación

Móvil · inalámbrico · blockchain

• "Analiza estáticamente este APK en busca de secretos y almacenamiento inseguro" — descompila apktool / jadx → chequeos estilo MobSF, y luego greps de claves y endpoints

• "Audita esta captura de Wi-Fi" — analiza el handshake y ejecuta aircrack-ng / hashcat contra él

• "Revisa este contrato Solidity en busca de reentrancy completo" — ejecuta slither / mythril y explica los hallazgos

run_tool y run_pipeline están saneados de argumentos, con política de red, límite de tasa y registro de auditoría. run_script está desactivado por defecto porque activarlo es un opt-in de ejecución de código total con los permisos de sistema de archivos y red del usuario del servidor MCP; la política de objetos externos no pone los scripts en sandbox. Flags destructivos (--os-shell, -rf, --exploit, …) están bloqueados en el ruta gobernada de herramientas. Úsalo solo contra sistemas que estés autorizado a probar.

Inicio rápido

Requiere uv. Claude Code puede usar directamente el .mcp.json del proyecto. Ejecuta el servidor MCP por stdio con scripts y destinos externos de red desactivados por defecto:

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "uv",
      "args": ["run", "--directory", "mcp_server", "fastmcp", "run", "server.py", "--transport", "stdio", "--no-banner"],
      "env": {
        "CYBERSEC_MCP_ALLOW_EXTERNAL": "0",
        "CYBERSEC_MCP_ALLOW_SCRIPTS": "0"
      }
    }
  }
}

Reinicia Claude Code. Las 15 herramientas aparecen en /mcp.

Otros clientes MCP (Codex, Cursor, LLMs locales)

MCP es un estándar abierto, así que el mismo servidor stdio funciona con cualquier cliente compatible con MCP. Desde la raíz del repositorio, el comando de litio es:

uv run --directory mcp_server fastmcp run server.py --transport stdio --no-banner

--directory mcp_server es relativo al directorio de trabajo. Si un cliente puede iniciar el servidor desde un subdirectorio, usa el lanzador que conoce la raíz desde el raíz del repositorio:

bash scripts/mcp-launch.sh

Desde fuera del repositorio, usa la ruta absoluta del lanzador:

bash /path/to/cybersec-toolkit/scripts/mcp-launch.sh

• Codex — se incluye un .codex/config.toml de proyecto (resuelve la raíz de Git primero para que funcione desde cualquier subdirectorio). La configuración principal de Codex es ~/.codex/config.toml; si el archivo del proyecto no se detecta, copia el bloque [mcp_servers.cybersec-tools] en tu configuración de usuario.

• Cursor / Continue / Cline / Goose — añade el mismo comando de lanzamiento en la interfaz de configuración de MCP del cliente o en su archivo de configuración (usa una ruta absoluta si el directorio de trabajo del cliente no es la raíz del repositorio).

• LM Studio (≥0.3.17) — LM Studio es en sí mismo un host de MCP, no se necesita puente. Añade el servidor a su mcp.json (notación de Cursor, misma forma de mcpServers que .mcp.json) usando una ruta absoluta o el envoltorio de la raíz de Git, ya que el directorio de trabajo de LM Studio no es la raíz del repositorio. Usar MCP a través de la API de LM Studio requiere ≥0.4.0 y un endpoint compatible con MCP, como /api/v1/chat o /v1/responses.

• Ollama — Ollama es un tiempo de ejecución de modelos, no un host de MCP. Coloca un agente compatible con MCP delante de él (p. ej., Kit) y apúntalo al comando de lanzamiento anterior.

• Otros LLM locales — un modelo desnudo no habla MCP por sí solo. Ejecútalo detrás de cualquier host compatible con MCP (LM Studio, Cline, Continue, Goose, Kit u Open WebUI mediante un puente MCP→OpenAPI como mcpo) y apunta ese host al comando de lanzamiento anterior.

Nota de seguridad: empieza solo con este servidor. Ya aplica saneamiento de argumentos, listas blancas de red, limitación de velocidad y registro de auditoría, y viene con la ejecución de scripts y los destinos externos deshabilitados por defecto; mantenlos desactivados a menos que tengas un alcance autorizado, y prefiere hosts que admitan la aprobación de herramientas con intervención humana.

Las instrucciones del repositorio independientes del proveedor están en AGENTS.md (leído de forma nativa por Codex y muchas herramientas de agentes); Claude Code lee CLAUDE.md.

Conectarse desde WSL (p. ej., Kali Linux)

El servidor MCP se ejecuta sobre stdio, por lo que funciona desde cualquier entorno que Claude Code pueda lanzar. Para usar herramientas instaladas dentro de WSL:

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "wsl",
      "args": [
        "-d", "kali-linux",
        "bash", "-lc",
        "cd /path/to/cybersec-toolkit/mcp_server && uv run fastmcp run server.py --transport stdio --no-banner"
      ]
    }
  }
}

Conectarse desde Docker

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "CYBERSEC_MCP_ALLOW_EXTERNAL=0", "-e", "CYBERSEC_MCP_ALLOW_SCRIPTS=0",
        "--entrypoint", "bash", "cybersec-toolkit",
        "-c",
        "cd /opt/cybersec-toolkit/mcp_server && uv run fastmcp run server.py --transport stdio --no-banner"
      ]
    }
  }
}

Ejecución de scripts

run_script permite a la IA escribir y ejecutar scripts de Python o Bash. Requiere CYBERSEC_MCP_ALLOW_SCRIPTS=1, no está aislado por el sistema operativo y no está limitado por CYBERSEC_MCP_ALLOW_EXTERNAL. Habilitarlo otorga a los scripts los mismos permisos de sistema de archivos y red que al proceso del servidor MCP. Revisa el código generado y el alcance antes de activarlo:

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "uv",
      "args": ["run", "--directory", "mcp_server", "fastmcp", "run", "server.py", "--transport", "stdio", "--no-banner"],
      "env": {
        "CYBERSEC_MCP_ALLOW_SCRIPTS": "1",
        "CYBERSEC_MCP_ALLOW_EXTERNAL": "0"
      }
    }
  }
}

Soporte de entornos virtuales

Algunos paquetes (p. ej., pwntools) requieren una versión anterior de Python. El parámetro venv permite a la IA elegir el intérprete adecuado para cada script:

# One-time setup: create a venv with pwntools
python3.12 -m venv ~/.ctf-venvs/pwntools
~/.ctf-venvs/pwntools/bin/pip install pwntools z3-solver

La IA usa entonces run_script("from pwn import *; ...", venv="pwntools") automáticamente. El entorno MCP predeterminado contiene FastMCP y la biblioteca estándar de Python. Instala el conjunto de ayudas opcional con cd mcp_server && uv sync --extra ctf-core antes de usar requests, pycryptodome, beautifuls4, Pillow o NumPy sin un venv con nombre. Establece CYBERSEC_MCP_VENVS_DIR para sobrescribir la ubicación predeterminada ~/.ctf-venvs/.

Scripts manuales

El directorio manual_scripts/ almacena scripts persistentes que la IA crea para el usuario: exploits complejos, solucionadores de varios pasos, analizadores, ayudas de protocolo y herramientas reutilizables que no deberían desaparecer tras una sola ejecución. En el modo de acompañamiento, la IA propone el script y solo lo escribe y ejecuta tras la aprobación o un "continúa" claro. En el modo autonomous opcional, si las herramientas y canalizaciones normales dejan de progresar y la lógica de programación es la vía fiable más pequeña, la IA puede escribir, guardar y ejecutar ayudas acotadas mediante run_script. Los comandos simples de reconocimiento/HTTP como curl siguen siendo llamadas a run_tool; los scripts son para lógica que las herramientas no pueden expresar limpiamente.

Probar el servidor

cd mcp_server && uv run fastmcp dev server.py

Esto abre un MCP Inspector basado en web para probar interactivamente cada herramienta.

Consulta mcp_server/README.md para la configuración de Claude Desktop y la documentación completa.

Se buscan colaboraciones

Este proyecto es grande por diseño, y la ayuda de la comunidad es muy bienvenida.

Las contribuciones útiles incluyen probar instalaciones en diferentes distribuciones, añadir herramientas que falten, corregir asignaciones de paquetes, mejorar los flujos de trabajo de MCP, escribir casos de uso de ejemplo, perfeccionar la documentación e informar de los bordes ásperos de flujos de trabajo reales de CTF, laboratorio, bug bounty, pentest, DFIR o defensivos.

Abre un issue para cambios más grandes o envía un PR centrado para correcciones pequeñas. Consulta CONTRIBUTING.md para la lista de verificación de validación.

Desarrollo

La documentación pública para colaboradores está en CONTRIBUTING.md. El inicio rápido es:

git clone https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit
make setup    # submodules + MCP deps + skill mirror (Codex-ready)
make check    # core local checks — shellcheck, validators, bats, ruff, pytest

make help enumera todos los atajos (lint, test, validate, curate, sync-skills, check-skills, mcp, docker, …); el comando sin procesar que ejecuta cada objetivo está en CLAUDE.md / AGENTS.md.

El proyecto MCP de Python usa uv con [tool.uv] exclude-newer = "3 days". Las nuevas resoluciones de dependencias ignoran intencionadamente los paquetes subidos en las últimas 72 horas para reducir la confusión de dependencias y el radio de explosión de versiones comprometidas. Dependabot usa el mismo período de espera de 3 días, y el flujo de trabajo semanal de actualización de uv hereda la misma política.

Esta política de antigüedad de versiones se limita a las dependencias de arranque/ejecución del proyecto solo: paquetes MCP de Python, acciones de CI y entradas de compilación de Docker necesarias para poner el proyecto en marcha. No retrasa ni fija las herramientas de ciberseguridad instaladas desde el registro; esas herramientas siguen intencionadamente su instalador de módulos y flujo de actualización para que los operadores puedan obtener escáneres, exploits, firmas y utilidades de investigación actuales.

Ejecuta las pruebas de shell en Linux o WSL. Los checkouts nativos de Windows pueden reescribir los submódulos Bats incluidos con CRLF y provocar fallos de $'\r'.

Habilidades del agente

Este repositorio incluye 872 habilidades de agente bajo el árbol fuente canónico .claude/skills/. Claude Code descubre ese árbol directamente; scripts/sync-skills.sh genera el espejo portátil .agents/skills/ para clientes compatibles. Las habilidades se activan bajo demanda según la tarea: no consumen contexto de forma permanente. De ellas, 31 están creadas por el proyecto y 841 están seleccionadas de proyectos de código abierto, cada una atribuida a continuación y en THIRD_PARTY_NOTICES.md.

• 10 habilidades de desarrollador específicas del proyecto (add-tool, validate-all, module-scaffold, writeup-template, mcp-sync-check, security-wordlists, security-payloads, guided-assessment, skill-dependency-audit, skill-curation-router)

• 4 coordinadores entre habilidades (finding-triage, security-comms, authorization-gate, evidence-hygiene) a través de los cuales otras habilidades enrutan hallazgos, comunicación, comprobaciones de autorización y saneamiento de evidencia

• 7 habilidades ancla de brechas de cobertura (GRC/privacidad, seguridad de IA/LLM, IoT/empotrado/hardware, mainframe, telecomunicaciones/5G, SAP/ERP, seguridad de cadena de suministro/producto)

• 1 habilidad de flujo de trabajo de agente de codificación de multica-ai/andrej-karpathy-skills (MIT)

• 6 habilidades de metodología CTF (ctf-crypto, ctf-pwn, ctf-web, ctf-rev, ctf-forensics, ctf-stego)

• 4 habilidades de metodología de bug bounty (bounty-recon, bounty-web, bounty-api, bounty-mobile)

• 10 habilidades de flujo de trabajo de bug bounty de BugHunter (claude-bug-bounty) (MIT)

• 58 habilidades de metodología ofensiva de SnailSploit Claude-Red (MIT)

• 14 habilidades de auditoría de código de Trail of Bits (CC-BY-SA 4.0)

• 754 guías operativas de la comunidad mukul975/Anthropic-Cybersecurity-Skills (Apache 2.0)

• 4 flujos de trabajo de alto nivel de Transilience (MIT)

Índice de fuentes y categorías en .claude/skills/SKILLS.md.

Instalar como plugin de Claude Code

El repositorio funciona también como mercado de plugins (.claude-plugin/), por lo que puedes incorporar toda la biblioteca de habilidades a cualquier proyecto sin clonar manualmente:

/plugin marketplace add 26zl/cybersec-toolkit
/plugin install cybersec-toolkit@cybersec-toolkit

El plugin expone las habilidades en .claude/skills/ (declaradas mediante el campo skills en .claude-plugin/plugin.json). El servidor MCP se configura por separado mediante .mcp.json; consulta Servidor MCP.

Usar estas habilidades en clientes compatibles

Las habilidades de agente son Markdown más archivos auxiliares opcionales, pero el descubrimiento y la activación son funciones del cliente, no de MCP. Claude Code, OpenCode, Codex, Gemini CLI, GitHub Copilot, Cursor, Cline, Goose, Hermes y OpenClaw admiten habilidades de agente a través de diferentes rutas o ajustes. scripts/sync-skills.sh refleja el origen .claude/skills/ del repositorio en .agents/skills/ para los clientes que usan esa ubicación:

scripts/sync-skills.sh            # mirror .claude/skills/ -> .agents/skills/
scripts/sync-skills.sh --check    # report drift without writing (exit 1 if out of date)

make setup (consulta Desarrollo) ejecuta este paso de espejo por ti.

.claude/skills/ sigue siendo la única fuente de verdad; .agents/skills/ se genera y está en git-ignore, así que vuelve a ejecutar la sincronización después de editar una habilidad. Continue y LM Studio pueden usar el servidor MCP, pero ninguno de los dos clientes documenta actualmente el descubrimiento automático de los archivos SKILL.md de este repositorio. Un índice independiente SKILLS.md solo sería contexto manual; no añadiría activación bajo demanda. Usa reglas/indicaciones de Continue o proporciona contenido de habilidad seleccionado como contexto en esos clientes. Consulta docs/AI_CLIENTS.md para las rutas y límites específicos del cliente.

scripts/validate_claude_skills.py comprueba los metadatos de las habilidades, los recuentos de índices, la frescura de la curación y la sintaxis de los scripts auxiliares para Python y PowerShell. Los scripts auxiliares de habilidades incluidos también pueden tener importaciones de Python opcionales específicas de la tarea. Esas importaciones se declaran en .claude/skills/requirements.txt, generado a partir del inventario de importaciones de los scripts auxiliares:

python3 scripts/audit_skill_dependencies.py --check-declared
python3 scripts/audit_skill_dependencies.py --write-requirements
python3 -m pip install -r .claude/skills/requirements.txt

La clasificación/curación de habilidades está en .claude/skills/CURATION.md y .claude/skills/curation.json. Regenérala con:

python3 scripts/curate_claude_skills.py --write

Ubicaciones de herramientas

Las herramientas que no son del sistema (pipx, Go, Cargo, git, versiones binarias) se instalan en /usr/local/bin/ en Linux y en $PREFIX/bin en Termux. Los paquetes del sistema van a su ubicación predeterminada (/usr/bin/).

Imágenes de Docker (opcional)

Solo se usa con --enable-docker. Si Docker no está instalado y se establece --enable-docker, el instalador sale con un error pidiéndote que instales Docker primero.

Soporte de distribuciones

Debian/Ubuntu/Kali es el objetivo principal: allí está disponible el registro completo de más de 670 paquetes y cuenta con la mayor cobertura de pruebas. Fedora/Arch/openSUSE tienen entre ~10 y 20 paquetes omitidos automáticamente (específicos de la distribución) y están cubiertos por el flujo de trabajo de integración. WSL y ARM son compatibles en la práctica, pero aún no tienen trabajos de CI dedicados. Windows y macOS se detectan y bloquean con un mensaje de error claro.

Modelo de cadena de suministro

Este instalador descarga y ejecuta código de Internet. En Linux se ejecuta como root (sudo); en Termux se ejecuta en el sandbox de usuario de la aplicación (sin root).

• Paquetes del sistema: firmados con GPG por los repositorios de tu distribución (apt, dnf, pacman, zypper, pkg)

• pipx/Go/Cargo/Gem/npm: descargas desde registros (sin verificación de firmas, pipx aislado en venvs)

• Lanzamientos binarios: verificados con SHA256 cuando el archivo de suma de verificación está disponible; falla de forma estricta si hay discrepancia. Usa --require-checksums o el ajuste predefinido --production para fallar también cuando no se publica un archivo de suma de verificación. Advertencia: --fast desactiva toda la verificación de sumas de verificación, incluidos los lanzamientos que sí publican sumas de verificación; no lo uses en producción ni en entornos de CI

• Dependencias Python de MCP: resueltas por uv con una ventana de exclude-newer de 3 días; Dependabot también espera 3 días antes de proponer PRs de dependencias. Esto no se aplica a las herramientas de seguridad instaladas

• SDK de Go: verificado con SHA256 contra los hashes publicados en go.dev cuando están disponibles; advierte si falla la API, falla de forma estricta con --require-checksums

• Repositorios Git: clonados en HEAD, las dependencias se instalan en venvs aislados (setup.py NO se ejecuta)

• Compilación desde el código fuente: ejecuta make (como root en Linux); revisa lo que estás compilando

• Compilación Docker del toolkit: las fuentes de Ubuntu y uv están fijadas por digest, mientras que los paquetes apt se resuelven desde los repositorios de Ubuntu firmados actuales; las recompilaciones no son reproducibles bit a bit

• Imágenes de herramientas opcionales: se extraen mediante etiquetas mutables en lugar de digests, incluidas varias etiquetas latest explícitas. --production no fija ni verifica estas imágenes

El archivo .versions registra qué se instaló y cuándo.

Limitaciones conocidas

La verificación de sumas de verificación es de mejor esfuerzo por defecto. Algunos lanzamientos upstream no publican sumas de verificación ni firmas, por lo que las descargas pueden continuar sin verificación criptográfica en esos casos. Usa --production (o --require-checksums) para fallar de forma estricta cuando no haya un archivo de suma de verificación disponible. Este ajuste predefinido no fija clones de Git, registros de paquetes de lenguajes ni herramientas compiladas desde el código fuente; esos siguen sus canales de lanzamiento upstream. Las descargas del SDK de Go se verifican con SHA256 contra go.dev cuando la API es accesible; el modo de suma de verificación estricta falla de forma estricta si no lo es.

--fast omite toda la verificación de sumas de verificación para lanzamientos binarios (tanto las comprobaciones SHA256 como la advertencia de suma de verificación faltante), incluidos los lanzamientos que sí publican sumas de verificación. Esto intercambia la verificación de integridad por velocidad. Es mutuamente excluyente con --require-checksums y --production. No uses --fast en canalizaciones de CI ni en entornos donde la integridad de la cadena de suministro sea importante.

Falsos positivos de Windows Defender

Si clonas este repositorio en una ruta montada de Windows (p. ej. C:\Users\<tu-usuario>\... o cualquier carpeta visible desde Windows mientras trabajas en WSL), Microsoft Defender y otros productos antivirus pueden poner en cuarentena archivos individuales. El contenido defensivo (tablas de referencia de IOC, PowerShell ofuscado de muestra, fragmentos de análisis de malware, cadenas de PoC de exploits dentro de .claude/skills/, writeups/ y partes de mcp_server/) contiene las mismas cadenas de bytes que usan los atacantes reales, por lo que los motores basados en firmas y ML pueden marcarlos. Las detecciones comunes incluyen Trojan:Script/Wacatac.B!ml, HackTool:* y veredictos genéricos Heur.*.

Estos son falsos positivos en el contexto de un toolkit de seguridad. Para trabajar con el repositorio en Windows tienes tres opciones:

1. Añade una exclusión de Defender para la carpeta del repositorio (recomendado para un equipo de desarrollo personal). Ejecuta desde PowerShell elevado:

   Add-MpPreference -ExclusionPath "C:\path\to\cybersec-toolkit"

2. Restaura archivos individuales desde la cuarentena mediante Seguridad de Windows -> Protección contra virus y amenazas -> Historial de protección -> "Permitir en el dispositivo". Es archivo por archivo, pero no evita la redetección al actualizar.

3. Mantén el repositorio dentro del sistema de archivos de WSL (p. ej. ~/cybersec-toolkit en tu distribución). Defender no escanea el vhdx de WSL2 por defecto, por lo que no se producen detecciones. scripts/sync-wsl.sh ya hace esto para el subdirectorio del servidor MCP.

Los archivos eliminados por Defender aparecerán como D en git status. El contenido se conserva en el historial de git; restáuralo con git checkout -- <ruta> una vez que la exclusión esté en su lugar.

Licencia

Licencia MIT: consulta LICENSE para más detalles.

Este repositorio también redistribuye componentes de terceros bajo sus propios términos, incluidos algunos bajo CC-BY-SA-4.0 (ShareAlike, no relicenciables a MIT). Si redistribuyes o adaptas contenido incluido, sigue esos términos: consulta THIRD_PARTY_NOTICES.md.

Para el flujo de trabajo de contribuciones y las expectativas de revisión, consulta CONTRIBUTING.md. Para las expectativas de comportamiento de la comunidad, consulta CODE_OF_CONDUCT.md. Para informar vulnerabilidades, consulta SECURITY.md.

Aviso legal

Este proyecto se proporciona únicamente para pruebas de seguridad educativas, defensivas y explícitamente autorizadas. Úsalo solo en sistemas que poseas o para los que tengas permiso por escrito para evaluar, y cumple todas las leyes aplicables, reglas de compromiso, licencias de herramientas de terceros y términos de servicio.

El toolkit incluye herramientas ofensivas y defensivas de doble uso. Algunos comandos pueden escanear redes, ejecutar exploits, modificar sistemas o activar alertas de seguridad. Las integraciones MCP/IA están protegidas por políticas de seguridad, pero los usuarios siguen siendo responsables de revisar el alcance, los prompts, los comandos y las salidas antes de ejecutar acciones.

Este repositorio no redistribuye las herramientas de seguridad en sí; instala proyectos de código abierto disponibles públicamente desde sus fuentes upstream oficiales en el momento de la instalación. Está destinado únicamente a un uso lícito y autorizado.

El proyecto se proporciona "tal cual", sin garantía. Los mantenedores no son responsables del mal uso, daños, pérdida de datos, interrupción del servicio o consecuencias legales derivadas del uso de este toolkit.

El contenido de terceros se incluye bajo su licencia original: consulta THIRD_PARTY_NOTICES.md.