Lab 03 TCP Port Scanning & Service Discovery

Mission Overview

Welcome to Lab 03 — TCP Port Scanning & Service Discovery.

In Lab 02, you identified which systems are present on the authorized network.

Now you will answer the next question:

Which TCP services are exposed by those systems?

Port scanning is one of the most important skills in network penetration testing, but the objective is not simply to generate a long list of ports.

A professional tester must understand:

what was scanned
why that scan was selected
what each port state means
which services are actually exposed
whether service identification is reliable
what evidence supports the observation
whether the exposure is expected
which services deserve deeper enumeration

The workflow for this lab is:

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

Mission Goal: Perform controlled TCP port scanning against authorized lab hosts, identify exposed TCP services, distinguish open, closed, and filtered states, collect service information, compare remote observations with known baselines, and build a TCP Port & Service Register.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	TCP Port Scanning
Secondary Skill	Service Discovery
Environment	GoHackersCloud Network Pentesting Lab
Authorized Range	`192.168.56.0/24`
Primary Outcome	TCP Port & Service Register
Safety Level	Authorized Training Systems Only

Learning Objectives

By completing this lab, you will be able to:

verify scope before scanning
understand TCP communication
understand TCP port numbers
distinguish open, closed, and filtered ports
perform targeted TCP scans
perform broader TCP port scans
understand SYN scanning conceptually
perform TCP connect scanning where appropriate
identify likely services
perform service/version detection in the lab
recognize the limitations of port-based assumptions
compare local service baselines with remote observations
recognize firewall effects
prioritize services for enumeration
save reproducible scan evidence
build an attack-surface inventory
document professional scanning results

TCP Assessment Methodology

Use:

Scope → Host → Port → State → Service → Validate → Evidence → Prioritize

Conceptually:

Authorized Host
      │
      ▼
TCP Port Scan
      │
      ├── Open
      ├── Closed
      └── Filtered
      │
      ▼
Service Identification
      │
      ▼
Version / Context
      │
      ▼
Baseline Comparison
      │
      ▼
Attack Surface
      │
      ▼
Enumeration Priorities

The key principle is:

An open port represents exposed functionality, not automatically a vulnerability.

Part 1 — Verify the Scope Again

Before scanning, confirm the authorized targets from Lab 02.

Example:

Authorized Network:
192.168.56.0/24

Authorized Assessment Targets:

192.168.56.20 — Linux Target

192.168.56.30 — Windows Target

192.168.56.40 — Optional Web Target

Do not include:

192.168.56.10

unless you intentionally want to assess the pentest workstation itself.

Create:

Scope Confirmed:
Yes

Target 01:

Target 02:

Target 03:

Investigator:

Date:

Part 2 — Create the Lab Workspace

Create:

Network-Pentesting-Labs/
└── Lab-03/
    ├── Scope/
    ├── Notes/
    ├── Scans/
    │   ├── Targeted/
    │   ├── Standard/
    │   ├── Full-TCP/
    │   └── Service-Detection/
    ├── Evidence/
    ├── Assets/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-03-TCP-Port-Scanning-Journal.md

Suggested structure:

# Lab 03 — TCP Port Scanning & Service Discovery

## Mission Objective

## Authorization

## Target Inventory

## TCP Concepts

## Targeted Scans

## Standard TCP Scans

## Full TCP Scans

## Service Detection

## Baseline Comparison

## Firewall Observations

## TCP Port Register

## Service Register

## Attack Surface

## Findings

## Limitations

## Conclusion

Part 3 — Review the Validated Host Inventory

From Lab 02:

Host	IP	Status
linux-target	`192.168.56.20`	Confirmed Active
WIN-TARGET	`192.168.56.30`	Confirmed Active
web-target	`192.168.56.40`	Optional

Port scanning should begin from this validated inventory.

The proper progression is:

Host Discovery
      ↓
Validated Targets
      ↓
Port Scanning

not:

Random IP
   ↓
Scan Everything

Part 4 — Understand TCP Ports

TCP ports identify application endpoints.

Conceptually:

IP Address
   │
   └── Port
        │
        └── Service

Example:

192.168.56.20:22

might correspond to an SSH service.

A host can expose multiple services:

192.168.56.20

22/tcp
80/tcp
443/tcp

Part 5 — Understand the TCP Port Range

TCP uses ports from:

0–65535

They are commonly grouped as:

0–1023
Well-known ports

1024–49151
Registered ports

