Intro to Network Traffic Analysis

Por

In today’s interconnected world, network traffic is constantly flowing between systems, applications, and users. Every packet that traverses a network contains valuable information — some of it benign, some of it sensitive, and sometimes even malicious. This is where network traffic analysis (NTA) comes into play.

Whether you are on the defensive side (monitoring for threats and anomalies) or the offensive side (searching for weaknesses to exploit), analyzing traffic “on the wire” can uncover insights that are critical for understanding security posture, operational health, and potential vulnerabilities.

What Is Network Traffic Analysis?

At its core, network traffic analysis involves collecting, inspecting, and interpreting network data to understand what is happening in real time or retrospectively. This data could come from packet captures (PCAP files), flow logs, intrusion detection systems, or specialized monitoring tools.

Key goals of NTA include:

  • Monitoring activity: Spotting normal vs. abnormal traffic patterns.
  • Detecting anomalies: Identifying signs of compromise, unusual protocols, or suspicious communication flows.
  • Improving operations: Troubleshooting network bottlenecks or application performance issues.

Defensive Use Cases

Security teams leverage network traffic analysis as a core component of threat detection and incident response. Some examples include:

  • Identifying intrusions: Spotting command-and-control (C2) traffic or exfiltration attempts.
  • Anomaly detection: Detecting deviations in bandwidth usage, port scanning behavior, or unexpected geolocations.
  • Policy enforcement: Ensuring only approved applications and services communicate across sensitive network segments.
  • Incident response: Analyzing PCAP files to reconstruct attacker actions after a breach.

Think of it as the CCTV system of a network — providing visibility that firewalls and endpoint logs alone might miss.

Offensive Use Cases

On the flip side, penetration testers and adversaries can also leverage NTA to gain an advantage. Examples include:

  • Credential harvesting: Capturing cleartext usernames and passwords in unencrypted protocols (e.g., FTP, Telnet, HTTP Basic Auth).
  • Discovering hidden services: Identifying applications or servers that aren’t publicly documented.
  • Mapping networks: Analyzing which hosts, subnets, or segments are reachable.
  • Gathering intelligence: Spotting sensitive data like API keys, session tokens, or database queries transmitted in insecure ways.

For offensive practitioners, network traffic can serve as a treasure map, revealing paths to escalate privileges or pivot deeper into an environment.

Tools Commonly Used in NTA

Both defenders and attackers rely on a similar set of tools for network traffic analysis, including:

  • Wireshark – The go-to GUI tool for packet inspection.
  • tcpdump – Lightweight command-line tool for quick captures.
  • Zeek (formerly Bro) – A powerful framework for traffic analysis and anomaly detection.
  • Suricata / Snort – Intrusion detection and prevention systems with traffic analysis capabilities.
  • Network TAPs and SPAN ports – For visibility at strategic points in the network.

Challenges and Limitations

While powerful, network traffic analysis also comes with its hurdles:

  • Encryption – With TLS 1.3 and widespread use of HTTPS, much of the traffic is no longer visible in plaintext.
  • Volume – Large enterprise networks generate enormous amounts of data, making storage and real-time analysis difficult.
  • False positives – Anomaly-based detection can overwhelm analysts with noise.
  • Evasion techniques – Attackers may use tunneling, obfuscation, or custom protocols to hide malicious activity.

Key Takeaways

  • For defenders: Network traffic analysis is indispensable for detecting intrusions, anomalies, and compliance violations.
  • For attackers: It provides an opportunity to uncover sensitive data, hidden services, and potential attack vectors.
  • Tools like Wireshark, tcpdump, and Zeek are foundational for both sides of the equation.
  • Encryption and data volume are major challenges, requiring smarter monitoring and detection strategies.

In the end, network traffic analysis is a double-edged sword. It can empower defenders to catch attackers in action, but it can also equip attackers with the intelligence needed to infiltrate deeper into a system. The deciding factor is who can leverage the data more effectively — the blue team or the red team.

Networking Primer – Layers 1-4

Understanding how networks move data is essential for effective traffic capture and analysis. This section is a compact refresher that connects networking theory (models) to what you actually see on the wire (PDUs, ports, protocols). If some of these ideas are new to you, consider completing an introductory networking module first — the concepts below will make packet captures and protocol dissection far easier to reason about.

Why this matters for traffic analysis

When you open a packet capture (PCAP) in Wireshark or tcpdump, you’re looking at the concrete result of several layered processes working together. If you don’t know which layer handles addressing vs. reliability vs. presentation, you’ll struggle to:

  • Identify where a problem lives (physical link vs. routing vs. application),
  • Interpret what a PDU actually represents (frame, packet, segment, datagram),
  • Choose the right filters (by port, protocol, IP, MAC) and investigation steps,
  • Recognize suspicious patterns (e.g., odd protocols on unusual ports).

So—models first, then PDUs and real-world signposts.

OSI vs TCP/IP: the high-level comparison

Quick summary

  • OSI model: 7 layers — Application, Presentation, Session, Transport, Network, Data Link, Physical.
    • More granular, conceptual — useful for teaching and precise decomposition.
  • TCP/IP model: 4 layers — Application, Transport, Internet, Link.
    • Practical and protocol-oriented — maps closely to how the Internet actually operates.

Core differences at a glance

TraitOSITCP/IP
Layers74
FlexibilityStrict, well-defined rolesLooser, protocol-driven
FocusTheoretical separation of concernsPractical implementation of common protocols

Think of OSI as the blueprint (clear separation of responsibilities) and TCP/IP as the working architecture used in real networks. In practice you’ll usually reason with TCP/IP concepts but reference OSI when you need finer-grained layer reasoning.

How the layers map to each other (practical view)

A common way to map the models:

  • OSI Layers 7 / 6 / 5 (Application / Presentation / Session) → TCP/IP Application layer
    These layers are concerned with what the user sees and how data is formatted, encoded, or session-managed (e.g., HTTP, TLS, SSH).
  • OSI Layer 4 (Transport) → TCP/IP Transport layer
    Handles end-to-end communication and reliability (e.g., TCP segments, UDP datagrams; ports, sequence numbers).
  • OSI Layer 3 (Network) → TCP/IP Internet layer
    Responsible for packet routing and logical addressing (e.g., IP addresses, ICMP).
  • OSI Layer 2 / 1 (Data Link / Physical) → TCP/IP Link layer
    Deals with frames, MAC addresses, and the actual electrical/optical/radio transmission medium.

Protocol Data Unit (PDU): what you actually see on the wire

A PDU is the packaged unit exchanged between two networked entities at a given layer — containing control information (headers/footers) and the payload (data from above).

Common PDUs by layer (practical names you’ll see in captures):

  • Physical (OSI L1) — raw bits on the medium (not visible as a single structure in captures).
  • Data Link (OSI L2) — Frame
    • Example: Ethernet frame with source/destination MAC, EtherType, and payload.
  • Network (OSI L3) — Packet
    • Example: IPv4/IPv6 packet containing source/dest IP and encapsulated transport PDU.
  • Transport (OSI L4) — Segment / Datagram
    • Example: TCP segment (with sequence numbers, flags), or UDP datagram (simple header + payload).
  • Application (OSI L5–7 / TCP-IP App) — Data
    • Example: HTTP messages, DNS queries, SMTP payloads, TLS records.

When you open a packet capture tool, you typically see an Ethernet frame that contains an IP packet, which contains a TCP segment, which contains HTTP. Each layer adds and strips headers as PDUs are passed down/up the stack.

Practical mapping example (what you’ll see in Wireshark)

Capture packet → expand layers:

  1. Frame (Ethernet)
    • Frame 123: 74 bytes on wire, 74 bytes captured
    • Contains source MAC, dest MAC, EtherType.
  2. Internet (IPv4)
    • Src: 10.0.0.5 → Dst: 10.0.0.10
    • TTL, protocol (e.g., TCP), header checksum.
  3. Transport (TCP)
    • Src port: 443 → Dst port: 54321
    • Sequence/ack numbers, flags (SYN/ACK), window size.
  4. Application (TLS / HTTP)
    • If TLS: you’ll see TLS record layers; encrypted HTTP payload.
    • If plain HTTP: request lines, headers, body visible in plaintext.

Why PDUs matter for investigations

  • Filtering: Want HTTP traffic? Filter TCP port 80 or protocol http. Want ARP? Filter by arp. Understanding which PDU carries what info lets you build precise filters and avoid noise.
  • Attribution: MAC addresses (L2) help pinpoint local devices; IPs (L3) help map logical topology.
  • Correlation: Match TCP sequence/ack numbers, retransmissions, or time deltas to diagnose performance or detect injection attempts.
  • Decoding: Recognize whether the application data is encrypted (TLS) or plain — this determines what information you can actually recover from a capture.

