Packet Forensics: Web Evidence

Recover HTTP files in Wireshark and document the security exposure.

Introduction

30 Second Summary

Web browsing can leave more behind than the page someone sees. When that traffic is readable, a defender can trace what happened after the moment has passed.

In this project, you will use Wireshark to turn a controlled packet capture of plaintext HTTP traffic into a compact forensics case file.

What You'll Build

Your finished case file shows a reconstructed web conversation beside its recovered images plus a clear security recommendation.

By the end of this project, you'll have:

A repeatable investigation view that reduces raw packet noise to the web requests relevant to your investigation.
A client-server evidence record covering the request method plus host plus URI for a selected request.
A completed case file with recovered JPEG objects stored separately from the original capture. Its security finding explains the exposure. It recommends HTTPS protected by TLS.
Secret Mission: Build a reusable GET-request hunting view. Document its false-positive risk.

Are there any prerequisites?

You need a Windows computer with internet access. Basic IT knowledge plus networking knowledge are required. You also need permission to install software.

Before We Start

A clear investigation starts with a precise question about the controlled traffic in front of you. Defining why readable files matter gives your evidence recovery a defensive purpose.

Set Up Your Investigation Workstation

Your investigation depends on evidence you can trust. A controlled plaintext HTTP capture provides a safe packet-forensics case.

Wireshark 4.6.9 gives you a consistent analyzer for the saved capture. The stable release keeps your workspace aligned with this project.

Windows File Explorer will organize the case files. Notepad will hold your investigation report.

In this step, get ready to:

Install and verify Wireshark 4.6.9.
Create the case folder structure and download the official sample capture.
Create the blank report and open the capture in Wireshark.

Why use a saved capture?

A controlled sample gives every learner the same evidence. It also keeps the investigation focused on analysis.

Using saved traffic avoids collecting packets from another person's network. You can practice recovery without authorization concerns.

Install Wireshark 4.6.9

Npcap supports live packet capture on Windows. This project only needs Wireshark to open a saved capture.

Choose the tab that matches the Wireshark installation on your computer.

✔️ I already have the required version

Press the Windows key to open Windows search.
Type Wireshark into the search field.
Select Wireshark from the results.
Select Help from the main menu.
Select About Wireshark.

The information window should show version 4.6.9. Keep Wireshark open for the next part of the setup.

ⓧ I see an older version

An older release can place controls differently. Installing the stable version keeps the walkthrough consistent.

Windows may display a permission request when the installer starts. Approval allows the installer to make the required system changes.

Close the older Wireshark window.
Visit the official Wireshark download page.
Select the stable 4.6.9 Windows package highlighted for your platform.
Open the downloaded installer.
Approve the Windows permission request if it appears.
Keep the recommended default installation options.
Retain the included Npcap option when the installer shows it.
Complete the installation.

Wireshark is now installed with the standard components for this workstation.

Press the Windows key to open Windows search.
Type Wireshark into the search field.
Select Wireshark from the results.
Select Help from the main menu.
Select About Wireshark.

The information window should now show version 4.6.9. Keep Wireshark open.

ⓧ Wireshark is not installed

Windows may display a permission request when the installer starts. Approval allows the installer to make the required system changes.

Visit the official Wireshark download page.
Select the stable 4.6.9 Windows package highlighted for your platform.
Open the downloaded installer.
Approve the Windows permission request if it appears.
Keep the recommended default installation options.
Retain the included Npcap option when the installer shows it.
Complete the installation.

Wireshark is now installed with the standard components for this workstation.

Press the Windows key to open Windows search.
Type Wireshark into the search field.
Select Wireshark from the results.
Select Help from the main menu.
Select About Wireshark.

The information window should show version 4.6.9. Keep Wireshark open.

Installation not completing?

Confirm that you downloaded the stable Windows package for your platform. Run the installer again from your browser's download location.

Ask for help with the Wireshark installation. You can also ask in the Wireshark Discord.

Build the case folder

