Lab 04 Port Scanning & Service Discovery

Mission Overview

Welcome to Lab 04 — Port Scanning & Service Discovery.

In Lab 03, you identified which hosts were active inside the authorized lab network.

Now you will take those verified targets and answer the next critical question:

What network services are exposed by each system?

This is where reconnaissance becomes much more useful.

A reachable host tells you a system exists.

An exposed port begins to tell you what the system does.

Mission Goal: Perform controlled port scanning against authorized lab targets, identify exposed services, determine likely service versions, and build a prioritized service inventory for deeper enumeration.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Port Scanning
Secondary Skill	Service Discovery
Environment	Kali Linux + Authorized Lab Targets
Testing Type	Active Reconnaissance
Primary Outcome	Port & Service Inventory
Evidence Required	Scan outputs + findings table + screenshots
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

explain what network ports represent
distinguish TCP and UDP
understand open, closed, and filtered states
perform targeted TCP scanning
perform full TCP port scanning
perform service-version detection
interpret Nmap results
identify likely application protocols
understand why service banners matter
distinguish port numbers from actual services
avoid blindly trusting automatic fingerprinting
prioritize services for later enumeration
create a professional service inventory
document scan evidence properly

Lab Architecture

Use the same isolated environment from the previous labs.

Example:

                    GHC Ethical Hacking Lab
                        192.168.56.0/24
                              │
             ┌────────────────┴────────────────┐
             │                                 │
             ▼                                 ▼
        Linux Target                      Web Target
       192.168.56.20                     192.168.56.30
             ▲                                 ▲
             │                                 │
             └────────── Kali Linux ───────────┘
                         192.168.56.10

Only scan systems explicitly listed as authorized targets.

Part 1 — Review the Target Register

Use the target register created in Lab 03.

Example:

Target ID	IP Address	Role	In Scope
TGT-01	192.168.56.20	Linux Server	Yes
TGT-02	192.168.56.30	Web Target	Yes
INF-01	192.168.56.1	Lab Infrastructure	No
TEST-01	192.168.56.10	Kali	No

For this mission, scan only:

192.168.56.20
192.168.56.30

Do not include infrastructure or host systems unless explicitly authorized.

Part 2 — Create the Lab Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-04/
    ├── Notes/
    ├── Evidence/
    ├── Screenshots/
    ├── Scans/
    │   ├── Initial/
    │   ├── Full-TCP/
    │   └── Service-Detection/
    ├── Findings/
    └── Report/

Create:

Lab-04-Investigation-Journal.md

Use:

# Lab 04 — Port Scanning & Service Discovery

## Mission Objective

## Scope

## Authorized Targets

## Initial Scans

## Full TCP Scans

## Service Detection

## Exposed Ports

## Service Inventory

## Observations

## Priorities

## Evidence

## Lessons Learned

Part 3 — Understand Network Ports

A network service generally listens on a port.

Conceptually:

Host
 │
 ├── Port 22   → SSH
 ├── Port 80   → HTTP
 ├── Port 443  → HTTPS
 └── Port 3306 → Database

A port number is simply part of how network communication is directed to a service.

Valid TCP and UDP port numbers range from:

0–65535

Common port ranges are often grouped as:

0–1023
Well-known ports

1024–49151
Registered ports

49152–65535
Dynamic / ephemeral ports

Do not assume that a service must use its traditional port.

For example, HTTP could technically run on port 8080, 8000, or another configured port.

Part 4 — TCP vs UDP

Two important transport protocols are:

TCP

Connection-oriented.

Common services include:

SSH
HTTP
HTTPS
SMB
FTP
Databases

UDP

Connectionless.

Common examples include:

DNS
DHCP
SNMP
NTP

UDP discovery behaves differently and can be slower or less conclusive.

For this lab, focus primarily on TCP.

Part 5 — Understand Port States

Nmap may classify ports using states such as:

Open

A service appears to be accepting connections.