Common protocols and their typical layers

  • Application layer (OSI 7 / TCP-IP Application): HTTP, HTTPS (HTTP over TLS), DNS, SMTP, SSH, FTP.
  • Transport layer (OSI 4 / TCP-IP Transport): TCP (reliable), UDP (unreliable), SCTP.
  • Internet/Network layer (OSI 3 / TCP-IP Internet): IPv4, IPv6, ICMP.
  • Link layer (OSI 2 / TCP-IP Link): Ethernet, ARP, VLAN tagging, Wi-Fi (802.11 frames).

Knowing where a protocol sits tells you whether you should be inspecting ports (transport) or fields like TTL and fragmentation (network).

Short practical checklist before analyzing traffic

  1. Know your capture point — Are you on a SPAN/TAP? Inside a VLAN? Wireless monitor mode? This determines which traffic you will see.
  2. Identify link-layer type — Ethernet vs 802.11 changes how you read MACs and QoS fields.
  3. Look for broadcast/ARP — Great first steps for mapping hosts on a local network.
  4. Find repeated ports/protocols — Frequent DNS/TLS/HTTP flows indicate where to focus.
  5. Check for encryption — If traffic is TLS 1.3 or strong HTTPS, application payloads will be opaque; focus on metadata (SNI, IP, certs).
  6. Use PDUs to guide filters — Apply eth, ip, tcp, udp, http, dns filters to narrow down investigations.

Key takeaways

  • Models help reasoning: OSI is a conceptual breakdown; TCP/IP is the practical model you’ll use for packet analysis. Use both when troubleshooting.
  • PDU awareness is essential: Knowing whether you’re looking at frames, packets, or segments tells you what information is available and where to look for it.
  • Layer mapping guides filters and diagnosis: Pick the right layer to inspect based on the symptom (e.g., performance issues → transport, routing issues → network).
  • Encryption and capture point determine visibility: If traffic is encrypted or you’re not on the right segment, you may only be able to analyze metadata, not payloads.
  • Practice with captures: Theoretical knowledge becomes useful when applied to real PCAPs — start with small captures and expand your scope.

How many layers does the OSI model have?

Sure. The OSI model has 7 layers because it was designed as a conceptual framework that breaks network communication into small, distinct steps, each layer having a specific responsibility.
You can think of it like a package being prepared, shipped, transported, received, opened, and shown to someone — each step handled by a different “department.”

Here are the 7 layers from bottom to top:

LayerNamePurpose (In Simple Words)
7ApplicationWhere users and software interact (browsers, apps, etc.)
6PresentationFormats and encrypts data so apps understand it
5SessionStarts/maintains/ends communication sessions
4TransportBreaks data into segments and ensures delivery (TCP/UDP)
3NetworkHandles IP addressing and routing (decides the path)
2Data LinkUses MAC addresses for communication on the same network
1PhysicalElectrical signals, cables, wifi — the actual hardware layer

[REDACTED]

How many layers are there in the TCP/IP model?

The TCP/IP model has 4 layers.

Here they are in order:

LayerNameWhat it Does
4ApplicationWhere applications use protocols like HTTP, DNS, SSH
3TransportControls how data is sent (TCP / UDP)
2InternetHandles IP addressing and routing (IP)
1Link (Network Access)Deals with physical hardware, MAC addresses, and frames

[REDACTED]

True or False: Routers operate at layer 2 of the OSI model?

Routers operate at Layer 3 (Network layer) of the OSI model, because they make forwarding decisions based on IP addresses, not MAC addresses.

[REDACTED]

What addressing mechanism is used at the Link Layer of the TCP/IP model?

The addressing mechanism used at the Link Layer of the TCP/IP model is the MAC address.

[REDACTED]

At what layer of the OSI model is a PDU encapsulated into a packet? ( the number )

A PDU becomes a packet at Layer 3 of the OSI model.

[REDACTED]

What addressing mechanism utilizes a 32-bit address?

The addressing mechanism that uses a 32-bit address is IPv4.

[REDACTED]

What Transport layer protocol is connection oriented?

The connection-oriented Transport layer protocol is TCP (Transmission Control Protocol).

[REDACTED]

What Transport Layer protocol is considered unreliable?

The Transport Layer protocol considered unreliable is UDP (User Datagram Protocol).

[REDACTED]

TCP’s three-way handshake consists of 3 packets: 1.Syn, 2.Syn & ACK, 3. _? What is the final packet of the handshake?

The final packet in the TCP three-way handshake is ACK.

[REDACTED]

Networking Primer – Layers 5-7

So far, we’ve examined the lower-level functions of networking — the foundational layers that govern how data physically travels across wires, fibers, and airwaves. But networking isn’t just about bits and frames; it’s also about the applications and services that sit at the top of the stack. These upper-layer protocols are what make the internet and enterprise networks actually usable for humans and software.

In this section, we’ll explore some of the most essential upper-layer protocols. While there are countless application-level services in existence, we’ll focus on a few critical ones that you’ll encounter frequently during traffic analysis, penetration testing, and everyday IT operations.

Why Upper-Layer Protocols Matter

Think of the OSI or TCP/IP stack as a pyramid:

  • The lower layers (Physical, Data Link, Network, Transport) provide the infrastructure for data delivery.
  • The upper layers (Application and beyond) ensure that data is formatted, interpreted, and useful.

Without upper-layer protocols, the lower layers would just deliver streams of meaningless bits. These protocols give structure and context, enabling tasks like sending emails, resolving domain names, or loading websites.

For both defenders and attackers, understanding these protocols is critical:

  • Defenders need to analyze logs and captures for anomalies in application behavior.
  • Attackers often target weaknesses in these protocols to extract sensitive data, escalate privileges, or pivot within a network.

Key Upper-Layer Protocols You Need to Know

Here are some of the most common and vital protocols that operate at the Application Layer of the TCP/IP model (or Layers 5–7 in OSI):

1. HTTP / HTTPS (Hypertext Transfer Protocol / Secure)

  • Purpose: Foundation of the web. Used for communication between browsers, apps, and web servers.
  • HTTP is plaintext (insecure); HTTPS wraps HTTP in TLS for encryption and integrity.
  • Security implications: Credentials, cookies, and API tokens are exposed in plaintext over HTTP. Attackers also exploit misconfigured HTTPS or downgrade attacks.

2. DNS (Domain Name System)

  • Purpose: Translates human-friendly domain names (like example.com) into IP addresses computers can understand.
  • Typical behavior: UDP port 53 (though can use TCP for larger queries).
  • Security implications: Attackers can hijack DNS (poisoning, tunneling) to exfiltrate data or redirect traffic to malicious hosts. Defenders monitor DNS for unusual lookups.

3. SMTP, IMAP, POP3 (Email Protocols)

  • SMTP: Used to send emails from clients to servers or between mail servers.
  • IMAP/POP3: Used by clients to retrieve emails.
  • Security implications: Misconfigured email servers are prime targets for spam relaying or credential theft. Many breaches involve phishing campaigns delivered via email.

4. FTP / SFTP (File Transfer Protocols)

  • FTP: An older, plaintext protocol for transferring files between hosts.
  • SFTP/FTPS: Secure alternatives that encrypt authentication and transfer.
  • Security implications: FTP leaks credentials in plaintext, making it a goldmine during packet captures. Many attackers sniff FTP traffic for username/password combinations.

5. SSH (Secure Shell)

  • Purpose: Provides secure, encrypted remote administration of servers and devices.
  • Security implications: Brute-force attempts are common. If private keys are leaked, attackers can gain persistent access. Encrypted sessions make analysis harder, but metadata still reveals login attempts.

6. RDP (Remote Desktop Protocol)

  • Purpose: Allows graphical remote desktop access to Windows systems.
  • Security implications: Often targeted in brute-force or credential-stuffing attacks. Misconfigurations can allow lateral movement across enterprise environments.

Putting It All Together

While lower-level networking handles how data travels, these upper-layer protocols govern what that data represents and why it’s being sent. A simple web request, for example, involves multiple layers:

  • DNS resolves the domain.
  • TCP establishes the connection.
  • TLS encrypts it (if HTTPS).
  • HTTP transmits the actual request/response data.

For security professionals, knowing how these pieces fit together makes it possible to spot anomalies, detect attacks, and assess risks. For attackers, the same knowledge reveals weak points — like plaintext credentials in FTP or exploitable misconfigurations in email servers.

