Lab 01 Build Your Ethical Hacking Lab

Mission Overview

Welcome to your first Ethical Hacking Lab.

Before performing reconnaissance, scanning, enumeration, vulnerability assessment, or any other security-testing activity, you need a safe environment where you can practice without affecting real systems.

In this lab, you will build an isolated ethical hacking environment containing an attacker workstation and intentionally vulnerable target systems.

Mission Goal: Build a controlled lab that you can repeatedly use for future ethical hacking exercises while maintaining clear scope, isolation, evidence handling, and rollback capability.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Ethical Hacking Lab Design
Environment	Local Virtualization
Target Type	Intentionally Vulnerable Systems
Primary Outcome	Functional isolated penetration-testing lab
Evidence Required	Screenshots + environment inventory
Safety Level	Controlled Lab Only

Learning Objectives

By completing this lab, you will be able to:

• understand why ethical hacking labs must be isolated

• create an attacker workstation

• deploy intentionally vulnerable target systems

• configure a dedicated virtual network

• understand NAT, bridged, host-only, and internal networking

• prevent accidental interaction with external systems

• create virtual-machine snapshots

• build a lab asset inventory

• define Rules of Engagement

• establish an evidence-management structure

• verify communication between authorized lab systems

• prepare the environment for future pentesting labs

What You Will Build

Your lab will follow this basic architecture:

                    Your Physical Computer
                           │
                    Virtualization
                           │
              ┌────────────┴────────────┐
              │                         │
         Management/NAT           Isolated Lab
                                      │
                         ┌────────────┼────────────┐
                         │            │            │
                         ▼            ▼            ▼
                     Kali Linux   Linux Target  Web Target
                     Attacker       System       System

Later, the environment can be expanded with:

Windows Client

Windows Server

Active Directory

Additional Linux Servers

Vulnerable Web Applications

IDS / IPS

SIEM

Firewall

Cloud Simulation

Do not build everything at once.

For this first lab, keep the environment simple.

Part 1 — Understand the Lab Components

Your environment requires three basic components.

1. Hypervisor

A hypervisor allows multiple virtual machines to run on your computer.

Common choices include:

• VirtualBox

• VMware Workstation

• VMware Fusion

• Hyper-V

Use whichever supported virtualization platform you already have available.

The concepts in this lab apply regardless of the hypervisor.

2. Attacker Workstation

The attacker workstation is the system from which authorized security testing will be performed.

For these labs, Kali Linux is a practical choice because it includes many security-assessment tools.

The workstation will be used for activities such as:

• reconnaissance

• network discovery

• service enumeration

• vulnerability analysis

• traffic analysis

• web application testing

• evidence collection

3. Intentionally Vulnerable Targets

Targets should be deliberately designed for security training.

Examples include:

• Metasploitable

• OWASP Juice Shop

• DVWA

• deliberately vulnerable Linux systems

• purpose-built Windows lab systems

Never substitute an unknown internet system as your target.

Part 2 — Check Your Physical Computer

Before creating virtual machines, verify that your computer has sufficient resources.

A practical minimum is approximately:

CPU: 4 logical cores

RAM: 8 GB

Free Storage: 50 GB

Virtualization: Enabled

A more comfortable environment would have:

CPU: 6–8+ logical cores

RAM: 16 GB+

Free Storage: 100 GB+

You do not need to allocate all resources to virtual machines.

Your host operating system must still remain usable.

Part 3 — Verify Hardware Virtualization

On a Windows host, open:

Task Manager → Performance → CPU

Look for:

Virtualization: Enabled

If it shows disabled, virtualization may need to be enabled through the computer’s UEFI/BIOS configuration.

Common names include:

• Intel VT-x

• Intel Virtualization Technology

• AMD-V

• SVM Mode

Do not change unrelated firmware settings.

Part 4 — Install Your Hypervisor

Install your preferred virtualization platform using its official distribution channel.

After installation:

1. Start the hypervisor.

2. Confirm that the application opens correctly.

3. Verify that you can create a virtual machine.

4. Identify where virtual machines will be stored.

Consider creating a dedicated folder such as:

Cybersecurity-Lab/

Example:

Cybersecurity-Lab/
│
├── Virtual-Machines/
├── ISO/
├── Evidence/
└── Documentation/

This keeps the environment organized.

Part 5 — Download Kali Linux

Obtain Kali Linux from the official Kali Linux source.

Depending on your hypervisor, you may use:

• installer image

• prebuilt virtual machine

For beginners, a prebuilt virtual machine can reduce setup complexity.

After importing or installing Kali, allocate reasonable resources.

For example:

CPU: 2

RAM: 4 GB

Disk: 30–40 GB

