Lab 11 Network Traffic & Protocol Security Assessment

Mission Overview

Welcome to Lab 11 — Network Traffic & Protocol Security Assessment.

In the previous labs, you identified hosts, services, authentication controls, operating-system exposure, and infrastructure services.

Now you will examine something different:

The communication itself.

A service may be correctly authenticated and still transmit information insecurely. A network may contain sensitive protocols that expose:

• usernames

• session information

• DNS requests

• internal hostnames

• application paths

• service metadata

• file-sharing activity

• administrative traffic

• unencrypted content

Your objective is not to intercept unrelated communications.

You will capture and analyze only traffic generated inside the authorized lab environment and determine whether protocols provide appropriate confidentiality and integrity protection.

Mission Goal: Capture authorized lab traffic, identify protocols and communication patterns, distinguish encrypted from plaintext communication, determine whether sensitive information is exposed in transit, and produce defensible network-protocol security findings.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Network Traffic Analysis
Secondary Skill	Protocol Security Assessment
Environment	GoHackersCloud Network Pentesting Lab
Traffic Source	Authorized lab systems only
Primary Tools	Wireshark / tcpdump or approved packet analyzer
Primary Outcome	Network Traffic Security Register
Safety Level	Authorized Lab Traffic Only

Learning Objectives

By completing this lab, you will be able to:

• understand packet-capture fundamentals

• identify interfaces appropriate for capture

• capture authorized network traffic

• apply useful display filters

• analyze TCP and UDP communications

• examine DNS traffic

• compare HTTP and HTTPS

• identify plaintext protocols

• recognize encrypted application traffic

• analyze SMB traffic at a high level

• observe SSH and RDP transport behavior

• identify unexpected communication

• create host-to-host communication baselines

• recognize sensitive information exposure

• distinguish metadata exposure from content exposure

• preserve packet-capture evidence

• write evidence-based protocol security findings

Assessment Methodology

Use:

Traffic Source → Destination → Protocol → Content Exposure → Encryption → Expected Behavior → Evidence → Finding

Conceptually:

Authorized Communication
        │
        ▼
Capture Traffic
        │
        ▼
Identify Source / Destination
        │
        ▼
Identify Protocol
        │
        ├── DNS
        ├── HTTP/HTTPS
        ├── SMB
        ├── SSH
        ├── RDP
        ├── NTP
        └── Other
        │
        ▼
Inspect Security Characteristics
        │
        ├── Plaintext?
        ├── Encrypted?
        ├── Authentication Data?
        └── Sensitive Metadata?
        │
        ▼
Expected vs Observed
        │
        ▼
Evidence
        │
        ▼
Finding

The central principle is:

Capture only what you are authorized to observe, and interpret only what the evidence actually proves.

Part 1 — Revalidate Scope

Before capturing anything, identify exactly which traffic is authorized.

Example lab:

Pentest Workstation:
192.168.56.10

Linux Target:
192.168.56.20

Windows Target:
192.168.56.30

Infrastructure Target:
192.168.56.40

Authorized Network:
192.168.56.0/24

Record:

Packet Capture Authorized:
Yes / No

Authorized Interface:

Authorized Network:

Authorized Hosts:

Traffic Generation:
Lab Exercises Only

Credential Exposure:
Test Credentials Only

Unrelated Traffic Collection:
Prohibited

Assessment Date:

Investigator:

Part 2 — Understand Packet Capture

Network traffic is commonly represented as:

Frame
  ↓
Ethernet
  ↓
IP
  ↓
TCP / UDP
  ↓
Application Protocol

For example:

Ethernet
   ↓
IPv4
   ↓
TCP
   ↓
HTTP

or:

Ethernet
   ↓
IPv4
   ↓
UDP
   ↓
DNS

Part 3 — Choose the Correct Capture Interface

On Linux:

ip addr

or:

ip link

Identify the lab-facing interface.

Example:

eth0:
Internet/NAT

eth1:
192.168.56.10/24
Lab Network

Capture only from the authorized lab interface.

Part 4 — Avoid Capturing the Wrong Network

If you capture on a bridged, corporate, home, or public network interface, you may collect unrelated traffic.

Stop immediately if you observe:

• unknown production addresses

• corporate traffic

• personal network traffic

• unrelated credentials