Evidence handling starts with an organized case structure. The original capture belongs beside a separate folder for recovered objects.

Press the Windows key to open Windows search.
Type File Explorer into the search field.
Select File Explorer from the results.
Select Documents in the navigation pane.
Select New in the toolbar.
Select Folder.
Enter Packet-Forensics-Case as the folder name.
Press Enter.

You should see Packet-Forensics-Case inside Documents.

Open the Packet-Forensics-Case folder.
Select New in the toolbar.
Select Folder.
Enter evidence as the folder name.
Press Enter.

The case folder now contains an empty evidence subfolder for recovered HTTP objects.

Download the official sample capture by selecting the link.
Switch back to File Explorer.
Select Downloads in the navigation pane.
Select http_with_jpegs.cap.gz.
Press Ctrl+X to cut the file.
Return to Documents\Packet-Forensics-Case.
Press Ctrl+V to move the file into the case folder.

You should now see http_with_jpegs.cap.gz beside the evidence subfolder.

Can't find the sample capture?

Check your browser's download location if the file is missing from Downloads. Confirm that the filename is http_with_jpegs.cap.gz before moving it.

Help me locate the downloaded Wireshark sample capture.

Create the report and open the capture

The report gives your investigation one durable record. Opening the sample capture confirms that the analyzer can read the compressed evidence directly.

Press the Windows key to open Windows search.
Type Notepad into the search field.

✔️ Notepad appears in the results

Select Notepad from the results.
Select File from the menu.
Select Save As.
Navigate to Documents\Packet-Forensics-Case in the save window.
Enter plaintext-http-investigation.txt in the File name box.
Confirm the save to create the blank report.
Keep Notepad open.

ⓧ Notepad is missing

Open the official Windows Notepad listing.
Install Windows Notepad from the listing.
Press the Windows key to open Windows search.
Type Notepad into the search field.
Select Notepad from the results.

Notepad should open to a blank document.

Select File from the menu.
Select Save As.
Navigate to Documents\Packet-Forensics-Case in the save window.
Enter plaintext-http-investigation.txt in the File name box.
Confirm the save to create the blank report.
Keep Notepad open.

Switch back to File Explorer.
Return to Documents\Packet-Forensics-Case.

You should see http_with_jpegs.cap.gz, plaintext-http-investigation.txt, and the evidence subfolder.

Before you open the capture, do you think Wireshark will read the compressed file directly?

Switch back to Wireshark from the installation check.
Select File from the main menu.
Select Open.
Navigate to Documents\Packet-Forensics-Case in the file window.
Select http_with_jpegs.cap.gz.
Select Open.

You'll see captured packet rows fill the packet list. That confirms Wireshark opened the compressed evidence directly.

That's the setup complete. Your analyzer is running with the official capture open.

Packet list still empty?

Confirm that you opened http_with_jpegs.cap.gz from Documents\Packet-Forensics-Case. Make sure you did not select the empty evidence folder.

Help me open the sample capture in Wireshark.

✔️ Awesome, I've got everything!

Great work. Keep Wireshark and Notepad open for the investigation.

ⓧ I'd like to double check the full code

This setup step produces the following case files and workstation state.

The Documents\Packet-Forensics-Case folder contains http_with_jpegs.cap.gz, plaintext-http-investigation.txt, and the evidence subfolder.
The Documents\Packet-Forensics-Case\evidence folder is empty and ready for recovered HTTP objects.
The official http_with_jpegs.cap.gz sample is open in Wireshark 4.6.9.
The blank plaintext-http-investigation.txt report is saved and open in Notepad.
Wireshark 4.6.9 is installed with the recommended defaults. Npcap is installed if you retained the included option.

Your investigation workstation is ready. Next, you'll triage the unfiltered packet list and learn how its panes represent the same traffic.

Triage the Unfiltered Capture

Your official sample capture is open in Wireshark. The evidence is ready for its first review.

Packet triage starts with understanding what the unfiltered evidence contains. The raw packet list is readable, but its volume and mixed rows make focused web-request hunting slow and error-prone.

