Penetration Testing: Fundamentals and Workflow

What is penetration testing?

Penetration testing is a simulated attack against systems, networks, or applications, performed under explicit written authorization, with the goal of finding exploitable weaknesses before someone without permission does. The word "simulated" is doing a lot of work in that sentence — a pentest that doesn't behave like a real adversary produces a report full of theoretical findings that never get fixed, because nobody believed they mattered.

Unlike a vulnerability scan, which lists what might be wrong, a pentest proves what is actually exploitable, chains weaknesses together the way an attacker would, and shows the business impact in terms a non-technical stakeholder can act on.

Scoping before anything else

Every engagement starts with a scoping conversation, not a scan. Scope defines what's in bounds (IP ranges, domains, applications, physical locations), what's explicitly out of bounds, testing windows, and escalation contacts if something breaks. A signed rules-of-engagement document isn't paperwork — it's the line between an authorized assessment and a crime.

• Black box: the tester starts with no internal knowledge, closest to an external attacker's starting position.
• Gray box: the tester has limited credentials or documentation, mirroring an insider threat or a compromised low-privilege account.
• White box: full access to source, architecture diagrams, and credentials, used to maximize coverage in a fixed time window.

Core phases

1. Reconnaissance

Passive and active information gathering — DNS records, exposed subdomains, employee names on LinkedIn, technology fingerprinting from response headers. Good recon quietly does most of the work that makes later phases fast.

2. Scanning and enumeration

Mapping live hosts, open ports, running services, and versions. This is where a tester builds the actual attack surface, rather than guessing at it.

3. Exploitation and verification

Turning a suspected weakness into a proven one — a working exploit, a captured credential, a bypassed access control. Verification matters: an unconfirmed finding is a guess, and guesses get deprioritized by defenders who have limited time.

4. Post-exploitation

Once inside, the question shifts from "can I get in" to "what does this access actually let me reach." Privilege escalation, lateral movement, and data access are assessed against the client's real crown-jewel systems, not just the initial foothold.

5. Reporting

The deliverable a client actually pays for. A strong report separates an executive summary (business risk, in plain language) from technical findings (CVSS scoring, reproduction steps, and concrete remediation — not just "patch this").

What separates a useful pentest from a checkbox exercise

The engagements that actually reduce risk share a few habits: testers who chain low-severity findings into a high-severity path instead of reporting them in isolation, remediation advice specific enough for an engineer to act on without a follow-up call, and a retest once fixes ship. A report that sits in a drawer until next year's compliance audit didn't accomplish much.

Always operate within the rules of engagement and applicable law. Authorization in writing, scope boundaries respected, and a clear point of contact for anything unexpected — that discipline is what separates this work from the thing it's simulating.