Lab 02 Network Discovery & Host Identification

Mission Overview

Welcome to Lab 02 — Network Discovery & Host Identification.

In Lab 01, you built and validated an isolated network pentesting environment.

Now you will begin the first real assessment activity:

Identify which systems are actually present on the authorized network.

This sounds simple, but professional network discovery requires more than sending a few pings.

A host may be active even when:

• ICMP is blocked

• a firewall filters probes

• the system is temporarily silent

• only certain protocols respond

• ARP reveals the system while ping does not

• the host is present but outside your expected asset list

The goal of this lab is to teach you how to establish a reliable network inventory before moving into port scanning and service enumeration.

Mission Goal: Discover and identify active hosts on the authorized lab network, compare discovered systems against the known asset inventory, classify host status carefully, and produce a validated Network Asset Register.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Network Discovery
Secondary Skill	Host Identification
Environment	GoHackersCloud Network Pentesting Lab
Authorized Range	192.168.56.0/24
Primary Outcome	Validated Network Asset Register
Safety Level	Authorized Training Network Only

Learning Objectives

By completing this lab, you will be able to:

• confirm the authorized subnet before testing

• identify the local pentest interface

• understand CIDR boundaries

• discover hosts using multiple methods

• understand ARP-based discovery

• understand ICMP-based discovery

• identify hosts that do not respond to ping

• collect IP and MAC information

• recognize duplicate or unexpected systems

• compare discovered assets with known assets

• classify host status

• document evidence

• build a professional host inventory

• distinguish discovery evidence from assumptions

Discovery Methodology

Use:

Scope → Network → Discover → Identify → Validate → Inventory

Conceptually:

Authorized Scope
      │
      ▼
Local Network Context
      │
      ▼
ARP Discovery
      │
      ▼
ICMP / Host Discovery
      │
      ▼
Alternative Discovery Evidence
      │
      ▼
Host Identification
      │
      ▼
Known vs Discovered Comparison
      │
      ▼
Validated Asset Inventory

The key principle is:

No single discovery technique should be treated as absolute proof that every other host is absent.

Part 1 — Confirm Authorization Before Discovery

Open your Lab 01 scope document.

Confirm:

Authorized Network:
192.168.56.0/24

Authorized Pentest Host:
192.168.56.10

Known Linux Target:
192.168.56.20

Known Windows Target:
192.168.56.30

Optional Web Target:
192.168.56.40

Record:

Scope Verified:
Yes / No

Authorized CIDR:

Date:

Investigator:

If your real lab uses different addresses, use your actual authorized range.

Part 2 — Understand CIDR Scope

The network:

192.168.56.0/24

typically covers:

192.168.56.0
through
192.168.56.255

with usable host addressing usually between:

192.168.56.1
through
192.168.56.254

depending on the network design.

Do not automatically test another subnet.

For example:

192.168.57.0/24

is a different network and should not be included unless explicitly authorized.

Part 3 — Create the Lab Workspace

Create:

Network-Pentesting-Labs/
└── Lab-02/
    ├── Scope/
    ├── Notes/
    ├── Discovery/
    │   ├── Local-Network/
    │   ├── ARP/
    │   ├── ICMP/
    │   └── Host-Discovery/
    ├── Assets/
    ├── Evidence/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-02-Network-Discovery-Journal.md

Suggested structure:

# Lab 02 — Network Discovery & Host Identification

## Mission Objective

## Authorization

## Authorized Network

## Pentest Workstation

## Local Network Context

## Known Asset Baseline

## ARP Discovery

## ICMP Discovery

## Additional Host Discovery

## Discovered Asset Register

## Known vs Discovered Comparison

## Unexpected Systems

## Findings

## Limitations

## Conclusion

Part 4 — Verify the Pentest Interface

On the pentest workstation:

ip addr

Identify the lab interface.

Record:

Interface:

IPv4 Address:

CIDR:

MAC Address:

Expected example:

Interface:
eth1

IPv4:
192.168.56.10/24

Part 5 — Verify the Route