• public systems not part of the lab

Use:

Stop → Verify Interface → Resume Only When Scope Is Clear

Part 5 — Start a Controlled Capture

Using tcpdump:

sudo tcpdump -i <lab-interface>

For a controlled capture limited to the lab subnet:

sudo tcpdump -i <lab-interface> net 192.168.56.0/24

Save the capture:

sudo tcpdump -i <lab-interface> net 192.168.56.0/24 \
-w Evidence/lab-traffic.pcap

Stop after generating the required test traffic.

Part 6 — Use Wireshark

Open your approved interface in Wireshark.

A packet list commonly displays:

Field	Purpose
No.	Packet number
Time	Relative/absolute time
Source	Source address
Destination	Destination address
Protocol	Decoded protocol
Length	Packet size
Info	Protocol summary

Do not assume the protocol column tells the entire story.

Part 7 — Capture a Baseline

Before deliberately generating traffic, capture a short baseline.

Record:

Capture Duration:

Active Hosts:

Protocols Observed:

Broadcast Traffic:

Unexpected Traffic:

Notes:

The baseline helps distinguish normal background activity from your test actions.

Part 8 — Build the Traffic Baseline Register

Source	Destination	Protocol	Purpose	Expected
.10	.20	SSH	Administration	Yes
.10	.40	DNS	Name resolution	Yes
.10	.30	SMB	File access	Yes

Part 9 — Understand Capture Filters vs Display Filters

Capture Filter

Controls what is recorded.

Example:

host 192.168.56.20

Display Filter

Controls which already-captured packets are displayed.

Example in Wireshark:

ip.addr == 192.168.56.20

This distinction is important.

Part 10 — Useful Wireshark Display Filters

Authorized lab examples:

ip.addr == 192.168.56.20

tcp

udp

dns

http

tls

tcp.port == 22

tcp.port == 445

udp.port == 53

Use filters to narrow analysis rather than collecting unnecessary traffic.

Part 11 — Analyze TCP Traffic

Generate an authorized TCP connection to a known lab service.

Observe:

SYN
  ↓
SYN, ACK
  ↓
ACK

This is the TCP three-way handshake.

Record:

Source:

Destination:

Source Port:

Destination Port:

Handshake Complete:
Yes / No

Application Protocol:

Part 12 — Understand TCP Connection Closure

You may observe:

FIN

ACK

during normal connection termination.

You may also see:

RST

indicating a reset.

Do not interpret every reset as malicious activity.

Part 13 — Analyze UDP Traffic

Generate a known DNS request or other authorized UDP communication.

Unlike TCP, UDP does not require a connection handshake.

Observe:

Client
  │
  ├── UDP Request
  ▼
Server
  │
  └── UDP Response

Record:

Source:

Destination:

Protocol:

Request:

Response:

Stateful Handshake:
No

Part 14 — Analyze DNS Traffic

Generate a lab DNS query:

dig @192.168.56.40 host1.example.test

Filter:

dns

Observe:

• source

• destination

• query name

• record type

• response

• DNS flags

Part 15 — Build the DNS Traffic Profile

DNS TRAFFIC PROFILE

Client:

Resolver:

Query:

Record Type:

Response:

Transport:
UDP / TCP

Query Visible:
Yes / No

Response Visible:
Yes / No

Encryption:
Yes / No / Not Applicable to Lab Design

Assessment:

Part 16 — Understand DNS Metadata Exposure

Traditional DNS commonly exposes queried names to systems along the relevant network path.

Example:

db01.example.test

may reveal infrastructure naming.

But:

DNS Query Visible
     ≠
Sensitive Data Breach

Assess context.

Part 17 — Compare HTTP and HTTPS

This is one of the most important exercises.

Generate an authorized HTTP request:

curl http://192.168.56.20

Filter:

http

Observe what can be decoded.

You may see:

• request method

• host

• path

• headers

• response status

• content

Part 18 — Build the HTTP Traffic Profile

Client:

Server:

Protocol:
HTTP

Method:

Path:

Headers Visible:
Yes / No

Content Visible:
Yes / No

Encryption:
No

Sensitive Information Present:
Yes / No

Part 19 — Analyze HTTPS

Generate:

curl https://192.168.56.20

where your lab supports HTTPS.

Filter:

tls

