Penetration Testing Basics

A penetration test is an authorized, simulated attack against a system to find what's actually exploitable. Not what's theoretically vulnerable — what an attacker could realistically leverage to cause damage. The key word is "authorized." Testing without explicit, written permission is a crime, full stop. There's no gray area.

Scope and Authorization First

Before any testing begins, you need a signed scope document that defines exactly what's in bounds and what isn't. Which systems, which IP ranges, which applications, what time windows, what's explicitly off-limits.

This document is your legal protection. It should be signed by someone with actual authority to authorize the testing — typically a CTO, CISO, or VP of Engineering. "My manager said it was fine" doesn't hold up when you accidentally take down a production database. The scope should also specify notification procedures (who to call if something breaks) and data handling rules (what happens to any sensitive data the tester discovers).

If you're testing a cloud-hosted application, check the cloud provider's policies. AWS, GCP, and Azure all have rules about authorized testing against resources hosted on their infrastructure. Some require pre-notification.

Types of Testing

Black box: The tester has no prior knowledge of the system. No source code, no architecture diagrams, no credentials. This simulates an external attacker and tests your perimeter defenses. It's realistic but time-consuming, since the tester spends significant effort on reconnaissance that an insider could skip.

Grey box: The tester has partial knowledge — maybe standard user credentials, API documentation, or network diagrams. This balances realism with efficiency. Most engagements are grey box because pure black box testing burns time on things that aren't the point.

White box: The tester has full access to source code, architecture diagrams, and credentials at various privilege levels. This maximizes coverage and finds the deepest vulnerabilities but doesn't simulate a realistic attack scenario. Think of it as a very aggressive code review with exploitation.

Red Team vs. Pentest vs. Vulnerability Scanning

These terms get mixed up constantly.

Vulnerability scanning is automated. You point a tool (Nessus, Qualys, OpenVAS) at your infrastructure and it checks for known vulnerabilities — missing patches, default configurations, exposed services. It's fast, cheap, and catches the low-hanging fruit. It also produces false positives and can't chain vulnerabilities together.

Penetration testing is manual, targeted, and tries to actually exploit vulnerabilities. A pentest proves something is exploitable, not just theoretically vulnerable. A scanner might flag a service as "potentially vulnerable to CVE-2024-1234." A pentester confirms whether they can actually leverage that into a shell.

Red teaming is adversary simulation — a broader, longer-term engagement where the team simulates a real attacker with specific objectives (exfiltrate customer data, gain domain admin access). Red teams use social engineering, physical access, phishing, and custom tooling. The goal isn't to find every vulnerability; it's to test your detection and response capabilities against a realistic threat.

Methodology Phases

Professional penetration testing follows a structured methodology. The most widely referenced are PTES (Penetration Testing Execution Standard) and the OWASP Testing Guide for web applications.

Reconnaissance. Gather information about the target. Passive recon uses public sources — DNS records, WHOIS, certificate transparency logs, LinkedIn profiles, GitHub repos, job postings that reveal tech stacks. Active recon directly probes the target — port scanning, service fingerprinting, directory enumeration. The line between recon and scanning is blurry.

Scanning and enumeration. Map the attack surface in detail. Which ports are open? What services and versions are running? What web application endpoints exist? What authentication mechanisms are in place? Tools like nmap for network scanning and Burp Suite for web application analysis live here.

Exploitation. Attempt to exploit discovered vulnerabilities. This might be a SQL injection that dumps the database, a deserialization vulnerability that gives remote code execution, or a misconfigured S3 bucket that exposes sensitive data. Metasploit is the well-known exploitation framework, but experienced testers often use manual techniques and custom scripts. The goal is to prove impact, not just demonstrate a proof-of-concept.

Post-exploitation and lateral movement. Once initial access is gained, what else can the attacker reach? Can they pivot from the compromised web server to the internal network? Can they escalate from a standard user account to administrator? Can they access other systems, databases, or credentials? This phase reveals the real blast radius of a vulnerability.

Reporting. The report is the actual deliverable. Not the exploitation — the report. It should include an executive summary for leadership, detailed technical findings with reproduction steps, evidence (screenshots, logs, request/response captures), severity ratings, and specific remediation recommendations. A pentest that finds critical vulnerabilities but produces a vague report has failed at its primary job.

Common Tooling Categories

You don't need to master every tool, but you should understand what each category does:

• Network scanning: nmap — port discovery, service identification, OS fingerprinting
• Web application testing: Burp Suite — proxy, scanner, and manual testing toolkit for HTTP traffic
• Exploitation frameworks: Metasploit — known exploit modules, payload generation, post-exploitation
• Credential testing: Hydra, hashcat — brute force and password hash cracking
• OSINT: Shodan, theHarvester — internet-wide scanning data and public information gathering

Tools are means, not ends. A skilled tester with a browser and curl will find things that an unskilled operator running every tool in Kali Linux will miss.

Point-in-Time Snapshot

A pentest tells you your security posture on the day the test was conducted. New code deploys the next week. Infrastructure changes the week after that. A vulnerability the pentest didn't find might be introduced tomorrow. This is why a single annual pentest is necessary but not sufficient.

Bug bounty programs provide continuous coverage. Platforms like HackerOne and Bugcrowd let external researchers test your systems year-round. The economics work differently — you pay per valid finding, so you only pay for results. Bug bounties complement periodic pentests, they don't replace them.

Real-World Reality

Here's the unglamorous truth about pentest findings: most of them are boring. The critical finding is usually default credentials on an internal admin panel, not a zero-day exploit chain. Missing patches on internet-facing services. An S3 bucket with public-read ACL. Overly permissive IAM roles. Hardcoded API keys in a public GitHub repository. An admin interface with no authentication that was "only supposed to be internal."

These mundane issues are what actually get exploited in real breaches. The sophisticated, nation-state-level exploits exist, but the vast majority of breaches start with something embarrassingly simple. A good pentest confirms this and makes it impossible to ignore.

Key Takeaways

• A pentest is an authorized simulated attack — written scope and signed authorization are non-negotiable legal requirements.
• Grey box testing (partial knowledge) offers the best balance of efficiency and realism for most engagements.
• The report is the deliverable, not the exploitation. Clear findings, reproduction steps, and remediation guidance are what drive actual security improvement.
• Pentesting is manual and proves exploitability; vulnerability scanning is automated and flags potential issues; red teaming simulates a real adversary over an extended engagement.
• A pentest is a point-in-time snapshot. Bug bounty programs provide continuous testing between formal engagements.
• Most critical findings are mundane — default credentials, missing patches, and misconfigured access controls, not exotic zero-days.

Next up: AI Security Risks — the genuinely new attack surfaces introduced by LLM applications.