Most posts on this blog assume you already do offensive security work. This one doesn’t. It’s for the people who message me asking what pentesting actually is, how it differs from running Nessus, and what a real engagement looks like day to day. A lot of the public-facing material on this is either marketing copy or the kind of motivational hacker writing that’s heavier on attitude than on what the job actually entails. I’d rather just describe the work.
VA, pen testing, and red teaming aren’t the same thing#
These three terms get used interchangeably in job postings and they shouldn’t be.
Vulnerability assessment (VA) is automated. You point a scanner — Nessus, Qualys, Tenable, OpenVAS — at a network and it produces a list of CVEs. Cheap, fast, and mostly useless on its own because the list is huge, full of false positives, and ranked by CVSS scores that ignore your business. VA tells you what’s wrong; it doesn’t tell you what matters.
Penetration testing (PT) is manual exploitation against a defined scope. The goal is to find chains of vulnerabilities that actually let an attacker do something — get a shell, dump a database, escalate to domain admin — and to come out the other side with a narrative of how you did it. PT is usually scoped tight: “the payment app,” “this /24,” “the customer-facing API.” The output is proof of compromise plus a story the client can act on.
Red teaming is testing the defenders. You’re not trying to find every bug in the network; you’re trying to accomplish a specific objective (steal the CEO’s email, pivot to the OT network, exfiltrate a sample of customer data) without getting caught. The deliverable is a timeline: what you did, when the SOC noticed (or didn’t), what they missed, and where the detection gaps live. It’s longer, more expensive, and almost always uses social engineering and custom tooling.
Loosely: VA tells you what’s broken. PT tells you which of those breaks an attacker can actually use. Red team tells you whether anyone would notice if they did. Most clients want PT and call it red teaming, which is fine if you set expectations.
PTES, the workflow#
Pentests follow some kind of methodology, otherwise they degenerate into “running tools until something works.” The Penetration Testing Execution Standard (PTES) is the most widely cited one. Its seven phases:
- Pre-engagement interactions — scope, legal boundaries, contacts, Rules of Engagement (ROE), what’s out of bounds, what the success criteria are. The bad engagements are bad because of poor work here, not because of poor exploitation skills later.
- Intelligence gathering — OSINT and active recon. Map the attack surface.
- Threat modeling — who would attack this, what would they go after, what controls are in the way.
- Vulnerability analysis — finding the weak points, validating them, ranking them.
- Exploitation — getting in. This is the part that gets put in movies, and on a real engagement it’s usually a small percentage of the total time spent.
- Post-exploitation — what can you actually do once you’re in? Looting, privilege escalation, lateral movement, persistence (if scope allows).
- Reporting — turning the technical work into something the client’s executives can act on. This is what they’re paying for.
OSSTMM and OWASP’s Testing Guide are alternatives — OSSTMM is broader and covers physical and human channels, OWASP WSTG is specifically for web apps. Any of them is fine. What matters is picking one and actually using it, instead of running tools in whatever order they occur to you at the moment.
The Rules of Engagement#
The ROE is the document that distinguishes a pentester from a criminal. Read it slowly before you start, and re-read it whenever you’re about to do something you’re not sure about.
What should be in it:
- Testing windows. Explicit hours and days. “Monday through Friday, 9-5” vs. “any time” is a different engagement.
- IP ranges and assets. Both inclusions and exclusions. The “don’t touch the legacy AS/400 because it crashes if you breathe on it” exclusion is real.
- Forbidden techniques. Can you DoS? Phish employees? Drop physical media? Test the wireless network? Touch production data?
- Emergency contacts. Who do you call when you accidentally take something down, when you find evidence of a real intrusion, or when the SOC is about to call the FBI on you?
Never touch anything outside scope, ever, even if it’s tempting and “would only take a second.” Scope creep is how pentesters lose their certifications and their freedom.
Box colors#
The industry talks about engagements in terms of how much information you start with:
- Black box — you know nothing. An external attacker’s view. Realistic, but inefficient: you’ll burn hours on recon that a defender could have just told you. Best when the client wants to know what a real outsider would find.
- White box — you have everything: source code, architecture diagrams, admin credentials. Best for thorough audits where the goal is “find every bug” not “simulate an attacker.” Code review-heavy.
- Grey box — partial info. User credentials but not admin, or a network diagram but no code. The most common in practice because it’s the most cost-effective.
The names are inherited from cryptography and don’t matter much. What matters is being clear with the client about what you’re getting before the engagement starts.
The home lab#
You don’t learn this on production systems. You learn it in a lab where you can break things without consequences.
What I’d build first:
- A hypervisor. Proxmox if you have spare hardware, VMware Workstation Pro (now free for personal use) or VirtualBox on your laptop if you don’t.
- An attack box. Kali Linux is the default; Parrot Security is the actively-developed alternative.
- Vulnerable targets. Metasploitable 2 and 3 are classics. DVWA and OWASP Juice Shop cover web apps. For Active Directory, build a Windows Server DC and join two Windows clients to it — most of the interesting modern attacks live there.
- Pre-built challenges. HackTheBox, TryHackMe, and VulnHub publish vulnerable VMs in the dozens. HackTheBox’s “Pro Labs” simulate full enterprise networks.
The lab is where you learn to feel comfortable with failure. Most exploits don’t work the first time. Most exploits don’t work the fifth time. That’s normal.
Reports are the deliverable#
New testers fixate on getting the shell. The shell is the easy part. The report is what the client paid for.
A good pentest report has:
- Executive summary. A page, plain English, written for someone who can’t tell SQL injection from XSS but signs the budget. Not “we exploited CVE-2024-1234 in your Tomcat instance” but “an attacker on the internet can read your entire customer database.” Risk in business terms.
- Narrative. The story of the attack chain. What you found, what you tried, what worked. Readable end to end.
- Technical findings. One entry per issue, with severity (CVSS is fine), reproduction steps (screenshots, requests/responses, specific payloads), and remediation that says more than “patch it.” If the fix is “use parameterized queries,” say so and link to the framework’s docs.
Remediation is where reports usually fall down. Writing one that an engineer at the client can actually act on, without their security team having to translate, is the thing that makes clients hire you again.
Ethics and the law#
The legal side isn’t optional and the rules are stricter than you’d guess.
- Computer Fraud and Abuse Act (CFAA, US). Unauthorized access to a computer is a federal crime. “I was just testing” is not a defense. Get written authorization (a signed Statement of Work, contract, or letter), keep a copy with you during the engagement, and don’t touch anything not in scope.
- Data privacy. If you stumble into PII, PHI, payment card data, or anything else regulated, stop, document, and contact the client’s emergency contact. Don’t exfiltrate it. “Proof of access” is enough; the database itself is not yours to take.
- Backdoors and cleanup. Whatever you installed for persistence, take it back out. Webshells, scheduled tasks, services, AD accounts — all of it. The last day of the engagement is cleanup day.
- Other jurisdictions. The EU has the Computer Misuse Act in the UK, GDPR for data handling, and various national laws. If you’re testing systems in other countries, you need to know the local rules.
Closing#
Penetration testing is mostly tedious. The OSCP-style movie-montage hacking is maybe ten percent of the actual job. The rest is reading, recon, writing, and getting the scope right. Get the lab built, work through enough challenges to learn what failure feels like, find a methodology you’ll actually follow, and write a report you’d be proud to hand to a stranger. And whatever you do, get the authorization in writing before you start scanning anything you don’t own.