You should generally observe encrypted application payload rather than readable HTTP content.

You may still observe metadata such as:

• source IP

• destination IP

• ports

• TLS negotiation

• certificate-related information

• packet sizes

• timing

Part 20 — Understand Encryption vs Metadata

Encryption can protect content while still leaving network metadata visible.

Conceptually:

Visible:
Client IP
Server IP
Port
Timing
Packet Size

Protected:
Application Payload
Credentials
Page Content

Therefore:

Encrypted ≠ Invisible

Part 21 — Build the HTTP vs HTTPS Comparison

Characteristic	HTTP	HTTPS
Destination visible	Yes	Yes
Port visible	Yes	Yes
Path readable	Often	Generally encrypted
Headers readable	Often	Generally encrypted
Application content readable	Often	Generally encrypted
TLS used	No	Yes

Part 22 — Assess Plaintext Authentication Carefully

If your intentionally vulnerable lab provides a designated plaintext login exercise, use only the supplied test credentials.

Do not enter:

• personal credentials

• production credentials

• reused passwords

Capture only the designated lab transaction.

The goal is to demonstrate:

Plaintext authentication can expose credentials to a system positioned to observe the network path.

Part 23 — Document the Plaintext Authentication Observation

Use:

Finding Candidate:

Service:

Transport:

Authentication:
Lab credential only

Credential Material Visible:
Yes / No

Sensitive Value Included in Report:
No

Security Impact:

Evidence Reference:

Never paste the actual password into the report.

Part 24 — Assess FTP Traffic Where Present

If the lab intentionally includes FTP, generate only an authorized test connection.

FTP control traffic may be readable if not encrypted.

Assess:

Protocol:

Encryption:

Authentication Information Exposure:

Command Metadata:

Expected:

Do not transfer unrelated data.

Part 25 — Compare FTP, FTPS, and SFTP

Conceptually:

FTP
→ traditional protocol
→ may use plaintext transport

FTPS
→ FTP protected with TLS

SFTP
→ file transfer over SSH

Do not confuse SFTP with FTP.

Part 26 — Analyze SSH Traffic

Generate a supplied-account SSH session:

ssh lab-user@192.168.56.20

Filter:

tcp.port == 22

Observe that the session payload is not readable as plaintext application commands.

Record:

Source:

Destination:

Port:
22

Protocol:
SSH

Transport Encryption:
Yes

Application Commands Visible:
No

Credentials Visible:
No

Part 27 — Understand What SSH Still Reveals

Even encrypted SSH traffic exposes metadata such as:

• source address

• destination address

• connection timing

• port

• session duration

• traffic volume

Do not interpret this metadata as decrypted activity.

Part 28 — Analyze RDP Traffic

Where your lab includes RDP, generate an authorized session using the supplied test account.

Filter:

tcp.port == 3389

Record:

Client:

Server:

Protocol:
RDP

Encrypted Session Data:
Observed

Screen Content Readable from Capture:
No

Authentication Content Readable:
No / Depends on lab design and protocol configuration

Assessment:

Do not attempt to weaken encryption.

Part 29 — Analyze SMB Traffic

Using the supplied test account, perform an authorized access to a designated training share.

Filter:

tcp.port == 445

Observe:

• SMB session traffic

• client/server addresses

• share-related operations

• protocol metadata

Depending on SMB version/configuration, some application-level information may be protected differently.

Do not extract unrelated files.

Part 30 — Build the SMB Traffic Profile

Client:

Server:

Port:
445

SMB Version:
If known

Authentication:
Authorized test account

Signing:
If known

Encryption:
Enabled / Disabled / Unknown

Share Metadata Visible:

File Content Visible:
Yes / No / Not Assessed

Assessment:

Part 31 — Understand SMB Signing vs Encryption

These are not the same.

Signing

Helps protect message integrity.

Encryption

Protects message confidentiality.

Therefore:

SMB Signed
   ≠
SMB Encrypted

This is an important distinction.

Part 32 — Analyze DNS, SMB, and SSH Side by Side

Create:

Protocol	Port	Payload Readable	Encryption	Security Role
DNS	53	Often	Traditional DNS plaintext	Infrastructure
HTTP	80	Yes	No	Web
HTTPS	443	Generally no	TLS	Web
SSH	22	No	Yes	Admin
SMB	445	Depends on config/version	Context	File sharing

