Pentest

# Pen Test Reconnaissance Skill

Run an automated external penetration test reconnaissance against any domain. Performs endpoint discovery, security header analysis, auth mechanism probing, and vulnerability assessment.

## Usage

```
/pentest <domain>
```

Examples:
- `/pentest api.example.com`
- `/pentest www.myapp.com`

## Parameters

- `domain` (required): The target domain to test (with or without scheme). If no scheme provided, use `https://`.

## Pre-scan Gate

**This gate is mandatory. Do not skip it.**

Before running any scan, you MUST:

1. Ask the user: "Do you have written authorization to test `<domain>`? (e.g., pentest engagement letter, bug bounty scope, or it's your own infrastructure)"
2. Wait for explicit confirmation. Acceptable answers: "yes", "it's mine", "I have a pentest contract", etc.
3. If the user says "no", declines, or is ambiguous, **stop immediately** and explain why authorization is required.

Do not proceed to Phase 1 until this gate passes.

## Methodology

Execute the following phases sequentially. Use `Bash` with `curl` for all HTTP requests. Report findings as you go so the user sees progress.

### Phase 1: Infrastructure Fingerprinting

1. **DNS resolution**: `nslookup` the target to get IP addresses
2. **HTTP headers**: `curl -sI` the root URL — look for:
   - `Server` header (nginx, Apache, Cloudflare, etc.)
   - `X-Powered-By` (framework/language disclosure)
   - `X-Runtime` (Rails indicator)
   - `Via` header (proxy/CDN info)
   - `Set-Cookie` (session cookie names reveal frameworks: `_session`, `JSESSIONID`, `PHPSESSID`, etc.)
3. **SSL certificate**: Check cert subject, issuer, SANs for related domains
4. **Error page fingerprinting**: Fetch the root `/` and a known-bad path like `/nonexistent_abc_xyz` — analyze the error page HTML for framework signatures (Rails default page, Django debug, Spring Boot, etc.)

### Phase 2: Endpoint Discovery

Run these in batches using Bash for-loops with `curl -s -o /dev/null -w "%{http_code}"`.

**Documentation & Swagger paths** (test first — if found, the rest of the skill can leverage the spec):
```
/docs /swagger /swagger-ui.html /swagger/index.html /api-docs /api-docs.json
/openapi.json /openapi.yaml /swagger.json /swagger.yaml /redoc
/api/docs /api/v1/docs /api/v1/swagger /api/v2/docs
/.well-known/openapi.json /.well-known/openapi.yaml
```

**Common info/debug paths:**
```
/robots.txt /sitemap.xml /favicon.ico /.env /health /healthz /ready /status
/ping /version /config /info /metrics /debug /trace
/rails/info /rails/info/routes /rails/mailers
/graphql /graphiql /playground
```

**Admin & management paths:**
```
/admin /admin/login /admin/dashboard /administrator /manage /management
/sidekiq /resque /delayed_job /bull /arena /flower
/phpmyadmin /adminer /pgadmin /kibana /grafana /prometheus
```

**Auth paths:**
```
/login /signin /sign_in /signup /register /logout /sign_out
/oauth/token /oauth/authorize /oauth/applications
/api/v1/login /api/v1/register /api/v1/sessions /api/v1/auth
/api/v1/tokens /api/v1/registrations
/.well-known/openid-configuration
```

**For non-404 responses**: Note the HTTP status code. Key signals:
- **200**: Publicly accessible (investigate content)
- **301/302**: Redirect (check `Location` header — may reveal internal URLs or auth pages)
- **401**: Exists but needs auth (check `WWW-Authenticate` header for auth mechanism)
- **403**: Exists but forbidden (ACL-protected, still confirms existence)
- **405**: Route exists but wrong HTTP method
- **500**: Server error (potential info leak in error body)

### Phase 3: API Enumeration

If API routes are suspected (from Phase 2 or domain name like `api.*`):

1. **Determine the response signature** for real vs non-existent routes:
   - Fetch a known-good path and a known-bad path
   - Compare: content-type (`application/json` vs `text/html`), status codes, response body
   - Use this signal to distinguish real endpoints from catch-all 404s

