Lab 08 Network Forensics & Packet Investigation

Mission Overview

Welcome to Lab 08 — Network Forensics & Packet Investigation.

So far, you have investigated:

• disk evidence

• deleted files

• Windows artifacts

• Linux artifacts

• memory

• phishing and browser activity

Now you will investigate what happened across the network.

Network forensics can help answer questions such as:

• Which systems communicated?

• Which protocols were used?

• Which external destinations were contacted?

• What DNS queries occurred?

• Did browser activity correspond with observed network traffic?

• Was a downloaded file visible in network evidence?

• Which process or endpoint activity aligns with the communication?

• Was the traffic normal, suspicious, or inconclusive?

The central question is:

What communication occurred, between which systems, when did it happen, and how does the network evidence correlate with endpoint and user activity?

Mission Goal: Verify and examine a provided PCAP or network-evidence set, identify hosts and conversations, analyze DNS and protocol activity, review network sessions, correlate traffic with endpoint evidence, reconstruct a network timeline, and produce a defensible Network Forensics Investigation Report.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Network Forensics
Secondary Skill	Packet & Protocol Analysis
Environment	GoHackersCloud Digital Forensics Lab
Evidence Type	Training PCAP / exported network logs
Testing Type	Offline evidence analysis
Primary Outcome	Network Evidence Correlation Matrix
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• verify PCAP integrity

• understand packet-capture evidence

• identify internal and external hosts

• identify network conversations

• examine protocols

• analyze DNS requests and responses

• review TCP sessions

• interpret connection metadata

• examine HTTP activity

• understand HTTPS limitations

• identify file-transfer evidence where visible

• recognize repeated communication patterns

• distinguish normal traffic from investigation leads

• correlate network evidence with browser activity

• correlate network activity with endpoint processes

• build a network activity timeline

• identify network indicators

• distinguish observation from conclusion

• maintain evidence lineage

• produce a professional packet-investigation report

Network Forensics Methodology

Use:

PCAP → Hosts → Conversations → Protocol → DNS → Session → Application Metadata → Correlation → Timeline → Evidence

Conceptually:

Packet Capture
     │
     ▼
Evidence Integrity
     │
     ▼
Host Identification
     │
     ▼
Network Conversations
     │
     ▼
Protocol Analysis
     │
     ▼
DNS / Name Resolution
     │
     ▼
Sessions
     │
     ▼
Application Metadata
     │
     ▼
Endpoint Correlation
     │
     ▼
Timeline
     │
     ▼
Supported Conclusion

The key principle is:

A connection is evidence of communication, not automatically evidence of compromise.

Part 1 — Understand Network Evidence

Common network-forensics evidence includes:

PCAP

Firewall Logs

Proxy Logs

DNS Logs

VPN Logs

NetFlow

Cloud Network Logs

IDS / IPS Alerts

Web Gateway Logs

In this lab, the primary evidence source is a supplied training PCAP.

Part 2 — Understand What a PCAP Contains

A PCAP can contain captured network packets.

Depending on where the capture was taken, it may reveal:

• source addresses

• destination addresses

• ports

• protocols

• timestamps

• packet sizes

• DNS

• TCP sessions

• HTTP requests

• unencrypted application data

• encrypted session metadata

It does not necessarily contain every packet generated by the system.

Part 3 — Understand Capture Perspective

Before analyzing traffic, determine:

Where was the capture taken?

Possibilities include:

Endpoint

Switch Port

Network Sensor

Firewall

Router

Cloud Network Interface

Capture location affects interpretation.

For example:

Endpoint Capture
      ≠
Entire Enterprise Traffic

Record:

Capture Point:

Network Segment:

Known Endpoint:

Known Gateway:

Known Time Period:

Part 4 — Confirm Evidence Integrity

Document:

Case ID:

Evidence ID:

PCAP Filename:

PCAP Size:

Expected SHA-256:

Current SHA-256:

Hash Match:

Capture Start:

Capture End:

Investigator:

Verify:

sha256sum training-network.pcap

Record:

Recorded Hash:

Current Hash:

Match:
Yes / No

Do not continue with a corrupted or unexplained evidence mismatch.

Part 5 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-08/
    ├── Notes/
    ├── Evidence/
    │   ├── PCAP/
    │   ├── Hosts/
    │   ├── Conversations/
    │   ├── DNS/
    │   ├── TCP/
    │   ├── HTTP/
    │   ├── TLS/
    │   ├── Files/
    │   └── Indicators/
    ├── Screenshots/
    ├── Timeline/
    ├── Findings/
    └── Report/

Create:

Lab-08-Network-Forensics-Journal.md

Suggested structure:

# Lab 08 — Network Forensics & Packet Investigation

## Mission Objective

## Evidence Information

## Integrity Verification

## Capture Context

## Host Inventory

## Conversation Analysis

## Protocol Distribution

## DNS Analysis

## TCP Analysis

## HTTP Analysis

## TLS Analysis

## File Transfer Evidence

## Indicators

## Endpoint Correlation

## Timeline

## Findings

## Limitations

## Conclusion

Part 6 — Open the PCAP Safely

Use an offline packet-analysis tool such as:

• Wireshark

• tshark

• another approved forensic network-analysis tool

Do not replay traffic.

Do not connect to observed external destinations.

This is evidence examination only.

Part 7 — Record Capture Statistics

Document:

Capture Duration:

Total Packets:

Total Bytes:

First Packet:

Last Packet:

Protocols Observed:

This provides basic scope.

Part 8 — Build the Host Inventory

Identify IP addresses participating in the capture.

Create:

Host ID	IP Address	Internal/External	Role	Notes
HOST-01		Internal	Endpoint
HOST-02		Internal	DNS
HOST-03		External	Unknown

Do not assume every external IP is suspicious.

Part 9 — Identify Private vs Public Addresses

Private IPv4 ranges commonly include:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

These usually represent internal/private addressing.

Network architecture may still use other ranges.

Use the case context.

Part 10 — Identify the Primary Investigated Endpoint

Determine the host corresponding to the system examined in earlier labs.

Record:

Endpoint Hostname:

IP Address:

MAC Address:
If available

Evidence Supporting Mapping:

Possible correlation sources:

• DHCP

• ARP

• endpoint configuration

• DNS

• previous forensic evidence

Part 11 — Build the Conversation Register

A conversation is communication between endpoints.

Create:

ID	Source	Destination	Protocol	Packets	Bytes	Relevance
CONV-01			TCP
CONV-02			UDP

Prioritize case-relevant conversations.

Part 12 — Understand Protocol Distribution

Common protocols may include:

ARP

DNS

TCP

UDP

HTTP

TLS

ICMP

DHCP

Protocol presence by itself is not suspicious.

For example:

DNS + TLS + HTTPS

is normal for modern browsing.

Part 13 — Build the Protocol Register

Protocol	Packet Count	Relevance
DNS		High
TCP		High
HTTP		Case dependent
TLS		High
ARP		Context

Part 14 — Start with DNS

DNS often provides valuable context because it links:

Human-readable Domain
        ↓
IP Address

Search for DNS traffic.

Record:

Client:

Queried Domain:

Query Type:

Response:

Resolved IP:

Timestamp:

Part 15 — Build the DNS Evidence Register

Time	Client	Query	Type	Response	Relevance
			A
			AAAA

Part 16 — Understand DNS Record Types

Common record types include:

A

IPv4 address.

AAAA

IPv6 address.

CNAME

Alias to another hostname.

MX

Mail server information.

TXT

Text records, including some domain-security information.

In this lab, focus primarily on records relevant to observed network activity.

Part 17 — Correlate DNS with the Phishing Lab

Suppose Lab 07 identified:

training-login.example

and the PCAP shows:

09:07:12
DNS Query:
training-login.example

This provides independent network evidence.

Conceptually:

Email URL
   +
Browser History
   +
DNS Query
   =
Stronger Link-Interaction Evidence

Part 18 — Understand DNS Limitations

A DNS request does not prove:

Page Viewed

It establishes:

A system or application requested name resolution.

The request may come from:

• browser

• application

• background process

• security software

• DNS prefetching

Correlate.

Part 19 — Review DNS Timing

Compare:

DNS Request
     ↓
TCP Connection
     ↓
TLS / HTTP Activity

Example:

09:07:12 DNS query
09:07:13 TCP connection
09:07:13 TLS session

That sequence provides useful context.

Part 20 — Analyze TCP Conversations

TCP provides reliable connection-oriented communication.

A simplified session begins:

SYN
 ↓
SYN/ACK
 ↓
ACK

This is the TCP three-way handshake.

The handshake supports establishment of a TCP connection.

Part 21 — Build the TCP Session Register

Session	Source	Source Port	Destination	Destination Port	Status
TCP-01
TCP-02

Part 22 — Understand Ports

Common ports may include:

53    DNS

80    HTTP

443   HTTPS

22    SSH

25    SMTP

But:

Port number does not guarantee protocol.

Applications can communicate over nonstandard ports.

Part 23 — Identify Relevant External Connections

Prioritize connections involving:

• case-relevant domains

• case-relevant IPs

• phishing infrastructure

• unusual destinations

• known training indicators

• unusual timing

Build:

Time	Internal Host	External IP	Port	Related Domain

Part 24 — Understand Connection States

Depending on your evidence, you may observe:

Connection Established

Reset

Closed

Repeated SYN

Incomplete Handshake

Do not assume a failed handshake means an attack.

Context matters.

Part 25 — Analyze HTTP Traffic

If HTTP is present and unencrypted, you may observe:

Request Method

Host

URI

User-Agent

Response Code

Content Type

Content Length

Record only what is relevant.

Part 26 — Build the HTTP Evidence Register

Time	Source	Host	Method	URI	Response
			GET
			POST

Do not replay requests.

Part 27 — Understand GET and POST

GET

Typically retrieves a resource.

POST

Typically submits data.

However:

POST request does not automatically mean credentials were submitted.

You must inspect available evidence carefully.

Part 28 — Handle Sensitive HTTP Data

Unencrypted HTTP may expose:

• usernames

• form fields

• session identifiers

• other private data

Do not unnecessarily reproduce sensitive values.

Redact them where appropriate.

Part 29 — Correlate HTTP with Browser Evidence

Suppose browser history shows:

09:10
http://training-site.example/login

and network evidence shows:

09:10
GET /login
Host: training-site.example

Now the evidence sources corroborate each other.

Part 30 — Understand HTTPS

Most modern web traffic is encrypted with TLS.

With HTTPS, packet evidence may still expose metadata such as:

• source/destination IP

• ports

• session timing

• packet sizes

• TLS handshake details

• server certificate details in some circumstances

• server name information depending on protocol/version/configuration

But application content may remain encrypted.

Part 31 — Do Not Claim to See Encrypted Content

Avoid:

“The user submitted credentials over HTTPS.”

if you only have encrypted packet traffic.

Better:

“The endpoint established an encrypted TLS session with the relevant destination.”

Human interaction requires additional evidence.

Part 32 — Examine TLS Session Metadata

Record where available:

Source:

Destination:

Port:

TLS Version:

Server Name:
If visible

Certificate Subject:
If relevant

Session Start:

Session End:

Part 33 — Build the TLS Evidence Register

Time	Client	Server	SNI/Host	TLS Version	Relevance

Part 34 — Understand SNI Carefully

Server Name Indication may identify the hostname requested during TLS setup.

However, availability depends on protocol and encryption mechanisms.

Do not assume SNI is always visible.

