recon-scope-triage

Validates asset ownership in ASM and recon output before security testing begins.

4.0k|628|Updated May 5, 2026
One-click install
npx skills add https://github.com/elementalsouls/Claude-BugHunter --skill recon-scope-triage
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: recon-scope-triage
Source: https://github.com/elementalsouls/Claude-BugHunter/tree/main/skills/recon-scope-triage
Command: npx skills add https://github.com/elementalsouls/Claude-BugHunter --skill recon-scope-triage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Automated recon and ASM tools keyword-match on brand names, so for targets whose name is a common word, reports are dominated by assets belonging to unrelated same-named companies. Testing these assets wastes the engagement and risks attacking innocent third parties outside scope.

Core Features & Use Cases

  • Ownership Verification Matrix: Per-source verification rules for GitHub repos, cloud buckets, mobile apps, breach combos, typosquats, and forum hits, requiring concrete ownership signals rather than scanner keyword matches.
  • Soft-404 Detection: A curl-based control comparing suspected .env/.git/actuator exposures against junk-path responses to discard catch-all false positives.
  • Triage Workflow: A five-step process covering canonical domain anchoring, per-asset verification, severity re-baselining, explicit quarantine logging, and meta-finding reporting.
  • Use Case: You receive an ASM report showing hundreds of Criticals for a dictionary-word brand. Apply the ownership checks to quarantine unrelated repos, buckets, and apps, then re-baseline severity counts against only confirmed assets before testing anything.

Quick Start

Triage this ASM report and separate confirmed owned assets from same-named third-party collisions before I start testing.

Frequently Asked Questions about recon-scope-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify asset ownership in recon output before pentesting?

Confirm the canonical owned-domain set first, then require concrete ownership signals per asset class: org-owned GitHub accounts for repos, content correlation with confirmed subdomains for buckets, and exact owned-domain matches for breach emails. Never trust a scanner's keyword match alone.

How to detect soft-404 false positives in ASM scan results?

Fetch the reported path (e.g., /.env) and a random junk path on the same host with curl, then compare response sizes and bodies. Identical responses indicate a catch-all route, meaning the finding is a false positive; differing content with expected signatures indicates a real exposure.

Why do ASM tools report assets that don't belong to my target?

ASM tools keyword-match on the brand name across global namespaces like GitHub, S3 bucket names, and app stores. For brands that are common dictionary words, this matches unrelated same-named companies, producing repos, buckets, apps, and breach combos owned by third parties.

When should recon triage happen in a security engagement?

Run ownership triage at the very start of the engagement, immediately upon receiving any ASM report, recon export, or OSINT dataset, and before testing anything. Skipping triage risks wasting the engagement on third-party assets and attacking out-of-scope organizations.

What should I do with assets that fail ownership verification?

Quarantine them explicitly in an auditable file such as loot/quarantined_<source>.txt rather than testing or silently dropping them. This documents that you saw the collisions and chose not to target them, and supports re-baselined severity counts in the final report.