---
name: hacktivity-check
description: Scrape HackerOne hacktivity and disclosed reports to detect duplicate patterns before submitting - prevents wasted submissions and reputation damage
---

# Hacktivity Check

## Usage
`/greyhatcc:hacktivity <program_name> [finding_description]`

## Smart Input
`{{ARGUMENTS}}` is parsed automatically:
- **Program handle** (e.g. `security`) → used directly with H1 API
- **H1 URL** (https://hackerone.com/security) → program handle extracted
- **Domain** (example.com) → search H1 programs for matching domain
- **Empty** → error: "Usage: /greyhatcc:<skill> <program>"

No format specification needed — detect and proceed.


Searches HackerOne's public hacktivity and disclosed reports for similar findings. This is the external duplicate check — Layer 6 of the dedup system.

## Context Loading (MANDATORY)
Before executing this skill:
1. Load scope: `.greyhatcc/scope.json` — verify target is in scope, note exclusions
2. Load hunt state: `.greyhatcc/hunt-state.json` — check active phase, resume context
3. Load program files: `findings_log.md`, `tested.json`, `gadgets.json` — avoid duplicating work
4. Load memory: Check MEMORY.md for target-specific notes from previous sessions

## Why This Exists

Internal dedup (layers 1-5) catches YOUR duplicates. Hacktivity check catches OTHER RESEARCHERS' duplicates. If someone already reported the same bug 3 months ago and it was resolved, yours will be marked duplicate.

## Method 0: HackerOne API MCP (Fastest, Most Accurate)

Use the dedicated HackerOne MCP tools for the most reliable dupe detection:

### 0a. Smart Dupe Check (Primary)
```
Use: mcp__plugin_greyhatcc_hackerone__h1_dupe_check
Arguments: { handle: "<PROGRAM_HANDLE>", vuln_type: "<FINDING_TYPE>", asset: "<ASSET>" }
```
Returns: Dupe risk assessment (HIGH/MEDIUM/LOW/CLEAR) based on live hacktivity matching.

### 0b. Full Hacktivity Scan (Comprehensive)
```
Use: mcp__plugin_greyhatcc_hackerone__h1_hacktivity
Arguments: { handle: "<PROGRAM_HANDLE>", page_size: 100 }
```
Returns: All recent activities. Manually scan for matching:
- Same vulnerability type on same/similar asset
- Same CWE or weakness category
- Similar report titles or descriptions

### Fallback
If HackerOne API is not configured or returns errors, fall through to Method 1 (Web Search).

## Method 1: Web Search (Fast, Always Available)

Search for disclosed reports matching the finding:

```
WebSearch: site:hackerone.com/reports "<vulnerability_type>" "<target_domain>"
WebSearch: site:hackerone.com "<program_name>" "<vulnerability_type>"
WebSearch: "<program_name>" bug bounty "<vulnerability_type>" disclosed
```

Parse results for:
- Report titles matching the vulnerability type
- Same asset/endpoint in disclosed reports
- Resolution status (resolved = your dupe will be marked duplicate)
- Disclosure date (recent = higher dupe risk)

## Method 2: Playwright Scrape (Thorough, Needs Browser)

If the program has public hacktivity:
1. Navigate to `https://hackerone.com/<program>/hacktivity`
2. Filter by "Disclosed" and "Resolved"
3. Search for vulnerability type keywords
4. Extract: report title, severity, asset, resolution date
5. Check for patterns matching the finding

If hacktivity is not public, Method 1 is the fallback.

## Method 3: Perplexity Deep Search (Broadest)

Use Perplexity to search across:
- HackerOne disclosed reports
- Bugcrowd disclosed reports
- Security blog posts about the target
- CVE databases for the same vulnerability
- Twitter/X security researcher discussions

```
perplexity_ask: "Has anyone reported <vulnerability_type> on <target_domain> on HackerOne or Bugcrowd? Look for disclosed bug bounty reports."
```

## Pattern Matching

After collecting search results, match against these patterns:

### High Dupe Risk (>70%)
- Same vuln type + same endpoint = almost certainly a dupe
- Same vuln type + same service = likely a dupe (root cause)
- Resolved within last 6 months = fix may still be deployed

### Medium Dupe Risk (30-70%)
- Same vuln type + different endpoint on same service = possible root cause dupe
- Similar vuln type + same technology (e.g., "Spring Boot actuator" on any endpoint)
- Program has disclosed many similar findings = they know about this class

### Low Dupe Risk (<30%)
- Different vuln type on same endpoint = probably unique
- Same vuln type but different service = probably unique
- No disclosed reports matching at all = fresh ground

## Output

```markdown
## Hacktivity Check: <finding_description>
### Program: <program_name>

### Disclosed Reports Found: <N>

| # | Report | Severity | Asset | Date | Similarity |
|---|--------|----------|-------|------|------------|
| 1 | "CORS misconfiguration on api.example.com" | Medium | api.example.com | 2025-11-15 | HIGH (same vuln + same endpoint) |
| 2 | "Reflected XSS via search parameter" | Low | www.example.com | 2025-09-01 | LOW (different vuln type) |

### Dupe Risk Assessment: [HIGH / MEDIUM / LOW / CLEAR]

### Recommendation: [SUBMIT / DO NOT SUBMIT / DIFFERENTIATE]

- SUBMIT: No similar disclosed reports found, or finding is clearly different
- DO NOT SUBMIT: High-confidence duplicate exists in hacktivity
- DIFFERENTIATE: Similar report exists but your finding has unique aspects — clearly articulate the difference in your report title and description

### If DIFFERENTIATE:
Suggested differentiators:
- Different endpoint/asset: "Your finding is on api-au.syfe.com, disclosed report was on api.syfe.com"
- Different impact: "Your finding demonstrates data exfiltration, disclosed report was CORS without proof"
- Chain component: "Your finding chains with F-003 to achieve ATO, disclosed report was standalone"
```

## Keyword Matching Strategy

### Building Search Queries
For each finding, generate multiple search queries covering different angles:

```
Query templates:
1. Exact: "<program_name>" "<exact_vuln_type>" "<exact_endpoint>"
2. Broad: "<program_name>" "<vuln_category>" site:hackerone.com
3. Tech: "<program_name>" "<technology>" vulnerability disclosed
4. Endpoint: "<program_name>" "<endpoint_path>" security
5. CWE: "<program_name>" "CWE-<number>" disclosed
```

### Keyword Expansion
Map the finding to multiple search terms:

| Finding Type | Search Keywords |
|-------------|----------------|
| CORS misconfiguration | "CORS", "cross-origin", "Access-Control", "origin reflection" |
| IDOR | "IDOR", "insecure direct object", "broken access control", "unauthorized access" |
| XSS | "XSS", "cross-site scripting", "script injection", "reflected", "stored" |
| SSRF | "SSRF", "server-side request", "internal access", "metadata" |
| SQL injection | "SQL injection", "SQLi", "database", "query injection" |
| JWT manipulation | "JWT", "token", "algorithm confusion", "none algorithm" |
| OAuth bypass | "OAuth", "redirect_uri", "token theft", "authorization bypass" |
| Subdomain takeover | "subdomain takeover", "dangling CNAME", "unclaimed", "takeover" |
| GraphQL | "GraphQL", "introspection", "batching", "query abuse" |
| Actuator exposure | "actuator", "Spring Boot", "health endpoint", "env exposure" |

### False Positive Filtering

After collecting search results, filter out false positives:

| False Positive Signal | Action |
|----------------------|--------|
| Different program, same vuln type | Ignore — not a dupe for YOUR program |
| Same program, different asset entirely | Likely not a dupe — different asset |
| Same program, same vuln, but 2+ years old | Low dupe risk — likely different root cause |
| Blog post discussing the vuln type generically | Ignore — not a program-specific disclosure |
| Report marked "Informational" or "N/A" | Note — your report may face same fate |
| Report marked "Duplicate" with original visible | Check original — YOUR finding may also be a dupe of that original |
| Report resolved but fix confirmed incomplete | Your finding may be a VARIANT — clearly differentiate in report |

### API-Based Search (When H1 API Available)

Use the dedicated HackerOne MCP server:

```
Use: mcp__plugin_greyhatcc_hackerone__h1_dupe_check
Arguments: { handle: "<program_handle>", vuln_type: "<vulnerability_type>", asset: "<target_asset>" }
```

This provides structured dupe risk assessment that is more reliable than scraping.

For deeper analysis:
```
Use: mcp__plugin_greyhatcc_hackerone__h1_hacktivity
Arguments: { handle: "<program_handle>", page_size: 100 }
```

Then search the returned activities for:
- Disclosed reports matching the vulnerability type
- Resolved reports on the same asset
- Reporter activity patterns (frequent reporters on same asset)

## Integration
- Called by `/greyhatcc:dedup` as Layer 6
- Called by hunt-loop before reporting phase
- Called by siege mode in the validation pipeline
- Can be called standalone for quick checks

## Delegation
- Quick search (web search only) → execute directly
- Deep search (Playwright + Perplexity) → `osint-researcher-low` (haiku)


## Agent Dispatch Protocol
When delegating to agents via Task(), ALWAYS:
1. **Prepend worker preamble**: "[WORKER] Execute directly. No sub-agents. Output ≤500 words. Save findings to disk. 3 failures = stop and report."
2. **Set max_turns**: haiku=10, sonnet=25, opus=40
3. **Pass full context**: scope, exclusions, existing findings, recon data
4. **Route by complexity**: Quick checks → haiku agents (-low). Standard work → sonnet agents. Deep analysis/exploitation → opus agents.

## State Updates
After completing this skill:
1. Update `tested.json` — record what was tested (asset + vuln class)
2. Update `gadgets.json` — add any informational findings with provides/requires tags for chaining
3. Update `findings_log.md` — log any confirmed findings with severity
4. Update hunt-state.json if in active hunt — set lastActivity timestamp