Pentest Checklist: A Pro's Guide to Systematic Security Testing

An effective pentest checklist is a structured framework that guides security researchers through the systematic identification, exploitation, and reporting of vulnerabilities within a target environment. By following a rigorous methodology, you ensure that no critical attack surface—from misconfigured S3 buckets to obscure logic flaws in an OAuth flow—is overlooked during an engagement. This guide provides a battle-tested roadmap used by senior testers to maintain consistency and depth in their technical assessments.

Pre-Engagement and Scoping Checklist

Before you send a single SYN packet, you need to define the boundaries. I’ve seen engagements go south because the "Rules of Engagement" (ROE) were vague. You don't want to accidentally take down a production database or scan an out-of-scope third-party API. Clear scoping protects both the consultant and the client.

• Legal Authorization: Ensure you have a signed SOW (Statement of Work) and written permission (the "Get Out of Jail Free" card).
• Scope Definition: Identify specific domains, IP ranges, CIDR blocks, and mobile app binaries.
• Exclusions: Explicitly list fragile systems, third-party SaaS providers (like Salesforce or AWS infrastructure), and specific time windows for aggressive testing.
• Testing Type: Define if the assessment is Black Box (zero knowledge), Gray Box (partial knowledge), or White Box (full access to docs/code).

Key Takeaway: Never start testing without a technical point of contact (POC) who can verify if a system goes offline. A checklist is useless if you're legally exposed.

Reconnaissance and Information Gathering

Recon is where 90% of bugs are found. If you find an asset the company forgot they owned, you’ve likely found an unpatched entry point. I start by mapping the external perimeter to understand the organization's footprint. This includes finding hidden subdomains and identifying the technologies running on every open port.

Passive Reconnaissance

• WHOIS & DNS: Query records to find associated IP blocks and name servers.
• Search Engine Discovery: Use Google Dorks (e.g., site:target.com filetype:pdf) to find leaked documents or sensitive paths.
• GitHub/GitLab Shodan: Search for leaked API keys, hardcoded credentials, or internal documentation in public repositories.
• Social Media OSINT: Check LinkedIn for employee tech stacks (e.g., an admin posting about migrating to Kubernetes suggests a specific attack surface).

Active Reconnaissance

• Subdomain Enumeration: Use tools like Amass, Subfinder, or Assetfinder to discover hidden hosts. For a deep dive into the best tools for this, check out our guide on subdomain enumeration tools.
• Port Scanning: Run Nmap with service version detection (-sV) and default scripts (-sC).
• Directory Brute-forcing: Use ffuf or Gobuster with high-quality wordlists (like SecLists) to find /admin, /.env, or /config.

# Example Nmap scan for a quick overview
nmap -sC -sV -p- -oN initial_scan.txt target.com

# Ffuf command for hidden directory discovery
ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -mc 200,301

Web Application Penetration Testing Checklist

Web apps are the most common entry point for modern breaches. When I test an application, I follow the OWASP Top 10 but also look for complex business logic flaws that automated scanners miss. You need to understand how the application handles state, identity, and data input.

Authentication and Session Management

• Brute Force Protection: Check for account lockout or rate-limiting on login forms.
• Password Policy: Test if weak passwords (e.g., Password123) are allowed.
• Session Fixation: Does the session ID change after login? It should.
• JWT Security: Check for weak signing keys, "none" algorithm vulnerabilities, or sensitive data in the payload.

Injection and Input Validation

• SQL Injection (SQLi): Test all parameters for error-based, boolean-based, or time-based SQLi.
• Cross-Site Scripting (XSS): Check for reflected, stored, and DOM-based XSS. Focus on bypasses for WAFs and CSPs.
• Server-Side Request Forgery (SSRF): Can you make the server fetch internal resources? This is huge in cloud environments for hitting metadata services (169.254.169.254).
• Command Injection: Test if user input is passed directly to system shells.

For a more detailed breakdown of these web-specific vulnerabilities, you should refer to our web application security testing guide which covers these vectors in much higher granularity.

Business Logic and Authorization

• IDOR (Insecure Direct Object Reference): Change /api/user/100 to /api/user/101. Can you see someone else's data?
• Privilege Escalation: Can a "User" role access "Admin" endpoints by simply changing a request parameter?
• Race Conditions: Test if multiple simultaneous requests can bypass limits (e.g., withdrawing money from an account twice).

Network and Infrastructure Assessment

Once you've moved past the web layer, you need to look at the underlying infrastructure. Network pentesting focuses on services like SMB, SSH, RDP, and database listeners. In internal environments, this often involves attacking Active Directory (AD) to gain Domain Admin privileges.