Key Takeaways

  • Upper-layer protocols enable human-facing services like web browsing, email, and remote access.
  • Common protocols to know: HTTP/HTTPS, DNS, SMTP/IMAP/POP3, FTP/SFTP, SSH, RDP.
  • Each carries unique risks: plaintext transmission, misconfigurations, or brute-force susceptibility.
  • Security professionals must understand both layers: Lower levels (transport/delivery) and upper layers (applications/services).

What is the default operational mode method used by FTP?

The default FTP mode is Active Mode, where the server initiates the data connection back to the client.
This can cause issues if the client is behind a firewall or NAT.

[REDACTED]

 FTP utilizes what two ports for command and data transfer? (separate the two numbers with a space)

FTP uses port 21 for sending commands and managing the session, and port 20 for transferring data.

[REDACTED]

Does SMB utilize TCP or UDP as its transport layer protocol?

SMB primarily uses TCP as its transport layer protocol (most commonly on port 445).

[REDACTED]

SMB has moved to using what TCP port?

SMB now primarily uses TCP port 445.

[REDACTED]

Hypertext Transfer Protocol uses what well known TCP port number?

HTTP uses TCP port 80.

[REDACTED]

What HTTP method is used to request information and content from the webserver?

The HTTP method used to request information from a web server is GET.

[REDACTED]

What web based protocol uses TLS as a security measure?

The protocol that uses TLS for security is HTTPS.

[REDACTED]

True or False: when utilizing HTTPS, all data sent across the session will appear as TLS Application data?

When using HTTPS, the data sent is encrypted and appears as TLS Application Data in packet captures.

[REDACTED]

Tcpdump Fundamentals

Tcpdump is the classic command-line packet sniffer used by network engineers, security analysts, and penetration testers to capture and inspect network traffic without a GUI. It’s fast, available on most Unix-like systems, and—when you learn a few core commands—extraordinarily effective for everyday troubleshooting and investigations.

What tcpdump does (in plain terms)

  • Captures packets from a network interface or reads them from a capture file (PCAP).
  • Decodes common protocols (Ethernet, IP, TCP, UDP, ICMP, DNS, HTTP headers, etc.) so you can see what’s happening “on the wire.”
  • Filters traffic at the capture time (so you save only what matters), using a flexible BPF (Berkeley Packet Filter) syntax.
  • Writes and reads PCAP files compatible with Wireshark and other analysis tools.

Because it’s terminal-based, tcpdump is perfect for remote work over SSH, automated scripts, and fast triage when you don’t have or don’t want a GUI.

Under the hood: libpcap and promiscuous mode

  • tcpdump relies on libpcap / pcap libraries to grab packets from the network stack.
  • To see traffic not specifically destined for the host, tcpdump can put an interface in promiscuous mode, allowing the NIC to accept and capture all frames it observes on the LAN segment.
  • Because of the low-level hardware access, root (administrator) privileges are required to run captures. That’s why you’ll typically run tcpdump with sudo.

Platform availability and Windows note

  • Tcpdump ships on most Unix-like systems: Linux distributions, *BSD, Solaris, AIX, etc.
  • WinDump was the Windows port, but it’s no longer maintained. If you need tcpdump on Windows, a practical option is to run a Linux distro inside Windows Subsystem for Linux (WSL) or a VM (Parrot, Ubuntu) and use tcpdump there.

Common, practical tcpdump commands (cheat sheet)

Run these with sudo or as root when capturing live interfaces.

  • Capture on interface eth0, show packets live:
sudo tcpdump -i eth0
  • Capture only first N bytes of each packet (useful to limit output):
sudo tcpdump -s 96 -i eth0
  • Save capture to a file (PCAP) for later analysis in Wireshark:
sudo tcpdump -i eth0 -w capture.pcap
  • Read and print a saved capture:
tcpdump -r capture.pcap
  • Capture only traffic to/from a specific host:
sudo tcpdump -i eth0 host 10.0.0.5
  • Capture only TCP traffic on port 80 (HTTP):
sudo tcpdump -i eth0 tcp port 80
  • Capture UDP DNS traffic:
sudo tcpdump -i eth0 udp port 53
  • Combine filters (host and port) with logical operators:
sudo tcpdump -i eth0 'host 10.0.0.5 and tcp port 443'
  • Capture only packets with a particular source MAC (link layer filter):
sudo tcpdump -i eth0 ether src 00:11:22:33:44:55
  • Print timestamps with microsecond precision and verbose packet decoding:
sudo tcpdump -tttt -vv -i eth0

Filtering tips — capture less, analyze more

  • Use BPF filters to reduce capture size—capture only what’s relevant (host, port, proto) rather than saving everything.
  • When investigating credentials or suspicious traffic, start with port filters for common services (21, 22, 80, 443, 139/445, 53, 3389) and expand as needed.
  • Use -c <count> to automatically stop after N packets (handy for quick checks):
    sudo tcpdump -i eth0 -c 200 tcp port 80

Promiscuous mode and capture visibility

  • Promiscuous mode lets a NIC accept all frames, not just those to its MAC. On a switched network, you’ll still only see traffic for your host unless you capture on a mirror/SPAN port or a TAP.
  • If you’re on Wi-Fi, capturing often requires monitor mode (different from promiscuous) and may need special drivers or tools.

When to use tcpdump vs Wireshark

  • tcpdump: quick remote captures, scripting, lightweight harvesting, saving PCAPs on servers, environments where GUI isn’t available.
  • Wireshark: deep protocol decoding, easy packet inspection, graphical timeline and follow-stream features.
  • Common workflow: use tcpdump on the host to capture a focused PCAP, copy the file to your workstation and analyze in Wireshark.

Security & operational considerations

  • Capturing traffic can produce large files—monitor disk usage and rotate or limit capture sizes.
  • Packet captures may contain sensitive data (passwords, tokens). Treat PCAPs as sensitive artifacts and protect them.
  • Only run tcpdump and collect traffic when you have authorization—capturing network traffic can breach privacy or policy.

Quick troubleshooting hints

  • If tcpdump reports “No such device”: check ip a / ifconfig for available interfaces.
  • If output is empty: verify you’re using the correct interface, check SPAN/TAP configuration, and confirm your capture point can see target traffic.
  • If you can’t run tcpdump: use WSL or a small Linux VM on Windows for access to tcpdump and libpcap tools.

Example short workflow (remote triage)

  1. SSH into the remote host.
  2. Identify interfaces: ip link or ip a.
  3. Capture a small sample to file:
    sudo tcpdump -i eth0 -c 100 -w /tmp/sample.pcap host 10.0.0.5 and tcp port 443
  4. Copy the PCAP locally with scp and open in Wireshark for deeper analysis.

Key takeaways

  • tcpdump is the go-to CLI sniffer for Unix-like systems—perfect for remote and scripted captures.
  • It uses libpcap and promiscuous mode to capture packets “on the wire,” but you still need the right capture point to see all traffic.
  • Root privileges are required; use sudo responsibly.
  • Prefer targeted BPF filters to minimize capture size and speed up analysis.
  • For Windows, use WSL or a Linux VM as a practical alternative to the obsolete WinDump.

 Utilizing the output shown in question-1.png, who is the server in this communication? (IP Address)

Just download the file, unzip and open the image.

