Security Bounty Hunter

Skill: Security Bounty Hunter

Supplementary Files:

• payloads.md — Static analysis commands, triage scripts, and PoC templates organized by vulnerability class
• test-cases.md — Structured test cases for bounty-worthy vulnerability discovery, triage, and reporting

Summary

Focuses on remotely reachable vulnerabilities that qualify for real reports and responsible disclosure, not broad best-practices reviews or theoretical findings.

Domain: assessment

Description

Hunt for exploitable, bounty-worthy security issues in target systems. Focuses on remotely reachable vulnerabilities that qualify for real reports and responsible disclosure, not broad best-practices reviews or theoretical findings.

Difference from vulnerability-assessment: vulnerability-assessment runs automated scanners for a wide inventory of weaknesses. This skill focuses on manually verifying that a specific attack path is exploitable, user-controlled, and impactful enough to submit as a bounty report.

Use Cases

• Bug bounty hunting on HackerOne, Bugcrowd, Synack, or private programs
• Responsible disclosure vulnerability research on open-source projects
• Pre-engagement proof-of-concept development for penetration tests
• Validating scanner findings to separate real vulnerabilities from false positives
• Triage of large scan results to identify which findings are actually exploitable

Core Tools

Methodology

Bounty Hunter Workflow

Step 1: Scope Check

Before any testing:

• Read the program's scope, rules, and exclusions (SECURITY.md, policy pages)
• Identify in-scope domains, IP ranges, and application types
• Note any out-of-scope targets and testing restrictions
• Check for existing reports on the same target

Step 2: Find Real Entrypoints

Focus on network-reachable attack surfaces:

• HTTP handlers, REST API endpoints, GraphQL resolvers
• File upload processing
• Webhook handlers and callback URLs
• Background job processors that consume external data
• Parser and deserializer code paths

Step 3: Triage with Static Tooling

Run automated tools as triage input only:

semgrep --config=auto --severity=ERROR --severity=WARNING --json
# Then manually filter:
# - drop tests, demos, fixtures, vendored code
# - keep only findings with a clear network or user-controlled route

Step 4: Read the Full Code Path

Trace user input from source to sink end-to-end. Confirm:

• Input is genuinely user-controlled
• The sink is meaningful and exploitable
• No intervening sanitization blocks the attack

Step 5: Prove Exploitability

Build the smallest safe PoC:

• RCE → harmless command (id, whoami)
• Data exfiltration → retrieve a known test value
• Auth bypass → access another user's resource
• SSRF → reach internal metadata endpoint

Step 6: Report

Draft a clear, reproducible report.

In-Scope Vulnerability Patterns

Skip These (Usually Low-Signal)

• Local-only deserialization with no remote path
• eval() or exec() in CLI-only tooling
• shell=True on fully hardcoded commands
• Missing security headers by themselves
• Self-XSS requiring victim to paste code manually
• Demo, example, or test-only code

Defense Perspective

• Responsible disclosure: Always report through proper channels
• Scope respect: Stay within authorized boundaries
• Do no harm: Minimize impact during testing; use safe payloads
• Documentation: Keep detailed logs of all testing activity

Report Structure

## Description
[What the vulnerability is and why it matters]

## Vulnerable Component
[File path/endpoint, line range, code snippet]

## Proof of Concept
[Minimal working request or script]

## Impact
[What the attacker can achieve]

## Affected Version
[Version, commit, or deployment target tested]

## Suggested Remediation
[How to fix it]

Detection Methods

Bug Bounty Program Audit

• Out-of-scope reports: Reports for assets not in scope.
• Duplicate rate: >50% duplicates suggests poor target selection.
• Report quality metrics: CVSS accuracy, reproduction clarity, remediation actionability.

SIEM Detection Rules

• Custom tracking: HackerOne / Bugcrowd integration for finding lifecycle.

Defense Evasion Techniques

Operational Security for Hunters

• Stay in scope: Don't access systems outside bug bounty scope; preserves legal protection.
• Don't exfiltrate data: Show only screenshots/PoCs; don't dump databases.
• Responsible disclosure: Don't publish before fix deployed.

Orchestration

ECC Loop Pattern

