Lab 1: Guided pcap Analysis — Wireshark CVE Quartet

Module: VCA-MINI-WIRESHARK-CVES-2026-05 Duration: ~2.5 hr (approximately 30 min per part; Part 5 runs 30-45 min) Points: 20 Prerequisites: completed Session 1-4 lecture material; Wireshark 4.6.5 installed on analyst workstation; fwlab container available or instructor-supplied pre-recorded pcap files

Authorization and lab-target discipline

All hands-on work in this lab targets:

1. Pre-recorded .pcapng files from the academy pcap-tools catalog. These files are opened in patched Wireshark 4.6.5 on your analyst workstation. They are safe to open in 4.6.5; the patch prevents the vulnerable code paths from running.

2. The fwlab container running Wireshark 4.6.4 (intentionally vulnerable). This container is the lab target for observing dissector crash behavior. It runs in isolation; it is not connected to any network.

Production analyst workstations are never the target. Do not install or run Wireshark 4.6.4 on any machine you use for legitimate analysis work.

# Start the fwlab container (if using container path)
docker run --rm -it --name fwlab virtusacademy/fwlab:4.6.4 bash

# Inside the container, launch tshark with the trigger capture:
tshark -r /captures/cve-2026-5402-trigger-tls-ech-overflow.pcapng
# On 4.6.4 this will segfault; on 4.6.5 it will complete with expert-info warnings

Authorization statement for your lab notebook:

Authorized target: lab-owned Wireshark 4.6.4 instance in fwlab container, and pre-recorded academy CVE-trigger captures. Lab system: [your machine ID]. Operator: [your name]. Date: [date].

Write this statement at the top of your lab notebook before proceeding.

pcap file locations

The academy pcap-tools catalog hosts all five trigger files under the cve-quartet-2026-05/ prefix. Paths relative to the pcap-tools fixtures directory:

Each file also has a .meta.json companion in the same directory with the capture timestamp, range fingerprint, and CVE anchor metadata.

If using the online catalog: navigate to /pcap-tools/ and filter by the cve-quartet-2026-05 tag.

Part 1: TLS ECH overflow — CVE-2026-5402 (25 min, 4 points)

Objective: identify the malformed ECH extension in the trigger capture; confirm patched Wireshark 4.6.5 raises an expert-info warning instead of following the wrapped offset.

Step 1: first-pass shape check (3 min)

Before opening in Wireshark, use capinfos and tshark for a safe shape check:

capinfos cve-2026-5402-trigger-tls-ech-overflow.pcapng
# Record: number of packets, duration, data link type

tshark -r cve-2026-5402-trigger-tls-ech-overflow.pcapng -V 2>&1 | grep -i "expert\|tls\|ech" | head -20
# On 4.6.5: expect expert-info lines about malformed ECH extension
# On 4.6.4: expect a segfault or crash output

Record the capinfos output and the tshark expert-info lines in your lab notebook.

Step 2: open in patched Wireshark 4.6.5 (10 min)

Open the capture in Wireshark 4.6.5.

1. Navigate to the TLS ClientHello packet. Apply the display filter tls.handshake.type == 1 to find it quickly.

2. In the packet details pane, expand: Transport Layer Security -> TLSv1.3 Record Layer -> Handshake Protocol -> ClientHello.

3. Scroll to Extensions. Locate the encrypted_client_hello extension. Note that Wireshark 4.6.5 shows an expert-info warning on this extension rather than parsing the ECH transcript.

4. In the Expert Information panel (Analyze -> Expert Information), confirm the warning entry for the ECH extension.

Record in your lab notebook:

• What display filter found the ClientHello packet?
• What is the expert-info message text for the malformed ECH extension?
• What is the packet number of the malformed ClientHello?

Step 3: crash confirmation in fwlab 4.6.4 (5 min, optional)

If using the fwlab container:

# Inside fwlab container:
tshark -r /captures/cve-2026-5402-trigger-tls-ech-overflow.pcapng 2>&1 | tail -5

Observe whether tshark crashes (segfault) or completes. Record the output.

Step 4: locate the integer-arithmetic defects in source (7 min)

Using the Wireshark 4.6.5 source or the Wireshark GitLab issue #21090 patch view, locate the three integer-arithmetic defects discussed in Session 1. You do not need to compile Wireshark; reading the patch diff is sufficient.

Record in your lab notebook:

• In which file and approximate function does the ECH transcript reconstruction live?
• What integer types were replaced by the fix?
• Which of the three defects would have been caught by static analysis with a tool like AddressSanitizer versus which require a more targeted integer-overflow check?

Part 1 deliverables (4 points)

Part 2: SBC codec overflow — CVE-2026-5403 (25 min, 4 points)

Objective: identify the oversized SBC RTP stream in the trigger capture; locate the loop accounting failure in the source.

Step 1: shape check (3 min)