Part 33 — Analyze NTP Traffic

Where NTP is present:

udp.port == 123

Observe:

• client

• server

• request/response

• timestamps

• service behavior

Do not generate amplification traffic.

Part 34 — Analyze SNMP Traffic

Where authorized SNMP polling exists and a supplied credential is available:

udp.port == 161

Observe the management communication.

Document:

SNMP Version:

Source:

Destination:

Information Visible:

Management Network:

Expected:

Do not guess credentials or perform write operations.

Part 35 — Identify Unexpected Protocols

During your baseline or controlled capture, you may observe unexpected traffic.

Examples:

FTP from a web server

Database traffic from a user workstation

SMB from guest segment

Unexpected cleartext administration

Record it.

Do not immediately label it malicious.

Part 36 — Build the Unexpected Traffic Register

Source	Destination	Protocol	Expected	Status
			No	Review

Possible classifications:

• expected after review

• unexpected application behavior

• architecture issue

• misconfiguration

• unknown

Part 37 — Identify Unusual Destinations

Compare observed destination systems against the known architecture.

Example:

Web Server
    ↓
Database Server

Expected.

But:

User Workstation
    ↓
Database Server

may require review.

Part 38 — Build the Communication Matrix

Source	Destination	Protocol	Purpose	Expected
User	Web	HTTPS	Application	Yes
Web	DB	Database	Application backend	Yes
User	DB	Database	Direct DB access	No

This becomes useful later in segmentation assessment.

Part 39 — Assess Sensitive Information Exposure

Potential examples include:

• credentials

• session identifiers

• internal paths

• application parameters

• hostnames

• filenames

• query names

• system metadata

Create:

Information	Protocol	Protected	Sensitivity
Username	HTTP	No	Medium
Password	HTTP	No	High
DNS hostname	DNS	No	Context
File content	SMB	Depends	Context

Do not include actual secrets in your final report.

Part 40 — Redact Sensitive Evidence

If packet evidence contains test credentials, redact the secret.

Example:

Username:
lab-user

Password:
[REDACTED]

The finding only needs enough evidence to demonstrate the condition.

Part 41 — Assess Application Encryption

For each important protocol ask:

Is encryption present?

Is authentication data protected?

Is sensitive content protected?

Is encryption required or optional?

Is the protocol appropriate for the data?

Build an Encryption Matrix.

Part 42 — Build the Encryption Matrix

Communication	Protocol	Encryption	Expected	Status
User → Web	HTTPS	Yes	Yes	Pass
Admin → Linux	SSH	Yes	Yes	Pass
User → Legacy App	HTTP	No	No	Review

Part 43 — Identify Plaintext Legacy Protocols

Examples may include:

Telnet

FTP

HTTP administration

Older cleartext application protocols

The finding should focus on sensitive information exposure rather than merely the protocol name.

Part 44 — Assess Whether Plaintext Is Actually Sensitive

Example:

HTTP delivering a public static test page

does not carry the same risk as:

HTTP carrying administrative credentials

Context matters.

Part 45 — Understand Content vs Metadata Exposure

Use:

Content Exposure

Actual application information is readable.

Examples:

• credentials

• page content

• commands

• files

Metadata Exposure

Communication characteristics are visible.

Examples:

• source

• destination

• port

• protocol

• timing

• size

Both can be security relevant, but they are not equivalent.

Part 46 — Build the Exposure Classification Register

Traffic	Exposure Type	Example
HTTP	Content	Headers/content
HTTPS	Metadata	Endpoints/timing
SSH	Metadata	Connection
DNS	Content/Metadata	Query names

Part 47 — Identify Authentication Traffic

Mark services where authentication occurs:

SSH

RDP

SMB

Web Login

FTP

Database

Ask:

Is authentication information protected appropriately in transit?

Part 48 — Assess Management Traffic

Administrative traffic deserves particular attention.

Examples:

SSH

RDP

HTTPS Administration

SNMP

Database Administration

Management traffic should generally use appropriate transport protection and network restrictions.

Part 49 — Build the Management Traffic Register

Service	Source	Destination	Encrypted	Expected Source
SSH	Admin	Linux	Yes	Mgmt network
RDP	Admin	Windows	Yes	Mgmt network
HTTP Admin	User	Device	No	Review