In this step, get ready to:

Identify the Packet List, Packet Details, and Packet Bytes panes.
Assess the noise in the unfiltered packet list.
Save a first-pass observation in your investigation report.

Identify the three packet panes

Wireshark presents each selected packet at three levels. Moving between rows shows how the summary, protocol structure, and raw data describe the same network event.

In Wireshark from earlier, locate the Packet List pane at the top of the window.
Locate the Packet Details pane beneath the packet list.
Locate the Packet Bytes pane beneath the packet details.
Select one row in the Packet List pane.

The Packet Details pane now shows the selected packet's layered structure. The Packet Bytes pane shows the underlying data from that packet.

Select two more packet rows one at a time.

Each selection updates both lower panes. This confirms that the three views stay linked to the same selected packet.

How Do the Three Panes Work Together?

The Packet List pane summarizes captured events as rows. Its columns help you compare traffic quickly.

The Packet Details pane organizes the selected event into protocol layers. You can expand those layers during a focused investigation.

The Packet Bytes pane exposes the raw data behind the selected event. Together, the panes let you move from a broad clue to its underlying evidence.

Test the unfiltered view

An unfiltered packet list preserves the full capture. That completeness also mixes different protocols and events into the same view.

Before you scan, do you think the unfiltered columns make every web request easy to identify? Your scan will test that prediction.

Leave the display filter field empty during this scan.
Scan the visible values in the Protocol column.
Scan the corresponding summaries in the Info column.
Try to identify the web-request rows using only the unfiltered packet list.

The rows are readable, but different traffic types compete for your attention. Manually hunting for every web request would be slow and easy to get wrong.

Record your first-pass observation

A case record should capture your reasoning before you narrow the evidence. Your Notepad report gives that first impression a permanent place in the investigation.

Switch back to the open plaintext-http-investigation.txt report in Notepad.
Write one sentence stating that the unfiltered capture is readable but contains mixed packet rows.
Write a second sentence explaining that a narrower view is needed for efficient web-request investigation.
Save plaintext-http-investigation.txt.

Your case file now preserves why manual review of the unfiltered capture falls short. That observation gives the next filtering decision a clear purpose.

Before the final check, which three panes do you expect to respond when you select a packet row? This check tests your mental map.

Return to Wireshark from earlier.
Clear any text from the display filter field.
Scroll through the Packet List pane.
Select one packet row.

You'll see multiple packet rows remain visible with no display filter applied. The selected row populates both the Packet Details pane and the Packet Bytes pane.

Packet Panes Look Empty?

Keep one packet row selected before checking the lower panes.
Clear any text from the display filter field if the packet rows are missing.
Maximize the Wireshark window if the lower panes are compressed.

Ask for help if the panes still do not respond. Help me restore the three Wireshark packet panes.

Your unfiltered baseline is documented. Next, you'll narrow the capture to the web requests that matter.

Isolate the HTTP Requests

The raw capture is open in Wireshark. You already proved that its mixed packet rows make manual request hunting slow and error-prone.

A display filter gives you a repeatable way to show only traffic matching an investigation question. You will start with a broad HTTP view before narrowing the evidence to requests.

The request-only view reveals who asked for what. A single request packet still cannot reveal the complete file transferred in the conversation.

In this step, get ready to:

Compare a broad HTTP view with the unfiltered capture.
Use a request-only filter to isolate candidate web requests.
Record the endpoints plus the request details from one selected packet.

Compare HTTP Views

The protocol filter http keeps packets containing HTTP. This creates a broad application-layer baseline for comparison.

Click the display filter field above the Packet List pane in Wireshark.
Enter http.
Press Enter to apply the filter.

You will see the Packet List shrink to packets containing HTTP. The unrelated protocol rows disappear from this view.

Compare the Protocol column with the mixed unfiltered view from earlier.
Compare the Info column with the mixed unfiltered view from earlier.

The broad filter removes unrelated traffic. It still includes HTTP traffic beyond client requests.

