io.github.26zl/cybersec-toolkit

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

Cybersecurity-Toolkit mit integrierter KI-Anbindung. Ein eingebetteter MCP (Model Context Protocol)-Server fährt MCP-fähigen Clients, das Tool-Registry abzufragen, den Installationsstatus zu prüfen, Tools für eine CTF-Kategorie oder ein Bug-Bounty-Ziel zu empfehlen und installierte Tools über einen geschäften Ausführungspfad auszuführen. Menü MCP-Server (KI-Integration).

Gebündelt mit einem modularen Installer für Linux und Termux (Android) mit 670+ Tools, 18 Modulen, 14 Profilen und 12 Installationsmethoden.

Was es unterscheidet: Die meisten Toolkits stop at install tools. Hier kann ein KI sie auch steuern – den Problemtyp ableiten, die richtigen Tools aus allen Modulen/Profilen auswählen und mit dir als interaktiven Begleiter arbeiten. Wenn du es explizit autorisierst, kann dieselbe MCP-Toolketting einen autonome Lösungsschleife eintreten. Standardmäßig ein Begleiter; autonom nur auf deine Anforderung hin.

Funktioniert mit

Siehe docs/AI_CLIENTS.md für eine detaillierte Konfiguration pro Client und docs/ORCHESTRATION.md für die Koordination mehrerer AGENTen über jeden MCP-Client.

So funktioniert es

Zwei Einstiegspunkte teilen sich eine gemeinsame Tool-Registry. Ein Operator führt den Bash-Installer aus, um die Vertrag auf die Platte zu legen; ein KI-Agent spricht mit dem MCP-Server, um dieselben Werkzeuge zu entdecken, zu empfehlen und auszuführen. tools_config.json ist die einheitliche Quelle der Wahrheit, die die Module definieren und die MCP-Berater lesen, und CI-Validatorinnen halten die Python- und Bash-Seite synchron.

Mermaid-Quelle: assets/how-it-works.mmd.

Diagramm lesen: Durchgezogene Pfeile sind Laufzeit- oder Installationsaktionen; gestrichelte Pfeile sind Validierungs- und Kontextbeziehungen. Client-Konfigurationen erfolgt den systemweiten Launcher, bevor sie FastMCP erreichen. security.py regelt run_tool und run_pipeline durch die Erlaubnisliste, Argumentprüfungen und Netzwerkeinstellungen, ohne eine Shell zu verwenden. run_script bleibt eine separate, standardmäßig deaktivierte Vollcode-Ausführungs-Funktion. Agent Skills bleiben außerhalb des Ausführungspfades: .claude/skills/ ist die maßgebliche Quelle und scripts/sync-skills.sh erzeugt .agents/skills/ für Clients, die den portablen Spiegel verwenden.

Related MCP server: Enterprise MCP Gateway and Tool Registry

Warum nicht einfach Kali?

Kali/Parrot/BlackArch liefern die Tools; das hier ist ergänzend, kein Ersatz. Es läuft auf der Box, die du bereits hast (inklusive Termux) und ergänzt eine KI-Kontrollierende Ebene, die installierte Werkzeuge durch eine gemeinsame, gesteuerte Schnittstelle entdecken, empfehlen, verketten und ausführen kann. Willst du alle Tools? Ein Distro installate reicht. Möchtest du einen MCP-Client, der sie unter expliziter Police auswählen und ausführen kann? Genau dafür ist das hier.

Vertrauen und Sicherheit

Sicherheitsnutzer sollten paranoid sein – hier ist genau, was läuft und was gesperrt ist:

• Default-sichere MCP. Standardmaßig verwirft CYBERSEC_MCP_ALLOW_EXTERNAL=0 Netzwerkziele, die nicht in Private/private bzw. Loopback-Bereiche aufgelöst werden, und CYBERSEC_MCP_ALLOW_SCRIPTS=0 deaktiviert run_script. Du optierst die externen Bereiche / Skripting explizit ein.

• Geschützte Ausführung geht durch eine Tor (mcp_server/security.py): Registry-Erlaubnisliste, keine Shell (create_subprocess_exec, niemals shell=True), Argument-Sanifizierung, per Tool blockierte/blockierte Flag-Ausschlussliste (z. B. sqlmap --os-shell, nmap -iL, Liste- oder Ziel-Injection-Flags), Ziel-/Netzwerk-Police, Ratenbegrenzung, Ausgabegrenzen, Timeouts.

• Die Ausführungspolice ist keine OS-Sandbox. Erlaubte Tools laufen mit den Rechten des MCP-Prozessbenutzers, und einige Security-Tools könKinderprozesse starten oder Plugins laden können. run_script zu deaktivieren, deaktiviert nur diesen Endpoint. führe den MCP-Server als Benutzer mit minimalsten Rechten oder in einer Isolationsgrenze aus, die für unverträgliche Targets geeignet ist.