$ tcpdump -nnr HTTP.cap
reading from file HTTP.cap, link-type EN10MB (Ethernet), snapshot length 65535
15:41:15.326821 IP 192.168.1.140.57876 > [REDACETD]: Flags [S], seq 2367813953, win 5840, options [mss 1460,sackOK,TS val 2216538 ecr 0,nop,wscale 7], length 0
15:41:15.332177 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 1, win 46, options [nop,nop,TS val 2216540 ecr 835172936], length 0
15:41:15.333877 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [S.], seq 1803456484, ack 2367813954, win 5792, options [mss 1460,sackOK,TS val 835172936 ecr 2216540,nop,wscale 6], length 0
15:41:15.349326 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 1, win 46, options [nop,nop,TS val 2216554 ecr 835172936], length 0
15:41:15.363503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [P.], seq 1:401, ack 1, win 46, options [nop,nop,TS val 2216569 ecr 835172936], length 400: HTTP: GET /images/layout/logo.png HTTP/1.1
15:41:15.363503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [.], ack 401, win 495, options [nop,nop,TS val 835172952 ecr 2216569], length 0
15:41:15.365503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 1:1448, ack 401, win 495, options [nop,nop,TS val 835172953 ecr 2216569], length 1447: HTTP/1.1 200 OK
15:41:15.366503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 1448, win 46, options [nop,nop,TS val 2216571 ecr 835172953], length 0
15:41:15.368503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 1448, win 46, options [nop,nop,TS val 2216573 ecr 835172953], length 0
15:41:15.373503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [P.], seq 401:801, ack 1448, win 46, options [nop,nop,TS val 2216578 ecr 835172953], length 400: HTTP
15:41:15.374503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [.], ack 801, win 495, options [nop,nop,TS val 835172955 ecr 2216578], length 0
15:41:15.376503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 1448, win 46, options [nop,nop,TS val 2216580 ecr 835172953], length 0
15:41:15.379503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 1448:2895, ack 801, win 495, options [nop,nop,TS val 835172957 ecr 2216580], length 1447: HTTP
15:41:15.380503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 2895, win 46, options [nop,nop,TS val 2216581 ecr 835172957], length 0
15:41:15.383503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 2895:4342, ack 801, win 495, options [nop,nop,TS val 835172958 ecr 2216581], length 1447: HTTP
15:41:15.384503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 4342, win 46, options [nop,nop,TS val 2216582 ecr 835172958], length 0
15:41:15.387503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 4342:5789, ack 801, win 495, options [nop,nop,TS val 835172959 ecr 2216582], length 1447: HTTP
15:41:15.388503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 5789, win 46, options [nop,nop,TS val 2216583 ecr 835172959], length 0
15:41:15.391503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 5789:7236, ack 801, win 495, options [nop,nop,TS val 835172960 ecr 2216583], length 1447: HTTP
15:41:15.392503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 7236, win 46, options [nop,nop,TS val 2216584 ecr 835172960], length 0
15:41:15.395503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 7236:8683, ack 801, win 495, options [nop,nop,TS val 835172961 ecr 2216584], length 1447: HTTP
15:41:15.396503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 8683, win 46, options [nop,nop,TS val 2216585 ecr 835172961], length 0
15:41:15.399503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 8683:10130, ack 801, win 495, options [nop,nop,TS val 835172962 ecr 2216585], length 1447: HTTP
15:41:15.400503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 10130, win 46, options [nop,nop,TS val 2216586 ecr 835172962], length 0
15:41:15.403503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 10130:11591, ack 801, win 495, options [nop,nop,TS val 835172963 ecr 2216586], length 1461: HTTP
15:41:15.404503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 11591, win 46, options [nop,nop,TS val 2216587 ecr 835172963], length 0
15:41:15.407503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 11591:13038, ack 801, win 495, options [nop,nop,TS val 835172964 ecr 2216587], length 1447: HTTP
15:41:15.408503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 13038, win 46, options [nop,nop,TS val 2216588 ecr 835172964], length 0
15:41:15.411503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 13038:14485, ack 801, win 495, options [nop,nop,TS val 835172965 ecr 2216588], length 1447: HTTP
15:41:15.412503 IP 192.168.1.140.57876 > 74.143.213.188.80: Flags [.], ack 14485, win 46, options [nop,nop,TS val 2216589 ecr 835172965], length 0
15:41:15.415503 IP 74.143.213.188.80 > 192.168.1.140.57876: Flags [P.], seq 14485:15932, ack 801, win 495, options [nop,nop,TS val 835172966 ecr 2216589], length 1447: HTTP

Were absolute or relative sequence numbers used during the capture? (see question-1.zip to answer)

The capture is using relative sequence numbers.

You can tell because the sequence values shown are small readable numbers like:

seq 2897:4345
seq 7241:8689

If the capture were using absolute sequence numbers, they would appear as very large 32-bit numbers like:

seq 2387613995:2387614052

If I wish to start a capture without hostname resolution, verbose output, showing contents in ASCII and hex, and grab the first 100 packets; what are the switches used? please answer in the order the switches are asked for in the question.

The switches, in the exact order asked, are:

-n -v -X -c 100

Explanation (short):

  • -n → no hostname/port resolution
  • -v → verbose output
  • -X → show ASCII + hex dump
  • -c 100 → capture only the first 100 packets

[REDACTED]

Given the capture file at /tmp/capture.pcap, what tcpdump command will enable you to read from the capture and show the output contents in Hex and ASCII? (Please use best practices when using switches)

Use the read switch and include hex + ASCII output (best practice: also disable name resolution):

sudo tcpdump -nn -XX -r /tmp/capture.pcap

Explanation:

  • -r /tmp/capture.pcap → read from the capture file
  • -nn → do not resolve IPs or ports
  • -XX → show packet contents in hex and ASCII

[REDACTED]

What TCPDump switch will increase the verbosity of our output? ( Include the – with the proper switch )

The switch to increase verbosity is: -v

[REDACTED]

What built in terminal help reference can tell us more about TCPDump?

You can use the man pages: man tcpdump

[REDACTED]

What TCPDump switch will let me write my output to a file?

The switch used to write output to a file is: -w

[REDACTED]

Fundamentals Lab

This lab is designed to get you comfortable with tcpdump, the command-line packet sniffer, and with working in a terminal environment. The goal is simple: learn how to read and write PCAPs, use basic tcpdump switches, find and manage capture files, and — most importantly — confirm you can actually observe network traffic from your capture point.

Below you’ll find a clear set of objectives, a suggested workflow, tips for exploration, and a short troubleshooting / validation checklist so you can run the lab confidently and produce meaningful captures for later analysis.

Why this lab matters

As the new network administrator for the Corporation, you’re responsible for validating monitoring infrastructure and building a baseline of normal network behavior. Capturing traffic is a core skill for:

  • Verifying monitoring tools and capture points (SPAN/TAP).
  • Creating baseline traffic to detect anomalies later.
  • Investigating suspicious activity (backdoors, exfiltration, unexpected connections).
  • Practicing secure, auditable capture workflows for incident response.

This lab is intentionally small and focused so you can build muscle memory with terminal tools before moving to advanced packet analysis.

Lab objectives (what you should accomplish)

  1. Confirm tcpdump and libpcap are installed and runnable on your host.
  2. Capture a small sample of traffic from your local broadcast domain.
  3. Save that capture to a .pcap file and verify it.
  4. Read and inspect the capture from the terminal and optionally import it into Wireshark.
  5. Experiment with several tcpdump switches and BPF filters.
  6. Document your findings and verify the capture device sees broadcast-domain traffic.

If you want to dig deeper, a second track offers exploratory tasks (below).

Suggested step-by-step workflow

  1. Prepare your environment
    • Open a terminal or SSH session to the capture host.
    • Confirm network interfaces with ip a or ifconfig.
    • Check for tcpdump: tcpdump --version. If missing, install with your distro package manager (e.g., sudo apt install tcpdump).
  2. Basic test capture
    • Capture a small number of packets to confirm functionality:
      sudo tcpdump -i eth0 -c 100 -w /tmp/test_capture.pcap
      Replace eth0 with the correct interface from step 1 and -c 100 to limit packet count.
    • The -w option writes raw PCAP data to disk (non-human-readable). Use -r to read later.
  3. Read and validate the file
    • Read the saved capture in the terminal:
      tcpdump -r /tmp/test_capture.pcap -n -tttt
      This prints decoded packets with human-readable timestamps and avoids DNS lookups (-n).
    • Optionally copy the PCAP locally and examine in Wireshark for richer decoding.
  4. Try a few useful switches
    • -s <snaplen> to capture the first N bytes of each packet (e.g., -s 96 to limit file size).
    • -vv / -vvv for increasing verbosity when printing.
    • -tttt for readable timestamps; -tt for epoch times.
    • -c <count> to stop after N packets.
    • -w to write to file, -r to read from file.
  5. Use BPF filters to focus
    • Filter by host: sudo tcpdump -i eth0 host 10.0.0.5
    • Filter by port: sudo tcpdump -i eth0 tcp port 80
    • Filter by protocol: sudo tcpdump -i eth0 icmp
    • Combine expressions: sudo tcpdump -i eth0 'host 10.0.0.5 and tcp port 443'
  6. Confirm broadcast domain visibility
    • Use ARP or broadcast filters to see local network chatter:
      sudo tcpdump -i eth0 arp or broadcast
    • If you capture ARP/LLMNR/mDNS and other local service announcements, your interface is seeing broadcast domain traffic.
  7. Save and secure artifacts
    • Move captures to a secure location, document capture time/interface/filters, and treat PCAPs as sensitive artifacts.
    • If you plan to analyze on another host, use scp or a secure transfer mechanism.

