Lab 04 UDP Service Discovery

Mission Overview

Welcome to Lab 04 — UDP Service Discovery.

In Lab 03, you mapped the TCP attack surface of your authorized targets.

Now you will investigate UDP.

UDP behaves very differently from TCP. There is no three-way handshake, many services remain silent unless they receive a valid application request, and firewalls may drop probes without returning useful information.

That means:

No response does not automatically mean no service exists.

Your job in this lab is to identify exposed UDP services, interpret ambiguous results correctly, validate likely services using safe service-aware checks, and add UDP findings to the network attack-surface inventory.

Mission Goal: Perform controlled UDP discovery against authorized lab systems, identify likely UDP services, validate relevant services safely, distinguish open, closed, filtered, and open|filtered states, and build a UDP Service Register.

Mission Information

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

Learning Objectives

By completing this lab, you will be able to:

• explain how UDP differs from TCP

• identify common UDP services

• perform targeted UDP discovery

• interpret open, closed, filtered, and open|filtered

• understand why UDP scans can take longer

• analyze DNS exposure

• identify SNMP exposure conceptually and safely

• review NTP exposure

• validate likely UDP services with benign queries

• distinguish silence from absence

• compare TCP and UDP attack surfaces

• preserve scan evidence

• prioritize UDP services for deeper assessment

UDP Assessment Methodology

Use:

Scope → Host → UDP Port → Response/No Response → Service Context → Validate → Evidence → Prioritize

Conceptually:

Authorized Host
      │
      ▼
UDP Discovery
      │
      ├── Response
      ├── ICMP Error
      └── No Response
      │
      ▼
Port-State Interpretation
      │
      ▼
Service-Aware Validation
      │
      ▼
Exposure Assessment
      │
      ▼
UDP Service Register

The key principle is:

UDP silence is ambiguous.

Part 1 — Revalidate Scope

Confirm the targets from Labs 02 and 03.

Example:

Authorized Network:
192.168.56.0/24

Linux Target:
192.168.56.20

Windows Target:
192.168.56.30

Optional Infrastructure Target:
192.168.56.40

Record:

Scope Verified:
Yes / No

UDP Testing Authorized:
Yes / No

Assessment Date:

Investigator:

Part 2 — Create the Lab Workspace

Create:

Network-Pentesting-Labs/
└── Lab-04/
    ├── Scope/
    ├── Notes/
    ├── Scans/
    │   ├── Targeted-UDP/
    │   ├── Service-Detection/
    │   └── Validation/
    ├── Evidence/
    ├── Assets/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-04-UDP-Service-Discovery-Journal.md

Suggested structure:

# Lab 04 — UDP Service Discovery

## Mission Objective

## Authorization

## Target Inventory

## UDP Concepts

## Targeted UDP Discovery

## DNS Assessment

## SNMP Assessment

## NTP Assessment

## Service Validation

## UDP Service Register

## TCP vs UDP Comparison

## Observations

## Limitations

## Conclusion

Part 3 — Understand UDP

UDP is connectionless.

Unlike TCP, it does not normally establish a session using:

SYN
SYN/ACK
ACK

A simplified UDP exchange is:

Client
   │
   │ UDP Datagram
   ▼
Server

Server may:
- respond
- remain silent
- trigger an ICMP error

This makes scanning more difficult.

Part 4 — Compare TCP and UDP

TCP	UDP
Connection-oriented	Connectionless
Handshake exists	No handshake
Easier to determine open state	Often ambiguous
Connection response useful	Valid application response often needed
Common state detection is faster	Discovery may be slower

The practical lesson:

TCP state is often easier to infer than UDP state.

Part 5 — Understand Common UDP Services

Examples include:

Port	Common Service
53	DNS
67/68	DHCP
69	TFTP
123	NTP
137	NetBIOS Name Service
138	NetBIOS Datagram
161	SNMP
162	SNMP Trap
500	IKE/IPsec
514	Syslog
1900	SSDP
5353	mDNS

Do not assume a service solely from the port number.

Part 6 — Understand UDP Port States

Typical scan states include:

Open

A valid response indicates a service is likely listening.

Closed

An ICMP port-unreachable message or equivalent indicates no service is listening.

Filtered

Filtering prevents a reliable conclusion.

Open|Filtered

The scanner received no conclusive response and cannot determine whether the port is open or filtered.

This is extremely important.

Part 7 — Understand open|filtered

