Skip to content

Hunting Workflows

RedPick supports several ways to actually hunt on a bug bounty target. They share the same scoped setup and program knowledge, but differ in how aggressively they automate rotation and orchestration.

Main Hunting Entry Points

Workflow Entry point Purpose
Focused manual hunt /bb-hunt --mode ... Deep work on one target and one vuln family
Auto-routed hunt /bb-hunt --auto Let the system choose the most promising mode from the current context
Rotating session /bb-session Multi-program continuous loop with timed rotation
Perpetual background hunt bugbounty/loop-manager.sh Always-on loop managed outside the interactive session

This page covers the shared hunting mechanics. The background manager is detailed separately in Perpetual Hunting Loop.

Focused Manual Hunting

The /bb-hunt skill exposes explicit modes:

  • access
  • ssrf
  • auth
  • injection
  • logic
  • chain
  • api
  • --auto

Mode routing

Each mode narrows the testing budget toward a specific group of underlying RedPick skills. Examples:

  • access emphasizes access-control and API validation
  • ssrf emphasizes callback, URL fetch, and XXE-adjacent paths
  • logic emphasizes billing, checkout, subscription, and race-condition workflows
  • api emphasizes REST, GraphQL, and mass-assignment style testing

Prerequisite phases

Before mode-specific testing starts, RedPick still runs the core early phases:

  1. context initialization
  2. walkthrough
  3. discovery
  4. smart routing

This is what keeps bug bounty hunts grounded in the same coverage-first methodology as standard pentests.

Auto Mode

/bb-hunt --auto is the depth-first operator mode.

It reads the generated context and tries to detect crown jewels such as:

  • payment and billing flows
  • file upload surfaces
  • GraphQL endpoints
  • webhook and callback URLs
  • export and backup features
  • admin and management paths
  • multi-tenant API resources

From there it biases the route toward the highest-probability mode rather than treating every target uniformly.

Session Loop Hunting

/bb-session is the higher-level continuous orchestrator.

Its standard cycle is:

  1. pick a small set of programs using intelligence and change signals
  2. load program knowledge and policy context
  3. run setup or reuse prior workspace state
  4. dispatch hunts in parallel
  5. prepare submissions for anything confirmed
  6. write new memory and rotate

This is the bridge between one-off manual hunting and the perpetual loop.

Policy and Scope Enforcement

Bug bounty hunting is stricter than general offensive work because platform policy is part of the execution contract.

Policy parsing

RedPick parses policy text into a structured ruleset with fields such as:

  • excluded vulnerability types
  • excluded keywords
  • out-of-scope domain patterns
  • special rules
  • whether an account is required
  • whether 2FA is required
  • safe harbor presence

What enforcement changes

Those policy rules then shape the actual hunt:

  • excluded vuln types are skipped
  • out-of-scope assets are not targeted
  • learned exclusions from previous rejected reports are reused
  • no_automated_scanning can force manual-only operation
  • specific rate limit language can constrain the tool choice and pace

The program policy is therefore not a note in the brief. It becomes execution state.

Claude and Codex During Hunts

RedPick keeps a strict split during active bug bounty testing:

  • Claude performs the live interaction, interprets the target, and owns the final exploit verdict
  • Codex handles bounded support work such as discovery digestion, clustering, advisory, and compact second opinions

That support includes roles like:

  • hypothesis_engine
  • critic
  • stuck_breaker
  • finding_verifier
  • chain_planner

The point is to reduce repeated Claude context spend without giving away the final live decision.

Cloudflare-Aware Operation

The bug bounty hunt path enables Cloudflare bypass support by default when available. The crawler persists cookies and reuses the clearance state across the session so real-world targets protected by Turnstile or managed challenges remain testable without constant manual intervention.

Passive Recon Between Hunts

The bug bounty system also runs passive recon between active sessions.

Current passive signals include:

  • Certificate Transparency lookups for new subdomains
  • DNS and version fingerprint monitoring
  • saved observations about deploy changes
  • placeholders for Wayback and changelog-driven drift

These signals are written back into program knowledge and become next-session hints rather than forcing the operator to rediscover them manually.

Findings During Hunting

The hunting flow does not treat every observed anomaly as a reportable vulnerability.

Typical progression is:

  1. weak signal observed
  2. evidence collected or replayed
  3. Codex advisory or FP screening used if the signal is ambiguous
  4. candidate is either dropped, kept pending, or promoted to a real finding
  5. compact session memory is updated so the next run knows what was tried

This is what makes long-running bug bounty work sustainable instead of log-driven and repetitive.

Hunting Artifacts

Across manual, session, and perpetual flows, RedPick stores reusable artifacts such as:

  • program-knowledge.json
  • attack-surface.json
  • test-history.json
  • techniques-log.json
  • policy-rules.json
  • session-memory.json
  • discovery-digest.json
  • candidate-findings.json
  • next-tests.json

The first group is long-lived program memory. The second group is compact run-to-run state meant to brief the next hunt without replaying the full raw logs.