Pentest

You are in AUTONOMOUS MODE. Do NOT ask questions. Hunt for exploitable vulnerabilities methodically.

TARGET: $ARGUMENTS

If no arguments provided, perform a full code-level penetration test of the project in the current working directory. If arguments specify a scope (e.g., "auth module", "API routes"), focus the analysis on that area.

============================================================ PHASE 0: RECONNAISSANCE

Map the application's attack surface:

TECH STACK:

• Detect framework, language, database, auth mechanism
• Identify entry points (HTTP routes, WebSocket handlers, CLI commands, queue consumers)
• Map middleware chain (auth, validation, rate limiting, logging)

ROUTE INVENTORY:

• List ALL defined routes/endpoints with their HTTP methods
• Note which routes have authentication middleware
• Note which routes accept user input (body, query, params, headers, files)
• Flag routes that perform privileged operations

DATA FLOW MAPPING:

• Trace user input from entry point through processing to output/storage
• Identify where input is validated, sanitized, or escaped
• Identify where input reaches dangerous sinks (database, shell, filesystem, HTML)

Record the full attack surface map before beginning targeted analysis.

============================================================ PHASE 1: SQL / NOSQL INJECTION

Hunt for injection points in database interactions:

SQL INJECTION:

• Search for string concatenation in SQL: "SELECT * FROM " + table
• Search for template literals in SQL: `SELECT * FROM ${table}`
• Search for format strings in SQL: "SELECT * FROM %s" % table
• Check ORM raw query methods for unsanitized input
• Check stored procedures called with dynamic parameters
• Verify parameterized queries are used consistently

NOSQL INJECTION:

• MongoDB: Search for $where, $regex, $gt, $ne with user input
• MongoDB: Check for object injection via JSON.parse(userInput) in queries
• Firestore: Check for user-controlled field paths in queries
• Redis: Check for user input in command strings

For each finding:

• Location: file:line
• Severity: Critical
• Proof-of-concept: Example malicious input that would exploit the flaw
• Fix: Parameterized query replacement code

============================================================ PHASE 2: CROSS-SITE SCRIPTING (XSS)

Hunt for XSS vectors:

REFLECTED XSS:

• User input reflected in HTML responses without encoding
• Search parameters displayed on results pages
• Error messages containing user input
• URL path segments rendered in page content

STORED XSS:

• User-generated content (comments, profiles, messages) rendered without escaping
• File names displayed without sanitization
• User-uploaded HTML/SVG files served inline

DOM-BASED XSS:

• document.write() with URL fragments or query parameters
• innerHTML assignment with user-controlled data
• eval() or Function() with user input
• location.href / window.open() with user-controlled URLs
• jQuery .html() with unescaped data

TEMPLATE INJECTION:

• Server-side template injection (SSTI): user input in template strings
• Client-side: dangerouslySetInnerHTML, v-html, [innerHTML], {!! !!}
• Missing auto-escape: <%- %> (EJS), | safe (Jinja2), {{{ }}} (Handlebars)

For each finding:

• Location: file:line
• Severity: High-Critical
• Proof-of-concept: <script>alert(1)</script> or context-specific payload
• Fix: Proper encoding/escaping code

============================================================ PHASE 3: AUTHENTICATION BYPASS

Hunt for authentication weaknesses:

MISSING AUTH:

• Routes handling sensitive data without auth middleware
• Admin endpoints accessible without admin role check
• API endpoints that should require auth but do not
• WebSocket connections without authentication handshake

AUTH LOGIC FLAWS:

• JWT verification that can be bypassed (algorithm confusion, missing expiry check)
• Session tokens predictable or not cryptographically random
• Password reset tokens reusable or long-lived
• OAuth state parameter missing (CSRF on OAuth flow)
• Remember-me tokens without proper validation

CREDENTIAL ATTACKS:

• No rate limiting on login endpoint
• No account lockout after failed attempts
• User enumeration via different error messages (valid vs invalid email)
• Timing attacks on authentication (measurably different response times)

For each finding:

• Location: file:line or route definition
• Severity: Critical-High
• Proof-of-concept: Steps to bypass authentication
• Fix: Middleware addition or logic correction

============================================================ PHASE 4: AUTHORIZATION FLAWS

Hunt for privilege escalation:

HORIZONTAL PRIVILEGE ESCALATION:

• Accessing other users' resources by changing ID parameters
• Missing ownership checks: findById(req.params.id) without where: { userId: req.user.id }
• Batch endpoints that do not filter by the requesting user
• File access without ownership verification

VERTICAL PRIVILEGE ESCALATION:

• Admin functions accessible by regular users
• Role changes possible without admin authorization
• Missing role checks on mutation endpoints (only checked on read)
• Client-side-only role enforcement (no server-side check)

MASS ASSIGNMENT:

• Request body spread directly into database updates: Model.update(req.body)
• User can set role, isAdmin, balance via API request
• GraphQL mutations accepting arbitrary fields

For each finding:

• Location: file:line
• Severity: Critical-High
• Proof-of-concept: Example API call exploiting the flaw
• Fix: Authorization middleware or ownership check code

============================================================ PHASE 5: PATH TRAVERSAL AND FILE INCLUSION

Hunt for file system attacks:

PATH TRAVERSAL:

• User input in fs.readFile(), open(), File() without path sanitization
• File download endpoints using user-supplied filenames
• Pattern: path.join(baseDir, userInput) without ../ prevention
• Image/document serving with user-controlled paths

FILE UPLOAD:

• Missing file type validation (only checking extension, not magic bytes)
• Missing file size limits
• Uploaded files stored in web-accessible directories
• Uploaded filenames not sanitized (may contain ../ or special chars)
• No virus/malware scanning on uploads

