From 4c517fa18175540e5483d780bf1fa3ef8728eae3 Mon Sep 17 00:00:00 2001 From: monoxgas Date: Fri, 12 Jun 2026 16:26:39 -0600 Subject: [PATCH] docs: operator-install READMEs for 11 capabilities MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds READMEs to the capabilities on main that lacked one, written to the operator-install bar: what it is, how to stand it up, what to know before trusting it. Agent-runtime content (attack methodology, tool-by-tool usage, query idioms) stays in skills/ — the README is for the person installing and running the capability, not the agent at runtime. Length follows install complexity: thin connectors (sliver-c2, bloodhound, dotnet-reversing) land at ~27 lines; install-heavy ones earn more (web-security's 10-MCP toolchain, ios-forensics' MVT + STIX-IoC prep, network-ops' uninstalled AD toolbelt). web-security's 68 skills and 10 servers are grouped by family / by what-needs-setup, not enumerated. Reciprocal sibling cross-links added: mythic-c2 <-> mythic-c2-readonly, secure-software <-> spectra-assure, bloodhound <-> bloodhound-enterprise. Excludes binary-analysis (not yet on main; belongs with its promotion PR) and windows-reversing (being superseded). Co-Authored-By: Claude Opus 4.8 (1M context) --- capabilities/ai-red-teaming/README.md | 48 +++++++++++++++++ capabilities/android-apk-research/README.md | 50 +++++++++++++++++ capabilities/bloodhound/README.md | 29 ++++++++++ capabilities/dotnet-reversing/README.md | 29 ++++++++++ capabilities/ios-forensics/README.md | 55 +++++++++++++++++++ capabilities/memory-forensics/README.md | 36 +++++++++++++ capabilities/mythic-c2-readonly/README.md | 2 + capabilities/mythic-c2/README.md | 32 +++++++++++ capabilities/network-ops/README.md | 59 +++++++++++++++++++++ capabilities/secure-software/README.md | 43 +++++++++++++++ capabilities/sliver-c2/README.md | 27 ++++++++++ capabilities/spectra-assure/README.md | 2 + capabilities/web-security/README.md | 42 +++++++++++++++ 13 files changed, 454 insertions(+) create mode 100644 capabilities/ai-red-teaming/README.md create mode 100644 capabilities/android-apk-research/README.md create mode 100644 capabilities/bloodhound/README.md create mode 100644 capabilities/dotnet-reversing/README.md create mode 100644 capabilities/ios-forensics/README.md create mode 100644 capabilities/memory-forensics/README.md create mode 100644 capabilities/mythic-c2/README.md create mode 100644 capabilities/network-ops/README.md create mode 100644 capabilities/secure-software/README.md create mode 100644 capabilities/sliver-c2/README.md create mode 100644 capabilities/web-security/README.md diff --git a/capabilities/ai-red-teaming/README.md b/capabilities/ai-red-teaming/README.md new file mode 100644 index 0000000..677ff82 --- /dev/null +++ b/capabilities/ai-red-teaming/README.md @@ -0,0 +1,48 @@ +# ai-red-teaming + +An agent-driven harness for adversarially probing AI systems. The `ai-red-teaming-agent` extracts attack parameters from a request, generates a Python workflow against the target, executes it, and reports platform-tracked metrics. Each workflow assembles three pieces — an **attack algorithm** (iterative jailbreaks like TAP/PAIR/Crescendo, ML adversarial samplers like HopSkipJump), optional **transforms** that mutate the adversarial prompt (encoding, cipher, persuasion, MCP/multi-agent poisoning), and **scorers** that judge whether the target broke — and runs them as trials on the Dreadnode platform. Targets can be plain LLMs, agentic HTTP endpoints (tools/MCP/multi-agent), RAG pipelines, or traditional ML classifiers. The agent is a parameter extractor: it does not write attack code or interpret results, it drives the generator tools and relays raw platform numbers. + +**Shape:** one agent (`ai-red-teaming-agent`, pinned to `claude-opus-4`), a Python tool surface (attack generation, workflow execution, assessment tracking, session context, platform analytics), and eight lazily-loaded skills (attack selection, transform/scorer reference, workflow patterns, compliance mapping, trace/analytics interpretation, troubleshooting). The attack-runner code generator and the catalogs of algorithms, transforms, and scorers live in `scripts/` and the skills — not here. + +The attack catalog (45 algorithms, 500+ transforms, the scorer set, and 260 bundled harm goals across 25 sub-categories) is methodology, not setup — the agent enumerates it on request (`"show me all available attacks"`) and the skills document selection. This README is for standing the harness up. + +## Setup + +Configuration is entirely through the environment — the tools self-bootstrap their dependencies via `uv run`. No `.env` autoload; set these on the deployer (secrets screen or web app). + +**Platform connection** (where assessments and trials are tracked): + +| Var | Notes | +|---|---| +| `DREADNODE_API_KEY` | Required with `DREADNODE_SERVER` for sandbox mode. | +| `DREADNODE_SERVER` | Platform URL. | +| `DREADNODE_ORGANIZATION` / `DREADNODE_WORKSPACE` / `DREADNODE_PROJECT` | Scope the run; optional. | + +If `DREADNODE_SERVER` + `DREADNODE_API_KEY` are unset, the runner falls back to a saved profile (`dreadnode login`). With neither, workflow execution aborts. + +**Model provider keys** — the attack, attacker, and judge models can be any litellm-routable provider. Supply the matching key (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `GROQ_API_KEY`, …) for whichever providers your target/attacker/judge models use; the runner warns at execution time when a model's key is missing. Alternatively, set `OPENAI_API_KEY` + `OPENAI_BASE_URL` to route prefix-less models through a LiteLLM proxy. + +**Target endpoints** are not env config — they are passed as tool parameters at attack time: a model alias or full litellm path for LLMs, an `agent_url` (plus `agent_auth_type` and an `agent_auth_env_var` naming a platform secret) for agentic targets, or an `api_url` for ML classifiers. The skills cover the parameter shapes. + +Outputs and session state land under `~/workspace/airt/` and `~/.dreadnode/airt///`; override with `AIRT_WORKFLOWS_DIR`, `AIRT_SESSION_PATH`, `AIRT_ASSESSMENT_PATH`. + +## Usage + +Drive it through the agent: + +``` +>>> @ai-red-teaming-agent Run TAP on gpt-4o, goal: extract the system prompt +>>> @ai-red-teaming-agent Full safety sweep on claude-sonnet +>>> @ai-red-teaming-agent Red team my agent at https://api.example.com/chat, make it execute shell commands +``` + +The agent picks a generator (`generate_attack`, `generate_category_attack`, `generate_agentic_attack`, `generate_image_attack`), executes the workflow, registers the assessment, validates the results, and reports the platform metrics. Session context carries target/goal/config across follow-ups so "now try Crescendo on the same target" reuses prior parameters. + +## Before you trust it + +- **This is offensive tooling against AI systems.** Attacks generate adversarial prompts, contact target endpoints, and attempt to elicit unsafe behavior. Only point it at models, agents, and endpoints you are authorized to test — the harm goals and prompts are test data, but the traffic to a target is real. +- **Agentic and ML attacks hit live endpoints.** `agent_url` / `api_url` attacks send real requests; agentic runs can invoke the target's tools. Scope auth and dangerous-tool lists deliberately. +- **Cost is query budget.** Iterative algorithms run hundreds to thousands of model queries per goal (see the per-attack budgets in the agent's table); a full category sweep multiplies that across 260 goals. Bound runs with `goals_per_category` and `n_iterations` before a kitchen-sink sweep. +- **The agent reports platform data only** — it never interprets ASR/risk scores or invents numbers. Deeper analysis lives in the platform web interface and the trace/analytics skills. +- **Compliance mappings are provenance, not a tour.** Goals and categories map to OWASP LLM Top 10, OWASP ASI01–ASI10, MITRE ATLAS, and NIST AI RMF; the `compliance-mapping` skill carries the crosswalk. +- Unit tests ship under `tests/` for the script layer (attack runner, goal loader, assessment tracker, results inspector, workflow helper); there is no live end-to-end target test. diff --git a/capabilities/android-apk-research/README.md b/capabilities/android-apk-research/README.md new file mode 100644 index 0000000..98f945e --- /dev/null +++ b/capabilities/android-apk-research/README.md @@ -0,0 +1,50 @@ +# android-apk-research + +Static semantic-bug research on Android APKs — deep-link routers, intent redirection, WebView trust boundaries, auth/session/client-state bypass, Dirty Stream share targets, and APK-derived backend API chains. A 10-tool orchestration MCP (`android-research`) handles the wide, parallel work — corpus inventory, component ranking, runtime classification, protector detection/unpack, API-map extraction, finding normalization — while the heavyweight decompile-and-hunt methodology (JADX heap tiers, ripgrep pattern packs, Semgrep rule ensembles, Joern/CodeQL recipes) lives in the skills as bash, where it belongs. Everything here is **static**: no device, no emulator, no live backend. + +**Shape:** one MCP server (`android-research`, self-bootstrapping via `uv run`), four skills — `android-corpus-prep` (AndroZoo/Play target selection), `android-semantic-vuln-hunting` (canonical at-scale methodology), `android-targeted-assessment` (one-APK depth mode), `android-protector-triage` (DexProtector/Promon handling). Findings ground in OWASP MASVS / MASTG, MASWE, and CWE. + +## What the MCP exposes + +Ten tools, grouped by pipeline stage. They orchestrate scripts under `scripts/`; the actual decompilation and scanning stays in the skills. + +| Stage | Tools | +|---|---| +| Probe | `inventory_status` | +| Corpus inventory | `run_corpus_inventory` | +| Attack-surface ranking | `extract_components`, `rank_components`, `detect_runtime_kind` | +| Protector triage | `detect_protector`, `dexprotector_unpack` | +| Backend mapping | `extract_api_map`, `rank_backend_richness` | +| Reporting | `normalize_semantic_findings` | + +## Setup + +The MCP self-bootstraps (PEP 723 / `uv run`) — no Python install step. The work it orchestrates depends on external CLIs that are **not** bundled; the manifest `checks:` block surfaces missing hard prerequisites in the TUI capability manager. + +**Hard prerequisites** (manifest `checks:` — capability is degraded without them): + +| Tool | Why | +|---|---| +| `uv` | Runs the MCP and its PEP 723 scripts | +| `jadx` | DEX → Java decompilation (the core hunting surface) | +| `apktool` | Resource / manifest decoding | +| `aapt` or `aapt2` | Manifest fallback when Androguard errors on multi-dex APKs | +| `semgrep` | Rule-pack triage of decompiled source | +| `apkid` | Packer / protector signal during inventory | + +**Skill-step tools** (not checked at install, but `inventory_status` reports them — needed for specific methodology steps): `joern`, `codeql`, `adb`, plus hybrid-runtime follow-ups `hbctool` (Hermes), `blutter` (Flutter/Dart AOT), and `prettier` / `npx` (JS bundle work). `android-corpus-prep` additionally uses DuckDB for AndroZoo Parquet selection. Call `inventory_status` once at session start to see which steps will run end-to-end on the host. + +**Tunables** (set via the deployer environment — secrets screen or web app; no `.env` autoload): + +| Var | Default | Change when | +|---|---|---| +| `ANDROID_RESEARCH_MAX_OUTPUT_CHARS` | `20000` | Tool output is being truncated and you need more inline context | +| `ANDROID_RESEARCH_TIMEOUT` | `300` | Reference default only; each tool takes its own `timeout` arg (per-APK inventory 180s, unpack 600s, etc.) | + +## Before you trust it + +- **Static only.** `extract_api_map` output is a *target map* for backend hypotheses, not proof — findings default to `needs_backend_validation` until tested against authorized accounts. No exploitation, no live-backend probing, no APK patching ships here. +- **DexProtector unpack is arm64-v8a only.** `dexprotector_unpack` statically recovers `libdp.so` via Unicorn emulation (it never *executes* the blob); other ABIs and other protectors fall back to adjacency analysis only. Always run `detect_protector` first and gate on `dexprotector_unpack_supported`. +- **Authorization is the operator's job.** The skills default to static + authorized read-only validation; pointing the pipeline at APKs or backends you're not cleared to test is out of scope by design. + +Agent-facing usage — the JADX heap tiers, ripgrep/Semgrep/Joern/CodeQL recipes, bug-class catalog, and finding schema — lives in `skills/`, not here. The MCP carries a header note on the "why bash, not MCP" split; the long-form rationale is in `skills/android-semantic-vuln-hunting/references/workflow.md`. diff --git a/capabilities/bloodhound/README.md b/capabilities/bloodhound/README.md new file mode 100644 index 0000000..22aacf2 --- /dev/null +++ b/capabilities/bloodhound/README.md @@ -0,0 +1,29 @@ +# bloodhound + +Wires a local [BloodHound Community Edition](https://bloodhound.specterops.io) deployment into chat and agents. The MCP authenticates to the CE REST API to verify the session, then runs **Cypher against the underlying Neo4j graph over Bolt** for AD/Entra attack-path analysis — domain enumeration, Tier Zero, Kerberos, delegation, ADCS, NTLM relay, and hygiene. It ships ~25 named "standard queries" alongside an arbitrary-Cypher tool. + +Twin of `bloodhound-enterprise/`: **this** talks Bolt to a local CE Neo4j; **that** talks HMAC-signed REST to a hosted BloodHound Enterprise deployment. Use this one when you run your own CE/Neo4j stack. + +## Setup + +The server connects to two endpoints — the CE web API (to authenticate) and the Neo4j graph (where queries run). Both default to a standard local CE Docker stack; the only value you must supply is the BloodHound password: + +| Var | Default | Reason to change | +|-----|---------|------------------| +| `BLOODHOUND_URL` | `http://localhost:8080` | CE running on another host/port | +| `BLOODHOUND_USERNAME` | `admin` | non-default CE account | +| `BLOODHOUND_PASSWORD` | (required) | the CE login secret — no default | +| `NEO4J_URL` | `bolt://localhost:7687` | Neo4j not co-located with CE | +| `NEO4J_USERNAME` | `neo4j` | non-default Neo4j account | +| `NEO4J_PASSWORD` | `bloodhoundcommunityedition` | you changed the CE Neo4j password | +| `NEO4J_DATABASE` | `neo4j` | multi-database Neo4j | + +Set these as capability secrets, or pass them at runtime via the `connect` tool (overrides env for the session). Until a password is present the server raises `Not connected` on first query. + +## Before you trust it + +- **Read/query only.** The four tools (`connect`, `query`, `standard_query`, `list_queries`) execute Cypher against the graph — there is no SharpHound/AzureHound ingest path here. Collect and import data with the normal CE tooling first; this capability analyzes what's already loaded. +- **`query` runs arbitrary Cypher** with the configured Neo4j credentials — scope those credentials to the read posture you want. +- **`docs/`** is imported SpecterOps BloodHound reference (node/edge/glossary docs), bundled under its own Apache-2.0 `LICENSE` for offline schema lookup. + +Agent-facing usage — Cypher idioms, the standard-query catalog, and attack-path tradecraft — lives in `skills/bloodhound/`, not here. diff --git a/capabilities/dotnet-reversing/README.md b/capabilities/dotnet-reversing/README.md new file mode 100644 index 0000000..f000148 --- /dev/null +++ b/capabilities/dotnet-reversing/README.md @@ -0,0 +1,29 @@ +# dotnet-reversing + +ILSpy-backed decompilation and static analysis for .NET assemblies (`.dll` / `.exe`). One agent (`dotnet-reversing-agent`) over a Python toolset that drives [ILSpy](https://github.com/icsharpcode/ILSpy) through `pythonnet`/CoreCLR: scan a directory for binaries, walk namespaces and types, decompile a type or specific methods to C#, search IL operands for API usage, and trace call flows across assemblies to a target method. Targets don't have to be on disk — it can pull a NuGet package or extract .NET assemblies straight out of a Microsoft Container Registry image (HTTP-only, the container is never run). + +**Shape:** one agent, two skills (`dotnet-reversing` for the decompilation workflow, `mcr-analysis` for MCR image extraction), and a Python `@tool` surface — no MCP server. The reversing tools run in a persistent subprocess pinned to **Python 3.12** (a `pythonnet` requirement); the parent process proxies calls to it over a local HTTP port. + +## Setup + +There is no manifest config to fill in — the toolset **bootstraps its own backend on first use**. The first `dotnet_*` tool call spawns the subprocess (via `uv run --python 3.12 --with pythonnet`), and that subprocess downloads, if not already present: + +| Component | Version | Source | +|---|---|---| +| .NET runtime (runtime-only, no SDK) | channel `8.0` | `dot.net/v1/dotnet-install.sh` (~100 MB) | +| ILSpy decompiler DLLs (`ICSharpCode.Decompiler.dll`, `Mono.Cecil.dll`) | `8.2.0.7535` | ILSpy GitHub releases | +| `pythonnet` | `>=3.0.5` | pip / uv | + +The download is **one-time and idempotent** — subsequent runs detect the installed DLLs and skip it. Dependencies land in a persistent deps directory so they survive sandbox restarts: `/home/user/workspace/.dreadnode/deps` in the Dreadnode sandbox (when `DREADNODE_SANDBOX` is set or the workspace is an S3 mount), `~/.dreadnode/deps` locally. The bootstrap sets `DOTNET_ROOT` and the ILSpy lib path itself; you don't configure them. + +Prerequisites the bootstrap does **not** install for you: `uv` (used to launch the 3.12 subprocess; a `python3.12` with `pythonnet` already present is the fallback), plus `curl` and `unzip` for the downloads. First call needs outbound network to Microsoft and GitHub. + +`CAPABILITY_PORT` (default `9797`) overrides the subprocess HTTP port if it collides; a free port is auto-selected otherwise. + +## Scope + +- **Targets:** managed .NET assemblies — `.dll` and `.exe`. Decompilation is ILSpy's; obfuscated or AOT/native-compiled binaries decompile poorly or not at all. +- **Read-only.** Tools decompile and inspect; nothing patches or writes to the target. Reporting tools persist findings to the Dreadnode platform. +- **NuGet & MCR** are convenience fetchers — `dotnet_download_nuget` pulls from nuget.org, the `mcr_*` tools extract layers from `mcr.microsoft.com` over HTTP without Docker and without executing the image. + +`secure-software` hands off to this capability for .NET assemblies found inside packages (its tools surface under the `dotnet_*` namespace); agent-facing usage — the decompilation and vuln-hunting workflow, tool-by-tool — lives in `skills/`, not here. diff --git a/capabilities/ios-forensics/README.md b/capabilities/ios-forensics/README.md new file mode 100644 index 0000000..bac8ca2 --- /dev/null +++ b/capabilities/ios-forensics/README.md @@ -0,0 +1,55 @@ +# ios-forensics + +A curated [MVT](https://github.com/mvt-project/mvt) (Mobile Verification Toolkit) surface for triaging iOS acquisitions for mercenary-spyware compromise — Pegasus, Predator, QuaDream, RCS, Hermit. The `mvt` MCP wraps the `mvt-ios` CLI behind verb-named tools (device info, installed apps, configuration profiles, TCC grants, data usage, SMS, calls, Safari, shutdown log) plus a STIX-IoC sweep that correlates every module against published indicator feeds. Backup-native helpers (`Manifest.db` resolution, read-only SQLite, plist parsing) let the agent pivot a flagged record into the underlying artifact. The `ios-forensics-analyst` agent drives the whole loop: identify → triage → focused hunt → extract → report. + +This is triage, not chain-of-custody forensics. It tells you whether a device looks compromised and pins findings to specific artifacts; it does not produce court-grade evidence packages or perform acquisition. + +**Shape:** one agent (`ios-forensics-analyst`), one MCP server (`mvt`, ~19 tools), five playbook skills (image triage, spyware hunt, communications analysis, activity reconstruction, config/persistence review). Sibling capability `memory-forensics` mirrors this shape for memory images. + +## Setup + +**1. Install MVT.** The MCP does not vendor it. It resolves the command as `MVT_COMMAND` → `mvt-ios` on `PATH` → a PEP 723 fallback that runs the `mvt` package installed into the `uv` venv. The fallback works, but install MVT explicitly so the version is yours to control: + +``` +pipx install mvt # or: uv tool install mvt +``` + +**2. Produce an input.** MVT reads one of two source kinds — every tool takes a `source_kind`: + +| `source_kind` | What it is | How to get it | +|---|---|---| +| `backup` | iTunes/Finder backup directory | Finder (or `idevicebackup2 backup` from libimobiledevice). **Enable encryption** before backing up — it pulls Health, keychain metadata, and more that an unencrypted backup omits. | +| `fs` | Full-filesystem extraction | A jailbreak / `checkm8`-class acquisition (commercial tooling or `palera1n`-style). | + +Most modules run on a backup. A handful are FFS-only and are the highest-signal spyware artifacts — `shutdown_log`, PowerLog, WebKit DataStore/resource logs, crash `.ips` files. If you only have a backup, the agent will say so rather than fabricate a verdict. + +Encrypted backups: supply the password to `mvt_decrypt_backup`, which writes a decrypted working copy. The password is passed to `mvt-ios` as a CLI argument, so it is briefly visible to local process listings while the subprocess runs. + +**3. Bring STIX IoCs.** Spyware detection is only as current as the indicators you feed it. MVT correlates modules against STIX2 IoC files supplied via the `iocs=` parameter — these are **not** bundled. Pull the latest from [Amnesty's Security Lab](https://github.com/AmnestyTech/investigations), Citizen Lab, Kaspersky GReAT, or Volexity, or hand-write a minimal STIX2 file for custom indicators. Absence of STIX hits is not a clean verdict; feeds lag live campaigns by weeks to months. + +### Tuning + +No credentials or secrets. Optional environment variables: + +| Var | Default | Change when | +|---|---|---| +| `MVT_COMMAND` | unset | You want a specific `mvt-ios` binary (e.g. a pinned venv) instead of `PATH` resolution. | +| `MVT_TIMEOUT` | `900` (s) | A module on a large FFS times out; raise it. Per-subprocess. | +| `MVT_MAX_OUTPUT_CHARS` | `200000` | Tool output is truncating mid-analysis and your context budget can absorb more. | + +## Usage + +Drive it through the agent: + +``` +>>> @ios-forensics-analyst triage the backup at ~/cases/device-01 with the Amnesty STIX feed at ~/iocs/amnesty.stix2.json +``` + +It runs `mvt_status` → `mvt_info` to fix device context, sweeps the high-signal modules, runs the STIX correlation, then pivots any hit into the underlying SQLite/plist record. The five skills carry the per-phase methodology; the agent loads them as evidence demands. + +## Before you trust it + +- **Triage scope, not custody.** Findings are evidence-pinned but this is not an acquisition or chain-of-custody tool. Treat suspected mercenary-spyware findings as sensitive — default to minimum distribution until victims and legal/human-rights stakeholders are briefed. +- **Backups underperform FFS.** The most diagnostic spyware artifacts (shutdown_log, WebKit DataStore, crash logs) only exist in a full-filesystem extraction. A clean backup sweep is not an all-clear. +- **IoC currency is on you.** Detection depends entirely on the STIX feed you supply and when it was last updated. +- **No tests ship** for the MCP server. The SQLite helpers open read-only with `ATTACH`/`DETACH` denied at the authorizer, so query tools can't write or reach beyond the named database. diff --git a/capabilities/memory-forensics/README.md b/capabilities/memory-forensics/README.md new file mode 100644 index 0000000..8d36494 --- /dev/null +++ b/capabilities/memory-forensics/README.md @@ -0,0 +1,36 @@ +# memory-forensics + +A curated Volatility3 surface for memory forensics and DFIR triage over captured memory images. The `volatility` MCP wraps the Volatility3 CLI with action-named tools for the artifacts an analyst actually pivots through — process enumeration and tree, pool-tag scanning for hidden processes, network endpoints, code-injection (malfind), DLLs and handles, registry hives/keys, credential extraction (hashdump), services, YARA scanning, process dumping, and a cross-plugin timeline — plus an escape hatch (`volatility_run_plugin`) for the long tail. Windows / Linux / macOS images are all in scope; most tools take an `os_kind` you resolve once with `volatility_info`. + +**Shape:** one agent (`forensics-analyst`, read-only DFIR posture), five skills (memory-triage, process-injection-hunt, credential-theft-hunt, persistence-hunt, yara-memory-hunting), one MCP server (`volatility`). Sibling `ios-forensics` is the same shape for iOS device images — this one is host memory. + +## Setup + +The MCP self-bootstraps via `uv run` (PEP 723 deps: `fastmcp`, `volatility3>=2.7`, `yara-python`), so `uv` is the only hard prerequisite (`checks:` enforces it). Volatility3 itself is pulled in by that bootstrap, but you can point at a system install instead — the server resolves the command in this order: + +1. `VOLATILITY_COMMAND` if set (e.g. `vol`, or a full command string) +2. `vol` on `PATH` +3. the `volatility3.cli` entry point under the bootstrapped interpreter + +So no separate install is required for a default run; set `VOLATILITY_COMMAND` only when you want a specific `vol` (e.g. a build with extra community plugins). + +**Symbol tables are the classic friction.** Vol3 fetches PDBs from the Microsoft symbol server on the first plugin run against a Windows image, and Linux/Mac images need a matching ISF symbol table. First-run plugins on a fresh host will hang or fail until symbols resolve. For air-gapped or offline work, prime a symbol cache and pass it through the escape hatch (`volatility_run_plugin` with Vol3's `-s ` / `--offline`) — the curated tools don't expose a symbol-dir flag of their own. See [Volatility3 Symbol Tables](https://volatility3.readthedocs.io/en/stable/symbol-tables.html). + +**Image formats:** raw/padded images and the formats Vol3 reads natively — `.mem`, `.raw`, `.vmem`, `.dmp`, `.lime`, `.bin`, `.aff4`. Pass an absolute path; the server checks the file exists before invoking Vol3. + +| Var | Default | Notes | +|---|---|---| +| `VOLATILITY_COMMAND` | unset | Force a specific `vol` command; otherwise resolved as above. | +| `VOLATILITY_TIMEOUT` | `600` | Per-plugin timeout (seconds). Long plugins (`memmap`, `timeliner`, whole-image `yarascan`) blow this on multi-GB images — scope by `--pid` first, then raise. | +| `VOLATILITY_MAX_OUTPUT_CHARS` | `200000` | Tool output is truncated past this; raise for verbose plugins. | + +Configure these through the deployer environment (secrets/settings screen or web app — no `.env` autoload). + +## Before you trust it + +- **Symbols gate everything.** A plugin that "returns nothing" on first run is often an unresolved symbol table, not a clean image — confirm `volatility_info` succeeds before reading absence as signal. +- **JSON schemas drift across Vol3 versions.** `-r json` field names are stable within a minor version but not across; `volatility_list_plugins` shows what the local Vol3 actually ships before you rely on a plugin name. +- **Read-only by design** — the agent acquires nothing and modifies no evidence; the one writing tool (`volatility_dump_process`) only emits carved artifacts into an `output_dir` you name. +- **`volatility_dump_process` `pe` mode** routes through `pslist` rather than a dedicated dumper; `vad` (the default) is the right mode for hunting injected regions. + +Tests: `mcp/test_server.py` covers helpers and tool registration. The analysis playbooks (which plugin to run when, MITRE mapping, hunt sequencing) live in `skills/`, not here. diff --git a/capabilities/mythic-c2-readonly/README.md b/capabilities/mythic-c2-readonly/README.md index dc90cc5..36249dd 100644 --- a/capabilities/mythic-c2-readonly/README.md +++ b/capabilities/mythic-c2-readonly/README.md @@ -2,6 +2,8 @@ Read-only Mythic C2 integration. Query callbacks, task history, credentials, downloaded files, artifacts, and more — without executing any commands or modifying Mythic state. +For active tasking, Apollo post-exploitation, or the AI-annotation worker, use the `mythic-c2` capability — it is the superset (same observation surface plus opt-in active features). This one has no active surface at all. + ## Prerequisites - Python 3.11+ diff --git a/capabilities/mythic-c2/README.md b/capabilities/mythic-c2/README.md new file mode 100644 index 0000000..3b828d5 --- /dev/null +++ b/capabilities/mythic-c2/README.md @@ -0,0 +1,32 @@ +# mythic-c2 + +Integration with [Mythic](https://github.com/its-a-feature/Mythic) C2. **Observation-only by default** — read callbacks, tasks, credentials, files, artifacts, keylogs, screenshots, processes, tokens, BloodHound discovery, and operation summaries from a running Mythic server. Optional flags add active tasking, Apollo post-exploitation, and a background worker that writes AI findings back onto Mythic's own surfaces. + +For a strictly read-only deployment with no active surface at all, use the sibling `mythic-c2-readonly`. This capability is the superset: the same observation surface, plus the opt-in active and triage features below. + +## Setup + +Point it at your Mythic server via the secrets screen (`/secrets`, F7) — these vars are shared by the MCP server and the worker: + +| Var | Notes | +|---|---| +| `MYTHIC_SERVER_IP` | Mythic host (default `127.0.0.1`). | +| `MYTHIC_SERVER_PORT` | Mythic port. | +| `MYTHIC_USERNAME` / `MYTHIC_PASSWORD` | Operator login (username defaults to `mythic_admin`). | +| `MYTHIC_API_TOKEN` | Use instead of username/password if you have one. | + +### Flags — all off by default + +Off means observation-only; the capability does nothing active until you opt in (`/capabilities` → reload after changing). + +| Flag | Registers | Risk | +|---|---|---| +| `tasking` | Generic `issue_task` + `list_callback_commands` — works for any payload type (Apollo, Poseidon, Merlin, …) | Issues live commands to implants | +| `apollo` | Apollo-specific multi-step helpers (`sharphound_and_download`, `powershell_script`, …) | Active post-exploitation | +| `triage` | The `task-annotator` worker — reviews completed tasks, keylogs, and downloads in the background and writes findings onto Mythic (task comments, severity/category tags, event log, cross-object `ai:trail` tags) | Mutates your Mythic operation's surfaces | + +## Before you trust it + +- **With `tasking` or `apollo` on, this executes post-exploitation** against live implants — not a reporting tool. Authorization and scope are yours. +- **The `triage` worker writes to your Mythic operation** — comments, tags, and event-log entries appear under the operator identity. It runs continuously while the flag is set (and exits cleanly on boot when unset). +- Three agents (`operator`, `correlator`, `task-analyzer`) drive these surfaces; their methodology lives in the agent prompts (`agents/`) and `docs/`, not here. diff --git a/capabilities/network-ops/README.md b/capabilities/network-ops/README.md new file mode 100644 index 0000000..d67a9d2 --- /dev/null +++ b/capabilities/network-ops/README.md @@ -0,0 +1,59 @@ +# network-ops + +A single autonomous agent (`network-ops-agent`) driving a full Active Directory exploitation toolbelt. Point it at an authorized lab network and it runs the kill chain end to end — discovery, enumeration, initial access, privilege escalation, credential harvesting — without stopping to ask. The agent's goal is blunt: compromise every domain it can reach. The Python toolsets are thin wrappers that shell out to the heavy offensive binaries practitioners already use (nmap, NetExec, Impacket, Certipy, bloodyAD, krbrelayx, Hashcat / John, smbclient, SharpView); the agent decides which to fire and when, and logs findings with `report_item` as it goes. + +## Setup + +The friction here is the toolchain, not the wiring. Each toolset is a wrapper — the actual work happens in external binaries that this capability does **not** install. The manifest ships no `checks:`, so nothing fails closed: a missing binary surfaces as a runtime warning when that toolset initializes, not as a pre-flight error. Stand it up on a host (a Kali box or equivalent pentest image is the path of least resistance) where these are already present: + +| Toolset | Needs on PATH / disk | Install | +|---|---|---| +| nmap | `nmap` | distro package | +| netexec | `nxc` | `pipx install netexec` | +| impacket | `secretsdump.py` & friends (auto-discovered on PATH, pip site-packages, or apt examples dir) | `pipx install impacket` | +| certipy | `certipy` (pip) or `certipy-ad` (Kali) — auto-detected | `pip install certipy-ad` | +| bloodyad | `bloodyAD` | `pip install bloodyAD` | +| krbrelayx | scripts under `/opt/krbrelayx/` (override via `script_path`) | `git clone https://github.com/dirkjanm/krbrelayx` | +| cracking | `hashcat` and/or `john`; wordlist at `/usr/share/wordlists/rockyou.txt` | distro packages + rockyou | +| smbclient | `smbclient` | distro `smbclient` package | +| sharpview | `SharpView.exe` (.NET, Windows) or a Mythic C2 / Apollo session for remote execution | drop the binary on PATH | +| reporting | none — logs structured findings into the Dreadnode run | — | + +SharpView is the odd one: it's a Windows .NET assembly. Run it locally on a Windows host, or pass an Apollo instance so it executes remotely over Mythic C2. With neither, the rest of the toolbelt still operates. + +## What's in the box + +Ten toolsets, grouped by where they land in the chain: + +**Recon & enumeration** +- **nmap** — host / port / service discovery (quick top-100 sweep or arbitrary nmap args). +- **netexec** (`nxc`) — SMB / LDAP / WinRM / MSSQL / SSH / RDP enumeration and credential spraying across protocols. +- **sharpview** — PowerView-style AD object enumeration (users, groups, ACLs, trusts) via the .NET SharpView port. +- **smbclient** — recursive share listing and file pull with recovered creds. + +**Access & escalation** +- **impacket** — the workhorse: AS-REP roasting, Kerberoasting, secretsdump (SAM / NTDS), RBCD / delegation / DACL abuse over the Impacket example scripts. +- **certipy** — AD CS (certificate services) enumeration and template-vulnerability abuse (ESC1-ESC8 class attacks). +- **bloodyad** — LDAP-based privilege escalation: password resets, group-membership edits, DACL writes against the DC. +- **krbrelayx** — Kerberos relay and unconstrained-delegation abuse, SPN add / manipulation. + +**Post-exploitation** +- **cracking** — Hashcat and/or John the Ripper for Kerberos and NTLM hashes (time-boxed; defaults to rockyou). +- **reporting** — `report_item` writes structured findings (hosts, DCs, credentials, hashes, shares, weaknesses) into the run as the agent discovers them. + +## Usage + +Drive it through the agent: + +``` +>>> @network-ops-agent compromise the lab domain at 10.0.0.0/24 +``` + +It scans, enumerates, roasts and sprays, escalates through whatever AD CS / delegation / DACL paths it finds, dumps and cracks hashes, and reports findings throughout — autonomously, no human in the loop mid-run. + +## Before you trust it + +- **This is fully active, offensive tooling.** Every toolset touches the target — scanning, authenticating, dumping, relaying, modifying directory objects. There is no passive or read-only mode. Run it **only** against networks you are explicitly authorized to test. +- **The agent is built for a lab.** Its prompt assumes a CTF-style "compromise every domain" objective and a couple of hardcoded out-of-scope accounts (`vagrant`, `ansible`). It will not self-limit beyond that — scope control is the operator's job, enforced by where you point it. +- **It mutates the directory.** bloodyAD, Certipy, and Impacket can reset passwords, alter group membership, write DACLs, and request certificates. These are not reversible by the agent. Expect state change in the target domain. +- **No `checks:` and no tests ship.** Missing binaries degrade silently to runtime warnings per toolset, and there's no test harness over the wrappers — verify your toolchain before a real run. diff --git a/capabilities/secure-software/README.md b/capabilities/secure-software/README.md new file mode 100644 index 0000000..31b0304 --- /dev/null +++ b/capabilities/secure-software/README.md @@ -0,0 +1,43 @@ +# secure-software + +Package supply-chain analysis built on the ReversingLabs [secure.software](https://www.secure.software/) (Spectra Assure) Community catalogue — millions of pre-analysed open-source package versions, searchable by purl or hash. The `secure-software` agent pins a package to an exact version, pulls RL's malware / vulnerability / hygiene report, then enriches with OSV (known CVEs) and OpenSSF Scorecard (repo health). For artifacts that need a closer look it imports them into your Portal, exports SBOMs (CycloneDX / SPDX / SARIF), downloads the file, and runs native static triage — extract, hash, strings, entropy, YARA. + +**vs. [`spectra-assure`](../spectra-assure):** that sibling is a Docker MCP wrapping RL's Portal *scanner* for deep behavioral binary analysis (`rl_protect_scan` / `_diff_behavior`); this one is native Python over the secure.software Community *catalogue search* plus OSV / Scorecard enrichment — no Docker, no scanner, free-tier-first. Reach for `spectra-assure` to scan an artifact you hold; reach for `secure-software` to look one up. + +## What's in the box + +| Component | Purpose | +|---|---| +| `agents/secure-software` | Autonomous analyst — pins versions, cites every finding to a source, hands binaries off to reversing tools | +| `skills/package-triage` | One package, deep, verdict wanted | +| `skills/supply-chain-analysis` | A manifest / lockfile, broad coverage, SBOM + ranked action list | +| `skills/enrichment-playbook` | An artifact already on disk, every usable static signal | +| `tools/spectra.py` | secure.software Community search + version reports (free tier) and Portal import / status / report export / artifact download | +| `tools/enrich.py` | Ecosystem download (npm/pypi/gem/cargo/maven/nuget/go), archive extract + per-file hashing, strings / entropy / YARA, OSV and Scorecard lookups | + +## Setup + +The capability self-bootstraps via `uv run`; supply config through the deployer environment (secrets screen or web app — no `.env` autoload). + +| Var | Default | Notes | +|---|---|---| +| `SPECTRA_ASSURE_TOKEN` | **none — fails closed** | Required for any secure.software call. Create a Personal Access Token in the Portal (Account settings). The first API call raises if unset. | +| `SPECTRA_ASSURE_HOST` | `my.secure.software` | Portal host. | +| `SPECTRA_ASSURE_PATH` | `demo` | Portal slug after the host. | +| `SPECTRA_ASSURE_ORG` / `SPECTRA_ASSURE_GROUP` | none | Required **only** for Portal import / export / download. Community search and version reports work without them. | +| `SECURE_SOFTWARE_DIR` | `~/workspace/secure-software` | Where downloads, extractions, and SBOM exports land. Responses carry paths, not contents. | + +OSV.dev and OpenSSF Scorecard are unauthenticated; `yara_scan` needs `yara-python` installed (it degrades gracefully and tells you if it's missing). + +## Scope + +- **Report / SBOM formats** (Portal export): `cyclonedx`, `spdx`, `sarif`, `rl-json`, `rl-cve`, `rl-checks`, `rl-diff`, `rl-uri`, `rl-summary-pdf`. +- **Read-only against secure.software** — the only writes are files under `SECURE_SOFTWARE_DIR`. `clean_workdir` is the one destructive tool and is fenced to that directory. +- **Chains into `dotnet-reversing`** — when an extracted artifact contains .NET assemblies, the agent hands the file paths to the `dotnet_*` tools rather than analysing binaries inline. + +## Usage + +``` +>>> @secure-software is pkg:pypi/requests@2.31.0 safe to adopt? +>>> @secure-software audit the dependencies in ./requirements.txt and rank by risk +``` diff --git a/capabilities/sliver-c2/README.md b/capabilities/sliver-c2/README.md new file mode 100644 index 0000000..108bde9 --- /dev/null +++ b/capabilities/sliver-c2/README.md @@ -0,0 +1,27 @@ +# sliver-c2 + +Wires a [Sliver](https://github.com/BishopFox/sliver) C2 server into chat and agents over the `sliver-py` SDK. Covers operator-side server management (list sessions/beacons, start mTLS/HTTPS/HTTP/DNS listeners, kill jobs, regenerate implants) and full implant post-exploitation against the active session/beacon — file ops, process control, `execute-assembly`, shellcode injection, sideloading, token manipulation, registry r/w, and LSASS-style process dumps. This is **active offense, not telemetry**: unlike the `mythic-c2`/`mythic-c2-readonly` split there is no read-only mode here — every implant tool runs commands on and mutates the target. + +## Setup + +The MCP connects with a Sliver **operator config** (`.cfg`) — the file `new-operator` mints, carrying the embedded mTLS client cert/key and the server address. Resolution order: + +1. `SLIVER_CONFIG_FILE` — explicit path to a `.cfg`. +2. Auto-discovery — newest `*.cfg` in `~/.sliver-client/configs/` (where the Sliver client drops imported operator configs). + +For a remote server, enable **Multiplayer Mode** on the server, generate an operator config, and point `SLIVER_CONFIG_FILE` at it. For Claude Code, set it in `.claude/settings.json`: + +```json +{ "env": { "SLIVER_CONFIG_FILE": "/path/to/operator.cfg" } } +``` + +`SLIVER_TIMEOUT` (default `60` s) bounds per-call gRPC waits; raise it for slow beacons or large transfers. The `connect` tool re-points at a config at runtime; `interact(implant_id, implant_type=)` selects the active implant before any post-ex tool. + +## Before you trust it + +- **Active-only, no guardrail.** The server has no read-only flag — `rm`, `execute_shellcode`, `get_system`, `process_dump`, `registry_write` all mutate the target the moment they're called. Only run against engagements you're **explicitly authorized** to operate, and treat agent autonomy here as live tradecraft. +- **One implant at a time.** `interact()` sets a single global active session/beacon; post-ex tools act on whatever was last selected. +- **Beacons are async.** Calls against a beacon block until its next check-in (interval + jitter), so they can hang for a while — size `SLIVER_TIMEOUT` accordingly. +- **Wraps `sliver-py`, not the upstream MCP.** Sliver ships its own experimental `sliver-client mcp` (stdio/HTTP-SSE); we deliberately build on the stable `sliver-py` SDK instead for a curated, typed tool surface. + +`docs/sliver/` is a vendored snapshot of the official Sliver wiki (GPLv3, see `docs/sliver/LICENSE`) for reference. Agent-facing tradecraft — sessions-vs-beacons posture, post-ex workflow, OPSEC — lives in `skills/sliver-c2/`, not here. diff --git a/capabilities/spectra-assure/README.md b/capabilities/spectra-assure/README.md index c7a5d60..340edeb 100644 --- a/capabilities/spectra-assure/README.md +++ b/capabilities/spectra-assure/README.md @@ -5,6 +5,8 @@ Software supply chain security capability for Dreadnode, powered by via the [rl-mcp-community](https://github.com/reversinglabs/rl-mcp-community) MCP server. +This wraps the Portal scanner (a Docker MCP) for deep behavioral binary analysis. For lightweight supply-chain lookups — secure.software Community catalogue search by purl/hash, plus OSV/Scorecard enrichment — see the sibling `secure-software` capability. + ## What's in the box | Component | Purpose | diff --git a/capabilities/web-security/README.md b/capabilities/web-security/README.md new file mode 100644 index 0000000..bcf9cd1 --- /dev/null +++ b/capabilities/web-security/README.md @@ -0,0 +1,42 @@ +# web-security + +An autonomous web-application penetration-testing capability: a single agent runs OODA-loop testing against a live target, backed by 68 attack-technique playbooks (skills) and a proxy + recon toolchain. The agent maps the surface, selects attack classes from the playbooks, and works them to proof — request smuggling, cache poisoning, SSRF, SSTI, DOM/client-side, auth bypasses, parser differentials, AEM/Sling, and more. + +**Shape:** one agent (`web-security`, autonomous), 68 skills grouped by attack family (loaded on demand — not enumerated here), ~9 HTTP/recon tool modules, and 10 MCP servers. + +## MCP servers + +| Server | Role | +|---|---| +| `caido`, `burp` | Intercepting proxies — Caido (host SDK) and Burp (external, see setup) | +| `agent-browser` | Headless Chromium for DOM interaction | +| `jxscout` | JavaScript recon — wraps `jxscout-pro-v2` and its SQLite projects | +| `protoscope` | Protobuf inspection | +| `thermoptic` | Local browser-fingerprint HTTP camouflage proxy | +| `hackerone` | Query programs, scopes, reports, hacktivity | +| `jira`, `github`, `linear` | File findings into trackers (token-gated — see setup) | + +## Setup + +This is the most install-heavy capability in the catalog — the agent and MCP servers shell out to a large external toolchain. + +**Toolchain.** On a hosted sandbox the runtime provisions everything automatically from `scripts/install_tools.sh` (Go + ProjectDiscovery tools via `pdtm`, katana, protoscope, interactsh-client, kiterunner, surf, 2fa, caido-cli) plus the `default-jre-headless` package. For local dev, `docker/Dockerfile.runtime` bundles the same binaries — build and run it, or run `install_tools.sh` yourself. The `checks:` block surfaces anything missing (nuclei, httpx, interactsh-client, protoscope, caido-cli, waymore, jxscout, and Burp at `/opt/burp/burpsuite.jar`) in the capability manager. + +**Burp is external**, not bundled — the capability expects a Burp instance exposing the MCP endpoint at `http://127.0.0.1:9876/`. Start Burp (with its MCP extension) before relying on the `burp` server; the other nine servers self-bootstrap via `uv run`. + +**Optional integration credentials** — set via the secrets screen only for the servers you want live: + +| Var | Enables | +|---|---| +| `JIRA_BASE_URL` / `JIRA_EMAIL` / `JIRA_API_TOKEN` | `jira` | +| `GITHUB_TOKEN` (+ `GITHUB_API_URL` for Enterprise) | `github` | +| `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN` | `linear` | +| `CAIDO_URL` / `CAIDO_PAT` | `caido` (or its device-flow login) | + +HackerOne and the proxies work without extra secrets once the toolchain is present. + +## Before you trust it + +- **Active, autonomous penetration testing.** The agent plans and executes attacks against a live target on its own, in continuous OODA loops, and is built to be exhaustive. Only point it at targets you are explicitly authorized to test, and scope it deliberately. +- **It generates real attacker traffic** — OOB callbacks (interactsh), crawling, fuzzing, payload delivery. Expect noise and load on the target. +- Attack methodology, payloads, and per-class playbooks live in `skills/` — that's the agent's knowledge base and where to look when extending it.