bb-methodology

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Bug Bounty Methodology: Workflow + Mindset

A planning framework for authorized assessment sessions. It provides no measured top-percentile performance guarantee.

---

Scope and evidence boundary

Follow the actual written program/SoW, scoped assets, testing methods, request/concurrency limits and stop conditions. Newly discovered assets, origin IPs and third-party integrations are not automatically in scope. Slash commands and linked skills are external dependencies, not bundled functions. Do not automatically install or execute them. Imported anecdotes/test counts are not independently verified by this bundle.

PART 0: MODE CONFIRMATION (Before Anything Else)

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.

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.

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.

---

PART 1: MINDSET (How to Think)

Core Principle

Hunting 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.

Daily Discipline: Define, Select, Execute

Before touching any tool:

1. Define: "Today I target [feature/domain] to achieve [CIA impact]"
2. Select: Choose 1-2 vuln classes (IDOR, Race Condition, etc.)
3. Execute: Focus ONLY on selected techniques. No wandering.

5 Ultimate Goals (Pick One Per Session)

1. Confidentiality -- steal data the attacker shouldn't see
2. Integrity -- modify data the attacker shouldn't change
3. Availability -- evaluate resilience only if explicitly permitted; app-level DoS is still disruptive
4. Account Takeover -- control another user's account
5. RCE -- execute commands on the server

4 Thinking Domains

1. Critical Thinking (deep analysis)

Question trust boundaries:

• Frontend control disabled? Send request directly via proxy
• user_role=user cookie? Change to admin
• price=1000 in POST? Change to 1
• <script> blocked? Try <img onerror=...>

Reverse-engineer developer psychology:

• Feature A has auth checks -> Similar feature B (newly added) probably doesn't
• Complex flows (coupon + points + refund) -> Edge cases have bugs
• /api/v2/user exists -> Does /api/v1/user still work with weaker auth?

What-If experiments:

• Skip checkout -> hit /checkout/success directly
• Skip 2FA -> navigate to /dashboard
• Send coupon request 10x simultaneously -> Race condition?
• Replace guid=f8a2... with id=100 on sibling endpoint -> IDOR?

2. Multi-Perspective (multiple angles)

3. Tactical Thinking (pattern detection)

• Naming anomaly: userId everywhere but suddenly user_id -> different dev, weaker security
• Error diff: Same 403 but different JSON structure -> different backend systems
• Environment diff: Prod vs Dev/Staging -> debug headers, CSP disabled
• Version diff: JS file before/after update -> new endpoints, removed params
• Supply chain: Check framework/library versions for known CVEs
• Third-party integration: Stripe/Auth0/Intercom -> webhook signature missing?

4. Strategic Thinking (big picture)

• Asymmetry: Defender must patch ALL holes. You only need ONE.
• Intuition engineering: Log why something "feels wrong." Verify later. Update mental DB.
• Unknown management: Can't understand something? Add to "investigate later" list. Just-in-Time Learning.

Amateur vs Pro: 7-Phase Comparison

Two Approach Routes

• Route A (Feature-based): "This feature is complex" -> deep-dive its input handling -> find vuln
• Route B (Vuln-based): "I want IDOR" -> find endpoints with sequential IDs -> test access control

Anti-Patterns (Stop Doing These)

• Program hopping: Stick with one target minimum 2 weeks / 30 hours
• Tool-only hunting: Automation finds duplicates. Manual testing finds unique bugs.
• Rabbit hole: Max 45 min per parameter. Set a timer. If stuck, sleep on it.
• No goal: "Just looking around" = wasted time. Always Define first.

---

PART 2: WORKFLOW (What to Do)

The 5-Phase Non-Linear Flow

+-------------------------------------------------+
|                                                 |
|  +----------+    +----------+    +----------+   |
|  | 1. RECON |---+| 2. MAP   |---+| 3. FIND  |  |
|  +----------+    +-----+----+    +-----+-----+  |
|       ^                |               |         |
|       |                v               v         |
|       |          +----------+    +----------+    |
|       +----------| 4. PROVE |---+| 5. REPORT|   |
|                  +----------+    +----------+    |
|                                                  |
|  Non-linear: stuck at any phase -> go back       |
|  New API found at phase 3 -> return to phase 2   |
|  WAF blocks at phase 4 -> origin IP from phase 1 |
+-------------------------------------------------+

THIS IS NOT LINEAR. Move freely between phases. When stuck, return to a previous phase.

Phase 0: SESSION START (Every Time)

Before touching any tool, answer these:

1. Define: "Today I target [feature/domain] to achieve [C/I/A/ATO/RCE]"
2. Select: Choose 1-2 vuln classes (IDOR, XSS, SSRF, etc.)
3. Execute: Focus ONLY on selected techniques

Route selection -- Wide or Deep?

Phase 1: RECON

Goal: Maximize attack surface. Find what others missed.

Wide approach (initial sweep):

Subdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect

Deep approach (targeted):

Google Dorks -> JS file download -> Hidden param discovery -> API mapping

Command: /recon target.com

Phase 2: MAPPING & ANALYSIS

Goal: Understand the app like its developer does.

Checklist:

• Map all endpoints (Burp/Caido sitemap + JS analysis)
• Identify auth model (cookie, JWT, OAuth, SAML?)
• Find business-critical flows (payment, registration, password reset, data export)
• Download and analyze JS files for hidden routes, secrets, logic
• Identify roles and permissions (user, admin, API keys)
• Note "weird" behaviors (anomalies in naming, errors, timing)

Phase 3: VULNERABILITY DISCOVERY

Goal: Find the bug. Use Error-based first, then Blind-based.

Decision flow based on what you're testing:

What input are you testing?
+-- ID parameter (user_id, order_id)
|   -> IDOR checklist
+-- Search/filter/sort field
|   -> SQLi, NoSQLi probing
+-- URL input / webhook / PDF gen
|   -> SSRF checklist
+-- Text field reflected in page
|   -> XSS (DOM or reflected)
+-- File upload
|   -> SVG XSS, web shell, path traversal
+-- Price/quantity/coupon
|   -> Business logic, race conditions
+-- Login / 2FA / password reset
|   -> Auth bypass
+-- Profile update API
|   -> Mass Assignment
+-- Template / wiki editor
|   -> SSTI
+-- Nothing obvious
    -> Fuzz with ffuf, try Error-based probing

Error vs Blind decision:

1. Try Error-based first (send ', ", {{7*7}}, ${7*7}) -- watch for 500 errors, stack traces
2. No error? Time-based (SLEEP(10), ; sleep 10;) -- watch response time
3. No time diff? OOB (curl attacker.com, interactsh) -- watch for DNS callback
4. Still nothing? Boolean (AND 1=1 vs AND 1=0) -- watch content-length diff

Phase 4: PROVE & ESCALATE

Goal: Demonstrate the minimum sufficient authorized impact using owned accounts and synthetic data. A chain is a hypothesis until every prerequisite is supported. Do not scrape PII, extract live cloud keys, deploy web shells, disrupt service or change real accounts to increase severity. Use a reversible canary and stop when evidence is sufficient; request separate scope for any additional action. DNS callbacks establish resolution only, not HTTP response access or RCE. HttpOnly blocks cookie reads but does not establish an email-change/ATO path without its additional controls.

After proving impact, check:

• Can attack work with 0-1 clicks? (minimize prerequisites)
• Does it affect all users or specific role?
• What's the business $ impact?

Phase 5: VALIDATE & REPORT

Goal: Get paid. Make triager's job easy.

Pre-report gate:

Run /validate (7-Question Gate)
+-- All 7 pass? -> Write report
+-- Any unsupported point? -> record candidate evidence/limitations and apply the program rubric; do not invent a stronger finding
+-- Borderline? -> Run /triage for quick go/no-go

Multi-Tool Reproduction Bar (Critical / High only):

Before labeling a finding Critical or High, reproduce it via at least two independent tools (different stacks, different HTTP libraries). Cross-tool consistency reduces some tool artifacts but does not rule them all out (e.g., a curl-only timing differential that disappears under Python requests was an artefact, not a bug).

Examples of independent reproductions:

• curl + Burp send_http1_request (different TLS stacks, different header normalisation)
• Python requests + raw socket via ssl.wrap_socket (one library normalises, one doesn't)
• Burp Repeater + Python urllib (same wire result expected from both)

The 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.

Unverified imported anecdote, not a severity precedent: All three purported 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.

Report:

Run /report
+-- Platform-specific format (H1/Bugcrowd/Intigriti/Immunefi)
+-- Title: [Bug Class] in [Endpoint] allows [role] to [impact]
+-- Impact-first summary (sentence 1 = what attacker CAN do)
+-- Exact HTTP requests in Steps to Reproduce
+-- Under 600 words
+-- CVSS 3.1 score that MATCHES actual impact

After submission:

• While waiting, preserve evidence and continue only other authorized bounded tests; no automatic escalation
• If fix deployed: re-test for bypass (incomplete patch = new bug)
• Record finding with /remember for hunt memory

---

PART 3: NAVIGATION & TIMING

Non-Linear Navigation Quick Reference

20-Minute Rotation Clock

Every 20 minutes ask yourself: "Am I making progress?"

• Yes -> Continue
• No -> Rotate to next: endpoint -> subdomain -> vuln class -> target
• Been on same target 2+ weeks with no findings? -> Consider switching program

Pushback Protocol (When the User Says "Find More")

When 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":

Reassess the tested surface and any specific missed evidence against the scope, remaining budget and stop conditions. A requested finding count is not evidence that those bugs exist. Report attempted tests, failures, uncertainty and untested coverage honestly; propose a bounded next pass only if authorized. Never label a negative probe exhaustive coverage or invent a required number of findings.

Tool Routing by Phase

Session End Checklist

• Save all Burp/Caido project files
• Record any "weird but not yet exploitable" behaviors (future gadgets)
• Update notes with failed attempts (don't re-test with same techniques)
• Log findings with /remember

---

Contents

• PART 4: METHODOLOGY DISCIPLINE (False-Positive Prevention)
• Related Skills & Chains
• Operator Notes (Claude-BugHunter)

When to Use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

Limitations

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see triage-validation) before reporting; report via report-writing. Prefer a sandbox, disposable VM, or controlled lab.

Example

# Read-only first step; confirm scope before anything active.
cat scope.txt  # target list from the authorized engagement brief

Adapted from elementalsouls/Claude-BugHunter (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.