Part 50 — Assess Internal Segmentation from Traffic

Packet analysis can reveal which systems communicate.

You may identify:

User → Server

Server → Server

Management → Server

Infrastructure → Infrastructure

This can help validate architecture assumptions.

However:

Seeing traffic does not by itself prove a firewall rule permits every possible flow.

Lab 12 will perform dedicated segmentation assessment.

Part 51 — Build the Protocol Security Register

Create:

Protocol	Host Pair	Authentication	Encryption	Information Exposure	Priority
HTTP			No	Content	High
HTTPS			Yes	Metadata	Low
SSH		Yes	Yes	Metadata	Low
DNS		N/A	No	Queries	Context

Part 52 — Identify Positive Controls

Examples:

Administrative SSH traffic encrypted.

Web login redirected to HTTPS.

RDP session content not readable.

Database traffic restricted to application server.

Sensitive SMB traffic uses appropriate protection.

Management traffic originates only from approved networks.

Document positive controls explicitly.

Part 53 — Build the Traffic Security Control Matrix

Control	Status	Evidence
Web authentication encrypted
SSH encrypted
RDP protected
SMB protection appropriate
Database access restricted
Management traffic restricted
Plaintext credentials absent

Part 54 — Classify Findings

Use:

Positive Control

Communication is protected as expected.

Observation

Security-relevant metadata/content is visible.

Potential Weakness

More context is required.

Validated Finding

Sensitive information is demonstrably exposed or communication violates the intended design.

Inconclusive

Available capture evidence is insufficient.

Part 55 — Example Finding — Plaintext Web Authentication

Where your intentionally vulnerable lab confirms it:

Finding ID:
NET-01

Title:
Administrative Credentials Transmitted Over Unencrypted HTTP

Asset:
192.168.56.20

Protocol:
HTTP

Severity:
High

Confidence:
High

Description:
The training administrative interface accepts authentication over
unencrypted HTTP.

Packet analysis of the authorized test login demonstrated that
authentication information was transmitted without TLS protection.

Evidence:
A controlled lab capture confirmed the condition. Password values
have been redacted from all retained reporting evidence.

Impact:
A system capable of observing the relevant network path could
potentially recover authentication information and use it to gain
unauthorized access.

Recommendation:
Require HTTPS for all authentication and administrative functions
and disable or redirect unencrypted HTTP access.

Retest:
Repeat the authorized login while capturing traffic and confirm
that authentication data is protected by TLS.

Part 56 — Example Finding — Direct Database Communication

Finding ID:
NET-02

Title:
User Network Can Communicate Directly with Database Service

Source:
User Segment

Destination:
Database Server

Protocol:
Database Protocol

Severity:
Medium

Confidence:
High

Description:
Network traffic confirmed direct connectivity between the user
assessment segment and the database service.

The intended architecture specifies that database communication
should originate only from the application tier and approved
administration systems.

Impact:
Direct database exposure increases the number of systems able to
interact with the database authentication surface.

Recommendation:
Restrict database connectivity to required application and
administrative systems.

Retest:
Confirm database traffic can no longer be established directly
from the user segment.

Part 57 — Example Observation — DNS Query Visibility

Finding ID:
NET-OBS-01

Title:
Internal DNS Query Names Visible in Network Traffic

Classification:
Observation

Description:
Authorized packet analysis confirmed that traditional DNS traffic
contains readable internal query names.

Security Context:
This behavior is consistent with traditional unencrypted DNS.
Whether additional protection is required depends on architecture,
privacy requirements, and organizational policy.

Recommendation:
Review DNS privacy requirements and ensure DNS access is limited to
approved resolvers and network paths.

Part 58 — Example Positive Control — HTTPS

Control:
Web Authentication Transport Protection

Observation:
The administrative web application redirects users to HTTPS, and
captured application content was protected by TLS.

Assessment:
Transport security operating as expected.

Part 59 — Example Positive Control — SSH

Control:
Remote Administration Encryption

Observation:
The supplied training user established an SSH session to the Linux
server. Packet analysis showed encrypted SSH application traffic,
and authentication credentials were not readable in the capture.

Assessment:
Remote administrative traffic is protected in transit.