Adjust based on your host capacity.

Part 6 — Start Kali Linux

Boot the virtual machine.

Confirm that you can:

• log in

• open a terminal

• access the desktop

• view network interfaces

• shut down correctly

Do not begin scanning anything yet.

First, we need to configure the network.

Part 7 — Understand Virtual Network Modes

This is one of the most important parts of the lab.

Most hypervisors provide several networking modes.

NAT

The virtual machine shares connectivity through the host.

Conceptually:

VM
 │
 ▼
Hypervisor NAT
 │
 ▼
Host
 │
 ▼
Internet

Useful for:

• downloading updates

• installing packages

But NAT should not automatically be treated as your penetration-testing network.

Bridged Networking

The VM connects directly to the physical network.

VM
 │
 ▼
Home / Corporate Network

This can expose the vulnerable VM to other systems on your network.

For intentionally vulnerable targets, this is usually not appropriate.

Avoid using bridged networking for vulnerable training machines unless you fully understand the consequences and have a controlled environment.

Host-Only Networking

Host-only creates a private network between the host and virtual machines.

Host
 │
 ├── Kali
 │
 ├── Target 1
 │
 └── Target 2

It generally prevents direct external connectivity.

This is useful for lab isolation.

Internal Networking

An internal network connects only selected virtual machines.

Kali
 │
 ├── Target 1
 │
 └── Target 2

The host may not participate directly, depending on the hypervisor configuration.

This is often excellent for isolated security labs.

Part 8 — Create the Lab Network

Create a dedicated network for the ethical hacking environment.

Example name:

GHC-Ethical-Hacking-Lab

Example address range:

192.168.56.0/24

Your lab might eventually use:

Kali              192.168.56.10

Linux Target      192.168.56.20

Web Target        192.168.56.30

Windows Target    192.168.56.40

These are only example private addresses.

The important requirement is that all systems belong to the same isolated lab network.

Part 9 — Configure Kali Networking

Configure Kali with an adapter connected to your isolated lab network.

A useful architecture is:

Kali
│
├── Adapter 1 → NAT
│
└── Adapter 2 → Lab Network

Why use two adapters?

The NAT adapter can provide internet connectivity when you intentionally need updates.

The second adapter communicates with vulnerable lab systems.

Your vulnerable targets, however, should generally have only:

Adapter 1 → Lab Network

This reduces unnecessary external exposure.

Part 10 — Examine Kali Interfaces

Inside Kali, open a terminal.

Run:

ip addr

You may see interfaces such as:

lo

eth0

eth1

Depending on the virtualization platform, interface names may differ.

Identify which interface belongs to the isolated lab network.

Record its address.

Example:

Kali Lab IP: 192.168.56.10

Part 11 — Verify the Network

You can inspect the routing table with:

ip route

Study the results.

Ask yourself:

• Which interface provides internet connectivity?

• Which interface connects to the lab?

• What is the default gateway?

• Which network is directly connected?

Do not simply copy commands.

Understand what they reveal.

Part 12 — Deploy Your First Vulnerable Target

Now add an intentionally vulnerable system.

For the first target, a deliberately vulnerable Linux training machine is sufficient.

After importing the VM, configure:

Network Adapter:

Host-Only
or
Internal Lab Network

Do not configure it as bridged.

Start the target.

Part 13 — Identify the Target IP

Log into the target if the exercise provides local access.

On a Linux-based target, you may inspect its interfaces using:

ip addr

Record the address.

Example:

Target 01

Hostname: Vulnerable-Linux

IP: 192.168.56.20

Part 14 — Create Your Asset Inventory

Create an inventory for every system in the lab.

For example:

Asset	Role	Operating System	IP Address
Kali	Security Workstation	Kali Linux	192.168.56.10
Target-01	Vulnerable Server	Linux	192.168.56.20
Target-02	Vulnerable Web App	Linux/Web	192.168.56.30

Later, extend the table with:

• hostname

• MAC address

• network

• snapshot status

• purpose

• credentials

• owner

• notes

Do not place real production credentials in your lab documentation.

Part 15 — Verify Authorized Connectivity

From Kali, test connectivity to your lab target.

Example:

ping 192.168.56.20

If successful, you may receive responses similar to:

64 bytes from 192.168.56.20

This confirms basic IP connectivity.

Stop the command with:

Ctrl+C

If there is no response, do not immediately assume the target is unavailable.

ICMP can be blocked.

Check:

• VM state

• IP addresses

• virtual-network settings

• subnet

• firewall configuration

This troubleshooting process is part of the lab.

Part 16 — Check That the Target Is Isolated

This step is extremely important.

On your vulnerable target, determine whether it has unintended access outside the training environment.

