⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Bug Bounty Master Workflow

Full pipeline: Recon -> Learn -> Hunt -> Validate -> Report. One skill for everything.

THE ONLY QUESTION THAT MATTERS

"Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions -- and does it cause real harm (stolen money, leaked PII, account takeover, code execution)?"

If the answer is NO -- STOP. Do not write. Do not explore further. Move on.

Theoretical Bug = Wasted Time. Kill These Immediately:

You must demonstrate actual harm. "Could" is not a bug. Prove it works or drop it.

CRITICAL RULES

1. READ FULL SCOPE FIRST -- verify every asset/domain is owned by the target org
2. NO THEORETICAL BUGS -- "Can an attacker steal funds, leak PII, takeover account, or execute code RIGHT NOW?" If no, STOP.
3. KILL WEAK FINDINGS FAST -- run the 7-Question Gate BEFORE writing any report
4. Validate before writing -- check CHANGELOG, design docs, deployment scripts FIRST
5. One bug class at a time -- go deep, don't spray
6. Verify data isn't already public -- check web UI in incognito before reporting API "leaks"
7. 5-MINUTE RULE -- if a target shows nothing after 5 min probing (all 401/403/404), MOVE ON
8. IMPACT-FIRST HUNTING -- ask "what's the worst thing if auth was broken?" If nothing valuable, skip target
9. CREDENTIAL LEAKS need exploitation proof -- finding keys isn't enough, must PROVE what they access
10. STOP SHALLOW RECON SPIRALS -- don't probe 403s, don't grep for analytics keys, don't check staging domains that lead nowhere
11. BUSINESS IMPACT over vuln class -- severity depends on CONTEXT, not just vuln type
12. UNDERSTAND THE TARGET DEEPLY -- before hunting, learn the app like a real user
13. DON'T OVER-RELY ON AUTOMATION -- automated scans hit WAFs, trigger rate limits, find the same bugs everyone else finds
14. HUNT LESS-SATURATED VULN CLASSES -- XSS/SSRF/XXE have the most competition. Expand into: cache poisoning, Android/mobile vulns, business logic, race conditions, OAuth/OIDC chains, CI/CD pipeline attacks
15. ONE-HOUR RULE -- stuck on one target for an hour with no progress? SWITCH CONTEXT
16. TWO-EYE APPROACH -- combine systematic testing (checklist) with anomaly detection (watch for unexpected behavior)
17. T-SHAPED KNOWLEDGE -- go DEEP in one area and BROAD across everything else

For the full hunting methodology — 5-phase non-linear workflow, developer psychology framework, session discipline, tool routing by phase, and Wide/Deep route selection — see skills/bb-methodology/SKILL.md.

A->B BUG SIGNAL METHOD (Cluster Hunting)

When you find bug A, systematically hunt for B and C nearby. This is one of the most powerful methodologies in bug bounty. Single bugs pay. Chains pay 3-10x more.

Known A->B->C Chains

Cluster Hunt Protocol (6 Steps)

1. CONFIRM A     Verify bug A is real with an HTTP request
2. MAP SIBLINGS  Find all endpoints in the same controller/module/API group
3. TEST SIBLINGS Apply the same bug pattern to every sibling
4. CHAIN         If sibling has different bug class, try combining A + B
5. QUANTIFY      "Affects N users" / "exposes $X value" / "N records"
6. REPORT        One report per chain (not per bug). Chains pay more.

Real Examples

Coinbase S3->Bundle->Secret->OAuth chain:

A: S3 bucket publicly listable (Low alone)
B: JS bundles contain OAuth client credentials
C: OAuth flow missing PKCE enforcement
Result: Full auth code interception chain

Vienna Chatbot chain:

A: Debug parameter active in production (Info alone)
B: Chatbot renders HTML in response (dangerouslySetInnerHTML)
C: Stored XSS via bot response visible to other users
Result: P2 finding with real impact

TOP 1% HACKER MINDSET

How Elite Hackers Think Differently

Average hunter: Runs tools, checks checklist, gives up after 30 min. Top 1%: Builds a mental model of the app's internals. Asks "why does this work the way it does?" Not "what does this endpoint do?" but "what business decision led a developer to build it this way, and what shortcut might they have taken?"

Pre-Hunt Mental Framework

Step 1: Crown Jewel Thinking

Before touching anything, ask: "If I were the attacker and I could do ONE thing to this app, what causes the most damage?"

• Financial app -> drain funds, transfer to attacker account
• Healthcare -> PII leak, HIPAA violation
• SaaS -> tenant data crossing, admin takeover
• Auth provider -> full SSO chain compromise