Run:

ip route

Look for the lab route.

Example:

192.168.56.0/24 dev eth1

Record:

Authorized Route:

Interface:

Route Present:
Yes / No

If the route is not present, resolve the network issue before discovery.

Part 6 — Confirm You Are Not Using the Wrong Interface

A pentest VM may have:

eth0 → NAT / Internet
eth1 → Lab Network

Do not confuse the two.

Create:

Interface	Network	Purpose
eth0	NAT	Updates
eth1	192.168.56.0/24	Pentest Lab

The actual interface names may differ.

Part 7 — Review the Known Asset Baseline

From Lab 01, your expected assets may be:

Asset ID	Hostname	IP	Role
NET-01	pentest01	192.168.56.10	Pentest
NET-02	linux-target	192.168.56.20	Linux
NET-03	WIN-TARGET	192.168.56.30	Windows
NET-04	web-target	192.168.56.40	Optional

This is your known inventory.

The discovery exercise will tell you what is actually visible.

Part 8 — Understand Discovery Sources

A host may be identified through:

ARP

ICMP

TCP response

UDP response

DNS

DHCP

MAC address

Known configuration

Network logs

Discovery is therefore a correlation process.

Part 9 — Start with the Local ARP Table

Before active discovery, inspect what your workstation already knows.

Run:

ip neigh

or:

arp -n

You may see entries such as:

192.168.56.20
192.168.56.30

Record:

IP	MAC	State	Source
			ARP cache

Part 10 — Understand ARP

ARP helps IPv4 systems on the same local Layer 2 network determine:

IP Address
     ↓
MAC Address

Conceptually:

Who has 192.168.56.20?
       ↓
192.168.56.20 replies with MAC address

This is especially useful on a local Ethernet segment.

Part 11 — Understand Why ARP Is Valuable

A host may block ICMP.

But on the same Layer 2 segment, it may still need to answer ARP for local communication.

Therefore:

No Ping Response
      +
ARP Response
      =
Host Likely Present

This is why professional discovery should not rely only on ping.

Part 12 — Perform Authorized ARP Discovery

On a local training network, an ARP discovery utility can identify neighboring hosts.

Use an approved discovery tool available in your environment.

If using Nmap on your isolated lab:

nmap -sn 192.168.56.0/24

On a directly connected Ethernet network, Nmap may use ARP discovery automatically for local hosts.

Record only the authorized range.

Part 13 — Understand -sn

In Nmap:

-sn

means:

Host discovery without a port scan.

This is appropriate for this lab because the objective is:

Find hosts first.

Port scanning comes in Lab 03.

Part 14 — Save the Discovery Output

Instead of relying only on the terminal, preserve output.

Example:

nmap -sn 192.168.56.0/24 -oN Discovery/nmap-host-discovery.txt

This gives you evidence for the report.

Record:

Command:

Target:

Timestamp:

Output File:

Part 15 — Review the Results

Example results may indicate:

192.168.56.10
Host is up

192.168.56.20
Host is up

192.168.56.30
Host is up

Do not immediately assume an unlisted address is inactive.

We will validate with additional methods.

Part 16 — Build the Initial Discovery Register

Create:

Host ID	IP	Discovery Method	Status
DISC-01	192.168.56.10	Local	Active
DISC-02	192.168.56.20	ARP/Discovery	Active
DISC-03	192.168.56.30	ARP/Discovery	Active

Part 17 — Perform ICMP Testing

Test known hosts individually.

For Linux:

ping -c 4 192.168.56.20

For Windows target:

ping -c 4 192.168.56.30

Record:

Host	Ping Result	Interpretation
Linux	Reply	ICMP reachable
Windows	No reply	ICMP unknown/filtered

Part 18 — Understand ICMP Limitations

Do not write:

“Windows host is offline because ping failed.”

Instead:

“The Windows target did not respond to the ICMP echo test.”

That is the defensible statement.

Possible explanations:

Host Offline

ICMP Disabled

Host Firewall

Network ACL

Packet Filtering

