hackerone-recon · diff
git:20260504.2a64374 to git:20260529.8f6ea0e
29 added, 72 removed. Audit A to A.
---
name: hackerone-recon
- description: Pre-engagement reconnaissance workflow using HackerOne MCP tools to enumerate program scope, study prior disclosures, and identify high-value targets before active testing.
+ description: Pre-engagement reconnaissance workflow using HackerOne MCP tools to enumerate program scope, study prior disclosures, and identify high-value targets. Use when starting a new HackerOne program engagement, building an asset inventory, or planning target selection before active testing.
---
- # HackerOne Pre-Engagement Reconnaissance
-
- Use this workflow at the start of any engagement against a HackerOne program. The goal is to fully understand the program's scope, rules, weakness taxonomy, and disclosure history before sending a single test request.
-
- ## Prerequisites
+ # HackerOne Pre-Engagement Recon
- - HackerOne MCP server running with valid credentials (`H1_USERNAME` + `H1_API_TOKEN`)
- - Run `hackerone_health` to verify connectivity and confirm your profile
+ Prerequisite: HackerOne MCP server running with valid credentials (`H1_USERNAME` + `H1_API_TOKEN`). Verify with `hackerone_health`.
## Phase 1: Program Intelligence
- ### 1.1 Retrieve Program Details
-
+ ### 1.1 Retrieve program details
```
hackerone_get_program(program_handle="<handle>")
```
-
- Extract and note:
- - **Program type**: Bug Bounty (paid) vs VDP (no bounty). Adjust effort accordingly.
- - **Submission state**: Is the program currently accepting reports?
- - **Response metrics**: Average time to first response, resolution, and bounty award. Programs with slow triage (>30 days) require more patience and stronger evidence.
- - **Bounty splitting**: If enabled, consider collaboration.
- - **Policy**: Read the full policy. Look for:
- - Excluded vulnerability types (often: DoS, social engineering, self-XSS, rate limiting)
- - Required testing restrictions (no automated scanning, no production data access)
- - Safe harbor language and scope limitations
- - Minimum severity thresholds for bounty eligibility
+ Extract: program type (bounty vs VDP), submission state, response metrics, bounty splitting, excluded vuln types, severity thresholds.
- ### 1.2 Enumerate Scope Assets
+ **Checkpoint:** If program is not accepting submissions, stop. If response metrics show >30 day triage, prepare stronger evidence.
+ ### 1.2 Enumerate scope assets
```
hackerone_get_program_scope(program_handle="<handle>")
```
-
- For each asset, record:
- - **Asset type**: URL, WILDCARD, DOMAIN, CIDR, SOURCE_CODE, MOBILE_APPLICATION
- - **Asset identifier**: The actual target (e.g., `*.example.com`, `https://api.example.com`)
- - **Bounty eligibility**: Not all in-scope assets are bounty-eligible
- - **Max severity**: Some assets cap severity (e.g., staging environments capped at medium)
- - **Instructions**: Per-asset notes from the program (testing restrictions, focus areas)
-
- **Prioritize by:**
- 1. Bounty-eligible assets with `max_severity: critical` — highest ROI
- 2. Wildcard domains — largest attack surface, most likely to have overlooked subdomains
- 3. API endpoints — often less hardened than main web apps
- 4. Recently added assets (cross-reference with bbscope_updates if available)
+ Record for each asset: type, identifier, bounty eligibility, max severity, per-asset instructions.
- ### 1.3 Map Accepted Weaknesses
+ **Prioritize:** (1) bounty-eligible + critical severity cap, (2) wildcard domains, (3) API endpoints, (4) recently added assets.
+ ### 1.3 Map accepted weaknesses
```
hackerone_get_program_weaknesses(program_handle="<handle>")
```
-
- This tells you which CWE categories the program accepts. Use it to:
- - Focus testing on accepted weakness types
- - Avoid wasting time on categories the program explicitly excludes
- - Note the weakness IDs — you will need them when submitting reports via `hackerone_submit_report`
+ Record CWE categories accepted. You need `weakness_id` values for report submission.
## Phase 2: Prior Art Analysis
- ### 2.1 Study Disclosed Reports (Hacktivity)
-
+ ### 2.1 Study disclosed reports
```
hackerone_search_hacktivity(program="<handle>")
```
-
- Disclosed reports reveal:
- - **What has been found before** — if 5 researchers found XSS in the search page, find something different
- - **Bounty amounts by severity** — calibrate your expectations and prioritize accordingly
- - **Program's bug preferences** — some programs reward certain vulnerability classes more generously
- - **Triage patterns** — how the program classifies and responds to different finding types
-
- ### 2.2 Review Your Own Report History
+ Identify: previously found vuln types, bounty amounts by severity, triage patterns. Avoid duplicating known findings.
+ ### 2.2 Review your own history
```
hackerone_search_reports(program="<handle>")
```
-
- If you have prior reports against this program:
- - Check for `informative` or `not-applicable` verdicts — understand what the program rejects
- - Review `duplicate` reports — what is already known
- - Check `triaged` or `new` reports — avoid testing the same surface while reports are pending
+ Check for `informative`/`not-applicable` verdicts (understand rejections), `duplicate` (known issues), `triaged`/`new` (avoid testing same surface).
## Phase 3: Target Selection
- After completing Phases 1 and 2, synthesize your findings:
+ 1. Build asset inventory with types, bounty eligibility, max severity
+ 2. Cross-reference with hacktivity -- deprioritize heavily-tested surfaces
+ 3. Record `structured_scope_id` for each target
+ 4. Record `weakness_id` for expected vuln types
+ 5. Respect per-asset instructions and policy restrictions
- 1. **Build the asset inventory**: All in-scope targets with their types, bounty eligibility, and max severity
- 2. **Cross-reference with hacktivity**: Remove heavily-tested surface areas, prioritize under-explored assets
- 3. **Identify the scope IDs**: For each target you plan to test, record its `structured_scope_id` — you will need this for report submission
- 4. **Note the weakness IDs**: For vulnerability types you expect to find, record the `weakness_id` values
- 5. **Set testing boundaries**: Respect per-asset instructions and program policy restrictions
+ **Checkpoint:** Before active testing, confirm you have: scope IDs, weakness IDs, asset inventory, and have read the full program policy.
- ## Phase 4: Report Submission (Post-Testing)
+ ## Phase 4: Report Submission
- When you have a confirmed finding (after the full pipeline: `assess_confidence` → `report-preflight` → `exploit-verifier` → `report-writer`):
+ After the full pipeline (`assess_confidence` -> `report-preflight` -> `exploit-verifier` -> `report-writer`):
```
hackerone_submit_report(
program_handle="<handle>",
title="[Vuln Type] in [Component] Leads to [Impact]",
vulnerability_information="<detailed report with PoC>",
impact="<concrete impact statement>",
severity_rating="<none|low|medium|high|critical>",
weakness_id="<CWE weakness ID from Phase 1.3>",
structured_scope_id="<scope asset ID from Phase 1.2>"
)
```
- Including `weakness_id` and `structured_scope_id` improves triage speed and demonstrates thoroughness.
-
- After submission, use `hackerone_get_report_activities` to monitor triage status and `hackerone_add_comment` to respond to triager questions.
+ Monitor with `hackerone_get_report_activities`. Respond to triager questions via `hackerone_add_comment`.
## Anti-Patterns
- - **Do not skip Phase 1.** Testing without reading the policy wastes time on excluded categories and risks violating program rules.
- - **Do not submit without scope/weakness IDs.** Reports without these require manual triager classification and signal lower researcher quality.
- - **Do not submit unverified findings.** The reporting pipeline (`assess_confidence` → `report-preflight` → `exploit-verifier` → `report-writer`) exists for a reason. Skipping it leads to `informative` verdicts and damaged reputation.
- - **Do not ignore hacktivity.** Submitting duplicates of known issues damages your signal score.
- - **Do not test out-of-scope assets.** Even if you find something, it will be closed as `not-applicable`.
+ - **Skipping Phase 1** -- wastes time on excluded categories, risks violating rules
+ - **Submitting without scope/weakness IDs** -- signals low researcher quality
+ - **Skipping verification pipeline** -- leads to `informative` verdicts
+ - **Ignoring hacktivity** -- submitting known duplicates damages signal score
+ - **Testing out-of-scope assets** -- findings closed as `not-applicable`