The Pentest Methodology

Penetration testing is not hacking. It looks the same from the outside - someone probing systems, finding weaknesses, gaining access - but the difference is a document. A signed, dated, scope-limited authorization agreement transforms a criminal act into a professional service. This lesson is about that difference, and about the structured process that turns raw technical skill into something clients can actually use.

What a Penetration Test Actually Is

A penetration test is a simulated attack carried out by authorized professionals to discover and demonstrate security weaknesses before real attackers do. The goal is not to cause damage - it is to produce a report that lets the organization fix problems.

This is different from:

• Vulnerability scanning - automated tools identify potential weaknesses, but don't exploit them to confirm impact
• Red team exercises - longer-duration, broader-scope engagements that simulate a full threat actor over weeks or months
• Bug bounty hunting - crowd-sourced security research under vendor-defined rules, often with legal safe harbors
• Capture The Flag (CTF) - purpose-built competitions with intentionally vulnerable systems, no authorization concerns

A pentest sits in the middle: more thorough than a scan, more contained than a red team, professional in its output.

The Professional Mindset

Before the phases, the mindset:

You are a consultant, not an attacker. Your client hired you to make them more secure. Every action you take should serve that goal. Causing unnecessary damage, accessing data beyond what's needed to demonstrate a finding, or going outside agreed scope - even accidentally - is a failure, not a success.

Documentation is not optional. Document everything in real time. Screenshots, timestamps, tool output, commands run, IPs accessed. If a client's database goes down during your test and they blame you, your logs prove what happened. If you find critical data exposure and report it without evidence, the finding is worthless.

"I could have done more" is not a metric. A successful test demonstrates representative risk at the agreed scope. It is not a competition to achieve maximum access. If you hit your objective (demonstrated access to in-scope systems, found critical vulnerabilities), you report it and stop.

Protect what you find. Credentials, PII, intellectual property, health records - you will encounter sensitive data during tests. Access only what you need to demonstrate a finding. Never copy sensitive data off the client's systems unnecessarily. Treat it as you'd want your own data treated.

Phases of a Penetration Test

The industry has converged on a roughly standard set of phases. Different frameworks (PTES, OWASP Testing Guide, NIST SP 800-115) use different names, but the structure is consistent.

Phase 1: Pre-Engagement

Before a single packet is sent, you establish the rules of the game.

Scoping defines what is and is not in scope. This is negotiated between you and the client and results in a written document. A scope document answers:

• Which IP ranges, domains, and applications are in scope?
• Which are explicitly out of scope (production databases, payment systems, third-party SaaS)?
• What types of testing are authorized? (Network, web app, social engineering, physical?)
• What are the test dates and windows? (Business hours only? Can you run tests at 3 AM?)
• Who is the emergency contact if something breaks?

Rules of Engagement (RoE) go deeper than scope:

• Are denial-of-service conditions allowed? (Usually no.)
• Can you access discovered credentials and authenticate to additional systems?
• Do you need to stop and report critical findings immediately, or document and continue?
• Is there a "get out of jail free" letter you carry? (A document proving your authorization, given to law enforcement if needed.)

Legal agreements round out pre-engagement: Non-Disclosure Agreement (NDA), Statement of Work (SoW), and the actual authorization letter. Get these signed before anything else.

Phase 2: Reconnaissance

Reconnaissance is information gathering. The goal is to build a map of the target - systems, services, technologies, people, and relationships - before touching anything.

Passive reconnaissance involves gathering information without directly interacting with the target's systems. WHOIS lookups, DNS queries to public servers, Certificate Transparency logs, Google dorking, LinkedIn profiling - all of this is invisible to the target.

Active reconnaissance involves probing the target directly: DNS zone transfers attempted against their nameservers, sending packets to their IP ranges, interacting with their web servers. This leaves traces. You do this only after the engagement begins.

The recon phase feeds directly into scanning: you're building a target list, mapping the attack surface, and identifying technologies that will inform your vulnerability research.

Phase 3: Scanning and Enumeration

