Penetration Testing

Penetration Testing and Its Scope

A vulnerability assessment analyzes systems for known weaknesses, configuration issues, and deviations from good practices. Its scope may include many hosts, applications, and devices. The result is a list of potential problems with descriptions, evidence, and severity ratings, for example: "The service uses a version with a published vulnerability," or "The authentication configuration does not meet the required policy." This assessment describes the presence of vulnerabilities, but it does not by itself confirm that a specific attack can succeed.

An organization may need an answer to a different question: "Can a vulnerability be used to reach a defined objective under the assumed attack conditions?"

A penetration test addresses this need through an authorized team of testers. Testers work within an agreed scope and actively check the defenses. They analyze entry points, attempt controlled exploitation, and verify whether they can reach the objective, such as access to a specified server or data. Each attempt should follow rules of engagement, limits on service impact, and a defined method for recording results.

This is the core concept behind a penetration test. It is an authorized attempt to evaluate IT infrastructure by controlled exploitation of vulnerabilities. The result addresses the vulnerability's impact, the conditions required for exploitation, and the resources that can be reached. The test plan should specify objectives, in-scope addresses and applications, timing, permitted techniques, emergency contacts, and stop criteria. The tester records evidence so the result can be reproduced without exposing data that is unnecessary for the assessment.

Pen Test vs. Vulnerability Assessment

Vulnerability assessment and penetration testing have different goals, scopes, and outputs.

A vulnerability assessment aims to provide a broad list of known potential weaknesses across a defined range of systems. Its primary output is a report describing the vulnerabilities, usually with severity ratings. A penetration test is a goal-oriented exercise. The tester may use a vulnerability scan as a starting point and then check whether vulnerabilities can be chained into a path leading to administrative access to a critical server or access to sensitive data.

A vulnerability assessment identifies the presence and nature of a weakness. A penetration test documents a controlled exploitation path, the access obtained, and the impact on the test objective.

Authorization and Tester Roles

Penetration testing is often referred to as ethical hacking. Formal permission from the system owner, a defined scope, and rules of engagement distinguish a test from criminal activity. The cybersecurity community uses a color classification to describe roles and intent:

• White Hat Hackers: These are security professionals working for defensive purposes. A penetration tester works with explicit permission and within a defined scope, then reports results so the organization can fix vulnerabilities before a real attack.
• Black Hat Hackers: These are malicious actors who operate without permission. They break into systems to steal data, disrupt services, or demand a ransom.
• Gray Hat Hackers: These individuals act without authorization, while their stated aim may be reporting a vulnerability instead of causing harm, sometimes for a bug bounty. The lack of permission can make the action unlawful even when the intent is not malicious.

A properly commissioned test is performed by authorized testers under a contract, defined scope, and rules of engagement. Recording the authorization reduces legal and operational risk. The plan should identify target systems, testing windows, permitted techniques, emergency contacts, data-handling rules, and criteria for stopping. This prevents an exploratory action from exceeding the owner's authorization.

Phases of a Penetration Test

A professional penetration test follows a defined methodology. NIST SP 800-115 groups an assessment into planning, execution, and post-execution activities, with techniques covering review, target identification, analysis, and attack validation. The following teaching model presents tester activity in five phases and assumes that rules of engagement were agreed before testing. Planning also covers authorization, scope, communication, and environment preparation. After execution, the team organizes evidence, discusses findings with the system owner, and delivers remediation recommendations.

Phase 1: Reconnaissance

This is the information-gathering phase. The tester confirms the target scope and builds a map of the organization's digital footprint using public sources and permitted system interaction. Reconnaissance includes two types:

• Passive Reconnaissance:Gathering information without directly interacting with the target's systems. This involves using publicly available sources, making it very difficult to detect. Techniques include searching Google for employee names and technology mentions, examining social media profiles, checking job postings for clues about the technologies used, and using tools like WHOIS to find domain registration information and associated IP address ranges.
• Active Reconnaissance:This involves directly probing the target's systems to gather more detailed information. This is noisier and more likely to be detected by security systems. Techniques include port scanning with tools like Nmap to find open services, DNS enumeration to discover subdomains, and banner grabbing to identify specific software versions.

Phase 2: Scanning