Temporary Loss

Part 19 — Compare ARP and ICMP

Build:

IP	ARP Evidence	ICMP Evidence	Assessment
.20	Yes	Yes	Active
.30	Yes	No	Active, ICMP filtered/disabled

This comparison is one of the main lessons of the lab.

Part 20 — Perform a Discovery Scan Without Relying on Ping

In an authorized lab, you can instruct a scanner to treat a known host as available for subsequent assessment.

For this lab, use that concept only to understand discovery limitations.

Do not begin the full port scan yet.

The important distinction is:

Host Discovery
      ≠
Port Enumeration

Part 21 — Inspect the ARP Cache Again

After discovery:

ip neigh

You may now see additional entries.

Record:

Before Discovery:
Number of neighbors

After Discovery:
Number of neighbors

Explain why the cache changed.

Part 22 — Build the MAC Address Register

Create:

IP	MAC Address	Vendor Context	Confidence
192.168.56.20		VM/Unknown	High
192.168.56.30		VM/Unknown	High

Do not overinterpret vendor information.

Virtual machines may use MAC ranges associated with the hypervisor.

Part 23 — Identify Duplicate IP Problems

Watch for signs such as:

• inconsistent MAC addresses

• intermittent connectivity

• ARP entries changing unexpectedly

Create:

Duplicate IP Suspected:
Yes / No

Affected Address:

Evidence:

If two systems share an IP, fix the lab before continuing.

Part 24 — Identify Unexpected Hosts

Suppose discovery reveals:

192.168.56.50

but that address is not in your known inventory.

Do not immediately scan it deeply.

First ask:

Is this system authorized?

Create:

IP	Known Asset	Authorized	Action
192.168.56.50	No	Unknown	Stop and verify

Part 25 — Follow the Stop Condition

If an unknown system appears:

Unexpected Host
      ↓
Stop Further Testing
      ↓
Identify Owner
      ↓
Confirm Scope
      ↓
Continue Only if Authorized

This is professional pentesting discipline.

Part 26 — Compare Known vs Discovered Assets

Create:

Expected IP	Expected Host	Discovered	Status
.10	pentest01	Yes	Expected
.20	linux-target	Yes	Expected
.30	WIN-TARGET	Yes	Expected
.40	web-target	No	Not Running

This comparison helps identify:

• missing expected hosts

• unexpected hosts

• configuration errors

Part 27 — Classify Host Status

Use:

Confirmed Active

Multiple discovery methods support presence.

Active — Limited Response

Host presence is confirmed but some discovery methods are blocked.

Expected but Not Observed

Known asset did not appear during discovery.

Unexpected

System appears but is not part of known inventory.

Unverified

Insufficient evidence.

Part 28 — Build the Validated Host Register

Create:

Host ID	IP	MAC	Discovery Evidence	Classification
HOST-01	.20		ARP + ICMP	Confirmed Active
HOST-02	.30		ARP	Active — Limited Response

Part 29 — Identify Hostnames Where Available

A hostname may be learned through:

• known configuration

• DNS

• DHCP

• reverse resolution

• application evidence

Do not assume an IP maps to a hostname solely based on memory.

Document the source.

Example:

IP	Hostname	Source
.20	linux-target	Known baseline
.30	WIN-TARGET	Known baseline

Part 30 — Perform Reverse Name Resolution Where Appropriate

If your lab has DNS configured, you may query the IP.

For example:

nslookup 192.168.56.20

or:

dig -x 192.168.56.20

Record:

IP:

Returned Name:

Resolver:

Result:

A failed reverse lookup does not mean the host does not exist.

Part 31 — Understand DNS Limitations

DNS is not a complete inventory source.

Reasons include:

No PTR record

Stale record

Dynamic addressing

Unregistered device

Local-only hostname

Therefore:

No DNS Record
    ≠
No Host

Part 32 — Compare Discovery Methods

Build:

IP	ARP	ICMP	DNS	Known Config	Final Status
.20	Yes	Yes	Maybe	Yes	Active
.30	Yes	No	Maybe	Yes	Active