49152–65535
Dynamic / ephemeral range

Do not assume only low-numbered ports matter.

Applications may listen anywhere.

Part 6 — Understand Common Ports

Examples:

Port	Common Association
21	FTP
22	SSH
23	Telnet
25	SMTP
53	DNS
80	HTTP
110	POP3
135	Microsoft RPC
139	NetBIOS
143	IMAP
443	HTTPS
445	SMB
3389	RDP
3306	MySQL
5432	PostgreSQL

But remember:

Port number suggests a service; it does not prove the service.

Part 7 — Understand TCP Connection Establishment

A normal TCP connection commonly begins:

Client                    Server
  │                         │
  │ -------- SYN ---------> │
  │ <----- SYN/ACK -------- │
  │ -------- ACK ---------> │
  │                         │
  │    Connection Ready     │

This is the TCP three-way handshake.

Understanding this helps explain scanning behavior.

Part 8 — Understand Port States

Nmap commonly reports states such as:

Open

An application appears to be accepting connections.

Closed

The host is reachable, but no application is accepting connections on that port.

Filtered

A firewall or filtering mechanism prevents the scanner from determining the port state reliably.

Open|Filtered

Often seen in situations where the scanner cannot determine whether the port is open or filtered.

More common during certain UDP assessments, but the underlying concept is important.

Part 9 — Understand the Security Meaning

These statements are different:

Port 22 is open.

and:

SSH is vulnerable.

The first is an observation.

The second requires vulnerability analysis.

Use:

Open Port
   ↓
Service
   ↓
Configuration / Version
   ↓
Security Analysis

Part 10 — Start with a Targeted Port Scan

Before broader scanning, test a few expected ports on the Linux target.

Example:

nmap -p 22,80,443 192.168.56.20

This asks:

Are these specific TCP services exposed?

Record:

Target:

Ports Tested:

Results:

Timestamp:

Part 11 — Save the Output

Use:

nmap -p 22,80,443 192.168.56.20 -oN Scans/Targeted/linux-targeted.txt

This creates reproducible evidence.

Your journal should record:

Command:

Purpose:

Target:

Scope Verified:

Output File:

Result:

Part 12 — Perform the Same Targeted Scan Against Windows

Example:

nmap -p 135,139,445,3389 192.168.56.30

This checks several common Windows-related services.

Save:

nmap -p 135,139,445,3389 192.168.56.30 -oN Scans/Targeted/windows-targeted.txt

Do not infer vulnerability from exposure alone.

Part 13 — Build the Targeted Scan Register

Host	Port	State	Initial Interpretation
Linux	22	Open	Possible SSH
Linux	80	Open	Possible HTTP
Windows	445	Open	Possible SMB
Windows	3389	Filtered/Closed/Open	Investigate

Part 14 — Perform a Standard TCP Scan

A normal Nmap scan of a host can be performed with:

nmap 192.168.56.20

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

Save:

nmap 192.168.56.20 -oN Scans/Standard/linux-standard.txt

Repeat for the Windows training target.

Part 15 — Compare Targeted and Standard Scans

Ask:

Did the standard scan identify additional services?

Did targeted results change?

Were any ports filtered?

Were expected services missing?

Create:

Port	Targeted Result	Standard Result	Consistent
22	Open	Open	Yes
80	Open	Open	Yes

Part 16 — Understand SYN Scanning

On systems where your account has appropriate privileges, Nmap may perform SYN scanning.

Example:

sudo nmap -sS 192.168.56.20

Conceptually:

Scanner → SYN

Target → SYN/ACK

Scanner identifies port as open

The scanner generally does not need to complete the full application connection.

Use this only within your authorized lab.

Part 17 — Understand TCP Connect Scanning

A TCP connect scan can be performed using:

nmap -sT 192.168.56.20

This relies on the operating system’s normal connection mechanism.

The important lesson is not which scan is “better.”

It is:

Understand what your scanner is doing and document the method.

Part 18 — Compare Scan Types

Create:

Method	Target	Open Ports	Differences
SYN	Linux
Connect	Linux

In a simple lab, results may be nearly identical.

Part 19 — Perform a Full TCP Port Scan

A standard scan does not inspect every possible TCP port.

On your isolated authorized target:

nmap -p- 192.168.56.20

-p- requests all TCP ports from 1 through 65535.

Save:

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

Repeat only against authorized training hosts.

Part 20 — Understand Why Full Scans Matter