Armed with a target list, you now map the exposed services. Port scanning identifies what's listening. Service enumeration identifies what is listening - versions, banners, configurations. Vulnerability scanning cross-references services against known vulnerability databases.

This phase answers: "What can I reach, and what is running on it?"

Phase 4: Exploitation

Exploitation converts discovered vulnerabilities into demonstrated access. You use exploits, misconfigurations, weak credentials, or logic flaws to gain a foothold - a shell, a session, an authenticated context - in the target environment.

This is the phase with the most risk of unintended damage. Mature testers:

• Test exploits in a lab environment first when possible
• Use the least-destructive exploit that demonstrates the finding
• Avoid running rm -rf, formatting drives, or crashing services unnecessarily
• Stop and document rather than continuing blindly after gaining access

Phase 5: Post-Exploitation

After gaining initial access, you assess what an attacker with that foothold could do. Situational awareness, privilege escalation, lateral movement, credential harvesting, data access - all of this determines the actual business impact of the vulnerability you found.

This phase answers: "How bad would this be in a real breach?"

Phase 6: Reporting

The deliverable. Everything you found, presented clearly for two audiences: the technical team who needs to fix things, and the executives who need to understand business risk.

A good report includes:

• Executive summary (risk level, top findings, business impact)
• Technical findings (vulnerability details, reproduction steps, evidence)
• Remediation recommendations (prioritized, actionable)
• Methodology appendix

Without this, the test accomplished nothing. Findings that can't be communicated can't be fixed.

Phase 7: Remediation Support (Optional but Professional)

Many engagements include a re-test after the client implements fixes, confirming that the vulnerabilities were actually remediated. Some testers offer advisory time during the remediation period.

Scoping in Practice

Common scoping decisions and their implications:

Scope Decision	Implication
"All IPs in 10.0.0.0/24"	Test every host in that subnet
"Exclude 10.0.0.50 (prod DB)"	Document that host as out-of-scope if found
"Web app at app.client.com"	That domain only - not subdomains unless stated
"No social engineering"	Phishing and pretexting are off limits
"No DoS testing"	Do not run exploits that crash services
"Business hours only (09:00-17:00)"	No scans or exploitation outside those hours

When you discover something outside your scope - say, a linked subdomain that looks vulnerable - you document it and report it, but do not test it. Scope creep without authorization is still unauthorized access.

Methodologies and Frameworks

Several established frameworks provide structured guidance:

PTES (Penetration Testing Execution Standard) - Defines seven stages of a pentest with detailed technical guidelines. A widely used reference.

OWASP Testing Guide - Focused on web application testing. Extensive, freely available, updated regularly.

NIST SP 800-115 - US government technical guide to information security testing. More conservative, used heavily in compliance-focused engagements.

MITRE ATT&CK - A framework of adversary tactics, techniques, and procedures mapped from real-world threat intelligence. Used for red team exercises and gap analysis.

None of these is a cookbook. They're reference materials. Real professionals internalize the principles and adapt to the engagement.

Ethics Beyond Legality

Authorization makes pentesting legal. Ethics makes it professional.

Some things are legal within scope but still wrong:

• Accessing personal email found in a compromised mailbox
• Exfiltrating medical records to "prove you can"
• Sharing client vulnerabilities with third parties
• Publishing findings without client consent

The legal boundary and the ethical boundary are not the same line. The best security professionals treat client systems with the care they'd want applied to their own.

Key Takeaways

• A signed, written authorization document is what separates penetration testing from criminal hacking. Never operate without one.
• The seven phases - pre-engagement, recon, scanning, exploitation, post-exploitation, reporting, and optional remediation - provide a professional structure for consistent, defensible work.
• Scope creep is unauthorized access, even if the primary client authorized the test.
• Third-party infrastructure (cloud providers, CDNs, SaaS) requires its own separate authorization.
• The deliverable is the report. Access without documentation is worthless to the client.
• Ethics goes beyond legality. Treat everything you encounter with care proportional to its sensitivity.