The desired architecture is:

Vulnerable Target
      │
      ▼
Private Lab Network

Not:

Vulnerable Target
      │
      ▼
Corporate / Home LAN
      │
      ▼
Internet

A deliberately vulnerable machine should not be unnecessarily exposed to other systems.

Part 17 — Add a Vulnerable Web Application

For future web-security labs, add a dedicated vulnerable application.

Potential training environments include:

• OWASP Juice Shop

• DVWA

• WebGoat

These applications are intentionally vulnerable and intended for security education.

A simple architecture becomes:

Kali
  │
  ├──────── Linux Target
  │
  └──────── Web Target

For example:

192.168.56.10   Kali

192.168.56.20   Linux Target

192.168.56.30   Web Target

Part 18 — Verify Web Application Access

From Kali, open a browser and navigate to the lab application’s private lab address.

Example conceptually:

http://192.168.56.30

Confirm that the training application loads.

Do not browse to or test unrelated external websites.

Part 19 — Take Your First Snapshot

Snapshots are extremely useful in security labs.

Create a snapshot after each VM reaches a known-good state.

Suggested snapshot:

Name:

00-Clean-Baseline

Description:

Fresh system before ethical hacking exercises.

Your snapshot strategy might become:

00-Clean-Baseline

01-Before-Lab

02-After-Lab

If a future exercise damages the VM, you can restore it rather than rebuilding everything.

Part 20 — Create Your Rules of Engagement

Before performing any security testing, write a simple Rules of Engagement document.

Use:

# Ethical Hacking Lab Rules of Engagement

## Authorized Tester

Student / Lab User

## Purpose

Cybersecurity education and authorized security testing.

## Authorized Systems

Kali Linux
Linux Training Target
Vulnerable Web Application

## Authorized Network

192.168.56.0/24

## Prohibited Targets

Public Internet systems
Home network devices
Corporate systems
Third-party services
Any system outside the lab

## Permitted Activity

Reconnaissance
Network discovery
Service enumeration
Vulnerability assessment
Controlled vulnerability validation

## Evidence

Lab screenshots
Terminal output
Assessment notes
Findings reports

## Safety Requirement

Testing must remain within the dedicated training environment.

This may feel formal for a home lab.

That is intentional.

You are developing professional habits.

Part 21 — Create an Evidence Structure

Create a folder for the ethical hacking labs.

Example:

Ethical-Hacking-Labs/
│
├── 00-Lab-Documentation/
│   ├── Network-Diagram/
│   ├── Asset-Inventory/
│   └── Rules-of-Engagement/
│
├── Lab-01/
│   ├── Notes/
│   ├── Screenshots/
│   ├── Evidence/
│   └── Report/
│
├── Lab-02/
├── Lab-03/
└── Lab-20/

This folder structure will eventually become part of your security portfolio.

Part 22 — Create an Investigation Journal

Create:

Lab-01-Investigation-Journal.md

Use:

# Lab 01 — Investigation Journal

## Date

## Objective

Build an isolated ethical hacking environment.

## Systems

### Kali Linux
IP:
Role:

### Target 01
IP:
Role:

### Target 02
IP:
Role:

## Network

Network Name:

Subnet:

Network Mode:

## Actions Performed

## Observations

## Problems Encountered

## Resolution

## Evidence

## Lessons Learned

Keep notes while working rather than attempting to reconstruct everything afterward.

Part 23 — Draw the Network Diagram

Create a simple diagram.

For example:

                    Host Computer
                         │
                    Hypervisor
                         │
          ┌──────────────┴──────────────┐
          │                             │
         NAT                     GHC Lab Network
          │                       192.168.56.0/24
          │                             │
       Kali VM ─────────────────────────┤
     192.168.56.10                      │
                                        ├── Linux Target
                                        │   192.168.56.20
                                        │
                                        └── Web Target
                                            192.168.56.30

Save this as part of your evidence.

Network diagrams become much more important as environments grow.

Part 24 — Validate the Environment

Before completing the lab, verify each requirement.

Kali

Confirm:

VM starts successfully.

Lab interface exists.

Correct lab IP assigned.

Can communicate with lab targets.

Target

Confirm:

Target starts.

Target has private lab IP.

Target is not bridged to production network.

Kali can reach target.

Vulnerable Web Application

Confirm:

Application starts.

Application is reachable from Kali.

Application is available only inside the authorized lab environment.

Documentation

Confirm:

Rules of Engagement created.

Asset inventory created.

Network diagram created.

Snapshots created.

Evidence folders created.

Part 25 — Capture Required Evidence

Take screenshots showing:

Evidence 01

Hypervisor displaying your lab virtual machines.

Evidence 02

