What is penetration testing methodology? A practitioner's guide

What is penetration testing methodology? 

A penetration testing (or pen test) methodology is a structured, repeatable framework that governs how ethical hackers plan, execute, document, and report a pen testing engagement. Pen testing itself is an approved simulation of a cyberattack that identifies security gaps.

A pen test methodology doesn’t govern tool selection, exploit choice, or CVE prioritization; those are tester judgment calls. Instead, its purpose is to ensure consistent, defensible coverage by defining four things: what gets tested (scope), in what order (phase sequencing), how evidence is collected (evidence standards), and how findings are communicated (reporting).

Before testing begins, the engagement must be formally authorized through documents such as: 

• Rules of engagement (RoE), which specifies testing boundaries, depth, and methods

• A non-disclosure agreement (NDA), which protects sensitive information

• A statement of work (SoW) which defines testing scope, deliverables, and timeline 

Once these boundaries are in place, the methodology comes next. Four frameworks dominate modern practice, each defining the pen test lifecycle differently.

VM Buyer's Guide

This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.

La tua email di lavoro qui

Download

Four pen testing frameworks, four different scopes

Framework choice is a structural decision that determines which phases, surfaces, and evidence standards are defined versus left to tester judgment. No single framework covers every engagement phase or environment type, which is why mature teams often combine multiple frameworks.

PTES: Lifecycle structure from pre-engagement to report

The Penetration Testing Execution Standard (PTES) is a lifecycle framework, not a technical pen test execution guide. The PTES defines seven sequential phases: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, and Reporting. It emphasizes documenting the entire process from test objectives to scope, discovered vulnerabilities, exploitation attempts (both successful and failed), evidence, and risk ratings to increase the value of findings. 

Since the official standard is static, practitioner-curated resources have become the go-to for translating the high-level phases into actionable workflows. This includes the PTES Field Manual, which provides checklists, tool recommendations, and exploits for various scenarios. 

OWASP WSTG: Test cases for web applications

The OWASP WSTG (Web Security Testing Guide) is structured as 12 testing categories that shape the what, why, when, where, and how of web application testing, from Information Gathering to API Testing, but it does not necessarily depict the general pen test workflow. That structural difference makes it complementary to PTES, not a substitute for it. The OWASP WSTG’s scope is explicitly web application and web services only.

The practical value of the WSTG is its 90+ standardized, auditable test cases. In OWASP WSTG v4.2, those test cases give security teams a stable, referenceable structure for assigning, tracking, and defending web application findings. Every test has a unique identifier, mapped to its testing category and a number value: for example, WSTG-INFO-02 (Fingerprint Web Server, which is part of the Information Gathering category) or WSTG-AUTHZ-02 (Testing for Bypassing Authorization Schema, part of Authorization Testing). Testers use these identifiers to assign, track, and defend findings by test case reference rather than written descriptions.

The OWASP WSTG is updated periodically. Version 4.2 (from 2020) is the current release, while v5.0 is in active development. For stable, traceable reporting, testers should use versioned ID formats (e.g., WSTG-v42-INFO-02, referring to v4.2), as IDs can change between major versions. 

NIST SP 800-115: Prescriptive structure

NIST SP 800-115 defines four phases (Planning, Execution, Post-Execution, Reporting) and has the most prescriptive reporting structure of the four frameworks here. Its detailed risk rating formats satisfy federal compliance frameworks like FISMA and FedRAMP, but they do not translate directly into developer workflows.

NIST SP 800-115 also has a structural limitation; it was published in September 2008, several years before technological shifts like cloud computing, Kubernetes, and the modern API economy. As a result, container attack paths, RBAC misconfigurations, and cloud IAM exploitation aren’t addressed. For any engagement involving Kubernetes or APIs, supplement it with NIST SP 800-190 and NIST SP 800-228. 

MITRE ATT&CK: A TTP (tactics, techniques, and procedures) taxonomy, not a phase-by-phase methodology

MITRE ATT&CK is a behavioral model and knowledge base, not a replacement for a traditional pen test methodology. It classifies what adversaries do and shows how to use that information to trace vulnerabilities, but it doesn’t define pen test workflows like pre-engagement phase, scope, or reporting format. 

MITRE ATT&CK is a behavioral knowledge base, not a lifecycle methodology. The Enterprise ATT&CK matrix organizes adversary behavior into tactics, techniques, and sub-techniques. Because MITRE updates ATT&CK regularly, cite the current stable release at publication time rather than hard-coding version numbers and counts that may change.

Framework comparison table

