io.github.26zl/cybersec-toolkit

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

“I am a friend of virtue, not of fortune.”
— Gjergj Kastrioti · Skanderbeg (1405–1468)

Cybersecurity toolkit with built-in AI integration. An embedded MCP (Model Context Protocol) server lets MCP-capable clients query the tool registry, check install status, recommend tools for a CTF category or bug-bounty target, and run installed tools through a governed execution path. Jump to MCP Server (AI Integration).

Bundled with a modular installer for Linux and Termux (Android) covering 670+ tools, 18 modules, 14 profiles, and 12 install methods.

What makes it different: most toolkits stop at installing tools. Here an AI can also drive them — infer the problem type, pick the right tools from all modules/profiles, and work with you as an interactive companion. When you explicitly authorize it, the same MCP toolchain can enter an autonomous solver loop. Companion by default; autonomous only when you ask.

Works with

See docs/AI_CLIENTS.md for detailed configuration per client, and docs/ORCHESTRATION.md for coordinating multiple agents across any MCP client.

How it works

Two entry points share one tool registry. An operator runs the bash installer to put tools on disk; an AI agent talks to the MCP server to discover, recommend, and execute those same tools through its governed tool path. tools_config.json is the single source of truth the modules define and the MCP advisors read, and CI validators keep the Python and bash sides in sync.

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

Reading the diagram: solid arrows are runtime or installation actions; dashed arrows are validation and context relationships. Client configurations enter through the root-aware launcher before reaching FastMCP. security.py governs run_tool and run_pipeline through the allowlist, argument checks, and network policy without invoking a shell. run_script remains a separate, disabled-by-default full-code-execution capability. Agent Skills stay outside the execution path: .claude/skills/ is canonical and scripts/sync-skills.sh produces .agents/skills/ for clients that use the portable mirror.

Why not just Kali (or another installer)?

Kali/Parrot/BlackArch ship the tools; this is complementary, not a replacement. It runs on the box you already have (incl. Termux) and adds an AI control plane that can discover, recommend, chain, and execute installed tools through one governed interface. Want all the tools? A distro is fine. Want an MCP client that can select and run them under explicit policy? That's the gap.

Trust & safety

Security users should be paranoid — here's exactly what runs and what's gated:

• Default-safe MCP. Out of the box CYBERSEC_MCP_ALLOW_EXTERNAL=0 rejects network targets that do not resolve to private/loopback ranges, and CYBERSEC_MCP_ALLOW_SCRIPTS=0 disables run_script. You opt into external scopes / scripting explicitly.
• Governed tool execution passes one gate (mcp_server/security.py): registry allowlist, no shell (create_subprocess_exec, never shell=True), argument sanitization, a per-tool blocked-flag denylist (e.g. sqlmap --os-shell, nmap -iL, file-list/target-injection flags), target/network policy, rate limiting, output caps, and timeouts.
• The execution policy is not an OS sandbox. Allowed tools run with the MCP process user's permissions, and some security tools can launch child processes or load plugins. Disabling run_script only disables that endpoint; run the MCP server as a least-privileged user or inside an isolation boundary appropriate for untrusted targets.
• Tool-aware policy is not solver hardcoding. The solver chooses tools from the registry/advisors; the policy layer only understands enough CLI grammar to tell a real target from a header, wordlist, output path, config file, or target-list flag. That keeps normal commands usable without letting file-list/config flags bypass scope checks.
• Audit trail, not leaks. Actions are logged as JSON to an owner-only (0600) rotating log under the user's state directory (~/.local/state/cybersec-tools-mcp/audit.log by default). Script bodies are never persisted — only an irreversible SHA256 + length is logged for correlation — and credential-shaped strings are redacted from tool arguments.
• Least privilege in the installer. It runs as root but drops to the invoking user ($SUDO_USER) for cloned-repo builds and pip/cargo/gem installs; binary releases are SHA256-verified when checksums are published.
• Dual-use tooling is gated. C2 and phishing frameworks (Sliver, Caldera, gophish, evilginx, …) are off by default and install only with --include-c2 (the redteam/full profiles); the MCP layer reflects this and never auto-runs them.
• Authorized use only. See SECURITY.md, the Supply Chain Model, and the Disclaimer.

Install

