CyberStrikeAI im Deployment-Protokoll: Auch einfache Tool-Installationen leben vom Detail

Ich habe mich zuletzt mit CyberStrikeAI beschäftigt, einer in Go geschriebenen KI-nativen Security-Testing-Plattform. „One-Click-Deployment“, dachte ich: Repo klonen, Skript ausführen, fertig. Stattdessen bin ich über einige teils größere, teils kleinere Stolpersteine gestolpert. Solange das Gedächtnis noch frisch ist, halte ich den gesamten Ablauf fest – viele der Stolpersteine liegen nämlich nicht am Tool, sondern an übersehenen Details.

Zunächst: Was ist das für ein Tool?

CyberStrikeAI versteht sich als „Handlungssystem für KI-native Cybersicherheit“. Es ist in Go geschrieben und fasst Planung, Ausführung, menschliche Aufsicht, Beweissicherung und Replay in einer prüfbaren Workbench zusammen. Zum Kern gehören ein von Eino angetriebener Agent, MCP-native Tools, eine RAG-Wissensbasis, visuelle Workflows sowie die Modellierung und Analyse von Angriffsketten.

Dazu kommen über 100 eingebaute Tool-Rezepte, die die gesamte Kill Chain abdecken: Netzwerkscanner wie nmap, masscan und rustscan; Web-Scanner wie sqlmap, nikto, gobuster und ffuf; Schwachstellenscanner wie nuclei, wpscan und dalfox; dazu Subdomain-Enumeration, API-Sicherheit, Container-Sicherheit, Cloud-Sicherheit, Binäranalyse, Exploits, Passwort-Cracking, Forensik, Post-Exploitation und mehr. Praktisch alles, was man für autorisierte Penetrationstests braucht, ist hier bereits orchestriert.

Außerdem gibt es ein Burp-Suite-Plugin und eine Browsererweiterung, mit denen sich abgefangener Traffic direkt zur KI-gestützten Analyse in die Plattform werfen lässt. Ein cleveres Design – der bestehende Workflow bleibt unangetastet.

Umgebungsvorbereitung vor dem Deployment

Offiziell sind zwei Voraussetzungen zu erfüllen – bei den Versionen nicht unter die Grenze rutschen:

• Go 1.25+ (die in go.mod explizit geforderte Version; darunter bricht die Kompilierung sofort mit Fehlermeldung ab)
• Python 3.10+ (für einige Tools erforderlich, etwa api-fuzzer und http-framework-test)

Stolperfalle 1: die Go-Version. Beim ersten Versuch hatte ich die alte, systemseitig vorinstallierte Go-Version im Einsatz – der Fehler zeigte sich erst in der Kompilierphase. Besser zuerst go version prüfen; reicht die Version nicht, vorab die neue Version von der offiziellen Website installieren. Solche „Voraussetzungen“ werden leicht übersehen, weil der Fehler erst sehr spät auftritt.

One-Click-Deployment: Was das Skript alles erledigt

Der offizielle One-Click-Deployment-Befehl ist sehr schlank:

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

Aber run.sh macht deutlich mehr, als man denkt. Es führt der Reihe nach aus:

• ✅ Go- und Python-Umgebung prüfen und validieren
• ✅ Virtuelle Python-Umgebung anlegen
• ✅ Python-Abhängigkeiten installieren
• ✅ Go-Abhängigkeiten herunterladen
• ✅ Projekt bauen
• ✅ Dienst starten

Detail 1: Das venv verwaltet das Skript automatisch. Das Verzeichnis venv/ wird von run.sh automatisch angelegt und gepflegt; die Tools, die Python brauchen (api-fuzzer, http-framework-test usw.), nutzen diese Umgebung automatisch. Nicht von Hand anlegen – das führt leicht zu Konflikten.

Start verifizieren: Ein paar Pflichtkontrollen

Wenn das Skript durchgelaufen ist: nicht vorschnell den Browser öffnen, sondern zuerst ins Terminal schauen:

