Diário de deploy do CyberStrikeAI: até a instalação de uma ferramenta simples exige atenção aos detalhes

Ultimamente ando mexendo no CyberStrikeAI, uma plataforma de testes de segurança nativa de IA escrita em Go. Achava que “deploy em um clique” era só clonar e rodar um script, mas acabei tropeçando em alguns percalços de tamanho médio. Enquanto a memória ainda está fresca, registro todo o processo — muitos desses tropeços não são culpa da ferramenta, e sim de detalhes que passaram despercebidos.

Primeiro, o que é essa ferramenta

O CyberStrikeAI se posiciona como um “sistema de ação de cibersegurança nativa de IA”, escrito em Go, que reúne planejamento, execução, supervisão humana, preservação de evidências e replay em um só ambiente de trabalho auditável. Seus componentes principais incluem um agente movido a Eino, ferramentas MCP nativas, base de conhecimento RAG, fluxos de trabalho visuais e modelagem/análise de cadeias de ataque.

Ele traz mais de 100 receitas de ferramentas embutidas cobrindo a cadeia de ataque completa: varredura de rede com nmap, masscan, rustscan; varredura web com sqlmap, nikto, gobuster, ffuf; varredura de vulnerabilidades com nuclei, wpscan, dalfox; além de enumeração de subdomínios, segurança de API, segurança de contêineres, segurança em nuvem, análise de binários, exploração, quebra de senhas, forense, pós-exploração e muito mais. Praticamente todo o arsenal necessário para um pentest autorizado já vem orquestrado de fábrica.

Há ainda um plugin para Burp Suite e uma extensão de navegador, que permitem jogar o tráfego capturado direto na plataforma para análise assistida por IA. O design é inteligente — não exige mudar o seu fluxo de trabalho atual.

Preparação do ambiente antes do deploy

A documentação oficial pede dois pré-requisitos; atenção às versões para não tropeçar:

• Go 1.25+(versão exigida explicitamente no go.mod; abaixo disso a compilação falha direto)
• Python 3.10+(necessário para algumas ferramentas, como api-fuzzer e http-framework-test)

Pegadinha 1: a versão do Go. Da primeira vez usei a versão antiga que vinha no sistema e só recebi erro na hora de compilar. Recomendo verificar antes go version ; se não atender, instale a versão nova pelo site oficial. Esse tipo de “pré-requisito” é o mais fácil de ignorar, porque o erro aparece bem lá no fim.

Deploy em um clique: o que o script faz por você

O comando oficial de deploy em um clique é bem enxuto:

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

Mas o run.sh faz bem mais do que parece; ele executa, em ordem:

• ✅ Verifica e valida os ambientes Go e Python
• ✅ Cria o ambiente virtual Python
• ✅ Instala as dependências Python
• ✅ Baixa as dependências Go
• ✅ Compila o projeto
• ✅ Inicia o serviço

Detalhe 1: o venv é gerenciado automaticamente pelo script. O diretório venv/ é criado e mantido pelo run.sh, e as ferramentas que precisam de Python (api-fuzzer, http-framework-test etc.) usam esse ambiente automaticamente. Não crie um manualmente, para evitar conflitos.

Validando a inicialização: o que precisa ser confirmado

Quando o script terminar, não corra para o navegador; olhe primeiro o terminal:

• Confirme que o terminal exibe ● ONLINE, seguido do endereço real da Web UI
• Abra esse endereço: no modo HTTPS padrão o certificado é autoassinado local e o navegador vai alertar; basta aceitar uma vez
• A instalação nova traz uma senha de administrador de uso único: o terminal a exibe sob ADMIN SETUP REQUIRED; troque assim que fizer login

Detalhe 2: HTTPS ou HTTP. O run.sh inicia por padrão com o parâmetro –https (TLS autoassinado local; segundo a documentação oficial, assim o tratamento de tráfego concorrente fica melhor). Se você quiser HTTP puro, precisa usar explicitamente ./run.sh --http. Ao iniciar manualmente, adicione –https ou defina a variável de ambiente CYBERSTRIKE_HTTPS=1.

Em produção, nada de certificado autoassinado: configure server.tls_cert_path e server.tls_key_path no config.yaml.

Pegadinha 2: erro de protocolo incompatível. Se você vir “client sent an HTTP request to an HTTPS server” nos logs, algum cliente ainda está acessando a porta TLS via http://. Basta corrigir a URL; não vá mexer na configuração do servidor.

Configuração inicial: o canal de IA é obrigatório

Sem esse passo, a plataforma não serve de nada. Após a primeira inicialização, acesse https://127.0.0.1:8080/ (a porta segue o server.port do config.yaml) e entre em System Settings → Basic Settings → AI Channel Configuration, adicione um canal e preencha provider, Base URL, chave de API, model e limite de tokens.

