Lab 01 Build Your Network Pentesting Lab

Mission Overview

Welcome to Lab 01 — Build Your Network Pentesting Lab.

Before you scan, enumerate, validate vulnerabilities, or assess segmentation, you need a controlled environment where every system is authorized, isolated, and recoverable.

This lab establishes that foundation.

You will build a reusable network pentesting environment with:

one attacker workstation
one Linux target
one Windows target
an optional vulnerable service host
an isolated virtual network
a clear IP-addressing plan
snapshots and rollback points
an evidence workspace
a written scope and authorization record

The main objective is not exploitation.

It is to create a professional training environment where all future network-pentesting labs can be performed safely and consistently.

Mission Goal: Build and validate an isolated network pentesting lab that can be reused for discovery, scanning, enumeration, vulnerability assessment, segmentation testing, and reporting.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Lab Architecture
Secondary Skill	Network Configuration
Environment	GoHackersCloud Network Pentesting Lab
Testing Type	Authorized Lab Setup
Primary Outcome	Reusable Isolated Pentest Environment
Safety Level	Training Systems Only

Learning Objectives

By completing this lab, you will be able to:

design a simple pentesting lab topology
understand lab isolation
configure virtual network adapters
assign static IP addresses
identify attacker and target systems
verify Layer 3 connectivity
distinguish Internet-facing and internal interfaces
establish pentest scope
create an asset inventory
create lab snapshots
create an evidence workspace
document authorization boundaries
validate that vulnerable systems are not unintentionally Internet exposed
prepare the environment for future network-pentesting labs

Core Principle

Throughout this entire track:

Never test what you do not own or have explicit authorization to assess.

Your lab should therefore satisfy three conditions:

Authorized
    +
Isolated
    +
Recoverable

Lab Architecture

A simple starting architecture is:

                Isolated Lab Network
                  192.168.56.0/24
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         ▼               ▼               ▼
   Pentest VM       Linux Target     Windows Target
192.168.56.10      192.168.56.20    192.168.56.30

An optional vulnerable-service host can be added later:

                Isolated Lab Network
                  192.168.56.0/24
                         │
        ┌─────────────┬──┴─────────────┬──────────────┐
        │             │                │              │
        ▼             ▼                ▼              ▼
   Pentest VM    Linux Target    Windows Target   Web Target
 .10             .20             .30              .40

Part 1 — Choose Your Virtualization Platform

Use a virtualization platform available on your system.

Examples include:

VirtualBox
VMware Workstation
Hyper-V
another approved local hypervisor

You do not need a specific product for the methodology.

The important concepts are:

VM
+
Virtual NIC
+
Isolated Network
+
Snapshots

Part 2 — Understand Network Modes

Before creating VMs, understand the common virtual-network modes.

NAT

The VM can generally reach external networks through the host.

Useful for:

software updates
package installation

But not ideal as the only interface for deliberately vulnerable systems.

Bridged Networking

The VM appears directly on the same network as the physical machine.

For intentionally vulnerable targets:

Avoid bridged networking unless you have a specific, controlled reason.

A vulnerable VM should not accidentally appear on your home, office, or production LAN.

Host-Only Networking

Creates a private virtual network between:

the host
connected VMs

This is often suitable for local training labs.

Internal / Private Virtual Network

Communication is limited to participating virtual machines.

This provides stronger isolation.

Part 3 — Recommended Network Design

For this course, use:

Lab Network:
192.168.56.0/24

Subnet Mask:
255.255.255.0

Example addressing:

Asset	IP Address	Role
Pentest VM	`192.168.56.10`	Assessment workstation
Linux Target	`192.168.56.20`	Linux services
Windows Target	`192.168.56.30`	Windows services
Web Target	`192.168.56.40`	Optional training application
Gateway	None initially	Isolated network

This is only a lab example.

Part 4 — Create the Scope Document

Before powering on the lab, create:

Network-Pentesting-Labs/
└── Lab-01/
    └── Scope/
        └── Lab-01-Scope.md

Use:

# Lab 01 — Network Pentesting Scope

## Purpose

Build and validate an isolated network pentesting environment.

## Authorized Systems

Pentest VM:
192.168.56.10

Linux Target:
192.168.56.20

Windows Target:
192.168.56.30