Part 35 — Review Certificates

Where available, certificate information may provide:

Subject

Issuer

Validity

Alternative Names

A valid certificate does not automatically mean the site is trustworthy.

Attack-controlled sites can have valid TLS certificates.

Part 36 — Examine User-Agent Metadata

HTTP traffic may contain a User-Agent identifying browser/application context.

Record:

User-Agent:

Observed Browser:

Version:
If supported

Correlation with Endpoint:

Treat it as contextual evidence.

Part 37 — Identify File Transfer Evidence

If file content is visible in the provided training traffic, identify:

Source

Destination

Filename:
If available

MIME Type

Content Length

Transfer Time

Do not export every object.

Prioritize case-relevant training artifacts.

Part 38 — Correlate with Browser Download

Suppose Lab 07 showed:

training-document.zip

and PCAP shows a corresponding HTTP response.

Now:

Browser Download Record
        +
Network Transfer
        +
Endpoint File
        =
Strong Download Evidence

Part 39 — Hash Exported Network Objects

If the lab requires extraction of a benign training object:

sha256sum exported-training-file

Compare with the endpoint file.

Record:

Network Object Hash:

Endpoint File Hash:

Match:
Yes / No

A match establishes identical file content.

Part 40 — Maintain Evidence Lineage

Example:

PCAP-01
   │
   ├── DNS-01
   ├── TCP-01
   ├── HTTP-01
   └── OBJ-01
          │
          ▼
Endpoint File

Document every derived artifact.

Part 41 — Examine Repeated Communication

Some systems communicate with the same destination repeatedly.

Create:

Destination	First Seen	Last Seen	Count	Pattern

Possible patterns include:

Periodic

Burst

Single Session

Irregular

A repeated pattern alone does not prove beaconing or command-and-control.

Part 42 — Understand Beaconing Conceptually

Regular periodic connections can sometimes be relevant during investigations.

Conceptually:

Connection
    ↓
Wait
    ↓
Connection
    ↓
Wait
    ↓
Connection

But legitimate software also performs scheduled network communication.

Do not classify periodicity alone as malicious.

Part 43 — Build the Communication Pattern Register

Source	Destination	Interval	Consistent	Interpretation

Classify as:

Expected

Requires Investigation

Supported Concern

Inconclusive

Part 44 — Examine Failed Connections

Repeated failed connections may be relevant.

Look for:

• SYN with no response

• resets

• DNS failures

• unreachable destinations

Record:

Source:

Destination:

Attempts:

Period:

Result:

Relevance:

Do not assume repeated failure means scanning.

Part 45 — Examine ICMP Where Relevant

ICMP may support:

• reachability testing

• network errors

• diagnostics

Typical ping-style traffic may be normal.

Record only when it contributes to the investigation.

Part 46 — Review ARP Evidence

ARP maps IP addresses to MAC addresses within local networks.

It can help identify:

IP ↔ MAC

Record where useful:

IP	MAC	Time	Role

This may help validate endpoint identity.

Part 47 — Correlate Host Identity

Combine:

Endpoint IP
    +
MAC
    +
Hostname
    +
DHCP / ARP
    +
Endpoint Evidence

This improves confidence that the network traffic belongs to the investigated system.

Part 48 — Build the Endpoint Network Profile

Create:

Hostname:

IP:

MAC:

Primary DNS:

Default Gateway:

Observed External Destinations:

Relevant Domains:

Relevant Protocols:

Part 49 — Correlate Network and Memory

Lab 06 may show:

PID 4240
training-app.exe
→ 203.0.113.20:443

Lab 08 may show:

Endpoint
→ 203.0.113.20:443

Now:

Memory Process
       +
Packet Evidence
       =
Process/Network Correlation

This is very strong when timestamps align.

Part 50 — Correlate Network and Windows Evidence

Example:

09:14 — Windows execution artifact

09:15 — DNS query

09:15 — TCP session