Isolate HTTP Request Packets

The field filter http.request matches packets that contain an HTTP request. That narrower list makes each candidate request reviewable.

Replace http with http.request in the display filter field.
Press Enter to apply the request filter.

Only HTTP request packets remain in the Packet List. Each visible row represents a request sent by a client.

Before you select a row, do you think this one request packet contains the complete transferred JPEG?

Select one visible request row in the Packet List.
Inspect the Packet Details pane for that selected row.

You will see request metadata for that packet. The complete transferred JPEG remains outside this single-packet view.

Filter Not Accepting the Request View?

Make sure the display filter field contains exactly http.request.
Remove any extra characters from the display filter field.
Press Enter after correcting the filter.

Help me troubleshoot my Wireshark display filter.

Record Request Evidence

A network endpoint combines an IP address with a port. The request direction makes the source endpoint the client while the destination endpoint is the server.

Expand Internet Protocol in the Packet Details pane.
Expand Transmission Control Protocol in the Packet Details pane.
Expand Hypertext Transfer Protocol in the Packet Details pane.

How Do the Layers Divide the Evidence?

Internet Protocol identifies the source address plus the destination address.
Transmission Control Protocol identifies the source port plus the destination port.
Hypertext Transfer Protocol exposes the request method.
The Host header identifies the requested host.
The request URI identifies the requested resource.

Switch back to Notepad from earlier.
Add a request evidence entry below the existing first-pass observation.
Record the source address plus source port on a line labelled Client endpoint.
Record the destination address plus destination port on a line labelled Server endpoint.
Record the observed method on a line labelled Request method.
Record the observed Host header value on a line labelled Host header.
Record the observed URI on a line labelled Request URI.
Save plaintext-http-investigation.txt by pressing Ctrl+S.

Strong work. Your case record now ties one selected request to its client endpoint plus its server endpoint.

Before your final check, which packet rows do you expect http.request to leave visible?

Return to Wireshark from earlier.
Confirm the active display filter reads http.request.
Confirm one HTTP request row remains selected.
Confirm Internet Protocol remains expanded.
Confirm Transmission Control Protocol remains expanded.
Confirm Hypertext Transfer Protocol remains expanded.

You will see only HTTP request packets in the Packet List. The selected row shows expanded IP, TCP, plus HTTP evidence in the Packet Details pane.

You now have a focused request view plus a packet-level evidence record. Next, you will connect those clues into the complete web conversation.

Reconstruct the Web Conversation

Your filtered HTTP request view has already identified the client, server, method, host, and URI. However, a single request packet cannot reveal the complete transferred file.

Wireshark uses TCP stream reconstruction to join conversation data from multiple packets. The ordered view reveals how the client request connects to the server response.

In this step, get ready to:

Open the selected request as a reconstructed TCP stream.
Distinguish client request data from server response data in ASCII.
Preserve your stream finding in the investigation report.

Follow the selected TCP stream

A TCP conversation can span several packets. Following its stream restores the application data in network order.

Switch back to Wireshark from earlier.
Keep the selected HTTP request highlighted in the Packet List.
Select Analyze from the top menu.
Select Follow.
Select TCP Stream.

You have turned separate packets into one ordered conversation. The Follow TCP Stream dialog shows data from both sides of the selected connection.

What Does Stream Reconstruction Add?

A packet row represents one captured unit from the network. Stream reconstruction joins the related payload data from the same TCP conversation.

The result preserves the sequence in which the client and server exchanged data. That sequence provides context missing from one request packet.

TCP Stream Unavailable?

Confirm that an HTTP request row is selected in the Packet List.
Select a different request row if TCP Stream remains unavailable.

Help me open the selected request in Follow TCP Stream.

Read the client and server exchange

An HTTP conversation pairs a client request with a server response. The ASCII view makes the readable protocol data easier to follow.

Select ASCII from the view format control.
Use the direction control to display both directions.
Read the conversation from top to bottom.
Locate the client request by matching its request line with your earlier evidence.
Locate the server response that follows the request.