22/tcp open ssh

Closed

The host is reachable, but nothing appears to be listening on the port.

23/tcp closed telnet

Filtered

A filtering device or rule prevents Nmap from confidently determining whether the port is open.

445/tcp filtered microsoft-ds

Other states may also appear depending on the scan type.

The key lesson is:

Port state is an observation, not automatically a vulnerability.

Part 6 — Confirm Target Reachability

Before port scanning, verify your target list.

For example:

nmap -sn 192.168.56.20 192.168.56.30

This confirms whether Nmap identifies the hosts as reachable.

If a known host does not appear active but is confirmed to exist, you can still investigate it appropriately within the lab.

Part 7 — Perform an Initial TCP Scan

Begin with a standard scan against the first target.

Example:

nmap 192.168.56.20

By default, Nmap scans a commonly used set of TCP ports.

Example output could resemble:

PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
3306/tcp open  mysql

Your output will depend on your target.

Save the result.

nmap 192.168.56.20 -oN Scans/Initial/TGT-01-initial.txt

Part 8 — Interpret the Initial Results

Suppose you observe:

21/tcp open ftp
22/tcp open ssh
80/tcp open http

Do not jump immediately to exploitation.

Instead ask:

Why is this service exposed?

Is it expected?

What software is running?

What version appears to be in use?

Does the service require authentication?

Should the service be accessible from this network?

What should be enumerated next?

This is service-oriented thinking.

Part 9 — Scan the Second Target

Repeat the same process for the second authorized system.

nmap 192.168.56.30 -oN Scans/Initial/TGT-02-initial.txt

Compare the results.

Example:

Target	Open Ports
TGT-01	21, 22, 80
TGT-02	80, 443, 8080

This already begins to show that the targets serve different purposes.

Part 10 — Understand the Default Scan Limitation

A standard Nmap scan does not normally scan every TCP port.

This means a service listening on a less common port may not appear.

For a controlled lab target, you can perform a full TCP port scan.

Part 11 — Perform a Full TCP Port Scan

Example:

nmap -p- 192.168.56.20

The option:

-p-

requests all TCP ports.

Conceptually:

1 → 65535

Save the output:

nmap -p- 192.168.56.20 -oN Scans/Full-TCP/TGT-01-full-tcp.txt

Repeat for your second target:

nmap -p- 192.168.56.30 -oN Scans/Full-TCP/TGT-02-full-tcp.txt

Because this is more comprehensive than the default scan, it may take longer.

Part 12 — Compare Initial vs Full Scan

Create a comparison.

Example:

Target	Initial Scan	Full TCP Scan	Additional Ports
TGT-01	22, 80	22, 80, 8080	8080
TGT-02	80, 443	80, 443, 9000	9000

This demonstrates why scan strategy matters.

Part 13 — Perform Service Version Detection

Now investigate the open ports more deeply.

For example, if the full scan identifies:

22
80
8080

you can target only those ports:

nmap -sV -p 22,80,8080 192.168.56.20

The option:

-sV

requests service-version detection.

Save the results:

nmap -sV -p 22,80,8080 192.168.56.20 -oN Scans/Service-Detection/TGT-01-services.txt

Part 14 — Understand Service Detection

Instead of simply reporting:

80/tcp open http

service detection may provide something closer to:

80/tcp open http Apache httpd

or possibly include a version.

This provides more context.

The progression becomes:

Host
 ↓
Port
 ↓
Protocol
 ↓
Service
 ↓
Product
 ↓
Version

This information will later support vulnerability analysis.

Part 15 — Do Not Blindly Trust Service Detection

Automated service detection is extremely useful, but it is not infallible.

Applications can:

run on unusual ports
hide version information
return misleading banners
sit behind proxies
be customized

Therefore:

Nmap Result
    ↓
Evidence
    ↓
Interpretation
    ↓
Validation

rather than:

Nmap Result
    ↓
Absolute Truth

