The 5 phases of a pentest, explained with a real case

A pentest is not sitting down and firing tools until something falls over. It's a process with phases, and skipping one gets paid for in the next. Here's how it's done, with what really happens along the way.

Phase 0: scope and authorisation

Before touching anything, paperwork. And it isn't bureaucracy: it's what separates the job from a crime.

This phase defines:

• What's in and what's out. IP ranges, domains, applications. What isn't written down doesn't get touched.
• The time window. When you're allowed to attack. Nobody wants the aggressive scan during month-end close.
• What's forbidden. Denial of service, social engineering against named employees, attacks on production.
• Emergency contacts. If you knock a service over by accident, there has to be a phone number you can call within two minutes.
• The signed authorisation. By someone with the authority to give it, not by the technician who let you in.

One detail that always gets forgotten: if the target is hosted at a cloud provider, that provider has its own rules about penetration testing. The contract with the client does not override the provider's terms.

Real case, condensed: a logistics company commissions an audit of its external infrastructure. Scope: two public ranges and every subdomain of its main domain. Out of scope: anything that could affect availability of the shipment tracking system.

Phase 1: reconnaissance

First you find out what exists. And here the more passive the better: information gathered without sending a single packet to the target raises no alerts and is usually the most revealing.

Passive: TLS certificates, historical DNS records, the Wayback Machine, public repositories, employee profiles on LinkedIn, old credential leaks. All of this is OSINT, and it's the phase that most determines the rest.

Active: port scanning, version identification, web directory enumeration.

amass enum -passive -d logistics-example.com
nmap -p- --min-rate 5000 -oA full 203.0.113.10
nmap -sVC -p 22,80,443,3389 -oA detail 203.0.113.10

What turned up in the case: 47 subdomains, 11 of which weren't in the inventory the company had given us. One of them, old-staging, answered with the admin panel of a content manager that hadn't been updated in three years.

That's the most common pattern in this industry: the problem is almost never the server they watch. It's the one they forgot.

Phase 2: analysis and exploitation

With the map in front of you, you look for the flaws and check which ones are real.

The important part, and what distinguishes a professional: an unexploited vulnerability is a hypothesis. Automated scanners generate false positives at a notable rate, and delivering a report full of findings that don't hold up destroys your credibility with a client faster than finding nothing at all.

The priority order, when time is limited:

1. What gives direct access: default credentials, unauthenticated exposed services, known remote code execution.
2. What gives chained access: a file upload plus an executable directory, an SSRF plus a trusted internal service.
3. What gives information: path disclosure, versions, verbose error messages.

What happened in the case: the forgotten panel allowed uploading a file with a double extension. The server interpreted it as PHP. Shell.

No sophisticated exploit was needed. It almost never is.

Phase 3: post-exploitation

Being inside isn't the end: it's where real impact starts being measured. And impact is what the client is going to read.

• Privilege escalation. From www-data to root, from domain user to administrator.
• Lateral movement. From that machine, what else can be reached?
• Persistence. You document how it would be achieved, but in a normal pentest you do not leave it installed. And if something is left by express agreement, it gets removed and the removal is certified.
• Data access. This needs great care: you demonstrate that access is possible, you don't download the customer database. A screenshot of the table structure and the record count proves the same thing without turning you into a data protection problem.

sudo -l
find / -perm -4000 -type f 2>/dev/null
bloodhound-python -u user -p password -d logistics.local -c all

In the case: from the compromised server the internal network was reachable through a badly segmented VPN. From there, a backup service with domain administrator credentials stored in a world-readable configuration file.

From forgotten panel to full domain in six hours.

Phase 4: the report

This is the phase that decides whether the work was worth anything, and the one everyone spends the least time on.

A useful report has two halves that get read separately:

Executive summary — two pages, no jargon, for whoever signs the budget. What risk the business carries, what it would cost if it happened, and which three things to fix first.

Technical detail — one finding per page, each with:

• Description and severity, with the CVSS score and why.
• Step-by-step reproduction, with the exact requests.
• Evidence: screenshots, command output, sensitive data redacted.
• Concrete remediation. Not "apply best practices", but "upgrade to version 4.2.1 or disable the upload module in config/uploads.yml".

The acid test for a good report: can the client's sysadmin fix the flaw reading only the finding, without calling you? If the answer is no, the report is half done.

Phase 5: the one nobody mentions

The retest. Weeks later you check again that what you said to fix has been fixed. It's surprising how often it hasn't, or how often the patch introduced a new flaw.

And afterwards, deletion. All client information left on your machine is destroyed within the agreed period. A pentester with a folder full of old clients' credentials is, himself, the biggest risk those clients have.

How to practise this without a client

Methodology is learned by repeating it. Vulnerable machine platforms are the place to do it, and the key is to treat them like a real engagement: full recon before touching anything, notes from minute one, and a report at the end even though nobody will read it.

That last part is what almost nobody does, and it's what will set you apart most when you look for work.

The Hack The Box course teaches exactly that methodology applied to real machines, and the Kali Linux course — free — walks this same full cycle, report included, in a lab you build yourself.

If you're starting out and want the whole map, it's in how to become an ethical hacker from scratch.