Step 2: Developer Empathy

Think like the developer who built the feature:

• What was the simplest implementation?
• What shortcut would a tired dev take at 2am?
• Where is auth checked -- controller? middleware? DB layer?
• What happens when you call endpoint B without going through endpoint A first?

Step 3: Trust Boundary Mapping

Client -> CDN -> Load Balancer -> App Server -> Database
         ^               ^              ^
    Where does app STOP trusting input?
    Where does it ASSUME input is already validated?

Step 4: Feature Interaction Thinking

• Does this new feature reuse old auth, or does it have its own?
• Does the mobile API share auth logic with the web app?
• Was this feature built by the same team or a third-party?

The Top 1% Mental Checklist

• I know the app's core business model
• I've used the app as a real user for 15+ minutes
• I know the tech stack (language, framework, auth system, caching)
• I've read at least 3 disclosed reports for this program
• I have 2 test accounts ready (attacker + victim)
• I've defined my primary target: ONE crown jewel I'm hunting for today

Mindset Rules from Top Hunters

"Hunt the feature, not the endpoint" -- Find all endpoints that serve a feature, then test the INTERACTION between them.

"Authorization inconsistency is your friend" -- If the app checks auth in 9 places but not the 10th, that's your bug.

"New == unreviewed" -- Features launched in the last 30 days have lowest security maturity.

"Think second-order" -- Second-order SSRF: URL saved in DB, fetched by cron job. Second-order XSS: stored clean, rendered unsafely in admin panel.

"Follow the money" -- Any feature touching payments, billing, credits, refunds is where developers make the most security shortcuts.

"The API the mobile app uses" -- Mobile apps often call older/different API versions. Same company, different attack surface, lower maturity.

"Diffs find bugs" -- Compare old API docs vs new. Compare mobile API vs web API. Compare what a free user can request vs what a paid user gets in response.

TOOLS

Go Binaries

Tools to Install When Needed

Static Analysis (Semgrep Quick Audit)

# Install: pip3 install semgrep

# Broad security audit
semgrep --config=p/security-audit ./
semgrep --config=p/owasp-top-ten ./

# Language-specific rulesets
semgrep --config=p/javascript ./src/
semgrep --config=p/python ./
semgrep --config=p/golang ./
semgrep --config=p/php ./
semgrep --config=p/nodejs ./

# Targeted rules
semgrep --config=p/sql-injection ./
semgrep --config=p/jwt ./

# Custom pattern (example: find SQL concat in Python)
semgrep --pattern 'cursor.execute("..." + $X)' --lang python .

# Output to file for analysis
semgrep --config=p/security-audit ./ --json -o semgrep-results.json 2>/dev/null
cat semgrep-results.json | jq '.results[] | select(.extra.severity == "ERROR") | {path:.path, check:.check_id, msg:.extra.message}'

FFUF Advanced Techniques

# THE ONE RULE: Always use -ac (auto-calibrate filters noise automatically)
ffuf -w wordlist.txt -u https://target.com/FUZZ -ac

# Authenticated raw request file — IDOR testing (save Burp request to req.txt, replace ID with FUZZ)
seq 1 10000 | ffuf --request req.txt -w - -ac

# Authenticated API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w wordlist.txt -H "Cookie: session=TOKEN" -ac

# Parameter discovery
ffuf -w ~/wordlists/burp-parameter-names.txt -u "https://target.com/api/endpoint?FUZZ=test" -ac -mc 200

# Hidden POST parameters
ffuf -w ~/wordlists/burp-parameter-names.txt -X POST -d "FUZZ=test" -u "https://target.com/api/endpoint" -ac

# Subdomain scan
ffuf -w subs.txt -u https://FUZZ.target.com -ac

# Filter strategies:
# -fc 404,403          Filter status codes
# -fs 1234             Filter by response size
# -fw 50               Filter by word count
# -fr "not found"      Filter regex in response body
# -rate 5 -t 10        Rate limit + fewer threads for stealth
# -e .php,.bak,.old    Add extensions
# -o results.json      Save output

AI-Assisted Tools

• strix (usestrix.com) -- open-source AI scanner for automated initial sweep

PHASE 1: RECON

Standard Recon Pipeline

# Step 1: Subdomains
subfinder -d TARGET -silent | anew /tmp/subs.txt
assetfinder --subs-only TARGET | anew /tmp/subs.txt

# Step 2: Resolve + live hosts
cat /tmp/subs.txt | dnsx -silent | httpx -silent -status-code -title -tech-detect -o /tmp/live.txt

