Skip to content
CSY204 Week 07 Intermediate

Practice network forensics before moving to reading resources.

Security Operations

Track your progress through this week's content

Opening Framing

Every network communication leaves evidence. When malware beacons to its command and control server, those packets traverse network infrastructure. When attackers exfiltrate data, that data flows through switches, routers, and firewalls. When credentials are stolen over the network, the transaction is recorded. Network forensics captures and analyzes this traffic to reconstruct attack timelines and identify compromise.

Unlike disk or memory forensics where evidence is localized to a single system, network forensics provides a global view of attacker activity across the entire infrastructure. A single packet capture at a network chokepoint can reveal lateral movement between dozens of systems, data exfiltration volumes, and C2 communication patterns.

This week covers packet capture acquisition, PCAP analysis methodology, protocol analysis, session reconstruction, file extraction, and the tools that make network forensics efficient. You'll learn to investigate network traffic to find evidence that host-based forensics might miss.

Key insight: The network sees everything—if you're capturing it. Network visibility is a prerequisite for network forensics.

Building on Prior Knowledge

This week integrates concepts from across the curriculum:

  • CSY104: Networking fundamentals (TCP/IP, protocols) essential for understanding packet-level forensics
  • CSY201 Week 03: Network security monitoring foundations that support packet capture strategies
  • CSY204 Week 03: Incident detection techniques that benefit from network forensic evidence
  • CSY301 Week 06: Intelligence collection methods including network-based IOC gathering

1) Packet Capture Acquisition

Before analysis, network traffic must be captured. Various methods exist depending on network architecture and access:

Capture Methods:

┌─────────────────────────────────────────────────────────────┐
│ Method              │ Use Case           │ Considerations   │
├─────────────────────┼────────────────────┼──────────────────┤
│ SPAN/Mirror Port    │ Switch traffic     │ May drop packets │
│ Network TAP         │ Full duplex copy   │ Hardware cost    │
│ Inline Capture      │ IDS/IPS position   │ Latency impact   │
│ Host-based          │ Single endpoint    │ Limited scope    │
│ Cloud VPC Mirroring │ Cloud environments │ Vendor-specific  │
└─────────────────────────────────────────────────────────────┘

SPAN (Switched Port Analyzer):
- Configure switch to copy traffic to monitoring port
- May drop packets under load
- Typically monitors one VLAN

Network TAP:
- Hardware device that copies all traffic
- Full duplex - sees both directions
- No packet loss
- Passive - no network impact

Capture Locations:
- Perimeter (Internet edge)
- Core switches (internal traffic)
- Server segments (critical assets)
- User segments (endpoint activity)
- Cloud VPC (virtual networks)

Capture Tools:

tcpdump - Command Line Capture:

Basic capture to file:
$ tcpdump -i eth0 -w capture.pcap

Common options:
$ tcpdump -i eth0 -w capture.pcap -c 10000    # Limit packets
$ tcpdump -i eth0 -w capture.pcap -s 0        # Full packet (no truncation)
$ tcpdump -i any -w capture.pcap              # All interfaces
$ tcpdump -i eth0 -w capture.pcap -G 3600     # Rotate hourly
$ tcpdump -i eth0 -w capture_%Y%m%d%H%M.pcap -G 3600 -W 24  # 24 hours

Capture filters (BPF syntax):
$ tcpdump -i eth0 -w capture.pcap host 192.168.1.100
$ tcpdump -i eth0 -w capture.pcap port 80 or port 443
$ tcpdump -i eth0 -w capture.pcap net 10.0.0.0/8
$ tcpdump -i eth0 -w capture.pcap 'tcp[tcpflags] & tcp-syn != 0'

Wireshark/dumpcap:
$ dumpcap -i eth0 -w capture.pcap
$ dumpcap -i eth0 -w capture.pcap -b filesize:100000  # 100MB files
$ dumpcap -i eth0 -w capture.pcap -b duration:3600    # Hourly rotation