• Bestätigen, dass das Terminal ● ONLINE anzeigt, gefolgt von der tatsächlichen Web-UI-Adresse
• Diese Adresse öffnen: Im HTTPS-Standardmodus kommt ein lokales selbstsigniertes Zertifikat zum Einsatz – der Browser gibt eine Warnung aus, einmal akzeptieren genügt
• Bei einer Neuinstallation gibt es ein einmaliges Admin-Passwort: Es wird im Terminal unter ADMIN SETUP REQUIRED angezeigt und sollte direkt nach dem Login geändert werden

Detail 2: HTTPS oder HTTP. run.sh startet standardmäßig mit dem Parameter –https (lokales, selbstsigniertes TLS; laut offizieller Aussage ist das für gleichzeitige Verbindungen freundlicher). Wer pures HTTP will, muss explizit ./run.sh --http verwenden. Beim manuellen Start –https anhängen oder die Umgebungsvariable CYBERSTRIKE_HTTPS=1 setzen.

Für die Produktionsumgebung: keine selbstsignierten Zertifikate. Stattdessen in config.yaml server.tls_cert_path und server.tls_key_path konfigurieren.

Stolperfalle 2: Fehlermeldung wegen Protokoll-Mismatch. Taucht im Log „client sent an HTTP request to an HTTPS server“ auf, greift noch ein Client per http:// auf den TLS-Port zu. Einfach die URL korrigieren – nicht an der Serverkonfiguration herumdoktern.

Erstkonfiguration: Der KI-Kanal ist Pflicht

Ohne diesen Schritt ist die Plattform praktisch unbrauchbar. Nach dem ersten Start https://127.0.0.1:8080/ aufrufen (maßgeblich ist der in config.yaml unter server.port gesetzte Port) und unter System Settings → Basic Settings → AI Channel Configuration einen Kanal hinzufügen: provider, Base URL, API key, model und Token-Limit eintragen.

Alternativ kann man config.yaml direkt bearbeiten – das Format sieht ungefähr so aus:

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”

Detail 3: Wirkungsbereich des Standard-Kanals. ai.default_channel gilt für neue Sitzungen und Aufgaben ohne explizite Kanalwahl; auf der Chat-Seite lässt sich zusätzlich pro Sitzung jeder gespeicherte Kanal einzeln wählen. Mit mehreren Modellen muss man sich also nicht auf einen einzigen beschränken.

Als provider genügt openai_compatible, um die meisten Dienste mit OpenAI-kompatibler Schnittstelle anzubinden: base_url auf https://api.deepseek.com/v1 und model auf deepseek-chat setzen funktioniert ebenso wie mit qwen3-max. Chinesische Modelle lassen sich ohne Weiteres anschließen – ein angenehmer Pluspunkt.

⚠️ Sicherheitshinweis: In config.yaml keine echten Schlüssel eintragen. Offiziell wird ausdrücklich davon abgeraten, echte Zugangsdaten zu committen – stattdessen Umgebungsvariablen zur Injektion verwenden.

Auch das Upgrade will gelernt sein

Offiziell gibt es ein One-Click-Upgrade-Skript; beim ersten Mal muss es zunächst ausführbar gemacht werden:

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

Es macht Folgendes: config.yaml und das Verzeichnis data/ sichern → neuen Code aus dem GitHub Release ziehen → die Versionsnummer in config.yaml aktualisieren → den Dienst neu starten.Die lokalen Verzeichnisse tools/, roles/ und skills/ werden grundsätzlich beibehalten – ein entscheidender Punkt: Die selbst erstellten Tool-Rezepte werden nicht überschrieben.

Stolperfalle 3: Abhängigkeiten des Upgrade-Skripts. Es benötigt curl oder wget, um das Release-Paket herunterzuladen, sowie rsync für die sichere Codesynchronisation (offiziell als empfohlen bzw. erforderlich bezeichnet). Drosselt die GitHub API die Anfragen, erst export GITHUB_TOKEN="..." abwarten und dann erneut ausführen.

Bei Problemen lässt sich aus .upgrade-backup/ wiederherstellen – oder man kopiert data und config.yaml von Hand zurück und führt run.sh erneut aus.