Suppose a probe is sent to UDP port 161.

Nothing comes back.

That could mean:

SNMP is listening but ignored the probe

or

Firewall silently dropped the packet

Therefore:

No Response
     ≠
Closed

Part 8 — Begin with Targeted UDP Discovery

Do not start with all 65,535 UDP ports.

Begin with a small, relevant set.

Example against an authorized Linux target:

sudo nmap -sU -p 53,69,123,161 192.168.56.20

Save:

sudo nmap -sU -p 53,69,123,161 192.168.56.20 \
-oN Scans/Targeted-UDP/linux-targeted-udp.txt

Part 9 — Understand -sU

In Nmap:

-sU

requests UDP scanning.

Because UDP lacks the TCP handshake, results may take longer and may be less definitive.

Part 10 — Scan the Windows Target

Example:

sudo nmap -sU -p 53,123,137,138,161 192.168.56.30

Save:

sudo nmap -sU -p 53,123,137,138,161 192.168.56.30 \
-oN Scans/Targeted-UDP/windows-targeted-udp.txt

Part 11 — Build the Initial UDP Register

Create:

Host	Port	State	Possible Service
Linux	53		DNS
Linux	123		NTP
Linux	161		SNMP
Windows	137		NetBIOS

Do not write “confirmed service” yet.

Part 12 — Record Timing

UDP scans may be slower than TCP scans.

Record:

Target:

Start Time:

End Time:

Duration:

Ports Tested:

This helps students understand operational differences.

Part 13 — Understand Why UDP Scans Are Slow

Scanners may need to wait for timeouts because:

No response might mean:
Open
or
Filtered

Waiting is often necessary before classification.

Part 14 — Avoid Extreme Scan Timing

Do not compensate by using excessively aggressive timing.

In a professional environment, high-rate UDP scanning may:

• increase packet loss

• overwhelm fragile services

• create misleading results

• affect monitoring systems

Use controlled lab defaults unless the exercise specifically tests performance.

Part 15 — Use Service Detection on Relevant UDP Ports

Once likely ports are identified, service detection may help.

Example:

sudo nmap -sU -sV -p 53,123,161 192.168.56.20

Save:

sudo nmap -sU -sV -p 53,123,161 192.168.56.20 \
-oN Scans/Service-Detection/linux-udp-services.txt

Part 16 — Understand UDP Service Detection

Service detection can send protocol-specific probes.

This is useful because many UDP applications respond only to correctly formatted requests.

Therefore:

Generic UDP Probe
       ↓
No Response

Service-Aware Probe
       ↓
Valid Response

may reveal an actual service.

Part 17 — Assess DNS Exposure

If UDP port 53 is exposed, determine whether the host is actually providing DNS.

A benign query against an explicitly authorized training DNS server might be:

dig @192.168.56.20 example.test

or:

nslookup example.test 192.168.56.20

Use only lab domains or approved queries.

Part 18 — Build the DNS Service Register

Create:

Item	Result
Target
UDP 53 State
DNS Response
Resolver Type
Query Tested
Recursion Observed
Evidence

Part 19 — Understand Authoritative vs Recursive DNS

Authoritative DNS

Provides answers for zones it is responsible for.

Recursive Resolver

Looks up answers on behalf of clients.

A server can perform one or both roles depending on configuration.

The question is:

Is the exposed DNS behavior appropriate for this network segment?

Part 20 — Review Recursive Resolver Exposure

If a DNS resolver is accessible from a network where it should not be, that may represent unnecessary exposure.

Do not classify it automatically as a critical issue.

Consider:

• intended clients

• network location

• access controls

• recursion policy

Part 21 — Understand DNS Query Results

A successful response proves:

The target responded to a DNS request.

It does not prove:

• every DNS feature is enabled

• the service is vulnerable

• unrestricted recursion exists

• zone data can be transferred

Each of those requires separate evidence.

Part 22 — Treat Zone Transfer Separately

Zone-transfer behavior is a configuration question.

If your intentionally configured training DNS lab includes it and the exercise authorizes checking it, document it as a separate validation activity.

Do not assume:

DNS Port Open
     =
Zone Transfer Possible

Part 23 — Assess NTP Exposure

NTP commonly uses:

123/udp

If present, determine whether the system responds as an NTP service.

You may use approved service-detection functionality.

For example:

sudo nmap -sU -sV -p 123 192.168.56.20

Part 24 — Build the NTP Register