tshark (Command-line Wireshark):
$ tshark -i eth0 -w capture.pcap
$ tshark -i eth0 -w capture.pcap -f "port 80"         # Capture filter
$ tshark -r capture.pcap -Y "http"                     # Display filter

PCAP File Formats:

Capture File Formats:

PCAP (libpcap):
- Traditional format
- Widely supported
- Maximum packet size: 65535 bytes
- Extension: .pcap

PCAPNG (PCAP Next Generation):
- Modern format
- Supports multiple interfaces
- Includes capture metadata
- Comments and annotations
- Extension: .pcapng

Other Formats:
- .cap: Generic capture
- .erf: Endace format
- .snoop: Solaris snoop format

Converting formats:
$ editcap -F pcap input.pcapng output.pcap
$ tshark -r input.pcapng -w output.pcap -F pcap

File Management:
# Merge multiple captures
$ mergecap -w merged.pcap file1.pcap file2.pcap

# Split large captures
$ editcap -c 100000 large.pcap split.pcap    # 100K packets each

# Filter and extract
$ editcap -A "2024-03-15 09:00:00" -B "2024-03-15 10:00:00" \
    input.pcap timefiltered.pcap

Capture Best Practices:

Forensic Capture Guidelines:

Before Capture:
- Synchronize time (NTP) across capture points
- Document capture location and method
- Ensure sufficient storage
- Test capture setup before incident

During Capture:
- Capture full packets (-s 0)
- Use ring buffers for continuous capture
- Monitor for dropped packets
- Capture at multiple points if possible

After Capture:
- Calculate and record hash (SHA256)
- Maintain chain of custody
- Store original - work on copies
- Document any filtering applied

Storage Considerations:
- 1 Gbps saturated ≈ 450 GB/hour
- Compression helps (gzip captures)
- Consider capture filters for high-speed links
- Retain based on policy and storage capacity

Legal Considerations:
- Ensure authorization for capture
- Be aware of privacy regulations
- May capture credentials and sensitive data
- Follow organizational policies

Key insight: You can't analyze what you didn't capture. Proactive network monitoring ensures evidence exists when incidents occur.

2) Wireshark Analysis Fundamentals

Wireshark is the premier tool for packet analysis. Mastering its features enables efficient investigation of large captures:

Wireshark Interface:

┌─────────────────────────────────────────────────────────────┐
│ [Filter Bar]  ip.addr == 192.168.1.100                      │
├─────────────────────────────────────────────────────────────┤
│ Packet List Pane                                            │
│ No.  Time        Source          Dest            Protocol   │
│ 1    0.000000    192.168.1.100   10.0.0.50       TCP        │
│ 2    0.000123    10.0.0.50       192.168.1.100   TCP        │
├─────────────────────────────────────────────────────────────┤
│ Packet Details Pane                                         │
│ ▶ Frame                                                     │
│ ▶ Ethernet II                                               │
│ ▶ Internet Protocol Version 4                               │
│ ▼ Transmission Control Protocol                             │
│     Source Port: 49234                                      │
│     Destination Port: 443                                   │
├─────────────────────────────────────────────────────────────┤
│ Packet Bytes Pane (Hex + ASCII)                             │
│ 0000  00 1a 2b 3c 4d 5e 00 1f 2e 3d 4c 5b 08 00 45 00     │
└─────────────────────────────────────────────────────────────┘

Display Filters:

Wireshark Display Filter Syntax:

Basic Filters:
ip.addr == 192.168.1.100           # IP address (src or dst)
ip.src == 192.168.1.100            # Source IP only
ip.dst == 10.0.0.50                # Destination IP only
tcp.port == 80                      # TCP port (src or dst)
udp.port == 53                      # UDP port
eth.addr == 00:11:22:33:44:55      # MAC address

