Penetration Testing Methods: A Practical Reference

What Penetration Testing Covers

Penetration testing is the practice of simulating attacks against a system in order to find weaknesses before someone with harmful intent does. A penetration tester works like an attacker, but within a defined agreement with the owner of the system. The goal is not to cause damage or prove that an organization can be broken for its own sake. The goal is to show which weaknesses can actually be exploited, how far an attacker could go, and what should be fixed first.

The work overlaps with related disciplines but is not identical to them. Vulnerability assessment usually identifies and ranks weaknesses without confirming that they can be used to gain access. Red teaming usually tests detection and response across a broader campaign, often with less visibility given to the defenders. Penetration testing sits between these, focusing on confirmed exploitation within a bounded target and timeframe.

Penetration testing is authorized, bounded and documented simulated attack, not unplanned intrusion.

Professional certifications describe the same core skills from different angles. The CompTIA PenTest+ exam covers planning and scoping, reconnaissance, vulnerability analysis, exploitation, post-exploit tasks and reporting. The EC-Council Certified Ethical Hacker program covers reconnaissance, scanning, enumeration, system attacks, web application security and cloud computing. Both reflect the same underlying idea: testing is a set of disciplined activities, not a single tool or trick.

A useful way to hold the whole subject in mind is as a set of overlapping circles: the method used, the target tested, and the authorization that makes the work lawful. Each part depends on the others, and each must be documented.

Levels of Testing Structure

Penetration testing is organized in layers. At the top is the reason for the test, usually a business or compliance need. Below that are the frameworks that define how the test is performed. Under the frameworks sit the techniques, tools and procedures that a tester uses on a given day. Understanding this structure helps a learner see why a good test is more than running a scanner.

Frameworks such as PTES, the OWASP Web Security Testing Guide, NIST SP 800-115 and OSSTMM provide shared vocabulary and expected coverage. They describe phases, deliverables and common checks. A tester who follows a framework can explain what was tested, why it was tested, and what was left out, which makes the results defensible.

A test is only as defensible as the framework and documentation behind it.

The lower layers are where skill is built. Tools such as port scanners, proxies and exploitation frameworks are only instruments. What matters is the judgment behind their use: choosing a relevant check, interpreting a result correctly and knowing when a finding is real.

Think of the structure as a pyramid. Business purpose rests on a framework, which rests on practiced technique, and the tools sit at the base. Weakness at any level weakens the whole test.

The Testing Improvement Loop

Penetration testing is rarely a single event. Organizations usually repeat tests as systems change, new vulnerabilities appear and controls are updated. The loop of planning, testing, reporting and remediation gives the work its continuing value. Each completed loop should leave the target in a better-understood state than before.

The loop begins with planning, where scope, objectives and rules are agreed. The tester then tests, moving through reconnaissance, analysis and exploitation within the agreed limits. Findings are recorded and communicated in a report. Owners then fix the weaknesses, and the next test checks whether the fixes hold.

Testing is a cycle, and retesting after remediation is what proves a fix works.

Breaking the loop at any point weakens the result. A test without a clear plan drifts out of scope. A test without a report produces no lasting benefit. A report without follow-up leaves the same weaknesses in place. Learners should treat the cycle as the unit of work, not any single action inside it.

Retesting closes the loop. A fix that was never verified is only an assumption, and verification is one of the most valuable services a tester provides.

Standard Engagement Workflow

A penetration test follows a workflow that moves from preparation to delivery. Although the names of stages vary between frameworks, the sequence is consistent. Work begins before any target is touched, with a conversation about purpose, boundaries and the people who must be in formed. Only after these are settled does technical work begin.

The middle of the workflow is technical. The tester gathers information, identifies weaknesses, attempts exploitation where permitted, and records what was achieved. Every step should be logged, because the log supports the final report and protects both the tester and the client if questions arise later.

Every engagement moves in order from agreement, to technical work, to documented delivery.

The workflow ends with delivery. A report explains the work, lists findings with evidence, rates their significance and recommends remediation. A debrief helps the client understand the results. Good engagements close with cleanup, meaning removal of test accounts, tools and artifacts left on systems.

Learners can remember the workflow as a simple chain of stages: prepare, investigate, attack within limits, and then document and hand over the results.

Knowledge Level Explained

