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 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.
| Engagement type | What counts as a finding | What gets rejected |
|---|---|---|
| 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) |
| 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 |
| Pentest (signed SoW / WAPT) | Depends on SoW. Read scope explicitly. Usually accepts hygiene + impact + recon | Out-of-scope assets, unsigned testing |
| Internal audit | Compliance-mapped findings (PCI / ISO / NIST / DPDPA / GDPR) | Findings without a control-mapping |
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:
- Define: "Today I target [feature/domain] to achieve [CIA impact]"
- Select: Choose 1-2 vuln classes (IDOR, Race Condition, etc.)
- Execute: Focus ONLY on selected techniques. No wandering.
5 Ultimate Goals (Pick One Per Session)
- Confidentiality -- steal data the attacker shouldn't see
- Integrity -- modify data the attacker shouldn't change
- Availability -- disrupt service (app-level DoS only)
- Account Takeover -- control another user's account
- 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=usercookie? Change toadminprice=1000in POST? Change to1<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/userexists -> Does/api/v1/userstill work with weaker auth?
What-If experiments:
- Skip checkout -> hit
/checkout/successdirectly - Skip 2FA -> navigate to
/dashboard - Send coupon request 10x simultaneously -> Race condition?
- Replace
guid=f8a2...withid=100on sibling endpoint -> IDOR?
2. Multi-Perspective (multiple angles)
| Perspective | What to check |
|---|---|
| Horizontal (same role) | User A's token + User B's ID -> IDOR |
| Vertical (different role) | Regular user -> /admin/deleteUser |
| Data flow (proxy view) | Hidden params in JSON: debug=false, discount_rate |
| Time/State | Race conditions, post-delete session reuse |
| Client environment | Mobile UA -> legacy API with weaker auth |
| Business impact | "What's the $ damage if this breaks?" |
3. Tactical Thinking (pattern detection)
- Naming anomaly:
userIdeverywhere but suddenlyuser_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
| Phase | Amateur | Pro |
|---|---|---|
| Recon | Main domain only | Shadow IT, dev environments, all assets |
| Discovery | Look for errors | Look for design contradictions, business logic flaws |
| Exploit | Give up when blocked | Build filter-bypass payloads |
| Escalation | Report the phenomenon only | Chain to real harm (session steal, ATO) |
| Feasibility | Include unrealistic conditions | Minimize attack prerequisites |
| Reporting | State facts only | Quantify business risk |
| Retest | Check if old PoC fails | Analyze fix method, find incomplete patches |
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:
- Define: "Today I target [feature/domain] to achieve [C/I/A/ATO/RCE]"
- Select: Choose 1-2 vuln classes (IDOR, XSS, SSRF, etc.)
- Execute: Focus ONLY on selected techniques
Route selection -- Wide or Deep?
| Signal | Wide (recon sweep) | Deep (focused testing) |
|---|---|---|
| New program, first day | X | |
Wildcard scope *.target.com | X | |
| Main webapp, been here >3 days | X | |
| Scope update (new domain added) | X | |
| Found interesting subdomain | X |
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