09:16 — external connection

The sequence may support a relationship between program activity and network communication.

Do not claim causality unless evidence connects them.

Part 51 — Correlate Network and Linux Evidence

For Linux:

SSH authentication
      +
Shell / service activity
      +
Outbound connection
      =
Stronger Investigation Context

Again, use timestamps and identity evidence carefully.

Part 52 — Correlate with Email and Browser Evidence

Combine Labs 07 and 08:

Email Delivered
      ↓
Browser Visit
      ↓
DNS Query
      ↓
TCP Connection
      ↓
TLS / HTTP
      ↓
Download

This can provide a defensible cross-evidence activity chain.

Part 53 — Normalize Timestamps

You may be working with:

PCAP timestamps

DNS logs

Endpoint logs

Browser timestamps

Memory times

Email timestamps

Record:

PCAP Timezone:

Endpoint Timezone:

Normalized Standard:

Clock Difference:
If identified

A few seconds of clock difference can matter when correlating events.

Part 54 — Identify Clock Skew

Suppose:

Browser:
09:10:05

while:

PCAP:
09:10:13

That does not automatically mean the events are unrelated.

Consider:

• clock skew

• logging delay

• timestamp precision

• system timezone

Document uncertainty.

Part 55 — Build the Network Timeline

Create:

Time	Source	Event	Confidence
09:07:12	DNS	domain resolved	Confirmed
09:07:13	TCP	session established	Confirmed
09:07:14	TLS	encrypted session	Confirmed
09:08:01	HTTP/browser	file transfer	Supported

Part 56 — Build the Cross-Evidence Timeline

Add evidence from previous labs:

Time	Evidence Source	Event
09:05	Email	message delivered
09:07	Browser	link visited
09:07	DNS	domain resolved
09:07	PCAP	connection established
09:08	Browser	file downloaded
09:08	Filesystem	file created
09:10	Memory	relevant process active

This is much stronger than an isolated PCAP review.

Part 57 — Build the Network Evidence Correlation Matrix

Create:

Question	PCAP	DNS	Browser	Endpoint	Memory	Confidence
Was domain resolved?	Yes	Yes				High
Was destination contacted?	Yes		Browser			High
Was file transferred?	HTTP		Download	File		High
Which process connected?	IP/port			Logs	Process	High

Part 58 — Classify Network Findings

Use:

Observation

Something visible in the evidence.

Relevant Communication

Traffic related to the investigation.

Supported Concern

Multiple artifacts suggest security significance.

Confirmed Activity

Specific activity is directly supported.

Avoid:

Malicious

unless the investigation has sufficient evidence to support that classification.

Part 59 — Example Finding: DNS and Connection Correlation

Finding:
Case-relevant domain resolution and subsequent network
communication were identified.

Observation:
The investigated endpoint issued a DNS query for the training
domain and received the designated training IP address.

Correlation:
A TCP connection to that address occurred immediately afterward.

Conclusion:
The evidence supports communication between the endpoint and the
infrastructure associated with the case-relevant domain.

Limitation:
Network metadata alone does not establish the user's intent or
the application-layer purpose of encrypted traffic.

Part 60 — Example Finding: Network File Transfer

Finding:
Network evidence supports transfer of the designated training
file.

Evidence:
The captured HTTP session contains a response corresponding to
the case-relevant file.

Correlation:
The exported network object and endpoint artifact produce the
same SHA-256 value.

Conclusion:
The available evidence supports that identical file content was
transferred to the endpoint during the observed session.

Part 61 — Example Observation: Encrypted Connection

Observation:
The investigated endpoint established a TLS session with the
case-relevant external destination.

Evidence:
The PCAP records the TCP and TLS session during the incident
window.

Limitation:
Application content is encrypted within the supplied evidence.

Conclusion:
Communication is confirmed, while the specific content exchanged
cannot be established from the packet capture alone.

Part 62 — Example Observation: Repeated Communication