The table shows structural boundaries, not quality rankings. As we’ve seen, it’s common for teams to adopt a combined-framework pattern: the PTES for lifecycle structure, the OWASP WSTG for web test cases, NIST SP 800-115 for compliance reporting, and ATT&CK for TTP classification. Keep in mind that these four represent the most widely used approaches rather than an exhaustive list. 

Accademia Wiz

Penetration Testing vs Vulnerability Scanning: What's the Difference?

Penetration Testing vs Vulnerability Scanning: Penetration testing simulates attacks to exploit flaws while vulnerability scanning identifies known risks.

Leggi di più

How a pen test actually runs, phase by phase

Based on the combined-framework approach, each phase produces a specific artifact that the next phase requires. Skipping pre-engagement leaves the reconnaissance phase without an authorized target list. Similarly, performing superficial reconnaissance leaves the exploitation phase without a complete attack surface map.

Phase 1: Pre-engagement scoping

Pre-engagement produces a foundational set of agreements, a signed authorization, a defined target scope, a rules of engagement (RoE) document, and a statement of work (SoW) document that authorize and govern every pen test activity that follows. Together, they specify which systems may be tested, the permitted depth of exploitation, data-handling requirements, communication procedures, deliverables, and timelines, preventing gaps that could potentially stop the test mid-engagement.

For cloud-native engagements, the scope should explicitly identify in-scope services, including Kubernetes clusters, API planes, nodes, access controls, and pod escape scenarios. Ambiguous scope could inadvertently exclude attack paths by default, reducing both coverage and confidence in the final assessment.

Phase 2: Reconnaissance

Reconnaissance builds a target profile of exposed assets, services, and technologies and potential entry points. Passive reconnaissance gathers information without interacting with the target, while active reconnaissance probes the target (requiring explicit authorization in the RoE). 

In a Kubernetes engagement, for example, one of the earliest active probes is checking port 6443 to determine whether the API server is reachable. Whether managed or self-hosted, simple unauthenticated GET requests to /api/v1/namespaces can reveal exposed control planes or authentication misconfigurations. But these attack paths only get validated if API probing falls within the SoW.

Phase 3: Scanning and enumeration

Scanning and enumeration build a service inventory, identify candidate vulnerabilities, and rank potential attack paths by exploitability, not CVSS alone. 

Back to the Kubernetes example from Phase 2: In Kubernetes environments, one of the highest-value activities here would be enumerating RBAC permissions, including service accounts, ClusterRoleBindings, wildcard verbs and resources, and namespace scope. 

Because Kubernetes RBAC is purely additive. Permissions can only be granted, never denied—an attacker who compromises a service account bound to a wildcard ClusterRole can inherit broad cluster permissions without exploiting a software vulnerability.

# Example wildcard ClusterRole: exploitable without a CVE
rules:

  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

The exploitation phase validates whether that permission chain can be traversed from an initial foothold to higher privileges or cluster-wide control. You can review how these attack paths extend across container and Kubernetes security surfaces to understand what a full cluster exposure looks like from an attacker's vantage point. 

Phase 4: Exploitation

During this phase, testers validate exploitability. The objective is not to produce a longer list of CVEs, but to demonstrate what an attacker can actually access or escalate. The primary deliverables are proof-of-concept artifacts, including the access obtained, credentials captured, and attack path traversed. 

Consider a pen test for a common Kubernetes privilege escalation chain:

• First prerequisite: An overly permissive binding exists, surfaced during RBAC enumeration in Phase 3. This is the entry condition; without it, the chain does not apply.

• Second prerequisite: The workload is configured to mount a service account token, which allows code running inside the pod to read that token. 

Note: By default, Kubernetes mounts a service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token unless the workload explicitly sets automountServiceAccountToken: false.

• Third prerequisite: Vulnerability exploitation is explicitly permitted in the SoW and RoE.

Escalation steps:

1. The tester reads the token and crafts API server requests authenticated as that identity. The API server treats these requests as legitimate because the token is valid.

2. API server enumeration with the stolen token reveals what permissions that identity actually holds, which are broader than the workload owner intended since this is an over-privileged identity.

3. If the identity can create pods or use RBAC admin verbs, the tester can demonstrate privilege escalation to cluster-admin without any CVE being involved.

4. The same methodology applies to cloud IAM. A compromised workload identity with excessive permissions may allow role assumption, cross-account access, or secrets retrieval without exploiting a single software vulnerability. 

Exploitation ends with testers mapping the validated attack chain to ATT&CK techniques to support detection engineering and coverage analysis. 

Phase 5: Post-exploitation

After proving exploitability, the post-exploitation phase measures the resulting blast radius: what identities can be assumed, which systems become reachable, how far can privileges be escalated, what sensitive assets could ultimately be compromised, and what business processes could be impacted. 