You should see client request data followed by server response data. This sequence connects the selected request to response data carried across multiple packets.

What Should I See?

The client side shows the web request associated with your recorded method, host, and URI.
The server side shows the response associated with that request.
Network order shows how the complete exchange unfolded over the connection.

Seeing Only One Direction?

Use the direction control to display both sides of the conversation.
Confirm that the view format is set to ASCII.

Help me distinguish the client request from the server response.

Preserve the reconstruction result

Your investigation report needs to capture the evidential difference between a packet and a reconstructed stream. This note explains why the complete conversation matters.

Switch back to Notepad from earlier.
Add a stream-reconstruction note beneath the recorded request evidence.
Describe the ordered client request you observed.
Record the corresponding server response information that was absent from the single request packet.
Save plaintext-http-investigation.txt.

That closes the evidence gap. Your report now explains what the ordered request and response revealed beyond one packet.

Before you select Back, do you expect the earlier http.request display filter to return? The next click tests your prediction.

Switch back to the Follow TCP Stream dialog.
Select Back.

You should return to the packet list with http.request restored in the display filter bar. Only HTTP request packets remain visible.

Your case now includes both packet-level evidence and the reconstructed client-server conversation. Next, you will recover the transferred files and turn your evidence into a defensive finding.

Recover the Files and Report the Exposure

Your reconstructed stream now shows the ordered client request plus server response in Wireshark. This final step preserves the transferred files as evidence.

Recovered files need context before another defender can act on them. A structured security finding connects the evidence to its impact.

In this step, get ready to:

Export every available HTTP object to the existing evidence folder.
Verify the recovered JPEG files beside the preserved source capture.
Complete a security finding with the exposure's impact plus a practical mitigation.

Export the HTTP objects

Wireshark's object export collects files transferred over HTTP from the capture. Saving every available object in the evidence folder creates a separate set for review.

Return to Wireshark from earlier.
Click File in the top menu.
Select Export Objects.
Select HTTP.

The HTTP Export Objects dialog now lists the files found in the captured web traffic.

Review the Packet, Hostname, Content Type, Size, and Filename columns.
Use the Content Type column to identify the JPEG entries.
Use the Filename column to review each object's saved name.
Click Save All.
Select Documents\Packet-Forensics-Case\evidence in the destination folder prompt.
Confirm the selected destination.

Wireshark saves every available HTTP object to the evidence folder while the source capture remains open.

Verify the recovered evidence

Windows File Explorer provides an independent check that the export exists outside Wireshark. It also lets you confirm the source capture remains preserved.

Press the Windows key to open search.
Type File Explorer and press Enter to open it.
Use the address bar to navigate to Documents\Packet-Forensics-Case.
Double-click the evidence folder.

You should see multiple recovered files in the folder. The collection includes JPEG image files stored separately from the capture.

Evidence folder still empty?

An empty folder usually means a different destination was selected during the export.

Return to the HTTP Export Objects dialog in Wireshark.
Use Save All again.
Select Documents\Packet-Forensics-Case\evidence as the destination.

Help me troubleshoot an empty evidence folder.

Return to Documents\Packet-Forensics-Case in File Explorer.

You should see http_with_jpegs.cap.gz, plaintext-http-investigation.txt, and the populated evidence folder.

That recovery step is complete: the source capture remains preserved while the derived files sit in their own evidence folder.

Complete the security finding

Your existing Notepad report holds the observations from each earlier stage. The final sections turn those notes into a defensive finding.

Why HTTPS with TLS?

Transport Layer Security, or TLS, encrypts communication between a client and server.

HTTPS uses TLS to protect web traffic. This keeps application data encrypted while it travels between the endpoints.

Switch back to the Notepad report from earlier.
Append Summary, Observed Endpoints, Recovered Evidence, Impact, and Mitigation below your existing notes.

You should now see five empty section headings below the investigation notes you already recorded.