All required runtimes (Python, Go, Ruby, Java, Rust, Node.js), dev libraries, pipx, and build tools are installed automatically. The only prerequisite is a supported Linux distro. Windows and macOS are not supported (use WSL or Docker).

Docker is the one exception — install it manually if you want C2 frameworks, MobSF, BeEF, BloodHound, TheHive, or Cortex (--enable-docker). See Docker install docs. GitHub authentication is recommended. The installer downloads ~30 binary releases and makes ~30+ API calls to GitHub. Without auth, you're limited to 60 requests/hour and some downloads may fail. With auth, the limit is 5,000/hour. The easiest way:

bash

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

Alternatively, export a personal access token (no scopes needed):

bash

export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

From the latest release (pinned and stable — recommended):

# 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

From main (newest tools, fixes, and changes; may include unreleased work):

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

That installs the standard tools from all 18 modules. C2/phishing tools and Docker images remain opt-in; use --profile full --enable-docker when you explicitly want the complete registry supported by the current platform. To install a subset:

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

Not sure the machine is ready? Run a read-only preflight first — it needs no root and installs nothing:

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

Try in Docker

Pull the prebuilt image (no local build):

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

Or build it yourself:

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

Podman works as a drop-in replacement — swap docker for podman (or alias docker=podman); rootless builds and runs are supported. For the Compose example below, use podman compose (needs a compose provider installed).

Or use the bundled Compose file (builds and runs the installer service):

docker compose run --rm installer --profile ctf

The image grants the toolkit user passwordless sudo so the installer can manage system packages. Treat code inside the container as root-capable; the image is not a security sandbox, especially when run_script is enabled or sensitive host paths are mounted.

macOS (Apple Silicon): Add --platform linux/amd64 to both commands to run via x86 emulation:

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

Profiles

Modules

Install Methods

Post-Install Scripts

All scripts require root on Linux (sudo) and support --help. On Termux, no root is needed.

--deep-clean removes Go module/build cache, Cargo registry, pip/pipx/npm/gem caches, orphaned pipx venvs, stale symlinks, and log files. Add --remove-deps to also purge Rustup toolchains.

MCP Server (AI Integration)

MCP (Model Context Protocol) is an open standard that lets AI assistants use external tools. This project includes an MCP server that gives any MCP-capable AI (Claude Code, Claude Desktop, Cursor, etc.) full read access to the 670+ tool registry — plus the ability to check installs, recommend profiles, and execute tools. The AI becomes an interactive partner for ethical hacking: it knows every tool, which ones you have installed, and can run them for you.

What the AI can do

Quick Start

Requires uv. Claude Code can use the tracked project .mcp.json directly. It runs the MCP server over stdio with scripts and external network targets disabled by default:

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

Restart Claude Code. The 15 tools appear in /mcp.

Other MCP clients (Codex, Cursor, local LLMs)

MCP is an open standard, so the same stdio server works with any MCP-capable client. From the repo root the launch command is:

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

--directory mcp_server is relative to the working directory. If a client may start the server from a subdirectory, use the root-aware launcher from the repo root:

bash scripts/mcp-launch.sh

From outside the repository, use the launcher's absolute path:

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

• Codex — a project .codex/config.toml is included (resolves the Git root first so it works from any subdirectory). Codex's primary config is ~/.codex/config.toml; if the project file isn't picked up, copy the [mcp_servers.cybersec-tools] block into your home config.
• Cursor / Continue / Cline / Goose — add the same launch command in the client's MCP settings UI or config file (use an absolute path if the client's working directory isn't the repo root).
• LM Studio (≥0.3.17) — LM Studio is itself an MCP host, no bridge needed. Add the server to its mcp.json (Cursor notation, same mcpServers shape as .mcp.json) using an absolute path or the git-root wrapper, since LM Studio's working directory isn't the repo root. Using MCP via LM Studio's API requires ≥0.4.0 and an MCP-capable endpoint such as /api/v1/chat or /v1/responses.
• Ollama — Ollama is a model runtime, not an MCP host. Put an MCP-capable agent in front of it (e.g. Kit) and point it at the launch command above.
• Other local LLMs — a bare model does not speak MCP on its own. Run it behind any MCP-capable host (LM Studio, Cline, Continue, Goose, Kit, or Open WebUI via an MCP→OpenAPI bridge like mcpo) and point that host at the launch command above.