This is your Host Validation Matrix.

Part 33 — Build the Discovery Evidence Chain

For each important host:

IP Address
    +
ARP Response
    +
MAC
    +
Known Baseline
    +
Optional ICMP/DNS
    =
Validated Host Identity

Part 34 — Understand Layer 2 vs Layer 3 Discovery

ARP generally operates locally at Layer 2.

ICMP is Layer 3.

This means:

ARP Discovery

is most useful on directly connected local networks.

Across routers, you typically need other discovery methods.

This becomes important later in segmented networks.

Part 35 — Understand Why Routed Networks Are Different

Suppose:

Pentest Network
192.168.56.0/24
       │
     Router
       │
192.168.57.0/24
Server Network

Your attacker workstation will not normally receive ARP responses directly from hosts on .57.0/24.

The router handles Layer 2 communication between segments.

Later labs will cover segmentation and routed reachability.

Part 36 — Identify Your Default Gateway

On the pentest VM:

ip route

Record:

Default Gateway:

Lab Gateway:

Same or Different:

For a fully isolated single-subnet lab, no lab gateway may exist.

Part 37 — Observe Broadcast Behavior

IPv4 local networks may use broadcast traffic for various functions.

Do not assume every broadcast packet identifies an active application host.

Host discovery should use evidence relevant to the target.

Part 38 — Build a Network Discovery Map

Example:

            192.168.56.0/24
                   │
       ┌───────────┼───────────┐
       │           │           │
       ▼           ▼           ▼
 .10 pentest   .20 Linux    .30 Windows
 Active        Active       Active
 ARP+ICMP      ARP+ICMP     ARP only

Add .40 if the optional target is running.

Part 39 — Create an Unexpected Asset Register

Even if no unexpected systems exist, create:

Asset	Status	Action
None	No unexpected assets identified	N/A

This demonstrates that the check was performed.

Part 40 — Identify Silent Hosts Conceptually

Some systems deliberately provide minimal network responses.

For example:

No ICMP

Only one TCP service

Host firewall enabled

This does not make the host invisible.

It means:

Discovery requires more than one evidence source.

Part 41 — Do Not Infer Operating System Yet

At this stage, avoid:

Port behavior
→ Definitely Windows

or:

TTL
→ Definitely Linux

Those can be clues, but OS identification belongs later in the workflow.

For now, use known baseline information only.

Part 42 — Create the Discovery Journal

Record each discovery activity:

Timestamp:

Method:

Target:

Purpose:

Result:

Evidence File:

Interpretation:

Example:

Time:
10:15

Method:
ICMP echo

Target:
192.168.56.30

Result:
No response

Interpretation:
ICMP reachability not established.

Additional Evidence:
ARP response confirms host presence.

Part 43 — Separate Observation from Interpretation

Observation

192.168.56.30 did not reply to ICMP echo requests.

Interpretation

ICMP may be disabled or filtered.

Unsupported conclusion

The host is offline.

Do not make the last statement when ARP evidence proves otherwise.

Part 44 — Example Finding — ICMP Restricted

Finding Type:
Observation

Asset:
192.168.56.30

Observation:
The target did not respond to ICMP echo requests while Layer 2
discovery identified the system as active.

Interpretation:
ICMP responses appear restricted or disabled.

Security Impact:
None by itself. This represents discovery behavior rather than a
vulnerability.

Evidence:
ARP discovery and ICMP test results.

Not every observation should become a vulnerability.

Part 45 — Example Finding — Unexpected Host

Only where applicable:

Finding:
An unexpected system was identified within the authorized lab
network.

Evidence:
Host discovery identified 192.168.56.50, which does not appear in
the known asset baseline.

Action:
Further assessment was stopped pending confirmation that the host
is authorized.

Status:
Scope Verification Required.

This demonstrates professional conduct.

Part 46 — Create the Network Asset Register

Final register:

Asset ID	IP	MAC	Hostname	Role	Status	Evidence
A-01	.10		pentest01	Pentest	Active	Local
A-02	.20		linux-target	Linux	Active	ARP+ICMP
A-03	.30		WIN-TARGET	Windows	Active	ARP

Part 47 — Create the Host Discovery Summary

Record:

Authorized Range:

Expected Hosts:

Hosts Discovered:

Confirmed Active:

Limited-Response Hosts:

Expected but Missing:

Unexpected Hosts:

Scope Violations:

Part 48 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Network Discovery & Host Identification

Authorized Network:

Pentest Workstation:

Lab Interface:

Pentest IP:


KNOWN ASSETS

Expected Host 01:

Expected Host 02:

Expected Host 03:

Optional Host:


DISCOVERY

Local Route Verified:
Yes / No

ARP Discovery Performed:
Yes / No

ICMP Testing Performed:
Yes / No

DNS/Hostname Checks:
Yes / No


HOST 01

IP:

MAC:

Hostname:

ARP Response:

ICMP Response:

DNS Result:

Known Asset:
Yes / No

Final Classification:


HOST 02

IP:

MAC:

Hostname:

ARP Response:

ICMP Response:

DNS Result:

Known Asset:
Yes / No

Final Classification:


HOST 03

IP:

MAC:

Hostname:

ARP Response:

ICMP Response:

DNS Result:

Known Asset:
Yes / No

Final Classification:


SCOPE VALIDATION

Unexpected Hosts:

Unauthorized Systems Tested:
Yes / No

Expected:
No


FINAL DISCOVERY

Total Hosts Identified:

Confirmed Active:

Active with Limited Response:

Unverified:

Expected but Missing:

Unexpected:


FINAL CONCLUSION

Was the authorized network successfully inventoried?

Which discovery method produced the strongest evidence?

Which host behaved differently?

Were any scope issues identified?

Is the environment ready for TCP port scanning?
Yes / No

Part 49 — What Not to Do

Do not:

Scan outside the authorized CIDR

Assume neighboring networks are in scope

Treat ping failure as proof a host is offline

Deep-scan unexpected systems before authorization

Assume every ARP entry is an authorized target

Assume DNS is complete

Assume hostname means identity is verified

Guess operating systems from weak indicators

Begin exploitation during discovery

Treat discovery behavior as a vulnerability

Ignore duplicate IP behavior

Ignore unexpected MAC changes

Continue if scope becomes uncertain

Troubleshooting

No Hosts Are Discovered

Check:

ip addr

Then:

ip route

Confirm the VMs are on the same virtual network.

Linux Responds but Windows Does Not

Windows may block ICMP.

Check ARP discovery before concluding the host is unavailable.

Nmap Shows Only the Pentest Host

Check whether the targets are powered on.

Also verify:

• virtual network name

• host-only/internal adapter

• subnet configuration

• target firewall behavior

ARP Shows an Unexpected Address

Do not continue testing that system automatically.

Confirm whether it belongs to:

• the hypervisor

• host adapter

• router/firewall VM

• another authorized lab VM

MAC Address Changes

Possible causes include:

• VM reconfiguration

• cloned VM

• duplicate addressing

• network adapter regeneration

Update the Asset Register only after validation.

Evidence Requirements

Capture:

Evidence 01

Authorized scope confirmation.

Evidence 02

Pentest workstation ip addr.

Evidence 03

Pentest workstation ip route.

Evidence 04

Known Asset Baseline.

Evidence 05

Initial ARP table.

Evidence 06

Host discovery output.

Evidence 07

Linux ICMP test.

Evidence 08

Windows ICMP test.

Evidence 09

Updated ARP table.

Evidence 10

MAC Address Register.

Evidence 11

Known vs Discovered Matrix.

Evidence 12

Host Validation Matrix.

Evidence 13

Unexpected Asset Register.

Evidence 14

Network Discovery Map.

Evidence 15

Validated Network Asset Register.

Evidence 16

Final Discovery Summary.

Mission Deliverables

Complete:

• authorization verified

• lab subnet confirmed