Protocol Filters:
http                                # HTTP traffic
dns                                 # DNS queries/responses
tcp                                 # All TCP
udp                                 # All UDP
icmp                                # ICMP (ping, etc.)
tls                                 # TLS/SSL traffic
smb                                 # SMB file sharing
ftp                                 # FTP control
ftp-data                            # FTP data transfer

Comparison Operators:
==    Equal
!=    Not equal
>     Greater than
<     Less than
>=    Greater than or equal
<=    Less than or equal
contains    String contains
matches     Regular expression

Logical Operators:
and, &&     Logical AND
or, ||      Logical OR
not, !      Logical NOT

Complex Filters:
ip.addr == 192.168.1.100 and tcp.port == 80
http and ip.src == 10.0.0.50
dns and dns.flags.response == 1
tcp.flags.syn == 1 and tcp.flags.ack == 0    # SYN only
http.request.method == "POST"
http contains "password"
frame contains "malware"

Following Streams:

Stream Reconstruction:

Right-click packet → Follow → TCP Stream
(Or Follow → HTTP Stream, TLS Stream, etc.)

Stream View Shows:
- Complete conversation
- Both directions (color-coded)
- Decoded content
- ASCII, Hex, Raw options

Use Cases:
- Read HTTP requests/responses
- See command and control traffic
- Extract transferred files
- View cleartext protocols

Filter by Stream:
tcp.stream eq 5                     # Show only stream #5
http.request and tcp.stream eq 5    # HTTP requests in stream 5

Export Stream:
- Follow stream → Save As
- Useful for extracting transferred data

Statistics and Analysis:

Wireshark Statistics Menu:

Capture File Properties:
- Packet count
- Time span
- Average packet rate
- File hash

Protocol Hierarchy:
Statistics → Protocol Hierarchy
- Shows protocol breakdown
- Percentage of traffic by protocol
- Quick overview of capture contents

Conversations:
Statistics → Conversations
- Lists all communication pairs
- Packet and byte counts
- Duration
- Sort by bytes to find large transfers

Endpoints:
Statistics → Endpoints
- All unique endpoints
- Traffic volume per endpoint
- Identify top talkers

I/O Graph:
Statistics → I/O Graph
- Traffic over time
- Spot anomalies and patterns
- Filter specific traffic types

DNS:
Statistics → DNS
- Query types
- Response codes
- Top queried domains

HTTP:
Statistics → HTTP → Requests
- URLs accessed
- Request methods
- Response codes

Key insight: Use statistics first to understand the capture, then dive into specific streams. Don't start by reading packets one by one.

3) Protocol Analysis

Understanding protocol behavior helps identify malicious traffic and reconstruct attacker actions:

HTTP Analysis:

Request Structure:
GET /download/malware.exe HTTP/1.1
Host: evil.com
User-Agent: Mozilla/5.0...
Cookie: session=abc123
[blank line]
[body for POST]

Response Structure:
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 102400
[blank line]
[file contents]

Suspicious Indicators:
- Requests to IP addresses (no hostname)
- Unusual User-Agent strings
- Base64 in URLs or headers
- POST to suspicious paths
- Large responses from unknown hosts
- Beaconing patterns (regular intervals)

Wireshark HTTP Filters:
http.request.method == "POST"
http.request.uri contains "cmd"
http.response.code == 200
http.content_type contains "executable"
http.user_agent contains "PowerShell"

Export HTTP Objects:
File → Export Objects → HTTP
- Lists all transferred files
- Save individual or all files
- Quick way to extract downloads

DNS Analysis:

DNS Forensics:

Normal DNS Query:
Client → DNS Server: "What is evil.com?"
DNS Server → Client: "evil.com is 10.0.0.50"

Query Types:
A       IPv4 address
AAAA    IPv6 address
MX      Mail server
TXT     Text record (often abused)
CNAME   Canonical name
NS      Name server

