Skip to content

cbh-cli.md

Latest commit

 

History

History
218 lines (155 loc) · 10.9 KB

cbh-cli.md

File metadata and controls

218 lines (155 loc) · 10.9 KB

cbh — claude-bughunter CLI

Secondary interface — slash commands are primary. Inside a Claude Code conversation, use the slash commands (/recon, /hunt, /triage, /report, /validate, /chain, /autopilot, /scope, etc.) — they leverage the full skill content and the LLM's judgment.

cbh is the terminal-native deterministic runner — use it when you're outside Claude Code, automating in CI/CD, running scheduled recon, or verifying labs reproducibly. Same skills, different execution model.

When to use cbh vs slash commands

Use case Use this
Hunting a new target conversationally, applying judgment Slash commands in Claude Code (/hunt, /triage, etc.)
Building a chain across multiple primitives Slash commands — LLM keeps state across the conversation
Scheduled / CI / scripted runs cbh — deterministic exit codes, identical output across runs
Bulk passive recon (hundreds of subdomains) cbh recon — real subfinder/dig/curl, no LLM in the loop
Verifying labs / reproducing claims cbh — every Phase 2 doc's curls work via cbh too
Reading skills without Claude Code installed cbh + browsing skills/ and docs/disclosed-reports/
Triage gate at PR time / pre-submit linting cbh triage — deterministic keyword-match against the 7-Question Gate

The two interfaces consume the same content (skills/ + docs/disclosed-reports/). They produce different outputs because they execute differently. Pick by context, not by preference.

Operating modes for the CLI

Stdlib + optional subfinder for richer recon. No build step.

Two HTTP-routing modes within the CLI — pick what fits your setup:

  1. Curl-only (default) — stdlib HTTP, no Burp dependency. Works on any laptop with Python 3.9+.
  2. Burp Suite integration — --burp flag routes everything through Burp's proxy (default 127.0.0.1:8080). Requests + responses land in Proxy → HTTP history; you can send any of them to Repeater/Intruder/Scanner/Collaborator. Pairs with the Burp MCP server (port 9876) for Claude-Code-conversational hunting.

Install

# Symlink the script to PATH (Linux / macOS)
chmod +x scripts/cbh.py
ln -sf "$(pwd)/scripts/cbh.py" /usr/local/bin/cbh

# Verify
cbh --help

Or run inline from a repo checkout:

scripts/cbh.py --help

Operating modes

Mode 1 — Curl-only (default)

Works out of the box. All HTTP goes via Python urllib. No Burp required.

cbh recon hackerone.com
cbh classify "https://api.target.com/v1/users/42?next=..."

Mode 2 — Burp Suite Pro integration

Two integration points:

A. --burp flag — proxy routing. Routes every HTTP request cbh makes through Burp's proxy. Every request + response shows up in Burp Proxy → HTTP history with full reqs/resps captured for replay.

# Start Burp Suite Pro, ensure Proxy listener is on 127.0.0.1:8080
cbh recon hackerone.com --burp
cbh classify "https://target.com/api/users/42" --burp

# Or use a custom proxy URL (Burp on a different port, mitmproxy, ZAP, etc.)
cbh recon hackerone.com --proxy http://127.0.0.1:8081

# Or set the env var once
export CBH_BURP_PROXY=http://127.0.0.1:8080
cbh recon target.com   # auto-detected

What happens after: every host cbh recon probes appears in Burp's Target → Site map. Each title-extracted live host is one click from Repeater. You drive the actual attacks from Burp; cbh did the bulk discovery + classification.

B. Burp MCP — conversational hunting via Claude Code. If you've installed the Burp MCP server BApp extension (typical port 127.0.0.1:9876) and registered it with Claude Code via claude mcp add burp -s user -- java -jar ~/.BurpSuite/mcp-proxy/mcp-proxy-all.jar, you can do the hunt loop entirely in a Claude conversation:

You:  cbh classified /api/users/42 as IDOR-prone. Send it to Burp Repeater
      with X-User-Id: 99 swapped in.
LLM:  [uses Burp MCP tool calls: get last response, send to Repeater with
       header swap, returns the new response]
You:  Looks like cross-tenant read. Apply triage-validation 7-Question Gate.
LLM:  [reads hunt-idor + triage-validation skills, runs 7Q against the
       captured req/resp pair, returns PASS/DOWNGRADE/KILL]

This mode is the most ergonomic — the LLM drives Burp via MCP while consulting the skill content. cbh and Burp MCP are complementary: cbh is fast at bulk classification + structured triage; Burp MCP is fast at deep individual-request analysis.

When to use which mode

Phase Curl-only Burp proxy Burp MCP
Recon (bulk subdomain + HTTP probe of 50+ hosts) ✓ fastest ✓ + audit trail overkill
Single-URL classification ✓ ✓ + traffic captured ✓ (conversational)
Detailed request manipulation (header swap, body fuzz, Intruder) painful ✓ (Repeater/Intruder) ✓ (LLM-driven)
Triage + report drafting ✓ ✓ ✓
Discipline-rule enforcement (OOB gate, marker discipline, body-diff) manual manual ✓ (LLM can apply the rules)

Operator default: --burp mode if Burp Suite Pro is open; curl-only mode otherwise. Burp MCP mode for engagements where you want maximum LLM-driven workflow inside Claude Code.

The four subcommands

cbh recon <target> — passive recon + live-host probe

cbh recon hackerone.com