Part 60 — Build the Findings Register

ID	Communication	Condition	Severity	Confidence
NET-01	Web Auth	Plaintext credentials	High	High
NET-02	User → DB	Unexpected access path	Medium	High
NET-OBS-01	DNS	Query visibility	Observation	High

Populate only validated lab conditions.

Part 61 — Build the Network Communication Map

Example:

                  User Workstation
                       │
                       │ HTTPS
                       ▼
                    Web Server
                       │
                       │ Database Protocol
                       ▼
                  Database Server


                  Admin Workstation
                    │          │
                  SSH          RDP
                    │          │
                    ▼          ▼
                 Linux       Windows


                       DNS
          Clients ─────────► Resolver

Mark:

• encrypted

• plaintext

• expected

• unexpected

Part 62 — Add Security Characteristics to the Map

For example:

User
 │
 │ HTTPS [Encrypted]
 ▼
Web
 │
 │ DB Protocol [Restricted]
 ▼
Database

and:

Admin
 │
 │ HTTP [Plaintext - Review]
 ▼
Legacy Management UI

This turns a network map into a security map.

Part 63 — Build the Final Traffic Security Profile

NETWORK TRAFFIC SECURITY PROFILE

Capture Interface:

Authorized Network:

Capture Duration:

Protocols Observed:

Encrypted Protocols:

Plaintext Protocols:

Authentication Protocols:

Management Protocols:

Infrastructure Protocols:

Unexpected Communications:

Sensitive Content Observed:

Sensitive Metadata Observed:

Plaintext Credentials:
Yes / No

Management Traffic Restricted:
Yes / No / Unknown

Positive Controls:

Validated Findings:

Highest-Priority Issue:

Part 64 — Preserve Evidence Properly

Keep:

Original PCAP

separate from:

Analysis Copy

Document:

File Name:

Capture Date:

Capture Interface:

Authorized Scope:

Analyst:

Evidence Hash:
Optional according to lab requirements

Sensitive Information:
Redacted in report

Do not unnecessarily distribute captures containing authentication activity.

Part 65 — Create the Command Journal

Example:

TIME:
14:05

ACTION:
Started capture on lab interface.

COMMAND:
sudo tcpdump -i eth1 net 192.168.56.0/24 -w Evidence/lab.pcap

PURPOSE:
Capture only authorized lab communication.

RESULT:
Capture started.

NOTES:
No unrelated network traffic observed.

Part 66 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Network Traffic & Protocol Security Assessment

Authorized Network:

Capture Interface:

Capture Start:

Capture End:

Investigator:


BASELINE

Hosts Observed:

Protocols Observed:

Expected Traffic:

Unexpected Traffic:


DNS

Client:

Resolver:

Query Visible:
Yes / No

Response Visible:
Yes / No

Internal Names Observed:

Assessment:


HTTP

Client:

Server:

Request Visible:

Headers Visible:

Content Visible:

Authentication Present:

Encryption:
No

Sensitive Information:
Yes / No

Assessment:


HTTPS

Client:

Server:

TLS Present:

Application Content Readable:
Yes / No

Credentials Readable:
Yes / No

Metadata Visible:

Assessment:


SSH

Client:

Server:

Encrypted:
Yes / No

Commands Readable:
Yes / No

Credentials Readable:
Yes / No

Assessment:


RDP

Client:

Server:

Transport Protected:

Session Content Readable:

Assessment:


SMB

Client:

Server:

Protocol Version:

Signing:

Encryption:

Share Metadata Visible:

File Content Visible:

Assessment:


OTHER PROTOCOLS

Protocol:

Source:

Destination:

Encrypted:

Expected:

Sensitive Information:


COMMUNICATION ANALYSIS

Expected Host Pairs:

Unexpected Host Pairs:

Direct Database Access:

Unexpected Management Access:

Plaintext Administrative Traffic:


POSITIVE CONTROLS

HTTPS:

SSH:

RDP:

SMB:

Database Segmentation:

Management Traffic:


FINAL ANALYSIS

Most Significant Plaintext Protocol:

Most Sensitive Information Exposed:

Most Important Unexpected Communication:

Best Positive Security Control:

Validated Findings:

Observations:

Inconclusive Items:

Ready for Network Segmentation & Access Control Assessment:
Yes / No