Part 16 — Service Name vs Actual Service

Suppose the output shows:

8080/tcp open http-proxy

Do not assume that a traditional proxy server is definitely running.

Sometimes Nmap uses the port number to suggest a likely service name.

Service detection and later enumeration can give you better evidence.

This distinction is important.

Part 17 — Build a Service Inventory

Create:

service-inventory.md

Example:

Target	Port	Protocol	State	Detected Service	Version	Confidence
TGT-01	22	TCP	Open	SSH	Unknown	Medium
TGT-01	80	TCP	Open	HTTP	Apache	High
TGT-02	443	TCP	Open	HTTPS	Web Service	Medium

Add notes where required.

Part 18 — Identify High-Value Services

Different services may deserve different investigation priorities.

For example:

Remote Administration

SSH
RDP
WinRM

Web Services

HTTP
HTTPS
8080
8443

SMB
FTP
NFS

Databases

MySQL
PostgreSQL
Microsoft SQL Server

Directory / Identity

LDAP
Kerberos

The objective is not to label these services as vulnerable.

The objective is to determine:

Which services deserve deeper enumeration?

Part 19 — Create a Service Priority Matrix

Use:

Service	Exposure	Importance	Next Action
SSH	Open	Medium	Enumerate configuration
HTTP	Open	High	Web enumeration
SMB	Open	High	SMB enumeration
Database	Open	High	Validate intended exposure

This helps you move from scanning to structured investigation.

Part 20 — Scan Specific Ports

If you already know which ports matter, you can perform a targeted scan.

Example:

nmap -p 22,80,443 192.168.56.20

This is often more efficient than repeatedly scanning all ports.

A professional tester adjusts the scan based on the question being asked.

Part 21 — Understand SYN Scanning

Depending on privileges and environment, Nmap may use a TCP SYN scan.

You may explicitly encounter:

sudo nmap -sS 192.168.56.20

Conceptually:

Tester sends SYN
       ↓
Target response
       ↓
Nmap interprets port state

You do not need to memorize packet-level behavior yet.

Understand that different scan techniques can infer service availability in different ways.

Part 22 — Understand TCP Connect Scanning

Another common scan type is:

nmap -sT 192.168.56.20

A TCP connect scan uses the operating system to establish a normal TCP connection.

The exact technique matters less at this stage than understanding:

Different scanning methods can produce different network behavior and visibility.

Part 23 — Observe Traffic with Wireshark

Optional but highly recommended.

Start Wireshark on your Kali lab interface.

Then run a small targeted scan such as:

nmap -p 22,80 192.168.56.20

Observe the packets.

Look for:

SYN

SYN/ACK

RST

This connects your scanning knowledge with networking fundamentals.

Part 24 — Understand the TCP Handshake

A successful TCP connection normally begins:

Client              Server

 SYN       ────────►

           ◄──────── SYN/ACK

 ACK       ────────►

Simplified:

SYN → SYN/ACK → ACK

Port scanners often use responses around this process to infer port states.

Understanding TCP makes scanning results easier to interpret.

Part 25 — Why Closed Ports Still Matter

Suppose a scan shows many closed ports.

That still provides useful information.

A closed port can suggest:

the host is reachable
no service is listening there
traffic is not being silently filtered

The absence of a service is still part of attack-surface mapping.

Part 26 — Why Filtered Ports Matter

Suppose you see:

445/tcp filtered

This can indicate filtering somewhere between the tester and service.

Possibilities include:

host firewall
network firewall
access-control rule
packet filtering

Do not immediately determine which one without evidence.

Record:

Observation:
Port appears filtered.

Interpretation:
Traffic may be restricted.

Validation:
Required.

Part 27 — Identify Web Services

If ports such as:

appear open, add them to your web-service list.

Example:

Target	Port	Service	Next Phase
TGT-01	80	HTTP	Web Enumeration
TGT-02	443	HTTPS	Web Enumeration
TGT-02	8080	HTTP	Web Enumeration

