Lab 04 — Network Exploitation and Post-Exploitation

Mission Information

Difficulty: Intermediate
Estimated Time: 90–120 minutes
Lab Type: Network Penetration Testing
Primary Focus: Exploitation Validation, Post-Exploitation, Evidence Collection, Reporting
Environment: Isolated and explicitly authorized lab network

Mission Objective

In this lab, you will continue from network discovery and vulnerability validation into the exploitation and post-exploitation phases of a penetration test.

Your objective is not simply to “gain access.” You will learn how a professional penetration tester determines whether a validated weakness can produce meaningful business impact, what an attacker could potentially access after compromise, and how to document that exposure safely.

By the end of the lab, you should be able to describe the complete attack path:

Discovered Service → Validated Weakness → Controlled Exploitation → Initial Access → Post-Exploitation Assessment → Impact Analysis → Remediation

Scenario

Your organization has provided you with an isolated penetration-testing environment containing several intentionally vulnerable systems.

Earlier reconnaissance identified a target system exposing multiple network services. Vulnerability analysis indicates that at least one service may contain a weakness capable of providing unauthorized access.

You have now received authorization to validate the vulnerability.

Your engagement rules permit controlled exploitation and limited post-exploitation activity but prohibit destructive actions, persistence, unnecessary data collection, and disruption of services.

You are acting as the penetration tester responsible for proving the security impact and producing evidence suitable for the final assessment report.

Learning Outcomes

After completing this lab, you should understand how to:

• Validate whether a discovered vulnerability is genuinely exploitable.

• Select an appropriate exploitation approach.

• Establish controlled initial access.

• Confirm the security context obtained after exploitation.

• Identify exposed users, services, processes, and configuration information.

• Evaluate possible privilege-escalation opportunities without performing unnecessary actions.

• Identify lateral-movement opportunities without expanding beyond scope.

• Assess the potential impact of compromised credentials or sensitive configuration.

• Collect appropriate evidence.

• Clean up testing artifacts.

• Translate technical findings into penetration-test observations and remediation recommendations.

Phase 1 — Review the Engagement Scope

Before performing exploitation, review the authorization provided for the lab.

Confirm the systems you are permitted to test and the types of activities allowed.

Your rules of engagement should clearly define:

Authorized targets

Only systems specifically listed in the penetration-testing scope may be tested.

Authorized exploitation

You may validate vulnerabilities and demonstrate controlled access.

Post-exploitation limitations

You may inspect security-relevant information required to determine exposure but should avoid unnecessary access to sensitive data.

Persistence

Persistence mechanisms should not be created unless specifically required by the exercise.

Denial of service

Actions capable of disrupting the target must not be performed.

Data handling

Collect only the minimum evidence necessary to demonstrate the finding.

This phase is important because a penetration tester must always understand where technical authorization begins and ends.

Phase 2 — Review Previously Identified Services

Return to the reconnaissance results produced during earlier network assessment activities.

Review the target’s exposed services and identify which service was flagged for further investigation.

For each exposed service, record:

Item	Example
Target	Lab Server
Network Service	Web / File Sharing / Remote Administration
Port	Identified during enumeration
Service Version	Detected during service discovery
Vulnerability Status	Suspected / Confirmed
Exploitation Approved	Yes / No

Your goal is to understand exactly what you are attempting to validate before exploitation begins.

Phase 3 — Validate the Vulnerability

Before attempting exploitation, verify that the suspected vulnerability applies to the target.

Review:

• Service version

• Operating-system information

• Application configuration

• Authentication requirements

• Vulnerability prerequisites

• Known affected versions

• Expected exploitation impact

Do not treat every scanner result as exploitable.

A scanner may identify a possible weakness that is:

• already patched,

• incorrectly detected,

• blocked by configuration,

• protected by compensating controls,

• or dependent on conditions that do not exist.

The penetration tester therefore performs manual validation before attempting exploitation.

Document your conclusion as one of the following:

Confirmed

Evidence strongly indicates the weakness exists.

Probable

The weakness appears applicable but requires exploitation to confirm.

False Positive

The vulnerability does not apply to the target.

Not Testable

Testing would violate the engagement rules or create unacceptable risk.

Phase 4 — Define the Exploitation Objective

Before attempting exploitation, define exactly what success means.

For example, the objective may be to demonstrate that the vulnerable service allows:

• unauthorized remote access,

• execution within the affected application,

• access to restricted information,

• authentication bypass,

• access using exposed credentials,

• or escalation from one security context to another.

A good penetration test uses the minimum action required to prove the issue.

The goal is proof of impact, not maximum compromise.

Phase 5 — Perform Controlled Exploitation

Use the approved exploitation method for the intentionally vulnerable lab service.

Observe whether the target responds as expected.

Possible outcomes include:

Exploitation Successful

The vulnerability provides the expected level of access.

Partial Success