Security note: start with just this one server. It already enforces argument sanitization, network allowlists, rate limiting, and audit logging, and ships with script execution and external targets disabled by default — keep those off unless you have an authorized scope, and prefer hosts that support human-in-the-loop tool approval.

Vendor-neutral repo instructions live in AGENTS.md (read natively by Codex and many agentic tools); Claude Code reads CLAUDE.md.

Connect from WSL (e.g. Kali Linux)

The MCP server runs over stdio, so it works from any environment that Claude Code can spawn. To use tools installed inside 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"
      ]
    }
  }
}

Connect from 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"
      ]
    }
  }
}

Script Execution

run_script lets the AI write and execute Python or Bash scripts. It requires CYBERSEC_MCP_ALLOW_SCRIPTS=1, is not OS-sandboxed, and is not constrained by CYBERSEC_MCP_ALLOW_EXTERNAL. Enabling it grants scripts the same filesystem and network permissions as the MCP server process. Review generated code and scope before opting in:

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

Python libraries have no console scripts, so pipx cannot install them. They go into named venvs under ~/.ctf-venvs/ instead, and the venv parameter picks the interpreter per script.

./install.sh --module crypto creates ~/.ctf-venvs/crypto with pycryptodome, sympy, gmpy2, numpy, z3, fpylll (+cysignals, which fpylll needs at import time but does not declare) and cypari2 — the set CTF crypto actually reaches for: lattice reduction, PARI point counting, custom constructions. The AI then runs run_script(code, venv="crypto").

Some packages (e.g. pwntools) additionally require an older Python:

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

The AI then uses run_script("from pwn import *; ...", venv="pwntools") automatically. The default MCP environment contains FastMCP and the Python standard library. Install the optional helper set with cd mcp_server && uv sync --extra ctf-core before using requests, pycryptodome, beautifulsoup4, Pillow, or NumPy without a named venv. Set CYBERSEC_MCP_VENVS_DIR to override the default ~/.ctf-venvs/ location.

Manual Scripts

The manual_scripts/ directory stores persistent scripts that the AI creates for the user — complex exploits, multi-step solvers, parsers, protocol helpers, and reusable tools that should not disappear after one execution. In companion mode the AI proposes the script, then writes and runs it only after approval or a clear "continue". In opt-in autonomous mode, if normal tools and pipelines stop making progress and programming logic is the smallest reliable path, the AI can write, save, and run scoped helpers via run_script. Simple recon/HTTP commands such as curl stay as run_tool calls; scripts are for logic that tools cannot express cleanly.

Test the Server

cd mcp_server && uv run fastmcp dev server.py

This opens a web-based MCP Inspector for interactively testing each tool.

See mcp_server/README.md for Claude Desktop setup and full documentation.

Help wanted

This project is large by design, and community help is very welcome.

Useful contributions include testing installs on different distros, adding missing tools, fixing package mappings, improving MCP workflows, writing example use cases, tightening documentation, and reporting rough edges from real CTF, lab, bug bounty, pentest, DFIR, or defensive workflows.

Open an issue for bigger changes, or send a focused PR for small fixes. See CONTRIBUTING.md for the validation checklist.

Development

Public contributor docs live in CONTRIBUTING.md. The quick-start is:

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 lists every shortcut (lint, test, validate, curate, sync-skills, check-skills, mcp, docker, …); the raw command each target runs is in CLAUDE.md / AGENTS.md.

The MCP Python project uses uv with [tool.uv] exclude-newer = "3 days". New dependency resolutions intentionally ignore packages uploaded in the last 72 hours to reduce dependency-confusion and compromised-release blast radius. Dependabot uses the matching 3-day cooldown, and the weekly uv update workflow inherits the same policy.

This release-age policy is scoped to project bootstrap/runtime dependencies only: MCP Python packages, CI actions, and the Docker build inputs needed to get the project running. It does not delay or pin the cybersecurity tools installed from the registry; those tools intentionally follow their module installer and update flow so operators can get current scanners, exploits, signatures, and research utilities.

Run shell tests on Linux or WSL. Native Windows checkouts can rewrite the vendored Bats submodules with CRLF and cause $'\r' failures.

Agent Skills