The first major classification of testing methods is by how much the tester knows about the target before testing begins. This is often called the knowledge level. It shapes how the test is run, how much time is spent on discovery, and what kinds of weaknesses are likely to be found.

Black-box testing starts with no internal information. The tester is given only a name, an address or an application entry point, much like an outside attacker would be. White-box testing gives the tester full access to source code, architecture documents, configurations and credentials. Gray-box testing sits between these, usually offering partial knowledge such as a user account or a network diagram.

Black-box, white-box and gray-box describe how much the tester knows before starting.

Each knowledge level answers a different question. Black-box work asks what an outsider could achieve. White-box work asks whether the internal design is sound. Gray-box work is often the most efficient, because it tests realistic access paths, such as a low-privilege user escalating to administrator.

Knowledge level is a choice made during planning, not a fixed property of the tester. The right level depends on the question the client needs answered.

Comparing Knowledge Levels

Each knowledge level has characteristic strengths and costs. Black-box testing is realistic about external exposure and mirrors the first steps an attacker would take, but it can spend much of its time on discovery and may miss deep design flaws. White-box testing is thorough and efficient at finding logic errors, insecure code and misconfigurations, but it does not directly show how an outsider would reach those weaknesses.

Gray-box testing often gives the best balance for many engagements. Limited credentials or documentation save discovery time while still preserving a realistic attacker perspective. Because the tester can reach deeper parts of the system, the work tends to reveal privilege escalation and lateral movement that black-box work might not reach in the same time.

Gray-box often balances realism and efficiency, but the best choice depends on the question asked.

Cost, timeline and the skill required also differ. White-box engagements demand experienced reviewers who can read code or architecture quickly. Black-box engagements demand patience and strong reconnaissance. Gray-box engagements demand planning to decide which access to provide.

The chart below compares typical emphasis in rough terms. These values are illustrative, intended to show relative focus rather than measured results.

Phases of a Test

A penetration test is commonly divided into phases. The phases are not rigid boxes; testers often loop back when new information appears. Still, naming them gives everyone a shared map. The frameworks generally include pre-engagement, reconnaissance, scanning, vulnerability analysis, exploitation, post-exploitation and reporting.

Pre-engagement is where scope, rules of engagement, contacts and timing are agreed. Reconnaissance gathers information about the target, actively or passively. Scanning identifies live hosts, open ports and running services. Vulnerability analysis matches discovered services and configurations against known weaknesses and confirms likely candidates.

Phases give structure, but skilled testers move between them as evidence develops.

Exploitation attempts to use confirmed weaknesses to gain access, within the agreed limits. Post-exploitation considers what an attacker could do after gaining access, such as moving to other systems or reaching sensitive data, again within agreement. Reporting then records everything in a form the client can act on.

The timeline below shows the sequence in simplified form. In practice, phases overlap and repeat as the tester learns more.

Scope and Rules Matrix

Scope determines what may be tested and how. Rules of engagement set limits on techniques, timing, data handling and communication. A matrix helps planners compare options before committing. Rows represent test targets, and columns represent aspects of the agreement. Ratings in the matrix reflect the level of care or documentation each option typically needs: 1 for low, 2 for moderate and 3 for high.

Web applications often need careful handling of user data and session behavior. Network infrastructure tests may disrupt live services if scanning is aggressive. Social engineering tests involve people and need clear rules about what staff may be told and when the test becomes known.

Scope and rules must be written down, because anything outside them is unauthorized.

The matrix is a planning aid, not a score of risk. Its purpose is to show where extra documentation and coordination are required before work starts. Scope changes during a test, known as scope creep, should be documented and approved rather than absorbed quietly.

Clear, written boundaries protect both the client and the tester. Anything outside them is unauthorized, regardless of intent.

Frameworks in Practice

Frameworks turn an informal probe into a repeatable process. PTES, the Penetration Testing Execution Standard, describes stages from pre-engagement through reporting and gives guidance on each. The OWASP Web Security Testing Guide focuses on web applications and lists specific test cases grouped by category. NIST Special Publication 800-115 offers guidance on planning and conducting technical security tests, with an emphasis on documentation and government-aligned practice. OSSTMM, the Open Source Security Testing Methodology Manual, emphasizes measurable operational security and results that can be verified.

