Penetration Testing Cheat Sheet

Quick note: This is intended for authorized, lawful security testing only. Always obtain written permission (scope, rules of engagement) and follow local laws and organizational policies. This document emphasizes methodology and common techniques — it intentionally avoids fully worked exploit scripts or unsafe step-by-step attack recipes.

At-a-glance checklist

• ☐ Scope & authorization confirmed (in writing)
• ☐ Reconnaissance (passive → active) complete
• ☐ Network/service discovery and port/service fingerprinting complete
• ☐ Enumeration of accounts, services, and content complete
• ☐ Vulnerability identification mapped to assets
• ☐ Exploitation (if in scope) — proof-of-concept only, no destructive actions
• ☐ Post-exploitation: persistence, lateral movement (in scope?)
• ☐ Privilege escalation checks (no destructive actions)
• ☐ Evidence collection (safe, for reporting)
• ☐ Cleanup & remediation recommendations delivered
• ☐ Final report + executive summary prepared

1. Preparation (Rules of engagement)

Goal: Define legal/technical boundaries so testing is safe and permitted.

Checklist:

• ☐ Written authorization (scope, dates, excluded systems, point(s) of contact).
• ☐ Scope inventory: IP ranges, domains, applications, cloud resources, user accounts.
• ☐ Time windows and emergency contacts.
• ☐ Testing classification: black / grey / white box.
• ☐ Data handling rules (sensitive data, exfiltration limits).
• ☐ Tools allowed/forbidden.
• ☐ Reporting format and timeline.

Why it matters: prevents legal exposure, avoids accidental disruptions.

2. Reconnaissance (Passive → Active)

Goal: Collect publicly available information and map attack surface.

Passive reconnaissance (low/no interaction):

• OSINT on domains, personnel, org structure.
• Search engines, public code repos, paste sites.
• Certificate transparency logs, DNS records (public).
• WHOIS, public S3 buckets, cloud metadata exposures (public).
• Subdomain enumeration (passive lists).

Active reconnaissance (interacts with target):

• DNS probing and zone transfers (if allowed).
• Passive vs active decision: prefer passive where required by scope.

Checklist (recon attacks & checks):

• ☐ Subdomain discovery — find subdomains; look for forgotten services.
• ☐ Public code & config leaks — search for credentials, API keys.
• ☐ Email harvesting — build target user list for social engineering (if in-scope).
• ☐ Certificate and CDN discovery — map hosts behind aliases.

Tools/notes: reconnaissance tools are many; choose according to scope and ethics. Record timestamps and sources.

Defensive note: public exposure of secrets and forgotten subdomains are common low-effort wins for defenders.

3. Discovery & Scanning

Goal: Identify live hosts, open ports, and running services.

Checklist (scanning attacks & checks):

• ☐ ICMP/ARP host discovery (internal networks).
• ☐ TCP/UDP port scanning (identify open ports).
• ☐ Service/version fingerprinting (identify software + versions).
• ☐ Banner grabbing and protocol analysis.
• ☐ Web crawling (identify endpoints, paths, sitemaps).
• ☐ SSL/TLS configuration analysis and weak cipher checks.

Common checks:

• Open RDP/SMB/SSH/SQL service exposure.
• Management interfaces on public IPs (databases, dashboards).
• Old/unsupported protocol versions.

Tools: port scanners and service probes — configure rate limits and timing per scope.

Defensive note: scanning noise can trigger IDS/IPS — coordinate with operations.

4. Enumeration

Goal: Extract detailed information needed to find and verify vulnerabilities.

Checklist (enumeration attacks & checks):

• ☐ User and group enumeration (SMB, LDAP, AD, application user lists).
• ☐ Share and file enumeration (SMB, NFS, S3 buckets).
• ☐ Web application parameter discovery (endpoints, parameters, upload points).
• ☐ Directory and file brute-force / discover (.git, .env, backup files) — prefer discovery via index/robots first.
• ☐ API endpoint mapping & parameter discovery (API docs, Swagger).
• ☐ Database presence and accessible DB dumps (read-only checks).
• ☐ Misconfigured services: anonymous FTP, open Redis/Mongo without auth.

Why: enumeration turns a list of ports/services into actionable attack paths.

Defensive note: restrict anonymous access, reduce disclosure of usernames in error messages.

5. Vulnerability Analysis (identification & verification)

Goal: Match assets and services to known vulnerabilities and configuration issues.

Checklist (vuln analysis techniques):

• ☐ CVE lookup for discovered versions and vendor advisories.
• ☐ Configuration checks (default creds, weak passwords, insecure permissions).
• ☐ Input validation checks (SQLi, XSS, command injection — non-exploitative verification).
• ☐ Auth and session handling weaknesses (insecure tokens, weak session expiry).
• ☐ Logic flaws and business logic vulnerabilities.
• ☐ Dependency and third-party component weaknesses.
• ☐ Rate limit and brute-force weakness checks (account lockout policies).

Tools/notes: vulnerability scanners are useful for triage but always validate findings manually to avoid false positives.

Defensive note: patch management and secure configuration reduce exposure.

6. Exploitation (only if in scope)

Goal: Validate vulnerabilities by demonstrating controlled access / proof-of-concept (PoC) without unnecessary harm.

Important constraints:

• Use PoCs that are non-destructive and reversible.
• Avoid data exfiltration of real sensitive content — use synthetic proof artifacts where required.
• Capture evidence (screenshots, hashes, logs) but avoid leaving persistent payloads.

Checklist (exploitation checks and safe PoC approaches):

• ☐ Authentication bypass attempts (password spray, credential stuffing) — respect lockout policies.
• ☐ Web OWASP Top 10 checks (SQLi, XSS, CSRF, file upload validation) — verify by benign payloads or proof strings.
• ☐ Exploit public-facing services with known, well-documented CVEs (PoC only, no destructive payloads).
• ☐ Check default or weak credentials on management interfaces.
• ☐ Test for insecure deserialization and unsafe file processing (use benign test cases).
• ☐ Validation of misconfigured cloud IAM roles / metadata access (non-exfiltrating checks).

High-level remediation advice: patch, rotate credentials, enforce MFA, implement WAF/filters.

Do not provide: destructive exploit code, weaponized payloads, or step-by-step exploit scripts.

7. Post-Exploitation (safe & scoped)

Goal: Demonstrate impact and map further attack paths — only within scope and with permission.

Checklist (post-exploitation focuses):

• ☐ Validate access level and show potential impact (screenshots, restricted data sampling with redaction).
• ☐ Identify credentials, tokens, or keys accessible from compromised host (do not exfiltrate).
• ☐ Lateral movement possibilities — map reachable hosts/services from compromised node (high-level mapping).
• ☐ Persistence mechanisms present? (documented, do not implant persistent backdoors).
• ☐ Data access patterns — what a real attacker could obtain? Provide examples, not raw data.

Defensive note: minimize operations that would alter system state; avoid creating new persistent accounts.

8. Privilege Escalation & Lateral Movement (assessment-only)

Goal: Evaluate paths an attacker might use to gain broader access.

Checklist (escalation & lateral checks):

• ☐ Local misconfigurations (SUID binaries, writable system files, weak sudoers entries).
• ☐ Credential reuse / plaintext credential storage.
• ☐ Scheduled tasks and scripts with insecure permissions.
• ☐ Unpatched kernel / service vulnerabilities (note versions; do not deploy exploits).
• ☐ Network trust relationships (unnecessary admin shares, service accounts with excessive privileges).

Remediation pointers: least privilege, secure credential storage, patching, file permission hygiene.

9. Cleanup & Evidence Handling

Goal: Leave the environment as found and provide clear, traceable evidence for the report.

Checklist:

• ☐ Remove any files, test accounts, or artifacts created.
• ☐ Provide evidence archived in a secure manner (screenshots, hashes, sanitized logs).
• ☐ Log actions with timestamps and context for reproducibility in the report.
• ☐ Communicate immediately if an accidental outage occurred.

Best practice: include remediation steps alongside each finding and severity rating.

10. Reporting (technical + executive)

Goal: Deliver usable, prioritized findings and remediation guidance.

Report sections:

• Executive summary (impact, high-level findings, business risk).
• Scope & methodology (what was tested, when, allowed activities).
• Findings (each with: title, evidence, risk rating, remediation steps, reproduction steps if safe).
• Remediation roadmap & quick wins.
• Appendices: logs, tool outputs (sanitized), CVE references.

Prioritize: give a short remediation checklist that ops can act on immediately (change creds, apply patch, firewall rule, disable public management interface).

Appendix — Common attacks / checks by phase

For authorized testing only — always obtain written permission before testing.

Tool categories (examples)

• Recon: passive OSINT tooling, crt.sh, amass (passive mode).
• Scanning: nmap (careful with timing), masscan (internal scans with permission).
• Web: Burp Suite / OWASP ZAP (interception & analysis), crawler.
• Enumeration: enum4linux, ldapsearch, smbclient, aws-cli (read-only checks).
• Vulnerability triage: Nessus, OpenVAS (triage only — validate manually).
• Reporting: Dradis, Serpico, custom templates.

(Pick tools per engagement and obey ROE about active vs passive)

Risk rating quick guide

• Critical: remote code execution on internet-facing services or exposed credentials allowing broad access.
• High: exposed sensitive data, privilege escalation paths, broken auth.
• Medium: outdated components with known fixes, info leakage.
• Low: discovery of non-sensitive files, single-user minor misconfigs.

Use CVSS for technical severity mapping, but map to business impact for executives.

Ethics & legal reminder

• Get written authorization before testing.
• Respect data privacy: do not exfiltrate or expose real private data in reports. Redact as needed.
• If you accidentally access production data or cause outages — notify the client immediately.
• Never sell or publish exploit code or private data from an engagement.

Quick reproducible examples (safe, illustrative)

Example: simple, non-destructive service version check (conceptual)

# Conceptual example only — adapt to your environment and scope
nmap -sV --version-all --top-ports 1000 10.0.0.0/24

Use results to search vendor advisories and CVEs for the identified version numbers.

Closing notes

This cheat sheet is a compact methodology + checklist. For each finding, include evidence, suggested remediation, and a timeline for patching. Keep communication clear with stakeholders — a prioritized remediation roadmap is the most valuable outcome of any pentest.

Related Cybersecurity Guides and Tutorials:

All-Ports Scanning with Nmap — TCP, UDP & Quieter Tactics

Understanding DHCP in Cybersecurity

Direct Drive Reads: A Double-Edged Technique in Cybersecurity

Windows Sticky Keys in Hands of Hackers