• pentest interface confirmed

• route confirmed

• known assets documented

• ARP table reviewed

• authorized host discovery performed

• ICMP tests performed

• ARP and ICMP compared

• MAC addresses recorded

• DNS/reverse lookup checked where available

• hostnames documented with evidence source

• duplicate IP issues checked

• unexpected assets checked

• scope stop conditions followed

• host classifications assigned

• known vs discovered comparison completed

• Host Validation Matrix completed

• network discovery map created

• final Asset Register completed

• journal updated

• discovery report completed

Lab Report Template

# Lab 02 — Network Discovery & Host Identification

## Executive Summary

## Mission Objective

## Authorization and Scope

## Authorized Network

## Pentest Workstation

## Known Asset Baseline

## Discovery Methodology

## Local Network Context

## ARP Discovery

## ICMP Discovery

## DNS and Hostname Identification

## MAC Address Analysis

## Discovered Hosts

## Host Validation Matrix

## Known vs Discovered Comparison

## Unexpected Assets

## Scope Verification

## Observations

## Limitations

## Final Network Asset Register

## Conclusion

Knowledge Check

Question 1 — What is the primary goal of host discovery?

To determine which systems are present and reachable within the authorized network.

Question 2 — Does a failed ping prove a system is offline?

No.

ICMP may be filtered or disabled.

Question 3 — Why is ARP useful for local network discovery?

Because local IPv4 systems generally need ARP to map IP addresses to MAC addresses.

Question 4 — Can ARP discover hosts across a router?

Generally not directly, because ARP operates on the local Layer 2 segment.

Question 5 — Why compare discovered assets against the known inventory?

To identify missing, unexpected, or incorrectly configured systems.

Question 6 — What should you do if an unknown host appears?

Stop deeper testing and verify that it is authorized.

Question 7 — Does failure of reverse DNS mean the host does not exist?

No.

The host may simply lack a PTR record.

Question 8 — Should every discovery observation become a vulnerability?

No.

Many discovery results are simply environmental observations.

Question 9 — What produces stronger host validation than a single ping?

Multiple independent signals such as ARP, ICMP, MAC information, DNS, and known configuration.

Question 10 — What is the key discovery principle?

Absence of one type of response is not proof of host absence.

Skills Achieved

After completing this lab, you should understand:

• authorized network discovery

• CIDR boundaries

• local network context

• route validation

• ARP discovery

• ICMP discovery

• discovery limitations

• MAC address collection

• hostname validation

• DNS limitations

• known-vs-discovered comparison

• unexpected asset handling

• scope discipline

• host classification

• discovery evidence collection

• professional network inventory creation

Professional Takeaway

Professional network discovery is not:

Ping
  ↓
Reply = Alive
No Reply = Dead

The better model is:

Known Scope
     +
ARP
     +
ICMP
     +
MAC
     +
DNS
     +
Network Context
     =
Validated Host Inventory

Always distinguish:

No Ping Reply
      ≠
Host Offline

Discovered Host
      ≠
Authorized Target

DNS Name
      ≠
Verified Identity

Host Active
      ≠
Host Vulnerable

The professional workflow is:

Scope → Discover → Correlate → Validate → Inventory

And before moving forward, you should be able to answer confidently:

“Which hosts are present on the authorized network, what evidence confirms their presence, and which systems are actually approved for further assessment?”

What’s Next?

➡️ Lab 03 — TCP Port Scanning & Service Discovery

In the next lab, you will take the validated host inventory and determine which TCP services are remotely exposed.

You will learn:

• TCP connection concepts

• open, closed, and filtered states

• targeted vs broader scans

• port-range selection

• service identification

• basic banner/version information

• scan timing and accuracy

• comparing remote observations with the Lab 01 service baseline

• building a TCP Port & Service Register

The methodology becomes:

Validated Host → TCP Ports → Port State → Service → Evidence → Attack Surface

The central question will be:

“Which TCP services are exposed by each authorized host, and what does that exposure tell us about the network attack surface?”