Optional Web Target:
192.168.56.40

## Authorized Network

192.168.56.0/24

## Allowed Activities

- connectivity testing
- host discovery
- service discovery
- enumeration
- vulnerability assessment
- controlled validation in future labs

## Prohibited Activities

- scanning public Internet systems
- scanning the host organization's production network
- attacking external services
- credential reuse outside the lab
- denial-of-service testing
- destructive actions

## Authorization

Training environment owned or explicitly authorized by the learner.

## Lab Status

Authorized for training only.

Part 5 — Create the Pentest Workstation

Your attacker workstation should contain the tools you need for later labs.

A common training choice is a security-focused Linux VM.

Configure:

Hostname:
pentest01

Lab IP:
192.168.56.10

Role:
Authorized Pentesting Workstation

Recommended resources:

CPU:
2–4 vCPU

Memory:
4–8 GB

Disk:
40+ GB

Actual requirements depend on your host hardware.

Part 6 — Configure Two Interfaces Carefully

A useful workstation configuration is:

NIC 1:
NAT
Purpose: Updates

NIC 2:
Host-Only / Internal
Purpose: Pentesting Lab

Conceptually:

Internet
   │
   ▼
NAT Interface
   │
Pentest VM
   │
Lab Interface
   ▼
192.168.56.0/24

This lets the pentest workstation receive updates while still participating in the isolated training network.

Part 7 — Avoid Dual-Homing Vulnerable Targets Initially

For intentionally vulnerable targets, start with only:

Host-Only / Internal Network

Do not give them an Internet-facing interface unless required for a controlled setup task.

This reduces accidental exposure.

Part 8 — Configure the Pentest VM IP

On Linux, first identify interfaces:

ip addr

or:

ip link

Identify the interface connected to the lab network.

Your names may look like:

eth0

eth1

ens33

ens37

Do not assume the interface name.

Part 9 — Verify Assigned Address

The lab interface should show an address such as:

192.168.56.10/24

Verify:

ip addr show

Record:

Pentest Hostname:

Lab Interface:

Lab IP:

Subnet:

MAC Address:

Part 10 — Create the Linux Target

Create a Linux target VM.

Use a standard Linux distribution suitable for training.

Configure:

Hostname:
linux-target

IP:
192.168.56.20

Network:
Lab-only

Resources can be modest:

CPU:
1–2 vCPU

RAM:
2–4 GB

Disk:
20+ GB

Part 11 — Record Linux Target Information

On the target:

hostname

Then:

ip addr

Record:

Hostname:

Distribution:

Version:

IP:

MAC:

Network Interface:

Part 12 — Create the Windows Target

Create a Windows VM appropriate for the lab.

Configure:

Hostname:
WIN-TARGET

IP:
192.168.56.30

Network:
Lab-only

Recommended resources will depend on the Windows version, but commonly:

CPU:
2 vCPU

RAM:
4+ GB

Disk:
40+ GB

Part 13 — Record Windows Network Configuration

On Windows:

ipconfig /all

Record:

Computer Name:

IPv4 Address:

Subnet Mask:

Default Gateway:

DNS:

MAC Address:

For a completely isolated lab, the default gateway may be absent.

Part 14 — Create the Asset Register

Build:

Asset ID	Hostname	IP	OS	Role	Authorized
NET-01	pentest01	192.168.56.10	Linux	Pentest	Yes
NET-02	linux-target	192.168.56.20	Linux	Target	Yes
NET-03	WIN-TARGET	192.168.56.30	Windows	Target	Yes

This register will be reused in later labs.

Part 15 — Verify the Network Route

On the pentest VM:

ip route

You should see a route corresponding to:

192.168.56.0/24

through the lab interface.

Document:

Lab Route:

Interface:

Gateway:
If any

Part 16 — Test Connectivity to Linux

From the attacker VM:

ping -c 4 192.168.56.20

Possible result:

Replies received

If successful:

Layer 3 connectivity:
Confirmed

If unsuccessful, do not immediately assume the host is offline.

ICMP may be disabled.

Part 17 — Test Connectivity to Windows

From the pentest VM:

ping -c 4 192.168.56.30

Windows firewall policies may block ICMP.

Therefore:

No Ping Response
    ≠
Host Offline