Exploratory tasks (optional deeper practice)

  • Capture only HTTP traffic and try to extract plaintext credentials from an unencrypted request.
  • Experiment with -s 0 (capture full packets) vs a smaller snaplen and compare output size and information retained.
  • Run a longer capture and rotate files using -W + -C (ring buffer) to avoid filling disk.
  • If you’re on a switched network and don’t see other hosts’ traffic, test capture from a SPAN/mirror port or a TAP (if available).
  • Try monitor mode for wireless captures (requires appropriate drivers and privileges).
  • Combine tcpdump with grep or awk for quick parsing in scripts (but prefer Wireshark/tshark for structured parsing).

Common pitfalls and troubleshooting

  • No packets shown: Verify you selected the correct interface and that the capture point actually sees traffic. Use ip a and check link status.
  • Empty capture on a switch: On switched networks you won’t see other hosts’ traffic unless using a mirror port, a TAP, or ARP/bridge-based visibility.
  • Large files: Set snaplen (-s) and packet count (-c) or enable file rotation (-W, -C) to manage disk usage.
  • Missing tcpdump on Windows: Use WSL or spin up a small Linux VM for tcpdump usage.
  • Permission denied: Remember tcpdump requires root privileges — run with sudo.

What to record for your lab submission

For each capture you produce, include the following in your notes:

  • Host and interface used (e.g., corp-capture-01, eth0)
  • Exact tcpdump command (so it’s reproducible)
  • Capture start/end timestamps (UTC preferred)
  • File name and location (e.g., /tmp/test_capture.pcap)
  • Short summary of what you observed (ARP chatter, DNS queries, HTTP flows, etc.)
  • Any issues encountered and how you resolved them

This documentation is useful during handoffs, audits, and later incident investigations.

Safety, privacy, and policy reminders

  • Only capture traffic when you have explicit authorization to do so. Network captures can include highly sensitive data.
  • Treat PCAP files as sensitive artifacts and store them securely.
  • Be cautious when sharing captures — sanitize or redact sensitive fields if required by policy.

Key Takeaways

  • This lab teaches core tcpdump skills: capturing to files, reading PCAPs, applying filters, and validating capture visibility.
  • Start with small, focused captures to learn filters and limit file growth.
  • Confirm your capture point (interface / SPAN / TAP) so you actually see broadcast-domain traffic.
  • Document every capture (commands, timestamps, findings) — good habits matter in real engagements.
  • Explore advanced switches and rotate files for long captures once you’re comfortable.

What TCPDump switch will allow us to pipe the contents of a pcap file out to another function such as ‘grep’?

The switch that allows tcpdump output to be piped to tools like grep is: -l

[REDACTED]

True or False: The filter “port” looks at source and destination traffic.

The port filter matches both source and destination ports.

[REDACTED]

If we wished to filter out ICMP traffic from our capture, what filter could we use? ( word only, not symbol please.)

Using the filter not icmp will exclude all ICMP packets (such as ping requests and replies) from the capture. This lets us capture all other traffic while ignoring ICMP specifically.

[REDACTED]

What command will show you where / if TCPDump is installed?

The command is: which tcpdump

[REDACTED]

How do you start a capture with TCPDump to capture on eth0?

You can start a capture on eth0 with: sudo tcpdump -i eth0

[REDACTED]

What switch will provide more verbosity in your output?

The switch for increased verbosity is: -v

[REDACTED]

What switch will write your capture output to a .pcap file?

The switch used to write the capture to a file is: -w

[REDACTED]

What switch will read a capture from a .pcap file?

The switch used to read from a .pcap file is: -r

[REDACTED]

What switch will show the contents of a capture in Hex and ASCII?

The switch that shows the contents in Hex and ASCII is: -X

[REDACTED]

Tcpdump Packet Filtering

When working with packet captures, the raw amount of data can quickly become overwhelming. This is where tcpdump filters come into play. They provide a powerful and efficient way to narrow down what you capture, making your analysis faster and more meaningful. In this article, we’ll dive into the world of tcpdump filtering, explore advanced syntax options, and understand how they help us gain clearer insights into network traffic.

Why Filters Matter in Tcpdump

Tcpdump is a versatile tool, but if you run it without filters, you may end up with gigabytes of data — much of it irrelevant to your investigation. By applying filters:

  • Efficiency improves: Less unnecessary data is written to disk.
  • Buffering is faster: Smaller capture size means tcpdump can process packets more smoothly.
  • Focus increases: You can zero in on exactly what you’re looking for — such as traffic from a single host, a specific port, or even a TCP flag.

Think of filters as a magnifying glass: instead of staring at the entire forest, you can zoom in on the one tree that matters.

Filtering and Advanced Syntax Options

Tcpdump offers a range of filters that can be combined with its standard syntax. These filters let you define precisely what traffic should be displayed or saved. You can capture broadly, such as all packets on a network segment, or drill down to specific traffic patterns.

Here are some examples of filtering capabilities:

  1. Host-based filtering tcpdump host 192.168.1.10 Captures only packets sent to or from the specified host.
  2. Port-based filtering tcpdump port 443 Useful for isolating HTTPS traffic.
  3. Protocol-specific filtering tcpdump ip tcpdump arp tcpdump tcp Limits output to a particular protocol type.
  4. TCP flag filtering tcpdump 'tcp[tcpflags] & tcp-syn != 0' Captures only packets where the SYN bit is set (helpful for detecting new TCP connections).
  5. Combination filters tcpdump 'src host 192.168.1.10 and port 22' Allows fine-grained control by combining conditions — in this case, SSH traffic from a specific host.

Building Confidence with Advanced Operators

The filters listed above aren’t exhaustive — tcpdump’s flexibility allows for much more. By experimenting with logical operators (and, or, not), you can create powerful expressions to isolate very specific traffic patterns.

For example:

  • Capture only HTTP or HTTPS traffic: tcpdump 'port 80 or port 443'
  • Exclude broadcast traffic: tcpdump 'not broadcast and not multicast'
  • Focus on traffic between two hosts: tcpdump 'host 10.0.0.5 and host 10.0.0.8'

With practice, you’ll discover combinations that allow you to target anomalies, suspicious behavior, or even potential attacks hidden within the noise of everyday network traffic.

Practical Benefits of Filtering

Beyond saving disk space and CPU resources, filtering also directly supports security analysis and troubleshooting. For instance:

  • Incident response: Capture only packets related to a suspected malicious host.
  • Performance issues: Isolate traffic to a single application port to diagnose latency.
  • Network baselining: Regularly filter specific protocols to understand “normal” behavior.

In penetration testing and red teaming scenarios, precise filtering allows security professionals to spot backdoors, data exfiltration attempts, or misconfigurations that might otherwise be buried in the noise.

Key Takeaways

  • Filters make tcpdump efficient by trimming down capture size and improving processing speed.
  • Advanced syntax and operators allow you to craft precise rules — focusing on protocols, hosts, ports, or even TCP header flags.
  • Experimentation is essential: the best way to learn tcpdump filters is by trying out different combinations.
  • Practical security value: filters help identify anomalies and support incident response, troubleshooting, and penetration testing.

By mastering tcpdump filters, you transform the tool from a blunt instrument into a precision weapon — one that can uncover the hidden details of your network traffic.

What filter will allow me to see traffic coming from or destined to the host with an ip of 10.10.20.1?

The filter host 10.10.20.1 will capture any packets where the source or destination IP is 10.10.20.1.
This makes the filter bi-directional, showing both inbound and outbound traffic.

[REDACTED]

What filter will allow me to capture based on either of two options?

The filter keyword is: or

[REDACTED]

True or False: TCPDump will resolve IPs to hostnames by default.

By default, tcpdump will try to resolve IP addresses into hostnames unless you disable it with -n.

[REDACTED]

Interrogating Network Traffic With Capture and Display Filters

One of the most valuable skills in network security and administration is the ability to interrogate captured traffic effectively. Raw packet captures can be overwhelming, but by applying filters, you can extract meaningful patterns and insights. This lab is designed to give you hands-on exposure to packet filtering, helping you build confidence in analyzing .pcap files and identifying key network activity.

Lab Objectives

The purpose of this lab is twofold:

  1. Skill Development – Gain practical experience working with tcpdump filters, including host, port, and protocol options.
  2. Network Analysis – Learn to recognize and interpret responses to critical network services such as DNS and HTTP/S.

By the end of this exercise, you’ll have a solid grasp of how to slice through noisy captures and uncover the details that matter.

Filters in Action

Filters are the key to turning an unmanageable capture into actionable intelligence. In this lab, you’ll be experimenting with several filter types:

  • Host filters – Focus only on traffic to or from a specific machine. tcpdump -r capture.pcap host 192.168.1.50
  • Port filters – Zero in on traffic to specific services. tcpdump -r capture.pcap port 80
  • Protocol filters – Limit your view to a certain type of protocol. tcpdump -r capture.pcap udp
  • Combined filters – Create precise queries by combining conditions. tcpdump -r capture.pcap 'host 192.168.1.10 and port 53'