Pipeline (in order):

  1. Passive subdomain enumeration — crt.sh certificate transparency (always, no key needed) + subfinder (if installed) merged + deduplicated.
  2. DNS resolution — stdlib socket.getaddrinfo() to dodge the dnsx segfault issue documented on macOS arm64 (per web2-recon Operator Notes).
  3. HTTP probe — concurrent (10 threads) urllib.request → status code, Server header, X-Powered-By, X-Drupal-Cache, and <title> extraction.
  4. Summary — writes recon/<target>/RECON_SUMMARY.md with the live-host table and a "Suggested next moves" pointer to classify.

Outputs:

  • recon/<target>/subdomains.txt
  • recon/<target>/resolved.txt
  • recon/<target>/live-hosts.json
  • recon/<target>/RECON_SUMMARY.md

cbh classify <url> — pattern-match URL → hunt-* skills

cbh classify "https://api.target.com/v1/users/42?next=https://evil.com"

Two-stage matcher:

  1. URL-pattern triggers (high confidence) — 18 hand-curated regexes mapping URL shapes to hunt-* skill names. Examples:
    • [?&](url|next|redirect|return)= → hunt-ssrf
    • /api/users/{id} → hunt-idor + hunt-api-misconfig
    • /graphql → hunt-graphql
    • /oauth/(authorize|token|callback) → hunt-oauth
    • /_layouts/15/ or /_vti_bin/ → hunt-sharepoint
    • /functionRouter → hunt-rce + hunt-ssti (Spring Cloud Function CVE-2022-22963)
    • /cli or /jnlpJars → hunt-rce (Jenkins CVE-2024-23897)
  2. Description-keyword match (lower confidence) — keyword overlap against each skill's description: frontmatter.

Output includes a pointer to the matched skill's Pattern Library doc in docs/disclosed-reports/<skill>.md when one exists.

cbh triage <finding.md> — 7-Question Gate

cbh triage findings/idor-2026-05-15.md

Runs all 7 questions from the triage-validation skill against the finding text. Returns:

  • PASS — all 7 answered with evidence. Eligible for cbh report.
  • DOWNGRADE — failed Q2 (severity) or Q5 (duplication) only. Continue with tempered severity claim.
  • KILL — failed multiple questions OR Q7 matched the never-submit list (self-XSS, missing security headers, etc.). Per triage-validation discipline: do not draft the report.

The gate matches keyword signals per question; absence-of-evidence is treated as "not answered". This catches the most common Phase 2D-verified FP shapes:

  • Q1 missing curl/POST/GET → finding wasn't actually tested
  • Q6 missing "leaked / exfiltrated / oob callback" → impact is "technically possible" only
  • Q7 hit on "self-xss / rate-limit only / clickjacking" → automatic KILL

cbh report <finding.md> [--platform h1|bugcrowd|intigriti|immunefi] [--out path]

cbh report findings/idor-2026-05-15.md --platform bugcrowd --out submissions/h1-draft.md

Parses the finding's YAML frontmatter + section headings, emits a platform-specific draft:

  • H1 — common template; CVSS optional.
  • Bugcrowd — adds VRT mapping + severity-request paragraph (per bugcrowd-reporting skill).
  • Intigriti — common template + CVSS 3.1 vector slot.
  • Immunefi — Foundry-PoC-required structure; forge test --match-test invocation pre-filled.

The draft will have (fill in) placeholders wherever the finding text didn't include the relevant section. The CLI never invents content — the operator owns each placeholder.

Composition example — full engagement loop

# Day 1 — intake
cbh recon target.com
# → recon/target.com/RECON_SUMMARY.md

# Day 2 — hunt
# Find an interesting URL in the recon summary, classify it
cbh classify "https://api.target.com/v1/users/42?token=abc"
# → matches hunt-idor + hunt-api-misconfig + hunt-ssrf
# → read docs/disclosed-reports/hunt-idor.md for the IDOR pattern library

# Day 3 — validate
# Wrote the finding up as a markdown
cbh triage findings/idor.md
# → PASS — eligible for report drafting

# Day 4 — submit
cbh report findings/idor.md --platform h1 --out drafts/h1-draft.md
# Review the draft, fill in placeholders, attach evidence, submit

What the CLI does NOT do

  • Does not auto-attack. It surfaces candidates and applies discipline rules. The operator runs the actual probes.
  • Does not invent finding content. Sections without source text become (fill in) placeholders.
  • Does not bypass platform rules. The Bugcrowd VRT mapping is left to the operator — the CLI emits the structural slot, not the choice.
  • Does not replace the skill content. The CLI is a router into the skill content; the skills are still where the operator-grade depth lives.

Why this exists

Every other bug-bounty toolchain is either (a) a payload list with no methodology, or (b) a methodology PDF with no runner. This CLI bridges the two: it consumes the repo's skill content and produces engagement-stage outputs. The recon → classify → triage → report flow mirrors the 6-phase workflow that bb-methodology describes, with the discipline rules from triage-validation enforced programmatically at the triage gate.

For senior pentesters: a productivity multiplier that does the boring orchestration so you stay in the interesting parts.

For junior researchers: a guardrail that prevents the top three N/A-submission classes (no real HTTP test, no concrete impact, finding on never-submit list).

Choice not dogma: operators with no Burp run curl-only; operators with Burp Pro route via --burp; operators with Burp + MCP drive everything from a Claude Code conversation. All three are first-class supported.