• Werkzeug-erkannte Police ist keine Solver-Harter Code. Der Solver wählt die Tools aus der Registry/den Beratern; the Police squat nur genug CLI-Grammatik, um das echte Ziel von einer Flaggedatei, einer Wortliste, einem Ausgabepfad, einer Konfigurationsdatei oder dem Ziel-Listen-Flag zu unterscheiden. So bleiben Normalkommentarien verwendbar, ohne dass Datei-/Config-Flags die Scope-Prüfungen umgehen.

• Audit-Protokoll, keine Leaks. Aktionen werden als JSON in ein besitzerbezogenes (0600) rotierenden Log unter dem Benutzer-State-Verzeichnis (~/.local/state/cybersec-tools-mcp/audit.log) protokolliert. Skriptinhalte werden nie gespeichert – nur SHA256 + Länge für die Korrelation wird protokolliert – und strings, die wie Anmeldedaten aussehen, werden aus Tool-Argumenten/Argumenten entfernt.

• Least privilege im Installer. Er läuft als root, fällt aber für geklonte-Repo-Builds und pip/cargo/gem-Installationen auf den aufrufenden Benutzer ($SUDO_USER) zurück; binäre Releases werden, wenn Prüfsummen veröffentlicht wurden, per SHA256 verifiziert.

• Dual-use-Tooling ist geschützt. C2- und Phishing-Frameworks (Sliver, Caldera, gophish, evilginx, …) sind standardmäßig eingeschaltet und werden nur mit --include-c2 installiert (die redteam/full-Profile); die MCP-Schicht zeigt das und führt sie niemals automatisch aus.

• Nur autorisierte Nutzung. Siehe SECURITY.md, das Supply Chain Model und den Haftungsausschluss.

Installation

Alle erforderlichen Runtimes (Python, Go, Ruby, Java, Rust, Node.js), Entwicklungsbibliotheken, pipx und Build-Tools werden automatisch installiert. Einzige Voraussetzung ist ein unterstütztes Linux-Derivat. Windows und macOS werden nicht unterstützt (verwende WSL oder Docker).

Docker ist die einzige Ausnahme – installiere es manuell, wenn du C2-Frameworks, MobSF, BeEF, BloodHound, TheHive oder Cortex (--enable-docker) möchtest. Siehe Docker-Installationsdokumentation. GitHub-Authentifizierung wird empfohlen. Der Installer lädt ca. 30 Binary-Releasecodes, ~30+ API-Kali erforderlich zu GitHub hinunter. Interesser auf 60 Anfragen/Stunde ohne Token; mit Token 10000/Stunde. Einfachste Methode:

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

Alternativ kann man ein freie Access Token exportieren:

export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

Aus dem aktuellen Release (gepirnt, stabil, empfohlen):

# 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

Aus main (neueste Tools, Fixes, Änderunge; kann unreales, Entwicklung enthalten):

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

Dieses Installation installiert die Werkzeuge aus allen 18 Modulen. C2/Phishing Tools und Docker-Docker Images bleiben Trinkgeld Optional; --profile full --enable-docker für die gesamte Registry:

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

Unsicher? Erst eine schwere Flug-Vorabprüfung starten (ohne root, installiert nichts):

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

Im testen Docker

Bild „Prebuild“ pullen (kein Bau):

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

Oder selbst bauen:

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

Podman ist ein Drop-in-Ersatz – docker durch podman ersetzen (oder alias docker=podman); rootless Builds und Leben funktionieren. Für das below Compose-Beispiel podman compose verwenden.

Oder die mitgelieferte Compose-Datei nutzen (installer-Dienst bauen und starten):

docker compose run --rm installer --profile ctf

Das Image gewährt dem Benutzer toolkit Passwortsudo da, damit der Installer System-Pakete verwalten kann. Behandle innercontainer-Code als dazu fähig; das Image ist kein Sicherheitsandbox, insbesondere wenn der run_script aktiviert ist oder die sensiblen Host-Pfade gemountet sind.

macOS (Apple Silicon): Bei beiden Befehlen --platform linux/amd64 anfangen, um über die x86-Emulator zu starten:

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 installiert nur das angegebene Tool, ohne die vollständige Setup zu installiert. Ein-Trocken-Test-Sliedsungen zählen Installationseinträge über Methoden hin, die Schätzung kann also höher als der lokale 670+-Tool-Registrier.

Der Installer übernimmt die Installation von 670+ Tools über 12 verschiedene Methoden. Die Zeit wird vor allem durch I/O-intensive Vorgänge belegt, die keine Skripssprache beschleunigen kann:

Für die aktuellen Tool-Anzahlen pro Methode führe ./install.sh --dry-run aus – es gibt die Live-Aufschlüsselung aus, damit die Zahlen hier nicht veralten können. Die langsamsten Phasen sind diejenigen, die am meisten kompilieren oder entpacken (apt/dnf und Go), nicht die reine Tool-Anzahl: Cargo kompiliert aus dem Quellcode, deckt aber nur eine Handvoll Tools ab.

Der Installer parallelisiert bereits, wo möglich (standardmäßig -j 4). Methoden mit gemeinsamen Sperren (apt, pipx, cargo) müssen sequenziell laufen. Um die Installationszeit zu reduzieren:

• Verwende --profile lightweight oder --module <name>, um nur das zu installieren, was du brauchst

