Phase 2: Endpoint Discovery & Parameter Identification¶

Overview¶

Phase 2 performs comprehensive endpoint enumeration and parameter discovery on the attack surface identified in Phase 1. This phase builds the complete catalog of endpoints and parameters that will be tested in Phase 4.

Purpose: Create a complete inventory of every API endpoint, parameter, and hidden file accessible to the application's users.

Why Completeness Matters¶

Finding vulnerabilities requires testing the complete endpoint inventory. Attackers often find Critical findings on obscure endpoints like: - /api/v1/admin/export (CMDi in filename export) - /api/v1/reports/schedule (stored XSS in cron jobs) - /internal/health (sensitive information disclosure) - /backup/config.zip (exposed source code)

Missing even one endpoint means missing the vulnerability on that endpoint.

Wave-Based Parallel Execution¶

Phase 2 uses three parallel waves:

graph TB
    A["Start Phase 2<br/>Discovery"] --> B["Wave A<br/>Katana + Auth Crawl"]
    B --> C["Wave B & C<br/>2 parallel agents"]
    C --> D["Merge Results<br/>All endpoints"]
    D --> E["Phase 2 Analysis<br/>Parameter extraction"]
    E --> F["Build<br/>test-plan.json ready"]
    F --> G["Continue to<br/>Phase 3: Scan"]

    style A fill:#4a148c,color:#fff
    style G fill:#4a148c,color:#fff
    style D fill:#ab47bc,color:#fff
    style E fill:#ab47bc,color:#fff

Wave A: Authenticated Crawling¶

Tool: Katana (Advanced Web Crawler)¶

Purpose: Crawl all discovered endpoints from Phase 1, filtering by content type and depth

docker run --rm -v $(pwd):/work pentest-tools \
  katana -u https://api.example.com \
  -o discovery/katana-urls.txt \
  -d 3 \
  -kf all \
  -jc \
  -ct application/json,text/html

Parameters explained: - -d 3: Max crawl depth (prevents infinite crawling on paginated endpoints) - -kf all: Keep all MIME types (cookies, redirects, JavaScript) - -jc: JavaScript crawling (execute JavaScript to find dynamically loaded endpoints) - -ct: Filter by content types (skip images, CSS, etc.)

Output: All URLs discovered through link following and JavaScript execution.

Authenticated Navigation¶

If authentication is required, Katana is run for each user role:

docker run --rm -v $(pwd):/work pentest-tools \
  katana -u https://api.example.com/admin \
  -H "Cookie: sessionid=ADMIN_SESSION" \
  -o discovery/katana-admin-urls.txt

Wave B & C: Parallel Endpoint Enumeration¶

Wave B and C run in parallel to maximize discovery speed:

Wave B Agent 1: Content Discovery - Common Files¶

Tool: ffuf (Fuzz Faster U Fool)

Enumerate common files and directories on the target:

docker run --rm -v $(pwd):/work pentest-tools \
  ffuf -u https://api.example.com/FUZZ \
  -w wordlist-common.txt \
  -fc 404,301 \
  -o discovery/ffuf-common.json \
  -of json

Common wordlists to use: - raft-small.txt: Quick enumeration (50K entries) - raft-medium.txt: Balanced (250K entries) - raft-large.txt: Comprehensive (1.4M entries)

Output example:

api/v1/
api/v2/
admin/
backup/
debug/
health/
swagger.json
openapi.json

Wave B Agent 2: Content Discovery - API Patterns¶

Tool: ffuf with API-specific wordlist

Enumerate API paths and backup/admin endpoints:

docker run --rm -v $(pwd):/work pentest-tools \
  ffuf -u https://api.example.com/api/FUZZ \
  -w wordlist-api.txt \
  -o discovery/ffuf-api.json

API wordlist keywords: users, posts, comments, tickets, reports, export, backup, admin, debug, health, status, version, config

Wave B Agent 3: Parameter Discovery¶

Tool: arjun

Discover hidden parameters on all discovered endpoints:

docker run --rm -v $(pwd):/work pentest-tools \
  arjun -u https://api.example.com/api/users \
  -o discovery/arjun-parameters.json

Arjun tests for: - Common parameter names: sort, order, filter, page, limit, offset, search, q, query, keyword, id, role, admin, debug, internal, test, verbose - HTTP methods: GET, POST, PUT, DELETE, PATCH - Injection parameter formats: JSON, form-data, query string, headers

