# Pentesting Everything

> Guides authorized penetration testing with PentestingEverything as the source-grounded knowledge base. Use when scoping an engagement, building domain checklists, hunting a vulnerability class, choosing tools/commands, or drafting evidence-based findings from this repository's Markdown.

- Skill: `m14r41/pentesting-everything` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add m14r41/pentesting-everything`
- Raw SKILL.md: https://api.skillmd.com/api/skills/m14r41/pentesting-everything/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: MIT
- Author: m14r41 (https://skillmd.com/u/m14r41)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/m14r41/pentesting-everything

---


# PentestingEverything

Use this repository as a practical, citable workflow for **authorized**
security assessments. Prefer repository evidence over memory. Do not invent
authorization, scope, or findings.

Companion sites:

- Knowledge base: https://pentesting.m14r41.in
- Checklist companion: https://checklist.m14r41.in
- Upstream repo: https://github.com/m14r41/PentestingEverything

## Ground rules

1. **Lawful use only.** Proceed only for systems the user is authorized to test.
2. **Never invent authorization.** If scope, rules of engagement, or written permission is unclear, ask before any active testing guidance.
3. **Confirm before active testing.** After drafting a plan or checklist, ask the user to confirm targets and constraints before recommending live attacks.
4. **Gate high-impact actions.** Require explicit written scope for destructive tests, denial-of-service or load abuse, credential stuffing at scale, phishing or social engineering against real people, persistence, lateral movement outside agreed hosts, or exfiltration of real personal data.
5. **Source-grounded answers.** Read repository Markdown (or the live site page) before teaching methodology, payloads, or tool commands. Cite paths and URLs used.
6. **Neutral, professional tone.** Accurate and practical; no hype or emoji in deliverables.
7. **Pace automated requests.** When running as an autonomous agent rather than alongside an interactive tester, respect the program's stated rate limits and testing window before looping requests. Unattended request floods are how agentic runs trigger a WAF ban or breach program rules that a human tester would have paced instinctively.

## When to use

Apply when the user asks to:

- Plan or run a pentest, VAPT, or security assessment
- Build a checklist for web, API, mobile, cloud, Active Directory, network, and related domains
- Look up how to test a vulnerability class (SQL injection, IDOR, SSRF, and similar)
- Draft findings, evidence notes, or report sections from this knowledge base
- Orient inside PentestingEverything folders or the live docs site

## Workflow

Track progress:

```text
Engagement progress:
- [ ] 1. Confirm authorization and scope
- [ ] 2. Identify assessment domain(s)
- [ ] 3. Locate repository sources
- [ ] 4. Read source material
- [ ] 5. Produce plan + prioritized checklist
- [ ] 6. User confirms active testing
- [ ] 7. Provide non-destructive guidance with evidence capture
- [ ] 8. Draft report-ready findings
```

### 1. Confirm authorization and scope

Collect or ask for:

| Field | Examples |
| --- | --- |
| Authorization | Written rules of engagement, bug bounty program, lab ownership |
| Targets | Domains, IPs, apps, APIs, accounts, cloud accounts |
| Environment | Lab / staging / production |
| Constraints | Hours, rate limits, excluded hosts, data handling |
| Goals | Auth bypass, data exposure, privilege escalation, etc. |

If any field is missing for **active** work, stop and ask. Educational or
lab-only questions may continue with clearly labeled assumptions.

Example:

> Assumptions: lab target `dvwa.local`, no production systems, no denial-of-service, no phishing.

### 2. Identify assessment domain(s)

Map the request to one or more top-level folders. Use
[REPOSITORY_MAP.md](REPOSITORY_MAP.md) for the full list.

Quick routing:

| User intent | Start here |
| --- | --- |
| Web app / OWASP / XSS / SQL injection | `Web Application Pentesting/` |
| REST / GraphQL / BOLA | `API Pentesting/` |
| Android / iOS | `Mobile Pentesting/` |
| AWS / Azure / GCP | `Cloud Pentesting/` |
| Internal hosts / services | `Network Pentesting/` |
| Active Directory / Kerberos / BloodHound | `Active Directory Pentesting/` |
| SAST / source review | `Secure Code Review/` |
| LLM / MCP apps | `LLM Security Assessment/`, `MCP Security Assessment/` |

Prefer the narrowest matching topic folder under that category.

### 3. Locate repository sources (local first)

**Prefer a local clone** of this repo when available:

1. Category landing page: `<Category>/README.md` (case may vary: `readme.md`)
2. Topic or vulnerability folder: often `<Category>/Vulnerabilities/<Topic>/README.md`
3. Dedicated cheat sheets (`*Cheatsheet*.md`, `Handy-command.md`) when the ask is
   "give me the command" rather than "explain the technique" - see the cheat
   sheet table in [REPOSITORY_MAP.md](REPOSITORY_MAP.md)
4. PDFs under `<Category>/References/` - note them; extract only if needed

**Remote fallbacks** when the clone is not open:

- GitHub tree: `https://github.com/m14r41/PentestingEverything/tree/main/<path>`
- Live docs: https://pentesting.m14r41.in

