Walk me through a penetration testing methodology like PTES.
Short answer
PTES defines seven phases: pre-engagement (scope, rules of engagement, authorization), intelligence gathering (OSINT, recon), threat modeling, vulnerability analysis, exploitation, post-exploitation (pivoting, data of value, persistence), and reporting. The structure makes engagements repeatable, defensible, and tied to business risk rather than ad-hoc hacking — pre-engagement and reporting are the phases juniors underrate.
A penetration test is not "hacking until something breaks" — it is a structured, authorized assessment that has to be repeatable and defensible. The Penetration Testing Execution Standard (PTES) is the most cited framework for that structure, and interviewers use it to see whether you treat a test as an engagement with legal and business boundaries, not a free-for-all.
The seven phases
- Pre-engagement interactions. Scope, goals, timing, in-scope and out-of-scope assets, the rules of engagement, and — critically — written authorization. Get this wrong and the rest of the test is unauthorized access.
- Intelligence gathering. OSINT, DNS, network and application recon to build a map of the attack surface before you touch anything intrusive.
- Threat modeling. Turn that intelligence into likely attack paths and prioritize targets by business impact, not just by what looks easy.
- Vulnerability analysis. Identify weaknesses through scanning, manual testing, and validation — discarding false positives a scanner would hand you.
- Exploitation. Prove the vulnerability is real by gaining access, while staying inside scope and avoiding collateral damage.
- Post-exploitation. Pivot, escalate privileges, find data of value, and demonstrate true business impact. This is where the test earns its fee, because "we got domain admin and could read payroll" lands harder than "port 445 is open."
- Reporting. A clear narrative for executives plus reproducible, risk-rated, remediable findings for engineers.
Why the structure matters
The bookend phases — pre-engagement and reporting — are what separate a professional from a script kiddie. Scope and authorization keep you legal; the report is the only deliverable the client actually pays for.
What interviewers look for
They want to hear that you scope and authorize before exploiting, that you tie findings to business risk, and that you can explain why post-exploitation and a strong report matter more than collecting shells.
Likely follow-ups
- What goes into a rules-of-engagement document before you touch a target?
- Why is post-exploitation often more valuable to the client than the initial exploit?
- How do you handle finding evidence of a real prior breach mid-engagement?