Using the reconnaissance results, the tester performs a focused vulnerability scan within the agreed scope and test window. Tools such as Nessus or OpenVAS may be used, followed by manual analysis. The tester selects entry points that matter to the objective, such as an outdated web server, an exposed database, or a misconfigured cloud storage bucket that could provide access to the rest of the network.

Phase 3: Gaining Access (Exploitation)

During this phase, the tester performs controlled attempts to exploit previously identified vulnerabilities and checks whether the access described in the scenario can be obtained. The method depends on the vulnerability and must limit risk to the system. It could involve:

• Network Exploits:Using a framework like Metasploit to launch a known exploit against a vulnerable service running on an open port. For example, exploiting a known vulnerability in Microsoft's Remote Desktop Protocol to gain remote control of a server.
• Web Application Attacks:Exploiting common web vulnerabilities like SQL Injection to manipulate a database, or Cross-Site Scripting (XSS) to steal a user's session cookie.
• Social Engineering: This is a controlled test of the human element. A tester might send an approved phishing email to check whether an employee enters a password on a test page or runs an attachment. The scope should define permitted actions and a stop procedure.

The initial access often consists of only a low-privilege user account.

Phase 4: Maintaining Access

In an attack scenario, maintaining access means attempting to remain present after a user logs off or a system reboots. The tester documents whether persistence mechanisms such as an additional administrative account, a backdoor, or a rootkit would be possible. A controlled test does not install such mechanisms without explicit approval and a rollback plan.

This phase also often involves privilege escalation. The tester will try to exploit local vulnerabilities on the compromised machine to elevate their access from that of a regular user to that of an administrator (root or SYSTEM), giving them complete control over the system.

Phase 5: Detection and Trace Assessment

An attacker may try to remove logs, change timestamps, and hide tools. The tester evaluates this scenario by documenting the logs that would show such activity and checking whether monitoring systems would detect and trace the simulated attack. Deleting logs or modifying systems during a test requires separate approval and a safe procedure.

Black, White, and Gray Box Testing

Penetration tests can begin with different levels of knowledge about the target environment. The terms black box, white box, and gray box describe how much information the tester receives before work begins.

• Black Box Testing:The tester receives minimal information about the target system, such as its name or IP address. They start with limited knowledge, similar to an external attacker. They must perform reconnaissance and service discovery within the agreed scope. This type of test reflects an outside adversary's perspective, but it can take longer and some internal systems may remain outside observation.
• White Box Testing: The tester receives a broad set of information about the target environment, which may include network diagrams, application source code, and administrative credentials. This supports broad testing and helps find vulnerabilities that a black box test might miss. This variant can simulate a threat from a knowledgeable insider.
• Gray Box Testing:The tester receives limited information, such as credentials for a standard user account. This can skip part of the initial reconnaissance and focus work on vulnerabilities available from that user's perspective, such as privilege escalation flaws. The variant combines shorter preparation with a partially external user perspective.

The Penetration Test Report

A penetration test concludes with a report describing its scope, methods, findings, and risk. A detailed report helps the organization plan vulnerability remediation, configuration changes, and detection improvements.

A good report typically includes:

• Executive Summary: A high-level, non-technical overview of the findings, explaining the business risk in terms that management can understand.
• Technical Findings: A detailed, step-by-step narrative of the attack path, explaining which vulnerabilities were found and exactly how they were exploited.
• Evidence: Screenshots, command outputs, and other evidence documenting the test result and access obtained.
• Risk Assessment: Each vulnerability receives a risk rating, for example Critical, High, or Medium. CVSS describes technical severity, while the organization can combine it with the business impact of exploitation.
• Remediation Recommendations: Clear, actionable steps that the organization can take to fix each identified vulnerability.

The report should state the testing dates, scope limitations, evidence sources, affected assets, and a method for confirming remediation. It should distinguish observed access from hypothetical impact and protect credentials, personal data, and other sensitive evidence.

A penetration test shows which attack paths are possible under the defined conditions, what impact they have, and which controls and detection mechanisms require improvement. These findings support remediation priorities. The report should also state test limitations, techniques excluded from the scope, and a recommended retest method. A result does not prove that no other vulnerabilities exist outside the tested scope.