External Network Checks

• SSL/TLS Analysis: Use testssl.sh to find expired certificates or weak ciphers (RC4, DES).
• Unused Services: Identify services like Telnet, FTP, or rlogin that should be disabled.
• VPN & Gateway Security: Check for vulnerabilities in Citrix, Pulse Secure, or Fortinet gateways (often the first target for ransomware groups).

Internal Network and Active Directory

• LLMNR/NBT-NS Poisoning: Use Responder to capture hashes on the local network.
• Kerberoasting: Extract service account hashes from AD for offline cracking.
• AS-REP Roasting: Target users who don't require Kerberos pre-authentication.
• SMB Signing: Check if SMB signing is disabled, allowing for NTLM relay attacks.

Pro Tip: Use BloodHound to visualize attack paths in Active Directory. It often reveals that a low-level user has "GenericAll" rights over a group that contains a Domain Admin.

Exploitation and Post-Exploitation

Exploitation is the "sexy" part of pentesting, but it must be done carefully. Your goal isn't just to get a shell; it's to demonstrate the risk. Once you have access, you need to see how far an attacker could go. This often involves pivoting to other systems or escalating your privileges from a standard user to root or SYSTEM.

Gaining Access

• Public Exploits: Check SearchSploit or GitHub for known CVEs affecting the discovered service versions.
• Credential Stuffing: Use leaked credentials found during the recon phase.
• Reverse Shells: Once you have code execution, you'll need a way to maintain a connection. I always keep a reverse shell cheatsheet handy for different environments (Python, PHP, Bash, NC).

Privilege Escalation

• Linux: Check for SUID binaries, writable /etc/passwd, or outdated kernels.
• Windows: Look for unquoted service paths, AlwaysInstallElevated registry keys, or stored credentials in unattend.xml files. For a comprehensive list of Windows techniques, see our Windows privilege escalation cheatsheet.

Post-Exploitation Checklist

• Data Exfiltration Simulation: Can you move a 1GB dummy file out of the network without triggering an alert?
• Pivoting: Use tools like Chisel or Ligolo-ng to tunnel into internal subnets from your initial foothold.
• Persistence: (Only if in scope) Create a scheduled task or a new user to maintain access.
• Cleanup: Delete your tools, scripts, and temporary user accounts. Never leave a "pwned.txt" on a client's production server.

Reporting and Remediation Tracking

The report is the only tangible product the client receives. If you found a critical bug but can't explain it, you haven't provided value. A good report should be readable by both a CTO and a Lead Developer. I structure my reports to emphasize the "so what?" factor—what is the actual business risk?

Reporting Essentials

• Executive Summary: High-level overview of the security posture. Use charts and a "Security Score."
• Technical Findings: For every bug, include:
  • Description and Severity (CVSS score).
  • Affected Assets (URLs, IPs).
  • Step-by-step Proof of Concept (PoC).
  • Remediation advice (don't just say "patch it," provide the specific config change).
• Appendix: Include raw scan data and the full pentest checklist used during the engagement.

Frequently Asked Questions

What is the most important part of a pentest checklist?

The "Scoping" and "Rules of Engagement" phase is the most critical. Without a clearly defined scope and legal authorization, you risk legal consequences or causing unintended downtime in a production environment.

How often should I update my pentest checklist?

You should treat your checklist as a living document, updating it after every engagement. New vulnerabilities (like Log4Shell or MoveIT) and new bypass techniques emerge weekly, so your methodology must evolve to stay relevant.

Can I use automated tools for my entire checklist?

No, automated tools are excellent for catching "low-hanging fruit" like missing headers or old versions, but they fail at detecting complex business logic flaws, IDORs, and multi-step pivoting chains that a human tester can find.

What is the difference between a vulnerability assessment and a pentest?

A vulnerability assessment is a list of potential security holes found via scanning, whereas a pentest involves actively exploiting those holes to prove the real-world impact and see how deep an attacker can get into the network.

Final Thoughts on Systematic Testing

A pentest checklist isn't a replacement for creativity; it's a safety net. It ensures that while you're busy chasing a complex exploit chain, you don't forget to check if the /admin panel is protected by a default password. Consistency is what separates professional pentesters from hobbyists. By following a structured approach—from the first DNS query to the final report—you provide the most value to your clients and help build a more secure internet.

For more hands-on tutorials and deep dives into specific exploitation techniques, keep exploring the White Hats Nepal blog. Whether you are prepping for the OSCP or hunting on Bugcrowd, having a solid methodology is your greatest asset.