Part 67 — What Not to Do

Do not:

Capture traffic outside the authorized lab

Capture corporate or public network traffic

Use ARP spoofing

Perform man-in-the-middle attacks

Poison DNS

Hijack sessions

Downgrade encryption

Attempt SSL stripping

Steal authentication tokens

Collect real credentials

Use personal passwords in test traffic

Capture unrelated user data

Analyze unrelated communications

Decrypt traffic using unauthorized keys

Modify packets

Inject packets into sessions

Reset unrelated connections

Perform traffic flooding

Perform denial-of-service activity

Expose PCAP files publicly

Include plaintext passwords in reports

The professional principle is:

Observe the authorized communication path without creating a new attack against it.

Troubleshooting

No Traffic Appears

Verify:

Correct interface

Correct subnet

Correct virtual-network mode

Traffic is actually being generated

You See Internet Traffic

Stop the capture.

Verify that you selected the isolated lab interface.

HTTP Filter Shows Nothing

The application may:

• redirect to HTTPS

• use a different port

• use another protocol

Check the communication baseline.

HTTPS Content Is Not Readable

That is normally expected.

Document the presence of TLS rather than trying to bypass it.

SSH Commands Cannot Be Read

That is expected because SSH protects application content.

SMB Traffic Is Difficult to Interpret

Record:

• client

• server

• port

• protocol

• known authentication event

• observed protection

Do not force deeper interpretation beyond available evidence.

Packet Capture Contains a Test Password

Do not include it in course screenshots or the final report.

Redact it immediately in derived evidence.

Evidence Requirements

Capture:

Evidence 01

Scope authorization.

Evidence 02

Capture-interface validation.

Evidence 03

Baseline capture.

Evidence 04

Traffic Baseline Register.

Evidence 05

TCP handshake evidence.

Evidence 06

UDP communication evidence.

Evidence 07

DNS traffic.

Evidence 08

DNS Traffic Profile.

Evidence 09

HTTP traffic.

Evidence 10

HTTPS/TLS traffic.

Evidence 11

HTTP-vs-HTTPS comparison.

Evidence 12

SSH traffic.

Evidence 13

RDP traffic where available.

Evidence 14

SMB Traffic Profile.

Evidence 15

NTP/SNMP traffic where applicable.

Evidence 16

Unexpected Traffic Register.

Evidence 17

Communication Matrix.

Evidence 18

Information Exposure Register.

Evidence 19

Encryption Matrix.

Evidence 20

Management Traffic Register.

Evidence 21

Protocol Security Register.

Evidence 22

Traffic Security Control Matrix.

Evidence 23

Findings Register.

Evidence 24

Network Communication Map.

Evidence 25

Final Traffic Security Profile.

Evidence 26

Mission Challenge worksheet.

Mission Deliverables

Complete:

• capture scope confirmed

• correct interface identified

• unrelated traffic excluded

• baseline capture completed

• traffic baseline documented

• TCP communication analyzed

• UDP communication analyzed

• DNS traffic assessed

• HTTP traffic assessed

• HTTPS traffic assessed

• HTTP vs HTTPS compared

• plaintext authentication assessed only in designated lab scenario

• SSH traffic reviewed

• RDP traffic reviewed where available

• SMB traffic assessed

• NTP/SNMP traffic reviewed where present

• unexpected protocols identified

• communication matrix completed

• sensitive information exposure documented

• content vs metadata differentiated

• encryption matrix completed

• management traffic reviewed

• positive security controls documented

• sensitive evidence redacted

• PCAP preserved securely

• validated findings written

• remediation prepared

• retest criteria defined

• final Network Traffic Security Profile completed

• final report completed

Lab Report Template

# Lab 11 — Network Traffic & Protocol Security Assessment

## Executive Summary

## Mission Objective

## Authorization and Scope

## Capture Architecture

## Capture Interface

## Baseline Traffic

## Assessment Methodology

## TCP Analysis

## UDP Analysis

## DNS Traffic Analysis

## HTTP Analysis

## HTTPS/TLS Analysis

## HTTP vs HTTPS Comparison

## SSH Traffic Analysis

## RDP Traffic Analysis

## SMB Traffic Analysis

## Infrastructure Protocols

## Unexpected Traffic

## Communication Matrix