This repo ships 872 Agent Skills under the canonical .claude/skills/ source tree. Claude Code discovers that tree directly; scripts/sync-skills.sh generates the portable .agents/skills/ mirror for compatible clients. Skills activate on demand based on the task — they don't permanently consume context. Of these, 31 are project-authored and 841 are curated from open-source projects — each attributed below and in THIRD_PARTY_NOTICES.md.

• 10 project-specific developer 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 coordinators (finding-triage, security-comms, authorization-gate, evidence-hygiene) that other skills route findings, communication, authorization checks, and evidence sanitization through
• 7 coverage gap anchor skills (GRC/privacy, AI/LLM security, IoT/embedded/hardware, mainframe, telecom/5G, SAP/ERP, supply-chain/product security)
• 1 coding-agent workflow skill from multica-ai/andrej-karpathy-skills (MIT)
• 6 CTF methodology skills (ctf-crypto, ctf-pwn, ctf-web, ctf-rev, ctf-forensics, ctf-stego)
• 4 bug bounty methodology skills (bounty-recon, bounty-web, bounty-api, bounty-mobile)
• 10 bug bounty workflow skills from BugHunter (claude-bug-bounty) (MIT)
• 58 offensive methodology skills from SnailSploit Claude-Red (MIT)
• 14 code audit skills from Trail of Bits (CC-BY-SA 4.0)
• 754 operational how-tos from the community project mukul975/Anthropic-Cybersecurity-Skills (Apache 2.0)
• 4 high-level workflows from Transilience (MIT)

Source and category index in .claude/skills/SKILLS.md.

Install as a Claude Code plugin

The repo doubles as a plugin marketplace (.claude-plugin/), so you can pull the whole skill library into any project without cloning manually:

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

The plugin exposes the skills under .claude/skills/ (declared via the skills field in .claude-plugin/plugin.json). The MCP server is configured separately via .mcp.json — see MCP Server.

Use these skills across supported clients

Agent Skills are Markdown plus optional helper files, but discovery and activation are client features rather than MCP features. Claude Code, OpenCode, Codex, Gemini CLI, GitHub Copilot, Cursor, Cline, Goose, Hermes, and OpenClaw support Agent Skills through different paths or settings. scripts/sync-skills.sh mirrors the repository's .claude/skills/ source into .agents/skills/ for clients that use that location:

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 (see Development) runs this mirror step for you.

.claude/skills/ stays the single source of truth; .agents/skills/ is generated and git-ignored, so re-run the sync after editing a skill. Continue and LM Studio can use the MCP server, but neither client currently documents automatic discovery of this repository's SKILL.md files. A standalone SKILLS.md index would only be manual context; it would not add on-demand activation. Use Continue rules/prompts or provide selected skill content as context in those clients. See docs/AI_CLIENTS.md for the client-specific paths and limits.

scripts/validate_claude_skills.py checks skill metadata, index counts, curation freshness, and helper-script syntax for Python and PowerShell. Vendored skill helper scripts can also have optional task-specific Python imports. Those imports are declared in .claude/skills/requirements.txt, generated from the helper-script import inventory:

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/curation lives in .claude/skills/CURATION.md and .claude/skills/curation.json. Regenerate it with:

python3 scripts/curate_claude_skills.py --write

Tool Locations

Non-system tools (pipx, Go, Cargo, git, binary releases) are installed to /usr/local/bin/ on Linux and $PREFIX/bin on Termux. System packages go to their default location (/usr/bin/).

Docker Images (optional)

Only used with --enable-docker. If Docker is not installed and --enable-docker is set, the installer exits with an error asking you to install Docker first.

Distro Support

Debian/Ubuntu/Kali is the primary target -- the full 670+ registry is available there, and it has the strongest test coverage. Fedora/Arch/openSUSE have ~10-20 packages auto-skipped (distro-specific) and are covered by the integration workflow. WSL and ARM are supported in practice, but they do not yet have dedicated CI jobs. Windows and macOS are detected and blocked with a clear error message.

Supply Chain Model

This installer downloads and runs code from the internet. On Linux it runs as root (sudo); on Termux it runs in the app's user sandbox (no root).