• Verwende --skip-cargo, um die Rust-Kompilierung zu überspringen (die langsamste Methode pro Tool)

• Erhöhe die Parallelität mit -j 8 für schnellere Go/git/binary-Downloads

• Richte einen apt-cacher-ng-Proxy für wiederholte Installationen ein

Profile

Module

Installationsmethoden

Skripte nach der Installation

Alle Skripte erfordern Root-Rechte unter Linux (sudo) und unterstützen --help. Auf Termux ist kein Root erforderlich.

--deep-clean entfernt den Go-Modul-/Build-Cache, den Cargo-Registry, pip/pipx/npm/gem-Caches, verwaiste pipx-venvs, veraltete Symlinks und Log-Dateien. Füge --remove-deps hinzu, um auch Rustup-Toolchains zu bereinigen.

MCP-Server (KI-Integration)

MCP (Model Context Protocol) ist ein offener Standard, der KI-Assistenten die Nutzung externer Tools ermöglicht. Dieses Projekt enthält einen MCP-Server, der jeder MCP-fähigen KI (Claude Code, Claude Desktop, Cursor usw.) vollständigen Lesezugriff auf das 670+-Tool-Registry bietet – plus die Möglichkeit, Installationen zu prüfen, Profile zu empfehlen und Tools auszuführen. Die KI wird zu einem interaktiven Partner für ethisches Hacken: Sie kennt jedes Tool, weiß, welche du installiert hast, und kann sie für dich ausführen.

Was die KI tun kann

Der MCP-Client kann alle Tools und deren Installationsstatus abfragen, verwaltete Tool-Aufrufe verketten, die Ausgabe parsen und auf Basis der Ergebnisse umschalten. Die Skriptausführung erfordert ein separates Opt-in.

Externe Recon → Angriffsfläche (benötigt CYBERSEC_MCP_ALLOW_EXTERNAL=1, nur autorisierter Scope)

• „Angriffsfläche für target.com ermitteln und alles Ausnutzbare markieren“ – verteilt amass / subfinder → löst auf und testet mit httpx → identifiziert mit whatweb → führt nuclei-Templates aus → Content-Discovery mit ffuf, dann bewertet es Hosts nach Exposition und schlägt nächste Schritte vor.

• „Offener Redirect auf /go?url= gefunden – ausarbeiten“ – verifiziert mit curl, baut dann einen SSRF-/OAuth-Token-Diebstahl-PoC und testet auf einen ausnutzbaren Callback.

Web-Exploitation

• „SQLi am Login-Endpunkt bestätigen und ausnutzen“ – sqlmap zum Bestätigen und Dumpen (destruktive --os-shell/--os-cmd sind durch die Richtlinie blockiert), dann run_script zum Automatisieren des Auth-Bypasses und um genug für einen PoC zu ziehen.

• „GraphQL-Introspection ist aktiv – kartieren und IDOR jagen“ – zieht das Schema, generiert Abfragen, fuzzt Objekt-IDs und vergleicht authentifizierte vs. nicht authentifizierte Antworten.

Active Directory / intern

• „Low-Priv-Creds auf 10.10.0.0/24 – finde einen Weg zu Domain Admin“ – sammelt mit bloodhound, Kerberoast mit impacket (GetUserSPNs.py), knackt das TGS in hashcat, validiert dann laterale Bewegung mit netexec – alles über die Kali-VM per SSH.

• „Auf DCSync-Rechte prüfen und dumpen, falls der Pfad existiert“ – enumeriert Replikations-ACLs, führt dann secretsdump.py gegen den DC aus.

Binary-Exploitation & Reversing

• „Ret2libc-Exploit für dieses 64-Bit-Binary bauen“ – triagiert mit checksec / readelf, findet Gadgets mit ROPgadget, leakt libc über einen puts@plt-Aufruf, schreibt dann die vollständige pwntools-Kette in venv="pwntools" und öffnet lokal eine Shell.

• „Algorithmus aus diesem gestrippten Binary rekonstruieren“ – objdump / radare2-Disassemblierung in gezielte Analyse geleitet, dann eine run_script-Reimplementierung zur Verhaltensprüfung.

Crypto

• „RSA brechen – kleines e, mehrere Ciphertexte“ – erkennt den Angriff (Håstad / Common-Modulus / Wiener) und löst ihn mit pycryptodome + sympy in einer venv, gibt Klartext zurück.

• „Dieses JWT ist HS256 mit schwachem Schlüssel“ – knackt das Signing-Secret und fälscht ein Admin-Token.

Blue Team · Detection Engineering

• „Sigma-Regel für diese Technik schreiben und in mein SIEM konvertieren“ – erstellt die Regel und rendert sie für das Ziel-Backend (Splunk / Elastic) über sigma-cli.

• „Diese Windows-Ereignisprotokolle auf laterale Bewegung durchsuchen“ – führt chainsaw über die EVTX mit Sigma-Regeln aus, fasst dann Treffer nach Host und Zeitachse zusammen.

• „YARA-Regeln aus diesen Samples erstellen und den Baum scannen“ – generiert yara-Signaturen und führt sie rekursiv aus.

