Bug Bounty Hunting Methodology

Bug Bounty Methodology: Workflow + Mindset

Master orchestrator for hunting sessions. Combines the 5-phase non-linear workflow with the critical thinking framework that separates top 1% hunters from the rest.

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 -- disrupt service (app-level DoS only)
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
• 200 but wrong body length/content: 200 OK with tiny response or "just a moment" text → WAF soft block, not a real response. Run bypass_403.sh to confirm and get baseline diff.
• 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.

5. AI-Assisted Thinking (model as a second analyst)

Use AI to expand hypotheses, not to declare verdicts. The model is a fast adversarial planner; the browser, proxy, and live requests are the proof layer.

• Decompose the feature: ask for actors, assets, entry points, state transitions, and trust boundaries.
• Generate sibling paths: versioned endpoints, mobile routes, legacy APIs, alternate roles, and admin-only variants.
• Build a role matrix: anonymous, user A, user B, stale session, fresh session, admin, service account.
• Ask for dev shortcuts: "Where would a tired developer skip a check or reuse a helper?"
• Ask for chains: "If this bug is real, what bug B and C sit next to it?"
• Turn ideas into requests: every AI suggestion must become a single reproducible HTTP experiment.
• Kill weak signals fast: if AI cannot point to a concrete request, response diff, or cross-account delta, the idea stays as a hypothesis.

High-signal prompts:

• "Given this endpoint and feature, list the 10 most likely trust-boundary mistakes."
• "What sibling endpoints, methods, or roles should I test next?"
• "Which bug class would a rushed implementation likely miss here?"
• "What does the smallest proof request look like?"
• "What would make this become a real report instead of a scanner hit?"

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
4. Identity: Anonymous or authenticated? If the bugs you're hunting need a session (IDOR, BOLA, privilege escalation, auth bypass, mass-assignment), load auth once at session start — see docs/auth-sessions.md. Then every downstream tool (httpx, katana, ffuf, nuclei, dalfox, PoC verifiers) sends those headers automatically and audit log entries are stamped with a stable session_id hash.

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

After every recon (mandatory):

python3 tools/lead_board.py ingest target.com
python3 tools/lead_board.py show target.com
python3 tools/lead_board.py next target.com
# Route in plain language: "GraphQL endpoint → skills/graphql-audit"
# touch status when you start / kill / report a lead

(hunt.py runs ingest + EOL automatically unless --skip-leads.)

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)