Target	Port	State	Service	Expected	Notes
	123		NTP

Ask:

Should this system provide NTP to the assessed network?

Part 25 — Understand NTP Security Context

NTP itself may be legitimate.

Assessment questions include:

• Is the service expected?

• Is it unnecessarily exposed?

• Is it restricted to appropriate clients?

• Is the software maintained?

• Does configuration reveal excessive information?

Do not attempt disruptive or amplification testing.

Part 26 — Assess SNMP Exposure Safely

SNMP commonly uses:

161/udp

It is used for monitoring and management.

If your lab contains an intentionally configured SNMP service, first determine whether the port appears reachable.

Example:

sudo nmap -sU -sV -p 161 192.168.56.20

Part 27 — Understand SNMP Versions

Common versions include:

SNMPv1

SNMPv2c

SNMPv3

Broadly:

• v1/v2c rely on community-string models

• SNMPv3 can provide stronger authentication and privacy features

Do not attempt guessing, brute force, or community-string discovery in this lab.

Part 28 — Use Supplied Lab Credentials Only

If the lab explicitly provides an SNMP community string or authorized credential for verification, use only that supplied value.

The purpose is to validate:

What information does an authorized SNMP client receive?

not:

Can I guess credentials?

Part 29 — Build the SNMP Exposure Register

Create:

Item	Result
Target
UDP 161 State
SNMP Version
Credential Supplied	Yes/No
Authorized Response
Information Exposure
Security Assessment

Part 30 — Identify SNMP Information Exposure

Authorized SNMP responses may reveal:

• hostname

• operating system

• interfaces

• interface addresses

• device description

• uptime

• other management information

Determine whether the information is appropriate for the assessed segment.

Part 31 — Keep SNMP Findings Narrow

Bad conclusion:

“SNMP is open, therefore the host is compromised.”

Better:

“SNMP is remotely accessible from the assessment segment.”

Stronger, if supported:

“The supplied authorized SNMP credential permits retrieval of system information from a network segment not expected to have management access.”

Part 32 — Assess NetBIOS UDP Exposure

Windows networks may expose:

137/udp
138/udp

These ports are associated with legacy NetBIOS functionality.

Record whether they are visible.

Do not assume vulnerability solely because they exist.

Part 33 — Build the Windows UDP Register

Port	State	Service	Expected	Priority
137		NetBIOS NS
138		NetBIOS Datagram

These results will help later Windows network assessment.

Part 34 — Check for DHCP Carefully

DHCP commonly uses:

67/udp
68/udp

Do not perform unnecessary DHCP requests on networks outside your isolated lab.

In this course, DHCP assessment should remain observational unless your training topology specifically includes a DHCP server.

Part 35 — Understand TFTP

TFTP commonly uses UDP 69.

It is a simple file-transfer protocol and typically lacks strong authentication mechanisms.

If a deliberately configured training service is present, identify exposure first.

Do not retrieve arbitrary files unless the exercise explicitly supplies an approved test filename.

Part 36 — Build the Service Validation Matrix

Create:

Host	Port	Initial State	Validation Method	Final Assessment
Linux	53	Open	DNS query	Confirmed DNS
Linux	123	Open	Filtered	Service-aware probe
Linux	161	Open	Filtered	Approved SNMP check

Part 37 — Understand the Importance of Application-Aware Validation

UDP investigation often looks like:

Port Result
    ↓
Possible Service
    ↓
Protocol-Specific Request
    ↓
Response
    ↓
Higher Confidence

This is the central technical lesson of Lab 04.

Part 38 — Compare Local Baseline with Remote Results

On Linux, if you have administrative access to the training target:

ss -uln

This shows locally listening UDP sockets.

Compare with the remote assessment.

Create:

Port	Local Listening	Remote Result	Interpretation
53	Yes	Open	Exposed
123	Yes	Open	Filtered
161	Yes	Filtered	Network restriction likely

Part 39 — Understand Local vs Remote Differences

Possible causes:

Service bound to localhost

Host firewall

Virtual firewall

Network ACL

Incorrect interface

Application ignores probe

Scanner uncertainty

Do not overstate the cause without verification.

Part 40 — Compare Windows Baseline

If the Windows target exposes UDP services locally, document them using approved operating-system tooling and compare to remote observations.

The principle remains:

Locally Listening
       ≠
Remotely Reachable

Part 41 — Build the UDP Exposure Matrix

Create:

Host	Port	Service	Remote State	Exposure
Linux	53	DNS	Open	Exposed
Linux	123	NTP	Open	Filtered
Windows	137	NetBIOS	Open	Exposed

Part 42 — Compare TCP and UDP Attack Surfaces

Now combine Labs 03 and 04.

Example:

Host	TCP Exposure	UDP Exposure
Linux	SSH, HTTP	DNS, NTP
Windows	SMB, RDP	NetBIOS

This gives a broader attack-surface view.

Part 43 — Build the Combined Service Map

Conceptually:

                  Linux Target
                     │
             ┌───────┴───────┐
             │               │
            TCP             UDP
             │               │
         22 SSH            53 DNS
         80 HTTP          123 NTP
                         161 SNMP

The assessment surface now includes both transport protocols.

Part 44 — Prioritize UDP Services

Prioritization can consider:

• management function

• information exposure

• authentication model

• network reachability

• whether the service is expected

• legacy protocol usage

• business importance

Create:

Priority	Host	UDP Port	Service	Reason
High	Linux	161	SNMP	Management exposure
Medium	Linux	53	DNS	Infrastructure service
Medium	Linux	123	NTP	Network infrastructure

Part 45 — Separate Observation from Finding

Observation

UDP port 161 responded to an authorized SNMP request.

Interpretation

The SNMP management service is remotely reachable from the
assessment segment.

Potential Finding

SNMP management access is available from a network segment not
expected to have administrative visibility.

The final finding depends on intended architecture.

Part 46 — Example Observation — DNS Exposure

Asset:
192.168.56.20

Port:
53/udp

Observation:
The target responds to authorized DNS requests over UDP.

Validation:
A lab-domain query received a valid DNS response.

Assessment:
DNS service exposure confirmed.

Next Step:
Review whether resolver behavior and network accessibility align
with the intended architecture.

Part 47 — Example Observation — SNMP Exposure

Asset:
192.168.56.20

Port:
161/udp

Observation:
The target responded to an authorized SNMP request using the
credential supplied for the training exercise.

Evidence:
The response contained system management information.

Assessment:
Management-plane information is remotely accessible from the
assessment segment.

Next Step:
Review SNMP version, access restrictions, and intended network
management architecture.

Part 48 — Example Observation — Open|Filtered

Asset:
192.168.56.20

Port:
123/udp

State:
Open|Filtered

Observation:
No conclusive generic UDP response was received.

Interpretation:
The scanner cannot determine whether the service is listening or
the traffic is silently filtered.

Status:
Requires service-aware validation.

Conclusion:
No vulnerability conclusion can be made from this state alone.

Part 49 — Build the UDP Service Register

Final format:

ID	Host	Port	State	Service	Validation	Priority
UDP-001	Linux	53	Open	DNS	Confirmed	Medium
UDP-002	Linux	123	Open	Filtered	NTP	Review
UDP-003	Linux	161	Open	SNMP	Confirmed	High

Part 50 — Build the UDP Attack-Surface Summary

Record:

Linux Target

UDP Ports Tested:

Confirmed UDP Services:

Open|Filtered Services:

Filtered Services:

Unexpected Services:

Highest-Priority UDP Exposure:


Windows Target

UDP Ports Tested:

Confirmed UDP Services:

Open|Filtered Services:

Unexpected Services:

Highest-Priority UDP Exposure:

Part 51 — Identify Unexpected UDP Services

Suppose a web server unexpectedly exposes:

161/udp

This should prompt:

Why is a management protocol accessible from this segment?

Do not jump immediately to exploitation.

Record and investigate the architectural purpose.

Part 52 — Identify Infrastructure Services

UDP frequently exposes infrastructure functionality.

Examples:

DNS
NTP
SNMP
DHCP

These services can be more security-significant than their simple port list suggests because they support core network operations.

Part 53 — Understand Management Plane Exposure

Services such as SNMP should often be more restricted than general user-facing applications.

Think in terms of:

User Plane

Application Plane

Management Plane

Ask:

Should ordinary network segments reach this management service?

This becomes important in Lab 12 segmentation testing.

Part 54 — Understand Amplification Conceptually

Some UDP protocols have historically been abused for traffic amplification.

For this lab, understand the concept only:

Small Request
     ↓
Larger Response

Do not perform amplification or denial-of-service tests.

Your job is to assess configuration and exposure safely.

Part 55 — Understand Spoofing Conceptually