DFIR – Malware-Triage

• „Dieses Speicher-Dump in eine Timeline bringen“ – durchsucht volatility3-Plugins (pslist, netscan, malfind) und verknüpft sie zu einer Erzählung.

• „Nach C2-Beaconing in diesem pcap suchen“ – tshark / tcpdump-Extraktion → suricata-Regeln → markiert periodische Callbacks.

• „Statische Triage dieser verdächtigen Datei“ – file → strings → capa / yara, dann IOCs für Anreicherung extrahieren.

Cloud – Container – Betrieb

• „AWS-Konto auf öffentliche S3 und riskante IAM prüfen“ – führt prowler / scoutsuite aus und zeigt nur die hohen Schweregrade.

• „Dieses Image und k8s-Manifeste vor dem Deploy scannen“ – grype-Image-Scan plus kubescape-Config-Checks.

• „Wie ist meine Redteam-Abdeckung – und Lücken schließen“ – vergleicht get_profile_tools("redteam") mit dem Installationsstatus und gibt die exakten Installationsbefehle aus.

Mobile – Wireless – Blockchain

• „Statische Analyse dieser APK auf Geheimnisse und unsichere Speicherung“ – apktool / jadx dekompilieren → MobSF-artige Checks, dann nach Schlüsseln und Endpunkten suchen.

• „Diese Wi-Fi-Aufnahme prüfen“ – parst den Handshake und führt aircrack-ng / hashcat dagegen aus.

• „Dieses Solidity-Kontrakt auf Reentrancy prüfen“ – führt slither / mythril aus und erklärt die Ergebnisse.

run_tool und run_pipeline sind argumentbereinigt, netzwerküberwacht, ratenbegrenzt und audit-logged. run_script ist standardmäßig deaktiviert, da die Aktivierung ein Opt-in für vollständige Codeausführung mit den Dateisystem- und Netzwerkberechtigungen des MCP-Server-Benutzers ist; die Richtlinie für externe Ziele sandboxt Skripte nicht. Destruktive Flags (--os-shell, -rf, --exploit, …) sind im verwalteten Tool-Pfad blockiert. Verwenden Sie nur gegen Systeme, für die Sie autorisiert sind.

Schnellstart

Erfordert uv. Claude Code kann die verfolgte Projekt-.mcp.json direkt verwenden. Es führt den MCP-Server über stdio aus, wobei Skripte und externe Netzwerkziele standardmäßig deaktiviert sind:

{
  "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"
      }
    }
  }
}

Starten Sie Claude Code neu. Die 15 Tools erscheinen in /mcp.

Andere MCP-Clients (Codex, Cursor, lokale LLMs)

MCP ist ein offener Standard, daher funktioniert derselbe stdio-Server mit jedem MCP-fähigen Client. Vom Repository-Root aus lautet der Startbefehl:

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

--directory mcp_server ist relativ zum Arbeitsverzeichnis. Falls ein Client den Server aus einem Unterverzeichnis starten könnte, verwenden Sie den root-bewussten Launcher aus dem Repository-Root:

bash scripts/mcp-launch.sh

Von außerhalb des Repository verwenden Sie den absoluten Pfad des Launchers:

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

• Codex — Für das Projekt ist eine .codex/config.toml enthalten (sie löst zuerst das Git-Root auf und funktioniert so aus jedem Unterverzeichnis). Die primäre Konfiguration von Codex ist ~/.codex/config.toml; falls die Projektdatei nicht übernommen wird, kopieren Sie den Block [mcp_servers.cybersec-tools] in Ihre Home-Konfiguration.

• Cursor / Continue / Cline / Goose — Fügen Sie denselben Startbefehl in der MCP-Einstellungs-UI oder der Konfigurationsdatei des Clients hinzu (verwenden Sie einen absoluten Pfad, wenn das Arbeitsverzeichnis des Clients nicht das Repository-Root ist).

• LM Studio (≥0.3.17) — LM Studio ist selbst ein MCP-Host, es ist keine Brücke nötig. Fügen Sie den Server zu seiner mcp.json hinzu (Cursor-Notation, gleiche mcpServers-Struktur wie .mcp.json) und verwenden Sie einen absoluten Pfad oder den Git-Root-Wrapper, da das Arbeitsverzeichnis von LM Studio nicht das Repository-Root ist. Die Nutzung von MCP über die LM-Studio-API erfordert ≥0.4.0 und einen MCP-fähigen Endpunkt wie /api/v1/chat oder /v1/responses.

• Ollama — Ollama ist eine Modell-Laufzeitumgebung, kein MCP-Host. Stellen Sie einen MCP-fähigen Agenten davor (z. B. Kit) und richten Sie ihn auf den oben genannten Startbefehl aus.

• Andere lokale LLMs — ein reines Modell spricht von sich aus kein MCP. Betreiben Sie es hinter einem beliebigen MCP-fähigen Host (LM Studio, Cline, Continue, Goose, Kit oder Open WebUI über eine MCP→OpenAPI-Brücke wie mcpo) und richten Sie diesen Host auf den oben genannten Startbefehl aus.

