Bb methodology
/SKILLUse at the START of any bug bounty hunting session, when switching targets, or when feeling lost about what to do next.
--- name: bb-methodology description: Use at the START of any bug bounty hunting session, when switching targets, or when you're unsure what to do next. A master orchestrator that combines the 5-phase non-linear hunting workflow with the critical thinking framework (developer psychology, anomaly detection, What-If experiments). Provides links to all other skills based on the current hunting phase. Also use when asking "what should I do next" or "where am I in the process." --- # Bug Bounty Methodology: Workflow + Mindset Master orchestrator for hunting sessions. Combines the 5-phase non-linear workflow with the critical thinking framework that separates the top 1% of 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 yields a different report format depending on which mode applies. Getting this wrong is the single biggest waste of time in this workflow : answer this explicitly before Phase 0. | Engagement type | What counts as a finding | What gets rejected | |---|---|---| | Bug bounty (H1 / Bugcrowd / Intigriti / private VDP) | Bugs with demonstrated impact ONLY. Full chain leading to harm attainable by an attacker. | Hygiene (end-of-life software alone, permissive CSP alone, stack traces, information disclosure without concrete impact, “best practice” violations) | | Red team (external client engagement) | Hygiene findings + reconnaissance + IoCs + defensive-state observations are ALL deliverables | Nothing : even “no findings here” is reportable as a positive defensive observation | | Penetration test (signed SoW / WAPT) | Depends on the SoW. Read the scope explicitly. Usually accepts hygiene + impact + reconnaissance | 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 begins, write the engagement type as the first line in your hunt notes. If you can’t determine it from the user’s instructions, ASK once. Don’t assume:this mistake costs both you and the triager. Lesson from an authorized engagement: The first pass on this target produced 5 hygiene findings (SP2013 EoL, permissive CSP, stack traces) submitted in red-team format. The engagement was a bug bounty. The findings would have been marked as N/A, classified as “informational, no impact demonstrated.” After the corrected pass, where hygiene issues were treated as context rather than findings, the same target yielded 11 bugs with demonstrated impact, including 3 Critical ones. --- ## 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 using any tool: 1. Define: “Today I’m targeting [feature/domain] to achieve [CIA impact]” 2. Select: Choose 1:2 vulnerability classes (IDOR, race condition, etc.) 3. Execute: Focus ONLY on the 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 : take control of another user’s account 5. RCE : execute commands on the server ### 4 Thinking Domains #### 1. Critical Thinking (deep analysis) Question trust boundaries: - Is frontend control disabled? Send the request directly via a proxy - Is the cookie set to `user_role=user? Change it to admin - Is price=1000 in the POST request? Change it to 1 - Is <script> blocked? Try <img onerror=...> **Reverse-engineer developer psychology:** - Feature A has authentication 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 authentication? **What-If experiments:** - Skip checkout -> go directly to /checkout/success - Skip 2FA -> navigate to /dashboard - Send 10 coupon requests simultaneously -> Race condition? - Replace guid=f8a2... with id=100` on sibling endpoint -> IDOR? #### 2. Multi-Perspective (multiple angles) | Perspective | What to check | |--