Use this skill when conducting authorized penetration tests, vulnerability assessments, or security audits within proper engagement scope. Triggers on pentest methodology, vulnerability scanning, OWASP testing guide, Burp Suite, reconnaissance, exploitation, reporting, and any task requiring structured security assessment within authorized engagements or CTF competitions.
Use this skill when conducting authorized penetration tests, vulnerability assessments, or security audits within proper engagement scope. Triggers on pentest methodology, vulnerability scanning, OWASP testing guide, Burp Suite, reconnaissance, exploitation, reporting, and any task requiring structured security assessment within authorized engagements or CTF competitions.
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:
Plans or scopes an authorized penetration test engagement
Conducts a web application security assessment following the OWASP Testing Guide
Tests authentication, session management, or access control weaknesses
Writes a professional pentest report with findings and remediation guidance
Prioritizes vulnerabilities using CVSS scoring or risk-based frameworks
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
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.
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.
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.
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.
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)
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:
Scope document - list every IP range, CIDR block, domain, and application
explicitly authorized for testing. Write a separate exclusion list.
Rules of engagement - cover testing windows, allowed techniques, emergency
contacts, and data handling requirements (see ROE section above).
Timeline - reconnaissance phase, active testing phase, reporting phase, and
remediation validation window.
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:
Attacker OS: Kali Linux or Parrot OS (come pre-loaded with pentest tooling)
Network isolation: Never bridge your lab network to a production or corporate
network
Snapshots: Snapshot VM state before each exploitation attempt for easy revert
Practice only on systems you own or platforms that grant explicit authorization
(HTB, THM, VulnHub). Setting up a lab is the correct path when you want to
develop skills without an engagement in hand.
Anti-patterns
Anti-pattern
Why it's wrong
What to do instead
Testing without written authorization
Illegal under CFAA and equivalent laws worldwide, regardless of intent or claimed ownership
Obtain signed statement of work and ROE before any testing begins
Scope creep during exploitation
Pivoting to out-of-scope systems creates legal exposure even if discovered accidentally
Stop immediately, document the out-of-scope system found, notify the client, get written scope extension if needed
Running destructive exploits without explicit authorization
Can cause data loss, service outages, or permanent system damage
Demonstrate exploitability with a PoC that proves the vulnerability without causing harm (e.g., id vs full shell)
Saving client credentials or PII beyond the engagement
Creates data liability and breaches engagement agreement
Destroy captured credentials per the data-handling terms in the ROE; never store them after the engagement closes
Reporting only exploited vulnerabilities
Misses the full attack surface - un-exploited vulnerabilities still carry risk
Report all findings including those that could not be exploited in the test window, with CVSS-based risk scores
Vague remediation advice ("fix the SQL injection")
Developers cannot act on generic advice
Provide specific remediation - parameterized query example, library recommendation, configuration change - for every finding
Gotchas
Scope creep via pivoting to discovered out-of-scope systems is a legal exposure - During exploitation or enumeration, you will discover systems adjacent to your scope. Even if pivoting there would demonstrate greater impact, touching them is unauthorized access regardless of intent. When you discover an out-of-scope system that is critical (e.g., a connected production DB), stop, document, and notify the client immediately - do not test it.
Nmap aggressive scans (-A) without rate limiting will trigger IDS and disrupt fragile services - The default aggressive scan sends thousands of packets per second and will trigger intrusion detection, fill firewall logs, and crash UDP-sensitive services on older hardware. Always set --max-rate 100-500 for initial scans in production environments and increase only after confirming stability.
Storing captured credentials or PII beyond engagement close is a data liability - Pentest tooling (Responder, Metasploit loot, Burp history) accumulates real credentials, session tokens, and PII. Many testers forget to purge this data after the engagement. The ROE data-handling clause applies: destroy all captured data per the agreed method on the day the engagement closes.
CVSS base scores do not account for business context - A CVSS 9.8 on an internal dev tool with no external access is genuinely lower risk than a CVSS 6.5 IDOR on a payment API. Presenting raw CVSS scores to clients without contextualizing for their environment creates misplaced remediation priorities. Always add a business risk statement to each finding that reflects the actual environment.
Password spraying without lockout testing first triggers account lockouts at scale - Testing a list of 500 accounts with one password attempt each can lock out a significant fraction of users if the lockout threshold is low (e.g., 3 attempts in 30 minutes from any source). Always test the lockout policy on a single test account before running any spray, and confirm spray scope with the client.
References
For detailed methodology and patterns, load the relevant references file:
references/methodology.md - PTES and OWASP Testing Guide methodology,
phase-by-phase breakdown, tool reference, and reporting templates
Only load references files when the current task requires them - they are long and
will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
