Penetration Testing
Scoped, time-boxed assessments that find and demonstrate exploitable weaknesses against a defined target.
Status: seed Related: Red Teaming, Reconnaissance, Initial Access, Privilege Escalation, Burp Suite, nmap
What it is
A penetration test is a goal-oriented security assessment performed against a defined scope (a network range, a web application, a binary, a cloud account) under explicit authorization. The deliverable is a report: what was found, how it was exploited, what the impact is, what to fix.
It is not the same as red teaming. Pentests are usually announced, broad in coverage, and graded on completeness. Red teams are stealthy, narrow in objective, and graded on whether they achieve them. See Red Teaming for the contrast.
Engagement types
| Type | Target | Typical artifacts |
|---|---|---|
| External network | Internet-facing infrastructure | Service inventory, exposed admin panels, exploitable services |
| Internal network | LAN / AD environment | Lateral movement paths, privilege escalation, domain compromise |
| Web application | A specific app / API | OWASP-class bugs, business-logic flaws, auth bypasses |
| Mobile | iOS / Android app | Insecure storage, transport, IPC, hardcoded secrets |
| Cloud | AWS / Azure / GCP account | IAM misconfig, exposed buckets, lateral cross-account |
| Wireless | WiFi, BLE | Rogue APs, weak crypto, client attacks |
| Physical | Buildings, hardware | Tailgating, badge cloning, port access |
Methodology
Most pentest methodologies map roughly to:
- Pre-engagement — scope, rules of engagement, escalation contacts, evidence handling.
- Reconnaissance — passive OSINT, then active enumeration.
- Vulnerability identification — automated scans + manual analysis.
- Exploitation — proving the vulnerability is real.
- Post-exploitation — privilege escalation, lateral movement, data access.
- Reporting — executive summary, technical detail, reproducible evidence, remediation guidance.
- Re-test — verify fixes.
Reference standards: PTES, OSSTMM, OWASP WSTG (web), NIST SP 800-115.
What separates a good pentester
- Coverage discipline — methodology checklists keep you from missing the obvious.
- Manual depth — Burp scanners and
nucleifind easy bugs; auth/auth flaws and business-logic bugs need a human. - Reporting — a great finding poorly written is a wasted finding. Write for both the engineer who fixes it and the executive who funds it.
- Restraint — knowing what not to do (DoS, destructive payloads, exfil of real PII) matters as much as knowing what to do.
Reporting
A pentest report’s center of gravity is the finding. Each finding typically has:
- Title — concise, descriptive.
- Severity — CVSS or organization-defined; pair with business impact.
- Affected asset — URL, host, function, line number.
- Description — what the bug is, in plain language.
- Evidence — request/response, screenshots, decoded payloads.
- Reproduction — exact steps an engineer can follow.
- Impact — what an attacker can do. Be specific.
- Remediation — concrete fix, not “implement input validation.”
- References — CWE, OWASP, vendor docs.
Common starting toolkit
- nmap — host/service discovery.
- Burp Suite — web proxy, repeater, intruder.
ffuf/gobuster— content discovery.nuclei— template-driven vuln scanner.crackmapexec/nxc(NetExec) — Windows / AD enumeration.responder— LLMNR/NBT-NS poisoning for credential capture.impacket— Python implementations of MSRPC, SMB, Kerberos primitives.metasploit— exploit framework, post-ex modules.
References
- PTES — http://www.pentest-standard.org/
- OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment