| name | attack-surface-mapper |
| description | Consolidates outputs from web-recon-passive, web-recon-active, and api-recon into a single prioritized attack-surface picture - merging PASSIVE_RECON.md, ATTACK_SURFACE.md, API_INVENTORY.md, and AUTH_FLOWS.md into a deduplicated inventory ranked by risk (high-impact features, new/changed code, legacy /v1 endpoints, business-logic-rich flows). Use at the end of the recon phase to produce a single decision document that the orchestrator uses to select which class-specific hunters to run in what order. Passive-active hybrid - mostly reads prior outputs, adds minimal targeted probes for priority fingerprinting. Produces CONSOLIDATED_ATTACK_SURFACE.md with prioritization rationale. Defensive testing only. |
| model | sonnet |
| allowed-tools | Read, Grep, Glob, Write(path:.claude/planning/**), WebFetch, Bash(curl:*), Bash(wget:*), Bash(httpx:*), Bash(ffuf:*), Bash(gobuster:*), Bash(nuclei:*), Bash(jq:*), Bash(arjun:*), Bash(gf:*), Bash(gau:*), Bash(waybackurls:*), Bash(nmap:--script=safe*), Bash(nmap:-sV), Bash(nmap:-Pn), Bash(dig:*), Bash(host:*), Bash(whois:*), Bash(openssl:s_client*), Bash(openssl:x509*)
|
| metadata | {"version":"1.0.0","category":"security-testing","subcategory":"recon","authorization_required":true,"tier":"T4","source_methodology":"Metodologia de Reconhecimento e Mapeamento de Superfície de Ataque.md","service_affecting":false,"composed_from":[]} |
Attack Surface Mapper
Goal
Take the outputs of the three foundational recon skills
(web-recon-passive, web-recon-active, api-recon) plus
auth-flow-mapper and produce a single consolidated,
deduplicated, and PRIORITIZED attack-surface view. The
orchestrator uses this document to select which class-specific
hunters to run in what order. This skill does NOT re-run recon - it reads what the foundational skills already produced, identifies
gaps, adds a small number of targeted probes where priorities
depend on fingerprinting, and produces
CONSOLIDATED_ATTACK_SURFACE.md. Maps loosely to OWASP
WSTG-INFO family as a capstone. Primary output is the
prioritization decision document.
When to Use
- After ALL THREE recon skills have run (
web-recon-passive +
web-recon-active + api-recon) AND auth-flow-mapper has
produced AUTH_FLOWS.md.
- As the final recon-phase step before hunter-class skills run.
- When the orchestrator needs a risk-ranked list to choose
skill-execution order (e.g., "run auth-flaw-hunter first
because legacy /v1/auth is the highest-risk asset").
- Mid-assessment when a major new surface has been discovered
and the plan needs updating.
When NOT to Use
- Before the three foundational recon skills have run - this
skill has nothing to consolidate.
- For deep surface discovery on a single asset - use the
specific recon skill.
- For active vulnerability testing - that's the class-specific
hunters.
- Any asset not listed in
.claude/security-scope.yaml or whose
testing_level is not active.
Authorization Check (MANDATORY FIRST STEP)
Before ANY outbound activity:
- Read
.claude/security-scope.yaml. If the file doesn't exist
or doesn't parse, halt and report.
- Confirm the intended target appears in the
assets list AND
its testing_level is active.
- Most of this skill's work is reading prior skill outputs.
Any targeted probes (typically <20 requests for tech-stack
fingerprinting or version fuzzing) honor the scope's
rate-limit. This skill should never need to issue more than
~50 HTTP requests.
- If the prior-skill outputs are missing or stale (>7 days
old), halt and recommend re-running the foundational recon
skills first.
- Log the authorization check to
.claude/planning/{issue}/SECURITY_AUDIT.md Skills Run Log
with status running.
Inputs
The skill expects the caller to provide:
{issue}: the planning folder name{target}: the asset identifier from security-scope.yaml{recon_inputs}: paths to the four prior outputs
PASSIVE_RECON.mdATTACK_SURFACE.mdAPI_INVENTORY.mdAUTH_FLOWS.md
Methodology
Phase 1: Ingest and Deduplicate
-
Read all four prior outputs
[Hacking APIs, Ch 6]
Do: Parse each input into an intermediate Python / jq / awk
structure. Extract:
- Subdomains (from PASSIVE + ATTACK_SURFACE)
- Endpoints (from all four - deduplicate)
- Parameters (from ATTACK_SURFACE + API_INVENTORY)
- Auth endpoints (from AUTH_FLOWS)
- Tech stack fingerprint (from ATTACK_SURFACE + PASSIVE)
- Open findings already filed
Record: Raw deduplicated inventory in
.claude/planning/{issue}/consolidated-raw.json.
-
Cross-reference canonical entities [this skill's logic]
Do: Each asset may appear in multiple input files with
different detail levels. Merge:
- Subdomain entries → one canonical record per subdomain with
(liveness, tech stack, auth required?, is-api?)
- Endpoint entries → one canonical record per
(method, path) with (params, auth model, inventory source)
- Parameter entries → one per (endpoint, param) with
(type, location, hidden?)
Record: Normalized model.
Phase 2: Gap Detection
-
Inventory gaps between recon outputs
[Bug Bounty Bootcamp, Ch 5]
Do: Identify surface that appears in ONE source but not
others (usually a miss, sometimes a legitimate distinction):
- Subdomain in CT logs but not in
web-recon-active's scan → was it reachable?
- Endpoint in Wayback Machine but not in live spider →
decommissioned or hidden-but-live?
- API spec endpoint not covered by
api-recon's
HTTP-method fuzz → gap worth filling
Where ambiguous, issue a small number of targeted probes
(curl -sI {subdomain} for liveness,
curl -sI {endpoint} for status) - cap total at ~20 probes
to respect rate limits.
Record: Gap list + probe results.
Phase 3: Risk Classification
-
High-impact-functionality tagging
[zseanos methodology]
Do: Tag each endpoint with impact-class indicators:
- P1-critical: payment, auth, password reset, admin
function, API-key management, MFA setup
- P2-high: profile update (PII-bearing), document /
message access, multi-tenant data fetch
- P3-medium: search, display-only data, non-sensitive
updates
- P4-informational: static content, public info, public
API keys (Stripe publishable, etc.)
Use endpoint names, auth requirements, and response-shape
hints (from API_INVENTORY) to classify. When unsure,
classify one level higher rather than lower (err on side of
caution).
Record: Impact tier per endpoint.
-
Change-recency tagging [zseanos methodology]
Do: Mark endpoints as "new / recently-changed" based on
signals:
- Wayback Machine entries absent (endpoint is recent)
v2 / v3 endpoint paths (new surface relative to older
v1)- Git commit dates from public repos (if accessible via
secrets-in-code-hunter output)
- Recently-added CT-log certs for new subdomains
New code is under-tested and higher-risk. Tag with
recently_changed: true.
-
Legacy / deprecated endpoint tagging
[Bug Bounty Playbook V2]
Do: Tag endpoints that appear abandoned or deprecated:
/v1/ when /v2/ is the current production versionlegacy-*.{target} subdomains- Endpoints absent from the current OpenAPI spec but still
responding to requests
- Endpoints that lack modern headers (no HSTS, no CSP, no
rate-limit headers)
Tag with legacy: true - these are highest-yield per effort.
-
Business-logic-rich flow tagging
[Bug Bounty Bootcamp, Ch 5]
Do: Tag multi-step flows identified in AUTH_FLOWS or from
observation:
- Checkout / payment
- Account recovery
- Approval chains
- Subscription / plan changes
- Multi-party transactions
Tag with business_logic: true - these are candidates for
business-logic-hunter.
Phase 4: Prioritized Inventory
-
Produce ranked hit list [WSTG Risk Model]
Do: Combine impact-class + change-recency + legacy + business-
logic tags into a composite priority score:
priority =
impact_weight (P1=4, P2=3, P3=2, P4=1)
+ recently_changed (2)
+ legacy (3)
+ business_logic (2)
+ auth_required (1)
Sort descending. The top entries are where orchestrator-
selected hunter skills go first.
Record: Ranked inventory in
.claude/planning/{issue}/consolidated-ranked.md.
Phase 5: Skill-Dispatch Recommendations
-
Map inventory to hunter skills
[this skill's orchestration logic]
Do: For each priority group, recommend which skills should
run:
- P1 endpoints with object-ID params →
bola-bfla-hunter,
idor-hunter
- P1 auth endpoints →
auth-flaw-hunter, jwt-hunter,
session-flaw-hunter, oauth-oidc-hunter
- P1 payment/workflow →
business-logic-hunter,
rate-limit-hunter (SMS/financial cost)
- P1 URL-fetch features →
ssrf-hunter, then
ssrf-cloud-metadata-hunter if SSRF confirmed
- P1 write endpoints with JSON bodies →
mass-assignment-hunter, sqli-hunter,
excessive-data-exposure-hunter
- Reflective endpoints →
xss-hunter, dom-xss-hunter,
ssti-hunter
- XML-accepting endpoints →
xxe-hunter
- Legacy
/v1/ → extra scrutiny across ALL classes
- DNS-layer (dangling subdomains) →
subdomain-takeover-hunter
- CI/CD-infrastructure surface →
gitlab-cicd-hunter,
secrets-in-code-hunter, aws-iam-hunter,
container-hunter
- CORS-header-reflecting →
cors-misconfig-hunter
- CDN-fronted static →
cache-smuggling-hunter (staging
only)
Record: Skill-dispatch plan per priority group.
Phase 6: Synthesize CONSOLIDATED_ATTACK_SURFACE.md
-
Write the decision document
[Deliverable]
Do: Produce
.claude/planning/{issue}/CONSOLIDATED_ATTACK_SURFACE.md:
# Consolidated Attack Surface - {issue} - {target}
## Executive Summary
- Total subdomains: N (live / dangling / legacy breakdown)
- Total endpoints: N (authenticated / public / deprecated)
- Total parameters: N (hidden-discovered / documented)
- Highest-priority class: {class}
- Recommended first 5 skills: {list}
## Priority Targets (ranked)
| # | Endpoint | Method | Auth | Impact | Recent | Legacy | BL | Priority | Recommended Skills |
|---|----------|--------|------|--------|--------|--------|----|----------|--------------------|
| 1 | /v1/admin/users/{id} | DELETE | admin | P1 | - | ✓ | - | 10 | bola-bfla-hunter, auth-flaw-hunter |
| 2 | /api/v2/checkout | POST | user | P1 | ✓ | - | ✓ | 10 | business-logic-hunter, mass-assignment-hunter |
...
## Gaps in Recon
- {list of items flagged in Phase 2 that need follow-up}
## Hunter Skill Dispatch Plan
Grouped by priority:
### P1 (critical - run first)
1. `auth-flaw-hunter` on /v1/auth/* (legacy auth + change
recency)
2. `bola-bfla-hunter` on /api/v2/accounts/{id}
...
### P2 (high - run second)
...
## Class Coverage Matrix
(Which skills to run to cover which OWASP categories)
-
Status + handoff
[Orchestrator handoff]
Do: Update STATUS.md:
- Mark recon phase COMPLETE
- List the top 5 recommended skills with reasoning
- Note any scope questions that surfaced during
consolidation
Payload Library
No new payloads - consumes and prioritizes prior outputs. Any
new probes are single curl -sI liveness checks capped at ~20.
Output Format
This skill's primary output is
CONSOLIDATED_ATTACK_SURFACE.md. It files FINDINGS only for
recon-level issues not already filed by the upstream skills:
- Legacy endpoints reachable alongside modern ones →
CWE-1059 (Incomplete Retirement of Resources),
API9:2023 (Improper Inventory Management)
- Undocumented-but-live endpoints (found in live spider,
not in spec) - typically Medium - cross-reference the class-
specific hunter once assigned.
The skill also updates:
.claude/planning/{issue}/STATUS.md - marks recon complete
.claude/planning/{issue}/SECURITY_AUDIT.md Skills Run Log.claude/planning/{issue}/CONSOLIDATED_ATTACK_SURFACE.md - the primary artifact
Quality Check (Self-Review)
Before marking complete, verify:
Common Issues
-
Stale recon inputs: Inputs older than 7 days may miss
recent surface changes. Halt and request re-run if any input
is stale.
-
Conflicting reports: Two recon skills report different
HTTP method support for the same endpoint. Usually the
authenticated scan was more thorough - prefer
api-recon output over web-recon-active for API endpoints;
prefer authenticated captures over unauthenticated.
-
Prioritization arbitrariness: The composite score is a
heuristic, not a rule. Document the reasoning per top-10
entry so reviewers can sanity-check - especially when a
low-impact-class endpoint ranks high due to legacy + recent
tags.
-
Inventory explosion for large apps: Some targets have
thousands of endpoints. Consolidation should collapse similar
endpoints into patterns (e.g., /api/v2/users/{id}/* → one
entry with a note on the N specific operations under it)
rather than flat-listing every variant.
-
Authenticated-only missing from public spec: The OpenAPI
spec describes only public surface; the authenticated-only
endpoints are found in live traffic. Consolidated inventory
should mark spec-source vs live-source for each entry.
References
External:
Source Methodology
Converted from:
pentest-agent-development/notebooklm-notes/Metodologia de Reconhecimento e Mapeamento de Superfície de Ataque.md
Grounded in:
- Bug Bounty Bootcamp, Ch 5 + Ch 24 + Ch 25
- Hacking APIs, Ch 6 + Ch 7
- zseano's methodology (prioritization heuristics)
- Bug Bounty Playbook V2 (1-Day / legacy focus)
Conversion date: 2026-04-24
Conversion prompt version: 1.0
