penetration-testing

When this skill is activated, always start your first response with the 🧢 emoji.

Penetration Testing

A structured framework for conducting authorized security assessments. This skill covers the full pentest lifecycle - from scoping and reconnaissance through exploitation and reporting - with an uncompromising emphasis on authorized testing only. Every technique, tool, and tactic here is applied exclusively within written engagement agreements, sanctioned CTF competitions, or controlled lab environments.

Security testing without explicit written authorization is illegal under the Computer Fraud and Abuse Act (CFAA), the Computer Misuse Act (UK), and equivalent laws in virtually every jurisdiction. There are no exceptions.

When to use this skill

Trigger this skill when the user:

1. Plans or scopes an authorized penetration test engagement
2. Conducts a web application security assessment following the OWASP Testing Guide
3. Performs network vulnerability scanning (Nmap, Nessus, OpenVAS)
4. Tests authentication, session management, or access control weaknesses
5. Writes a professional pentest report with findings and remediation guidance
6. Prioritizes vulnerabilities using CVSS scoring or risk-based frameworks
7. Practices in a CTF competition, HackTheBox, TryHackMe, or personal lab environment

Do NOT trigger this skill for:

• Any activity targeting systems the user does not have explicit written authorization

to test - this is unauthorized access, not security testing

• Attacks on production systems outside a defined and agreed engagement scope,

regardless of intent or claimed ownership

Key principles

1. Always have written authorization - A signed statement of work, rules of

engagement document, or CTF registration is non-negotiable before any testing begins. Verbal permission is legally meaningless. If you do not have written authorization, you do not have authorization.

1. Follow scope strictly - The engagement scope defines exactly which IP ranges,

domains, applications, and test types are in bounds. Scope creep - even "accidental" pivoting to out-of-scope systems - carries legal liability. When in doubt, stop and clarify with the client.

1. Document everything - Log every command run, every finding discovered, and every

timestamp. Detailed records protect the tester legally, enable accurate reporting, and provide the client with a reproducible audit trail.

1. Responsible disclosure - Critical findings (RCE, credential exposure, data

exfiltration paths) must be reported to the client immediately, not at the end of the engagement. Do not hold back critical vulnerabilities to make the final report look more impressive.

1. Minimize impact - Testing should never cause unnecessary disruption. Avoid

destructive exploits, denial-of-service techniques, or mass data extraction unless explicitly authorized. The goal is to demonstrate a vulnerability exists, not to fully exploit it.

Core concepts

Pentest phases

The Penetration Testing Execution Standard (PTES) defines five phases that form a repeatable methodology for every engagement:

| Phase | Goal | Key activities | |---|---|---| | Reconnaissance | Understand the target's attack surface | Passive OSINT (WHOIS, Shodan, Google dorks), active scanning, subdomain enumeration | | Scanning & Enumeration | Map live hosts, open ports, services, and versions | Nmap, Nessus, Nikto, banner grabbing, service fingerprinting | | Exploitation | Demonstrate that a vulnerability can be leveraged | Metasploit, manual exploit development, web app attacks (SQLi, XSS, SSRF) | | Post-Exploitation | Assess impact depth after initial compromise | Privilege escalation, lateral movement, credential harvesting, persistence (within scope) | | Reporting | Communicate risk to the client in actionable terms | Executive summary, technical findings, CVSS scores, remediation steps |

Vulnerability severity - CVSS

The Common Vulnerability Scoring System (CVSS v3.1) provides a standardized numerical score (0.0-10.0) used to communicate severity:

| Score | Severity | Typical examples | |---|---|---| | 9.0-10.0 | Critical | Unauthenticated RCE, pre-auth SQL injection with DBA access | | 7.0-8.9 | High | Authenticated RCE, significant privilege escalation, SSRF to metadata | | 4.0-6.9 | Medium | Stored XSS, IDOR exposing other users' data, weak TLS config | | 0.1-3.9 | Low | Informational disclosure, missing security headers, verbose errors | | 0.0 | Informational | Best-practice gaps with no direct exploitability |

CVSS scores are a communication tool, not the final word on business risk. A medium-severity finding in a payment card system may carry higher business risk than a high-severity finding on a low-value internal tool. Always contextualize scores for the client.

Rules of engagement

Rules of engagement (ROE) define the guardrails for a test. A well-formed ROE document covers:

• Scope: IP ranges, domains, applications in-scope and out-of-scope
• Test types: Allowed techniques (e.g., is social engineering in scope? DoS testing?)
• Time windows: Permitted testing hours (avoid peak business hours for network tests)
• Emergency contacts: Who to call if testing causes unintended disruption
• Data handling: How captured credentials and PII must be stored and destroyed
• Exclusions: Specific systems, third-party services, or shared infrastructure that

must not be touched

Common tasks

Plan a pentest engagement

Before any technical work begins, define:

1. Scope document - list every IP range, CIDR block, domain, and application

explicitly authorized for testing. Write a separate exclusion list.

1. Rules of engagement - cover testing windows, allowed techniques, emergency

contacts, and data handling requirements (see ROE section above).

1. Timeline - reconnaissance phase, active testing phase, reporting phase, and

remediation validation window.

1. Test type - black-box (no prior knowledge), grey-box (limited knowledge like

a standard user account), or white-box (full source code and architecture access).

Always get ROE signed before the first Nmap packet leaves your machine.

Conduct a web application assessment

Follow the OWASP Testing Guide (OTG) v4 methodology:

1. Information Gathering
   - OTG-INFO-001: Fingerprint web server and technology stack
   - OTG-INFO-003: Review webserver metafiles (robots.txt, sitemap.xml)
   - OTG-INFO-007: Map application entry points

2. Authentication Testing
   - OTG-AUTHN-001: Test credentials over encrypted transport
   - OTG-AUTHN-003: Test account lockout and brute-force protections
   - OTG-AUTHN-006: Test for default credentials

3. Authorization Testing
   - OTG-AUTHZ-001: Directory traversal / file inclusion
   - OTG-AUTHZ-002: Bypass authorization schema (IDOR, privilege escalation)

4. Session Management Testing
   - OTG-SESS-001: Test cookie attributes (Secure, HttpOnly, SameSite)
   - OTG-SESS-005: Test for CSRF

5. Input Validation Testing
   - OTG-INPVAL-001: Reflected/stored/DOM XSS
   - OTG-INPVAL-005: SQL injection
   - OTG-INPVAL-017: SSRF

6. Business Logic Testing
   - OTG-BUSLOGIC-004: Test for process timing attacks
   - OTG-BUSLOGIC-009: Test for upload of malicious files

Tools: Burp Suite (proxy and scanner), OWASP ZAP, SQLMap (authorized use only), ffuf (directory brute-forcing), Nikto (initial reconnaissance).

Perform a network vulnerability scan

A repeatable Nmap scanning workflow for authorized network assessments:

# Phase 1: Host discovery (fast, low noise)
nmap -sn 10.0.0.0/24 -oG hosts-up.txt

# Phase 2: Service version scan on live hosts
nmap -sV -sC -p- --open -iL hosts-up.txt -oA nmap-full

# Phase 3: Targeted UDP scan for key services
nmap -sU -p 53,67,161,500 -iL hosts-up.txt -oA nmap-udp

# Phase 4: Vulnerability scripts (