Using a framework does not remove the need for judgment, but it does provide a checklist of expected coverage. A tester who consults a framework can show that common areas were considered and explain any that were excluded. This is valuable when results are challenged or when the same test must be repeated.

A framework gives a test repeatable coverage and a shared vocabulary.

Frameworks also help teams communicate. When a client, a manager and a tester all refer to the same stage names, planning meetings and reports become clearer. Learners should become familiar with at least one general framework and one domain-specific guide.

The mindmap below shows how the main concerns of a framework relate to one another. Each branch is a topic a well-documented test should address.

Scope of Coverage Splits

Testing methods are also classified by target. Network tests examine hosts, services and the paths between them. Web application tests examine behavior of application code, sessions, inputs and access controls. Cloud tests examine identities, storage, configuration and interconnected services. Social engineering tests examine human behavior and processes. Operational technology tests examine industrial control environments, where safety and availability are critical.

Each target category emphasizes different skills and different risks. A network test may focus on segmentation and patch levels. A web test may focus on input handling and authentication. A cloud test may focus on misconfigured permissions. Social engineering focuses on verification procedures and staff awareness. Operational technology work requires extra caution because a disruptive action can have physical consequences.

Target category determines which skills, risks and precautions dominate the work.

Real engagements often combine categories. A cloud-hosted web application may involve web, cloud and identity testing in the same project. Planners should decide which categories are in scope before work begins.

The donut below shows an illustrative division of effort across target categories in a mixed engagement. The shares are not measured data and should be read as an example of how planning might be split.

Network and Host Methods

Network penetration testing begins with understanding what is reachable. Testers identify live hosts, open ports and running services, then determine how each service responds. Enumeration goes further, extracting details such as user names, share names, software versions and configuration hints that help determine whether a weakness applies.

Once services are known, analysis matches them to likely weaknesses. Confirmation is essential: a version number that appears vulnerable may be patched or configured differently. A tester verifies before reporting, so that the client can rely on the findings.

Network testing confirms reachability, then verifies that discovered services are truly weak.

Host-based testing examines individual systems. It may involve checking patch status, local privilege settings, stored credentials and security controls. Lateral movement, where a tester moves from one compromised host to another, is tested to show how far an intrusion could spread within a segmented network.

Methods in this area are often described as a set of overlapping techniques. The diagram shows how the main concerns relate to each other when a network is assessed.

Web Application Methods

Web application testing focuses on how software responds to unexpected or malicious input. Testers examine forms, query parameters, headers, cookies and API calls. They look for weaknesses such as broken authentication, injection flaws, insecure session handling and missing access checks. The OWASP Web Security Testing Guide organizes these checks into categories that cover the whole application lifecycle.

A common approach moves from mapping to probing. The tester first identifies the application structure, including pages, endpoints and user roles. Then they test each input and control, comparing responses to expected behavior. Authentication and authorization checks deserve special attention because small errors can expose data across users.

Web testing combines broad automated coverage with manual analysis of business logic.

Web testing also uses both automated and manual techniques. Automated tools cover broad surface quickly, while manual testing examines logic that a tool cannot judge, such as whether a business process can be abused. Good testers combine both and document which findings required human judgment.

The pyramid below shows a common hierarchy of web test depth, from broad surface scanning at the base to targeted logic analysis at the top.

Repeating the Method Cycle

Many methods follow a repeating cycle rather than a single straight path. Assessment identifies weaknesses, planning chooses which ones to pursue and how, treatment attempts or applies the appropriate test action, and review confirms the outcome. The cycle then begins again as new information emerges. This pattern fits both technical probing and the wider security program the test supports.

In a penetration test, the cycle might repeat several times within one engagement. A tester who gains a foothold on one host may return to reconnaissance with new information, then plan a second attack path. Each pass should narrow uncertainty and produce documented evidence.

Methods repeat in cycles, and each pass should narrow uncertainty within agreed limits.

The cycle also applies across engagements. Findings feed remediation, and remediation feeds the next test plan. Learners should avoid treating each test as isolated; the cycle connects them into a program.

Recognizing the cycle helps testers pace their work. Stopping after one pass may leave important paths untested, while endless repetition can exceed the agreed time and scope.

Exploitation Process Steps

Exploitation is the stage where a confirmed weakness is used to gain some level of access. It is the most sensitive part of the test, so it follows strict controls. Before exploitation begins, the tester checks that the target and technique are within scope and that the expected impact is acceptable to the client.