Suppose an application runs on:

8080/tcp

or:

8443/tcp

A limited scan might not always identify every nonstandard service.

Therefore:

Standard Scan
      +
Full TCP Scan
      =
More Complete Exposure Inventory

Part 21 — Do Not Confuse Completeness with Aggression

A full port scan means:

more ports are checked.

It does not mean you should:

overwhelm the target
use extreme timing
perform denial-of-service behavior
ignore environment stability

Even in a lab, use controlled scanning.

Part 22 — Record Full Scan Results

Create:

Host	Open TCP Ports
Linux
Windows
Web

Do not yet list vulnerabilities.

Part 23 — Perform Service Detection

Once open ports are identified, investigate what service appears to be listening.

Example:

nmap -sV -p 22,80 192.168.56.20

Save:

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

Part 24 — Understand `-sV`

-sV asks Nmap to perform service/version detection.

It may identify information such as:

22/tcp
SSH

80/tcp
HTTP

and potentially product/version information.

Treat version strings as evidence requiring context.

Part 25 — Perform Service Detection on Windows

If the scan found ports such as:

135
445
3389

use:

nmap -sV -p 135,445,3389 192.168.56.30

Record results.

Part 26 — Build the Service Register

Create:

Host	Port	State	Service	Confidence
Linux	22	Open	SSH	High
Linux	80	Open	HTTP	High
Windows	445	Open	SMB	High

Part 27 — Understand Service Detection Confidence

A service may be identified through:

protocol response
banner
fingerprint
known behavior
default port association

These are not equal.

Classify:

Confirmed

Strongly Indicated

Possible

Unknown

Part 28 — Do Not Trust Port Numbers Alone

For example:

8080/tcp

might host:

web server
proxy
management interface
custom application

Similarly:

22/tcp

could theoretically run something other than SSH.

Therefore:

Port → Clue. Service response → stronger evidence.

Part 29 — Review Banners Safely

Some services expose a banner when a connection is established.

A banner may disclose:

Service Name

Software

Version

Hostname

Protocol Capabilities

This can be useful for assessment.

Do not send unnecessary or destructive commands.

A banner can be:

accurate
customized
deliberately suppressed
stale
misleading

Therefore:

Banner
   ≠
Absolute Truth

Use service detection plus other evidence.

Part 31 — Compare Remote Findings with Linux Baseline

In Lab 01, you ran:

ss -tuln

on the Linux target.

Compare:

Locally Listening Service
          vs
Remotely Visible Service

Create:

Port	Local Listening	Remote Visible	Interpretation
22	Yes	Yes	Exposed
3306	Yes	No	Locally bound/filtered
80	Yes	Yes	Exposed

Part 32 — Understand Why Differences Occur

A service may listen locally but not appear remotely because:

Bound only to 127.0.0.1

Host firewall blocks access

Network firewall blocks access

Service bound to another interface

Scanner path is filtered

Therefore:

Listening
   ≠
Exposed

Part 33 — Compare Remote Findings with Windows Baseline

In Lab 01, Windows listening services were recorded using:

Get-NetTCPConnection -State Listen

or:

netstat -ano

Compare those results with the remote scan.

Create:

Port	Local Windows	Remote Scan	Status
135	Yes	Open	Exposed
445	Yes	Open	Exposed
3389	Yes/No	Filtered/Closed	Review

Part 34 — Understand Firewall Effects

Example:

Windows Service:
Listening on 3389

but:

Remote Scan:
Filtered

Possible interpretation:

A firewall appears to restrict remote access to the service from the pentest workstation.

This is very different from saying the service is absent.

Part 35 — Build the Exposure Matrix

Create:

Host	Port	Local Service	Remote State	Exposure
Linux	22	SSH	Open	Exposed
Linux	3306	DB	Filtered	Restricted
Windows	445	SMB	Open	Exposed

Part 36 — Identify Services Requiring Deeper Enumeration

Prioritize based on:

business importance
remote exposure
authentication
version disclosure
management function
legacy protocol exposure
network location

Example:

22 SSH
→ Authentication review

80 HTTP
→ Web enumeration

445 SMB
→ Share/service assessment

3389 RDP
→ Remote access review

Part 37 — Build the Enumeration Priority Register

Priority	Host	Port	Service	Reason
High	Windows	445	SMB	Network file/service exposure
High	Linux	22	SSH	Remote authentication
Medium	Linux	80	HTTP	Application exposure

