pentest-recon

name	pentest-recon
description	Perform passive reconnaissance and attack surface mapping from the codebase. Identifies exposed endpoints, auth flows, input vectors, and potential attack paths for authorized security testing. For use in pentesting engagements, CTF, or internal security assessments only. Trigger phrases: "pentest recon", "attack surface", "map endpoints", "recon", "forge pentest-recon", "threat model", "attack surface mapping".
argument-hint	[optional: specific area — api, auth, uploads, payments]
allowed-tools	Read, Bash, Glob, Grep

Pentest Reconnaissance (Codebase-Based)

Map the application's attack surface from source code for authorized security testing.

Scope

This skill performs passive, codebase-only reconnaissance. It does NOT:

• Send any network requests
• Run active scanners
• Attempt exploitation
• Access external systems

It produces a recon report useful for planning an authorized pentest engagement.

Workflow

Step 1: Identify Stack & Entry Points

Detect the stack and find all entry points:

- Routes/endpoints: Express routes, Flask routes, FastAPI paths, API Gateway definitions
- GraphQL schemas and resolvers
- WebSocket handlers
- Static file serving
- Cron jobs / background workers
- CLI commands exposed

If $ARGUMENTS specifies an area (e.g., "auth", "api", "uploads"), focus only on that.

Step 2: Map Attack Surface

For each endpoint/entry point found, document:

| Method | Path | Auth | Input | Handler | Notes |
|--------|------|------|-------|---------|-------|
| POST | /api/login | none | body(email,pass) | auth.controller:34 | rate limited? |

Categorize by risk:

• Unauthenticated endpoints — highest priority
• File upload/download endpoints — type validation? size limits?
• Payment/financial endpoints — auth + validation depth?
• Admin/privileged endpoints — role checks? RBAC?
• User input endpoints — validation schemas present?

Step 3: Auth Flow Analysis

Map the complete authentication and authorization flow:

• How are sessions/tokens created? (JWT, session cookie, OAuth)
• Where are tokens stored? (httpOnly cookie, localStorage, header)
• Token expiration and rotation policy
• Password reset flow (token generation, expiry, single-use?)
• OAuth/social login flows (state parameter, PKCE?)
• Role/permission model (RBAC, ABAC, simple role field?)
• Where is auth middleware applied? Any gaps?

Step 4: Input Vector Analysis

For each input point:

• What validation is applied? (schemas, manual checks, none?)
• Is the input used in SQL queries? (parameterized or concatenated?)
• Is the input reflected in HTML responses? (XSS vector?)
• Is the input used in file system operations? (path traversal?)
• Is the input used in command execution? (command injection?)
• Is the input used in URL construction? (SSRF?)
• File uploads: type checking, size limits, storage location, filename sanitization?

Step 5: Data Flow Mapping

Track sensitive data through the application:

• Where is PII stored? (database columns, logs, caches?)
• Where are secrets used? (env vars, config files, hardcoded?)
• What data is returned in API responses? (over-exposure?)
• What data is logged? (sensitive data in logs?)
• What data crosses trust boundaries? (client ↔ server, service ↔ service)

Step 6: Third-Party Integration Analysis

For each external service/API integrated:

• What data is sent to the third party?
• How are API keys stored and rotated?
• Is the integration validated on both request and response?
• Webhook endpoints: signature verification present?

Step 7: Recon Report

## Pentest Recon Report
Date: <timestamp>
Application: <project name>
Stack: <detected stack>

### Attack Surface Summary
- Total endpoints: X (Y unauthenticated)
- File upload points: X
- Admin endpoints: X
- External integrations: X

### High-Value Targets (start testing here)
1. <endpoint> — <why it's interesting>
2. ...

### Auth Flow
<diagram or description>

### Endpoint Map
<table from Step 2>

### Input Vectors
<findings from Step 4, ordered by risk>

### Data Flow Concerns
<findings from Step 5>

### Suggested Test Cases
- [ ] <specific test to run> — targets <endpoint> for <vuln type>
- [ ] ...

### Out of Scope (needs active testing)
- Rate limiting verification
- Session fixation testing
- Business logic bypass
- Race conditions

Principles

• Codebase only. No network requests, no active scanning.
• Authorized use only. This report is for planning legitimate security assessments.
• Actionable output. Every finding should have a specific test case the pentester can execute.
• No exploitation. Map the surface, don't prove the vuln — that's the pentester's job.