Search strategy in a local workspace:

1. Search category `README` tables for the vulnerability or topic name
2. Glob `**/<Topic>/**/*.md` under that category
3. Read the topic `README` fully before summarizing
4. Pull adjacent notes only if they change the checklist

### 4. Read before teaching

For every technique recommended:

1. Open the relevant Markdown file(s)
2. Extract methodology, test cases, and commands that fit the user's scope
3. Replace real secrets and targets with placeholders: `<TARGET>`, `<USER_ID>`, `<TOKEN>`
4. Prefer non-destructive validation first (recon, auth mapping, IDOR with own objects, safe probes)
5. If guidance is outdated, incomplete, or version-sensitive, supplement with a primary source (OWASP, vendor docs, CVE advisory) and say what came from the repo versus external material

Never paste repository PDFs wholesale. Summarize and link.

### 5. Produce deliverables

Use templates in [OUTPUT_TEMPLATES.md](OUTPUT_TEMPLATES.md). Default package:

1. **Engagement assumptions** - scope, constraints, out-of-scope
2. **Prioritized checklist** - ordered by likely impact and effort for this target
3. **Safe command sketches** - placeholders only; note required tools
4. **Evidence plan** - what to capture (request/response, screenshots, IDs)
5. **Finding drafts** - only after confirmed issues, or clearly marked as *hypotheses*

Keep checklists actionable. One checkbox equals one testable assertion.

### 6. Active testing gate

Before recommending live attack steps, ask the user to confirm:

- In-scope targets
- Allowed accounts and roles
- Whether production is included
- Whether high-impact actions above are permitted

If they decline or are unsure, continue with planning, recon-only guidance, or lab exercises.

### 7. Evidence and reporting

Before drafting any finding, rule out common false-positive patterns: a WAF or
proxy echoing the payload back unexecuted, timing noise mistaken for a
blind-injection signal, behavior that is already publicly disclosed or
patched, and duplicate reports on the same program. If the signal doesn't
survive a second, independent reproduction attempt, label it a hypothesis, not
a finding.

For each confirmed finding, capture:

- Title, severity (with rationale), affected asset
- Steps to reproduce (minimal, numbered)
- Evidence (sanitized)
- Impact and remediation
- Repository and external references cited

Do not claim a vulnerability is confirmed without user-provided evidence or an
authorized run the user performed. Label speculative items as hypotheses.

## Citation format

Always cite sources used:

```markdown
Sources:
- `Web Application Pentesting/Vulnerabilities/SSRF/readme.md`
- https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
```

Use exact repo-relative paths when working from a clone.

## Out of scope for this skill

- Does not grant or imply authorization to attack systems
- Does not replace written rules of engagement or a bug bounty policy
- Does not automatically run exploits against remote targets
- Does not contribute new repository content unless the user separately asks (see `CONTRIBUTING.md`)

## Additional resources

- Domain index and lookup rules: [REPOSITORY_MAP.md](REPOSITORY_MAP.md)
- Plan, checklist, evidence, and finding templates: [OUTPUT_TEMPLATES.md](OUTPUT_TEMPLATES.md)
- Contribution guide: https://github.com/m14r41/PentestingEverything/blob/main/CONTRIBUTING.md