• Pattern: Watch Loop (continuous monitoring) + Sequential Pipeline (per-finding flow)
• Rationale: Bounty hunting benefits from continuous target monitoring (new attack surfaces appear over time) combined with a structured per-finding pipeline from discovery to report
• Integration: recon-osint (surface discovery), verification-loop (finding confirmation), knowledge-ops (cross-session pattern tracking), article-writing (report generation)

Cross-Skill Pipeline

recon-osint → security-bounty-hunter → verification-loop → article-writing
                                         ↓
                                    knowledge-ops (persist patterns)

Quality Gate

• Pre-condition: Scope verified, target authorized for testing
• Post-condition: Finding independently reproduced with different method
• Verification: Use verification-loop Phase 4 (independent confirmation)

Bug Bounty Platforms

Major platforms differ in scope model, payout ranges, and triage quality. Choosing the right platform maximizes both learning speed and earnings.

Platform selection strategy:

• New hunters: Start with HackerOne public programs to build reputation and learn triage expectations
• Intermediate: Apply for private programs on Bugcrowd and HackerOne once you have 10+ valid reports
• Advanced: Pursue Synack Red Team invite or focus on high-paying private programs
• Specialization: Some platforms have more API/IoT/mobile programs; match your skill set

Responsible Disclosure

When no formal bug bounty program exists, responsible disclosure is the ethical and often legally safest path.

Disclosure process:

1. Identify the contact channel -- Check for SECURITY.md, security@domain, or GitHub Security Advisory
2. Report privately -- Never disclose to a third party before the vendor has had reasonable time to fix
3. Set a timeline -- 90 days is the industry standard; extend for good-faith vendor engagement
4. Request CVE -- Use GitHub Security Advisory or MITRE to obtain a CVE identifier
5. Coordinate public disclosure -- Publish details only after a fix is available or the timeline expires

Legal considerations:

• Always stay within authorized scope
• Document all communication with the vendor
• Avoid accessing data beyond what is necessary to demonstrate the vulnerability
• Some jurisdictions have safe-harbor provisions for good-faith security research; know your local laws

Payout Optimization

Maximizing bounty earnings requires strategic target selection and efficient reporting:

Target selection heuristics:

• Programs with high maximum bounties but few active hunters (new programs, niche industries)
• Targets undergoing rapid feature development (new features = new bugs)
• Programs that reward "interesting" findings at higher tiers than standard CVSS suggests
• Mobile and API endpoints that receive less attention than web front-ends

Report strategies for higher payouts:

• Chain vulnerabilities to demonstrate higher impact (XSS + CSRF = account takeover)
• Include business impact analysis (regulatory, financial, reputation) alongside technical impact
• Demonstrate the widest possible blast radius in your PoC (how many users/data records affected)
• Report variants as separate findings when they affect different code paths

Time management:

• Allocate 70% of effort to recon and attack surface discovery, 30% to exploitation
• Track time-per-finding to identify which vulnerability classes give the best return
• Use automated recon to maintain a pipeline of targets; switch targets when progress stalls

Report Writing for Bounties

The quality of your report directly affects triage speed, bounty amount, and reputation score.

Report quality tiers:

Critical report elements:

1. Descriptive title -- [Vuln Type] in [Component] allows [Impact] ([Severity])
2. Step-by-step reproduction -- Numbered, copy-pasteable, starting from authentication
3. Minimal PoC -- One-click exploit script or curl command; no unnecessary complexity
4. Impact analysis -- Business consequences, number of affected users, data at risk
5. Remediation -- Specific, actionable fix recommendations with code examples
6. Evidence -- Screenshots, HTTP request/response pairs, video recordings

Common report rejection reasons:

• Out of scope (always verify scope before testing)
• Duplicate (check resolved reports before submitting)
• Informative (finding does not demonstrate real impact)
• Cannot reproduce (PoC is environment-specific or relies on race conditions without clear steps)

Quality Gate

Before submitting any report:

• The code path is reachable from a real user or network boundary
• The input is genuinely user-controlled
• The sink is meaningful and exploitable
• The PoC works and demonstrates real impact
• The issue is not already covered by an advisory, CVE, or open ticket
• The target is in scope for the program