pentest-checklist skill

---
name: Pentest Checklist
description: This skill should be used when the user asks to "plan a penetration test", "create a security assessment checklist", "prepare for penetration testing", "define pentest scope", "follow security testing best practices", or needs a structured methodology for penetration testing engagements.
---

# Pentest Checklist

## Purpose

Provide a comprehensive checklist for planning, executing, and following up on penetration tests. Ensure thorough preparation, proper scoping, and effective remediation of discovered vulnerabilities.

## Inputs/Prerequisites

- Clear business objectives for testing
- Target environment information
- Budget and timeline constraints
- Stakeholder contacts and authorization
- Legal agreements and scope documents

## Outputs/Deliverables

- Defined pentest scope and objectives
- Prepared testing environment
- Security monitoring data
- Vulnerability findings report
- Remediation plan and verification

## Core Workflow

### Phase 1: Scope Definition

#### Define Objectives

- [ ] **Clarify testing purpose** - Determine goals (find vulnerabilities, compliance, customer assurance)
- [ ] **Validate pentest necessity** - Ensure penetration test is the right solution
- [ ] **Align outcomes with objectives** - Define success criteria

**Reference Questions:**
- Why are you doing this pentest?
- What specific outcomes do you expect?
- What will you do with the findings?

#### Know Your Test Types

| Type | Purpose | Scope |
|------|---------|-------|
| External Pentest | Assess external attack surface | Public-facing systems |
| Internal Pentest | Assess insider threat risk | Internal network |
| Web Application | Find application vulnerabilities | Specific applications |
| Social Engineering | Test human security | Employees, processes |
| Red Team | Full adversary simulation | Entire organization |

#### Enumerate Likely Threats

- [ ] **Identify high-risk areas** - Where could damage occur?
- [ ] **Assess data sensitivity** - What data could be compromised?
- [ ] **Review legacy systems** - Old systems often have vulnerabilities
- [ ] **Map critical assets** - Prioritize testing targets

#### Define Scope

- [ ] **List in-scope systems** - IPs, domains, applications
- [ ] **Define out-of-scope items** - Systems to avoid
- [ ] **Set testing boundaries** - What techniques are allowed?
- [ ] **Document exclusions** - Third-party systems, production data

#### Budget Planning

| Factor | Consideration |
|--------|---------------|
| Asset Value | Higher value = higher investment |
| Complexity | More systems = more time |
| Depth Required | Thorough testing costs more |
| Reputation Value | Brand-name firms cost more |

**Budget Reality Check:**
- Cheap pentests often produce poor results
- Align budget with asset criticality
- Consider ongoing vs. one-time testing

### Phase 2: Environment Preparation

#### Prepare Test Environment

- [ ] **Production vs. staging decision** - Determine where to test
- [ ] **Set testing limits** - No DoS on production
- [ ] **Schedule testing window** - Minimize business impact
- [ ] **Create test accounts** - Provide appropriate access levels

**Environment Options:**
```
Production  - Realistic but risky
Staging     - Safer but may differ from production
Clone       - Ideal but resource-intensive
```

#### Run Preliminary Scans

- [ ] **Execute vulnerability scanners** - Find known issues first
- [ ] **Fix obvious vulnerabilities** - Don't waste pentest time
- [ ] **Document existing issues** - Share with testers

**Common Pre-Scan Tools:**
```bash
# Network vulnerability scan
nmap -sV --script vuln TARGET

# Web vulnerability scan
nikto -h http://TARGET
```

#### Review Security Policy

- [ ] **Verify compliance requirements** - GDPR, PCI-DSS, HIPAA
- [ ] **Document data handling rules** - Sensitive data procedures
- [ ] **Confirm legal authorization** - Get written permission

#### Notify Hosting Provider

- [ ] **Check provider policies** - What testing is allowed?
- [ ] **Submit authorization requests** - AWS, Azure, GCP requirements
- [ ] **Document approvals** - Keep records

**Cloud Provider Policies:**
- AWS: https://aws.amazon.com/security/penetration-testing/
- Azure: https://docs.microsoft.com/security/pentest
- GCP: https://cloud.google.com/security/overview

#### Freeze Developments

- [ ] **Stop deployments during testing** - Maintain consistent environment
- [ ] **Document current versions** - Record system states
- [ ] **Avoid critical patches** - Unless security emergency

### Phase 3: Expertise Selection

#### Find Qualified Pentesters

- [ ] **Seek recommendations** - Ask trusted sources
- [ ] **Verify credentials** - OSCP, GPEN, CEH, CREST
- [ ] **Check references** - Talk to previous clients
- [ ] **Match expertise to scope** - Web, network, mobile specialists

**Evaluation Criteria:**

| Factor | Questions to Ask |
|--------|------------------|
| Experience | Years in field, similar projects |
| Methodology | OWASP, PTES, custom approach |
| Reporting | Sample reports, detail level |
| Communication | Availability, update frequency |

#### Define Methodology