Sicherheitshinweis: Beginnen Sie mit genau diesem einen Server. Er erzwingt bereits Argumentbereinigung, Netzwerk-Allowlists, Ratenbegrenzung und Audit-Logging und wird standardmäßig mit deaktivierter Skriptausführung und deaktivierten externen Zielen ausgeliefert — lassen Sie beides deaktiviert, sofern Sie keinen autorisierten Scope haben, und bevorzugen Sie Hosts, die eine Human-in-the-loop-Genehmigung für Tools unterstützen.

Anbieterneutrale Repository-Anweisungen finden Sie in AGENTS.md (die nativ von Codex und vielen agentischen Tools gelesen wird); Claude Code liest CLAUDE.md.

Verbindung über WSL (z. B. Kali Linux)

Der MCP-Server läuft über stdio und funktioniert daher aus jeder Umgebung, die Claude Code spawnen kann. Um in WSL installierte Tools zu verwenden:

{
  "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"
      ]
    }
  }
}

Verbindung über 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"
      ]
    }
  }
}

Skriptausführung

run_script ermöglicht der KI, Python- oder Bash-Skripte zu schreiben und auszuführen. Es erfordert CYBERSEC_MCP_ALLOW_SCRIPTS=1, ist nicht in einer Betriebssystem-Sandbox gekapselt und wird nicht durch CYBERSEC_MCP_ALLOW_EXTERNAL eingeschränkt. Durch die Aktivierung erhalten Skripte dieselben Dateisystem- und Netzwerkberechtigungen wie der MCP-Serverprozess. Überprüfen Sie generierten Code und den Scope, bevor Sie die Funktion aktivieren:

{
  "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"
      }
    }
  }
}

Venv-Unterstützung

Einige Pakete (z. B. pwntools) benötigen eine ältere Python-Version. Der Parameter venv ermöglicht der KI, den passenden Interpreter pro Skript zu wählen:

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

Die KI verwendet dann automatisch run_script("from pwn import *; ...", venv="pwntools"). Die Standard-MCP-Umgebung enthält FastMCP und die Python-Standardbibliothek. Installieren Sie den optionalen Hilfssatz mit cd mcp_server && uv sync --extra ctf-core, bevor Sie requests, pycryptodome, beautifulsoup4, Pillow oder NumPy ohne ein benanntes Venv verwenden. Setzen Sie CYBERSEC_MCP_VENVS_DIR, um den Standardpfad ~/.ctf-venvs/ zu überschreiben.

Manuelle Skripte

Das Verzeichnis manual_scripts/ speichert dauerhafte Skripte, die die KI für den Benutzer erstellt – komplexe Exploits, mehrstufige Solver, Parser, Protokollhelfer und wiederverwendbare Tools, die nicht nach einer einzigen Ausführung verschwinden sollen. Im Companion-Modus schlägt die KI das Skript vor und schreibt und führt es erst nach Freigabe oder einem eindeutigen „continue" aus. Im opt-in-Modus autonomous kann die KI, wenn normale Tools und Pipelines keine Fortschritte mehr erzielen und Programmlogik den kleinsten zuverlässigen Weg darstellt, begrenzte Helfer über run_script schreiben, speichern und ausführen. Einfache Recon-/HTTP-Befehle wie curl bleiben run_tool-Aufrufe; Skripte sind für Logik gedacht, die Tools nicht sauber ausdrücken können.

Testen Sie den Server

cd mcp_server && uv run fastmcp dev server.py

Dadurch wird ein webbasierter MCP Inspector geöffnet, mit dem jedes Tool interaktiv getestet werden kann.

Siehe mcp_server/README.md für die Einrichtung mit Claude Desktop und die vollständige Dokumentation.

Hilfe willkommen

Dieses Projekt ist von Design bewusst groß ausgelegt, und Unterstützung von der Community ist sehr willkommen.

Nützliche Beiträge umfassen das Testen von Installationen auf verschiedenen Systemdistributionen, das Hinzufügen fehlender Tools, das Beheben von Paketen, die Verbesserung von MCP-Workflows, das Schreiben von Beispielen, die Beseitigung von Stolpersteinen in der Dokumentation sowie das Melden von rauen Kanten aus echten CTF-, Labor-, Bug-Bounty-, Pentest-, DFIR- oder Defensiv-Workflows.

Öffnen Sie ein Issue für größere Änderungen oder senden Sie einen fokussierten PR für kleine Korrekturen. Siehe CONTRIBUTING.md für die Validierungscheckliste.

Entwicklung

Öffentliche Dokumente für Mitwirkende liegen in CONTRIBUTING.md. Der Schnellstart ist:

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 listet alle Shortcuts (lint, test, validate, curate, sync-skills, check-skills, mcp, docker, …); den tatsächlichen Befehl, den jedes Ziel ausführt, sehen Sie in CLAUDE.md bzw. AGENTS.md.