The process is deliberately measured. The tester chooses the least disruptive method that proves the weakness, often a read-only check before any change. Each attempt is logged with time, target and outcome. If a service becomes unstable, the tester stops and reports the problem immediately rather than continuing.

Exploitation proves a weakness with the least disruptive method, then records and cleans up.

Exploitation ends with a clear result. The tester records what access was gained, what data or privilege was reachable, and how the finding could be reproduced. Where access was gained, cleanup follows, removing any test artifacts before the next phase.

Diagrams of this process help learners remember its order. The steps below show the controlled path from validation to documented evidence.

Information Gathering Flow

Reconnaissance is the first technical phase and shapes everything that follows. Passive reconnaissance collects information without touching the target directly, such as reviewing public records, documentation, search results and open-source data. Active reconnaissance interacts with the target, such as scanning or probing services. The choice between them depends on what is permitted and how much noise the client accepts.

Gathered information feeds directly into planning. Names of technologies suggest which weaknesses to check. Staff roles suggest social engineering targets. Network ranges indicate where scanning should concentrate. A tester who gathers well avoids wasting time on irrelevant checks.

Reconnaissance should narrow the test to relevant, permitted targets before any deeper action.

Records of what was gathered, and how, also matter for the report. Clients should know which sources were consulted and whether any information was obtained in a way they would want to restrict.

The flow below shows the typical movement from collecting information to deciding what to test next.

Evidence Comparison Bars

Testing methods can be compared by the type of evidence they tend to produce. Scanner output is broad but often needs verification. Manual exploitation produces strong proof but covers less ground. Code review produces precise findings but depends on the completeness of the code provided. Documentation review produces findings about process and policy, which are harder to demonstrate technically.

A balanced test uses several methods so that each covers the others' weaknesses. A reviewer comparing the methods should ask how confirmed each finding is and how much effort was needed to confirm it. The chart below shows an illustrative comparison of how much each method's output required manual verification. It is an example for discussion, not a measured result.

Each method produces different evidence, so reports should state how each finding was confirmed.

Good reports state the method behind each finding. This allows readers to judge confidence and decide how urgently to act.

Engagement Timeline Example

Penetration tests run on timelines that must be planned in advance. A typical engagement begins with preparation, followed by testing windows agreed with the client, then analysis and report writing. Some tests run continuously across weeks, while others are short and focused. The timeline should include time for retesting after fixes, which is often overlooked.

Timelines also must account for coordination. Testing may need approval from system owners, notice to monitoring teams and agreed contact points for emergencies. Sensitive activities such as social engineering may be scheduled to avoid disrupting operations.

A realistic timeline includes coordination, interim checkpoints and time for retesting.

Clear milestones help manage the work. Milestones might include scope approval, testing start, interim check-in, draft report and final briefing. Each milestone gives both sides a chance to correct course before problems grow.

The timeline below shows a simplified example of milestones in a typical engagement.

Cloud Testing Decision Matrix

Cloud environments change the testing method in important ways. Responsibilities are divided between the provider and the customer, and the provider usually limits what may be tested on shared infrastructure. Testers must read the provider's testing policy before starting, because some activities that are permitted on one service may be prohibited on another.

Cloud tests often focus on identity, storage, configuration and interconnected services. Misconfigured permissions, publicly exposed storage and weak identity controls are common areas. Testers also examine how workloads communicate and whether segmentation between cloud accounts is sound.

Cloud testing depends on shared responsibility and provider policy as much as technical method.

The matrix below compares typical emphasis across cloud and other environments. Rows are environment types and columns are considerations. Ratings are 1 for low, 2 for moderate and 3 for high concern.

Planners should involve both the cloud account owner and any relevant provider policy before testing begins, because cloud actions can affect shared resources and billing.

Social Engineering Variant Map

Social engineering tests examine how people and processes respond to manipulation. The tester may attempt to obtain information, persuade staff to perform actions, or by pass procedures through deception. These tests are valuable because human behavior is often a path into systems that technical controls protect.

Common variants include phishing, which uses messages to prompt action; pretexting, which builds a believable scenario to gain trust; and physical assessments, which test access controls at facilities. Each variant needs explicit authorization, clear rules about personal data and an agreed process for stopping the test if a person becomes distressed.