• System packages: GPG-signed by your distro's repos (apt, dnf, pacman, zypper, pkg)
• pipx/Go/Cargo/Gem/npm: Downloads from registries (no signature verification, pipx isolated in venvs)
• Binary releases: SHA256 verified when checksum file available, hard-fails on mismatch. Use --require-checksums or the --production preset to also fail when no checksum file is published. Warning: --fast disables all checksum verification, including for releases that do publish checksums — do not use in production or CI environments
• MCP Python dependencies: Resolved by uv with a 3-day exclude-newer window; Dependabot also waits 3 days before proposing dependency PRs. This does not apply to installed security tools
• Go SDK: SHA256 verified against go.dev published hashes when available; warns on API failure, hard-fails with --require-checksums
• Git repos: Cloned at HEAD, deps installed in isolated venvs (setup.py is NOT executed)
• Build from source: Runs make (as root on Linux) -- review what you're building
• Toolkit Docker build: Ubuntu and uv sources are digest-pinned, while apt packages resolve from the current signed Ubuntu repositories; rebuilds are not bit-for-bit reproducible
• Optional tool images: Pulled by mutable tags rather than digests, including several explicit latest tags. --production does not pin or verify these images

The .versions file logs what was installed and when.

Known Limitations

Checksum verification is best-effort by default. Some upstream releases do not publish checksums or signatures, so downloads may proceed without cryptographic verification in those cases. Use --production (or --require-checksums) to fail closed when no checksum file is available. This preset does not pin Git clones, language-package registries, or build-from-source tools; those still track their upstream release channels. Go SDK downloads are SHA256-verified against go.dev when the API is reachable; strict checksum mode hard-fails if it is not.

--fast skips all checksum verification for binary releases (both SHA256 checks and the missing-checksum warning), including releases that do publish checksums. This trades integrity verification for speed. It is mutually exclusive with --require-checksums and --production. Do not use --fast in CI pipelines or environments where supply-chain integrity matters.

Windows Defender false positives

If you clone this repo onto a Windows-mounted path (e.g. C:\Users\<you>\... or any folder visible from Windows while you work in WSL), Microsoft Defender and other AV products may quarantine individual files. Defensive content -- IOC reference tables, sample obfuscated PowerShell, malware analysis snippets, exploit PoC strings inside .claude/skills/, writeups/, and parts of mcp_server/ -- contains the same byte-strings real attackers use, so signature- and ML-based engines can flag them. Common detections include Trojan:Script/Wacatac.B!ml, HackTool:*, and generic Heur.* verdicts.

These are false positives in the context of a security toolkit. To work with the repo on Windows you have three options:

1. Add a Defender exclusion for the repo folder (recommended for a personal dev box). Run from an elevated PowerShell:

   powershell

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

2. Restore individual files from quarantine via Windows Security -> Virus & threat protection -> Protection history -> "Allow on device". Per-file, but does not prevent re-detection on update.

3. Keep the repo inside the WSL filesystem (e.g. ~/cybersec-toolkit in your distro). Defender does not scan WSL2's vhdx by default, so detections do not occur. scripts/sync-wsl.sh already does this for the MCP server subdirectory.

Files removed by Defender will appear as D in git status. The content is preserved in git history; restore with git checkout -- <path> once an exclusion is in place.

License

MIT License -- see LICENSE for details.

This repository also redistributes third-party components under their own terms, including some under CC-BY-SA-4.0 (ShareAlike, not relicensable to MIT). If you redistribute or adapt bundled content, follow those terms — see THIRD_PARTY_NOTICES.md.

For contribution workflow and review expectations, see CONTRIBUTING.md. For community behavior expectations, see CODE_OF_CONDUCT.md. For vulnerability reporting, see SECURITY.md.

Disclaimer

This project is provided for educational, defensive, and explicitly authorized security testing only. Use it only on systems you own or have written permission to assess, and follow all applicable laws, rules of engagement, third-party tool licenses, and service terms.

The toolkit includes dual-use offensive and defensive tools. Some commands can scan networks, execute exploits, modify systems, or trigger security alerts. MCP/AI integrations are guarded by safety policies, but users remain responsible for reviewing scope, prompts, commands, and outputs before running actions.

This repository does not redistribute the security tools themselves; it installs publicly available, open-source projects from their official upstream sources at install time. It is intended for lawful, authorized use only.

The project is provided "as is", without warranty. Maintainers are not responsible for misuse, damage, data loss, service disruption, or legal consequences from using this toolkit.

Third-party content is bundled under its original license — see THIRD_PARTY_NOTICES.md.