This principle becomes important in Lab 02.

Part 18 — Verify Reverse Connectivity

From Linux:

ping -c 4 192.168.56.10

If Windows allows ping, test similarly.

The objective is to establish that the machines share the expected network.

Part 19 — Confirm Network Isolation

This is one of the most important checks.

On the Linux target:

ip route

Look for an external default route.

If the intentionally vulnerable target is supposed to be fully isolated:

External Internet Route:
Should not exist

Part 20 — Test External Connectivity Carefully

On the deliberately vulnerable target, check whether it can reach the public Internet.

If the lab is intended to be isolated, it should not.

Document:

Target Internet Connectivity:
Unavailable / Available

Expected:
Unavailable

Do not leave vulnerable systems unintentionally Internet-accessible.

Part 21 — Confirm Host LAN Isolation

Your physical network might use something like:

192.168.1.0/24

while the pentest lab uses:

192.168.56.0/24

The vulnerable systems should not automatically be participating in the physical LAN.

Document:

Physical LAN:

Lab Network:

Bridged Adapter Present:
Yes / No

Expected for vulnerable systems:

No

Part 22 — Check Listening Services on Linux

On the Linux target itself:

ss -tuln

This shows listening sockets.

Do not perform remote scanning yet.

Simply establish the target’s local baseline.

Record:

Protocol	Local Address	Port	Expected Service
TCP
UDP

Part 23 — Check Listening Services on Windows

On the Windows target:

netstat -ano

or:

Get-NetTCPConnection -State Listen

Record relevant services.

Again, this is the baseline.

Later, you will compare:

What the target says is listening
        vs
What the pentester can remotely observe

Part 24 — Understand the Difference

Suppose Linux reports:

TCP 22 listening

but the pentest machine cannot connect.

Possible explanation:

Host firewall

This becomes a valuable networking lesson.

The model is:

Service Listening
       +
Network Reachability
       +
Firewall Policy
       =
Remote Exposure

Part 25 — Create a Network Diagram

Document the lab:

               Host Computer
                    │
              Virtualization
                    │
        ┌───────────┴────────────┐
        │ 192.168.56.0/24        │
        │ Isolated Lab Network   │
        │                        │
   192.168.56.10            192.168.56.20
    pentest01               linux-target
        │
        └────────────────── 192.168.56.30
                             WIN-TARGET

Save as:

Lab-01-Network-Topology

Part 26 — Create a Network Addressing Plan

Build:

Address	Host	Purpose	Status
`.1`	Reserved	Hypervisor/Host	Optional
`.10`	pentest01	Pentesting	Assigned
`.20`	linux-target	Linux target	Assigned
`.30`	WIN-TARGET	Windows target	Assigned
`.40`	web-target	Future lab	Reserved

Avoid random addressing from lab to lab.

Consistency improves learning.

Part 27 — Create the Evidence Workspace

Build:

Network-Pentesting-Labs/
└── Lab-01/
    ├── Scope/
    ├── Notes/
    ├── Network/
    ├── Assets/
    ├── Evidence/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-01-Network-Pentesting-Journal.md

Part 28 — Create the Lab Journal

Use:

# Lab 01 — Build Your Network Pentesting Lab

## Mission Objective

## Authorization

## Lab Network

## Hypervisor

## Pentest Workstation

## Linux Target

## Windows Target

## Asset Register

## Network Addressing

## Connectivity Tests

## Isolation Validation

## Service Baseline

## Snapshots

## Issues Encountered

## Evidence

## Final Validation

Part 29 — Capture Baseline Evidence

Capture evidence showing:

Evidence 01

Pentest VM:

ip addr

Evidence 02

Pentest VM:

ip route

Evidence 03

Linux target network configuration.

Evidence 04

Windows target:

ipconfig /all

Evidence 05

Connectivity between authorized systems.

Evidence 06

Lab topology.

Evidence 07

Asset inventory.

Part 30 — Create Snapshots

Once each VM is working correctly, create snapshots.

Recommended names:

pentest01:
NETLAB-BASELINE

linux-target:
NETLAB-BASELINE

WIN-TARGET:
NETLAB-BASELINE

Snapshots allow you to return to a known state after future labs.

Part 31 — Understand Snapshot Discipline

Before major future exercises:

Baseline
   ↓
Snapshot
   ↓
Lab Activity
   ↓
Evidence
   ↓
Restore if needed

Do not rely on snapshots as the only backup of important evidence.

Store evidence outside the target VM where appropriate.

Part 32 — Separate Evidence from Targets

A useful principle is:

Target System
    ≠
Only Location of Evidence

Your journal and screenshots should be stored in a dedicated evidence location.

Part 33 — Create a Testing Rules File

Create:

Scope/
Rules-of-Engagement.md

Use:

# Rules of Engagement

## Authorized Range

192.168.56.0/24

## Authorized Systems

192.168.56.10
192.168.56.20
192.168.56.30
192.168.56.40 when deployed

## Testing Window

Training sessions only.

## Allowed

- host discovery
- port scanning
- service enumeration
- vulnerability assessment
- controlled validation
- packet analysis
- segmentation testing within lab

## Not Allowed

- public Internet scanning
- production-network scanning
- denial-of-service activity
- destructive actions
- testing systems outside the defined range
- using recovered lab credentials elsewhere

## Stop Condition

If an unknown system outside the lab appears during testing,
stop and verify scope before continuing.

Part 34 — Define a Stop Condition

Professional testers know when to stop.

Examples:

Unexpected public IP discovered

Unknown production host responds

Lab network overlaps corporate network

Target becomes unstable

Scope is unclear

Sensitive non-lab data is discovered

The correct action is:

Stop → Verify → Continue only when authorized

Part 35 — Create the Scope Verification Checklist

Before every later lab, confirm:

[ ] Authorized network confirmed

[ ] Target IP confirmed

[ ] Lab isolation confirmed

[ ] Correct VM snapshot available

[ ] Evidence directory ready

[ ] No public targets included

[ ] Testing objective understood

[ ] Stop conditions understood

Part 36 — Optional Web Target

You may later add an intentionally vulnerable web target.

Assign:

192.168.56.40

Keep it on the same isolated network.

Do not expose it directly to the public Internet.

It may be useful for later:

service enumeration
HTTP analysis
authentication assessments

Part 37 — Optional Router or Firewall

For advanced labs, add a virtual router/firewall.

Example:

             Pentest Network
             192.168.56.0/24
                   │
             Virtual Firewall
                   │
             192.168.57.0/24
                   │
              Server Network

This will become valuable during the segmentation lab.

You do not need it for Lab 01.

Part 38 — Optional Multi-Network Design

Later the environment can evolve into:

                    Pentest VM
                        │
                        ▼
                  192.168.56.0/24
                        │
                     Firewall
                  ┌─────┴─────┐
                  ▼           ▼
             DMZ Network   Internal Network
             .57.0/24      .58.0/24

This helps simulate enterprise networks.

Part 39 — Do Not Overbuild the First Lab

For now, three VMs are enough:

Pentest
Linux
Windows

The priority is:

Stable, understandable, isolated, reusable.

Part 40 — Create the Lab Readiness Matrix

Requirement	Pentest	Linux	Windows
VM Boots	✓	✓	✓
Correct Network	✓	✓	✓
Static IP	✓	✓	✓
Authorized	✓	✓	✓
Snapshot	✓	✓	✓
Evidence Captured	✓	✓	✓

Part 41 — Validate IP Uniqueness

Make sure no two machines share the same address.

Expected:

192.168.56.10

192.168.56.20

192.168.56.30

Duplicate addresses can produce confusing behavior.

Part 42 — Record MAC Addresses

MAC addresses can become useful during discovery.

Record:

Host	IP	MAC
pentest01	192.168.56.10
linux-target	192.168.56.20
WIN-TARGET	192.168.56.30

You will revisit this in Lab 02.

Part 43 — Create a Known-Hosts Baseline

Create:

Assets/Known-Hosts.md

Example:

# Authorized Lab Hosts

## pentest01

IP: 192.168.56.10
Role: Pentest Workstation

## linux-target

IP: 192.168.56.20
Role: Linux Target

## WIN-TARGET

IP: 192.168.56.30
Role: Windows Target

This becomes useful when comparing discovery results.

Part 44 — Validate You Are on the Correct Network

Before any future pentest command:

ip addr

and:

ip route

Ask:

Am I about to test the lab network I intended to test?

That habit matters more than memorizing scanning syntax.

Part 45 — Create a Command Journal

In future labs, record:

Timestamp:

Command:

Target:

Purpose:

Result:

Evidence Reference:

Example:

Time:
10:35

Command:
Connectivity test

Target:
192.168.56.20

Purpose:
Verify lab host reachability

Result:
Reachable

Evidence:
E01

Part 46 — Understand Evidence Quality

Weak evidence:

“I think the host was reachable.”

Better evidence:

“Connectivity testing from the authorized pentest workstation
received responses from 192.168.56.20 at 10:35.”

Best evidence combines:

timestamp
source host
target
command or method
output
screenshot/log reference

Part 47 — Create the Lab Configuration Register

Use:

Setting	Value
Network	192.168.56.0/24
Mode	Host-Only / Internal
Pentest IP	192.168.56.10
Linux IP	192.168.56.20
Windows IP	192.168.56.30
Internet on Targets	No
Snapshot Created	Yes

Part 48 — Perform Final Isolation Validation

Confirm:

Pentest VM
→ Linux:
Reachable

Pentest VM
→ Windows:
Reachable or known firewall behavior

Linux
→ Pentest VM:
Reachable

Vulnerable Target
→ Internet:
Unavailable

Vulnerable Target
→ Production LAN:
Unavailable

Part 49 — Mission Challenge

Complete:

LAB INFORMATION

Lab Name:
Network Pentesting Lab

Authorized Range:

Hypervisor:

Network Type:


PENTEST WORKSTATION

Hostname:

IP:

MAC:

Operating System:

Internet Interface:

Lab Interface:


LINUX TARGET

Hostname:

IP:

MAC:

OS:

Lab Interface:

Internet Access:
Yes / No


WINDOWS TARGET

Hostname:

IP:

MAC:

Windows Version:

Lab Interface:

Internet Access:
Yes / No


NETWORK VALIDATION

Pentest → Linux:
Pass / Fail

Pentest → Windows:
Pass / Fail / Firewall Restricted

Linux → Pentest:
Pass / Fail

Target → Public Internet:
Available / Unavailable

Expected:
Unavailable


SCOPE

Authorized Range:

Authorized Hosts:

Testing Restrictions:

Stop Conditions:


SNAPSHOTS

Pentest Snapshot:

Linux Snapshot:

Windows Snapshot:


EVIDENCE

Asset Register:
Complete / Incomplete

Network Diagram:
Complete / Incomplete

Rules of Engagement:
Complete / Incomplete

Screenshots:
Complete / Incomplete


FINAL STATUS

Lab Isolated:
Yes / No

Lab Authorized:
Yes / No

Lab Recoverable:
Yes / No

Ready for Network Discovery:
Yes / No

Part 50 — What Not to Do

Do not:

Bridge intentionally vulnerable targets onto public or production networks

Scan nearby systems just because they respond

Scan the Internet

Use a work network as a practice target

Include unknown addresses in the scope

Disable isolation without documenting why

Run future tests before confirming the target

Use production credentials

Reuse lab passwords on real systems

Skip snapshots

Skip scope documentation

Assume a nonresponsive host is offline

Assume an open port is automatically vulnerable

Use destructive testing unless explicitly designed into a lab

Troubleshooting

Linux Cannot Reach Pentest VM

Check:

ip addr

Then:

ip route

Confirm both VMs use the same virtual network.

Pentest VM Can Reach Internet but Not Target

Check that the correct lab NIC exists.

You may be using only the NAT interface.

Target Can Reach Your Physical LAN

This may indicate:

Bridged networking

Review the VM adapter immediately.

Two Machines Have Same IP

Change one address.

Each host requires a unique address.

Windows Does Not Respond to Ping

The firewall may block ICMP.

This does not necessarily indicate a network problem.

Later labs will use multiple discovery methods.

Linux Target Has Unexpected Internet Access

Inspect:

ip route

and hypervisor NIC settings.

Remove unintended NAT or bridged interfaces.

Evidence Requirements

Capture:

Evidence 01

Lab Scope Document.

Evidence 02

Rules of Engagement.

Evidence 03

Pentest workstation interface configuration.

Evidence 04

Pentest workstation route table.

Evidence 05