This prepares you for Lab 05.

Part 38 — Identify Unexpected Services

Suppose a server expected to expose only:

22
443

but your scan shows:

This is worth investigating because port 23 commonly suggests Telnet.

But the correct initial statement is:

An unexpected TCP service was observed on port 23.

Not:

The server is compromised.

Part 39 — Create an Unexpected Service Register

Host	Port	Service	Expected	Action
			No	Enumerate

Part 40 — Identify Management Services

Management interfaces deserve particular attention.

Examples include:

SSH

RDP

Web Administration

Database Administration

Remote Management

Ask:

Should this service be reachable from the assessed network segment?

This introduces the concept of exposure risk.

Part 41 — Identify Plaintext Protocols

If services such as these appear:

FTP

Telnet

HTTP

POP3

IMAP

do not immediately classify them as vulnerabilities.

First determine:

whether authentication/data is sensitive
whether encryption alternatives exist
whether traffic is limited to a trusted segment
whether the service is intentionally configured

Lab 11 will examine protocol security more deeply.

Part 42 — Understand Version Disclosure

Suppose service detection reports:

Apache httpd <version>

This is useful information.

However:

Version disclosure itself is not necessarily a critical vulnerability.

The version becomes an input to later vulnerability analysis.

Part 43 — Avoid “Version = Vulnerable”

Do not use:

Old-looking version
      ↓
Vulnerable

Instead use:

Observed Version
      ↓
Vendor / Package Context
      ↓
Configuration
      ↓
Security Advisory Review
      ↓
Controlled Validation

This becomes important in Lab 06.

Part 44 — Build the TCP Port Register

Final format:

ID	Host	Port	State	Evidence
TCP-001	Linux	22	Open	Scan output
TCP-002	Linux	80	Open	Scan output
TCP-003	Windows	445	Open	Scan output

Part 45 — Build the Final Service Register

ID	Host	Port	Service	Exposure	Priority
SRV-001	Linux	22	SSH	Exposed	High
SRV-002	Linux	80	HTTP	Exposed	Medium
SRV-003	Windows	445	SMB	Exposed	High

Part 46 — Build the Network Attack-Surface Map

Conceptually:

                    Pentest Workstation
                           │
                ┌──────────┴─────────┐
                │                    │
                ▼                    ▼
         Linux Target          Windows Target
          │       │            │       │
          ▼       ▼            ▼       ▼
       22 SSH   80 HTTP      445 SMB 3389 RDP

This becomes your first real attack-surface map.

Part 47 — Classify Exposure

Use:

Expected Exposure

Service is intentionally available.

Unexpected Exposure

Service is reachable but was not expected.

Restricted

Service exists but access appears filtered.

Unknown

Insufficient evidence.

Do not equate these directly with severity.

Part 48 — Create the Remote Exposure Summary

Record:

Linux Target

Open TCP Ports:

Filtered TCP Ports:

Primary Services:

Unexpected Services:


Windows Target

Open TCP Ports:

Filtered TCP Ports:

Primary Services:

Unexpected Services:

Part 49 — Validate an Open Port Carefully

Where you want to verify a specific TCP endpoint without interacting deeply with the application, you can perform a simple connection check within the lab.

For example:

nc -vz 192.168.56.20 22

This can help verify TCP reachability.

Use it only on authorized lab ports.

Record:

Target:

Port:

Connection Result:

Interpretation:

Part 50 — Understand What Connection Validation Proves

A successful TCP connection proves:

The TCP endpoint accepted a connection from your source.

It does not prove:

authentication works
the service is securely configured
the service is exploitable
you have authorization to log in

Keep conclusions narrow.

Part 51 — Understand Filtered Results

A filtered result often indicates that the scanner did not receive enough information to determine whether the service is open.

Possible reasons:

Firewall Drop

ACL

Security Group

Host Firewall

Network Filtering

Record:

The port was observed as filtered from the assessment source.

Do not assume a specific firewall until verified.

Part 52 — Compare Scans Over Time

If you repeat a scan, results may differ because:

service started/stopped
firewall changed
VM restarted
network changed
target became unavailable

Record timestamps for all scans.

This is why evidence collection matters.

Part 53 — Maintain a Command Journal

Use:

Command/Method	Target	Purpose	Evidence
Targeted TCP scan	Linux	Expected ports	E03
Full TCP scan	Linux	Complete exposure	E05
Service detection	Linux	Identify services	E07