Kali network interfaces.

Evidence 03

Target network interface.

Evidence 04

Successful communication between Kali and the target.

Evidence 05

Vulnerable web application accessible from Kali.

Evidence 06

VM snapshot.

Evidence 07

Asset inventory.

Evidence 08

Network diagram.

Do not expose sensitive host information unnecessarily.

Part 26 — Troubleshooting

Kali and Target Cannot Communicate

Check whether both machines are connected to the same virtual network.

Example problem:

Kali:
Host-Only Network A

Target:
Host-Only Network B

They are isolated from each other.

Both must use the intended lab network.

Machines Have Different Subnets

Example:

Kali:
192.168.56.10/24

Target:
192.168.100.20/24

Without routing, these systems are not on the same subnet.

Correct the network configuration.

No IP Address

Verify:

• virtual adapter enabled

• network selected

• DHCP availability

• guest operating-system configuration

Target Has Internet Access

Review the target’s network adapters.

If it has a NAT or bridged adapter that is not required, remove or disable it.

Kali Has No Internet

If updates are required, Kali can temporarily use a separate NAT adapter.

You do not need internet connectivity to perform most isolated lab exercises.

Part 27 — Understand What You Built

You have created more than a few virtual machines.

You now have the foundation of a miniature cybersecurity environment:

Attacker
   │
   ▼
Isolated Network
   │
   ├── Operating System Target
   │
   └── Application Target

This allows future labs to safely explore the complete assessment lifecycle.

Part 28 — Security Architecture Perspective

Notice that this small lab already contains several enterprise-security concepts.

Assets

Your VMs.

Network Boundary

The virtual lab network.

Identity

Accounts on each system.

Services

Applications running on targets.

Vulnerabilities

Weaknesses deliberately introduced into training systems.

Security Controls

Firewalls, permissions, authentication, segmentation.

Future labs will examine each layer.

Mission Challenge

Without following additional instructions, determine the following for your environment:

Kali IP Address:

Linux Target IP Address:

Web Target IP Address:

Lab Subnet:

Kali Default Gateway:

Network Mode:

Which system has Internet access?

Which systems are isolated?

How would you restore the environment after a failed exercise?

Document your answers.

Mission Deliverables

Submit or retain the following:

• lab network diagram

• asset inventory

• Rules of Engagement

• Kali network screenshot

• target network screenshot

• connectivity verification

• vulnerable application screenshot

• VM snapshot evidence

• investigation journal

• short lab report

Lab Report Template

# Lab 01 — Build Your Ethical Hacking Lab

## Executive Summary

## Mission Objective

## Environment

## Lab Architecture

## Asset Inventory

## Network Configuration

## Isolation Controls

## Validation Performed

## Evidence

## Problems Encountered

## Resolution

## Security Considerations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1

Why should deliberately vulnerable machines generally not use bridged networking?

Answer: Because bridged networking can place the vulnerable system directly on the physical network, potentially exposing it to other devices or exposing those devices to the vulnerable system.

Question 2

Why do we use snapshots?

Answer: Snapshots provide a known restore point so the lab can be returned to a clean state after testing or configuration changes.

Question 3

What is the purpose of the Rules of Engagement?

Answer: They establish authorization, targets, boundaries, permitted activities, prohibited activities, and operating expectations for the assessment.

Question 4

What is the primary purpose of a host-only or internal network?

Answer: To provide controlled communication between authorized lab systems while reducing exposure to external networks.

Question 5

Why keep an asset inventory?

Answer: It establishes what systems belong to the authorized assessment environment and provides a reference for later testing and evidence.

Skills Achieved

After completing this lab, you should understand:

• ethical hacking lab architecture

• virtualization concepts

• attacker and target systems

• NAT networking

• bridged networking

• host-only networking

• internal networking

• network isolation

• private IP addressing

• VM snapshots

• Rules of Engagement

• asset inventories

• evidence organization

• security-lab documentation

Professional Takeaway

The first skill of a penetration tester is not exploitation.

It is control of the assessment environment.

A professional tester understands:

Scope → Authorization → Environment → Testing → Evidence → Reporting

If you cannot clearly identify which systems are authorized targets, security testing should not begin.

Your isolated environment is now ready for the next stage of the ethical hacking methodology.

What’s Next?

➡️ Lab 02 — Passive Reconnaissance & OSINT

In the next lab, you will begin the reconnaissance phase.

You will learn how publicly available information can be used to understand an organization’s potential external attack surface without immediately interacting with target services.

You will practice:

Scope → Information Collection → Validation → Attack-Surface Mapping → Documentation

The objective will not be to collect as much information as possible, but to determine:

Which information could meaningfully influence a security assessment?