Das MCP-Python-Projekt verwendet uv mit [tool.uv] exclude-newer = "3 days". Auflösung einer neuen Abhängigkeit ignoriert absichtlich Pakete, die in den letzten 72 Stunden hochgeladen wurden, um den Wirkungskreis von Dependency Confusion und kompromittierten Releases zu verringern. Dependabot verwendet die passende dreitätige Ausfallsicherheit. Cooldown; der wöchentliche uv-Update-Workflow übernimmt dieselbe Richtlinie, die in den letzten 72 Stunden hochgeladen wurden, um den Blast-Radius von Dependency-Confusion und kompromittierten Releases zu reduzieren. Dependabot nutzt die dazu passende 3-Tage-Cooldown und der wöchentliche uv-Update-Workflow übernimmt dieselbe Richtlinie.

Diese Release-Alter-Richtlinie bezieht sich ausschließlich auf Bootstrap-/Runtime-Abhängigkeiten des Projekts: MCP-Python-Jacketage, CI-Aktionen und die Docker-Paketeingaben, die zum Start des Projekts benötigt werden. Sie hält die aus der Registry installierten Cybersicherheits-Tools nicht zurück und pinnt die auch nicht fest; diese Tools folgen absichtlich Flow des Modulinstallers und des Update-Flows, damit Administratoren aktuelle Scanner, Exploits, Signaturen und Recherchen-Werkzeuge erhalten.

Führen Sie die Shell-Tests on Linux oder WSL aus. Native Windows-Checkouts können die gebündelten Bats-Submodule mit CRLF umschreiben und zu $'\r'-Fehlern führen.

Agent Skills

Dieses Repository enthält 872 Agent Skills unter dem kanonischen Quellbaum .claude/skills/. Claude Code findet diesen Baum direkt; scripts/sync-skills.sh generiert den tragbaren Spiegel .agents/skills/ für kompatible Clients. Skills werden bei Bedarf aufgabenabhängig aktiviert – sie verbrauchen nicht permanent Kontext. Von diesen sind 31 projekteigene und 841 kuratierte aus Open-Source-Projekten – jeweils attribuiert unten und in THIRD_PARTY_NOTICES.md.

• 10 projektspezifische Entwickler-Skills (add-tool, validate-all, module-scaffold, writeup-template, mcp-sync-check, security-wordlists, security-payloads, guided-assessment, skill-dependency-audit, skill-curation-router)

• 4 Cross-Skill-Koordinatoren (finding-triage, security-comms, authorization-gate, evidence-hygiene), durch die andere Skills Findings, Kommunikation, Autorisierungsprozesse durchlaufen.

• 7 Anker-Skills für Abdeckungslücken (GRC/Datenschutz, AI/LLM-Sicherheit, IoT/Embedded/Hardware, Mainframe, Telekom/5G, SAP/ERP, Lieferketten-/Produktsicherheit)

• 1 Coding-Agent-Workflow-Skill flex multica-ai/andrej-karpathy-skills (MIT)

• 6 CTF-Methodik-Skills (ctf-crypto, ctf-pwn, ctf-web, ctf-rev, ctf-forensics, ctf-stego)

• 4 Bug-Bounty-Methodik-Skills (bounty-recon, bounty-web, bounty-api, bounty-mobile)

• 10 Bug-Bounty-Workflow-Skills von BugHunter (claude-bug-bounty) (MIT)

• 58 offensive Methodik-Skills von SnailSploit Claude-Red (MIT)

• 14 Code-Audit-Skills von Trail of Bits (CC-BY-SA 4.0)

• 74 operative How-Tos aus dem Community-Projekt mukul975/Anthropic-Cybersecurity-Skills (Apache 2.0)

• 4 übergeordnete Workflows von Transilience

Sourcequellen- und Kategorieindex in .claude/skills/SKILLS.md.

Installieren als Claude-Code-Plugin

Das Repo funktioniert auch als Plugin-Marketplace (.claude-plugin/), sodass Sie die gesamte Skill-Bibliothek in beliebige Projekte laden können, ohne manuell zu klonen:

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

Das Plugin stellt die Skills unter .claude/skills/ bereit (deklariert über das skills-Feld in .claude-plugin/plugin.json). Der MCP-Server wird separat über .mcp.json konfiguriert – siehe MCP Server.

Diese Skills mit unterstützten Clients verwenden

Agent Skills sind Markdown plus optionale Hilfsdateien, aber das Entdecken und Aktivieren sind Clientfunktionen und keine MCP-Funktionen. Claude Code, OpenCode, Cursor, Gemini CLI, GitHub Copilot, Cursor, Cline, arXiv, Hermes und OpenClaw unterstützend Agent Skills über verschiedene Wege oder Einstellungen. scripts/sync-skills.sh spiegelt die .claude/skills/-Quelle des Repos nach .agents/skills/ für Clients, die diesen Speicherort verwenden:

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 (siehe Entwicklung) führt diesen Spiegelschritt für Sie aus.