Suspicious DNS Indicators:
- Queries to non-corporate DNS servers
- High volume of NXDOMAIN responses
- TXT record queries (data exfiltration)
- Long subdomain names (tunneling)
- Queries for known malicious domains
- DNS over HTTPS (DoH) to external servers

DNS Tunneling Detection:
- Unusually long hostnames
- High query volume to single domain
- TXT record abuse
- Encoded data in subdomains

Example tunneling:
SGVsbG8gV29ybGQ.data.evil.com    ← Base64 in subdomain

Wireshark DNS Filters:
dns.qry.name contains "evil"
dns.flags.response == 0              # Queries only
dns.flags.response == 1              # Responses only
dns.flags.rcode != 0                 # Errors
dns.qry.type == 16                   # TXT queries
dns.resp.len > 100                   # Large responses

SMB Analysis:

SMB (Server Message Block):

Used For:
- File sharing
- Printer sharing
- Named pipes
- Lateral movement

SMB Versions:
SMB1: Legacy, vulnerable (EternalBlue)
SMB2: Windows Vista+
SMB3: Windows 8+, encryption support

Suspicious SMB Activity:
- SMB from unexpected sources
- Access to admin shares (C$, ADMIN$)
- PsExec patterns (PSEXESVC)
- Large file transfers
- Unusual file access patterns

PsExec Detection:
1. SMB connection to ADMIN$
2. Write PSEXESVC.EXE
3. Service creation via RPC
4. Command execution

Wireshark SMB Filters:
smb
smb2
smb.file contains "exe"
smb2.filename contains "PSEXESVC"
smb.path contains "ADMIN$"
smb.path contains "C$"

Export SMB Files:
File → Export Objects → SMB
- Extracts files transferred via SMB

TLS/Encrypted Traffic:

TLS Analysis (Without Decryption):

What You CAN See:
- Client Hello / Server Hello
- Certificate information
- Handshake metadata
- Traffic volume and timing
- SNI (Server Name Indication)

TLS Metadata Analysis:
ssl.handshake.type == 1             # Client Hello
ssl.handshake.type == 2             # Server Hello
ssl.handshake.type == 11            # Certificate
tls.handshake.extensions_server_name   # SNI hostname

JA3/JA3S Fingerprinting:
- Creates hash of TLS client/server parameters
- Identifies malware families
- Detects known-bad implementations

Certificate Analysis:
- Issuer and subject
- Validity period
- Self-signed detection
- Known malicious certificates

Decryption (If Keys Available):
- Pre-master secret log (browser)
- Private key (server)
Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log

Suspicious TLS Indicators:
- Self-signed certificates
- Recently issued certificates
- Certificates with IP addresses
- Unusual cipher suites
- Traffic to IP without valid SNI

Key insight: Even encrypted traffic reveals patterns. Timing, volume, certificate metadata, and SNI provide valuable intelligence without decryption.

4) Session Reconstruction and File Extraction

Reconstructing complete sessions and extracting transferred files provides crucial evidence:

Session Reconstruction:

TCP Stream Reconstruction:
- Wireshark: Follow → TCP Stream
- Reassembles all packets in conversation
- Shows complete data exchange

Challenges:
- Out-of-order packets
- Retransmissions
- Fragmented transfers
- Encrypted content

Manual Reconstruction:
1. Filter to specific conversation
2. Follow TCP stream
3. Export stream data
4. Analyze or carve files

Example Investigation:
tcp.stream eq 15 and http
→ Follow HTTP Stream
→ See complete request/response
→ Export transferred files

File Extraction Methods:

Wireshark Export Objects:

File → Export Objects → HTTP
- Lists all HTTP-transferred files
- Preview available
- Save individual or all

File → Export Objects → SMB
- Windows file sharing transfers

File → Export Objects → FTP-DATA
- FTP file transfers

File → Export Objects → TFTP
- TFTP transfers

