Introduction to Penetration Testing

A penetration test is an authorised, scoped, time-boxed attempt to compromise a system so that its owner learns what a real attacker would achieve. The word doing the heavy lifting is authorised. Without written permission defining scope and timing, the same activity is a crime.

Scoping and rules of engagement. Before any tool runs, you agree in writing on target ranges, excluded systems, testing windows, whether social engineering is permitted, and who to call if you break production. This document protects both sides.

Reconnaissance. Passive first: certificate transparency logs, DNS records, job postings, code repositories, leaked credential dumps. Public information routinely reveals internal hostnames, technology stacks, and naming conventions before you touch the target at all.

Enumeration. Now you interact. Map hosts, ports, services, and versions, then dig into each service properly.

```bash
# Discover live hosts and open ports, then fingerprint what is listening
nmap -sS -p- --min-rate 2000 -oA sweep 10.10.0.0/24
nmap -sCV -p 22,80,443,3306 -oA detail 10.10.0.15

Exploitation. Prove the vulnerability is real. A scanner finding is a hypothesis; a shell, an authenticated session, or extracted data is evidence. Chain small issues, because an information leak plus weak password policy plus a forgotten admin panel often beats any single critical CVE.

Post-exploitation. Establish what the foothold is worth. Can you reach the database? Read another tenant's data? Escalate to domain admin? Impact is what turns a technical finding into a business decision.

Reporting. The deliverable is the product. Every finding needs reproduction steps, evidence, realistic impact, and a specific fix. A report that says 'implement input validation' helps nobody; one that names the file, the parameter, and the parameterised query to use gets fixed that week.

Good testers read documentation and error messages more than they read exploit code. They ask what the developer assumed, then break that assumption: what if the id belongs to another user, what if the price arrives negative, what if the file is uploaded twice at once, what if I request the endpoint without the UI ever sending me there.

• Testing out of scope. Cloud providers, shared hosts, and third-party SaaS need their own authorisation.
• Running loud scans blindly. A full-rate scan can knock over fragile industrial or embedded devices.
• Depending on automated scanners. They find known patterns. Business logic flaws, the ones that actually cost money, need a human.
• Skipping notes. Log every command and timestamp. Reconstructing a week of work from memory is misery, and clients ask what you did at 14:32.

Build a lab, work through deliberately vulnerable applications, and use platforms that provide legal targets. Then read public bug bounty disclosures, because watching how someone reasoned toward a finding teaches more than any tool tutorial.