These commands allow you to narrow the traffic to only the pieces relevant to your investigation.

Scenario: Corporate Network Survey

After demonstrating your ability to capture network traffic for the Corporation, management now expects you to analyze the captured data. Your assignment is straightforward but highly practical:

Identify which servers in the local network are answering DNS and HTTP/S requests.

This task simulates a common real-world need. System administrators, penetration testers, and network defenders often need to confirm which systems are handling essential services — sometimes to validate configurations, other times to detect unauthorized or unexpected activity.

Guided vs. Exploratory Approach

This lab supports two different learning styles:

  1. Exploratory Approach
    • Treat the .pcap file as a sandbox.
    • Try out different filters and combinations.
    • Discover patterns without being told exactly where to look.
  2. Guided Walkthrough
    • If you prefer structured learning, a detailed walkthrough is provided.
    • Each task is broken down with clear instructions in the solution bubble.
    • This ensures you don’t miss key details while practicing.

Both approaches are valid. In fact, combining them is ideal: first, attempt to solve the tasks independently, then review the guided solutions to compare your process and results.

Why This Matters

Being able to spot DNS and HTTP/S servers on a network has real-world applications:

  • Network Baseline – Ensures only intended systems are answering requests.
  • Incident Response – Helps detect rogue servers set up by attackers.
  • Pentesting & Red Teaming – Reveals targets that may expose sensitive data or provide an entry point.
  • Compliance & Monitoring – Verifies that configurations align with organizational policies.

Key Takeaways

  • Filters transform raw captures into meaningful insights. Without them, analysis would be slow and overwhelming.
  • Different filters serve different purposes. Use host, port, protocol, and logical combinations to refine your view.
  • Practical assignments like identifying DNS/HTTP servers simulate real-world tasks for admins and security professionals.
  • Exploration builds intuition, while walkthroughs provide structured reinforcement of best practices.

By mastering tcpdump filtering and practicing on .pcap files, you’re building a skill set that’s directly transferable to network troubleshooting, cybersecurity investigations, and penetration testing.

What are the client and server port numbers used in first full TCP three-way handshake? (low number first then high number)

The server is listening on port 80 (HTTP), which is the low port.
The client uses a random high port (3372) to establish the connection, so the handshake occurs between 80 and 3372.

[REDACTED]

Based on the traffic seen in the pcap file, who is the DNS server in this network segment? (ip address)

172.16.146.1 responds to DNS queries (port 53) in the capture.
Because it sends DNS replies, it is acting as the DNS server for the network segment.

[REDACTED]

Analysis with Wireshark

When it comes to network analysis, few tools are as widely recognized and respected as Wireshark. While tcpdump offers powerful command-line packet capturing, Wireshark brings a graphical interface (GUI) that makes packet inspection more intuitive and accessible. It’s free, open-source, and available across multiple platforms, making it a go-to choice for network administrators, penetration testers, and cybersecurity professionals alike.

What is Wireshark?

Wireshark is a network traffic analyzer capable of capturing, filtering, and analyzing packets from a wide variety of network interfaces. It doesn’t just display the raw traffic—it breaks down packets into human-readable fields, providing deep insight into how protocols communicate and interact.

Unlike tcpdump, which requires users to sift through text-based output, Wireshark’s GUI allows you to visually navigate traffic flows, apply filters, and even reconstruct sessions. This makes it not only a diagnostic tool but also a learning platform for understanding how networks operate.

Why Wireshark Stands Out

Several features make Wireshark an indispensable tool:

  • Graphical and Command-Line Support
    While Wireshark is best known for its GUI, command-line variants such as tshark allow users to work in environments where no graphical interface is available (e.g., remote servers).
  • Cross-Platform Compatibility
    Wireshark runs on most major operating systems, including Windows, Linux, macOS, BSD, and Solaris, ensuring accessibility no matter your setup.
  • Interface Flexibility
    It can capture from multiple interface types, including:
    • Ethernet
    • Wi-Fi (IEEE 802.11)
    • USB
    • Bluetooth
    • PPP/HDLC
    • ATM
    • Token Ring, Frame Relay, FDDI, and more
  • Deep Protocol Analysis
    Wireshark supports hundreds of protocols, from the classics like TCP/IP and DNS to modern security protocols.
  • Decryption Capabilities
    It can decrypt and analyze encrypted traffic for protocols such as:
    • IPsec
    • ISAKMP
    • Kerberos
    • SNMPv3
    • SSL/TLS
    • WEP and WPA/WPA2
  • File Format Support
    Captures can be saved and exported in various formats, making collaboration and further analysis easier.

Real-World Applications

Wireshark isn’t just for labs and classrooms—it’s widely used in professional environments:

  1. Network Troubleshooting
    • Identify latency issues
    • Pinpoint packet loss
    • Detect routing misconfigurations
  2. Security Analysis
    • Spot suspicious traffic patterns
    • Investigate potential intrusions
    • Verify encryption in sensitive data transfers
  3. Learning & Training
    • Perfect for students and professionals studying networking
    • Explore how DNS lookups, TCP handshakes, or HTTPS sessions actually work
  4. Compliance & Forensics
    • Auditors and forensic teams use Wireshark to validate secure configurations
    • Evidence gathering during incident investigations

Variants for Command-Line Environments

Not every system has a GUI available, especially in server or cloud environments. Fortunately, Wireshark has alternatives:

  • TShark – The command-line counterpart of Wireshark, offering capture and analysis capabilities directly in the terminal.
  • Dumpcap – A lightweight packet capture tool included with Wireshark for efficient raw data collection.

These make Wireshark’s core features available even in headless systems, ensuring flexibility for both analysts and penetration testers.

Key Takeaways

  • Wireshark is more than a packet sniffer — it’s a complete network analysis toolkit.
  • Its GUI makes deep packet inspection intuitive, while tools like TShark extend its reach to command-line environments.
  • With support for hundreds of protocols, multiple interfaces, and even encrypted traffic, Wireshark is one of the most versatile tools in a security professional’s toolkit.
  • Whether you’re troubleshooting, learning, or investigating incidents, Wireshark provides the level of visibility needed to understand what’s happening on your network.

True or False: Wireshark can run on both Windows and Linux.

Wireshark is cross-platform and supports Windows, Linux, macOS, and BSD systems.
As long as the system meets basic requirements, it can run Wireshark and capture network traffic.

[REDACTED]

Which Pane allows a user to see a summary of each packet grabbed during the capture?

The Packet List pane shows a summary of each captured packet in a list format.
It displays fields like time, source, destination, protocol, and brief info for quick overview.

[REDACTED]

Which pane provides you insight into the traffic you captured and displays it in both ASCII and Hex?

The Packet Bytes pane.
It shows the raw captured data in Hex and ASCII formats for detailed inspection.

[REDACTED]

What switch is used with TShark to list possible interfaces to capture on?

The switch is: -D

[REDACTED]

What switch allows us to apply filters in TShark?

The switch used to apply capture filters in TShark is: -f

[REDACTED]

Is a capture filter applied before the capture starts or after? (answer before or after)

A capture filter is applied before the capture begins to limit which packets are recorded.

[REDACTED]

Wireshark Advanced Usage

Wireshark is already powerful out of the box, but its advanced features and plugins elevate it into one of the most comprehensive network analysis platforms available. Beyond simply capturing and filtering traffic, Wireshark allows you to track conversations, analyze statistics, and even work with wireless security protocols. In this section, we’ll explore how these advanced capabilities can turn packet captures into actionable intelligence.

Why Advanced Features Matter

For beginners, Wireshark is often about learning how to capture packets and apply display filters. But once you’re comfortable, you’ll quickly realize the value of diving deeper. Advanced features help you:

  • Identify top talkers in a network (hosts generating the most traffic).
  • Break down protocol usage across your environment.
  • Drill into individual conversations, such as a TCP session between a client and server.
  • Investigate security implications, like weak encryption or unusual packet flows.

In short, advanced usage moves Wireshark from being a packet sniffer to being a network intelligence engine.

Exploring Plugins in Wireshark

Wireshark includes a wide range of plugins accessible from the Analyze and Statistics tabs. These plugins are like mini-applications inside Wireshark, each designed to extract specific insights from your capture.

Some examples of what plugins can do:

  • Track TCP conversations to visualize the flow between hosts.
  • Identify protocol breakdowns to see which services dominate the traffic.
  • Generate reports that summarize bandwidth usage, latency, or error conditions.
  • Support wireless analysis, including the ability to work with WPA/WPA2 handshakes.

