Registro de despliegue de CyberStrikeAI: el detalle importa

Últimamente ando trasteando con CyberStrikeAI, una plataforma de pruebas de seguridad nativa de IA escrita en Go. Pensaba: «despliegue con un clic», clonas, corres el script y listo… y acabé topándome con unos cuantos baches ni grandes ni pequeños. Mientras la memoria está fresca, dejo todo el proceso anotado; muchos tropiezos no eran culpa de la herramienta, sino detalles descuidados.

Primero: qué es esta herramienta

CyberStrikeAI se define como un «sistema de acción de ciberseguridad nativo de IA», escrito en Go, que reúne planificación, ejecución, supervisión humana, conservación de evidencias y reproducción en un solo puesto de trabajo auditable. Sus componentes centrales incluyen un Agent impulsado por Eino, herramientas MCP nativas, una base de conocimiento RAG, flujos de trabajo visuales y modelado y análisis de cadenas de ataque.

Trae más de 100 recetas de herramientas integradas que cubren la kill chain completa: escáneres de red como nmap, masscan y rustscan; escáneres web como sqlmap, nikto, gobuster y ffuf; escáneres de vulnerabilidades como nuclei, wpscan y dalfox; además de enumeración de subdominios, seguridad de APIs, seguridad de contenedores y de nube, análisis binario, explotación, cracking de contraseñas, forense, post-explotación y más. Prácticamente todo el arsenal que hace falta para un pentesting autorizado ya viene orquestado.

También hay un plugin de Burp Suite y una extensión de navegador para lanzar el tráfico capturado directamente a la plataforma y analizarlo con ayuda de la IA. Un diseño listo: no tienes que cambiar tu flujo de trabajo actual.

Preparación del entorno antes de desplegar

Los requisitos previos oficiales son dos; ojo con no rozar el límite de versión:

• Go 1.25+ (la versión exigida explícitamente en go.mod; por debajo, la compilación falla de inmediato)
• Python 3.10+ (necesario para algunas herramientas, como api-fuzzer y http-framework-test)

Bache 1: la versión de Go. La primera vez usé la versión vieja de Go que traía el sistema, y el error saltó en plena compilación. Antes conviene go version verificarlo; si no llega, instala primero la nueva desde el sitio oficial. Este tipo de «requisitos previos» es el que más se pasa por alto, porque el error aparece muy tarde.

Despliegue con un clic: qué hace el script por ti

El comando oficial de despliegue con un clic es muy corto:

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

Pero run.sh hace bastante más de lo que crees; ejecuta, en orden:

• ✅ Comprueba y valida los entornos de Go y Python
• ✅ Crea el entorno virtual de Python
• ✅ Instala las dependencias de Python
• ✅ Descarga las dependencias de Go
• ✅ Compila el proyecto
• ✅ Arranca el servicio

Detalle 1: el venv lo gestiona el script. El directorio venv/ lo crea y mantiene run.sh automáticamente, y las herramientas que necesitan Python (api-fuzzer, http-framework-test, etc.) usan ese entorno sin más. No crees uno a mano: solo provocarías conflictos.

Verificar el arranque: puntos que hay que confirmar

Cuando el script termine, no corras a abrir el navegador; mira primero la terminal:

• Confirma que la terminal muestra ● ONLINE, seguido de la dirección real de la Web UI
• Abre esa dirección: el modo HTTPS por defecto usa un certificado autofirmado local; el navegador avisará, basta con aceptarlo una vez
• Una instalación nueva trae una contraseña de administrador de un solo uso: la terminal la muestra bajo ADMIN SETUP REQUIRED; cámbiala justo después de iniciar sesión

Detalle 2: ¿HTTPS o HTTP?. run.sh arranca por defecto con el parámetro –https (TLS autofirmado local; según la web oficial, trata mejor los flujos concurrentes). Si quieres HTTP puro, tienes que indicarlo explícitamente con ./run.sh --http. En arranque manual, añade –https o define la variable de entorno CYBERSTRIKE_HTTPS=1.

En producción no uses certificado autofirmado: configura server.tls_cert_path y server.tls_key_path en config.yaml.

Bache 2: el error de protocolo no coincidente. Si en los logs ves «client sent an HTTP request to an HTTPS server», hay algún cliente que sigue entrando por http:// al puerto TLS. Corrige la URL y no te pongas a toquetear la configuración del servidor.

Configuración inicial: el canal de IA es imprescindible

Sin este paso, es como si no la hubieras instalado. Tras el primer arranque, entra en https://127.0.0.1:8080/ (el puerto lo manda el server.port de config.yaml) y ve a System Settings → Basic Settings → AI Channel Configuration, añade un canal y rellena provider, Base URL, API key, model y el límite de tokens.

También puedes editar config.yaml directamente; el formato es más o menos así:

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