LOCAL FILE INCLUSION:

• Dynamic require() or import() with user input
• Template file paths from user input
• Configuration file paths from user input

For each finding:

• Location: file:line
• Severity: High-Critical
• Proof-of-concept: ../../etc/passwd or equivalent payload
• Fix: Path sanitization code

============================================================ PHASE 6: COMMAND INJECTION

Hunt for command injection:

DIRECT INJECTION:

• child_process.exec() with user input: exec("convert " + filename)
• os.system(), subprocess.run(shell=True) with user arguments
• Runtime.exec() with unsanitized parameters
• Backtick execution with user data

INDIRECT INJECTION:

• User input in environment variables passed to subprocesses
• User-controlled arguments in CLI tool invocations
• CRON job expressions from user input
• Git commands with user-supplied branch/repo names

For each finding:

• Location: file:line
• Severity: Critical
• Proof-of-concept: ; cat /etc/passwd or $(whoami) payload
• Fix: Use array-form exec, escape arguments, or avoid shell execution

============================================================ PHASE 7: CSRF AND REQUEST FORGERY

Hunt for CSRF vulnerabilities:

MISSING CSRF PROTECTION:

• State-changing POST/PUT/DELETE endpoints without CSRF tokens
• Missing SameSite cookie attribute
• CORS allowing credentials with broad origins
• Form submissions without anti-CSRF tokens

SSRF:

• User-supplied URLs passed to HTTP clients (fetch, axios, requests)
• URL redirects without origin validation
• Webhook URLs from user input fetched server-side
• Image/preview URLs fetched without allowlist

OPEN REDIRECTS:

• Redirect URLs from query parameters without validation
• Login redirect (?next= or ?redirect=) without allowlist
• OAuth callback URLs not properly validated

For each finding:

• Location: file:line
• Severity: Medium-High
• Proof-of-concept: Example malicious URL or forged request
• Fix: CSRF token implementation, URL validation code

============================================================ PHASE 8: SECRETS AND CREDENTIALS

Hunt for hardcoded secrets:

PATTERNS TO SEARCH:

• API keys: strings matching [A-Za-z0-9_-]{20,} near key-related variables
• AWS keys: AKIA[0-9A-Z]{16}
• Private keys: -----BEGIN (RSA |EC |)PRIVATE KEY-----
• JWT secrets: hardcoded strings in JWT sign/verify calls
• Database passwords: connection strings with embedded credentials
• OAuth client secrets: hardcoded in source (not env vars)
• Encryption keys: hardcoded byte arrays or strings used as keys

CHECK CONFIGURATION:

• .env files committed (not in .gitignore)
• Secrets in docker-compose.yml (not using Docker secrets)
• Secrets in CI/CD config files (not using secret variables)
• Secrets in client-side/frontend code (visible to users)

For each finding:

• Location: file:line
• Severity: Critical
• Secret type: [what kind of credential]
• Fix: Move to environment variable or secret manager

============================================================ PHASE 9: INSECURE DESERIALIZATION

Hunt for deserialization attacks:

• JSON.parse() on untrusted input used to construct queries or commands
• pickle.loads() on user-supplied data (Python)
• yaml.load() without SafeLoader (Python)
• unserialize() on user input (PHP)
• ObjectInputStream with untrusted data (Java)
• Marshal.load() on untrusted data (Ruby)
• XML parsing without disabling external entities (XXE)

For each finding:

• Location: file:line
• Severity: High-Critical
• Proof-of-concept: Malicious serialized payload structure
• Fix: Safe deserialization method or input validation

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing the security analysis, validate thoroughness:

1. Verify every category in the audit was actually checked (not skipped).
2. Verify every finding has a specific file:line location.
3. Verify severity ratings are justified by impact assessment.
4. Verify no false positives by re-reading flagged code in context.

IF VALIDATION FAILS:

• Re-audit skipped categories or vague findings
• Verify or remove false positives
• Repeat up to 2 iterations

============================================================ OUTPUT

Penetration Test Report (Code Analysis)

Project: [name] Stack: [detected technologies] Scope: [full project or specified scope] Date: [date]

Executive Summary

Findings

For each finding, in severity order:

[SEVERITY] — [Finding Title]

• Category: [e.g., SQL Injection]
• Location: path/to/file.ts:42
• Description: [What the vulnerability is]
• Proof-of-concept:

  [Example exploit payload or steps]
  

• Impact: [What an attacker could achieve]
• Fix:

  [Code showing the remediation]
  

Attack Surface Summary

• Total routes: N
• Unauthenticated routes: N
• Routes accepting user input: N
• Routes with dangerous sinks: N

Remediation Priority

[Ordered list: Critical findings first, with effort estimates]

============================================================ NEXT STEPS

After reviewing the pentest report:

• "Fix all Critical findings immediately — these are exploitable."
• "Run /owasp for a systematic OWASP Top 10 compliance check."
• "Run /encryption to address cryptographic weaknesses."
• "Run /dependency-scan to fix vulnerable component findings."
• "Run /secure after remediation to verify the security posture improved."

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /pentest — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT

• Do NOT execute actual exploits — this is static code analysis only.
• Do NOT send network requests to test vulnerabilities.
• Do NOT expose full secret values — redact all but first 4 characters.
• Do NOT modify any code — report findings with suggested fixes only.
• Do NOT report theoretical vulnerabilities without code evidence — every finding must cite a specific file and line.
• Do NOT conflate "possible" with "confirmed" — clearly state confidence level.
• Do NOT skip any phase — even if the project seems small, check all categories.
• Do NOT install external tools — analyze the source code directly.