Lab 03 Host Discovery & Network Mapping

Mission Overview

Welcome to Lab 03 — Host Discovery & Network Mapping.

In the previous lab, you used passive reconnaissance to build hypotheses about an external attack surface.

Now you move into active reconnaissance inside your authorized lab environment.

The objective is to determine:

• which systems are present

• which systems are reachable

• which addresses are active

• how the lab network is structured

• which assets should be investigated next

Mission Goal: Discover active hosts within the authorized lab network, verify their identities where possible, build an asset inventory, and create a basic network map.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Host Discovery
Secondary Skill	Network Mapping
Environment	Kali Linux + Isolated Lab Network
Testing Type	Active Reconnaissance
Primary Outcome	Verified Host Inventory
Evidence Required	Discovery output + screenshots + network map
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

• identify the network your assessment workstation is connected to

• understand IPv4 addresses and subnet notation

• identify the authorized discovery range

• discover active systems

• distinguish different discovery techniques

• interpret ICMP responses

• understand ARP-based discovery

• perform controlled discovery with Nmap

• identify MAC-address information on local networks

• validate discovery results

• recognize false negatives

• build an asset inventory

• create a basic network map

• document active reconnaissance professionally

Lab Architecture

A simple environment may look like:

                    GHC Ethical Hacking Lab
                        192.168.56.0/24
                              │
           ┌──────────────────┼──────────────────┐
           │                  │                  │
           ▼                  ▼                  ▼
        Kali Linux       Linux Target        Web Target
       192.168.56.10     192.168.56.20      192.168.56.30

Your addresses may be different.

Use the actual configuration of your environment.

Part 1 — Review the Rules of Engagement

Before performing active discovery, confirm the authorized network.

Example:

Authorized Network:

192.168.56.0/24

Allowed:

192.168.56.1 – 192.168.56.254

Not automatically authorized:

192.168.1.0/24

10.0.0.0/8

Public IP addresses

Corporate network addresses

Do not expand the scan range because another network appears in your routing table.

Part 2 — Create the Lab Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-03/
    ├── Notes/
    ├── Evidence/
    ├── Screenshots/
    ├── Discovery/
    ├── Network-Map/
    └── Report/

Create:

Lab-03-Investigation-Journal.md

Use:

# Lab 03 — Host Discovery & Network Mapping

## Mission Objective

## Authorized Network

## Kali IP Address

## Lab Interface

## Discovery Techniques

## Active Hosts

## Validation

## Asset Inventory

## Network Map

## Observations

## Evidence

## Lessons Learned

Part 3 — Identify Your Kali Network Configuration

On Kali, open a terminal.

Run:

ip addr

Look for the interface connected to your lab network.

Example:

eth1

inet 192.168.56.10/24

Record:

Interface: eth1

Kali IP: 192.168.56.10

Prefix: /24

The /24 tells us the size of the network.

Part 4 — Understand the Subnet

Suppose Kali has:

192.168.56.10/24

The network is typically:

192.168.56.0/24

The address range is approximately:

192.168.56.1
through
192.168.56.254

Important special addresses include:

Network Address:
192.168.56.0

Broadcast Address:
192.168.56.255

Do not treat those as normal host addresses.

Part 5 — Review the Routing Table

Run:

ip route

You may see something like:

192.168.56.0/24 dev eth1

This indicates that the lab network is directly reachable through that interface.

If Kali has a second NAT interface, you might also see a default route.

Example:

default via 10.0.2.2 dev eth0

Record only the network relevant to this lab.

Part 6 — Establish Known Hosts

Before scanning, list systems you already know exist.

Example:

Host	Expected Address	Role
Kali	192.168.56.10	Security Workstation
Linux Target	192.168.56.20	Training Server
Web Target	192.168.56.30	Vulnerable Web Application

This gives you a baseline for validating discovery.

Part 7 — Test a Known Host with Ping

From Kali:

ping -c 4 192.168.56.20

If the target responds, you may see:

64 bytes from 192.168.56.20

Record:

Host:

192.168.56.20

ICMP Response:

Yes

This confirms that the target is reachable through ICMP.

Part 8 — Understand What Ping Actually Proves

A successful ping generally tells you:

The system responded to an ICMP Echo Request.

It does not prove:

• which operating system is running

• which services are available

• whether vulnerabilities exist

• whether the target is secure

Also:

A failed ping does not necessarily mean the host is offline.

The system may simply block ICMP.

This distinction is essential.

Part 9 — Test Another Known Host

Try your second authorized target:

ping -c 4 192.168.56.30

Record whether it responds.

