zwanski2019/zwanski-Bug-Bounty
GitHub: zwanski2019/zwanski-Bug-Bounty
一套以业务逻辑驱动的 Bug Bounty 侦察与漏洞利用方法论框架,附带本地命令中心和 AI 辅助流水线。
Stars: 0 | Forks: 0
# zwanski Bug Bounty 方法论
[](https://github.com/zwanski2019/zwanski-Bug-Bounty/stargazers) [](https://github.com/zwanski2019/zwanski-Bug-Bounty/network/members) [](https://github.com/zwanski2019/zwanski-Bug-Bounty/blob/main/LICENSE)
由从业者构建的、带有明确倾向的侦察与漏洞利用方法论,专注于**大多数猎人会忽略的环节**。
这不是一份工具列表,也不是一份检查清单,而是一个由实际发现作为支撑的思维框架。
**文档:** [仓库内 Wiki](docs/wiki/README.md) · [QUICKSTART.md](QUICKSTART.md) · [INSTALL.md](INSTALL.md) · [PRODUCTION.md](PRODUCTION.md) · [DOCKER.md](DOCKER.md)
## ZWANSKI.BB 命令中心 (本地仪表盘)
本仓库包含一个基于 **Flask + Socket.IO** 的 Web 界面(`ui/index.html`, `server.py`)——一个集成了工具、代理、AI、遥测以及可选 **Zwanski Watchdog** 集成的统一操作面板。
### 启动
```
zwanski start
```
打开 **http://localhost:1337** (或在 `.env` 中设置 `PORT`)。
### UI 包含内容
| 区域 | 功能说明 |
|------|----------------|
| **Command (命令)** | 作战地图 (`/api/warmap`),扫描/重启快捷方式 |
| **Telemetry (遥测)** | 主机健康状态 + 进程 (`/api/system/*`) |
| **Agentic (智能体)** | 多阶段侦察流水线 (`/api/agent/*`) |
| **Arsenal (武器库)** | 工具注册表,命令预览,子域名/OAuth 链 |
| **Watchdog (看门狗)** | `zwanski-watchdog/` 的状态及白名单任务(Docker 基础设施、`pnpm` 开发服务器、扫描器) — [wiki](docs/wiki/watchdog.md) |
| **Terminal (终端)** | xterm 统一流 + 基于 tmux 的并行会话控制 (`/api/term/sessions`) |
| **Intel AI (情报 AI)** | 聊天、评分、KB/RAG、漏洞利用链提示(兼容 OpenRouter) |
| **Reports (报告)** | 报告定稿 API |
| **Config (配置)** | 会话 AI 覆盖配置;`SHADOW_MODE`、`AUTO_GIT_SYNC` 的说明以及安装向导重新启动 |
### 首次启动设置向导
在首次启动仪表盘时,ZWANSKI.BB 会打开一个引导式设置向导,用于检查必需和推荐的先决条件(工具、API 密钥和运行时依赖项)。
清单中的每一项都支持**安装**、**配置**或**跳过**,用户可以通过 **Config → Run setup wizard** 重新执行该流程。
向导 API:
- `GET /api/setup/checklist`
- `POST /api/setup/decision`
- `POST /api/setup/complete`
### Watchdog 环境(可选)
如果您在非默认端口上运行 Watchdog 栈,请在 `.env` 中设置:
- `WATCHDOG_API_URL`(默认 `http://127.0.0.1:4000`)
- `WATCHDOG_WEB_URL`(默认 `http://127.0.0.1:3000`)
- `WATCHDOG_CLASSIFIER_URL`(默认 `http://127.0.0.1:8001`)
完整 API 表:[docs/wiki/api.md](docs/wiki/api.md)。
## 功能特性
- 针对现代 Web、API、OAuth/OIDC 和移动端目标的倾向性 Bug Bounty 方法论
- 带有作战地图、统一终端、系统遥测和代理流水线的**命令中心**
- **Zwanski Watchdog** 选项卡:探测 API/Web/分类器并启动有文档记录的基础设施和开发命令(无任意 shell 执行)
- 本地 **KB / RAG** 钩子以及 AI 辅助评分、链式分析和报告流程
- 用于移动 C2 对齐的 **OpenClaw 桥接**清单(`openclaw_bridge.json`,`GET /api/openclaw/commands`)
- 带有可选 Go 工具链辅助的一键安装器(`install.sh`,`setup-tools.sh`)
- **影子模式**(`SHADOW_MODE=1`),用于在流水线内探测时产生抖动的 HTTP 客户端行为
- 从画像分析到报告的整洁分阶段工作流(`00-setup/` … `08-reporting/`)
## 方法论概述
本方法论被设计为一个链条:业务逻辑、侦察、认证面、漏洞类别、环境渗透、移动/API 关联以及报告。每个阶段都建立在前一个阶段之上,使您始终将范围、上下文和影响放在首位。
## 为什么与众不同
大多数公开的方法论都止步于此:
`subfinder → httpx → nuclei → ???`
而本方法论在其他方法结束的地方开始:
- **业务逻辑先于技术** — 在运行任何工具之前,先了解收入流和数据信任关系
- **信任边界映射** — 寻找身份验证决策实际发生的地方,而不是文档中声称的地方
- **二阶链** — 输入 → 存储 → 异步处理 → 输出,这才是真正的高危漏洞所在
- **环境渗透** — staging/UAT/dev 环境是一个金矿,而大多数猎人完全忽略了它们
- **OAuth/OIDC 恶意客户端链** — 几乎没有人能正确报告的 CVSS 9+ 漏洞类别
- **AI/LLM 攻击面** — 2025-2026 年项目中一块很大程度上未被认领的领地
- **供应链侦察** — 包泄露、GitHub Actions 密钥、依赖混淆
## 结构
```
00-setup/ → Toolchain, environment, API keys
01-target-profiling/ → Business model, scope analysis, threat model BEFORE tools
02-passive-recon/ → OSINT, GitHub dorking, historical, supply chain
03-active-recon/ → Subdomain enum, port scan, tech fingerprint, API discovery
04-auth-surface/ → OAuth/OIDC mapping, session analysis, MFA bypass vectors
05-vuln-classes/ → Business logic, race conditions, second-order, tenant isolation,
GraphQL, WebSockets, AI/LLM surface
06-environment-bleed/ → Staging-prod correlation, CI/CD exposure
07-mobile-api/ → APK/IPA recon, endpoint correlation with web surface
08-reporting/ → Report templates, CVSS guidance, chain documentation
scripts/ → Automation: scope parser, subdomain chain, auth flow mapper
zwanski-watchdog/ → Optional leak-pipeline monorepo (scanner, API, web, classifier)
docs/wiki/ → In-repo wiki (dashboard, API, Watchdog, configuration)
```
## 阶段流程
```
TARGET ASSIGNED
│
▼
[01] Profiling ──► Understand the business. What data is valuable? Who are the user tiers?
│ What's the revenue model? What would embarrass them?
▼
[02] Passive ────► No packets to target. OSINT, GitHub, historical, supply chain.
│
▼
[03] Active ─────► Subdomain enum → live hosts → tech stack → API discovery → JS analysis
│
▼
[04] Auth Surface ► OAuth flows, SSO chains, session lifecycle, privilege boundaries
│
▼
[05] Vuln Classes ► Target-specific: pick the classes that match the stack
│
▼
[06] Env Bleed ──► Staging/dev/UAT correlation. Often skipped. Often critical.
│
▼
[07] Mobile/API ─► Cross-reference mobile endpoints with web surface
│
▼
[08] Report ─────► Chain findings, calculate real business impact, draft write-up
```
## 核心思维
**1. 假设外围防御已经加固,直接攻击逻辑。**
WAF 会拦截你的 `