## Sensitive Information Exposure

## Content vs Metadata Exposure

## Encryption Assessment

## Management Traffic

## Positive Security Controls

## Validated Findings

### NET-01
### NET-02

## Observations

## Inconclusive Items

## Evidence Handling

## Recommendations

## Retest Criteria

## Limitations

## Conclusion

Knowledge Check

Question 1 — What is the main difference between a capture filter and a display filter?

A capture filter determines what traffic is recorded. A display filter controls which captured packets are shown during analysis.

Question 2 — Does HTTPS hide source and destination IP addresses?

No.

It protects application content, but network metadata remains visible.

Question 3 — Why can traditional HTTP be risky for authentication?

Because application content may travel without encryption and could expose credentials or session information to systems capable of observing the network path.

Question 4 — Can you normally read commands from an SSH packet capture?

No.

SSH encrypts the application session.

Question 5 — Does SMB signing mean SMB traffic is encrypted?

No.

Signing provides integrity protection; encryption provides confidentiality.

Question 6 — Does seeing a DNS hostname in a packet automatically mean a vulnerability exists?

No.

It is an information-exposure observation that must be evaluated in context.

Question 7 — What should you do if you accidentally capture unrelated traffic?

Stop the capture, verify the interface and scope, and continue only when the capture can be limited to authorized traffic.

Question 8 — Should packet captures containing passwords be attached directly to a report?

Not without appropriate protection and redaction. The report should normally contain only the minimum evidence needed.

Question 9 — Why create a communication matrix?

It helps determine which systems communicate, which protocols they use, and whether those communication paths match the expected architecture.

Question 10 — What is the central question of this lab?

What information is visible while authorized systems communicate, which protocols expose sensitive data, and are critical communications protected appropriately in transit?

Skills Achieved

After completing this lab, you should understand:

• packet-capture fundamentals

• authorized interface selection

• tcpdump basics

• Wireshark analysis

• capture vs display filters

• TCP traffic analysis

• UDP traffic analysis

• DNS packet analysis

• HTTP security

• HTTPS/TLS protection

• plaintext authentication awareness

• SSH traffic security

• RDP traffic analysis

• SMB traffic security

• SMB signing vs encryption

• infrastructure protocol analysis

• communication baselining

• unexpected traffic identification

• sensitive-information exposure analysis

• content vs metadata exposure

• traffic evidence preservation

• evidence-based protocol findings

Professional Takeaway

A weak traffic assessment looks like:

Capture Everything
      ↓
Search for Secrets
      ↓
Report Anything Interesting

A professional assessment looks like:

Define Scope
    ↓
Select Authorized Interface
    ↓
Capture Controlled Traffic
    ↓
Identify Communication
    ↓
Identify Protocol
    ↓
Assess Encryption
    ↓
Assess Content Exposure
    ↓
Compare with Expected Architecture
    ↓
Preserve Evidence
    ↓
Write Finding

Always distinguish:

Traffic Visible
     ≠
Content Readable

Encrypted Traffic
     ≠
No Metadata Exposure

DNS Query Visible
     ≠
DNS Vulnerability

HTTP Present
     ≠
Sensitive Information Exposed

SMB Signed
     ≠
SMB Encrypted

Unexpected Communication
     ≠
Malicious Communication

Packet Captured
     ≠
Permission to Inspect Unrelated Data

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

“Which authorized systems communicate with each other, which protocols they use, what information those protocols expose, and whether sensitive communications receive appropriate protection in transit?”

What’s Next?

➡️ Lab 12 — Network Segmentation & Access Control Assessment

In the next lab, you will use the service inventories and communication maps from the previous labs to assess whether network trust boundaries are working as intended.

You will evaluate:

• user network → server network access

• management network restrictions

• guest network isolation

• database-tier exposure

• administrative service reachability

• east-west communication

• expected vs observed flows

• firewall and ACL enforcement

• allowed vs denied paths

• segmentation gaps

• management-plane isolation

• least-privilege network access

• evidence-based segmentation findings

The methodology becomes:

Source Zone → Destination Zone → Required Service → Observed Reachability → Expected Policy → Evidence → Finding

The central question will be:

“Can systems communicate only across the network paths required for legitimate business functions, or do unnecessary trust relationships expose sensitive services across security boundaries?”