Part 54 — Separate Observation, Interpretation, and Finding

Observation

TCP port 22 is remotely reachable on 192.168.56.20.

Interpretation

Service detection indicates SSH.

Potential Finding

SSH is reachable from the assessed network.

Whether this becomes a security finding depends on:

intended architecture
authentication controls
configuration
exposure requirements

Part 55 — Example Observation — SSH Exposure

Asset:
192.168.56.20

Port:
22/tcp

State:
Open

Service:
SSH

Observation:
The SSH service is remotely reachable from the authorized
assessment workstation.

Security Status:
Requires configuration and authentication review.

Next Step:
Assess SSH authentication and configuration in a later lab.

Part 56 — Example Observation — SMB Exposure

Asset:
192.168.56.30

Port:
445/tcp

Service:
SMB

Observation:
The Windows SMB service is remotely accessible from the lab
assessment segment.

Current Classification:
Exposed Service.

Next Step:
Perform authorized SMB service and share assessment.

Part 57 — Example Observation — Filtered Service

Asset:
192.168.56.30

Port:
3389/tcp

Observation:
The port was reported as filtered from the pentest workstation.

Interpretation:
Network or host filtering may restrict access.

Limitation:
The scan alone does not establish which security control performs
the filtering.

Part 58 — Do Not Report Every Open Port as a Vulnerability

A well-configured server may legitimately expose:

22 SSH
443 HTTPS

The pentester’s role is to determine whether the exposure is:

Necessary

Securely Configured

Restricted Appropriately

Maintained

Consistent with Architecture

Part 59 — Build the Attack-Surface Priority Matrix

Service	Exposure	Security Importance	Next Action
SSH	Remote	High	Auth assessment
HTTP	Remote	Medium	Web/service enumeration
SMB	Remote	High	SMB assessment
RDP	Restricted	High	Access-control review

Part 60 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
TCP Port Scanning & Service Discovery

Authorized Range:

Pentest Host:

Assessment Date:


TARGET 01

Hostname:

IP:

Host Status:

Targeted Ports:

Standard Scan Completed:
Yes / No

Full TCP Scan Completed:
Yes / No

Open Ports:

Closed Ports of Interest:

Filtered Ports:

Services Identified:

Versions Identified:

Unexpected Services:

Highest-Priority Service:


TARGET 02

Hostname:

IP:

Host Status:

Targeted Ports:

Standard Scan Completed:
Yes / No

Full TCP Scan Completed:
Yes / No

Open Ports:

Filtered Ports:

Services Identified:

Versions Identified:

Unexpected Services:

Highest-Priority Service:


BASELINE COMPARISON

Linux Local Listening Services:

Linux Remotely Visible Services:

Differences:


Windows Local Listening Services:

Windows Remotely Visible Services:

Differences:


ATTACK SURFACE

Total Open TCP Services:

Total Restricted/Filtered Services:

Management Services:

Authentication Services:

Web Services:

File-Sharing Services:

Unexpected Services:


FINAL ANALYSIS

Most Exposed Host:

Most Important Service:

Unexpected Exposure:

Strongest Firewall Evidence:

Service Requiring Immediate Enumeration:

Confirmed Vulnerability Identified:
Yes / No

Expected:
Not necessarily


READY FOR SERVICE ENUMERATION:
Yes / No

Part 61 — What Not to Do

Do not:

Scan systems outside scope

Scan public IPs for practice

Treat every open port as vulnerable

Assume default port equals service

Assume version output is perfectly accurate

Launch exploits because a version looks old

Attempt authentication without authorization

Run denial-of-service tests

Use excessive scan intensity against unstable systems

Ignore filtered ports

Ignore unexpected services

Ignore differences between local and remote exposure

Hide scan failures

Forget timestamps

Report scanner output without interpretation

The professional rule is:

Discover the service before judging the service.

Troubleshooting

Host Appeared in Lab 02 but Scan Says Down

The target may block discovery probes.

Because the host is already validated and authorized, you can troubleshoot its reachability and firewall behavior.

Confirm:

ip neigh

and validate VM/network configuration.

Do not assume the target disappeared solely from one scanner message.

All Ports Appear Closed

Possible explanations:

no services are running
wrong target
target firewall behavior
services are locally bound
VM configuration issue

Check the Lab 01 local service baseline.

All Ports Appear Filtered

Review:

target host firewall
virtual firewall
ACLs
network path
correct interface