The vulnerability changes application behavior but does not provide full access.

Exploit Failed

The vulnerability may be patched, misidentified, or protected by another control.

Target Unstable

Testing should immediately stop if unexpected service instability occurs.

If access is achieved, record:

• target system,

• vulnerable service,

• vulnerability used,

• date and time,

• obtained security context,

• evidence of successful access.

Do not perform unnecessary actions after obtaining proof.

Phase 6 — Confirm Initial Access

Once access has been achieved, confirm the security context.

Determine whether the session represents:

• anonymous access,

• application-level access,

• standard-user access,

• service-account access,

• administrative access,

• or another restricted security context.

Record the level of privilege obtained.

This distinction matters because the business impact of a vulnerability depends heavily on the privileges granted after exploitation.

For example:

Low-privilege access

May allow limited application or operating-system visibility.

Service-account access

May expose application credentials, databases, APIs, or internal services.

Administrative access

May indicate complete compromise of the affected system.

Phase 7 — Identify the Compromised Host

Perform limited host identification to understand the compromised environment.

Determine:

• hostname,

• operating system,

• operating-system version,

• network interfaces,

• domain or workgroup membership,

• current user context,

• host role.

Ask yourself:

What type of system have I compromised?

It may be:

• workstation,

• web server,

• application server,

• database server,

• jump host,

• file server,

• identity server,

• development server.

Understanding the host’s role helps determine potential business impact.

Phase 8 — Review Local Users and Groups

Inspect the user and group structure of the compromised host.

Look for evidence of:

• administrator accounts,

• service accounts,

• application accounts,

• dormant accounts,

• shared accounts,

• privileged groups,

• unusual user memberships.

The objective is not to manipulate accounts.

Instead, determine whether the compromised security context could expose additional identities or privileges.

Record any security-relevant observations.

Phase 9 — Review Running Services and Applications

Identify important services and applications operating on the compromised system.

Look for:

• web services,

• database services,

• remote-management services,

• backup applications,

• security agents,

• monitoring services,

• internal applications,

• cloud-management components.

Consider whether compromise of the host could indirectly expose other systems.

For example, an application server may contain credentials used to connect to a backend database.

Phase 10 — Review Network Connectivity

Determine what network connectivity is available from the compromised host.

Examine:

• connected networks,

• internal subnets,

• active connections,

• listening services,

• gateway information,

• internal DNS configuration.

This helps determine whether the compromised system could act as an entry point into additional network segments.

You are identifying the potential attack path rather than automatically expanding the attack.

Phase 11 — Identify Sensitive Configuration Exposure

Review security-relevant configuration locations permitted by the lab.

Look for evidence of exposed:

• application credentials,

• service-account credentials,

• API credentials,

• database connection information,

• configuration files,

• environment settings,

• certificates,

• private keys,

• backup configurations.

Avoid collecting the actual sensitive information unless required by the exercise.

For reporting purposes, evidence that a secret was exposed is usually more important than extracting or retaining the secret itself.

Phase 12 — Evaluate Privilege Escalation Exposure

Assess whether the compromised account appears capable of obtaining higher privileges.

Review factors such as:

• excessive group memberships,

• insecure service permissions,

• weak file permissions,

• vulnerable local software,

• misconfigured scheduled activities,

• exposed administrator credentials,

• insecure administrative tools,

• poorly protected scripts or configurations.

Classify each possible escalation path as:

Likely

Evidence strongly suggests privilege escalation is possible.

Possible

Additional validation would be required.

Unlikely

Existing controls appear to prevent escalation.

For this lab, identifying and explaining the escalation path may be sufficient unless exploitation is explicitly required by the mission.

Phase 13 — Evaluate Credential Exposure

Determine whether the compromised system could expose credentials that provide access elsewhere.

Consider:

• service accounts,

• administrative credentials,

• stored application credentials,

• reused passwords,

• cached authentication material,

• deployment credentials,

• database credentials.

From an enterprise perspective, credential exposure is frequently more dangerous than compromise of the original host.

A single vulnerable server may therefore become the beginning of a much larger attack path.

Phase 14 — Evaluate Lateral Movement Opportunities

Determine where the compromised host could potentially connect.

Possible destinations include:

• neighboring servers,

• databases,

• management systems,

• file servers,

• administrative interfaces,

• internal applications,

• directory infrastructure.

Do not move to another system unless the lab specifically authorizes it.

Instead, document the possible attack path.

For example:

Internet-facing application → compromised server → exposed service account → internal application

This demonstrates business impact while maintaining testing boundaries.

Phase 15 — Assess Security Controls

Observe which defensive controls are present on the compromised system.

Look for:

• endpoint protection,

• EDR,

• host firewall,

• centralized logging,

• monitoring agents,

• intrusion detection,

• application-control mechanisms,

• privileged-access controls.

Consider whether your exploitation activity should have generated alerts.