Observation:
The endpoint communicated repeatedly with the same external
destination during the investigation period.

Pattern:
Connections occurred at approximately regular intervals.

Classification:
Requires Investigation.

Limitation:
Periodic communication may also occur with legitimate software;
additional endpoint and process evidence is required.

Part 63 — Build the Network Indicator Register

Create:

ID	Type	Value	First Seen	Source	Relevance
NET-IOC-01	Domain			DNS	High
NET-IOC-02	IP			PCAP	High
NET-IOC-03	URL			HTTP	High
NET-IOC-04	Hash			Exported file	High

Defang indicators in reports where appropriate.

Part 64 — Distinguish IOC from Attribution

An IP address or domain can show:

Infrastructure involved in observed communication.

It does not automatically prove:

Who owns or controls the infrastructure.

Infrastructure attribution requires additional evidence.

Part 65 — Build the Investigation Hypothesis Register

Hypothesis	Supporting Evidence	Missing Evidence	Status
Endpoint accessed phishing site	Browser + DNS + PCAP	None	Confirmed
File transferred from site	HTTP + browser + hash	None	Confirmed
Downloaded file initiated network activity	Memory + PCAP	direct process mapping	Supported
Repeated traffic is C2	periodicity	intent/content	Unconfirmed

Part 66 — Document Positive Evidence

Examples:

No unexpected external destination identified

Connection attempts failed

No relevant file transfer observed

Traffic matches expected browser behavior

No process correlation to suspicious destination

No communication after security control intervention

Positive evidence can disprove a suspected attack path.

Part 67 — Understand Capture Limitations

Your report should state limitations such as:

• capture may be incomplete

• packet loss may exist

• encryption hides content

• capture point limits visibility

• NAT can obscure host identity

• proxy services may change destination visibility

• DNS cache may mean no query appears

• QUIC/HTTP3 may differ from classic TCP analysis

• clock differences may exist

These are important professional caveats.

Part 68 — Reverify the PCAP

At completion:

sha256sum training-network.pcap

Compare:

Pre-Analysis Hash:

Post-Analysis Hash:

Match:

Integrity Status:

Expected:

Match:
Yes

Part 69 — Mission Challenge

Using the provided packet evidence, complete:

CASE INFORMATION

Case ID:

PCAP Evidence ID:

PCAP Filename:

SHA-256 Verified:

Capture Start:

Capture End:

Capture Point:


ENDPOINT

Hostname:

IP:

MAC:

Gateway:

DNS Server:


HOSTS

Internal Hosts:

External Hosts:

Primary External Destination:


DNS

Relevant Domain:

Query Time:

Query Type:

Response:

Resolved IP:

Repeated Queries:


NETWORK CONNECTION

Source:

Destination:

Source Port:

Destination Port:

Protocol:

Connection Start:

Connection End:

Status:


HTTP / TLS

HTTP Present:
Yes / No

TLS Present:
Yes / No

Host / SNI:

Request Path:
If visible

Response:

Certificate Details:
If relevant


FILE TRANSFER

Transfer Identified:
Yes / No

Filename:

Source:

Destination:

Network Hash:

Endpoint Hash:

Hash Match:


COMMUNICATION PATTERN

Destination:

First Seen:

Last Seen:

Connection Count:

Pattern:

Classification:


CORRELATION

Browser Evidence:

DNS Evidence:

Endpoint File Evidence:

Execution Evidence:

Memory Process Evidence:

Email Evidence:


TIMELINE

Event 01:

Event 02:

Event 03:

Event 04:

Event 05:


FINAL ANALYSIS

Most Important Domain:

Most Important IP:

Most Important Conversation:

Most Important Protocol:

Highest-Confidence Finding:

Strongest Cross-Evidence Correlation:

Largest Evidence Gap:

Unconfirmed Hypothesis:

Overall Conclusion:

Recommended Next Investigation:

Part 70 — What Not to Do