File → Export Objects → IMF
- Email messages (Internet Message Format)

Limitations:
- Only works for supported protocols
- Chunked transfers may fail
- Partial captures miss data

NetworkMiner:

NetworkMiner - Network Forensic Analyzer:

Features:
- Automatic file extraction
- Image reconstruction
- Credential detection
- OS fingerprinting
- Session reconstruction
- Host profiling

Usage:
1. Open PCAP file
2. Automatic parsing
3. Browse extracted artifacts

Tabs:
- Hosts: All endpoints with details
- Files: Extracted files with hashes
- Images: Reconstructed images
- Credentials: Captured credentials
- Sessions: Communication sessions
- DNS: DNS queries and responses

Advantages over Wireshark:
- Automatic extraction
- Better file reconstruction
- Credential highlighting
- Case management

Use Together:
- NetworkMiner for extraction and overview
- Wireshark for deep packet analysis

Zeek (Bro) for Logging:

Zeek Network Analysis Framework:

Purpose:
- Generates structured logs from traffic
- Extracts files automatically
- Detects protocols
- Scriptable analysis

Processing PCAP:
$ zeek -r capture.pcap

Generated Logs:
conn.log      - All connections
http.log      - HTTP requests/responses
dns.log       - DNS queries
ssl.log       - TLS/SSL sessions
files.log     - Transferred files
smtp.log      - Email traffic
ftp.log       - FTP activity
notice.log    - Alerts and anomalies

conn.log Fields:
ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p,
proto, service, duration, orig_bytes, resp_bytes, ...

Example Queries:
# Large outbound transfers
$ awk -F'\t' '$10 > 1000000' conn.log

# HTTP to suspicious domains
$ grep "evil.com" http.log

# DNS TXT queries
$ awk -F'\t' '$12 == "TXT"' dns.log