Detalle 3: alcance del canal por defecto. El ai.default_channel se aplica a las sesiones nuevas y a las tareas que no eligen canal explícitamente; en la página de chat puedes escoger por sesión cualquier canal guardado. Así que si tienes varios modelos, no hace falta limitarte a uno.

Con provider en openai_compatible conectas la mayoría de servicios compatibles con la API de OpenAI; cambia base_url a https://api.deepseek.com/v1 y model a deepseek-chat, o lo mismo con qwen3-max. Enchufar modelos chinos es cosa fácil, un detalle muy amable.

⚠️ Aviso de seguridad: no guardes claves reales en config.yaml. La web oficial lo dice claro: no hagas commit de credenciales reales, inyéctalas con variables de entorno.

La actualización también tiene su técnica

Hay un script de actualización con un clic, pero la primera vez hay que darle permisos de ejecución:

chmod +x upgrade.sh && ./upgrade.sh –yes

Lo que hace: respalda config.yaml y el directorio data/ → descarga el código nuevo del GitHub Release → actualiza el número de versión en config.yaml → reinicia el servicio.Los directorios locales tools/, roles/ y skills/ siempre se conservan: es clave, tus recetas de herramientas personalizadas no se sobreescriben.

Bache 3: las dependencias del script de actualización. Necesita curl o wget para descargar el paquete Release y rsync para sincronizar código con seguridad (la web oficial lo marca como recomendado/imprescindible). Si la API de GitHub te limita las peticiones, primero export GITHUB_TOKEN="..." y lánzalo de nuevo.

Si algo falla, puedes restaurar desde .upgrade-backup/ o copiar a mano data y config.yaml y volver a ejecutar run.sh.

Regla importante: antes de actualizar, lee siempre las release notes de la versión objetivo, sobre todo si tocan configuración, base de datos o API. La web oficial lo dice sin adornos: «hacer copia de seguridad es obligatorio aunque sea un parche; el número de versión no garantiza compatibilidad por sí solo».

Estructura de directorios de un vistazo

Saber para qué sirve cada directorio evita perderse en el mantenimiento:

• cmd/ — servidor, punto de entrada MCP stdio, herramientas
• internal/ — Agent, núcleo MCP, manejadores, C2, ejecutor de seguridad
• web/ — SPA estática y plantillas
• tools/ — recetas de herramientas en YAML (más de 100 ejemplos)
• roles/ — configuración de roles (más de 12 roles de pruebas de seguridad preconfigurados)
• skills/ — directorio de Agent Skills (SKILL.md + archivos opcionales)
• agents/ — multiagente en Markdown (orchestrator.md + sub-agentes)
• config.yaml — configuración en tiempo de ejecución
• run.sh / upgrade.sh — scripts de arranque / actualización

En seguridad, la herramienta no te sustituye

La plataforma integra capacidades de alto riesgo como gestión de WebShell y un C2 integrado (listeners, beacons cifrados, sesiones, cola de tareas). La postura oficial es tajante:solo se puede usar en sistemas que te pertenezcan o cuya prueba tengas autorizada explícitamente.

Antes de activar herramientas de alto riesgo en entornos compartidos o de producción, lee sin falta el modelo de seguridad y la guía de hardening. Además incorpora intercepción de llamadas a herramientas: comprobaciones por regex configurables antes de cada ejecución MCP, con protección de dominios gubernamentales activada por defecto.

Además, por defecto solo escucha en 127.0.0.1; si vas a exponer el servicio hacia fuera, endurece antes el sistema. No es cortesía de manual: es el aviso de quien ya se sangró con estos tropiezos.

Para cerrar

Mirándolo en retrospectiva, el despliegue no tuvo grandes problemas: el script ya hizo el 90 % del trabajo. Lo que me hizo parar a consultar documentación fueron detalles «que no había notado»: el límite de versión de Go, que el venv no se crea a mano, que HTTPS activado por defecto provoca el desajuste de protocolo, que la actualización exige copia de seguridad, que las claves no van en la configuración.

Ninguno de esos detalles es difícil por separado, pero saltarte uno te puede frenar media hora. Cuanto más madura es una herramienta, mayor la ganancia de «leer la documentación»: encapsula la complejidad en el script, y la que queda se esconde en los detalles de configuración.

El proyecto ya forma parte de knownsec 404Starlink y es open source bajo Apache 2.0. Si haces pruebas de seguridad autorizadas, dale una oportunidad.

Despliegue con un clic no es comprender con un clic: los detalles son la verdadera clave para ahorrar tiempo.

Repositorio: github.com/Ed1s0nZ/CyberStrikeAI (migrado a github.com/AIPentest/CyberStrikeAI)
Requisitos: Go 1.25+ / Python 3.10+
Licencia: Apache License 2.0
⚠️ Solo para pruebas autorizadas