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:

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 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
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. 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:

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
• Plan, checklist, evidence, and finding templates: OUTPUT_TEMPLATES.md
• Contribution guide: https://github.com/m14r41/PentestingEverything/blob/main/CONTRIBUTING.md