Here’s a Kubernetes example:

1. After compromising a workload via remote code execution inside a running container (this is the critical entry point, and every other step depends on it), a tester may discover that the associated service account can create privileged pods. 

2. If the engagement’s SoW permits, and if cluster configurations allow (e.g., a privileged pod scheduled with a hostPath mount on / gives read/write access), the tester can prove attackers can reach the underlying node’s filesystem.

3. From there, the tester may also demonstrate access to sensitive host resources: e.g., modifying systemd units, or using nsenter to join the host's PID and network namespace.

4. In cloud environments, post-exploitation may also include authorized validation of IAM trust relationships, such as permitted sts:AssumeRole paths between AWS accounts, to determine whether identity-based lateral movement expands the attack’s blast radius.

This workflow is a major point of divergence between pen testing, vulnerability scanning, and red teaming. Vulnerability scanning produces a list of CVEs and misconfigurations. Pen testing demonstrates which risks are actually reachable and their blast radii. Red teaming tests whether detection and response would catch adversaries trying to exploit existing security weaknesses.

Pen tests often stop short of demonstrating impact because many SoWs forbid exploitation or define scope ambiguously. Testers must explicitly confirm expectations for exploitation and post-exploitation depth before testing begins. 

Phase 6: Reporting and remediation

Reporting delivers evidence-backed findings, prioritized by exploitability and business context. Remediation guidance and compliance mapping are other core elements.

Watch 12-min demo

Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.

La tua email di lavoro qui

Watch now

Common pitfalls in pen test methodology selection

Five coverage problems consistently show up in pen test methodology decisions:

• Naming ATT&CK as the engagement methodology. ATT&CK is a TTP taxonomy, not a lifecycle framework. Apply it post-exploitation for classification, and govern the pen test lifecycle with frameworks like the PTES or NIST. 

• Applying the OWASP WSTG to cloud or network engagements. This creates gaps because the WSTG’s taxonomy excludes network and cloud infrastructure risks like lateral movement, infrastructure enumeration, and cloud IAM abuse. Scope the WSTG strictly to web application tests and add the PTES or NIST for other attack surfaces.

• Treating NIST SP 800-115's reporting as remediation-ready. NIST outputs are audit-focused and translate poorly to remediation workflows. Keep them for compliance but build a parallel engineer-friendly translation for remediation teams.

• Not defining exploitation and post-exploitation depth in the SoW. Exploitation and post-exploitation documentation are often lean, primarily because testers default to stopping at initial access when the scope is unclear. Where the scope is ambiguous, testers should seek clarification.

• Even a well-designed, well-run engagement runs into a structural constraint. The pen test is a snapshot of the environment at that time, but in environments shipping code daily, new deployments add containers, RBAC bindings change, IAM policies get modified, and the attack surface shifts continuously. Basically, new gaps emerge very fast. This means organizations must plan for scheduled test cycles and continuous automated testing in between.

Accademia Wiz

What is a penetration testing report? Components and examples

Leggi di più

How Wiz closes the gap between test cycles

Continuous Threat Exposure Management (CTEM) is a framework for validating exploitability between scheduled engagements. Wiz CTEM operationalizes this approach by continuously validating cloud attack paths, ingesting on-prem exposure data via Wiz UVM, and surfacing new exposures as environments change. 

After a scheduled test, Wiz Pen Test Findings correlates external penetration test results with the Wiz Security Graph, providing contextual exploitability analysis and attack path mapping across infrastructure, identity, vulnerabilities, configurations, and runtime behavior.

The Wiz Red Agent, an AI-powered adversarial simulation capability, continuously discovers and validates attack paths across cloud, Kubernetes, and CI/CD environments, surfacing exploitable misconfigurations between scheduled engagements.

See how continuous attack path validation and contextualized pen test findings work in practice.  Request a demo to explore how Wiz helps teams bridge the gap between scheduled engagements.

Uncover Vulnerabilities Across Your Cloud

Stop chasing alerts—Wiz maps your entire cloud to find and prioritize real risks immediately.

E-mail di lavoro*

Nome di battesimo*

Cognome*

Paese

Numero di telefono*

Società*

Tienimi aggiornato sulle versioni dei prodotti Wiz, sulle novità del settore e sugli eventi (puoi annullare l'iscrizione in qualsiasi momento)

Iscrivimi alle e-mail di riepilogo del blog Wiz

Invia

Per informazioni su come Wiz gestisce i tuoi dati personali, consulta il nostro Informativa sulla privacy.

La tua email di lavoro qui

Richiedi una demo

FAQs