- [ ] **Select testing standard** - PTES, OWASP, NIST
- [ ] **Determine access level** - Black box, gray box, white box
- [ ] **Agree on techniques** - Manual vs. automated testing
- [ ] **Set communication schedule** - Updates and escalation

**Testing Approaches:**

| Type | Access Level | Simulates |
|------|-------------|-----------|
| Black Box | No information | External attacker |
| Gray Box | Partial access | Insider with limited access |
| White Box | Full access | Insider/detailed audit |

#### Define Report Format

- [ ] **Review sample reports** - Ensure quality meets needs
- [ ] **Specify required sections** - Executive summary, technical details
- [ ] **Request machine-readable output** - CSV, XML for tracking
- [ ] **Agree on risk ratings** - CVSS, custom scale

**Report Should Include:**
- Executive summary for management
- Technical findings with evidence
- Risk ratings and prioritization
- Remediation recommendations
- Retesting guidance

### Phase 4: Monitoring

#### Implement Security Monitoring

- [ ] **Deploy IDS/IPS** - Intrusion detection systems
- [ ] **Enable logging** - Comprehensive audit trails
- [ ] **Configure SIEM** - Centralized log analysis
- [ ] **Set up alerting** - Real-time notifications

**Monitoring Tools:**
```bash
# Check security logs
tail -f /var/log/auth.log
tail -f /var/log/apache2/access.log

# Monitor network
tcpdump -i eth0 -w capture.pcap
```

#### Configure Logging

- [ ] **Centralize logs** - Aggregate from all systems
- [ ] **Set retention periods** - Keep logs for analysis
- [ ] **Enable detailed logging** - Application and system level
- [ ] **Test log collection** - Verify all sources working

**Key Logs to Monitor:**
- Authentication events
- Application errors
- Network connections
- File access
- System changes

#### Monitor Exception Tools

- [ ] **Track error rates** - Unusual spikes indicate testing
- [ ] **Brief operations team** - Distinguish testing from attacks
- [ ] **Document baseline** - Normal vs. pentest activity

#### Watch Security Tools

- [ ] **Review IDS alerts** - Separate pentest from real attacks
- [ ] **Monitor WAF logs** - Track blocked attempts
- [ ] **Check endpoint protection** - Antivirus detections

### Phase 5: Remediation

#### Ensure Backups

- [ ] **Verify backup integrity** - Test restoration
- [ ] **Document recovery procedures** - Know how to restore
- [ ] **Separate backup access** - Protect from testing

#### Reserve Remediation Time

- [ ] **Allocate team availability** - Post-pentest analysis
- [ ] **Schedule fix implementation** - Address findings
- [ ] **Plan verification testing** - Confirm fixes work

#### Patch During Testing Policy

- [ ] **Generally avoid patching** - Maintain consistent environment
- [ ] **Exception for critical issues** - Security emergencies only
- [ ] **Communicate changes** - Inform pentesters of any changes

#### Cleanup Procedure

- [ ] **Remove test artifacts** - Backdoors, scripts, files
- [ ] **Delete test accounts** - Remove pentester access
- [ ] **Restore configurations** - Return to original state
- [ ] **Verify cleanup complete** - Audit all changes

#### Schedule Next Pentest

- [ ] **Determine frequency** - Annual, quarterly, after changes
- [ ] **Consider continuous testing** - Bug bounty, ongoing assessments
- [ ] **Budget for future tests** - Plan ahead

**Testing Frequency Factors:**
- Release frequency
- Regulatory requirements
- Risk tolerance
- Past findings severity

## Quick Reference

### Pre-Pentest Checklist

```
□ Scope defined and documented
□ Authorization obtained
□ Environment prepared
□ Hosting provider notified
□ Team briefed
□ Monitoring enabled
□ Backups verified
```

### Post-Pentest Checklist

```
□ Report received and reviewed
□ Findings prioritized
□ Remediation assigned
□ Fixes implemented
□ Verification testing scheduled
□ Environment cleaned up
□ Next test scheduled
```

## Constraints

- Production testing carries inherent risks
- Budget limitations affect thoroughness
- Time constraints may limit coverage
- Tester expertise varies significantly
- Findings become stale quickly

## Examples

### Example 1: Quick Scope Definition

```markdown
**Target:** Corporate web application (app.company.com)
**Type:** Gray box web application pentest
**Duration:** 5 business days
**Excluded:** DoS testing, production database access
**Access:** Standard user account provided
```

### Example 2: Monitoring Setup

```bash
# Enable comprehensive logging
sudo systemctl restart rsyslog
sudo systemctl restart auditd

# Start packet capture
tcpdump -i eth0 -w /tmp/pentest_capture.pcap &
```

## Troubleshooting

| Issue | Solution |
|-------|----------|
| Scope creep | Document and require change approval |
| Testing impacts production | Schedule off-hours, use staging |
| Findings disputed | Provide detailed evidence, retest |
| Remediation delayed | Prioritize by risk, set deadlines |
| Budget exceeded | Define clear scope, fixed-price contracts |