Write a concise description of the plaintext HTTP investigation under Summary.
Organize the recorded client endpoint, server endpoint, request method, Host header value, and URI under Observed Endpoints.
Save plaintext-http-investigation.txt.

The opening sections should now identify the investigation's focus plus the web request you traced.

Record the exported JPEG files plus their evidence folder location under Recovered Evidence.
Explain under Impact that captured plaintext HTTP traffic can expose readable application data.
Save plaintext-http-investigation.txt.

The report now links the recovered files to the security exposure demonstrated by the capture.

Recommend HTTPS with TLS under Mitigation so application data is encrypted between the client and server.
Save plaintext-http-investigation.txt.

Before you verify the whole case, what should prove that you preserved both the source evidence and your conclusions?

Switch back to File Explorer from earlier.
Open the evidence folder.

You should see multiple exported objects, including recovered JPEG image files.

Return to Documents\Packet-Forensics-Case in File Explorer.

You should see the preserved http_with_jpegs.cap.gz capture beside the saved report plus populated evidence folder.

Switch back to plaintext-http-investigation.txt in Notepad.
Review the five new section headings.

You should see completed Summary, Observed Endpoints, Recovered Evidence, Impact, and Mitigation sections.

You have closed the loop from packets to evidence: the source capture, recovered images, and defensive recommendation now sit together in one case.

Secret mission

Turn the Investigation into a Hunting View

Turn your completed investigation into a reusable request-hunting workflow. You will filter for HEAD and GET requests, compare the results with your recovered evidence, and document the context needed to avoid false conclusions.

Clean Up Your Resources

Every resource in this investigation is local and free, so keeping it creates no ongoing charges. Choose whether to keep the case available, pause your work, or remove it from your computer.

Resources you used:

Local case folder Documents\Packet-Forensics-Case containing the source capture, saved report, and recovered evidence.
Installed Wireshark version 4.6.9 for packet analysis.
Installed Npcap if it was retained during the default Wireshark installation.

Keep everything running

No action is needed. Choose this option if you want to revisit the investigation or use the case as a reference.

Keep Documents\Packet-Forensics-Case as your local case record.
Leave Wireshark version 4.6.9 installed for future packet analysis.
Leave Npcap installed if you want live-capture support for future authorized work.

Pause - I'll come back to this later

Close the active applications while preserving every investigation file. There are no cloud services or charges to suspend.

Close Wireshark.
Close Notepad.
Close Windows File Explorer.
Leave Documents\Packet-Forensics-Case in place for your next review.

Delete - I don't want to use this again

Deleting the case folder removes your saved report and recovered evidence. Removing Npcap disables packet capture in Wireshark.

Close Wireshark.
Close Notepad.
In Windows File Explorer, return to the parent Documents folder.
Select the Packet-Forensics-Case folder.
Delete the selected folder.
Confirm that Documents\Packet-Forensics-Case no longer appears in Windows File Explorer.

The remaining actions remove the packet-analysis tools from your computer.

Press the Windows key to open search.
Type Programs and Features.
Select Programs and Features from the results.
Select the Wireshark entry.
Use its uninstall option to remove Wireshark.
Select the Npcap entry only if it is present.
Use its uninstall option only if no other application needs Npcap.
Confirm that each removed entry no longer appears in Programs and Features.

Nice Work!

Case closed! You turned an official capture into a packet-forensics case with recovered images plus a defensive security finding.

You've learned how to:

Use Wireshark to triage an unfamiliar capture. Apply http.request to isolate readable HTTP requests from packet noise.
Reconstruct a TCP stream to recover the ordered conversation. Distinguish the client request from the server response.
Recover transferred JPEG objects into a separate evidence folder. Connect that evidence to its impact in a plain-text finding. Recommend HTTPS with TLS as the mitigation.
Secret Mission: Build a reusable GET-request hunting view with http.request.method in {"HEAD", "GET"}. Document a false-positive caveat that keeps matching traffic framed as a review lead.

Ready to quiz yourself?