Do not perform vulnerability testing yet.

That comes later.

Part 28 — Identify Remote Access Services

Examples might include:

22 SSH

3389 RDP

Ask:

Is remote administration expected?
Who should have access?
Is it exposed only to the management network?
Does it require strong authentication?

These questions become part of security analysis.

Examples could include:

21 FTP

139/445 SMB

2049 NFS

Later enumeration may investigate:

authentication requirements
shares
access controls
exposed information
configuration

For now, simply identify and prioritize them.

Part 30 — Identify Database Services

Common database-related ports may include:

3306 MySQL

5432 PostgreSQL

1433 Microsoft SQL Server

If a database service is exposed, ask:

Should this service be reachable from the assessment network?

Exposure itself may be a security architecture concern even before any vulnerability is identified.

Part 31 — Identify Unexpected Services

One of the most useful findings is often:

A service that nobody expected to exist.

Example:

Target Role:
Web Server

Expected:
80, 443

Observed:
22, 80, 443, 3306

The database exposure may deserve further investigation.

Document:

Expected Services:

Observed Services:

Unexpected Services:

Security Relevance:

Next Action:

Part 32 — Compare Service Exposure to Asset Role

Create:

Target	Intended Role	Observed Services	Consistent?
TGT-01	Web Server	22, 80, 443	Mostly
TGT-02	Database Server	22, 3306	Yes
TGT-03	Workstation	22, 80, 3306	Investigate

This encourages architectural thinking.

Part 33 — Avoid the “Every Open Port Is Bad” Mistake

An open port is not automatically a vulnerability.

For example:

443/tcp open https

may be entirely expected for a web server.

Security depends on:

why the service exists
configuration
version
authentication
network exposure
access controls
known vulnerabilities

Correct thinking:

Open Port
   ↓
Service
   ↓
Purpose
   ↓
Configuration
   ↓
Risk

Part 34 — Save Scan Results in Multiple Formats

For important scans, you may preserve output using Nmap’s standard formats.

Example:

nmap -sV -p 22,80,443 192.168.56.20 -oA Scans/Service-Detection/TGT-01

This can produce multiple output formats useful for:

human review
later processing
evidence retention

Keep original scan evidence unchanged after collection.

Part 35 — Create a Scan Log

Record:

Scan ID:

Date/Time:

Tester:

Source:

Target:

Command:

Purpose:

Output File:

Observations:

Follow-Up:

Example:

Scan ID:
SCAN-04

Target:
192.168.56.20

Purpose:
Identify services on confirmed open ports.

Result:
SSH and HTTP services identified.

Follow-Up:
Enumerate SSH and web service.

Part 36 — Prioritize Follow-Up Enumeration

After service discovery, each exposed service should have an action.

Example:

22 / SSH
      ↓
SSH Enumeration

80 / HTTP
      ↓
Web Enumeration

445 / SMB
      ↓
SMB Enumeration

3306 / MySQL
      ↓
Database Exposure Review

This creates a structured assessment pipeline.

Part 37 — Build the Service Map

Extend your network diagram.

Example:

                  192.168.56.0/24
                         │
              ┌──────────┴──────────┐
              │                     │
              ▼                     ▼
       192.168.56.20          192.168.56.30
        Linux Target            Web Target
              │                     │
         ┌────┼────┐           ┌────┼────┐
         │    │    │           │    │    │
        22   80   3306        80   443  8080
        SSH HTTP MySQL       HTTP HTTPS HTTP

The map now begins to represent the attack surface, not just the network.

Part 38 — Create the Final Port & Service Register

Example:

ID	Target	Port	Service	Version	Exposure	Priority	Next Step
SRV-01	TGT-01	22	SSH	Detected	Open	Medium	Enumerate
SRV-02	TGT-01	80	HTTP	Detected	Open	High	Web Enumeration
SRV-03	TGT-01	3306	MySQL	Detected	Open	High	Exposure Review
SRV-04	TGT-02	443	HTTPS	Detected	Open	High	Web Enumeration