File Extraction:
- Automatically extracts to extract_files/
- files.log maps files to connections
$ ls extract_files/
$ sha256sum extract_files/*

tshark for Scripted Analysis:

tshark - Command Line Wireshark:

Basic Reading:
$ tshark -r capture.pcap

Specific Fields:
$ tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e tcp.port

Filter and Extract:
$ tshark -r capture.pcap -Y "http.request" -T fields \
    -e ip.src -e http.host -e http.request.uri

Statistics:
$ tshark -r capture.pcap -z conv,tcp
$ tshark -r capture.pcap -z http,tree
$ tshark -r capture.pcap -z dns,tree

Export Specific Streams:
$ tshark -r capture.pcap -Y "tcp.stream eq 5" -w stream5.pcap

DNS Queries:
$ tshark -r capture.pcap -Y "dns.flags.response == 0" \
    -T fields -e dns.qry.name | sort | uniq -c | sort -rn

HTTP Requests:
$ tshark -r capture.pcap -Y "http.request" \
    -T fields -e ip.src -e http.host -e http.request.full_uri

Scripting Example:
#!/bin/bash
for pcap in *.pcap; do
    echo "Processing $pcap"
    tshark -r "$pcap" -Y "http.request.method == POST" \
        -T fields -e frame.time -e ip.src -e http.request.uri
done > post_requests.txt

Key insight: Use the right tool for the task. Wireshark for interactive analysis, tshark for scripting, NetworkMiner for extraction, Zeek for structured logging.

5) C2 and Exfiltration Detection

Identifying command and control traffic and data exfiltration is a primary goal of network forensics:

C2 Communication Patterns:

Beaconing:
- Regular intervals between connections
- Jitter (randomization) to avoid detection
- Small data transfers
- Check-in patterns

Indicators:
- Connections to same IP at regular intervals
- HTTP(S) to unusual ports
- DNS queries at consistent intervals
- Long-lived connections with periodic activity

Detecting Beacons:
1. Extract connection timestamps
2. Calculate intervals between connections
3. Look for consistent patterns
4. Account for jitter

Example Beacon Detection:
$ tshark -r capture.pcap -Y "ip.dst == 10.0.0.50" \
    -T fields -e frame.time_relative | \
    awk 'NR>1 {print $1-prev} {prev=$1}' | sort | uniq -c

Common C2 Channels:
- HTTP/HTTPS (blends with normal traffic)
- DNS (hard to block)
- ICMP (often overlooked)
- Custom protocols on high ports
- Cloud services (OneDrive, Dropbox, etc.)

Data Exfiltration Indicators:

Exfiltration Detection:

Volume Analysis:
- Unusually large outbound transfers
- Transfers during off-hours
- Transfers to cloud storage
- Gradual data movement

Protocol Abuse:
- DNS tunneling (data in queries)
- ICMP tunneling (data in ping)
- HTTP(S) POST with large bodies
- FTP/SFTP to unknown servers

Timing Analysis:
- Sustained high bandwidth
- Regular large transfers
- Activity outside business hours

Wireshark Analysis:
# Large outbound transfers
ip.src == 192.168.1.0/24 and frame.len > 1400

# POST requests with bodies
http.request.method == "POST" and http.content_length > 10000

Statistics → Conversations → Sort by Bytes
→ Identify top bandwidth consumers

Zeek Analysis:
# Large outbound connections
$ awk -F'\t' '$10 > 100000000' conn.log   # >100MB sent

# Connections to unusual ports
$ awk -F'\t' '$6 !~ /^(80|443|53|22)$/' conn.log

DNS Tunneling Detection:

DNS Tunneling Analysis:

Characteristics:
- Long subdomain strings
- High query volume
- TXT record abuse
- Encoded data patterns

Detection Queries:
# Long domain names
$ tshark -r capture.pcap -Y "dns.qry.name" \
    -T fields -e dns.qry.name | \
    awk 'length($0) > 50' | head

# Query frequency per domain
$ tshark -r capture.pcap -Y "dns.flags.response == 0" \
    -T fields -e dns.qry.name | \
    awk -F'.' '{print $(NF-1)"."$NF}' | \
    sort | uniq -c | sort -rn | head

# TXT queries (common for tunneling)
$ tshark -r capture.pcap -Y "dns.qry.type == 16"

Detection Heuristics:
- Entropy of subdomain (high = encoded)
- Query rate per domain
- Response size distribution
- Character frequency analysis

Tools:
- Zeek dns.log analysis
- PacketTotal online analysis
- RITA (Real Intelligence Threat Analytics)

Encrypted C2 Detection:

Detecting Malicious Encrypted Traffic:

Without Decryption:
1. JA3/JA3S fingerprinting
2. Certificate analysis
3. Traffic patterns
4. Destination reputation

JA3 Fingerprinting:
- Hash of TLS client hello parameters
- Identifies specific implementations
- Known malware JA3 hashes available

$ tshark -r capture.pcap -Y "tls.handshake.type == 1" \
    -T fields -e tls.handshake.ja3

Certificate Red Flags:
- Self-signed
- Recently issued (< 30 days)
- Let's Encrypt to suspicious domains
- IP address as subject
- Unusual validity periods

Pattern Analysis:
- Consistent packet sizes
- Regular timing intervals
- Traffic to known-bad IPs
- Connections to hosting providers

Threat Intelligence:
- Check IPs against threat feeds
- Verify domain reputation
- Search certificate fingerprints
- Cross-reference with indicators

Key insight: C2 traffic follows patterns because malware needs reliability. These patterns—timing, volume, protocol choices—enable detection even without payload visibility.

Real-World Context

Case Study: APT Network Forensics

During an investigation, network captures revealed the full scope of an APT compromise: Initial infection via spearphishing was confirmed through HTTP requests downloading a malicious document. C2 beaconing was identified—connections to a hardcoded IP every 5 minutes with 30-second jitter. Lateral movement appeared as SMB connections to ADMIN$ shares across internal servers. Data staging was visible as internal file copies to a single workstation. Exfiltration showed as HTTPS POST requests totaling 2.3GB to a cloud storage provider over 72 hours. Network forensics provided the complete attack timeline that host forensics alone couldn't reconstruct.

Case Study: DNS Tunneling Detection

Security analysts noticed unusual DNS traffic volume. Network forensic analysis revealed: A single internal host generating thousands of DNS queries to one domain. Subdomain names were unusually long and appeared base64-encoded. TXT record responses contained encoded commands. Traffic analysis showed consistent query-response patterns regardless of business hours. The malware was using DNS as a covert channel for C2, bypassing web proxies and firewalls that would have detected HTTP-based C2.

MITRE ATT&CK Alignment:

Network Forensics Detects:

Command and Control:
- T1071.001: Web Protocols → HTTP analysis
- T1071.004: DNS → DNS query analysis
- T1572: Protocol Tunneling → Tunnel detection
- T1573: Encrypted Channel → TLS analysis
- T1095: Non-Application Layer Protocol → ICMP, custom protocols

Exfiltration:
- T1041: Exfiltration Over C2 Channel → C2 traffic analysis
- T1048: Exfiltration Over Alternative Protocol → Protocol analysis
- T1567: Exfiltration to Cloud Storage → HTTPS to cloud providers

Lateral Movement:
- T1021.002: SMB/Windows Admin Shares → SMB analysis
- T1021.001: Remote Desktop Protocol → RDP traffic

Initial Access:
- T1566: Phishing → Email/download analysis
- T1190: Exploit Public-Facing Application → HTTP attack patterns

Discovery:
- T1046: Network Service Scanning → Port scan detection
- T1018: Remote System Discovery → Network enumeration patterns

Network forensics provides visibility into attacker activity across the entire infrastructure—something no single host can provide.

Guided Lab: PCAP Investigation

In this lab, you'll analyze a packet capture from a compromised network to identify the attack vector, C2 communications, and data exfiltration.

Lab Environment:

  • Wireshark installed
  • NetworkMiner (optional)
  • Practice PCAP (Malware Traffic Analysis exercises)
  • tshark for command-line analysis

Exercise Steps:

  1. Open the PCAP and review Protocol Hierarchy statistics
  2. Examine Conversations to identify top talkers
  3. Filter for HTTP traffic and identify suspicious requests
  4. Extract transferred files using Export Objects
  5. Analyze DNS queries for tunneling or C2 indicators
  6. Identify beaconing patterns in connection timing
  7. Document all indicators of compromise found

Reflection Questions:

  • What was the initial infection vector?
  • How did the malware communicate with C2?
  • Was any data exfiltrated? How much?

Week Outcome Check

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

  • Capture network traffic using tcpdump and Wireshark
  • Navigate Wireshark interface and use display filters
  • Analyze HTTP, DNS, SMB, and TLS traffic
  • Reconstruct TCP sessions and extract files
  • Identify C2 beaconing patterns
  • Detect data exfiltration indicators
  • Recognize DNS tunneling characteristics
  • Use tshark for scripted analysis

🎯 Hands-On Labs (Free & Essential)

Practice network forensics before moving to reading resources.

🎮 TryHackMe: Wireshark

What you'll do: Use display filters, follow streams, and extract artifacts.
Why it matters: Wireshark is the primary tool for PCAP analysis.
Time estimate: 1.5-2 hours

Start TryHackMe Wireshark →

🎮 TryHackMe: PCAP Analysis

What you'll do: Investigate packet captures and identify attack patterns.
Why it matters: PCAP analysis uncovers initial access and C2 evidence.
Time estimate: 2-3 hours

Start TryHackMe PCAP Analysis →

📝 Lab Exercise: Beaconing Detection

Task: Identify periodic beaconing in a PCAP and document intervals.
Deliverable: Table of suspected C2 domains/IPs and timing patterns.
Why it matters: Beaconing is a reliable indicator of C2 activity.
Time estimate: 60-90 minutes

🛡️ Lab: Cloud Forensics (AWS)

What you'll do: Analyze CloudTrail logs for suspicious access patterns.
Deliverable: Timeline of suspicious API calls + remediation notes.
Why it matters: Cloud investigations rely on audit logs, not disk images.
Time estimate: 90-120 minutes

💡 Lab Tip: Use Statistics → Conversations to quickly spot suspicious endpoints.

🛡️ Cloud Forensics Basics

Cloud forensics focuses on logs and identity actions rather than physical disks. Audit trails are your primary evidence.

Key evidence sources:
- CloudTrail or Azure Activity Logs
- IAM policy changes and role assumptions
- Storage access logs (S3, Blob)
- VPC flow logs for network context

📚 Building on CSY302: Cloud logging and IAM fundamentals.

Resources

Lab

Complete the following lab exercises to practice network forensics. Use practice PCAPs from Malware Traffic Analysis or similar sources.

Part 1: PCAP Overview Analysis (LO5)

Open a practice PCAP and generate an overview: (a) total packets and time span, (b) protocol hierarchy breakdown, (c) top 10 conversations by bytes, (d) unique endpoints. Identify any initial anomalies.

Deliverable: PCAP summary report with statistics and initial observations about suspicious traffic.

Part 2: HTTP Traffic Analysis (LO5)

Filter for HTTP traffic and analyze: (a) all HTTP requests with hosts and URIs, (b) suspicious User-Agent strings, (c) POST requests and their content, (d) file downloads. Extract any transferred files.

Deliverable: HTTP analysis report with extracted files and their hashes, suspicious requests highlighted.

Part 3: DNS Investigation (LO5)

Analyze DNS traffic for: (a) all unique domains queried, (b) queries to non-standard DNS servers, (c) unusually long domain names, (d) TXT record queries. Assess for tunneling.

Deliverable: DNS analysis with domain frequency table and assessment of any tunneling indicators.

Part 4: C2 Detection (LO5)

Identify command and control traffic by: (a) finding beaconing patterns (regular connection intervals), (b) analyzing connections to external IPs, (c) examining TLS certificate information, (d) correlating with known threat intelligence.

Deliverable: C2 analysis report with beacon timing analysis, external IP reputation, and confidence assessment.

Part 5: Attack Timeline (LO5, LO7)

Using all previous analysis, construct a complete network-based attack timeline: (a) initial compromise/download, (b) C2 establishment, (c) any lateral movement, (d) data staging and exfiltration. Correlate with timestamps.

Deliverable: Chronological attack narrative with supporting packet evidence and IOC list.

Week 07 Quiz

Test your understanding of Network Forensics, PCAP analysis, and Wireshark.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Checkpoint Questions

  1. What is the difference between a capture filter and a display filter in Wireshark? When would you use each?
  2. Describe three indicators in network traffic that might suggest C2 beaconing activity.
  3. How would you detect DNS tunneling in a packet capture? What specific characteristics would you look for?
  4. Why is TLS traffic still valuable for forensics even without decryption? What can be analyzed?
  5. Explain how you would use Wireshark to extract a file that was downloaded via HTTP during an incident.
  6. What are the advantages of using Zeek to process packet captures compared to manual Wireshark analysis?

Weekly Reflection

Network forensics provides a unique vantage point—seeing attacker activity across the entire infrastructure rather than on individual hosts. This week demonstrated how packet analysis reveals attack patterns invisible to endpoint forensics alone.

Reflect on the following in 200-300 words:

A strong reflection addresses the practical challenges of network monitoring, the impact of encryption, and how network evidence complements other forensic sources in investigations.

Verified Resources & Videos

← Previous: Week 06 Next: Week 08 →