capinfos cve-2026-5403-trigger-sbc-rtp-overflow.pcapng

tshark -r cve-2026-5403-trigger-sbc-rtp-overflow.pcapng -T fields -e rtp.payload \
  -Y "rtp" 2>&1 | wc -l
# Count how many RTP packets are in the capture

Record the packet count and duration in your lab notebook.

Step 2: open in Wireshark 4.6.5 (10 min)

1. Apply display filter rtp to isolate the RTP stream.

2. Select any RTP packet and use Telephony -> RTP -> RTP Streams to see the stream summary. Note the payload type and codec.

3. In packet details, expand the RTP layer to locate the SBC payload. Note the payload length per packet.

4. Estimate the total decoded PCM output by multiplying the number of frames by the per-frame decoded size (approximately 128 bytes per SBC frame at typical settings). Compare that estimate to the 8 192-byte output buffer size.

Record in your lab notebook:

• How many RTP packets are in the stream?
• What is the approximate per-packet SBC payload size?
• At what approximate packet number does the cumulative decoded output first exceed 8 192 bytes?

Step 3: source-level analysis (12 min)

Locate plugins/codecs/sbc/sbc.c in the Wireshark 4.6.4 source (or the GitLab issue #21103 patch view).

1. Find the codec_sbc_decode() function. Identify the while loop.

2. Confirm that size_out is initialized to 8 192 before the loop.

3. Find the line inside the loop where the output pointer is advanced. Confirm that size_out is NOT decremented at that point in 4.6.4.

4. In the 4.6.5 patch, confirm the three added lines: subtraction of bytes written from size_out, a comparison before the next decode call, and a break on overflow.

Record in your lab notebook:

• The line number range of the while loop in codec_sbc_decode().
• The exact variable name and type of the output capacity variable.
• Whether size_out is decremented inside the loop in 4.6.4 (yes / no).

Part 2 deliverables (4 points)

Part 3: RDP ZGFX overflow — CVE-2026-5405 (25 min, 4 points)

Objective: identify the oversized uncompressed ZGFX segment in the trigger capture; confirm the asymmetric validation between compressed and uncompressed paths in source.

Step 1: shape check (3 min)

capinfos cve-2026-5405-trigger-rdp-zgfx-overflow.pcapng

tshark -r cve-2026-5405-trigger-rdp-zgfx-overflow.pcapng -Y "rdp" 2>&1 | head -20
# If tshark produces no output, try without the filter (RDP may be on a non-default port)
tshark -r cve-2026-5405-trigger-rdp-zgfx-overflow.pcapng 2>&1 | head -30

Record the port and protocol dissection summary.

Step 2: open in Wireshark 4.6.5 (12 min)

1. Open the capture. RDP runs on TCP 3389 by default. If the dissector does not activate automatically, right-click a packet and choose Decode As -> RDP.

2. Navigate to the packet containing the ZGFX segment. Apply display filter rdp to narrow the packet list.

3. In the packet details pane, expand the RDP layer as deep as it will go. Look for a ZGFX or RemoteFX-related sub-dissector. In 4.6.5, you should see an expert-info warning on the packet where the oversized uncompressed segment would have triggered the overflow.

4. If the expert-info warning is present, record its text. If it is not visible (the 4.6.5 patch may not always emit a visible warning in the GUI for this specific CVE), use tshark with -V and grep for expert or overflow.

Record in your lab notebook:

• The packet number containing the ZGFX segment.
• The value of the payload_length field in that segment (should be greater than 65 536).
• Whether patched Wireshark 4.6.5 produced an expert-info warning on this packet.

Step 3: source-level analysis (10 min)

Locate epan/tvbuff_rdp.c in the Wireshark source (or GitLab issue #21105 patch view).

1. Find rdp8_decompress_segment(). Identify the compressed and uncompressed dispatch paths.

2. In each compressed helper (zgfx_write_raw(), zgfx_write_literal(), zgfx_write_from_history()), confirm that they check bounds before writing.

3. In the uncompressed fast path, confirm that 4.6.4 has no bounds check before the tvb_memcpy() call.

4. In the 4.6.5 patch, confirm the added check: if (payload_length > 65536) with an expert_info call and an early return.

Record in your lab notebook:

• Whether the compressed helper functions check bounds before writing (yes / no, with specific function names).
• Whether the uncompressed path has a bounds check in 4.6.4 (yes / no).
• The output buffer size constant (should be 65 536).

Part 3 deliverables (4 points)

Part 4: Profile import zip-slip — CVE-2026-5656 (25 min, 4 points)

Objective: inspect the malicious profile ZIP archive to identify the path-traversal entries; trace the two-step exploit chain from zip-slip to RCE.

CVE-2026-5656 does not require a network capture for the initial inspection. The trigger file is a ZIP archive (cve-2026-5656-trigger-profile-zip-slip.zip). The loopback pcapng (cve-2026-5656-trigger-profile-zip-slip-loopback.pcapng) captures the local loopback traffic that Wireshark generates when processing the import.

Step 1: inspect the archive without extraction (5 min)

# List archive entries without extracting
unzip -l cve-2026-5656-trigger-profile-zip-slip.zip

Record in your lab notebook:

• How many entries are in the archive?
• Which entry (or entries) contain .. path traversal sequences in the filename?
• What is the filename of the malicious entry, including the full path as stored in the archive?
• What file extension does the malicious entry have, and why does that extension matter for RCE?

Step 2: trace the exploit chain (10 min)

Answer the following in your lab notebook. You may reference the companion handout §4.3 and §4.4.

1. When Wireshark 4.6.4 imports the archive, where does the malicious .lua file land on the filesystem? Write the absolute path for both Linux (~/.config/wireshark/) and Windows (%APPDATA%\Wireshark\) variants.

2. What Wireshark code file and function is responsible for the zip-slip primitive (the extraction without path validation)?

3. What Wireshark code file and function is responsible for auto-executing the extracted .lua file at startup?

4. If an attacker cannot get a victim to restart Wireshark after the import, does the attack succeed? Explain in one sentence.

Step 3: inspect the loopback pcap (5 min)

Open cve-2026-5656-trigger-profile-zip-slip-loopback.pcapng in Wireshark 4.6.5.

tshark -r cve-2026-5656-trigger-profile-zip-slip-loopback.pcapng 2>&1 | head -20

This capture shows the local loopback traffic generated during the import operation.

Record in your lab notebook:

• What protocol(s) appear in the loopback capture?
• Is there any network-layer evidence that would allow an IDS to detect the zip-slip import event? (Yes / no; if no, explain why.)

Step 4: detection options (5 min)

Answer the following in your lab notebook.

1. Write the shell command an analyst would run to scan a profile ZIP archive for path-traversal entries before importing it. (One line; use unzip -l and a pipeline.)

2. Why is a network-IDS rule insufficient as the primary detection layer for this CVE, unlike CVE-2026-5402 and CVE-2026-5405?

Part 4 deliverables (4 points)

Part 5: Suricata rule authoring — CVE-2026-5402 (30 min, 4 points)

Objective: write a Suricata 7.x rule that alerts on TLS ClientHello records with malformed ECH extensions of the CVE-2026-5402 shape; test it against the trigger capture.

Background

The companion Suricata rules reference (cve-suricata-rules-reference-wireshark-quartet-2026-05.md) provides a template rule for CVE-2026-5402. Your task in this part is to:

1. Read and understand the template rule.
2. Write a variant that covers the same condition in your own syntax.
3. Test it against the trigger capture using suricata -r.
4. Document the result.

Rule requirements

Your rule must:

• Alert on TCP traffic to port 443 (standard HTTPS/TLS) carrying a TLS ClientHello with the encrypted_client_hello extension type present.
• Use the msg field to identify the alert as a CVE-2026-5402 indicator.
• Set sid to a value in the 9000000-9000099 range (academy lab SIDs).
• Set rev to 1.

You may use Suricata's tls.sni keyword, the content keyword for the ECH extension type byte sequence (extension type 0xfe0d is the encrypted_client_hello extension type), or the app-layer-event keyword if your Suricata build supports TLS event detection. Consult the companion rules reference for the canonical shape.

Testing

# Run Suricata against the trigger capture in offline mode
sudo suricata -r cve-2026-5402-trigger-tls-ech-overflow.pcapng \
  -S /path/to/your-rule-file.rules \
  -l /tmp/suricata-test-output/ \
  --no-random

# Review alerts
cat /tmp/suricata-test-output/fast.log
cat /tmp/suricata-test-output/eve.json | python3 -m json.tool | grep -A 5 '"alert"'

If your rule fires on the trigger capture, it is working. If it does not fire, review the extension type byte sequence and the TCP port match.

False-positive consideration

After writing your rule, answer in your lab notebook: this rule will fire on any TLS ClientHello containing an ECH extension, including from legitimate browsers connecting to ECH-enabled servers. Is this acceptable as a long-term production rule? What additional condition would narrow the rule to malformed ECH specifically?

You do not need to implement the narrower rule; a written analysis is sufficient.

Part 5 deliverables (4 points)

Lab submission

Submit the following:

1. Lab notebook (plain text or Markdown): authorization statement, recorded outputs and answers for each part. Include terminal output screenshots or copy-paste where noted.

2. Suricata rule file for Part 5 (your-name-cve-5402.rules).

3. Suricata test output for Part 5 (the fast.log file or the relevant eve.json entries).

Total: 20 points. See module rubric in MINI-WIRESHARK-CVES-2026-05-OUTLINE.md for check-for-understanding questions (10 additional points).