src-hunter

name	src-hunter
description	Structured SRC bug bounty hunting for security response centers: intake scoped targets and payout rules, recon subdomains and perimeters, enumerate attack surface, hunt prioritized vulnerability classes with time-boxed discipline, and report with evidence discipline. Use when hunting on SRC platforms, running time-boxed bounty campaigns, or applying China-specific asset fingerprinting.
domain	cybersecurity
subdomain	web-application-security
tags	["bug-bounty","src","reconnaissance","web-application-security","pentesting","vulnerability-hunting"]
version	1.0
author	oyi77
license	Apache-2.0
nist_csf	["DE.AE-02","ID.RA-01","RS.AN-03"]

SRC Bug Bounty Hunting

Overview

Security Response Centers (SRCs, 安全应急响应中心) run scoped, rules-based bug bounty programs with payout tables, explicit out-of-scope lists, and strict compliance red lines. Hunting them productively is a staged campaign — intake, recon, enumeration, hunt, report — where the highest-value failures are scope violations and evidence gaps, not missed vulnerabilities.

This skill encodes that campaign structure plus China-specific asset fingerprinting (OA/中间件 identification, ICP-style asset mapping) and the compliance discipline SRC programs enforce. It complements general bug-hunting skills with the scope/payout discipline and time-boxed prioritization that SRC platforms demand.

Source: cherry-picked and translated from zhaoxuya520/reverse-skill (skills/pentest-tools/src-hunter, MIT license). Reference payload libraries are not bundled; this skill is the standalone workflow.

When to Use

Trigger phrases:

• "hunt on this SRC program"
• "SRC bounty campaign"
• "scope-in/scope-out for a Chinese SRC"
• "time-boxed vulnerability hunt"
• "report a finding to an SRC"
• "China asset fingerprinting for bounty"

Use this skill when:

• You are working a scoped SRC/bug bounty target with published rules and payout tables.
• You need a repeatable, evidence-disciplined campaign rather than ad hoc probing.
• Out-of-scope boundaries and compliance red lines must be respected.

Prerequisites

• Scope authorization for every asset tested (see red lines below).
• A recon toolset: subdomain enumeration, HTTP probing, directory/parameter fuzzing, and a vulnerability scanner for confirmation.
• The program's rules page: scope, out-of-scope, payout table, reporting format.

Workflow

Phase 1: Intake

• Record the scoped target list, the out-of-scope list, the rules, and the payout table in a campaign notes file.
• Note submission format and any "do not test" conditions (production hours, rate limits, WAF behavior).
• Define the campaign time box and the target classes in scope.

Phase 2: Recon

• Subdomain discovery: passive (certificate transparency, DNS) then active (brute force) enumeration; validate resolvable, live hosts.
• Perimeter mapping: CDN/WAF identification (knowledge-pass these — see red lines), origin discovery, cloud asset inventory.
• File-browser and API discovery: exposed directories, JS bundle endpoints, API documentation endpoints, and versioned API surfaces.