Service Detection Gives `unknown`

The application may use:

uncommon protocol
custom service
minimal response
nonstandard implementation

Record it as unknown rather than guessing.

Full TCP Scan Finds Additional Ports

That is expected.

Update the Service Register and prioritize the newly discovered exposure.

Local Service Exists but Remote Scan Cannot See It

Check whether the service is bound to:

127.0.0.1

or another interface.

Also review firewall rules.

Evidence Requirements

Capture:

Evidence 01

Scope verification.

Evidence 02

Validated Target Register from Lab 02.

Evidence 03

Linux targeted TCP scan.

Evidence 04

Windows targeted TCP scan.

Evidence 05

Linux standard scan.

Evidence 06

Windows standard scan.

Evidence 07

Linux full TCP scan.

Evidence 08

Windows full TCP scan.

Evidence 09

Linux service-detection output.

Evidence 10

Windows service-detection output.

Evidence 11

TCP Port Register.

Evidence 12

Service Register.

Evidence 13

Linux baseline comparison.

Evidence 14

Windows baseline comparison.

Evidence 15

Exposure Matrix.

Evidence 16

Unexpected Service Register.

Evidence 17

Enumeration Priority Register.

Evidence 18

Network Attack-Surface Map.

Evidence 19

Remote Exposure Summary.

Evidence 20

Mission Challenge worksheet.

Mission Deliverables

Complete:

scope revalidated
authorized targets confirmed
targeted TCP scan performed
standard TCP scan performed
full TCP scan performed
scan outputs preserved
TCP states interpreted
service detection performed
service versions recorded carefully
port assumptions avoided
Linux local baseline compared
Windows local baseline compared
firewall effects documented
exposed services identified
restricted services documented
unexpected services recorded
management services identified
authentication services identified
TCP Port Register completed
Service Register completed
Exposure Matrix created
Enumeration Priority Register created
Attack-Surface Map created
journal updated
final report completed

Lab Report Template

# Lab 03 — TCP Port Scanning & Service Discovery

## Executive Summary

## Mission Objective

## Authorization and Scope

## Target Inventory

## Assessment Methodology

## TCP Scanning Strategy

## Targeted Port Scanning

## Standard TCP Scanning

## Full TCP Port Scanning

## TCP Port States

## Service Identification

## Service Version Analysis

## Linux Target Results

## Windows Target Results

## Local vs Remote Service Comparison

## Firewall and Filtering Observations

## TCP Port Register

## Service Register

## Unexpected Services

## Attack-Surface Map

## Enumeration Priorities

## Observations

## Limitations

## Recommended Next Steps

## Conclusion

Knowledge Check

Question 1 — What does an open TCP port mean?

A network application appears to be accepting TCP connections on that port.

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

No.

It indicates exposed functionality that requires further assessment.

Question 3 — What does a closed port generally mean?

The host is reachable, but no service is accepting connections on that port.

Question 4 — What does filtered mean?

The scanner cannot reliably determine the port state because traffic appears to be filtered.

Question 5 — Why perform a full TCP scan?

To identify services listening on ports that may not be included in a standard scan.

Question 6 — What does `-sV` provide?

Service and possible version-detection information.

Question 7 — Does port 22 prove that SSH is running?

No.

It is a strong initial clue, but service behavior provides stronger evidence.

Question 8 — Why compare local listening services with remote scanning?

To understand which services are actually exposed across the network.

Question 9 — Does an older-looking version string prove a vulnerability?

No.

The version must be evaluated against vendor context, configuration, and validated security information.

Question 10 — What should happen after service discovery?

Prioritize the exposed services and perform structured service enumeration.

Skills Achieved

After completing this lab, you should understand:

TCP port fundamentals
TCP handshake concepts
open ports
closed ports
filtered ports
targeted scanning
standard TCP scanning
full TCP scanning
SYN scanning concepts
TCP connect scanning
service identification
version-detection concepts
banner limitations
firewall effects
local vs remote service exposure
service prioritization
attack-surface mapping
scan evidence preservation
professional port-scan documentation

Professional Takeaway

Port scanning should not look like:

Scan
 ↓
Open Port
 ↓
Exploit

The professional workflow is:

Authorized Host
      ↓
Port Discovery
      ↓
Port State
      ↓
Service Identification
      ↓
Exposure Validation
      ↓
Configuration Context
      ↓
Enumeration Priority

Always distinguish:

Open Port
   ≠
Vulnerability

Port Number
   ≠
Confirmed Service

Version Detected
   ≠
Vulnerability Confirmed

Service Listening Locally
   ≠
Service Remotely Exposed

Filtered Port
   ≠
Closed Port

By the end of this lab, you should be able to answer:

“Which TCP services are remotely exposed on each authorized host, how confidently can those services be identified, and which ones deserve deeper security assessment?”

What’s Next?

➡️ Lab 04 — UDP Service Discovery

In the next lab, you will investigate a very different network behavior.

You will learn:

why UDP discovery differs from TCP
why lack of response is difficult to interpret
common UDP services
DNS exposure
SNMP concepts
NTP exposure
UDP port states
targeted UDP assessment
validation using service-aware queries
comparing TCP and UDP attack surfaces

The methodology becomes:

Authorized Host → UDP Port → Response/No Response → Service Context → Validation → Evidence

The key question will be:

“Which UDP services are exposed by the authorized hosts, and how can we assess them without incorrectly treating silence as proof that nothing is listening?”

Lab 03 TCP Port Scanning & Service Discovery

Mission Overview

Mission Information

Learning Objectives

TCP Assessment Methodology

Part 1 — Verify the Scope Again

Part 2 — Create the Lab Workspace

Part 3 — Review the Validated Host Inventory

Part 4 — Understand TCP Ports

Part 5 — Understand the TCP Port Range

Part 6 — Understand Common Ports

Part 7 — Understand TCP Connection Establishment

Part 8 — Understand Port States

Open

Closed

Filtered

Open|Filtered

Part 9 — Understand the Security Meaning

Part 10 — Start with a Targeted Port Scan

Part 11 — Save the Output

Part 12 — Perform the Same Targeted Scan Against Windows

Part 13 — Build the Targeted Scan Register

Part 14 — Perform a Standard TCP Scan

Part 15 — Compare Targeted and Standard Scans

Part 16 — Understand SYN Scanning

Part 17 — Understand TCP Connect Scanning

Part 18 — Compare Scan Types

Part 19 — Perform a Full TCP Port Scan

Part 20 — Understand Why Full Scans Matter

Part 21 — Do Not Confuse Completeness with Aggression

Part 22 — Record Full Scan Results

Part 23 — Perform Service Detection

Part 24 — Understand -sV

Part 25 — Perform Service Detection on Windows

Part 26 — Build the Service Register

Part 27 — Understand Service Detection Confidence

Part 28 — Do Not Trust Port Numbers Alone

Part 29 — Review Banners Safely

Part 30 — Understand Banner Limitations

Part 31 — Compare Remote Findings with Linux Baseline

Part 32 — Understand Why Differences Occur

Part 33 — Compare Remote Findings with Windows Baseline

Part 34 — Understand Firewall Effects

Part 35 — Build the Exposure Matrix

Part 36 — Identify Services Requiring Deeper Enumeration

Part 37 — Build the Enumeration Priority Register

Part 38 — Identify Unexpected Services

Part 39 — Create an Unexpected Service Register

Part 40 — Identify Management Services

Part 41 — Identify Plaintext Protocols

Part 42 — Understand Version Disclosure

Part 43 — Avoid “Version = Vulnerable”

Part 44 — Build the TCP Port Register

Part 45 — Build the Final Service Register

Part 46 — Build the Network Attack-Surface Map

Part 47 — Classify Exposure

Expected Exposure

Unexpected Exposure

Restricted

Unknown

Part 48 — Create the Remote Exposure Summary

Part 49 — Validate an Open Port Carefully

Part 50 — Understand What Connection Validation Proves

Part 51 — Understand Filtered Results

Part 52 — Compare Scans Over Time

Part 53 — Maintain a Command Journal

Part 54 — Separate Observation, Interpretation, and Finding

Observation

Interpretation

Potential Finding

Part 55 — Example Observation — SSH Exposure

Part 56 — Example Observation — SMB Exposure

Part 57 — Example Observation — Filtered Service

Part 58 — Do Not Report Every Open Port as a Vulnerability

Part 59 — Build the Attack-Surface Priority Matrix

Part 60 — Mission Challenge

Part 61 — What Not to Do

Troubleshooting

Host Appeared in Lab 02 but Scan Says Down

All Ports Appear Closed

Part 24 — Understand `-sV`

Service Detection Gives `unknown`

Question 6 — What does `-sV` provide?