Do not:

Modify the original PCAP

Replay captured traffic

Browse to observed suspicious domains

Connect to captured external IPs

Submit recovered requests

Reuse session cookies

Use discovered credentials

Assume every external IP is malicious

Assume DNS means browser visit

Assume connection means compromise

Assume POST means credential theft

Assume TLS traffic contents without decryption evidence

Call repeated traffic C2 without corroboration

Ignore capture-point limitations

Ignore packet loss

Ignore timezone differences

Attribute infrastructure ownership without evidence

The rule is:

Observe → Reconstruct → Correlate → Qualify → Report

Part 71 — Troubleshooting

PCAP Does Not Open

Check:

• file integrity

• file format

• incomplete acquisition

• tool compatibility

Do not alter the evidence.

No DNS Traffic Exists

Possible reasons:

• DNS caching

• encrypted DNS

• capture began after resolution

• another DNS method

• incomplete capture

Do not assume no name resolution occurred.

No HTTP Traffic Exists

The communication may use HTTPS or another protocol.

Review TLS and TCP.

HTTPS Content Cannot Be Read

That is expected without appropriate decryption material.

Report metadata only.

File Download Appears in Browser but Not PCAP

Possible explanations:

• encrypted traffic

• capture gap

• proxying

• different interface

• capture started later

Document the limitation.

PCAP Shows External Connection but Browser Does Not

The traffic could originate from:

• another application

• system service

• background process

Correlate with memory and endpoint evidence.

Network and Endpoint Times Differ

Check:

• timezone

• clock skew

• event precision

• collection time

Document and normalize.

Evidence Requirements

Capture:

Evidence 01

PCAP integrity verification.

Evidence 02

Capture statistics.

Evidence 03

Capture-point context.

Evidence 04

Host Inventory.

Evidence 05

Conversation Register.

Evidence 06

Protocol Register.

Evidence 07

DNS Evidence Register.

Evidence 08

TCP Session Register.

Evidence 09

Relevant external connections.

Evidence 10

HTTP evidence where available.

Evidence 11

TLS evidence where available.

Evidence 12

File-transfer evidence where available.

Evidence 13

Exported-object hash.

Evidence 14

Endpoint hash comparison.

Evidence 15

Communication Pattern Register.

Evidence 16

Endpoint Network Profile.

Evidence 17

Memory/network correlation.

Evidence 18

Browser/network correlation.

Evidence 19

Network Timeline.

Evidence 20

Cross-Evidence Timeline.

Evidence 21

Network Evidence Correlation Matrix.

Evidence 22

Network Indicator Register.

Evidence 23

Hypothesis Register.

Evidence 24

Evidence lineage.

Evidence 25

Post-analysis integrity verification.

Mission Deliverables

Complete:

• PCAP integrity verified

• capture point documented

• capture duration recorded

• host inventory created

• investigated endpoint identified

• conversations analyzed

• protocol distribution documented

• DNS traffic examined

• relevant domains correlated

• TCP sessions analyzed

• important external destinations identified

• HTTP reviewed where visible

• TLS metadata reviewed

• encrypted-content limitations documented

• file transfer examined where available

• exported evidence hashed

• network/endpoint hashes compared

• repeated communication reviewed

• communication patterns classified cautiously

• endpoint network profile created

• memory evidence correlated

• browser/email evidence correlated

• timestamps normalized

• Network Timeline created

• Cross-Evidence Timeline created

• Network Evidence Correlation Matrix completed

• Network Indicator Register completed

• facts separated from hypotheses

• positive evidence documented

• capture limitations documented

• PCAP reverified

• final report completed

Lab Report Template

# Lab 08 — Network Forensics & Packet Investigation

## Executive Summary

## Mission Objective

## Case Information

## Evidence Information

## Integrity Verification

## Capture Context

## Capture Statistics

## Host Identification

## Network Conversations

## Protocol Analysis

## DNS Analysis