.claude/skills/ bleibt die Installation der Wahrheit; .agents/skills/ wird generiert und in git ignoriert – daher die Synchronisierung nach der Bearbeitung eines Skills erneut aus. Weiter mit Continue und LM Studio können den MCP-Server nutzen, aber kein Kunde innerhalb hat die automatische Erkennung der SKILL.md-Dateien dieses Repos dokumentiert. Ein eigenständiger SKILLS.md-Index wäre nur manueller Kontext; er würde keine dynamische Aktivierung hinzufügen. Verwenden Sie Continue-Regeln/-Prompts oder stellen Sie ausgewählte Skill-Inhalte als Kontext in diesen Clients bereit. Siehe docs/AI_CLIENTS.md für die clientspezifischen Pfade und Einschränkungen.

scripts/validate_claude_skills.py prüft Skill-Metadaten, Indexzählungen, Aktualität der Kuratierung und die Syntax von Hilfsskripten für Python und PowerShell. Hinzuggezogene Hilfsskripte können auch optionale, task-spezifische Python-Importe enthalten. Diese Importe sind in .claude/skills/requirements.txt deklariert, das aus dem Import-Inventar der Hilfsskripte generiert wird:

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

Skill-Ranking/Kuratierung befindet sich in .claude/skills/CURATION.md und .claude/skills/curation.json. Regenerieren Sie es mit:

python3 scripts/curate_claude_skills.py --write

Tool-Standorte

Tools, die nicht aus dem System verfügbar sind (pipx, Go, Cargo, git, Binärreleases), wurden Linux in /usr/local/bin/ installiert und in Termux nach $PREFIX/bin. Systempakete landen an ihrem üblichen Ort (/usr/bin/).

Docker-Images (optional)

Wird nur mit --enable-docker benutzt. Wenn --enable-docker gesetzt ist, aber Docker nicht installiert ist, bricht die Installation mit der Aufforderung ab, zuerst Docker zu installieren.

Distributionsunterstützung

Debian/Ubuntu/Kali ist das primäre Ziel – die vollständige Registry mit über 670 Paketen ist dort verfügbar und hat die stärkste Testabdeckung. Fedora/Arch/openSUSE haben ~10–20 automatisch übersprungene Pakete (distributionsspezifisch) und werden vom Integrations-Workflow abgedeckt. WSL und ARM werden praktisch unterstützt, haben aber noch keine dedizierten CI-Jobs. Windows und macOS werden erkannt und mit einer klaren Fehlermeldung blockiert.

Lieferkettenmodell

Dieser Installer lädt Code aus dem Internet herunter und führt ihn aus. Unter Linux läuft er als root (sudo); unter Termux läuft er in der Benutzer-Sandbox der App (kein root).

• Systempakete: GPG-signiert von den Repos Ihrer Distribution (apt, dnf, pacman, zypper, pkg)

• pipx/Go/Cargo/Gem/npm: Downloads aus Registries (keine Signaturprüfung, pipx in venvs isoliert)

• Binärversionen: SHA256-verifiziert, wenn eine Prüfsummendatei verfügbar ist, harter Fehlschlag bei Abweichung. Verwenden Sie --require-checksums oder das --production-Preset, um auch dann fehlzuschlagen, wenn keine Prüfsummendatei veröffentlicht wird. Warnung: --fast deaktiviert alle Prüfsummenprüfungen, einschließlich für Versionen, die Prüfsummen veröffentlichen – nicht in Produktions- oder CI-Umgebungen verwenden

• MCP-Python-Abhängigkeiten: Von uv mit einem 3-Tage-exclude-newer-Fenster aufgelöst; Dependabot wartet ebenfalls 3 Tage, bevor er Abhängigkeits-PRs vorschlägt. Dies gilt nicht für installierte Sicherheitstools

• Go-SDK: SHA256-verifiziert gegen die von go.dev veröffentlichten Hashes, wenn verfügbar; warnt bei API-Fehler, harter Fehlschlag mit --require-checksums

• Git-Repos: Geklont bei HEAD, Abhängigkeiten in isolierten venvs installiert (setup.py wird NICHT ausgeführt)

• Build from Source: Führt make aus (als root unter Linux) – überprüfen Sie, was Sie bauen

• Toolkit-Docker-Build: Ubuntu- und uv-Quellen sind digest-pinned, während apt-Pakete aus den aktuellen signierten Ubuntu-Repos aufgelöst werden; Neubauten sind nicht bit-für-bit reproduzierbar

• Optionale Tool-Images: Über veränderliche Tags statt Digests gezogen, einschließlich mehrerer expliziter latest-Tags. --production pinnt oder verifiziert diese Images nicht

Die Datei .versions protokolliert, was installiert wurde und wann.

Bekannte Einschränkungen

Die Prüfsummenprüfung ist standardmäßig best-effort. Einige Upstream-Versionen veröffentlichen keine Prüfsummen oder Signaturen, sodass Downloads in diesen Fällen ohne kryptografische Prüfung fortgesetzt werden können. Verwenden Sie --production (oder --require-checksums), um fehlzuschlagen, wenn keine Prüfsummendatei verfügbar ist. Dieses Preset pinnt keine Git-Klone, Sprachpaket-Registries oder Build-from-Source-Tools; diese folgen weiterhin ihren Upstream-Release-Kanälen. Go-SDK-Downloads werden gegen go.dev SHA256-verifiziert, wenn die API erreichbar ist; der strikte Prüfsummenmodus schlägt hart fehl, wenn dies nicht der Fall ist.