This register becomes the input for Lab 05.

Part 39 — Evidence Requirements

Capture:

Evidence 01

Authorized Target Register.

Evidence 02

Initial scan of TGT-01.

Evidence 03

Initial scan of TGT-02.

Evidence 04

Full TCP scan.

Evidence 05

Service-version detection.

Evidence 06

Comparison between default and full scans.

Evidence 07

Port & Service Inventory.

Evidence 08

Service Priority Matrix.

Evidence 09

Updated Service Map.

Evidence 10

Final Port & Service Register.

Part 40 — Mission Challenge

For each authorized target, determine:

Target:

Total Open TCP Ports:

Open Ports:

Detected Services:

Detected Versions:

Web Services:

Remote Administration Services:

File-Sharing Services:

Database Services:

Unexpected Services:

Highest-Priority Service:

Services Requiring Enumeration:

Do not simply list ports.

Explain what each exposed service means for the assessment.

Part 41 — Troubleshooting

Nmap Reports Host Down

If you know the target is active, verify:

target VM state
network configuration
correct IP
correct subnet
firewall behavior

Within an authorized lab, you may use Nmap’s host-discovery bypass when appropriate:

nmap -Pn 192.168.56.20

-Pn tells Nmap to treat the host as online and proceed with scanning.

Do not use this as a substitute for understanding why discovery failed.

Service Detection Shows Unknown

This may occur when:

service banners are hidden
the software is uncommon
the service behaves unexpectedly

Record:

Service:
Unknown

Validation:
Required

Do not invent a service identity.

Scan Takes Too Long

Full TCP scans naturally take longer than targeted scans.

Ask whether you actually need all ports or whether a more targeted scan answers your current question.

Results Changed

Services may start or stop between scans.

Record:

time
scan conditions
VM state

A scan is a snapshot of the environment at a particular moment.

Mission Deliverables

Complete:

target register reviewed
initial TCP scans completed
full TCP scans completed
service-version detection completed
raw outputs saved
open ports documented
service versions documented
expected vs unexpected services compared
service priorities assigned
Port & Service Inventory created
Service Map updated
follow-up enumeration targets identified
evidence captured
lab report completed

Lab Report Template

# Lab 04 — Port Scanning & Service Discovery

## Executive Summary

## Mission Objective

## Scope

## Authorized Targets

## Methodology

## Initial Port Scanning

## Full TCP Scanning

## Service Detection

## Port States

## Port & Service Inventory

## Expected Services

## Unexpected Services

## Service Prioritization

## Service Map

## Evidence

## Limitations

## Follow-Up Enumeration

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What does an open TCP port indicate?

It indicates that a service appears to be accepting connections on that port.

Question 2 — Does an open port automatically represent a vulnerability?

No.

The service must be evaluated in context, including its purpose, configuration, version, access controls, and exposure.

Question 3 — What does `-p-` do in Nmap?

It requests scanning of all TCP ports.

Question 4 — What does `-sV` do?

It attempts to identify the service and, where possible, product or version information associated with open ports.

Question 5 — What does `filtered` mean?

Nmap cannot confidently determine the port state because traffic appears to be filtered or blocked.

Question 6 — Why compare default and full TCP scans?

Because the default scan may not include every TCP port, so services on less common ports could be missed.

Question 7 — Why should version information be validated?

Automatic fingerprinting can be incomplete or inaccurate, and services may hide or modify their banners.

Question 8 — What comes after service discovery?

Service enumeration.

You take identified services and gather deeper information relevant to their security posture.

Skills Achieved

After completing this lab, you should understand:

TCP ports
UDP concepts
common port ranges
open ports
closed ports
filtered ports
default port scanning
full TCP scanning
targeted scanning
service-version detection
service fingerprinting limitations
expected vs unexpected exposure
service prioritization
attack-surface mapping
evidence collection
scan documentation