Pro tip: Wireshark’s plugins are not limited to what comes pre-installed. Community-developed plugins can extend functionality even further, making the tool adaptable to specialized environments.

The Statistics Tab

The Statistics tab is one of Wireshark’s most powerful features. It provides high-level visibility into your capture with built-in reports and summaries. A few highlights include:

  • Protocol Hierarchy – Breaks down traffic by protocol, showing percentages and counts (e.g., 40% HTTPS, 25% DNS).
  • Conversations – Displays communication between pairs of endpoints (IP-to-IP or MAC-to-MAC).
  • Endpoints – Summarizes statistics for every host observed, such as packet counts and bytes transferred.
  • IO Graphs – Visualize packet rates over time, helping you spot spikes, drops, or patterns.

These insights are especially useful when analyzing large captures where manual inspection is impractical.

The Analyze Tab

The Analyze tab complements Statistics by providing tools for deeper inspection. It allows you to:

  • Apply or remove display filters to zoom in on traffic of interest.
  • Follow specific streams (TCP, UDP, HTTP, etc.) to reconstruct conversations between clients and servers.
  • Decode protocols or adjust how packets are interpreted if Wireshark hasn’t automatically recognized them.
  • Run expert analysis, which flags unusual or potentially problematic behavior in the capture (e.g., retransmissions, malformed packets).

This tab essentially acts as your microscope, letting you drill into specific parts of the capture for precision analysis.

Real-World Use Cases

The combination of Analyze and Statistics tools makes Wireshark invaluable for:

  • Performance Troubleshooting – Spotting bottlenecks by analyzing throughput and retransmissions.
  • Security Audits – Detecting rogue devices, abnormal traffic flows, or weak encryption.
  • Incident Response – Quickly identifying compromised hosts or data exfiltration attempts.
  • Training & Education – Teaching students or junior analysts how to interpret real-world network traffic.

Key Takeaways

  • Plugins extend Wireshark’s power, providing specialized analysis without extra tools.
  • The Statistics tab offers high-level summaries, making it easy to spot trends and anomalies.
  • The Analyze tab enables precision work, from following conversations to decoding encrypted sessions.
  • Together, these features make Wireshark one of the most comprehensive traffic analysis platforms available.

Mastering these advanced features is about more than just clicking through menus—it’s about developing an investigative mindset. With the right combination of filters, plugins, and analysis tools, Wireshark can reveal a complete story about what’s happening on your network.

Which plugin tab can provide us with a way to view conversation metadata and even protocol breakdowns for the entire PCAP file?

Statistics tab — it provides protocol hierarchy, address/endpoint stats, top talkers, and conversation breakdowns for the whole PCAP.
Use it to get quick metadata and protocol-level summaries (packets, bytes, conversation pairs) for analysis.

[REDACTED]

What plugin tab will allow me to accomplish tasks such as applying filters, following streams, and viewing expert info?

The Analyze tab. It allows you to follow TCP streams, apply/prepare filters, and view Expert Information about anomalies in the traffic.

[REDACTED]

What stream oriented Transport protocol enables us to follow and rebuild conversations and the included data?

TCP is a stream-oriented transport protocol, meaning data is sent in a continuous, ordered flow.
Because of this, Wireshark can reassemble and follow TCP streams to rebuild full conversations.

[REDACTED]

True or False: Wireshark can extract files from HTTP traffic.

Wireshark can reassemble HTTP streams and extract transferred files such as images, documents, or executables.
This is done through File → Export Objects → HTTP.

[REDACTED]

True or False: The ftp-data filter will show us any data sent over TCP port 21.

ftp-data shows data transferred over TCP port 20, not port 21.
Port 21 is used for FTP control commands, not file data.

[REDACTED]

Packet Inception, Dissecting Network Traffic With Wireshark

One of Wireshark’s most powerful features is its ability to reassemble and extract objects from captured traffic. In this lab, we’ll practice digging into an unencrypted web session, filtering for HTTP packets, and pulling out an image file that may contain hidden messages. This exercise simulates a real-world security investigation where suspicious activity must be validated with evidence.

Lab Overview

The purpose of this lab is to:

  • Gain experience dissecting captured traffic in Wireshark.
  • Learn how to apply filters to reduce noise and focus on relevant packets.
  • Extract files from HTTP traffic, including images.
  • Provide evidence of improper network usage.

In this scenario, the Security Manager suspects that a user is hiding messages inside images transferred over an unencrypted web session. We’ll use Wireshark to uncover and export these suspicious files for further analysis.

Getting Started

You’ll need the pre-captured packet file provided in the resources:

Wireshark-lab-2.zip → extract and locate Wireshark-lab-2.pcap.

Task #1: Open the Pre-Captured File

  1. Launch Wireshark.
  2. Navigate to File → Open.
  3. Browse to the file Wireshark-lab-2.pcap and open it.

You should now see a full capture with around 1171 packets total. At this point, the window will look busy, as it contains a mix of TCP, IP, and other traffic.

Task #2: Filter the Results (Focus on HTTP)

Since the Security Manager suspects an image was transferred via HTTP, let’s narrow the view:

  • Apply the filter: http

This filter displays only HTTP packets (TCP port 80).

Notice how this reduces the clutter, showing only about 20 HTTP packets instead of the full 1171.

Within these packets, you’ll see:

  • GET requests – requests made by the client to retrieve files.
  • 200 OK responses – confirmations from the server that the requested file was delivered.

This is exactly what we need to investigate.

Task #3: Follow the Stream and Extract Objects

Now that we’ve identified HTTP traffic, it’s time to examine file transfers:

  1. Locate a packet with an HTTP 200 OK response.
  2. Right-click the packet → Follow → TCP Stream.
  3. Review the contents of the stream — this shows you the file transfer between client and server.

At this stage, we’re looking for image formats such as:

  • JFIF (JPEG File Interchange Format)
  • PNG (Portable Network Graphics)

If you spot JFIF headers in the packet details, you’ve confirmed the presence of JPEG images.

Task #4: Export the Image

Wireshark makes extracting files from HTTP traffic straightforward:

  1. In the menu bar, go to:
    File → Export Objects → HTTP
  2. Review the list of objects transferred in the capture.
  3. Select the suspicious image(s).
  4. Save them locally for further inspection.

You now have the image file evidence requested by the Security Manager.

Real-World Application

This lab mirrors situations that security teams face regularly:

  • Forensics Investigations – uncovering hidden or suspicious data within network captures.
  • Incident Response – validating whether unauthorized files were downloaded or transferred.
  • Policy Enforcement – identifying misuse of corporate networks (e.g., hiding data in images, also known as steganography).

By learning how to extract objects, analysts gain a critical ability: turning raw packets into tangible evidence.

Key Takeaways

  • Filtering reduces noise: Applying an HTTP filter allowed us to focus only on relevant packets.
  • 200 OK responses indicate file transfers, which often hold the evidence you’re looking for.
  • Image headers (like JFIF) confirm the presence of transferable media.
  • Export Objects → HTTP is the quickest way to pull files from unencrypted sessions.
  • This technique is crucial in digital forensics, incident response, and penetration testing.

By completing this lab, you’ve successfully extracted suspicious images from a .pcap file. The Security Manager can now analyze the evidence to confirm whether hidden messages exist.

What was the filename of the image that contained a certain Transformer Leader? (name.filetype)

[REDACTED]

Which employee is suspected of performing potentially malicious actions in the live environment?

Conect to the machine and open the terminal

$ ls
[REDACTED] local-student nrb3n

Guided Lab: Traffic Analysis Workflow

Network baselining is a critical part of security monitoring. By collecting “normal” traffic over time, administrators can spot anomalies that may indicate compromise. In this lab, one such anomaly was detected:

A suspicious connection originating from Bob’s host (IP: 172.16.10.90).

As security analysts, our job is to investigate this unusual behavior, determine if it’s malicious, and provide a summary of our findings for incident response.

Lab Setup

To investigate, we’ll use Wireshark inside the lab environment. Access is provided through XfreeRDP, connecting to a target VM within the Hack The Dome network.

Connection Instructions

  1. Spawn the target machine in the lab.
  2. Use the following FreeRDP command: xfreerdp /v:<target IP> /u:local-student /p:LOCAL_@cademy_stdnt!
  3. Once connected, open Wireshark.
  4. Begin capturing on interface ENS224.

You’ll also be working with a pre-captured file inside guided-analysis.zip for practice and comparison.

Analysis Workflow