UDP does not establish a connection like TCP, so source-address verification works differently.

This contributes to some UDP abuse scenarios.

Again, no spoofing is required in this lab.

Part 56 — Document Scan Limitations

Your report should mention:

• UDP state ambiguity

• packet loss

• service-specific response behavior

• firewall filtering

• scan duration

• probe compatibility

These limitations are part of professional reporting.

Part 57 — Build the Command Journal

Use:

Time	Method	Target	Ports	Purpose	Evidence
	UDP scan	Linux	53,123,161	Discovery	E03
	DNS query	Linux	53	Validation	E06
	SNMP authorized check	Linux	161	Validation	E08

Part 58 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
UDP Service Discovery

Authorized Network:

Pentest Workstation:

Assessment Date:


TARGET 01

Hostname:

IP:

UDP Ports Tested:

Confirmed Open UDP Ports:

Open|Filtered Ports:

Filtered Ports:

Services Identified:

Services Validated:


DNS

Port 53 Present:
Yes / No

DNS Service Confirmed:
Yes / No

Authorized Query:

Response:

Expected Service:
Yes / No


NTP

Port 123 Present:
Yes / No

State:

NTP Confirmed:
Yes / No / Inconclusive

Expected Service:
Yes / No


SNMP

Port 161 Present:
Yes / No

State:

Authorized Credential Supplied:
Yes / No

SNMP Response:
Yes / No / Not Tested

Management Information Exposed:
Yes / No / Unknown


TARGET 02

Hostname:

IP:

UDP Ports Tested:

Confirmed Services:

Open|Filtered Services:

Unexpected Services:


TCP VS UDP

TCP Services from Lab 03:

UDP Services from Lab 04:

New Attack-Surface Findings:

Highest-Priority UDP Service:


FINAL ANALYSIS

Did silence create any ambiguous results?

Which service required protocol-aware validation?

Were any management services exposed?

Were any services unexpected?

Was a vulnerability confirmed?
Yes / No / Requires Further Analysis

Ready for Network Service Enumeration:
Yes / No

Part 59 — What Not to Do

Do not:

Scan outside the authorized range

Treat no response as closed

Treat open|filtered as confirmed open

Treat every UDP service as vulnerable

Guess SNMP community strings

Brute-force SNMP credentials

Perform UDP amplification tests

Spoof packet sources

Perform denial-of-service testing

Retrieve arbitrary TFTP files

Disrupt DHCP services

Assume DNS exposure means zone transfer

Assume NTP exposure means vulnerability

Ignore firewall behavior

Ignore local-vs-remote differences

Run full UDP scans unnecessarily against fragile systems

Report ambiguous scanner results as confirmed findings

The professional rule is:

When UDP is silent, investigate carefully rather than guessing.

Troubleshooting

UDP Scan Is Very Slow

That is common.

UDP scanning often waits for timeouts because silence is ambiguous.

Use targeted ports rather than immediately scanning the entire range.

Everything Shows open|filtered

Possible reasons include:

• firewall silently dropping probes

• target services ignoring generic requests

• incomplete responses

• virtual networking behavior

Perform protocol-aware validation for relevant services.

DNS Port Looks Open but Query Fails

Possible explanations:

• service does not answer your query

• firewall rules

• DNS configuration

• wrong target

• port misidentification

Do not call it confirmed DNS without a suitable response.

SNMP Appears Open but No Authorized Response

Record:

SNMP Service:
Possible / Unconfirmed

Do not begin guessing credentials.

Local UDP Service Is Listening but Remote Scan Is Filtered

Review:

• host firewall

• interface binding

• virtual firewall

• ACLs

Document only what you can verify.

Evidence Requirements

Capture:

Evidence 01

Scope verification.

Evidence 02

Validated target inventory.

Evidence 03

Linux targeted UDP scan.

Evidence 04

Windows targeted UDP scan.

Evidence 05

UDP service-detection output.

Evidence 06

DNS validation evidence.

Evidence 07

DNS Service Register.

Evidence 08

NTP assessment.

Evidence 09

SNMP assessment, if configured.

Evidence 10

Windows UDP Service Register.

Evidence 11

Local-vs-remote UDP comparison.

Evidence 12

Service Validation Matrix.

Evidence 13

UDP Exposure Matrix.

Evidence 14

TCP-vs-UDP comparison.

Evidence 15

UDP Service Register.

Evidence 16