## TCP Session Analysis

## External Communication Analysis

## HTTP Analysis

## TLS Analysis

## File Transfer Analysis

## Communication Pattern Analysis

## Endpoint Correlation

## Memory Correlation

## Browser and Email Correlation

## Network Activity Timeline

## Cross-Evidence Timeline

## Indicator Register

## Network Evidence Correlation Matrix

## Investigation Hypotheses

## Positive Evidence

## Findings

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Host Inventory

## Appendix B — Conversation Register

## Appendix C — Indicators

## Appendix D — Hashes

## Appendix E — Evidence Lineage

Knowledge Check

Question 1 — What is a PCAP?

A packet-capture file containing captured network traffic.

Question 2 — Does a DNS request prove a user visited a website?

No.

It proves that name resolution was requested.

Question 3 — What does the TCP three-way handshake establish?

That a TCP connection was successfully established between endpoints.

Question 4 — Does port 443 always prove HTTPS?

No.

Port numbers strongly suggest common protocols but do not absolutely determine them.

Question 5 — Why is HTTPS harder to investigate at packet level?

Because application-layer content is generally encrypted.

Question 6 — Does a valid TLS certificate prove a destination is trustworthy?

No.

Malicious infrastructure can also use valid certificates.

Question 7 — What does a matching network-object and endpoint-file hash prove?

That the hashed file content is identical.

Question 8 — Does periodic network communication automatically prove command-and-control?

No.

Legitimate applications can also communicate periodically.

Question 9 — Why correlate packet evidence with memory?

Memory can sometimes associate the observed connection with a particular process.

Question 10 — What creates the strongest network-forensics conclusion?

Correlating packets with DNS, browser, endpoint, memory, filesystem, and log evidence.

Skills Achieved

After completing this lab, you should understand:

• PCAP evidence integrity

• capture-point context

• host identification

• IP and MAC evidence

• network conversations

• protocol distribution

• DNS forensics

• DNS record interpretation

• TCP session analysis

• external connection analysis

• HTTP metadata

• TLS metadata

• encrypted-traffic limitations

• file-transfer correlation

• object hashing

• communication-pattern analysis

• endpoint/network correlation

• process/network correlation

• browser/network correlation

• cross-evidence timelines

• network indicators

• hypothesis management

• evidence lineage

• professional network-forensics reporting

Professional Takeaway

Network forensics should not become:

“I found a strange IP, therefore the system was compromised.”

The professional model is:

Domain
   +
DNS Resolution
   +
Network Session
   +
Application Metadata
   +
Endpoint Evidence
   +
Process Evidence
   +
Timeline
   =
Defensible Communication Context

Always distinguish:

DNS Query
   ≠
Website Viewed

TCP Connection
   ≠
Compromise

TLS Session
   ≠
Application Content Known

Repeated Traffic
   ≠
Command-and-Control Proven

External IP
   ≠
Malicious Infrastructure Proven

The professional workflow is:

PCAP → Hosts → Conversations → Protocol → DNS → Session → Application Context → Endpoint Correlation → Timeline → Conclusion

The real investigative question is:

“Which communications are directly supported by packet evidence, what generated them, and how do they fit into the wider incident timeline?”

What’s Next?

➡️ Lab 09 — Incident Timeline Reconstruction & Evidence Correlation

In the next lab, you will combine the major evidence sources from the entire Digital Forensics track:

• disk artifacts

• deleted files

• Windows evidence

• Linux evidence

• memory

• browser activity

• email

• DNS

• network traffic

• authentication events

• file activity

• process activity

The methodology becomes:

Collect Events → Normalize Time → Source Attribution → Correlate → Sequence → Validate → Identify Gaps → Reconstruct Incident

You will move from analyzing individual artifacts to answering the larger forensic question:

“What happened first, what happened next, which evidence sources confirm each event, and what complete sequence can be defensibly reconstructed from the available evidence?”