Wave C Agent 1: JavaScript Analysis Pipeline¶

Tools: jsluice (AST analysis) → linkfinder (regex) → secretfinder (keys/tokens) → jshunter (entropy)

Extract sensitive information from JavaScript bundles:

docker run --rm -v $(pwd):/work pentest-tools \
  jsluice -u https://api.example.com \
  --mode sources \
  -o discovery/js-sources.json

docker run --rm -v $(pwd):/work pentest-tools \
  /opt/pentest-venv/bin/python3 << 'PYEOF'
import subprocess
result = subprocess.run([
    'linkfinder', '-i', 'discovery/js-sources.json',
    '-o', 'discovery/linkfinder-endpoints.txt'
], capture_output=True)
print(result.stdout.decode())
PYEOF

Pipeline discovers: - jsluice: All imported modules and dependencies (reveals tech stack) - linkfinder: Endpoints from string patterns (regex-based endpoint discovery) - secretfinder: API keys, AWS credentials, private tokens - jshunter: High-entropy strings (likely secrets, base64 tokens)

Example output:

/api/v1/users/import
/api/v1/reports/execute
/internal/admin/reset
/stripe/webhook
AWS_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE
STRIPE_KEY=sk_live_51234567890

Wave C Agent 2: Source Map & Inline JS Analysis¶

Technique: Extract .js.map files (source maps) for exact endpoint discovery

Modern JavaScript bundles often include source maps that reveal original source code:

docker run --rm -v $(pwd):/work pentest-tools \
  curl -s https://api.example.com/js/app.js.map | jq '.sources[]' \
  | grep -o '\./' | wc -l > discovery/source-map-files.txt

Source maps reveal: - Exact API endpoints before minification - Function names and logic flow - Parameter names and types - Error handling patterns - Authentication/authorization logic

Inline JavaScript analysis:

grep -r "fetch\|axios\|XMLHttpRequest" discovery/js-files/ \
  | grep -oE "/api/[a-zA-Z0-9/_-]+" \
  | sort -u > discovery/inline-api-endpoints.txt

Parameter Completeness (MANDATORY)¶

After endpoint enumeration, every endpoint MUST be tested for parameters. This includes non-obvious parameters:

Testing command example:

# Test sort parameter for SQLi
docker run --rm -v $(pwd):/work pentest-tools \
  curl -s "https://api.example.com/api/v1/users?sort=name' OR '1'='1" \
  -H "Authorization: Bearer TOKEN" \
  | jq '.'

Output Files¶

Example resource-map.json¶

{
  "users": {
    "endpoints": [
      "/api/v1/users",
      "/api/v1/users/{id}",
      "/api/v1/users/{id}/profile",
      "/api/v1/users/{id}/permissions"
    ],
    "id_patterns": ["numeric", "uuid", "email"],
    "idor_risk": "High"
  },
  "tickets": {
    "endpoints": [
      "/api/v1/tickets",
      "/api/v1/tickets/{id}",
      "/api/v1/tickets/{id}/comments"
    ],
    "id_patterns": ["numeric"],
    "idor_risk": "Medium"
  }
}

SPA-Specific Notes¶

For Single Page Applications: - Use ffuf -fs <size> to filter by response body size (not HTTP status) - SPAs often return 200 for all routes (SPA handles 404 in JS) - Focus on JavaScript analysis (jsluice) rather than HTTP status codes - Source maps are CRITICAL for SPAs—they contain all route names

Tech-Specific Wordlists¶

After fingerprinting in Phase 0, use tech-specific SecLists wordlists:

Completeness Gate Check¶

❌ NOT COMPLETE if: - Parameters missing for discovered endpoints - Source maps not downloaded - JavaScript not analyzed - Hidden flags not probed (debug=1, admin=1, test=1, verbose=1, etc.)

✅ COMPLETE if: - Every endpoint has parameters identified - All JavaScript files analyzed - Source maps extracted and reviewed - resource-map.json and injectable-params.json populated - Inline JavaScript reviewed for API endpoints

Next Phase¶

After Phase 2 completes, proceed to Phase 3: Automated Scanning to run vulnerability scanners against all discovered endpoints.