{"id":"bb-methodology","name":"bb-methodology","summary":"バグバウンティハンティングの開始時やターゲット切り替え時、次に何をすべきか迷った時に使う。5段階の非線形ハンティングワークフローとクリティカルシンキングフレームワーク(開発者心理学、異常検出、もしも実験)を組み合わせたマスターオーケストレーターです。","body":"# Bug Bounty Methodology: Workflow + Mindset\n\nMaster orchestrator for hunting sessions. Combines the 5-phase non-linear workflow with the critical thinking framework that separates top 1% hunters from the rest.\n\n---\n\n## PART 0: MODE CONFIRMATION (Before Anything Else)\n\n**Confirm the engagement type before deciding what counts as a finding.** The same target produces a different report shape depending on which mode applies. Getting this wrong is the single biggest waste of time in this workflow — answer it explicitly before Phase 0.\n\n| Engagement type | What counts as a finding | What gets rejected |\n|---|---|---|\n| **Bug bounty** (H1 / Bugcrowd / Intigriti / private VDP) | Impact-demonstrated bugs ONLY. Full chain to attacker-attainable harm. | Hygiene (EoL software alone, permissive CSP alone, stack traces, info disclosure without concrete impact, \"best practice\" violations) |\n| **Red team** (external client engagement) | Hygiene findings + recon + IoCs + defensive-state observations are ALL deliverables | Nothing — even \"no finding here\" is reportable as a positive defensive observation |\n| **Pentest** (signed SoW / WAPT) | Depends on SoW. Read scope explicitly. Usually accepts hygiene + impact + recon | Out-of-scope assets, unsigned testing |\n| **Internal audit** | Compliance-mapped findings (PCI / ISO / NIST / DPDPA / GDPR) | Findings without a control-mapping |\n\n**Hard rule:** Before Phase 0 runs, write the engagement type as the first line in your hunt notes. If you can't answer it from the user's instruction, ASK once. Don't assume — the mistake costs both you and the triager.\n\n**Lesson from an authorized engagement:** First-pass on this target produced 5 hygiene findings (SP2013 EoL, permissive CSP, stack traces) shipped in red-team format. The engagement was bug-bounty. Findings would have been N/A'd as \"informational, no impact demonstrated.\" After the corrected pass with hygiene-as-context-not-finding, the same target yielded 11 impact-demonstrated bugs including 3 Critical.\n\n---\n\n## PART 1: MINDSET (How to Think)\n\n### Core Principle\n\nHunting is not \"find a bug\" -- it is \"prove an attack scenario.\" Think like an attacker with a specific goal, not a scanner looking for patterns.\n\n### Daily Discipline: Define, Select, Execute\n\nBefore touching any tool:\n\n1. **Define**: \"Today I target [feature/domain] to achieve [CIA impact]\"\n2. **Select**: Choose 1-2 vuln classes (IDOR, Race Condition, etc.)\n3. **Execute**: Focus ONLY on selected techniques. No wandering.\n\n### 5 Ultimate Goals (Pick One Per Session)\n\n1. **Confidentiality** -- steal data the attacker shouldn't see\n2. **Integrity** -- modify data the attacker shouldn't change\n3. **Availability** -- disrupt service (app-level DoS only)\n4. **Account Takeover** -- control another user's account\n5. **RCE** -- execute commands on the server\n\n### 4 Thinking Domains\n\n#### 1. Critical Thinking (deep analysis)\n\n**Question trust boundaries:**\n- Frontend control disabled? Send request directly via proxy\n- `user_role=user` cookie? Change to `admin`\n- `price=1000` in POST? Change to `1`\n- `<script>` blocked? Try `<img onerror=...>`\n\n**Reverse-engineer developer psychology:**\n- Feature A has auth checks -> Similar feature B (newly added) probably doesn't\n- Complex flows (coupon + points + refund) -> Edge cases have bugs\n- `/api/v2/user` exists -> Does `/api/v1/user` still work with weaker auth?\n\n**What-If experiments:**\n- Skip checkout -> hit `/checkout/success` directly\n- Skip 2FA -> navigate to `/dashboard`\n- Send coupon request 10x simultaneously -> Race condition?\n- Replace `guid=f8a2...` with `id=100` on sibling endpoint -> IDOR?\n\n#### 2. Multi-Perspective (multiple angles)\n\n| Perspective | What to check |\n|------------|---------------|\n| Horizontal (same role) | User A's token + User B's ID -> IDOR |\n| Vertical (different role) | Regular user -> `/admin/deleteUser` |\n| Data flow (proxy view) | Hidden params in JSON: `debug=false`, `discount_rate` |\n| Time/State | Race conditions, post-delete session reuse |\n| Client environment | Mobile UA -> legacy API with weaker auth |\n| Business impact | \"What's the $ damage if this breaks?\" |\n\n#### 3. Tactical Thinking (pattern detection)\n\n- **Naming anomaly**: `userId` everywhere but suddenly `user_id` -> different dev, weaker security\n- **Error diff**: Same 403 but different JSON structure -> different backend systems\n- **Environment diff**: Prod vs Dev/Staging -> debug headers, CSP disabled\n- **Version diff**: JS file before/after update -> new endpoints, removed params\n- **Supply chain**: Check framework/library versions for known CVEs\n- **Third-party integration**: Stripe/Auth0/Intercom -> webhook signature missing?\n\n#### 4. Strategic Thinking (big picture)\n\n- **Asymmetry**: Defender must patch ALL holes. You only need ONE.\n- **Intuition engineering**: Log why something \"feels wrong.\" Verify later. Update mental DB.\n- **Unknown management**: Can't understand something? Add to \"investigate later\" list. Just-in-Time Learning.\n\n### Amateur vs Pro: 7-Phase Comparison\n\n| Phase | Amateur | Pro |\n|-------|---------|-----|\n| Recon | Main domain only | Shadow IT, dev environments, all assets |\n| Discovery | Look for errors | Look for design contradictions, business logic flaws |\n| Exploit | Give up when blocked | Build filter-bypass payloads |\n| Escalation | Report the phenomenon only | Chain to real harm (session steal, ATO) |\n| Feasibility | Include unrealistic conditions | Minimize attack prerequisites |\n| Reporting | State facts only | Quantify business risk |\n| Retest | Check if old PoC fails | Analyze fix method, find incomplete patches |\n\n### Two Approach Routes\n\n- **Route A (Feature-based)**: \"This feature is complex\" -> deep-dive its input handling -> find vuln\n- **Route B (Vuln-based)**: \"I want IDOR\" -> find endpoints with sequential IDs -> test access control\n\n### Anti-Patterns (Stop Doing These)\n\n- **Program hopping**: Stick with one target minimum 2 weeks / 30 hours\n- **Tool-only hunting**: Automation finds duplicates. Manual testing finds unique bugs.\n- **Rabbit hole**: Max 45 min per parameter. Set a timer. If stuck, sleep on it.\n- **No goal**: \"Just looking around\" = wasted time. Always Define first.\n\n---\n\n## PART 2: WORKFLOW (What to Do)\n\n### The 5-Phase Non-Linear Flow\n\n```\n+-------------------------------------------------+\n|                                                 |\n|  +----------+    +----------+    +----------+   |\n|  | 1. RECON |---+| 2. MAP   |---+| 3. FIND  |  |\n|  +----------+    +-----+----+    +-----+-----+  |\n|       ^                |               |         |\n|       |                v               v         |\n|       |          +----------+    +----------+    |\n|       +----------| 4. PROVE |---+| 5. REPORT|   |\n|                  +----------+    +----------+    |\n|                                                  |\n|  Non-linear: stuck at any phase -> go back       |\n|  New API found at phase 3 -> return to phase 2   |\n|  WAF blocks at phase 4 -> origin IP from phase 1 |\n+-------------------------------------------------+\n```\n\n**THIS IS NOT LINEAR.** Move freely between phases. When stuck, return to a previous phase.\n\n### Phase 0: SESSION START (Every Time)\n\n**Before touching any tool, answer these:**\n\n1. **Define**: \"Today I target [feature/domain] to achieve [C/I/A/ATO/RCE]\"\n2. **Select**: Choose 1-2 vuln classes (IDOR, XSS, SSRF, etc.)\n3. **Execute**: Focus ONLY on selected techniques\n\n**Route selection -- Wide or Deep?**\n\n| Signal | Wide (recon sweep) | Deep (focused testing) |\n|--------|-------------------|----------------------|\n| New program, first day | X | |\n| Wildcard scope `*.target.com` | X | |\n| Main webapp, been here >3 days | | X |\n| Scope update (new domain added) | X | |\n| Found interesting subdomain | | X |\n\n### Phase 1: RECON\n\n**Goal**: Maximize attack surface. Find what others missed.\n\n**Wide approach** (initial sweep):\n```\nSubdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect\n```\n\n**Deep approach** (targeted):\n```\nGoogle Dorks -> JS file download -> Hidden param discovery -> API mapping\n```\n\n| What you find | Next action |\n|--------------|-------------|\n| Live subdomains with tech stack | Phase 2 (Mapping) |\n| Known software (WordPress, Jira) | Check CVEs + defaults immediately |\n| Cloud resources (S3, Firebase) | Test permissions (read/write/list) |\n| Nothing after 5 min on a host | Skip, try next host (5-minute rule) |\n\n**Command**: `/recon target.com`\n\n### Phase 2: MAPPING & ANALYSIS\n\n**Goal**: Understand the app like its developer does.\n\n**Checklist:**\n- [ ] Map all endpoints (Burp/Caido sitemap + JS analysis)\n- [ ] Identify auth model (cookie, JWT, OAuth, SAML?)\n- [ ] Find business-critical flows (payment, registration, password reset, data export)\n- [ ] Download and analyze JS files for hidden routes, secrets, logic\n- [ ] Identify roles and permissions (user, admin, API keys)\n- [ ] Note \"weird\" behaviors (anomalies in naming, errors, timing)\n\n| What you find | Next action |\n|--------------|-------------|\n| JS files with interesting code | Taint analysis (Sink -> Source) |\n| OAuth/SAML authentication | OAuth/SAML checklist |\n| API with ID parameters | Phase 3, target IDOR |\n| Complex business logic (payment, coupon) | Phase 3, target BizLogic |\n| postMessage listeners | DOM analysis, postMessage-tracker |\n\n### Phase 3: VULNERABILITY DISCOVERY\n\n**Goal**: Find the bug. Use Error-based first, then Blind-based.\n\n**Decision flow based on what you're testing:**\n\n```\nWhat input are you testing?\n+-- ID parameter (user_id, order_id)\n|   -> IDOR checklist\n+-- Search/filter/sort field\n|   -> SQLi, NoSQLi probing\n+-- URL input / webhook / PDF gen\n|   -> SSRF checklist\n+-- Text field reflected in page\n|   -> XSS (DOM or reflected)\n+-- File upload\n|   -> SVG XSS, web shell, path traversal\n+-- Price/quantity/coupon\n|   -> Business logic, race conditions\n+-- Login / 2FA / password reset\n|   -> Auth bypass\n+-- Profile update API\n|   -> Mass Assignment\n+-- Template / wiki editor\n|   -> SSTI\n+-- Nothing obvious\n    -> Fuzz with ffuf, try Error-based probing\n```\n\n**Error vs Blind decision:**\n1. Try Error-based first (send `'`, `\"`, `{{7*7}}`, `${7*7}`) -- watch for 500 errors, stack traces\n2. No error? Time-based (`SLEEP(10)`, `; sleep 10;`) -- watch response time\n3. No time diff? OOB (`curl attacker.com`, interactsh) -- watch for DNS callback\n4. Still nothing? Boolean (`AND 1=1` vs `AND 1=0`) -- watch content-length diff\n\n| What you find | Next action |\n|--------------|-------------|\n| Low-impact behavior (redirect, self-XSS, cookie injection) | Chain it -- find a connector gadget |\n| Confirmed vuln (XSS, IDOR, SQLi) | Phase 4 (Prove and Escalate) |\n| Blocked by WAF/CSP/403 | Bypass techniques, then retry |\n| Known software vuln (CVE) | 1-day speed workflow |\n| Nothing after 20 min on this endpoint | Rotate (20-minute rule) |\n\n### Phase 4: PROVE & ESCALATE\n\n**Goal**: Prove maximum business impact. Turn Low into Critical.\n\n**Escalation decision:**\n```\nWhat did you find?\n+-- XSS\n|   +-- Can steal cookie/token? -> Session hijack -> ATO\n|   +-- Cookie is HttpOnly? -> Force email change via XHR -> ATO\n|   +-- Self-XSS only? -> Find CSRF to trigger it\n+-- IDOR\n|   +-- Can read PII? -> Automate scraping, show scale\n|   +-- Can change password/email? -> Direct ATO\n|   +-- UUID only? -> Find UUID leak source, then retry\n+-- SSRF\n|   +-- DNS only? -> DON'T REPORT. Try cloud metadata\n|   +-- Can reach 169.254.169.254? -> Extract keys -> RCE\n|   +-- Internal port scan? -> Find Redis/K8s -> RCE\n+-- SQLi\n|   +-- Error-based? -> Extract data (passwords, tokens)\n|   +-- Can INTO OUTFILE? -> Web shell -> RCE\n|   +-- Blind? -> Boolean/Time extraction\n+-- Open Redirect\n|   +-- OAuth flow? -> Token theft -> ATO\n|   +-- javascript: scheme? -> XSS\n+-- Blocked by defense\n|   -> Bypass (WAF/CSP/proxy/sanitizer/2FA)\n+-- Low-impact, can't escalate alone\n    -> Find connector gadget for chain\n```\n\n**After proving impact, check:**\n- [ ] Can attack work with 0-1 clicks? (minimize prerequisites)\n- [ ] Does it affect all users or specific role?\n- [ ] What's the business $ impact?\n\n### Phase 5: VALIDATE & REPORT\n\n**Goal**: Get paid. Make triager's job easy.\n\n**Pre-report gate:**\n```\nRun /validate (7-Question Gate)\n+-- All 7 pass? -> Write report\n+-- Any fail? -> KILL the finding. Don't waste time.\n+-- Borderline? -> Run /triage for quick go/no-go\n```\n\n**Multi-Tool Reproduction Bar (Critical / High only):**\n\nBefore labeling a finding **Critical** or **High**, reproduce it via at least **two independent tools** (different stacks, different HTTP libraries). Cross-tool consistency rules out tool-artefact findings (e.g., a curl-only timing differential that disappears under Python `requests` was an artefact, not a bug).\n\nExamples of independent reproductions:\n- `curl` + Burp `send_http1_request` (different TLS stacks, different header normalisation)\n- Python `requests` + raw socket via `ssl.wrap_socket` (one library normalises, one doesn't)\n- Burp Repeater + Python `urllib` (same wire result expected from both)\n\nThe reproduction commands MUST be paste-into-shell ready in the report — a triager copies them verbatim. If the curl version requires special flags or breaks on certain systems, include a Python alternative.\n\n**Lesson from an authorized engagement:** All three Critical findings (Authentication.asmx brute-force, TE.CL smuggling, NTLM Type-2 disclosure) were each independently reproduced via curl + Python raw sockets + Burp tooling. The cross-tool consistency was what convinced the triage write-up that the findings were not artefacts.\n\n**Report:**\n```\nRun /report\n+-- Platform-specific format (H1/Bugcrowd/Intigriti/Immunefi)\n+-- Title: [Bug Class] in [Endpoint] allows [role] to [impact]\n+-- Impact-first summary (sentence 1 = what attacker CAN do)\n+-- Exact HTTP requests in Steps to Reproduce\n+-- Under 600 words\n+-- CVSS 3.1 score that MATCHES actual impact\n```\n\n**After submission:**\n- [ ] While waiting for triage: try to escalate further (A->B signal method)\n- [ ] If fix deployed: re-test for bypass (incomplete patch = new bug)\n- [ ] Record finding with `/remember` for hunt memory\n\n---\n\n## PART 3: NAVIGATION & TIMING\n\n### Non-Linear Navigation Quick Reference\n\n| I'm stuck because... | Go to... |\n|----------------------|----------|\n| Can't find any subdomains | Phase 1: Try different recon sources, Google Dorks |\n| Found subdomain but don't know what to test | Phase 2: Map the app, download JS, understand auth |\n| Testing but nothing works | Phase 3: Switch vuln class (20-min rotation rule) |\n| Found a bug but impact is low | Phase 4: Escalation paths or gadget chaining |\n| WAF/CSP/403 blocking my payload | Bypass techniques, then return to current phase |\n| Been stuck for 45 min on one param | STOP. Rabbit hole. Move to next endpoint. |\n| New API endpoint discovered during testing | Return to Phase 2: map it before attacking |\n| Found one bug | A->B signal: same dev made more mistakes. Hunt 20 min for siblings. |\n\n### 20-Minute Rotation Clock\n\nEvery 20 minutes ask yourself: **\"Am I making progress?\"**\n- Yes -> Continue\n- No -> Rotate to next: endpoint -> subdomain -> vuln class -> target\n- Been on same target 2+ weeks with no findings? -> Consider switching program\n\n### Pushback Protocol (When the User Says \"Find More\")\n\nWhen the user disagrees with your stopping point — e.g., \"I've found 10+ bugs, you should find the same,\" or \"look harder,\" or \"you're missing things\":\n\n**Default assumption: they are correct. You stopped early.**\n\nBefore pushing back with \"I think we're done because X,\" do this:\n1. **Re-read 3 more `hunt-*` skills** beyond what you have loaded. Pick ones that match observed surface (e.g., custom login → `hunt-auth-bypass`; SOAP endpoints → look for protocol-specific skills; URL parameters → `hunt-ssrf`).\n2. **Re-attack the same surface** with the new skill checklists. Walk every step in the new skills, even if it feels redundant.\n3. **Document negatives** as you go — a confirmed \"no bug here\" is itself a finding for the user to see (it proves coverage).\n4. **Only after exhausting 3 new skills' checklists** do you push back, and only with a concrete list of what was tested.\n\n**Lesson from an authorized engagement:** After a first-pass of 5 weak findings the user said \"I have 10+, find them.\" Loading `hunt-auth-bypass` (which had been loaded but not walked through end-to-end) immediately surfaced the `/_vti_bin/Authentication.asmx` legacy SOAP login — the highest-impact bug in the engagement. The user was right; pushback would have been wrong.\n\n### Tool Routing by Phase\n\n| Phase | Tools | Why this order |\n|-------|-------|----------------|\n| Recon: Subdomains | `subfinder` -> `amass` -> `puredns` -> `httpx` | Passive first (no detection) -> resolve DNS -> probe HTTP + tech stack |\n| Recon: URLs | `gau` + `waymore` -> `katana` -> `uro` | Archive (forgotten endpoints) -> active crawl (JS-rendered) -> deduplicate |\n| Recon: JS | `jsluice` + `mantra` + `trufflehog --only-verified` | Extract URLs/secrets -> find API keys -> verify keys actually work |\n| Recon: Ports | `naabu` (wide) -> `rustscan` (deep) | Fast top-1000 sweep -> full 65535 on interesting targets |\n| Recon: Scan | `nuclei -tags cve` -> `nuclei -tags takeover` | Known CVEs first -> then takeover (act immediately) |\n| Mapping: Params | `arjun` + `paramspider` + ParamMiner | Brute-force hidden params + mine archives + cache headers |\n| Mapping: JS code | Download -> `jsluice` -> VS Code/Cursor grep | Extract -> static analysis -> AI-assisted taint analysis |\n| Mapping: Dorks | Manual Google Dorks | Custom per-target queries find what automation misses |\n| Discovery: Fuzz | `ffuf -ac` + `cewl` custom wordlist | Auto-calibrate filtering + target-specific words beat generic lists |\n| Discovery: XSS | `kxss` -> `dalfox` | Filter (which params reflect?) -> scan (only reflective params) |\n| Discovery: SQLi | `ghauri` | Modern blind SQLi on ID-like parameters |\n| Discovery: SSRF | `interactsh-client` | Self-hosted OOB listener for blind SSRF/XXE/RCE |\n| Discovery: WAF | `wafw00f` -> `whatwaf` | Identify WAF vendor -> test bypass techniques |\n| Exploit: 403 | `byp4xx` or `nomore403` | 20+ bypass techniques automated |\n| Exploit: Takeover | `subzy` | Checks CNAME against 70+ vulnerable services |\n| Exploit: Cloud | `s3scanner` + `aws` CLI | Scan bucket permissions -> extract metadata credentials |\n| Exploit: Secrets | `trufflehog --only-verified` | Only verified working keys (no false positives) |\n\n### Session End Checklist\n\n- [ ] Save all Burp/Caido project files\n- [ ] Record any \"weird but not yet exploitable\" behaviors (future gadgets)\n- [ ] Update notes with failed attempts (don't re-test with same techniques)\n- [ ] Log findings with `/remember`\n\n---\n\n## PART 4: METHODOLOGY DISCIPLINE (False-Positive Prevention)\n\nMost retracted findings come from four recurring process bugs. Each has a hard rule.\n\n> **Important framing:** These discipline rules are about *correctness of findings* — not throttling of effort. They tell you which signals are real findings and which aren't. They do **not** tell you to send fewer probes. If you find yourself using these rules to justify stopping early, you're misreading them — load `redteam-mindset` (DO NOT STOP primary directive) and continue. Coverage discipline and finding-correctness discipline are orthogonal axes; you need both on full.\n\n### Marker Discipline\n\nWhen testing for reflection, cache poisoning, parameter pollution, or OOB SSRF, the marker string you inject MUST be unique and unmistakable.\n\n**Rules:**\n- Markers are random alphanumeric strings, **8+ characters**, no English words, no protocol keywords.\n- **NEVER** use `test`, `marker`, `evil`, `attacker`, `payload`, `javascript`, `script`, `AAAA`, `BBBB`, your domain name, or any string that could plausibly appear naturally in the target's HTML/JS/error messages.\n- **Good markers:** `cpmark987abc`, `x4hd2k9pq`, a Collaborator subdomain prefix like `dlsrcurl.<collab>.oastify.com`, or `__ZZ_MARKER_<random>_ZZ__`.\n- Before claiming reflection: search the **baseline** (no-marker) response for the marker string. If it appears naturally, change your marker. This single check catches 80% of false-positive reflection reports.\n- For OOB testing, sub-tag each Collaborator payload (e.g., `dlsrcurl.<collab>`, `authsrc.<collab>`) so callbacks identify the specific sink that fired.\n\n**Lesson from an authorized engagement:** Initial scan flagged `X-Forwarded-Proto: javascript` as reflecting into multiple SharePoint pages. The \"reflection\" was the literal word `javascript` appearing naturally in SP help-link hrefs (`href=\"javascript:HelpWindowKey(...)\"`). False positive caused by a non-unique marker.\n\n### Body-Diff Rule\n\nA bypass claim requires response **body** differential, not just status code.\n\n**Rules:**\n- 200 OK with byte-identical body to the baseline is NOT a bypass.\n- 200 OK with a 5-byte difference might be — verify what changed (correlation ID? timestamp? real content?).\n- Always diff the body side-by-side before claiming bypass: `diff <(curl ... baseline) <(curl ... bypass)`.\n- Status-code-only claims (e.g. \"Host header X gave 200 instead of 403\") are the most common rejected-as-N/A category on bug bounty platforms.\n\n**Lesson from an authorized engagement:** `Host: target.example:80@evil.example.com` returned HTTP 200 instead of the baseline 403. Looked like a Host-header bypass. But the body was byte-identical (8341 bytes both) — the AWS ELB normalised the Host to `target.example:80`, dropping the `@evil` portion. Not a bypass.\n\n### Statistical-Sample Rule (for timing-based claims)\n\nSingle outliers are NOT signal. Network jitter routinely produces 2× outliers.\n\n**Rules for any user-enum / blind-SQLi / blind-NoSQLi / timing-side-channel claim:**\n- Minimum sample size: **n ≥ 10 INTERLEAVED trials per group** (control + test, randomised order, not back-to-back).\n- Compute mean, median, σ for each group.\n- A signal requires the suspect group's mean to be **≥ 2σ above** the control group's mean.\n- A single 2× outlier in n=1 testing is jitter, not signal.\n\n**Lesson from an authorized engagement:** Single-shot probe showed `Administrator` taking 1527 ms vs ~700 ms control on Authentication.asmx Login — looked like clear user-enum signal. Reproduction with n=80 interleaved trials across 8 groups collapsed every group to mean=685-716 ms, σ=25-74 ms. The 1527 ms was network jitter. Finding retracted.\n\n### Shell-Loop Ban (>5 iterations)\n\nFor any iteration that runs more than 5 times, **use Python (with try/except per iteration), not shell for-loops.**\n\n**Why:** zsh array expansion fails silently on edge cases. A loop like `for x in \"${arr[@]}\"` can produce zero iterations with no error if the array wasn't populated by the previous command. The user sees output that looks complete but actually skipped the test entirely.\n\n**Rules:**\n- Loops of ≤5 hardcoded items in shell: OK.\n- Anything that iterates a list, file, or computed range: Python.\n- Always count results. If you expected 100 probes and got <50 lines of output, your loop ate something.\n\n**Lesson from an authorized engagement:** A zsh array-iteration verb-tampering test silently produced no curl invocations across 20+ iterations (zsh ate the array). Output looked like \"HIT [GET] /_api/web → \" repeated for every probe but the actual response was missing. ~50 probes worth of testing lost. Switching the test to Python with explicit per-iteration logging surfaced the real results.\n\n---\n\n## Related Skills & Chains\n\n- **`hunt-dispatch`** — When PART 0 mode is confirmed (redteam / wapt + blackbox|greybox). Workflow primitive: after the engagement-type answer is locked, hand off to `hunt-dispatch` to fingerprint the target and load the matching platform + hunt-* skill set; this skill stops being the active context once dispatch prints its taxonomy.\n- **`bug-bounty`** — When the user asks a generic \"what should I do\" or starts a new target. Workflow primitive: `bug-bounty` is the orchestrator that names which `hunt-*` skills to load by topic; this skill (`bb-methodology`) provides the 5-phase workflow that orchestrator runs against.\n- **`triage-validation`** — When a finding completes Phase 4 and is about to be written up. Workflow primitive: Phase 5 explicitly calls `/validate` (the 7-Question Gate); only findings that pass all 7 questions get handed off to `report-writing`.\n- **`offensive-osint`** + **`web2-recon`** — When Phase 1 (Recon) is active. Workflow primitive: Phase 1's \"Wide approach\" delegates to `offensive-osint` for asset arsenal and `web2-recon` for the live-host + URL pipeline.\n\n---\n\n## Operator Notes (Claude-BugHunter)\n\n> Engagement-derived additions to the vendored foundation. Wisdom from real\n> authorized engagements + Phase 2 verification across this repo's 31+\n> skill-area live tests. The upstream methodology covers the WHAT; this\n> layer covers the WHEN-IT-ACTUALLY-WORKS and the FAILURE-MODES.\n\n### What the methodology doesn't tell you\n\nThe vendored 5-phase workflow is a checklist; real engagements are improvisation. Sometimes you skip phases entirely — a client hands you a single URL and a JWT, recon was already done by their internal team, and Phase 1 collapses to a 10-minute fingerprint. Sometimes you spend 80% of the engagement in Phase 1 because the scope is a 200-asset financial-services parent org and asset discovery IS the work. The methodology is a map of terrain that exists in every engagement, not a sequence you traverse uniformly.\n\n### Mode-confirmation, in practice\n\nPART 0 (the bug-bounty vs WAPT vs red-team gate at the top of this file) is a hard rule, but the answer isn't always handed to you. Read the scope language:\n\n- **\"in-scope assets\"** + **\"out-of-scope assets\"** + **\"safe harbor\"** → bug-bounty discipline. Validation-heavy, OOB-required, no exfil.\n- **\"kill chain\"** + **\"objectives\"** + **\"flag capture\"** + **\"adversary emulation\"** → red-team. Stealth, persistence, lateral movement valid.\n- **\"compliance\"** + **\"PCI\"** + **\"HIPAA\"** + **\"executive report\"** + **\"remediation timeline\"** → WAPT. Coverage-driven, deliverable-focused, all findings count regardless of exploitability.\n\nWhen the language is mixed (common — clients often write WAPT-shaped SOWs and call them red-team engagements), default to bug-bounty discipline until proven otherwise. It's the most validation-strict mode; you can always relax later if the client confirms red-team. The reverse — assuming red-team latitude on what turns out to be a WAPT — gets findings retracted at delivery.\n\n### Phase priority shifts by target type\n\nThe 5 phases are not equal-weight. Engagement type dictates the time allocation:\n\n| Engagement | Recon | Hunt | Validate+Report |\n|---|---|---|---|\n| SaaS bug-bounty (defined scope) | 10% | 70% | 20% |\n| External red-team (wide scope) | 40% | 30% | 30% |\n| WAPT (asset list provided) | 0% | 60% | 40% |\n| Enterprise on-prem (single product) | 5% | 50% | 45% |\n\nIf you find yourself spending 50% of a SaaS bug-bounty engagement in recon, you're procrastinating on the hunt. If you're spending 10% of an external red-team engagement on recon, you've already lost — the attack surface map IS the deliverable on those.\n\n### When to break the methodology\n\nIf you find a Critical in the first 30 minutes of recon, **stop reconning, validate the Critical fully, report it, then return to recon.** The methodology says \"complete the phase before moving on\" — the value-per-hour curve disagrees. A confirmed Critical paying out within 24h of engagement start is worth more than a comprehensive asset list you'll never get to chain.\n\nThe same applies in reverse: if you've been hunting a candidate for 4+ hours and it won't reproduce on a second account, the candidate is dead. Don't sink another 4 hours into making a dead candidate reproduce. Drop it, document the retraction in your notes, move on.\n\n### The discipline rules are non-negotiable\n\nThe discipline rules in this file — OOB Gate, Marker Discipline, Body-Diff Rule, Statistical-Sample Rule, Server-Policy-vs-State, Pre-Severity Gate, Shell-Loop Ban — are not methodology. They are quality gates. Methodology is the order of operations; these are the validation guarantees at each step.\n\nVerified across Phase 2D's hardened-lab campaign: 8/8 discipline rules fired correctly against fake-bug-shaped behavior (URL echo dressed as XSS, word collision dressed as reflection, status-code-only \"bypasses\" with byte-identical bodies, 200-OK leak-claims with no actual leak data). Validation rates fall sharply when these rules get skipped. The friction is the feature — if a rule feels obstructive, that's it doing its job. The findings it kills are the half that would have come back N/A anyway.\n- **`evidence-hygiene`** — When Phase 5 is collecting PoC screenshots / HARs. Workflow primitive: before any cookie / PII appears in a screenshot, hand off to `evidence-hygiene` for the redaction protocol.","author":"@elementalsouls","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/elementalsouls/Claude-BugHunter/tree/main/skills/bb-methodology","license":"MIT","category":"writing","lang":"en","tokens":7255,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}