# Step 3: URL collection
cat /tmp/live.txt | awk '{print $1}' | katana -d 3 -silent | anew /tmp/urls.txt
echo TARGET | waybackurls | anew /tmp/urls.txt
gau TARGET | anew /tmp/urls.txt

# Step 4: Nuclei scan
nuclei -l /tmp/live.txt -severity critical,high,medium -silent -o /tmp/nuclei.txt

# Step 5: JS secrets
cat /tmp/urls.txt | grep "\.js$" | sort -u > /tmp/jsfiles.txt
# Run SecretFinder on each JS file

# Step 6: GitHub dorking (if target has public repos)
# GitDorker -org TARGET_ORG -d dorks/alldorksv3

Cloud Asset Enumeration

# Manual S3 brute
for suffix in dev staging test backup api data assets static cdn; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://${TARGET}-${suffix}.s3.amazonaws.com/")
  [ "$code" != "404" ] && echo "$code ${TARGET}-${suffix}.s3.amazonaws.com"
done

API Endpoint Discovery

# ffuf API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -mc 200,201,301,302,403 -ac

HackerOne Scope Retrieval

curl -s "https://hackerone.com/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { team(handle: \"PROGRAM_HANDLE\") { name url policy_scopes(archived: false) { edges { node { asset_type asset_identifier eligible_for_bounty instruction } } } } }"}' \
  | jq '.data.team.policy_scopes.edges[].node'

Quick Wins Checklist

• Subdomain takeover (subjack, subzy)
• Exposed .git (/.git/config)
• Exposed env files (/.env, /.env.local)
• Default credentials on admin panels
• JS secrets (SecretFinder, jsluice)
• Open redirects (?redirect=, ?next=, ?url=)
• CORS misconfig (test Origin: https://evil.com + credentials)
• S3/cloud buckets
• GraphQL introspection enabled
• Spring actuators (/actuator/env, /actuator/heapdump)
• Firebase open read (https://TARGET.firebaseio.com/.json)

Technology Fingerprinting

Framework Quick Wins

Laravel: /horizon, /telescope, /.env, /storage/logs/laravel.log WordPress: /wp-json/wp/v2/users, /xmlrpc.php, /?author=1 Node.js: /.env, /graphql (introspection), /_debug AWS Cognito: /oauth2/userInfo (leaks Pool ID), CORS reflects arbitrary origins

Contents

• Source Code Recon
• Read Disclosed Reports
• "What Changed" Method
• Threat Model Template
• 6 Key Patterns from Top Reports
• Note-Taking System (Never Hunt Without This)
• Interesting Leads (not confirmed bugs yet)
• Dead Ends (don't revisit)
• Anomalies
• Rabbit Holes (time-boxed, max 15 min each)
• Confirmed Bugs
• Subdomain Type -> Hunt Strategy
• CVE-Seeded Audit Approach
• Rust/Blockchain Source Code (Hard-Won Lessons)
• IDOR -- Insecure Direct Object Reference
• SSRF -- Server-Side Request Forgery
• OAuth / OIDC
• File Upload
• Race Conditions
• Business Logic
• XSS -- Cross-Site Scripting
• SQL Injection
• GraphQL
• LLM / AI Features
• Cache Poisoning / Web Cache Deception
• HTTP Request Smuggling
• Android / Mobile Hunting
• CI/CD Pipeline — GitHub Actions Security
• SSTI -- Server-Side Template Injection
• Subdomain Takeover
• ATO -- Account Takeover (Complete Taxonomy)
• Cloud / Infra Misconfigs
• The 7-Question Gate (Run BEFORE Writing ANY Report)
• 4 Pre-Submission Gates
• CVSS 3.1 Quick Guide
• Conditionally Valid With Chain
• HackerOne Report Template
• Summary
• Steps To Reproduce
• Supporting Material
• Impact
• Severity Assessment
• Bugcrowd Report Template
• Human Tone Rules (Avoid AI-Sounding Writing)
• Report Title Formula
• Impact Statement Formula (First Paragraph)
• The 60-Second Pre-Submit Checklist
• Severity Escalation Language
• Bug Bounty Platforms
• Learning
• Wordlists
• Payload Databases
• Related Skills & Chains
• Operator Notes (Claude-BugHunter)

When to Use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

Limitations

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see triage-validation) before reporting; report via report-writing. Prefer a sandbox, disposable VM, or controlled lab.

Example

# Read-only first step; confirm scope before anything active.
cat scope.txt  # target list from the authorized engagement brief

Adapted from elementalsouls/Claude-BugHunter (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.