A penetration test is an authorized attack against a system, run to find out what a real attacker could do. The word authorized is doing all the work in that sentence.
Everything else about the profession, the scope documents, the rules of engagement, the careful reporting, exists to keep that authorization clear and to make the results useful.
The Line Between a Tester and a Criminal
It is a signed document. That is the whole difference, and it is worth stating bluntly because people entering this field sometimes treat it as a formality.
In the United States the Computer Fraud and Abuse Act governs unauthorized access, and similar laws exist nearly everywhere. Intent does not help you. Curiosity does not help you. Breaking nothing does not help you.
That is why every exercise in the HackRange courses runs against targets we own and provide, and why Module 1 of the CEH course covers scope and authorization before any tool is opened.
Testing Types, and What They Cost You
Black box means the tester starts with nothing but a name or an address, the way an outside attacker would. It feels realistic and it spends a lot of expensive hours on discovery you could have handed over.
White box means the tester gets documentation, source code, and credentials. It finds more real issues per hour because time goes into depth rather than discovery.
Grey box sits in the middle and is the most common in practice, typically with a standard user account provided.
The realism argument for black box is weaker than it sounds. A real attacker has unlimited time. Your tester has two weeks. Spending three days of that on reconnaissance buys you a simulation of the least interesting part.
Engagement Types
An external network test looks at what is exposed to the internet. An internal test assumes someone is already inside, which is realistic given how most intrusions start.
A web application test focuses on one application and its logic, and is where the OWASP Top 10 lives.
A red team engagement is different in kind. It is objective based, quiet, and tests detection and response as much as prevention. See red versus blue versus purple.
There are also wireless, physical, social engineering, cloud configuration, and mobile engagements, each with their own methodology.
The Phases
Scoping and authorization. What is in scope, what is explicitly out, when testing may happen, who the emergency contacts are, and what to do if something breaks or if evidence of a real ongoing compromise is found. That last clause matters more often than people expect.
Reconnaissance. Gathering what is publicly known and mapping the target.
Scanning and enumeration. Finding what is there, then making it talk: versions, users, shares, endpoints.
Exploitation. Proving a weakness is real rather than theoretical.
Post exploitation. What does this access actually reach, and what could an attacker do with it. This is where impact gets established.
Reporting. The deliverable, and the part clients actually pay for.
A Test Is Not a Scan
A vulnerability scan is automated, cheap, and produces a list of possible weaknesses, many of which are not exploitable in context. It is a program you run continuously. See vulnerability management.
A penetration test involves a human deciding what matters, chaining findings together, and proving impact. Anyone selling you a scan report as a penetration test is selling you a scan report.
Between the two sit breach and attack simulation and autonomous pentesting, which automate parts of the work at much higher frequency.
What a Good Report Contains
An executive summary that a non technical reader can act on, stating what was tested, what the overall picture is, and what the three most important things to fix are.
Findings with evidence, ranked by real risk in this environment rather than by raw score. A critical rated finding on an isolated test box is less urgent than a medium on the internet facing system holding customer data.
Reproduction steps clear enough that an engineer can confirm the fix worked.
Remediation advice that is specific. Update to version X, disable feature Y, change setting Z. Advice that says implement defense in depth is filler.
And an honest statement of what was not tested and why, including anything that ran out of time.
Getting Into This Work
The path most people take is strong fundamentals in networking and Linux, then hands on practice, then a practical certification. OSCP is the usual benchmark because its exam is a real lab with a time limit rather than a multiple choice test.
Practice platforms such as Hack The Box and TryHackMe are where most people build hours, and bug bounty programs through HackerOne or Bugcrowd provide legal targets with real payouts.
Our CEH v13 course covers the methodology and the tooling end to end with labs for every module.
Learn This at HackRange
The CEH course ends with a full engagement from first scan to root, run without module by module guidance, which is the closest thing to the real job.