--fast überspringt alle Prüfsummenprüfungen für Binärversionen (sowohl SHA256-Prüfungen als auch die Warnung bei fehlenden Prüfsummen), einschließlich Versionen, die doch Prüfsummen veröffentlichen. Dies tauscht Integritätsprüfung gegen Geschwindigkeit. Es schließt sich gegenseitig mit --require-checksums und --production aus. Verwenden Sie --fast nicht in CI-Pipelines oder Umgebungen, in denen die Integrität der Lieferkette wichtig ist.

Windows-Defender-Falschpositive

Wenn Sie dieses Repo auf einen Windows-gemounteten Pfad klonen (z. B. C:\Users\<you>\... oder einen beliebigen Ordner, der von Windows aus sichtbar ist, während Sie in WSL arbeiten), können Microsoft Defender und andere AV-Produkte einzelne Dateien unter Quarantäne stellen. Defensive Inhalte – IOC-Referenztabellen, Beispiel-obfuskiertes PowerShell, Malware-Analyse-Snippets, Exploit-PoC-Strings in .claude/skills/, writeups/ und Teile von mcp_server/ – enthalten dieselben Byte-Strings, die echte Angreifer verwenden, sodass signatur- und ML-basierte Engines sie markieren können. Häufige Erkennungen umfassen Trojan:Script/Wacatac.B!ml, HackTool:* und generische Heur.*-Befunde.

Dies sind Falschpositive im Kontext eines Sicherheits-Toolkits. Um mit dem Repo unter Windows zu arbeiten, haben Sie drei Optionen:

1. Fügen Sie eine Defender-Ausnahme für den Repo-Ordner hinzu (empfohlen für einen persönlichen Entwicklungsrechner). Führen Sie von einer erhöhten PowerShell aus:

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

2. Stellen Sie einzelne Dateien aus der Quarantäne wieder her über Windows-Sicherheit -> Viren- & Bedrohungsschutz -> Schutzverlauf -> „Auf Gerät zulassen". Pro Datei, verhindert jedoch keine erneute Erkennung bei Updates.

3. Bewahren Sie das Repo im WSL-Dateisystem auf (z. B. ~/cybersec-toolkit in Ihrer Distribution). Defender scannt die vhdx von WSL2 standardmäßig nicht, sodass keine Erkennungen auftreten. scripts/sync-wsl.sh erledigt dies bereits für das MCP-Server-Unterverzeichnis.

Von Defender entfernte Dateien erscheinen als D in git status. Der Inhalt bleibt in der Git-Historie erhalten; stellen Sie ihn mit git checkout -- <path> wieder her, sobald eine Ausnahme eingerichtet ist.

Lizenz

MIT-Lizenz – siehe LICENSE für Details.

Dieses Repository verteilt auch Komponenten von Drittanbietern unter deren eigenen Bedingungen weiter, einschließlich einiger unter CC-BY-SA-4.0 (ShareAlike, nicht in MIT umlizenzierbar). Wenn Sie gebündelte Inhalte weiterverteilen oder anpassen, befolgen Sie diese Bedingungen – siehe THIRD_PARTY_NOTICES.md.

Für den Beitrags-Workflow und die Erwartungen an Reviews siehe CONTRIBUTING.md. Für Erwartungen an das Community-Verhalten siehe CODE_OF_CONDUCT.md. Für die Meldung von Schwachstellen siehe SECURITY.md.

Haftungsausschluss

Dieses Projekt wird nur für Bildungs-, Verteidigungs- und ausdrücklich autorisierte Sicherheitstests bereitgestellt. Verwenden Sie es nur auf Systemen, die Sie besitzen oder für die Sie eine schriftliche Genehmigung zur Bewertung haben, und befolgen Sie alle geltenden Gesetze, Regeln des Engagements, Lizenzen von Drittanbieter-Tools und Dienstbedingungen.

Das Toolkit enthält offensive und defensive Tools mit doppeltem Verwendungszweck. Einige Befehle können Netzwerke scannen, Exploits ausführen, Systeme modifizieren oder Sicherheitswarnungen auslösen. MCP/AI-Integrationen sind durch Sicherheitsrichtlinien geschützt, aber die Benutzer bleiben dafür verantwortlich, Umfang, Eingabeaufforderungen, Befehle und Ausgaben zu überprüfen, bevor sie Aktionen ausführen.

Dieses Repository verteilt die Sicherheitstools selbst nicht; es installiert öffentlich verfügbare Open-Source-Projekte aus ihren offiziellen Upstream-Quellen zum Installationszeitpunkt. Es ist nur für rechtmäßige, autorisierte Nutzung bestimmt.

Das Projekt wird „wie besehen" ohne Gewährleistung bereitgestellt. Die Betreuer sind nicht verantwortlich für Missbrauch, Schäden, Datenverlust, Dienstunterbrechungen oder rechtliche Konsequenzen aus der Nutzung dieses Toolkits.

Inhalte von Drittanbietern werden unter ihrer ursprünglichen Lizenz gebündelt – siehe THIRD_PARTY_NOTICES.md.