Linux network configuration.

Evidence 06

Windows ipconfig /all.

Evidence 07

Asset Register.

Evidence 08

IP Addressing Plan.

Evidence 09

Network Topology.

Evidence 10

Pentest-to-Linux connectivity.

Evidence 11

Pentest-to-Windows connectivity result.

Evidence 12

Target isolation verification.

Evidence 13

Linux listening-service baseline.

Evidence 14

Windows listening-service baseline.

Evidence 15

Snapshot records.

Evidence 16

Lab Readiness Matrix.

Mission Deliverables

Complete:

virtualization platform selected
isolated virtual network created
authorized CIDR documented
pentest workstation created
Linux target created
Windows target created
pentest network interface configured
target network interfaces configured
unique IP addresses assigned
MAC addresses documented
asset inventory completed
connectivity tested
routing verified
target Internet exposure checked
production-LAN exposure checked
service baselines recorded
network diagram created
Rules of Engagement created
stop conditions documented
evidence workspace created
journal created
baseline screenshots collected
VM snapshots created
readiness checklist passed

Lab Report Template

# Lab 01 — Build Your Network Pentesting Lab

## Executive Summary

## Mission Objective

## Authorization and Scope

## Rules of Engagement

## Lab Architecture

## Network Addressing Plan

## Pentest Workstation

## Linux Target

## Windows Target

## Asset Register

## Network Configuration

## Connectivity Validation

## Routing Validation

## Isolation Validation

## Service Baseline

## Snapshot Strategy

## Evidence Collected

## Issues Encountered

## Troubleshooting Performed

## Limitations

## Final Readiness Assessment

## Conclusion

Knowledge Check

Question 1 — Why should intentionally vulnerable systems not normally use bridged networking?

Because it may expose them directly to the physical or production network.

Question 2 — What is the advantage of a host-only or internal network?

It provides controlled communication between authorized lab systems.

Question 3 — Why give each machine a known static IP?

It creates a predictable environment for discovery, enumeration, and evidence collection.

Question 4 — Does failure to respond to ping mean a host is offline?

No.

ICMP may be filtered.

Question 5 — Why record the target’s listening services before pentesting?

It creates a known baseline for comparison with remote observations.

Question 6 — Why create snapshots?

They provide a known recovery point for later exercises.

Question 7 — What should happen if an unknown system appears in your testing results?

Stop and confirm that the asset is within scope.

Question 8 — Why keep an Asset Register?

It establishes the authorized environment and helps validate later discovery results.

Question 9 — What are the three major qualities of this lab?

Authorized, isolated, and recoverable.

Question 10 — What should you confirm before every future network assessment?

The target, network range, authorization, and lab isolation.

Skills Achieved

After completing this lab, you should understand:

pentesting-lab architecture
virtualization network modes
lab isolation
virtual network interfaces
IP addressing
subnet concepts
network routing basics
attacker/target separation
host inventory
connectivity validation
target service baselining
evidence organization
scope documentation
Rules of Engagement
stop conditions
snapshot discipline
professional lab preparation

Professional Takeaway

A professional network pentest does not begin with a scanner.

It begins with:

Authorization
      +
Scope
      +
Known Assets
      +
Network Boundaries
      +
Safe Environment

Then:

Scope
   ↓
Environment
   ↓
Connectivity
   ↓
Baseline
   ↓
Evidence
   ↓
Testing

Remember:

Reachable
   ≠
Vulnerable

No Ping Reply
   ≠
Host Offline

Listening Service
   ≠
Remotely Reachable

Discovered System
   ≠
Authorized Target

The most important habit developed in this first lab is:

Know exactly what you are testing before you test it.

What’s Next?

➡️ Lab 02 — Network Discovery & Host Identification

In the next lab, you will begin the actual network assessment.

You will investigate:

local network information
authorized CIDR boundaries
ARP discovery
ICMP-based discovery
hosts that do not answer ping
MAC addresses
active vs inactive hosts
duplicate or unexpected systems
known-assets vs discovered-assets comparison
network asset inventory

The methodology becomes:

Scope → Network → Discover → Identify → Validate → Inventory

The central question will be:

“Which systems are actually present on the authorized network, and how can I identify them without assuming that ping response alone determines whether a host exists?”