Cybersecurity

Penetration Tester

Break in on purpose, with permission, so the gaps get closed first.

This is usually a second role — most people arrive from support, systems or networking.

What you actually do

  • Map what is exposed and reachable before deciding what to try
  • Chain small weaknesses into one that actually matters
  • Test applications for logic flaws as well as known vulnerabilities
  • Prove impact concretely rather than reporting theoretical risk
  • Write a report the defending team can act on, prioritised honestly
  • Retest after the fixes to confirm they worked

Technologies you may touch

Nobody uses all of these. Which ones depends entirely on the employer.

  • Nmap Scans a network to find what is there and which services each host is offering.
  • Burp Suite / Metasploit Tools for testing applications and systems by actually attacking them, under an agreed scope.
  • Linux The operating system most servers, network devices and cloud workloads run on, driven from a command line.
  • Python A general-purpose language used across automation, security tooling, data work and applications.
  • Active Directory The Microsoft system that holds every user, group and computer account in most organisations, and decides what each can open.
  • Wireshark Records and displays the actual conversation between two machines, packet by packet.

Concepts you will learn

These transfer between employers and outlast any particular product.

  • Scoping and rules of engagement
  • Privilege escalationprivilege escalation — Going from a limited account to one that can do far more than it should.
  • Lateral movementlateral movement — An attacker who is already inside moving from the first machine to more valuable ones.
  • Web application vulnerabilities
  • Reporting and impact

Where this work happens

Security consultancies Internal red teams Bug bounty work Government and defence

You may enjoy this if…

  • You instinctively look for the thing a system was not designed to handle
  • You enjoy learning a system deeply enough to find its assumptions
  • You like work with a clear, provable outcome

The honest downside

It is far more report writing than film suggests. Scopes are narrow, clients are sometimes defensive about findings, and the field is crowded at the entry end — most people arrive from systems, networking or development, not from a course.

What it pays

Pay is the thing people most often get misled about, so here is where every number comes from — including the ones that are not really numbers.

Nearest official occupation

Median for the occupation

$124,910

Information Security Analysts (15-1212)

What you actually start on

~$60,000–$85,000, and the entry end is crowded

Outlook

+29% — much faster than average, but heavily experience-gated at the entry end

There is no exact official occupation for this role. The figure comes from the closest one, which covers a somewhat different set of jobs.

Within Information Security Analysts (15-1212). The visible salary figures are skewed by a small number of highly specialised practitioners; the ordinary consultancy end is considerably lower, and competition for junior seats is intense.

A median is the midpoint of everyone employed in that occupation, including people decades into their careers — so starting pay runs materially lower. Verify against the live BLS page before making a decision.

Source: U.S. Bureau of Labor Statistics · BLS OES, May 2024 release · figures are national and United States–specific; pay varies substantially by region and employer. Nothing here is adjusted for cost of living.

CertBlueprint earns affiliate commission on some study resources. It earns nothing from Penetration Tester salaries, and no role is ranked, recommended or presented more favourably because of what it pays.

Where this leads

IT careers are a graph, not a ladder. These are the moves people actually make from here — each one reuses most of what you already know.

See where Penetration Tester sits on the whole map →

Application Security Engineer

If the software layer is where you keep finding things.

Vulnerability Management Analyst

The at-scale, defensive counterpart.

Security Architect

Knowing how things break is excellent preparation for designing them.

Often confused with

Titles overlap heavily in IT and tell you very little. Each of these puts Penetration Tester beside another role on the same dimensions, with the practical differences underneath.

vs Application Security Engineer vs Vulnerability Management Analyst vs Security Architect

Try it this weekend, before you spend anything

Reading about work and doing it are different. Each of these is free, runs on the machine you already have, and takes under an hour and a half. Finding out you dislike it is a genuinely useful result — and far cheaper here than after an exam voucher.

Try the work · 60–90 minutes

Find what’s exposed

Free

Discover what is actually listening on your own network — including the things you had no idea were there — and work out which of them would matter.

Nothing to install · no account · open the steps

Before you start

Scan ONLY your own home network, and only devices you personally own. There is exactly one external exception below — scanme.nmap.org, which the Nmap Project publishes specifically so people can practise, and which should be scanned a couple of times, not hammered. Everything else is off limits: not your employer, not your university, not a friend's network with verbal permission, not a website "just to see". Unauthorised scanning is a criminal offence in the UK, the US, and most of Europe, and the fact that you were curious rather than malicious is not a defence anyone has successfully run. If you are ever unsure whether you have permission, you do not have permission.