2. **Scan resource endpoints** using the correct HTTP methods. Test both GET (without body) and POST (with `Content-Type: application/json` and `{}`). Common patterns:
   ```
   /api/v1/users /api/v1/me /api/v1/profile /api/v1/account
   /api/v1/settings /api/v1/config /api/v1/app_config
   /api/v1/notifications /api/v1/messages /api/v1/feed
   /api/v1/search /api/v1/upload /api/v1/media
   ```

3. **Test ID-based access** on discovered resource endpoints: `/api/v1/users/1`, `/api/v1/users/2`, etc. — if they all return valid responses with different content-type than 404, sequential integer IDs are in use (IDOR candidate, but do NOT claim confirmed IDOR without auth testing).

4. **Check all HTTP methods** on interesting endpoints: `GET POST PUT PATCH DELETE OPTIONS`. Note which methods are accepted.

### Phase 4: Security Analysis

**Headers audit** — check for presence/absence of:
| Header | Expected | Risk if Missing |
|--------|----------|-----------------|
| `Strict-Transport-Security` | Present with `max-age` | SSL stripping |
| `Content-Security-Policy` | Present | XSS via injected scripts |
| `X-Frame-Options` | `DENY` or `SAMEORIGIN` | Clickjacking |
| `X-Content-Type-Options` | `nosniff` | MIME sniffing |
| `Referrer-Policy` | `strict-origin-when-cross-origin` or stricter | Referer leakage |

**CORS testing:**
```bash
curl -sI <url> -H "Origin: https://evil.com" | grep -i access-control
curl -sI <url> -H "Origin: null" | grep -i access-control
```
If `Access-Control-Allow-Origin` reflects the attacker's origin or `null`, this is a misconfiguration.

**Rate limiting** — on login/auth endpoints, send 10 rapid requests and check for:
- Consistent 200s (no rate limiting — HIGH finding)
- 429 Too Many Requests (rate limited — good)
- Increasing response times (progressive throttling)
- Account lockout messages

**Input validation** — on login/register endpoints:
- Send `{}` (empty body)
- Send `null` values
- Send array where string expected: `{"email":["test@test.com"]}`
- Send malformed JSON: `{{{invalid`
- Check if error responses leak stack traces, SQL errors, or internal paths

**Rails-specific checks** (if Rails detected):
- `_method` parameter override: `POST` with `{"_method":"delete"}` — does routing change?
- `X-HTTP-Method-Override` header
- Check for exposed Sidekiq, ActiveStorage, ActionCable (`/cable`)

**Authentication mechanism:**
- Check for Bearer tokens, API keys, session cookies, or custom headers
- Test if auth errors distinguish between "user not found" vs "wrong password" (account enumeration)

### Phase 5: Public Endpoint Deep Dive

For any endpoint that returns data **without authentication**:
- Fetch and record the full response
- Assess what information is disclosed
- Check if it reveals internal config, API keys, service names, or infrastructure details

## Output Format

Produce a structured report with these sections:

```markdown
## Pen Test Recon Report: <domain>

### Target Overview
- **IP**: ...
- **Stack**: (framework, language, hosting provider)
- **Notable infrastructure**: (CDN, load balancer, admin panels)

### Discovered Endpoints
| Method | Path | Status | Auth Required | Notes |
|--------|------|--------|--------------|-------|
| ... | ... | ... | ... | ... |

### Vulnerabilities & Findings

#### HIGH
[numbered list with description and evidence]

#### MEDIUM
[numbered list]

#### LOW / INFORMATIONAL
[numbered list]

#### POSITIVE (Well-Defended)
[what the target does right]

### Recommended Next Steps
[what to test with authenticated access, manual testing, etc.]
```

## Critical Rules

1. **Never create accounts, modify data, or perform destructive actions.** This is reconnaissance only — read-only probing.
2. **Be precise about what is confirmed vs suspected.** "Route exists behind auth" is NOT the same as "data is accessible." Do not overstate findings.
3. **Don't brute-force credentials.** Testing for rate limiting (10 requests) is acceptable. Actual credential stuffing is not.
4. **Report progress as you go.** Each phase should produce visible output so the user can follow along.
5. **Adapt to the stack.** If you identify Rails, test Rails-specific vectors. If Django, test Django. Don't blindly run all checks — be targeted.
6. **Use parallel curl loops** for endpoint scanning to keep runtime reasonable.
7. **Include evidence.** Every finding should cite the exact curl command or response that proves it.