Ein wichtiger Grundsatz: Vor jedem Upgrade unbedingt die Release Notes der Zielversion lesen – ganz besonders bei Änderungen an Konfiguration, Datenbank oder API. Eine offizielle Aussage trifft den Kern: „Backups sind Pflicht, auch bei einem reinen Patch-Upgrade; die Versionsnummer allein ist keine Kompatibilitätsgarantie.“

Verzeichnisstruktur auf einen Blick

Wer weiß, wofür jedes Verzeichnis da ist, verirrt sich bei der späteren Pflege nicht:

• cmd/ – Server, MCP-stdio-Einstiegspunkt, Tools
• internal/ – Agent, MCP-Kern, Handler, C2, Security Executor
• web/ – statische SPA und Templates
• tools/ – YAML-Tool-Rezepte (über 100 Beispiele)
• roles/ – Rollenkonfigurationen (über 12 vorgefertigte Security-Testing-Rollen)
• skills/ – Agent-Skills-Verzeichnis (SKILL.md + optionale Dateien)
• agents/ – Multi-Agent-Markdown (orchestrator.md + Sub-Agenten)
• config.yaml – Laufzeitkonfiguration
• run.sh / upgrade.sh – Start- bzw. Upgrade-Skript

Bei Sicherheit kann dich kein Tool vertreten

Diese Plattform integriert Hochrisiko-Fähigkeiten wie WebShell-Management und ein eingebautes C2 (Listener, verschlüsselte Beacons, Sitzungen, Aufgabenwarteschlangen). Die offizielle Haltung ist unmissverständlich:nur auf Systemen einsetzen, die einem selbst gehören oder für die eine ausdrückliche Testerlaubnis vorliegt.

Bevor Hochrisiko-Tools in geteilten oder Produktionsumgebungen aktiviert werden, unbedingt zuerst das Sicherheitsmodell und den Hardening-Leitfaden lesen. Eingebaut ist außerdem eine Tool-Call-Interception: konfigurierbare Regex-Prüfungen vor der MCP-Ausführung, mit standardmäßig aktiviertem Schutz von Regierungsdomänen.

Hinzu kommt: Standardmäßig wird nur auf 127.0.0.1 gelauscht. Soll der Dienst nach außen freigegeben werden, ist vorher zwingend zu härten. Das ist keine Floskel, sondern ein Hinweis, den nur jemand in die Dokumentation schreibt, der selbst in schmerzhafte Fallen getappt ist.

Zum Schluss

Rückblick: Das Deployment selbst verlief ohne große Probleme – das Skript erledigt 90 % der Arbeit. Was mich wirklich zum Blättern in der Dokumentation zwang, waren durchweg „übersehene“ Details: die Go-Versionsschwelle, das venv, das man nicht von Hand anlegen darf, das standardmäßig aktive HTTPS samt daraus folgendem Protokoll-Mismatch, Backups vor dem Upgrade, keine Schlüssel in der Konfiguration.

Einzeln betrachtet ist keines dieser Details schwierig – aber ein einziges Übersehen kann eine halbe Stunde kosten. Je ausgereifter das Werkzeug, desto größer der Ertrag des Dokumentationslesens: Es kapselt die Komplexität im Skript, und die verbleibende Komplexität steckt komplett in den Konfigurationsdetails.

Das Projekt ist Teil von knownsec 404Starlink und unter Apache 2.0 quelloffen. Alle, die autorisierte Sicherheitstests durchführen, können es ruhig ausprobieren.

One-Click-Deployment heißt nicht One-Click-Verständnis – die Details sind der wahre Schlüssel zur eingesparten Zeit.

Projektadresse: github.com/Ed1s0nZ/CyberStrikeAI (mittlerweile umgezogen auf github.com/AIPentest/CyberStrikeAI)
Umgebungsanforderungen: Go 1.25+ / Python 3.10+
Lizenz: Apache License 2.0
⚠️ Ausschließlich für autorisierte Tests verwenden