Professional Takeaway

Port scanning is not about producing a large list of numbers.

The professional workflow is:

Host → Port → Protocol → Service → Purpose → Exposure → Priority → Next Question

A beginner might report:

“Port 3306 is open.”

A security professional asks:

“Why is a database service reachable from this network, what software is running, is that exposure intentional, and what should be validated next?”

That difference is the beginning of professional penetration-testing analysis.

What’s Next?

➡️ Lab 05 — Service Enumeration

You now know which services are exposed.

In the next lab, you will investigate those services more deeply and learn how to turn a basic service inventory into meaningful security intelligence.

You will work through areas such as:

SSH
FTP
SMB
HTTP/HTTPS
DNS
common application services

The methodology becomes:

Service → Protocol → Configuration → Information → Access Controls → Evidence → Security Relevance

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

“What can each exposed service tell me about the system, and which observations should move forward into vulnerability analysis?”

Lab 04 Port Scanning & Service Discovery

Mission Overview

Mission Information

Learning Objectives

Lab Architecture

Part 1 — Review the Target Register

Part 2 — Create the Lab Workspace

Part 3 — Understand Network Ports

Part 4 — TCP vs UDP

TCP

UDP

Part 5 — Understand Port States

Open

Closed

Filtered

Part 6 — Confirm Target Reachability

Part 7 — Perform an Initial TCP Scan

Part 8 — Interpret the Initial Results

Part 9 — Scan the Second Target

Part 10 — Understand the Default Scan Limitation

Part 11 — Perform a Full TCP Port Scan

Part 12 — Compare Initial vs Full Scan

Part 13 — Perform Service Version Detection

Part 14 — Understand Service Detection

Part 15 — Do Not Blindly Trust Service Detection

Part 16 — Service Name vs Actual Service

Part 17 — Build a Service Inventory

Part 18 — Identify High-Value Services

Remote Administration

Web Services

File Sharing

Databases

Directory / Identity

Part 19 — Create a Service Priority Matrix

Part 20 — Scan Specific Ports

Part 21 — Understand SYN Scanning

Part 22 — Understand TCP Connect Scanning

Part 23 — Observe Traffic with Wireshark

Part 24 — Understand the TCP Handshake

Part 25 — Why Closed Ports Still Matter

Part 26 — Why Filtered Ports Matter

Part 27 — Identify Web Services

Part 28 — Identify Remote Access Services

Part 29 — Identify File-Sharing Services

Part 30 — Identify Database Services

Part 31 — Identify Unexpected Services

Part 32 — Compare Service Exposure to Asset Role

Part 33 — Avoid the “Every Open Port Is Bad” Mistake

Part 34 — Save Scan Results in Multiple Formats

Part 35 — Create a Scan Log

Part 36 — Prioritize Follow-Up Enumeration

Part 37 — Build the Service Map

Part 38 — Create the Final Port & Service Register

Part 39 — Evidence Requirements

Evidence 01

Evidence 02

Evidence 03

Evidence 04

Evidence 05

Evidence 06

Evidence 07

Evidence 08

Evidence 09

Evidence 10

Part 40 — Mission Challenge

Part 41 — Troubleshooting

Nmap Reports Host Down

Service Detection Shows Unknown

Scan Takes Too Long

Results Changed

Mission Deliverables

Lab Report Template

Knowledge Check

Question 1 — What does an open TCP port indicate?

Question 2 — Does an open port automatically represent a vulnerability?

Question 3 — What does -p- do in Nmap?

Question 4 — What does -sV do?

Question 5 — What does filtered mean?

Question 6 — Why compare default and full TCP scans?

Question 7 — Why should version information be validated?

Question 3 — What does `-p-` do in Nmap?

Question 4 — What does `-sV` do?

Question 5 — What does `filtered` mean?