When analyzing suspicious traffic, it’s important to follow a structured process. Below is the step-by-step framework we’ll use:

1. Define the Issue

  • Observation: Baseline captures revealed unusual connections from Bob’s host (127.0.0.1).
  • Goal: Determine what kind of activity is occurring, when it started, and whether it indicates compromise.

2. Define Scope

  • Where to look: Packets originating from or directed to 127.0.0.1.
  • Timeframe: Duration of the suspicious sessions in the provided .pcap file and during live capture.

3. Gather Supporting Information

  • Sources: Baseline traffic, the suspicious .pcap file, and live traffic from the Academy lab.
  • Tools: Wireshark filters and analysis plugins.

4. Identify Targets

  • Primary host: Bob’s workstation → 127.0.0.1.
  • Potential secondary hosts: Any systems Bob’s host attempts to communicate with, particularly over suspicious ports.

5. Capture and Filter Network Traffic

  • Apply filters in Wireshark to remove baseline noise: ip.addr == 127.0.0.1 and refine with port filters as needed (e.g., tcp.port == 3389 for RDP).
  • Eliminate known benign services (DNS, standard web browsing) to isolate anomalies.

6. Understand the Captured Traffic

  • Start broad: review all conversations involving 127.0.0.1.
  • Narrow the focus: look for suspicious ports (e.g., 4444 for Netcat shells, 3389 for RDP).
  • Follow streams to reconstruct attacker activity.

7. Note Taking and Documentation

Keep track of:

  • Timestamps – when connections were made.
  • Suspicious ports – Netcat shells often use high, uncommon ports.
  • RDP sessions – look for 3389/TCP traffic between Bob’s host and another workstation.
  • Files/commands – log any evidence of command shells or data exfiltration.

8. Summarize the Findings

Once the analysis is complete, present a clear summary for decision-makers.

Findings

After following the above workflow, the analysis revealed the following:

  • Netcat Shell Detected
    • The attacker established a reverse shell on Bob’s host using Netcat, directly interacting with the machine.
    • Evidence: traffic showing interactive communication over a non-standard port, consistent with Netcat usage.
  • Lateral Movement via RDP
    • From Bob’s host, the attacker attempted to pivot further into the network using Remote Desktop Protocol (RDP).
    • Evidence: TCP 3389 traffic to another Windows desktop within the environment.
  • Captured RDP Traffic
    • The IR team captured segments of this RDP session in the provided .pcap.
    • This shows clear evidence of the attacker trying to establish persistence on a secondary host.

Incident Response Actions

  • Bob’s Host Quarantined – Isolated from the network to stop attacker activity.
  • Incident Response Initiated – Investigation launched to determine:
    • What information was accessed or exfiltrated.
    • Whether other hosts were compromised.
    • How the initial compromise of Bob’s host occurred.

Summary

This lab demonstrates how quickly a seemingly small anomaly (a “weird connection” in baseline traffic) can escalate into a confirmed compromise and lateral movement attempt. By using Wireshark with structured analysis, we identified:

  • Unauthorized Netcat shell activity.
  • Attempts at lateral movement via RDP.
  • The need for immediate containment and response.

This exercise highlights the importance of network monitoring, baselining, and disciplined packet analysis in detecting intrusions before they spread further.

Key Takeaways

  • Always compare suspicious traffic against a baseline to spot anomalies.
  • Netcat shells are common in intrusions and can often be identified by unusual interactive traffic.
  • RDP traffic (3389/TCP) in unexpected contexts should always raise red flags.
  • Structured workflows help ensure nothing is overlooked in an investigation.
  • Thorough note-taking and summaries ensure IR teams can act quickly and confidently.

What was the name of the new user created on mrb3n’s host?

Download the pcap file

Open the file using Wireshark. Right click on it and choose Follow → TCP Stream.

How many total packets were there in the Guided-analysis PCAP?

What was the suspicious port that was being used?

In the PCAP the TCP conversation between the internal hosts shows many packets where one endpoint is sending to TCP port 4444 (for example 10.129.43.29 → 10.129.43.4 :4444). You can confirm this quickly in Wireshark by applying the display filter:

tcp.port == 4444

Or to focus on the suspected host:

ip.addr == 10.129.43.29 && tcp.port == 4444

Decrypting RDP connections

One of Wireshark’s most powerful features is its ability to go beyond packet captures and actually deobfuscate encrypted traffic—as long as you have the right keys. In this lab, we’ll put that capability to the test by working with Remote Desktop Protocol (RDP) traffic.

This exercise simulates a real-world scenario where an attacker has compromised a workstation, and investigators must decrypt and analyze captured traffic to understand the scope of the intrusion.

Lab Scenario

During an Incident Response (IR) investigation on Bob’s host, analysts discovered suspicious outbound RDP traffic to another machine inside the corporate network. Luckily, the IR team captured .pcap files of this activity.

While digging deeper into Bob’s machine, investigators uncovered an RDP session key hidden inside a registry hive. With this key in hand, we can feed it into Wireshark to decrypt and analyze the captured RDP traffic, giving us visibility into what the attacker was doing.

Resource File: RDP-analysis.zip (contains the PCAP and supporting material)

Why Decrypting RDP Matters

RDP is a widely used protocol for remote administration of Windows systems, but it’s also a popular target for attackers. By decrypting RDP traffic, analysts can:

  • Inspect commands issued during a session (instead of just seeing encrypted blobs).
  • Validate attacker actions (did they install tools, move laterally, or harvest credentials?).
  • Provide hard evidence during incident reports or legal proceedings.
  • Correlate traffic with other logs to reconstruct the attacker’s timeline.

Without decryption, you’re blind to the contents of the session. With the key, Wireshark gives you full visibility.

Step-by-Step Analysis Workflow

To properly analyze this lab, we’ll follow the structured workflow introduced earlier in the module.

1. Define the Issue

  • Suspicious RDP traffic originated from Bob’s host.
  • Goal: decrypt the captured traffic to determine what actions were taken.

2. Define Scope

  • Where to look: Packets between Bob’s host and the RDP target.
  • When: The timeframe covered by the .pcap in RDP-analysis.zip.

3. Supporting Evidence

  • .pcap file containing RDP traffic.
  • RDP session key extracted from Bob’s host.

4. Setup Wireshark for Decryption

  1. Open the .pcap file in Wireshark.
  2. Navigate to:
    Edit → Preferences → Protocols → RDP
  3. Enter the extracted RDP session key into the key management section.
  4. Restart the packet decode process—Wireshark should now be able to decrypt the RDP stream.

5. Filtering for Relevant Traffic

Apply filters to isolate the RDP connection:

tcp.port == 3389

This removes unrelated traffic and narrows the view to only the RDP session.

6. Analyze the Session

With decryption enabled, inspect the following:

  • Session initiation – verify Bob’s host initiated the RDP connection.
  • Commands and keystrokes – Wireshark can display user actions, including typed commands.
  • File transfers or clipboard usage – RDP often supports file and clipboard redirection, which attackers may abuse.

Document timestamps, packet numbers, and any suspicious actions uncovered.

7. Summarize the Findings

Once analysis is complete, present a concise summary for leadership. This will guide decisions such as quarantining affected systems, resetting credentials, or escalating to a broader IR effort.

Real-World Applications

This lab mirrors real challenges faced by IR teams:

  • Credential Theft – Attackers often use RDP to move laterally inside networks.
  • Persistence – By creating new accounts or scheduled tasks remotely.
  • Data Theft – Clipboard and file redirection can be abused to exfiltrate sensitive files.
  • Forensic Visibility – Decrypting RDP traffic provides evidence that cannot be ignored in post-incident reporting.

Key Takeaways

  • Encrypted traffic isn’t always a dead end. With the right keys, Wireshark can decrypt and reveal full attacker activity.
  • RDP is a common attack vector. Monitoring and analyzing RDP sessions is essential for incident response.
  • The Analysis Process workflow ensures nothing is overlooked. Define scope, filter traffic, analyze, and document findings clearly.
  • Evidence matters. Decrypted RDP traffic can serve as proof of attacker intent and actions.

By completing this lab, you’ve gained hands-on experience with one of Wireshark’s most advanced features: decrypting live sessions for forensic analysis. This skill is invaluable for both defensive investigations and red team exercises where RDP traffic is in play.

What user account was used to initiate the RDP connection?

Based on this analysis, it is determined that Bob, an employee within the organization, may be involved in potentially harmful activity in the live environment.
The report offers useful guidance for strengthening the network’s security posture and improving its ability to withstand future threats, highlighting the need for continuous monitoring, thorough analysis, and proactive risk-reduction measures.