UDP Attack-Surface Summary.

Evidence 17

Enumeration Priority Register.

Evidence 18

Mission Challenge worksheet.

Mission Deliverables

Complete:

• scope verified

• targets confirmed

• UDP behavior understood

• targeted UDP scans performed

• results preserved

• UDP states classified

• open|filtered interpreted correctly

• service detection performed

• DNS reviewed where present

• NTP reviewed where present

• SNMP reviewed where configured

• supplied credentials used only when authorized

• local-vs-remote exposure compared

• ambiguous results documented

• unexpected services identified

• management-plane exposure identified

• UDP Service Register completed

• TCP/UDP attack surfaces compared

• enumeration priorities assigned

• journal updated

• final report completed

Lab Report Template

# Lab 04 — UDP Service Discovery

## Executive Summary

## Mission Objective

## Authorization and Scope

## Target Inventory

## UDP Discovery Methodology

## UDP Protocol Characteristics

## Targeted UDP Scanning

## UDP Port-State Analysis

## Service Detection

## DNS Assessment

## NTP Assessment

## SNMP Assessment

## Windows UDP Services

## Local vs Remote Service Comparison

## Service Validation Matrix

## UDP Exposure Matrix

## TCP vs UDP Attack Surface

## Unexpected Services

## Management Service Exposure

## Observations

## Limitations

## Recommended Next Steps

## Conclusion

Knowledge Check

Question 1 — Why is UDP discovery harder than TCP discovery?

Because UDP has no connection handshake and many services remain silent unless they receive a valid request.

Question 2 — Does no UDP response prove a port is closed?

No.

The port may be open or traffic may be filtered.

Question 3 — What does open|filtered mean?

The scanner cannot reliably distinguish between an open service and silently filtered traffic.

Question 4 — Why are protocol-aware probes useful?

Because some UDP services respond only to valid application-layer requests.

Question 5 — What commonly runs on UDP port 53?

DNS.

Question 6 — What commonly uses UDP port 161?

SNMP.

Question 7 — Should you guess SNMP community strings in this lab?

No.

Use only credentials specifically supplied for the authorized exercise.

Question 8 — Does DNS exposure prove zone transfer is possible?

No.

That is a separate configuration question.

Question 9 — Does a locally listening UDP service guarantee remote exposure?

No.

Binding and filtering controls may prevent remote reachability.

Question 10 — What is the most important UDP discovery principle?

Silence must be interpreted as uncertainty until additional evidence clarifies it.

Skills Achieved

After completing this lab, you should understand:

• UDP fundamentals

• TCP vs UDP differences

• targeted UDP scanning

• UDP port states

• open|filtered

• UDP service detection

• protocol-aware validation

• DNS exposure assessment

• NTP exposure assessment

• SNMP exposure concepts

• management-plane awareness

• local-vs-remote service comparison

• ambiguous-result handling

• TCP-vs-UDP attack-surface comparison

• evidence preservation

• professional UDP reporting

Professional Takeaway

UDP scanning should not be interpreted like TCP scanning.

The incorrect model is:

No Response
    ↓
Closed

The professional model is:

UDP Probe
   ↓
Response / ICMP / Silence
   ↓
State Interpretation
   ↓
Service-Aware Validation
   ↓
Corroborating Evidence
   ↓
Defensible Conclusion

Always distinguish:

No Response
   ≠
No Service

Open|Filtered
   ≠
Confirmed Open

UDP Port Number
   ≠
Confirmed Application

DNS Exposed
   ≠
Zone Transfer Allowed

SNMP Reachable
   ≠
Compromise

NTP Exposed
   ≠
Vulnerability Automatically

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

“Which UDP services are exposed on the authorized network, how confidently can we identify them, and which require deeper enumeration rather than assumptions based on silence?”

What’s Next?

➡️ Lab 05 — Network Service Enumeration

In the next lab, you will move beyond ports and determine what the exposed services actually reveal.

You will work with the services identified in Labs 03 and 04 and examine areas such as:

• SSH

• FTP

• HTTP/HTTPS

• SMB

• DNS

• SMTP

• remote administration

• database listeners

• banners

• protocol capabilities

• authentication requirements

• encryption

• information exposure

• service configuration

The methodology becomes:

Service → Protocol → Capabilities → Authentication → Configuration → Information Exposure → Security Context

The central question will be:

“What does each exposed network service reveal, how is it configured, and which observations deserve further security analysis?”