Social engineering tests should measure processes and awareness, never punish individuals.

Social engineering results should focus on processes rather than blame. A staff member who fell for a test should be supported with training rather than punished, because punishment discourages reporting. Good reports describe the weakness in the procedure that allowed the deception.

The mindmap below shows how the main social engineering variants relate to one central concern.

Reporting and Metric Shares

Reports translate testing work into decisions. A strong report includes an executive summary for leaders, technical detail for administrators, and a list of findings with evidence and recommended fixes. Each finding should state how it was confirmed and how severe its impact would be if exploited.

Metrics help track improvement across tests. Common measures include the number of findings by severity, the time taken to fix confirmed issues and the share of findings that were retested successfully. Metrics should be used carefully, because counting findings alone can reward noise rather than value.

Reports should explain how each finding was confirmed and why its severity was rated as it was.

Severity ratings are often based on a standard scoring system and adjusted for context. A critical finding on an isolated system may be less urgent than a moderate finding on an internet-facing service holding sensitive data. Reports should explain these judgments.

The donut below shows an illustrative distribution of findings by severity in a sample report. The values are an example for teaching and are not measured results.

Authorization and Legal Boundaries

Authorization is the foundation of lawful penetration testing. Written permission from the owner of the systems, along with a clear scope document, establishes what is allowed. Without it, the same technical actions can constitute unauthorized access, regardless of the tester's intent. Learners should treat authorization as the first item in every plan, not an administrative afterthought.

Authorization documents usually name the systems in scope, the methods permitted, the testing window and the contacts to reach during the test. They also state what is excluded, such as third-party services or production data. Testers should confirm that the person signing has the authority to grant access to each system.

Written authorization and a clear scope are what make a penetration test lawful.

Some activities carry additional legal and ethical concerns, including handling personal data discovered during testing and reporting vulnerabilities in systems owned by others. Responsible practice limits data access to what is necessary and handles discoveries under agreed disclosure rules.

The Certified Lead Ethical Hacker and CEH programs both place ethics and authorized practice at the center of professional conduct. Learners should build this habit from the start.

Pyramid of Test Maturity

Some organizations progress through stages of testing maturity over time. Early stages may rely on basic vulnerability scans and limited manual checks. Mature programs combine regular testing, defined methods, skilled testers, documented retesting and metrics that show improvement across cycles.

Reaching higher maturity requires investment in people and process as well as tools. Teams should establish a repeatable framework, train testers in its use and keep records that allow comparison between tests. Learners who understand this progression can place a given test in context and suggest realistic next steps.

Maturity grows as tests become repeatable, documented and linked to measurable improvement.

The pyramid below shows the stages in simplified form, from ad hoc checks at the base to continuous improvement at the top.

Practice Review Cycle

Learning penetration testing methods is an ongoing practice. A learner should repeat a cycle of study, practice on authorized environments, review what was missed and study again. Authorized practice environments, such as those offered by training providers, let learners apply methods safely without any risk to real systems.

Review is essential. After each practice exercise, a learner should compare their notes with a framework checklist, identify steps that were skipped, and consider whether the evidence supports each conclusion. Writing a short report for each exercise builds the communication skills that employers value.

Authorized practice followed by honest review builds lasting penetration testing skill.

The cycle keeps learning grounded. Each pass should leave the learner with a clearer picture of how the phases connect and where judgment matters most.

The cycle below summarizes the practice loop a learner can follow repeatedly.

Final Process Summary

This reference has described penetration testing methods from several angles. The discipline is defined by authorization and bounded scope. Tests are classified by knowledge level as black-box, white-box or gray-box, and by target as network, web, cloud, social or operational technology. Frameworks such as PTES, OWASP, NIST SP 800-115 and OSSTMM give structure, while the phases of a test move from pre-engagement through reporting.

Automation supports the work but has clear limits. Tools broaden coverage and speed discovery, yet they cannot judge business logic, confirm every finding or understand context. Human verification remains necessary, and reports must say how each finding was confirmed.

A complete test runs from agreed scope through verified remediation, always within authorization.

A complete test ends with documented results, remediation guidance and retesting. Treat the process as a cycle, and remember that authorization comes first in every step.

The final process below summarizes a complete engagement from agreement through verified remediation.