Bb 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
• ` blocked? Try `

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)

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

| 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.
• Architecture-as-vulnerability: Reporting standard platform architecture (public RPC endpoints, client env vars, CORS on token-auth APIs) as bugs. Run adversarial self-review BEFORE writing the report, not after. See triage-validation/references/web3-dapp-architecture-false-positives.md.
• Writing reports before adversarial review: Always run the 7-Question Gate + adversarial "assume this is wrong" pass BEFORE investing time in a full report. Saves 45+ min per false positive.

Adversarial Self-Review — 9-Category Counter-Argument Framework

When you have a candidate finding, assume the report is incorrect and run this pass BEFORE writing. Each category is a class of rejection that bug-bounty triagers use. If you cannot defeat every category, the finding is probably N/A — kill it before report-writing eats an hour.

1. Scope ambiguity — Does the affected asset actually fall inside the program scope, under any reasonable interpretation? "Internal admin tooling reachable on a public-internet hostname" is borderline; "demo page on a marketing site" usually isn't. State the strongest scope-in interpretation AND the strongest scope-out interpretation in the report; do not pretend ambiguity doesn't exist.

1. No demonstrated impact — Did you actually prove harm (data exfil, account compromise, code execution, privilege escalation), or only prove "endpoint is reachable"? Hypothetical impact ("if an attacker guessed credentials they could…") almost never pays. If your finding lives in "could/would/might" land, you owe the report a concrete demo path.

1. Default-credential / preconditions — Did you confirm default creds exist, or is "admin/admin might work" just a guess? Brute-force without proof of credential validity is not a finding — enumerate the username space and prove at least one valid user, or kill it.

1. Intended public exposure — Could a defender argue the configuration is a standard SaaS pattern (SSO callback, login from any IP, public status page)? If so, the bug must be the SSO bypass or the auth-bypass, not the reachability. Move the report onto the actually-exploitable primitive.

1. OOS by policy — Re-read the program's out-of-scope list. Mature programs (Tencent, Google, Meta) explicitly enumerate "no rate limit on non-critical forms," "admin panel can be brute forced," "information leakage without direct attack," "missing security headers." If your finding lands on one of those bullets, you can submit but expect rejection — and don't be surprised.

1. Behavioral / WAF realism — Did you test under realistic attack load (distributed, low-and-slow, bypass header order)? Behavioral WAFs (AEGIS, Akamai Bot Manager, Cloudflare ML) may pass a small burst then silently drop or fake-respond. A 30-request burst that all return 200 does NOT prove "no rate limit" — it proves "30 sequential requests from one IP weren't rate-limited."

1. Honeypot / decoy possibility — Could the endpoint be a deliberate trap that logs all attempts and bans in real-time? Auth endpoints behind behavioral detection sometimes return uniform success/fail errors while quietly correlating with a security team. State the assumption explicitly; if you can't rule it out, soften the impact claim.

1. Duplicate / known-issue risk — Mature programs with 100+ reports submitted are likely to have triaged your exact issue before. Search Hacktivity, GitHub issues, changelogs. If you find evidence the team already knows about it, do not resurface it — find a sibling or chain instead.

1. Sensitive-data exposure (the missing piece) — Does the bug actually leak credentials, PII, or money? "Endpoint reachable" + "internal service name leaked" + "no auth" by themselves do not pay. The escalation to "this name reveals a credential / enables bypass / grants access" is what carries the bounty. If no escalation exists, downgrade to N/A.

Output: After the pass, list each category as PASS / FAIL / UNKNOWN. Any FAIL → kill the finding or rebuild it as a different chain. UNKNOWN → either gather the missing evidence or scope down the claim. The 9-category framework is reusable across web2, web3, cloud, and mobile bug classes — see references/adversarial-self-review-checklist.md for the printable checklist and worked examples.

---

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.

Output Style Constraint (User Preference)

• Ultra terse, technical, no filler. 1 line if possible.
• Drop conjunctions. Strip "Sure!"/"Of course!".
• Code first, explanation minimal.
• If unsure: state it, proceed. No hedging.

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. For SIWE/wallet login, create only ephemeral researcher-owned EOAs, reproduce the frontend's exact message, use separate cookie jars for the replay/BOLA differential, redact all auth material, and log out test sessions. See references/controlled-siwe-validation.md. For conventional form login or SSO, use a named secret reference, verify that the agent process—not merely an SSH shell—can resolve it, then perform one normal login plus one harmless session oracle before attacking authorization. Redact query strings, owned-account IDs, cookies, tokens, and response values. Never request or persist passwords in chat, reports, notes, artifacts, or memory; prefer secure credential profiles/resolvers. For cross-account testing, use two isolated browser contexts/cookie jars; never overwrite session A while testing session B. A 302 SSO chain is a mapping lead, not a finding. See references/authenticated-program-baseline.md. Cross-account differential testing must record actor/session, target owner, exact request, expected denial, observed response, and logout/expiry behavior. Stop immediately on nonpublic data exposure; retain only minimum redacted evidence required by policy.

• [x] Program channel first: resolve the live bounty/VDP page before deep dive.
• Platform slug may 404 (Immunefi/H1/Bugcrowd) — also check vendor /vdp, SECURITY.md, security@.
• Example: Nym is not a reliable Immunefi slug; official channel is https://nym.com/vdp-bbp + security@nym.com (PGP). Details: references/nym-vdp-bbp.md.
• [x] Manual-Only Programs: when policy prohibits automated tools/scanners/indexes, apply strict boundaries (no automated subfinder/httpx/archive sweeps). Details: references/manual-only-program-policy.md.

1. Target-switch signals (this user): "skip dulu", "bounty lain", numeric menu pick (1 = first listed target) → cancel residual todos on the old program immediately; write /home/ubuntu/recon//SCOPE_FENCE.md before more probes. Do not keep residual hunts after skip.
2. Prior-work de-dupe: inventory local *-report.md, PGP packages, incomplete chains (e.g. CSP without XSS sink = hardening debt, not a submit).
3. Live deployment provenance for dApps: before auditing checked-in addresses, extract the chain ID, RPC, deployment block, flags, and contract map from the frontend bundle currently served to users. Label repository manifests as current, legacy, or candidate source; never let an older checked-in manifest outrank the active app. Prove source equivalence contract-by-contract with runtime bytecode and validate impact on a pinned fork. For custom-chain fork fallback and the full evidence checklist, see references/live-dapp-deployment-provenance.md.
4. Document-published programs and public indexers: snapshot public policy documents, convert scope into a SCOPE_FENCE.md, and explicitly flag unresolved dates/placeholders. A first-party GraphQL/GraphiQL indexer can establish a contract-provenance lead, but its public schema, introspection, CORS, and public on-chain query data are not findings by themselves. Bind each contract to a current official flow and prove its actual role before auditing it. See references/program-document-and-dapp-provenance.md.

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 | | Hunting IDOR / BOLA / auth bugs | | X (auth-aware) |

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 app

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Sekolah76
• Source: Sekolah76/syadagentic
• License: MIT
• Homepage: https://github.com/Sekolah76/syadagentic

Install and usage instructions live in the source repository linked above.