How to become a penetration tester from scratch

To become a penetration tester, learn how systems work before you learn how to break them, practise attacks only in a lab you control, learn a recognised testing methodology, and get good at writing reports, because the report is what the client actually pays for. Most testers reach their first pentest role through an adjacent job (IT, SOC, development or support) plus a portfolio and a hands-on certification, not straight from zero.

That is less glamorous than “learn Kali in 30 days”, but it is how the people who do this for a living got there. The rest of this guide is the detail: what to learn, in what order, and how to prove it.

Legal note before anything else: only test systems you own or have written permission to test. Unauthorised access is a crime almost everywhere, including under Nigeria’s Cybercrimes (Prohibition, Prevention, etc.) Act 2015 and the UK’s Computer Misuse Act 1990. “I was only learning” is not a defence.

What does a penetration tester actually do?

A penetration tester is hired to find and demonstrate security weaknesses in a defined scope, within agreed rules, and to explain them clearly enough that the client can fix them. A typical engagement looks like this:

1. Scoping and rules of engagement. What is in scope (these IP ranges, this web app, these test accounts), what is out, testing windows, emergency contacts, and written authorisation.
2. Reconnaissance and enumeration. Finding hosts, services, versions, users and application functionality.
3. Vulnerability discovery. Working out which of those things are weak, with tools and, more importantly, with manual testing.
4. Exploitation. Proving impact safely: reading data you should not see, escalating privileges, moving from one system to another.
5. Reporting and debrief. Writing up each finding with evidence, risk rating and a fix, then walking the client through it.

We walk through every one of these on a fictional company in the phases of a penetration test. The thing to notice now is that only one of the five steps is “hacking”. Testers spend a large share of their time reading, documenting and explaining.

Do you need to be technical before you start?

Yes, and this is where most self-taught beginners go wrong. Exploitation is applied knowledge of how something normally works. Before touching attack tools, build these foundations:

If you are starting from absolute zero, our general cybersecurity roadmap for people with no experience covers these foundations month by month, and ethical hacking for beginners explains what to learn first and what to skip.

Step 1: build a lab you are allowed to attack

You need somewhere legal to practise. A laptop with 16 GB of RAM is comfortable; 8 GB works if you run one or two virtual machines at a time. The usual setup:

• An attacking VM, commonly Kali Linux or Parrot.
• One or more deliberately vulnerable targets: OWASP Juice Shop for web, Metasploitable and similar intentionally vulnerable VMs for network practice, and a small Windows domain once you are ready for Active Directory.
• A host-only or internal network in VirtualBox or VMware, so nothing vulnerable is reachable from the internet.

Our home lab guide covers free and low-cost builds step by step.

Step 2: learn reconnaissance properly

Recon is where the test is won or lost. Learn Nmap thoroughly, and learn to read its output rather than just run it. Here is a full TCP scan with service detection and default scripts against a target in our lab, a fictional “Acme Fintech” staff portal at 10.10.10.5:

$ sudo nmap -sV -sC -p- --min-rate 1000 -oA scans/web01 10.10.10.5
Starting Nmap 7.95 ( https://nmap.org ) at 2026-10-10 10:02 WAT
Nmap scan report for 10.10.10.5
Host is up (0.00041s latency).
Not shown: 65532 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Acme Fintech Staff Portal
|_http-server-header: Apache/2.4.41 (Ubuntu)
3306/tcp open  mysql   MySQL 5.7.33
MAC Address: 08:00:27:3A:1F:9C (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.42 seconds

What a tester notes from this, before running anything else:

• MySQL is exposed on the network. Databases rarely need to accept connections from everywhere. That alone may be a finding, and it is worth checking for weak credentials (in the lab).
• Versions are disclosed. Apache 2.4.41 and OpenSSH 8.2p1 point to an older Ubuntu release. Check the versions against public advisories, but remember that distributions backport fixes, so a version string alone is not proof of a vulnerability.
• The web app is the obvious next step. It has a title, so a human-facing portal sits there.
• -oA saved the output in three formats. You will need it for the report.

The flags are worth understanding rather than memorising: -sV probes versions, -sC runs Nmap’s default script set (some are intrusive, so use it only with permission), -p- scans all 65,535 TCP ports, and --min-rate speeds things up on a lab network (be gentler on real engagements). The official Nmap reference guide explains every option, and our Nmap commands cheat sheet has 25 commands with real output. If you want to try Nmap outside your lab, the Nmap project permits light scans of scanme.nmap.org and nothing else.

Step 3: learn web application testing

Much paid pentest work is web and API testing, so this is not optional. Learn:

• How HTTP works in detail: methods, headers, status codes, cookies, sessions, tokens.
• How to use an intercepting proxy, usually Burp Suite (the Community Edition is free), to see and modify every request your browser sends.
• The main vulnerability classes in the OWASP Top 10, currently the 2025 edition, which places Broken Access Control first.

The best free resource here is the PortSwigger Web Security Academy: structured lessons with labs that you are explicitly allowed to attack. Work through access control, authentication, SQL injection and cross-site scripting before anything exotic.

A simple example of the mindset. In your lab app, you log in as a normal user and Burp shows this request:

GET /api/v1/accounts/1042/statement HTTP/1.1
Host: portal.acme-fintech.test
Cookie: session=7f3c...

The tester’s question is: what happens if I change 1042 to 1041? If the server returns someone else’s statement, you have found an insecure direct object reference, a form of broken access control, and that is often a high-severity finding in a financial app. No fancy tool required; just an understanding of what the server should check.

Step 4: learn a methodology, not just tools

Tools change. Methodology is what makes your work repeatable and defensible. Read, at least once:

• NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment. It is older, but its planning, discovery, attack and reporting structure still underpins most methodologies.
• The OWASP Web Security Testing Guide, which gives every web test a reference ID you can cite in a report.

Then build your own checklist from them and use it on every lab machine. When a client asks “how do you know you tested authentication thoroughly?”, the answer is your methodology, not your favourite tool.

Step 5: practise writing the report

This is the step that separates hobbyists from hireable testers. Every finding needs a title, a risk rating, affected assets, a plain-English description, reproduction steps, evidence and a specific fix. Here is the shape of one, from the lab example above:

Finding 3: Account statements accessible to any authenticated user (IDOR) Risk: High. Affected: GET /api/v1/accounts/{id}/statement on portal.acme-fintech.test. Description: The API returns a statement for any account ID supplied, without checking that the account belongs to the logged-in user. A customer could read other customers' transaction histories. Evidence: Request and response screenshots showing account 1041’s statement returned to the user who owns account 1042. Recommendation: Enforce object-level authorisation on the server for every account-scoped endpoint; derive the account from the session rather than trusting the ID in the URL; add automated tests for cross-account access.

Many teams score severity with CVSS; the CVSS specification from FIRST is worth reading so you understand what goes into a score. Write a full report for every lab machine you complete. Two or three of those, sanitised and published, are better evidence than a list of tools on a CV.

Which certifications help you become a penetration tester?

Certifications do not make you a tester, but they help you get interviews and give your study a structure.

• CompTIA PenTest+ (PT0-003). A vendor-neutral, performance-based exam covering the whole engagement, from scoping to reporting. Its five domains are Engagement Management, Reconnaissance and Enumeration, Vulnerability Discovery and Analysis, Attacks and Exploits, and Post-exploitation and Lateral Movement. Check the official PenTest+ page for current details, and see our PenTest+ PT0-003 study guide.
• Hands-on practical exams from specialist training providers, where you compromise lab machines within a time limit and submit a report. These are well regarded for showing practical skill.
• CompTIA Security+ is not a pentest certification, but it is a common baseline requirement for security roles, and many testers take it first.

Whatever you choose, prepare honestly. Exam dumps breach certification agreements and leave you unable to do the job the certification describes.

How do you get your first penetration testing job?

Junior pentest roles exist, but there are fewer of them than entry-level SOC or IT roles, and they usually go to people who can already show practical work. Realistic routes in:

• Adjacent role first. IT support, system administration, SOC analyst or developer roles teach you how real environments are built and defended. Many testers moved across after a year or two.
• Internal move. Larger organisations and consultancies sometimes move people from SOC or IT into their testing teams.
• Portfolio-led application. Lab write-ups, sample reports, a GitHub with small tools or scripts, and walkthroughs of retired practice machines.
• Bug bounty, carefully. Public bug bounty programmes let you test real applications within each programme’s published rules. Read the scope and rules completely before you start, and never test anything outside them.

In interviews, expect to explain a finding from your portfolio end to end, talk through how you would approach a scenario (“you have one IP and a web app, go”), and answer networking and web fundamentals. Being able to explain clearly what you would not do without permission scores points too.

A realistic learning sequence

How long each stage takes depends on your starting point and weekly hours; treat any fixed timeline you see online with suspicion.