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