Your table may now look like:

Address	ICMP Response	Initial Status
192.168.56.20	Yes	Reachable
192.168.56.30	No	Unknown

Do not mark the second system as offline yet.

You need additional discovery methods.

Part 10 — Inspect the ARP / Neighbor Table

On a local network, Kali may learn which IP addresses correspond to MAC addresses.

Run:

ip neigh

You might see:

192.168.56.20 dev eth1 lladdr 08:00:27:xx:xx:xx REACHABLE

This provides:

• IP address

• interface

• MAC address

• neighbor state

Record relevant lab entries.

Part 11 — Why ARP Discovery Is Useful

ARP operates locally within the broadcast domain.

Conceptually:

Kali
  │
  ├── Who has 192.168.56.20?
  │
  ▼
Local Network
  │
  ▼
Target replies with MAC address

This means ARP-based discovery can identify local systems even if they do not respond to ICMP.

This makes it highly useful inside a local lab segment.

Part 12 — Perform an Nmap Host Discovery

Now perform a controlled host discovery across the authorized subnet.

Example:

nmap -sn 192.168.56.0/24

The option:

-sn

means host discovery without performing the normal port scan.

The objective is:

Identify hosts that appear to be up.

Do not expand the network range beyond your authorized lab.

Part 13 — Interpret the Results

Example output may identify:

Nmap scan report for 192.168.56.1
Host is up.

Nmap scan report for 192.168.56.10
Host is up.

Nmap scan report for 192.168.56.20
Host is up.

Nmap scan report for 192.168.56.30
Host is up.

Record the results.

Example:

IP Address	Status	Source
192.168.56.1	Up	Nmap
192.168.56.10	Up	Nmap
192.168.56.20	Up	Nmap
192.168.56.30	Up	Nmap

Do not assume every discovered address is a target.

For example:

192.168.56.1

could belong to the host-only adapter or hypervisor networking service.

Part 14 — Save the Discovery Results

Instead of relying only on screenshots, save the output.

Example:

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

This creates a normal text report.

Evidence quality improves when you retain the original output.

Part 15 — Compare Discovery Methods

You now have several sources:

Ping

ARP / Neighbor Table

Nmap Host Discovery

Create a comparison:

IP	Ping	Neighbor Data	Nmap	Conclusion
192.168.56.20	Yes	Yes	Up	Active
192.168.56.30	No	Yes	Up	Active
192.168.56.40	No	No	No	Unknown/Inactive

This demonstrates why professional discovery should not depend on one method.

Part 16 — Optional Local ARP Discovery

If an ARP discovery utility is available in your lab, it can provide another local-network view.

For example, identify your interface first:

ip addr

Then use your approved lab discovery tooling against the isolated segment.

The objective is to compare:

ARP-based discovery

with:

Nmap host discovery

Do not use ARP tools on networks outside your authorized lab.

Part 17 — Identify MAC Addresses

On local virtual networks, discovery results may reveal MAC addresses.

Example:

08:00:27:xx:xx:xx

The first portion of a MAC address may be associated with a vendor or virtual platform.

You might infer:

VirtualBox

VMware

Hyper-V

But vendor identification should be treated as supporting information rather than definitive system identification.

Part 18 — Build the Active Host Inventory

Create:

active-hosts.md

Use a table:

Asset ID	IP Address	MAC	Discovery Method	Status	Notes
HOST-01	192.168.56.10	—	Local	Active	Kali
HOST-02	192.168.56.20	—	ICMP/Nmap	Active	Linux target
HOST-03	192.168.56.30	—	ARP/Nmap	Active	Web target

Do not assign an operating system based solely on guesswork.

Part 19 — Verify Known Assets

Compare discovered addresses with your Lab 01 asset inventory.

You want to determine:

Known Asset
      ↓
Expected Address
      ↓
Observed Address
      ↓
Match?

Example:

Target-01

Expected:
192.168.56.20

Observed:
192.168.56.20

Status:
Verified

This is basic asset validation.

Part 20 — Investigate Unknown Addresses

Suppose discovery finds:

192.168.56.1

that was not in your asset inventory.

Do not immediately classify it as suspicious.

Ask:

• Could it be the host adapter?

• Could it be the hypervisor DHCP service?

• Could it be another VM?

• Is it within the authorized environment?

Document:

Address:

192.168.56.1

Classification:

Unknown Infrastructure

Investigation Required:

Yes

Asset discovery frequently identifies infrastructure components that were overlooked.

Part 21 — Validate Against the Hypervisor

Open your virtualization platform.

Review the network configuration.

Compare:

Hypervisor Network

Host Adapter

Kali

Target 01

Target 02

This allows you to map discovered addresses to actual lab systems.

Update the asset inventory accordingly.

Part 22 — Understand False Negatives

A false negative in discovery occurs when a host exists but the discovery process does not identify it.

Possible causes include:

• ICMP blocked

• firewall filtering

• system sleeping

• network misconfiguration

• discovery method limitations

• routing issues

This is why:

No response does not automatically equal no host.

Part 23 — Understand False Positives

Occasionally, a result may be misinterpreted as an active target.

Examples include:

• hypervisor adapters

• gateways

• DHCP services

• infrastructure addresses

The technical result may be correct, but your interpretation may be wrong.

Always validate asset identity.

Part 24 — Build the Network Map

Now represent the active systems visually.

Example:

                    Host Computer
                         │
                    Hypervisor
                         │
                  192.168.56.1
                         │
           GHC Lab — 192.168.56.0/24
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
       ▼                 ▼                 ▼
     Kali            Linux Target      Web Target
192.168.56.10      192.168.56.20     192.168.56.30

Keep this diagram simple.

Later labs will add:

• ports

• services

• trust relationships

• vulnerabilities

• attack paths

Part 25 — Add Asset Roles

A useful network map should show why each system exists.

For example:

192.168.56.10
Kali
Security Assessment Workstation

192.168.56.20
Linux Target
Intentionally Vulnerable Server

192.168.56.30
Web Target
Intentionally Vulnerable Application

This provides more context than IP addresses alone.

Part 26 — Identify Your Own System During Discovery

A very common beginner mistake is to treat the testing workstation as a target.

Always record your own address first.

Example:

Kali:

192.168.56.10

Then when it appears in discovery output, you immediately recognize it.

This prevents confusion.

Part 27 — Understand Broadcast Domains

Systems on the same local subnet generally share the same broadcast domain.

For your lab:

192.168.56.0/24

systems may communicate directly at Layer 2.

Conceptually:

             Local Broadcast Domain

 Kali ───── Linux ───── Web Target

This is one reason ARP discovery is useful.

As networks become segmented and routed, discovery becomes more complex.

Part 28 — Network Mapping vs Port Scanning

Keep these phases separate.

Host Discovery

Question:

Which systems appear to exist?

Port Scanning

Question:

Which services appear to be exposed by those systems?

The progression is:

Network
   ↓
Hosts
   ↓
Ports
   ↓
Services
   ↓
Applications
   ↓
Potential Vulnerabilities

Do not jump straight to vulnerability scanning without understanding the environment.

Part 29 — Prioritize Hosts for Next Investigation

Once the active host list is verified, classify assets.

Example:

Priority 1

Targets intentionally included for testing.

Linux Target

Web Target

Priority 2

Infrastructure requiring understanding.

Gateway

Virtual Network Adapter

Excluded

Kali testing workstation

Host operating system unless explicitly in scope

This gives you a clean target list for the next lab.

Part 30 — Create the Target Register

Example:

Target ID	IP	Role	In Scope	Next Action
TGT-01	192.168.56.20	Linux Server	Yes	Port Scan
TGT-02	192.168.56.30	Web Server	Yes	Port Scan
INF-01	192.168.56.1	Lab Infrastructure	No/Review	Document
TEST-01	192.168.56.10	Kali	No	Exclude

This target register will be used in Lab 04.

Part 31 — Evidence Collection

Capture:

Evidence 01

Kali network configuration.

ip addr

Evidence 02

Routing table.

ip route

Evidence 03

Known-host ping test.

Evidence 04

Neighbor/ARP information.

ip neigh

Evidence 05

Nmap host-discovery output.

Evidence 06

Saved discovery output.

Evidence 07

Active-host inventory.

Evidence 08

Updated asset inventory.

Evidence 09

Target register.

Evidence 10

Final network map.

Part 32 — Document Each Discovery

Use:

Evidence ID:

Date/Time:

Source System:

Network:

Discovery Technique:

Observed Address:

Observed MAC:

Result:

Interpretation:

Validation:

Example:

Evidence ID:
DISC-03

Technique:
Nmap host discovery

Address:
192.168.56.30

Observation:
Host reported active.

Validation:
Address matches known Web Target.

Conclusion:
Verified active target.

Part 33 — Mission Challenge

Without checking your Lab 01 inventory first, perform authorized discovery and determine:

Lab Network:

Kali IP:

Number of Active Hosts:

Host 01:

Host 02:

Host 03:

Unknown Infrastructure:

Hosts Responding to ICMP:

Hosts Not Responding to ICMP:

Hosts Identified Through Other Methods:

Authorized Targets:

Excluded Assets:

Afterward, compare your findings to the known environment.

Part 34 — Optional Troubleshooting Challenge

Configure one of your lab systems so that it does not respond to ICMP while remaining otherwise reachable.

Then repeat discovery.

Your objective is to observe:

Why relying on ping alone can produce incomplete results.

Restore the VM to its original state afterward if you changed its configuration.

Part 35 — Troubleshooting

No Hosts Discovered

Check:

Are the VMs running?

Are they connected to the same lab network?

Does Kali have the correct interface?

Is the subnet correct?

Did you accidentally scan the wrong network?

Kali Discovers Only Itself

Possible causes:

• targets connected to another virtual network

• incorrect adapter configuration

• targets powered off

• different subnet

Compare each VM’s hypervisor network configuration.

Ping Fails but Nmap Finds the Host

This is possible.

The target may not respond to ICMP, while another discovery technique identifies it.

Do not treat this as contradictory.

Unknown Host Appears

Do not immediately scan it more deeply.

First determine whether it is:

• authorized

• lab infrastructure

• another VM

• host system component

Scope comes before deeper testing.

Part 36 — Build the Final Asset Inventory

Your completed inventory might look like:

Asset ID	IP Address	Role	Discovery	Verified	In Scope
A-01	192.168.56.10	Kali	Local	Yes	No
A-02	192.168.56.20	Linux Target	ICMP/Nmap	Yes	Yes
A-03	192.168.56.30	Web Target	ARP/Nmap	Yes	Yes
A-04	192.168.56.1	Virtual Network	Discovery	Yes	No

This becomes one of the primary inputs for the next assessment phase.

Mission Deliverables

Complete:

• authorized network recorded

• Kali interface identified

• Kali IP address recorded

• routing table reviewed

• known host tested

• ICMP discovery performed

• neighbor/ARP information reviewed

• authorized Nmap host discovery completed

• raw discovery results saved

• active hosts verified

• unknown infrastructure classified

• asset inventory updated

• target register created

• network map created

• evidence captured

• final lab report completed

Lab Report Template

# Lab 03 — Host Discovery & Network Mapping

## Executive Summary

## Mission Objective

## Scope

## Authorized Network

## Assessment Workstation

## Discovery Methodology

## ICMP Discovery

## Local Network Discovery

## Nmap Host Discovery

## Active Host Inventory

## Asset Validation

## Unknown Infrastructure

## Target Register

## Network Map

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is host discovery?

Host discovery is the process of determining which systems appear to be active or reachable within an authorized network.

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

No.

The system may block ICMP or may be discoverable through another technique.

Question 3 — Why is ARP useful on a local network?

ARP can reveal IP-to-MAC relationships for systems on the local broadcast domain and may identify systems even when ICMP is unavailable.

Question 4 — What does this command do?

nmap -sn 192.168.56.0/24

It performs host discovery against the specified network without conducting the normal Nmap port scan.

Question 5 — Why should you identify your own Kali IP before scanning?

So you can distinguish the assessment workstation from actual target systems.

Question 6 — Why should an unknown discovered address not immediately be scanned more deeply?

Because it must first be identified and confirmed as being within the authorized scope.

Question 7 — What is the difference between host discovery and port scanning?

Host discovery identifies systems.

Port scanning investigates exposed network services on those systems.

Skills Achieved

After completing this lab, you should understand:

• IPv4 addressing

• subnet notation

• network ranges

• routing-table interpretation

• ICMP host discovery

• ARP/neighbor discovery

• Nmap host discovery

• discovery-method limitations

• false negatives

• asset verification

• target classification

• active-host inventory

• target registers

• network mapping

• evidence collection

• active reconnaissance documentation

Professional Takeaway

Professional network reconnaissance does not begin by asking:

“What can I scan?”

It begins with:

“What network am I authorized to assess, what assets exist inside that boundary, and how can I verify them?”

The methodology is:

Scope → Network → Discover → Correlate → Verify → Inventory → Map → Prioritize → Document

Once you know which systems actually exist, you can begin asking the next question:

What services are those systems exposing?

What’s Next?

➡️ Lab 04 — Port Scanning & Service Discovery

In the next lab, you will take the verified targets from your Target Register and investigate their exposed network services.

You will learn how to move systematically from:

Host → Port → Protocol → Service → Version → Security Relevance

By the end of Lab 04, you should be able to answer:

“Which network services are exposed by each authorized target, and which services deserve deeper enumeration?”