Também dá para editar o config.yaml direto; o formato é mais ou menos assim:

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”

Detalhe 3: o alcance do canal padrão. O ai.default_channel vale para novas sessões e para tarefas sem canal escolhido explicitamente; na página de chat também é possível escolher, por sessão, qualquer canal já salvo. Ou seja, se você tiver vários modelos, não precisa se limitar a um só.

Com provider = openai_compatible dá para conectar quase qualquer serviço compatível com a API da OpenAI: troque base_url por https://api.deepseek.com/v1 e model por deepseek-chat, e o mesmo vale para qwen3-max. Modelos chineses conectam sem dificuldade — um ponto bem amigável.

⚠️ Aviso de segurança: não coloque chaves reais no config.yaml. A documentação oficial é clara: não faça commit de credenciais reais, use injeção por variáveis de ambiente.

Upgrade também exige método

O projeto fornece um script de upgrade em um clique, mas na primeira vez é preciso dar permissão de execução:

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

Ele faz o seguinte: faz backup do config.yaml e do diretório data/ → baixa o novo código do GitHub Release → atualiza o número de versão no config.yaml → reinicia o serviço.Os diretórios locais tools/, roles/ e skills/ são sempre preservados — isso é essencial: suas receitas de ferramentas personalizadas não serão sobrescritas.

Pegadinha 3: dependências do script de upgrade. Ele precisa de curl ou wget para baixar o pacote do Release, e de rsync para sincronizar o código com segurança (recomendado/obrigatório segundo a documentação). Se a API do GitHub estiver com limite de requisições atingido, resolva isso primeiro export GITHUB_TOKEN="..." antes de rodar de novo.

Em caso de problema, dá para restaurar a partir de .upgrade-backup/, ou copiar de volta manualmente o data e o config.yaml e rodar run.sh.

Princípio importante: antes de atualizar, leia sempre as release notes da versão-alvo; redobre o cuidado quando houver mudanças de configuração, banco de dados ou API. Uma frase da documentação oficial resume bem — “backup é obrigatório, mesmo em upgrades de patch; o número de versão, por si só, não garante compatibilidade.”

Visão rápida da estrutura de diretórios

Entender o papel de cada diretório evita se perder na manutenção futura:

• cmd/ — servidor, entrada MCP stdio, ferramentas
• internal/ — agente, núcleo MCP, handlers, C2, executor seguro
• web/ — SPA estática e templates
• tools/ — receitas de ferramentas em YAML (100+ exemplos)
• roles/ — configurações de papéis (12+ papéis pré-definidos de testes de segurança)
• skills/ — diretório de Agent Skills (SKILL.md + arquivos opcionais)
• agents/ — multiagente em Markdown (orchestrator.md + subagentes)
• config.yaml — configuração de execução
• run.sh / upgrade.sh — scripts de inicialização / upgrade

Segurança é algo que a ferramenta não faz por você

A plataforma integra capacidades de alto risco, como gestão de WebShell e um C2 embutido (listeners, beacons cifrados, sessões, filas de tarefas). A posição oficial é bem direta:use apenas em sistemas que você possui ou para os quais tem autorização explícita de teste.

Antes de habilitar ferramentas de alto risco em ambientes compartilhados ou de produção, leia o modelo de segurança e o guia de hardening. Há ainda uma interceptação de chamadas de ferramentas embutida — verificações por regex configuráveis antes da execução no MCP, com proteção de domínios governamentais ativada por padrão.

Além disso, por padrão só escuta em 127.0.0.1; se for expor o serviço externamente, faça hardening antes. Isso não é frase de efeito: é o tipo de aviso que só entra na documentação de quem já passou por muita dor.

Considerações finais

Olhando para trás, o deploy em si não teve grandes problemas; o script já fez 90% do trabalho. O que realmente me fez parar e consultar a documentação foram detalhes que “passaram despercebidos”: a linha de versão do Go, o venv que não pode ser criado à mão, o HTTPS habilitado por padrão causando incompatibilidade de protocolo, backup antes do upgrade, chaves fora da configuração.

Cada um desses detalhes, isolado, é simples, mas perder um pode custar meia hora. Quanto mais madura a ferramenta, maior o retorno de “ler a documentação” — ela empacota a complexidade no script, e a complexidade que sobra mora nos detalhes de configuração.

O projeto foi incorporado ao knownsec 404Starlink e é open source sob a licença Apache 2.0. Quem faz testes de segurança autorizados pode experimentar.

Deploy em um clique não significa compreensão em um clique; os detalhes são a verdadeira chave para economizar tempo.

Endereço do projeto: github.com/Ed1s0nZ/CyberStrikeAI (migrado para github.com/AIPentest/CyberStrikeAI)
Requisitos de ambiente: Go 1.25+ / Python 3.10+
Licença: Apache License 2.0
⚠️ Uso exclusivo em testes autorizados