Bb Methodology

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)

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: Prove maximum business impact. Turn Low into Critical.

Escalation decision:

What did you find?
+-- XSS
|   +-- Can steal cookie/token? -> Session hijack -> ATO
|   +-- Cookie is HttpOnly? -> Force email change via XHR -> ATO
|   +-- Self-XSS only? -> Find CSRF to trigger it
+-- IDOR
|   +-- Can read PII? -> Automate scraping, show scale
|   +-- Can change password/email? -> Direct ATO
|   +-- UUID only? -> Find UUID leak source, then retry
+-- SSRF
|   +-- DNS only? -> DON'T REPORT. Try cloud metadata
|   +-- Can reach 169.254.169.254? -> Extract keys -> RCE
|   +-- Internal port scan? -> Find Redis/K8s -> RCE
+-- SQLi
|   +-- Error-based? -> Extract data (passwords, tokens)
|   +-- Can INTO OUTFILE? -> Web shell -> RCE
|   +-- Blind? -> Boolean/Time extraction
+-- Open Redirect
|   +-- OAuth flow? -> Token theft -> ATO
|   +-- javascript: scheme? -> XSS
+-- Blocked by defense
|   -> Bypass (WAF/CSP/proxy/sanitizer/2FA)
+-- Low-impact, can't escalate alone
    -> Find connector gadget for chain

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 fail? -> KILL the finding. Don't waste time.
+-- Borderline? -> Run /triage for quick go/no-go

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 for triage: try to escalate further (A->B signal method)
• 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

Tool Routing by Phase

Session End Checklist

• lead_board.py show <target> — any high-priority leads still new / stale?
• 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
• touch every lead you killed or reported