Nmap is free and open source. One install, no account, available for every platform.

  1. Establish what your own network is

    Find your own address and the range your network occupies. You need to know precisely what you own before you touch anything, and getting this wrong is how people accidentally scan their neighbour or their ISP.

    Windows
    ipconfig
    macOS
    ifconfig | grep "inet "
    Linux
    ip addr

  2. Find out what is actually on it

    A ping sweep of your own range. Count the results. Almost everyone finds more than they expected — a thermostat, a TV, a printer they thought was off, a doorbell, a device they cannot identify at all. That last category is the interesting one.

    Any
    nmap -sn 192.168.1.0/24        # adjust to YOUR range from step 1

  3. Identify the one you cannot name

    Pick the device you could not identify. Ask what it is — services, guessed operating system, vendor from its hardware address. Then go and physically find it in your home. This is device profiling, and it is precisely what a network access control system does automatically, all day, at enterprise scale.

    Any
    nmap -A 192.168.1.42          # the unknown device on YOUR network

  4. Practise against the one legal target

    The Nmap Project runs scanme.nmap.org for exactly this purpose. Scan it once or twice — not repeatedly — and compare what a deliberately exposed host looks like against your own devices. Read the open ports and ask what each one is for.

    Any
    nmap -A scanme.nmap.org

  5. Ask the question that actually matters

    You now have a list of open ports. A scanner will tell you what is open; it will never tell you whether it matters. For each finding ask: is it reachable from outside my house, what would someone get if they took it, and is there a reason it is on at all? That reasoning — exposure and impact, not severity scores — is the whole difference between running a tool and doing the job.

  6. Write it up as if for someone else

    Three findings, ranked by what you would fix first, with a sentence each on why. Include one you decided NOT to worry about, and say why. Being able to justify what you deliberately ignored is what separates a useful report from a wall of noise nobody acts on.

This suits you if…

  • Finding a device you did not know was there was a genuine thrill
  • You wanted to keep pulling on what each open port was for
  • Deciding what mattered was more interesting than running the scan
  • You immediately thought about how this scales to ten thousand devices

If you disliked it

If the scanning felt like pressing a button and reading output someone else generated, that reaction is worth trusting. Offensive and vulnerability work is far more about the judgement in steps five and six — exposure, impact, prioritisation, writing — than about tooling. If the tool was the fun part and the reasoning was the chore, the day-to-day may disappoint you.

Try the work · 60–90 minutes

Break your own app

Free

Build a small thing that works, break it in sixty seconds using nothing but the address bar, then understand exactly why it broke and fix it properly.

Nothing to install · no account · open the steps

Before you start

You are attacking a file you wrote, on your own machine, that nobody else can reach. Do not point any of this at a website you do not own — testing someone else's site without written authorisation is a criminal offence, and "it was only an alert box" has never made a difference to that. If you want a bigger target afterwards, OWASP Juice Shop exists specifically to be attacked legally.

A text editor and a browser. No install, no server, no account — the page runs from a file on your desktop.

  1. Build something that works

    Save this as a file called app.html and open it in your browser. It is a greeting page that takes a name. Use it normally first — type your own name, see it work. Everything you build starts here: correct, for the input you imagined.

    Any
    <!doctype html>
<input id="n" placeholder="your name">
<button onclick="go()">Greet</button>
<div id="out"></div>
<script>
function go() {
  const name = document.getElementById("n").value;
  document.getElementById("out").innerHTML = "Hello, " + name + "!";
}
</script>

  2. Type something that is not a name

    Now put this in the box instead and press the button. Something will happen that the author did not intend and did not anticipate. You have just done the fundamental move of application security: supplying input the designer never pictured.

    Any
    <img src=x onerror="alert('this is now my page')">

  3. Work out precisely why it worked

    The code never asked for code — it asked for a name. But it glued your text into the page as markup rather than as text, so the browser did what browsers do and executed it. Sit with that: the flaw is not the alert box, it is that data and instructions were allowed to occupy the same channel. Nearly every major vulnerability class is a variation of that one sentence.

  4. Escalate it

    An alert box proves nothing to anyone. Change your payload so it reads something real from the page instead — the document title, a cookie you set yourself, the contents of another element. Proving actual impact rather than mere possibility is the difference between a finding a developer fixes and one they close as noise.

    Any
    <img src=x onerror="document.getElementById('out').textContent = document.title">

  5. Fix it — the right way and the wrong way

    First fix it badly: filter out the word "script". Then defeat your own filter — the payload above never used that word. Now fix it properly by changing innerHTML to textContent, so the input is treated as text and can never be instructions. Try every payload again. This contrast, blocklist versus correct handling, is the single most useful lesson in the whole trial.

    Any
    document.getElementById("out").textContent = "Hello, " + name + "!";

  6. Go looking for the same shape elsewhere

    Where else does something you have written take input and put it somewhere with meaning — a filename, a database query, a shell command, a URL? Write down three. You now have the pattern-recognition that application security work actually consists of, and it transfers to every language you will ever use.

This suits you if…

  • Beating your own bad filter in step five was the best part
  • You immediately wanted to try payloads nobody suggested to you
  • The data-versus-instructions idea reframed something for you
  • You started mentally auditing code you have already written

If you disliked it

If the adversarial framing did not appeal — if you would rather have spent the ninety minutes making the page good than making it fail — that is a genuinely useful signal, and it points at development or platform work rather than security. The people who thrive in application security are the ones who cannot stop asking "but what if I send it something stupid".

Certifications that fit this path

These come last for a reason. A certification is evidence for a direction you have already chosen — it is not the direction itself.

Foundation CompTIA Security+ Baseline knowledge and a common hiring filter. Core CompTIA PenTest+ The methodology and reporting side, properly covered. Foundation CompTIA Network+ You cannot attack what you do not understand.

Not sure whether this is actually you?

Reading about a role and enjoying the work are different things. The scenarios show you the problems instead of describing them, and tell you which ones you keep reaching for.

Try the scenarios →