This becomes valuable information for both penetration testers and defensive security teams.

Phase 16 — Determine the Business Impact

Now translate the technical compromise into business risk.

Ask:

What could an attacker achieve because of this vulnerability?

Possible impacts include:

• unauthorized server access,

• sensitive-data exposure,

• credential theft,

• privilege escalation,

• lateral movement,

• application compromise,

• database compromise,

• disruption of business systems,

• use of the host as an internal attack platform.

Avoid overstating the impact.

Only report attack paths supported by evidence.

Phase 17 — Collect Evidence

Collect sufficient evidence to demonstrate the vulnerability and its impact.

Your evidence package may contain:

• vulnerable service details,

• vulnerability validation results,

• proof of initial access,

• obtained privilege level,

• hostname and system role,

• exposed security configuration,

• potential privilege-escalation paths,

• potential lateral-movement paths.

Screenshots should clearly show the relevant evidence without unnecessarily exposing secrets.

Every major finding should be reproducible by another authorized tester.

Phase 18 — Clean Up the Environment

Professional penetration testers leave systems as close as possible to their original state.

Verify that you have not left:

• temporary files,

• test accounts,

• unnecessary sessions,

• modified configuration,

• uploaded testing artifacts,

• created persistence,

• changed credentials.

Record the cleanup actions performed.

If something cannot safely be removed, document it and notify the system owner.

Phase 19 — Build the Attack Path

Summarize the complete attack chain discovered during the exercise.

A typical attack path might look like:

Network Enumeration

↓

Exposed Vulnerable Service

↓

Vulnerability Validation

↓

Controlled Exploitation

↓

Initial User-Level Access

↓

Credential or Configuration Exposure

↓

Potential Privilege Escalation

↓

Potential Internal Lateral Movement

↓

Business-System Exposure

This attack-path view is often more useful to leadership than a standalone vulnerability score.

Phase 20 — Create the Penetration Test Finding

Document the primary vulnerability using a professional finding structure.

Finding Title

Network Service Vulnerability Allows Unauthorized System Access

Severity

Determine severity based on:

• exploitability,

• network accessibility,

• authentication requirements,

• privileges obtained,

• sensitive assets exposed,

• lateral-movement potential.

Description

Explain what the vulnerable service is and why the weakness exists.

Evidence

Document the minimum proof required to demonstrate successful exploitation.

Security Impact

Explain what an attacker could realistically achieve.

Attack Path

Describe how the vulnerability could become part of a broader compromise.

Remediation

Recommend appropriate defensive actions.

Possible recommendations include:

• patching the affected service,

• removing unnecessary services,

• restricting network exposure,

• applying least privilege,

• rotating exposed credentials,

• implementing network segmentation,

• strengthening privileged access,

• improving endpoint monitoring,

• improving security logging.

Deliverables

At the end of the lab, prepare:

1. Exploitation Validation Record

Document whether the vulnerability was successfully exploited.

2. Initial Access Record

Document the privilege level obtained.

3. Post-Exploitation Assessment

Summarize exposed users, services, configurations, and credentials.

4. Attack Path Diagram

Show how the vulnerability could lead to broader compromise.

5. Penetration Test Finding

Document severity, evidence, impact, and remediation.

6. Cleanup Record

Confirm that the target was returned to its original state.

Pentest+ Exam Perspective

For the CompTIA PenTest+ exam, remember that exploitation is only one part of the engagement.

You should be able to distinguish:

Enumeration — discovering detailed information about a target.

Vulnerability analysis — determining what weaknesses may exist.

Exploitation — proving that a weakness can actually be abused.

Post-exploitation — determining the value and impact of the access obtained.

Privilege escalation — moving from a lower security context to a higher one.

Lateral movement — using an initial compromise to reach another system.

Persistence — maintaining access after the original session ends.

Cleanup — removing artifacts introduced during authorized testing.

Reporting — communicating technical evidence, business impact, and remediation.

A common exam-style scenario is:

A penetration tester has successfully compromised a host. What should the tester do next?

The correct answer depends on the engagement objective, but generally the tester should determine the extent and impact of the compromise while remaining within the rules of engagement, rather than immediately attacking every reachable system.

Key Takeaway

The professional penetration-testing mindset is:

Do not exploit more than necessary. Prove enough to demonstrate risk.

The value of post-exploitation is understanding what the initial compromise could lead to:

Initial Access → Privilege Exposure → Credential Exposure → Lateral Movement Potential → Business Impact

That is what turns a vulnerability scan result into a meaningful penetration-test finding.

What’s Next?

➡️ Lab 05 — Web Application Exploitation and Assessment

In the next lab, you move from network-service exploitation into controlled web application penetration testing, focusing on identifying exploitable application weaknesses, validating impact, examining authentication and authorization boundaries, and producing professional findings from a PenTest+ exam perspective.