General Methodology of a Test: PTES and the Major Phases

A penetration test is not a random series of clever tricks. It is a structured project that follows a method, so that results are complete, repeatable and useful to the client. Beginners imagine hacking as improvisation; professionals know that the discipline of a process is what makes the work reliable and safe. In this lesson you will learn the overall shape of a test, using the well-known Penetration Testing Execution Standard (PTES) as a guide, and see how it connects to the courses ahead.

The previous lesson explained the legal frame. Now we see what happens inside that frame, phase by phase. You will not run any attack here: the aim is the map, so that each later technique fits in a place you already know.

Why a methodology?

• Coverage: a method reduces the risk of forgetting entire areas.
• Repeatability: another tester can follow your notes and obtain comparable results.
• Safety: each step is planned, with limits, so that the test does not harm the client's production.
• Communication: the client understands what was done and why, and can compare results between years.
• Legal protection: a documented process shows that you stayed within scope.

Several frameworks exist and overlap. PTES describes the whole life of a penetration test. The OWASP Web Security Testing Guide (owasp.org) details web application testing, and you will use it in course 3. The NIST technical guide on information security testing (nist.gov) is a reference for planning assessments, and the MITRE ATT&CK knowledge base (attack.mitre.org) catalogues attacker tactics and techniques, helping to describe and to compare behaviours. Learn the common spirit rather than a single document.

The seven phases of PTES

1. Pre-engagement interactions

Everything that happens before any technical action: understanding the client's goals (compliance, validating a new application, measuring resilience), agreeing on the type of test, the scope, the rules of engagement, the schedule, the contacts, the legal documents and the reporting expectations. This is where the authorisation of lesson 1 is established. Skipping or rushing it is the most frequent source of problems. A test without clear goals produces a report nobody needs.

2. Intelligence gathering

Collecting information about the target: its domains, technologies, employees' public roles, exposed services, third-party providers. Part of this work is passive (it uses public sources and never touches the target's systems), and part is active (it sends traffic to the target, such as scanning). The next lesson covers passive collection.

3. Threat modelling

Thinking like an adversary to decide what matters. Which assets have the most value (customer data, payment systems, intellectual property)? Who might want them, and how? What would the most likely attack paths be? This step turns a pile of information into priorities. A tester with limited time should focus on what would hurt the client most.

4. Vulnerability analysis

Finding weaknesses in the in-scope systems: misconfigurations, outdated software, weak authentication, flawed logic. It combines automated scanners (fast, broad, noisy, with false positives) with manual analysis (slower, deeper, contextual). A scanner result is a lead, not a finding, until it is verified.

5. Exploitation

Demonstrating that a vulnerability can really be used, in a controlled and agreed way, to gain access or impact. The goal is proof, not destruction. A professional chooses the least intrusive demonstration that convincingly shows the risk, and avoids anything that could crash a service unless this was explicitly agreed. In a lab, you can go further; in a real engagement, the rules of engagement set the limit.

6. Post-exploitation

Determining the value of what was gained: what could an attacker do next? Which data could be reached? Could they move to other systems or climb to higher privileges? This is where a single weakness is put into business context. It is also where discipline matters most: stay in scope, handle data minimally, and clean up any tools or accounts created during the test so that you leave the environment as you found it.

7. Reporting

The deliverable that the client actually keeps. A good report has an executive summary in business language, a technical section with each finding (description, evidence, impact, severity, steps to reproduce, recommendation), a description of the method and scope, and a prioritised remediation plan. A very technical test with a poor report is a poor test. We spend a full chapter on this in courses 3 and 4. Often there is also a retest afterwards, to verify that fixes work.

Types of test, scope and perspective

Tests differ by the information given to the tester. In a black box test, you know almost nothing, like an external attacker. In a white box test, you receive full information (architecture, source code, accounts), which finds more in less time. A grey box test is in between, for example with a normal user account. Tests also differ by target: external network, internal network, web application, mobile application, wireless, social engineering, physical access, cloud. The next courses concentrate first on the web, then on complete network engagements.

You may also hear of red team exercises, which simulate a real adversary over a longer time and with fewer constraints on the defenders' knowledge, and of vulnerability assessments, which list weaknesses without trying to exploit them. A penetration test sits in between. Knowing which service the client needs avoids misunderstandings.

Notes, evidence and safety habits

Whatever the phase, professionals build the same habits, and you can start them in your lab now:

• Take timestamped notes of every action: command, target, time, result. They support the report and protect you in case of dispute.
• Collect evidence carefully (screenshots, command outputs), while masking sensitive data.
• Check the scope before every action, particularly when typing target addresses.
• Prefer the least harmful technique that answers the question.
• Communicate immediately about critical findings, instead of waiting for the final report.
• Protect client data: encrypt your notes and evidence, and securely delete them at the end according to the contract.

Mapping the phases to this track

Phase	Where you study it
Pre-engagement	This chapter and course 4, chapter 1
Intelligence gathering	Next lesson, then course 4, chapter 2
Threat modelling	Course 3 (web) and course 4 (prioritising targets)
Vulnerability analysis	Course 3 (web flaws) and course 4, chapter 3
Exploitation	Course 3 (in legal labs) and course 4, chapter 4
Post-exploitation	Course 4, chapter 6, with a defensive angle
Reporting	Course 3, chapter 7 and course 4, chapter 7

Your turn: plan a test of your own lab

Write a one-page test plan for a mini-engagement of your own: "assess the security of my lab server". Fill in each PTES phase with one or two lines. Include the written authorisation (you are both client and tester, so write the statement and sign it), the scope (only 10.10.10.20), what is out of scope (everything else, including your host and home network), the rules (no denial of service, snapshot before each phase), the contact (yourself) and the deliverable (a short report). Do not run any test yet: the point is to practise the planning discipline.

See a solution

A strong plan reads like a small contract. Example: Authorisation: "I, the owner of the lab, authorise myself to test the machine 10.10.10.20 from 10.10.10.10 between these dates." Scope: only that machine; out of scope: the host computer, the home network, the Internet. Rules: snapshot before each phase, no denial-of-service tests, no use of real credentials. Phases: intelligence gathering (list services and versions); threat modelling (what would hurt? my notes and the SSH service); vulnerability analysis (check configuration against the Linux hardening principles of chapter 4); exploitation (none in this exercise); post-exploitation (n/a); reporting (a table of findings with a recommendation for each). The exercise teaches you that the technical work is a small part of a professional engagement.