Skip to content
Back to skills

Pentest Methodology

BSecurity

Reference for PTES phases, the OWASP Testing Guide, and testing patterns by technology and vulnerability class, starting from pre-engagement authorization and rules of engagement. Use when planning or running an authorized penetration test and structuring its report.

  • 4 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 1, 2026
securityrustgoshellsqlawstestinggitapisecuritydocumentation

Works with

  • cli
  • api

Security analysis

B75/100
  • criticalAccesses sensitive system or user directories

Pro shows the line behind each finding and how to fix it

Scanned October 1, 2026

npx -y skills add HermeticOrmus/LibreSecOps-Claude-Code --skill pentest-methodology --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pentest Methodology?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pentest Methodology
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/hermeticormus-pentest-methodology/badge)](https://www.skillsdirectory.com/skills/hermeticormus-pentest-methodology)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: "pentest-methodology"
description: "Reference for PTES phases, the OWASP Testing Guide, and testing patterns by technology and vulnerability class, starting from pre-engagement authorization and rules of engagement. Use when planning or running an authorized penetration test and structuring its report."
---

# Penetration Testing Methodology

> Deep reference for PTES phases, OWASP Testing Guide structure, and practical testing patterns organized by technology and vulnerability class.

## Knowledge Base

### PTES (Penetration Testing Execution Standard)

The Penetration Testing Execution Standard defines seven phases of a penetration test:

**Phase 1: Pre-engagement Interactions**
- Scope definition: IP ranges, domains, applications, exclusions
- Rules of engagement: testing hours, communication channels, escalation procedures
- Authorization documentation: signed statement of work, get-out-of-jail letter
- Emergency contacts: who to call if testing causes issues
- Legal considerations: Computer Fraud and Abuse Act compliance, data protection regulations

**Phase 2: Intelligence Gathering**

Passive reconnaissance (no direct interaction with target):
- DNS records: A, AAAA, MX, TXT, CNAME, NS, SOA, SRV (dig, host, nslookup)
- WHOIS data: registration details, nameservers, registrar
- Search engine dorking: `site:target.com filetype:pdf`, `inurl:admin`, `intitle:"index of"`
- Certificate transparency logs: crt.sh, Censys for subdomain enumeration
- Public code repositories: GitHub, GitLab for exposed credentials, configuration, internal URLs
- Job postings: technology stack identification
- Social media: employee enumeration, technology hints
- Shodan/Censys: exposed services, banners, certificates

Active reconnaissance (direct interaction, within scope):
- Port scanning: Nmap SYN scan, version detection, OS fingerprinting, script scanning
- Service enumeration: Banner grabbing, protocol-specific probing
- Web application fingerprinting: Wappalyzer patterns, response headers, error pages, default files
- Directory and file discovery: ffuf, gobuster, feroxbuster with targeted wordlists
- Virtual host enumeration: Host header fuzzing for additional applications on shared infrastructure

**Phase 3: Threat Modeling**
- Identify valuable assets within scope
- Map trust boundaries and privilege levels
- Identify likely attack vectors based on reconnaissance
- Prioritize testing effort by risk and likelihood
- Cross-reference with STRIDE or PASTA methodologies

**Phase 4: Vulnerability Analysis**

Automated scanning:
- Web application: Burp Suite Scanner, OWASP ZAP, Nikto, Nuclei
- Network: Nessus, OpenVAS, Qualys
- Infrastructure: ScoutSuite (cloud), Trivy (containers), Semgrep (code)

Manual testing:
- Authentication: Brute force protection, credential policies, session management, MFA bypass
- Authorization: IDOR, privilege escalation, function-level access control
- Input validation: SQL injection, XSS, command injection, SSTI, file inclusion
- Business logic: Workflow bypass, price manipulation, race conditions
- Cryptography: Weak algorithms, key exposure, improper implementation

**Phase 5: Exploitation**

Confirming vulnerabilities are exploitable:
- Develop proof of concept (minimal, safe, documented)
- Demonstrate impact without causing damage
- Chain vulnerabilities for maximum demonstrated impact
- Document exact reproduction steps
- Capture evidence (screenshots, request/response, timestamps)

**Phase 6: Post-Exploitation**

Understanding the full impact of successful exploitation:
- Privilege escalation: Local to root/SYSTEM, user to admin
- Lateral movement: Pivoting to other systems, credential reuse, pass-the-hash
- Data access: What sensitive data is reachable from the compromised position
- Persistence analysis: Could an attacker maintain access? (Not establishing persistence, but assessing the risk)
- Business impact assessment: What would a real attacker achieve from this position?

**Phase 7: Reporting**

Structured report with multiple audiences:
- Executive summary: Business risk in non-technical language (1-2 pages)
- Technical findings: Detailed vulnerability descriptions with evidence
- Risk-rated remediation roadmap: Prioritized by severity and effort
- Methodology section: What was tested and how (for compliance)

### OWASP Testing Guide v4.2 Structure

The OWASP Testing Guide organizes 286 test cases into 12 categories:

| Category | ID Range | Focus |
|----------|----------|-------|
| Information Gathering | OTG-INFO | Technology identification, application mapping |
| Configuration Management | OTG-CONFIG | Infrastructure and platform configuration |
| Identity Management | OTG-IDENT | User registration, account provisioning |
| Authentication | OTG-AUTHN | Login, password management, MFA |
| Authorization | OTG-AUTHZ | Access control, privilege escalation |
| Session Management | OTG-SESS | Session tokens, cookies, timeouts |
| Input Validation | OTG-INPVAL | Injection, XSS, file upload, HTTP smuggling |
| Error Handling | OTG-ERR | Error codes, stack traces, information leakage |
| Cryptography | OTG-CRYPST | TLS, encryption, hashing |
| Business Logic | OTG-BUSLOGIC | Workflow bypass, data validation, timing |
| Client-Side | OTG-CLIENT | DOM XSS, clickjacking, WebSocket, postMessage |
| API Testing | OTG-API | REST, GraphQL, SOAP specific tests |

### Testing by Technology Stack

**Linux Server Testing**:
- Service enumeration: SSH, HTTP, HTTPS, SMTP, DNS, FTP, SMB, NFS
- SSH: Key-based auth enforcement, protocol version, allowed ciphers
- Web server: Apache/Nginx configuration, directory traversal, server-status exposure
- Privilege escalation: SUID binaries, sudo misconfiguration, kernel exploits, cron jobs, writable paths, capabilities
- Tools: LinPEAS, linux-exploit-suggester, pspy

**Windows/Active Directory Testing**:
- Domain enumeration: BloodHound, PowerView, ADRecon
- Credential attacks: AS-REP Roasting, Kerberoasting, NTLM relay, pass-the-hash
- Privilege escalation: Token impersonation, service misconfigurations, unquoted service paths, AlwaysInstallElevated
- Lateral movement: PsExec, WMI, WinRM, DCOM, RDP
- Tools: Impacket, CrackMapExec, Rubeus, Mimikatz, SharpHound

**Web Application Testing**:
- Framework identification and version-specific CVEs
- Authentication flow analysis (see api-security-testing plugin)
- Input injection across all OWASP categories (see web-application-security plugin)
- Business logic testing: multi-step process bypass, race conditions, numerical limits
- File upload: extension bypass, content-type manipulation, polyglot files, web shell upload paths
- Tools: Burp Suite, sqlmap, ffuf, Nuclei, Semgrep

**Cloud Infrastructure Testing**:
- IAM: Over-privileged roles, assume-role chains, cross-account access
- Storage: Public buckets/blobs, misconfigured access policies
- Compute: Metadata service access (169.254.169.254), instance profile credentials
- Network: Security group rules, VPC peering, public endpoints
- Tools: Prowler, ScoutSuite, Pacu, CloudMapper

## Patterns

### Effective Reconnaissance Pattern
1. Start with passive: DNS, certificates, OSINT
2. Map the external perimeter: ports, services, versions
3. Enumerate web content: directories, files, parameters
4. Identify the technology stack precisely (framework + version)
5. Search for known CVEs in identified components
6. Build a prioritized target list before any exploitation attempt

### Vulnerability Validation Pattern
1. Identify the potential vulnerability from scanning or manual testing
2. Understand the root cause (what the code does wrong)
3. Develop a minimal proof of concept that demonstrates the issue safely
4. Determine the maximum impact if fully exploited
5. Identify attack chains (what else becomes possible from this vulnerability)
6. Rate using CVSS with environmental context

### Report Writing Pattern
1. Lead with business impact, not technical details
2. One finding per vulnerability (don't combine unrelated issues)
3. Include exact reproduction steps (another tester should replicate your work)
4. Provide evidence: request/response pairs, screenshots, tool output
5. Remediation should be specific and actionable (not "fix the vulnerability")
6. Include compensating controls when the root fix requires significant time

## Anti-Patterns

- **Testing without authorization**: Legal consequences, ethical violations, career destruction. Always have written permission.
- **Scope creep**: Finding something interesting out of scope and testing it. Document and report through proper channels.
- **Automated scanning only**: Scanners find the easy stuff. Business logic flaws, authentication bypasses, and attack chains require manual testing.
- **Exploiting beyond proof of concept**: Demonstrating RCE by reading `/etc/passwd` is sufficient. Don't deploy shells, exfiltrate real data, or establish persistence unless explicitly authorized and required.
- **Copy-paste reports**: Scanner output pasted into a report template without validation. False positives destroy credibility. Verify every finding.
- **Missing the forest for the trees**: Reporting 50 low-severity findings while missing the one critical attack chain that actually compromises the system.
- **Neglecting the report**: Spending 80% of time testing and 20% on reporting. The report IS the deliverable. Budget adequate time.

## References

- [PTES - Penetration Testing Execution Standard](http://www.pentest-standard.org/)
- [OWASP Testing Guide v4.2](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP Mobile Application Security Testing Guide](https://mas.owasp.org/)
- [NIST SP 800-115 - Technical Guide to Information Security Testing](https://csrc.nist.gov/publications/detail/sp/800-115/final)
- [MITRE ATT&CK Framework](https://attack.mitre.org/)
- [HackTricks - Pentesting methodology](https://book.hacktricks.xyz/)
- [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…