Investigate HTTP Traffic with Wireshark

Analyze a cleartext HTTP capture and publish an evidence-based incident report.

Introduction

30 Second Summary

A screen full of network activity can make one simple web visit look overwhelming. The real challenge is separating what the evidence proves from what it only suggests.

In this project, you will use Wireshark to investigate a public packet capture of cleartext HTTP traffic. You will publish your evidence and conclusions as a recruiter-readable GitHub case study.

What You'll Build

Picture a recruiter opening your public GitHub repository to follow the investigation from the original capture to your final conclusion without needing Wireshark.

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

  • A public investigation case study that lets a reviewer understand the scenario and finding from the repository's front page.
  • Reproducible packet evidence in evidence.md that records the source and the http.request filter alongside facts you personally observed.
  • A scoped incident report in incident-report.md that separates confirmed cleartext transport from unconfirmed exposure or compromise.
  • Secret Mission: Independently analyze a gzip-encoded HTTP response in a comparison artifact that documents at least three observed differences.

Are there any prerequisites?

You need Ubuntu Linux or Debian GNU/Linux with Git, a GitHub account, and Visual Studio Code available.

No previous cybersecurity experience is required because the project guides you through Wireshark setup.

Before We Start

This project uses public training captures for a simulated security review that becomes a recruiter-facing portfolio case study. Your report will separate observed packet evidence from unconfirmed risk, so it never presents the exercise as a real breach.

Set Up Wireshark and Your Portfolio Repository

A defensible investigation needs a tool that can reveal packet evidence. Wireshark gives you that view before you write any findings.

You already have Git, a GitHub account, plus Visual Studio Code. This step adds the missing analysis tool plus a public workspace for your case study.

In this step, get ready to:
  • Prepare Wireshark through APT.
  • Create a public GitHub Free repository with an initial README.
  • Prepare a verified local workspace from the cloned repository.
Install and verify Wireshark

Wireshark is the packet analyzer you will use throughout the investigation. APT installs the build maintained for your Linux distribution.

Why use APT?

APT retrieves Wireshark from your configured distribution repositories. It also manages the packages that Wireshark needs to run.

Installing system software requires administrator privileges. These commands install the Wireshark package without enabling live capture for this project.

What might APT ask?

APT may pause while it downloads dependencies. A short wait during installation is expected.

  • Enter your administrator password if requested.
  • Confirm the package installation if asked.
  • Choose the option that leaves live capture disabled if a permission prompt appears.

Ubuntu

  • Install Wireshark from Ubuntu's APT repositories by running this command:
sudo apt install wireshark

What does this command do?

  • The sudo command grants administrator privileges for this installation.
  • The apt command retrieves the package named wireshark from Ubuntu's configured repositories.

Debian

  • Start a Debian administrator login shell by running this command:
su -

What does this command do?

This command starts a login shell for the administrator account. Debian asks for the administrator password before changing the shell.

  • Install Wireshark from Debian's APT repositories by running this command inside the administrator shell:
apt install wireshark

What does this command do?

APT retrieves the package named wireshark from Debian's configured repositories. It installs the required dependencies at the same time.

  • Return to your regular account by pressing Ctrl+D after the installation finishes.

Before you check the installation, what do you expect the first line of output to identify?

  • Verify the installed Wireshark build by running this command:
wireshark -v

What does this command do?

  • The wireshark command starts the installed program in version-reporting mode.
  • The -v option prints the Wireshark version plus information about linked libraries.

✔️ I see Wireshark version information

That is your analysis tool ready. The exact version depends on the package supplied by your Linux distribution.

ⓧ I do not see version information

Wireshark did not install?

  • Return to the installation tab for your Linux distribution.
  • Run the APT installation command again.
  • Read the final lines of APT output for a missing repository or network problem.

Still stuck? Help me troubleshoot my Wireshark installation on Ubuntu or Debian.

Create the public portfolio repository

Your repository gives the investigation a public home that a recruiter can open without Wireshark. GitHub displays the initial README.md on the repository's front page.

Making a repository public exposes every committed file. At this point, it contains only the initial README created by GitHub.

  • Open GitHub in your browser.
  • Sign in to your GitHub account.
  • Select New repository.
  • Enter wireshark-http-investigation in the Repository name field.
  • Select Public for the repository visibility.
  • Turn Add README on.
  • Select Create repository.

Your portfolio now has a public starting point. You should see the wireshark-http-investigation repository with its initial README.md rendered on the front page.

Clone and verify your local workspace

An HTTPS clone gives you a local copy of the public repository. Git connects that copy to the remote repository using the name origin.

  • Select Code on the GitHub repository page.
  • Select HTTPS as the clone method.
  • Copy the repository URL.
  • Store the copied URL here: https://github.com/YOUR-USERNAME/wireshark-http-investigation.
  • Return to the terminal you used for the Wireshark installation.
  • Move to your Desktop by running this command:
cd ~/Desktop

What does this command do?

The cd command changes the terminal's current location. The ~/Desktop path keeps your cloned repository easy to find.

  • Clone your public repository by running this command:
git clone [[REPOSITORY_URL="https://github.com/YOUR-USERNAME/wireshark-http-investigation"]]

What does this command do?

Git copies the remote repository into a local folder named wireshark-http-investigation. It configures the copied repository with the GitHub HTTPS remote named origin.

Repository did not clone?

  • Copy the HTTPS URL again from the repository's Code menu.
  • Check that the copied URL belongs to wireshark-http-investigation.
  • Rename any existing Desktop folder with the same repository name before retrying.

Need another pair of eyes? Help me troubleshoot why my public GitHub repository will not clone.

Before you inspect the clone, do you think Git will recognize the folder as a repository?

  • Enter the cloned repository folder and inspect its Git state by running these commands:
cd wireshark-http-investigation
git status

What do these commands prove?

  • The first command moves the terminal into the cloned wireshark-http-investigation folder.
  • The status check confirms that Git recognizes the folder as a repository.
  • The tracked README.md came from the initial GitHub repository.

You should see Git report the repository's current status without a clone error. This confirms that your local folder is connected to the repository workflow.

Git does not recognize the repository?

  • Check that your terminal path ends with wireshark-http-investigation.
  • Return to ~/Desktop if the terminal is in a different folder.
  • Repeat the clone after confirming the GitHub HTTPS URL.

Still blocked? Help me find why Git does not recognize my cloned repository.

  • Open the current repository folder in Visual Studio Code by running this command:
code .

What does this command do?

The code command launches Visual Studio Code. The . value opens the terminal's current folder as the workspace.

Visual Studio Code should open the wireshark-http-investigation folder. The Explorer sidebar should list the initial README.md file.

Visual Studio Code did not open?

  • Open your Linux applications menu.
  • Select Visual Studio Code from the application results.
  • Select File from the top menu.
  • Select Open Folder.
  • Choose the wireshark-http-investigation folder from your Desktop.

Need help opening the workspace? Help me open my cloned GitHub repository in Visual Studio Code on Linux.

✔️ My workspace matches

You have Wireshark version output plus a working local Git repository. Visual Studio Code now shows the initial GitHub-generated README.md.

ⓧ I'd like to double check the full setup

  • Confirm that GitHub shows a public repository named wireshark-http-investigation.
  • Confirm that the repository front page renders the initial GitHub-generated README.md.
  • Confirm that you cloned the repository using its HTTPS URL.
  • Confirm that the Git status check completed inside wireshark-http-investigation.
  • Confirm that Visual Studio Code shows README.md in the Explorer sidebar.

Your analyzer is installed. Your public case-study workspace is ready for the first packet evidence in the next step.

Establish the Unfiltered Evidence Baseline

Your public GitHub repository is ready. Wireshark is installed.

One HTTP exchange can be split across many rows in a packet capture. The key question is whether those rows explain the exchange by themselves.

You'll inspect the official sample with no display filter. You'll record the limits of that raw view before drawing any conclusion.

In this step, get ready to:
  • Save the official http.cap capture outside your repository.
  • Inspect one packet within the unfiltered packet list.
  • Build evidence.md as a scoped baseline record.
Download the official capture

An official training capture gives your investigation a shared evidence source. Keeping the capture outside the repository prevents the binary file from becoming part of your portfolio.

The sample list is long, so this small filename is easy to miss.

The official page describes http.cap as a simple HTTP request and response.

  • Select http.cap to download the capture.
  • Choose your Downloads folder if your browser asks for a location.
  • Open your browser's downloads list.

You should see http.cap listed as a completed download. Good start. Your evidence source is now separate from the public repository.

Capture not downloading?

  • Return to the official sample page if the download did not begin.
  • Search for the exact filename http.cap.
  • Check your browser's downloads list for an incomplete transfer.

Still stuck? Help me download http.cap from the official Wireshark Sample Captures page.

Inspect the unfiltered packet list

Wireshark presents each captured frame as a separate row. Selecting one row exposes its protocol layers in the details pane.

The protocol tree can feel dense on first inspection.

Before you open the capture, do you think the raw packet list will explain the complete request and response?

  • Use your Linux desktop's application menu to open the file manager.
  • Select your Downloads folder in the file manager sidebar.
  • Right-click http.cap.
  • Choose Wireshark from the available applications.
  • Confirm the display filter toolbar is empty.
  • Review the Source, Destination, Protocol, and Information columns.
  • Select one traffic row.
  • Expand one available protocol layer in the details pane.

You'll see traffic rows containing source, destination, protocol, and information values. Selecting a row exposes layered details while the complete request-response story remains fragmented.

Why does the raw view fall short?

Each row represents one captured frame. Details from one application exchange can appear across several rows and protocol layers.

Your baseline can confirm what is visible in the packet list. It cannot support a complete account of the conversation yet.

Capture not opening correctly?

  • Confirm the downloaded filename is http.cap.
  • Return to your Downloads folder if Wireshark opened without the capture.
  • Open http.cap with Wireshark again.

Need a hand? Help me open and inspect http.cap in Wireshark without a display filter.

Document the baseline evidence

Evidence handling keeps direct observations separate from interpretation. A structured Markdown log makes that boundary clear to future reviewers.

  • Switch back to Visual Studio Code from earlier.
  • Create evidence.md inside the wireshark-http-investigation repository using the file sidebar.

You should see evidence.md next to the existing README.md file.

  • Build the baseline evidence log by copying this template into evidence.md:
# Evidence Log

## Source Metadata
- Capture filename: `http.cap`
- Official source page: https://wiki.wireshark.org/SampleCaptures

## Initial Observation
- Visible protocols: [[VISIBLE_PROTOCOLS="protocols you observed"]]
- Protocol details inspected: [[PROTOCOL_DETAILS="protocol layer you expanded"]]
- Packet-list observation: [[INITIAL_OBSERVATION="what the raw packet rows show"]]

## Baseline Limitation
The unfiltered packet list shows individual traffic rows across protocol layers. By itself, this view does not explain the complete HTTP exchange.

How is the log structured?

  • Source Metadata identifies the capture file. It also preserves the official source page.
  • Initial Observation records only the protocols and details you personally saw.
  • Baseline Limitation defines what the raw packet list cannot establish by itself.
  • Save evidence.md.

Before you preview the file, which parts do you expect Markdown to display as headings?

  • Preview evidence.md by pressing Ctrl+Shift+V.

Your preview should show Evidence Log as the title. It should also show Source Metadata, Initial Observation, and Baseline Limitation as separate sections.

Evidence preview not structured?

  • Confirm evidence.md is saved inside wireshark-http-investigation.
  • Check that the title starts with one # character.
  • Check that each section heading starts with two # characters.

Still seeing plain text? Help me fix the Markdown structure in evidence.md.

✔️ Awesome, I've got everything!

Your evidence.md now records the official source, your direct observations, and the limit of the unfiltered view.

ⓧ I'd like to double check the full code

Your complete evidence log should follow this structure.

# Evidence Log

## Source Metadata
- Capture filename: `http.cap`
- Official source page: https://wiki.wireshark.org/SampleCaptures

## Initial Observation
- Visible protocols: [[VISIBLE_PROTOCOLS="protocols you observed"]]
- Protocol details inspected: [[PROTOCOL_DETAILS="protocol layer you expanded"]]
- Packet-list observation: [[INITIAL_OBSERVATION="what the raw packet rows show"]]

## Baseline Limitation
The unfiltered packet list shows individual traffic rows across protocol layers. By itself, this view does not explain the complete HTTP exchange.

Before your final check, do you expect the raw capture to support a complete conclusion or a carefully bounded baseline?

  • Return to Wireshark from earlier.
  • Confirm the display filter toolbar remains empty.

You should still see the unfiltered traffic rows with source, destination, protocol, and information columns. Your rendered evidence.md should describe those observations without claiming to explain the complete exchange.

Strong start. Your first evidence artifact now separates direct observation from the limits of the raw view. Next, you'll isolate the request that matters and record its packet-level facts.

Isolate and Record the HTTP Request

Your unfiltered baseline showed the whole capture. The application event is still buried across packet rows.

A Wireshark display filter reduces that noise. In this step, you'll isolate the HTTP request before recording only what the packet proves.

In this step, get ready to:
  • Narrow the packet list with http.request.
  • Inspect the request across its protocol details.
  • Record directly observed fields in a Packet Evidence table.
Filter for the HTTP request

A display filter changes which packets Wireshark shows. The original capture remains unchanged.

Before you apply the filter, how many packet rows do you expect to remain visible?

  • Click the display filter toolbar at the top of Wireshark.
  • Enter http.request.
  • Press Enter to apply the filter.
  • Select the matching HTTP request packet.

You'll see the packet list narrow to the matching HTTP request. The display filter toolbar remains set to http.request.

No Request Packet Visible?

  • Re-enter http.request exactly if the packet list does not narrow.
  • Confirm that the local http.cap capture from earlier is still open if the packet list becomes empty.
  • Clear any extra text from the display filter toolbar if more than http.request appears there.

Still stuck? Help me troubleshoot my Wireshark HTTP request filter.

Inspect the packet details

The selected packet holds evidence across several protocol details. Each layer answers a different question about the request.

  • Expand the IP details in the packet details pane.
  • Expand the TCP details in the packet details pane.
  • Expand the HTTP details in the packet details pane.
  • Read the frame time from the selected packet's details.

What Does Each Layer Contribute?

IP identifies the network endpoints shown in the packet.

TCP identifies the transport endpoints through port numbers.

HTTP shows the application request sent to the server.

Careful evidence handling keeps observed facts separate from assumptions. If a field is unavailable, record Not present.

  • Record the visible frame time here: observed frame time or Not present.
  • Record the visible source address here: observed source address or Not present.
  • Record the visible destination address here: observed destination address or Not present.
  • Record the visible source port here: observed source port or Not present.
  • Record the visible destination port here: observed destination port or Not present.
  • Record the visible request method here: observed request method or Not present.
  • Record the visible host here: observed host or Not present.
  • Record the visible request target here: observed request target or Not present.

Good progress. Every required field now has an observed value or an explicit Not present entry.

Add the Packet Evidence table

The table keeps packet observations separate from their analytical purpose. This structure makes each recorded fact easier to verify.

  • In Visual Studio Code, select evidence.md from the repository file list in the left sidebar.
  • Place your cursor after the final paragraph in the existing Baseline Limitation section.
  • Insert the new section at that cursor by copying this Markdown:
## Packet Evidence

| Observed Field | Observed Value | Why It Matters |
| --- | --- | --- |
| Frame time | [[FRAME_TIME="observed frame time or Not present"]] | Places the request in the capture timeline. |
| Source address | [[SOURCE_ADDRESS="observed source address or Not present"]] | Identifies the sender shown in the packet. |
| Destination address | [[DESTINATION_ADDRESS="observed destination address or Not present"]] | Identifies the receiver shown in the packet. |
| Source port | [[SOURCE_PORT="observed source port or Not present"]] | Identifies the sender-side TCP endpoint. |
| Destination port | [[DESTINATION_PORT="observed destination port or Not present"]] | Identifies the receiver-side TCP endpoint. |
| Request method | [[REQUEST_METHOD="observed request method or Not present"]] | Shows the action requested from the server. |
| Host | [[HOST="observed host or Not present"]] | Identifies the requested host when visible. |
| Request target | [[REQUEST_TARGET="observed request target or Not present"]] | Identifies the requested resource when visible. |

How Does This Table Protect Evidence Quality?

  • The Observed Field column names the packet detail under review.
  • The Observed Value column contains only information visible in the selected packet.
  • The Why It Matters column connects each field to the investigation.
  • The Not present value preserves an evidence gap without guessing.
  • Save evidence.md.

Before you compare the two windows, do you expect every recorded value to be traceable to one visible packet field?

  • Return to Wireshark from earlier.
  • Confirm that the display filter toolbar still contains http.request.
  • Confirm that the matching HTTP request packet remains selected.
  • Compare every Observed Value cell against the expanded packet details.

You should be able to trace every filled value to the selected packet. Each unavailable field should read Not present.

Strong work. Your Packet Evidence table now records the HTTP request without unsupported claims.

Can't Trace a Table Value?

  • Recheck the matching protocol details if a recorded value does not match the selected packet.
  • Replace any uncertain value with Not present.
  • Compare the table row labels with the eight required fields if an entry is missing.

Need another pair of eyes? Help me check my Packet Evidence table against the selected HTTP request.

✔️ My Evidence Table Is Complete

Your evidence log now contains the original baseline sections plus a Packet Evidence table grounded in the filtered request.

ⓧ I'd Like to Double Check the Evidence Log

  • Confirm that evidence.md still contains the Source Metadata section.
  • Confirm that evidence.md still contains the Initial Observation section.
  • Confirm that evidence.md still contains the Baseline Limitation section.
  • Confirm that the Packet Evidence table has Observed Field, Observed Value, and Why It Matters columns.
  • Confirm that the table contains only values visible in the filtered request packet.
  • Confirm that every unavailable field uses Not present.

The filtered request is now documented as reproducible evidence. Next, you'll reconstruct the conversation so the server response can join the investigation.

Reconstruct the Conversation and Assess the Risk

Your Wireshark filter has isolated the HTTP request that matters. That packet shows what the client asked. It cannot show how the server answered.

A TCP stream reconstructs both sides of the exchange in network order. You can use that complete conversation to separate confirmed evidence from potential security risk.

In this step, get ready to:
  • Reconstruct the request and response through Follow TCP Stream.
  • Add the observed response facts and event sequence to evidence.md.
  • Create a rendered incident report that separates evidence from risk.
Follow the TCP stream

Follow TCP Stream gathers the selected connection into one ordered view. This reveals the server response that the request-only filter leaves out.

  • Click Analyze in Wireshark's menu bar.
  • Select Follow.
  • Select TCP Stream.

What does Follow TCP Stream show?

  • The dialog displays the stream in the same sequence that its content appeared on the network.
  • The request records what the client sent to the server.
  • The response records how the server answered that request.
  • Read the request from top to bottom.
  • Locate the response status line below the request.
  • Record the status here: your observed response status.
  • Identify the response headers that help describe the server's reply.
  • Record those headers here: your relevant observed response headers.

The stream now gives you enough evidence to describe the exchange as an ordered sequence. Keep each event limited to facts visible in the capture.

  • Summarize the client request here: your observed request event.
  • Summarize the server response here: your observed response event.
  • Dismiss the stream dialog.
  • Enter http.request in the display filter toolbar.
  • Press Enter to restore the request-only packet list.

You should see the matching HTTP request packet again. Your response evidence remains available in the values you recorded.

  • Switch back to evidence.md in Visual Studio Code.
  • Place your cursor on a blank line at the end of the file.
  • Append the response evidence and event sequence by copying this template:
## Response Evidence

| Observed Field | Observed Value | Why It Matters |
| --- | --- | --- |
| Response status | [[RESPONSE_STATUS="your observed response status"]] | Confirms how the server answered the request. |
| Relevant response headers | [[RESPONSE_HEADERS="your relevant observed response headers"]] | Records response metadata visible in the stream. |

## Event Sequence

1. [[REQUEST_EVENT="your observed request event"]]
2. [[RESPONSE_EVENT="your observed response event"]]

What does this evidence add?

  • The response table records only facts you observed in the stream.
  • The event sequence preserves the order of the client request and server response.
  • The reasons column explains why each fact supports the investigation.
  • Save evidence.md.
  • Press Ctrl+Shift+V to render its Markdown preview.

You should see a rendered Response Evidence table followed by a numbered Event Sequence. Every value should trace back to the stream you reviewed.

Does the evidence preview look broken?

  • Check that every table row starts and ends with a vertical bar.
  • Confirm that the separator row sits directly below the table headings.
  • Make sure both event lines start with a number followed by a full stop.

Still stuck? Help me fix the Response Evidence table and Event Sequence in my Markdown file.

Build the incident report

A useful incident report labels observations as confirmed facts. It describes risk separately so the reader can see where the evidence ends.

CWE-319 applies when sensitive or security-critical data is transmitted in cleartext. Your report recommends HTTPS with correctly implemented TLS while keeping claims about exposure or compromise unconfirmed.

  • Use the same file-creation method as before to create incident-report.md beside evidence.md.
  • Add the investigation summary and evidence sections by copying this first report chunk:
# Cleartext HTTP Traffic Investigation

## Executive Summary

This report documents a simulated review of the public `http.cap` training capture.
The capture confirms an HTTP request and response without encrypted transport.
Sensitive-data exposure and compromise are not confirmed by this sample.

## Scope

- Capture: `http.cap`.
- Source: Official Wireshark Sample Captures page.
- Review type: Simulated network investigation using public training evidence.

## Timeline

| Order | Observed Event |
| --- | --- |
| 1 | [[REQUEST_EVENT="your observed request event"]] |
| 2 | [[RESPONSE_EVENT="your observed response event"]] |

## Evidence

- Request event: [[REQUEST_EVENT="your observed request event"]].
- Response event: [[RESPONSE_EVENT="your observed response event"]].
- Response status: [[RESPONSE_STATUS="your observed response status"]].
- Relevant response headers: [[RESPONSE_HEADERS="your relevant observed response headers"]].
- Transport observation: The sample contains HTTP traffic without TLS protection.

How does this report stay evidence-based?

  • The Executive Summary states the confirmed transport finding.
  • The Scope identifies the public capture and simulated review.
  • The Timeline preserves the network order established through stream reconstruction.
  • The Evidence section reuses observations already recorded in evidence.md.
  • Save incident-report.md.
  • Press Ctrl+Shift+V to render the report preview.

You should see the report title followed by five rendered sections. The Timeline should appear as a two-row table.

Is the timeline showing as plain text?

  • Confirm that the separator row sits immediately below the Timeline headings.
  • Check that each Timeline row contains the same number of vertical bars.
  • Save incident-report.md before reopening the preview.

Need a second pair of eyes? Help me repair the Timeline table in my incident report.

The final sections convert the observed transport into a carefully scoped assessment. They also make the recommended control and its security benefits explicit.

  • Return to the editor for incident-report.md.
  • Place your cursor on a blank line after the Evidence section.
  • Complete the report by appending this assessment chunk:
## Assessment

Unencrypted HTTP is confirmed in this sample.
Sensitive-data exposure is not confirmed.
Compromise is not confirmed.
CWE-319 applies when sensitive or security-critical data is sent in cleartext.
The sample does not establish that either kind of data was present.

## Limitations

The analysis covers one public training capture.
The finding does not represent a real breach investigation.
The capture alone cannot establish user impact.

## Prioritized Recommendations

1. Replace HTTP with HTTPS.
2. Configure TLS to protect confidentiality.
3. Configure TLS to protect integrity.
4. Validate server authentication through the TLS implementation.
5. Capture a new test exchange to verify that application content no longer travels over HTTP.

Why is the assessment carefully scoped?

  • The Assessment confirms cleartext HTTP because the capture directly supports that finding.
  • The exposure and compromise statements remain unconfirmed because the sample does not prove either claim.
  • The CWE-319 statement describes the condition that makes cleartext transmission a security weakness.
  • The recommendations connect correctly implemented TLS to confidentiality, integrity, and server authentication.
  • Save incident-report.md.
  • Press Ctrl+Shift+V to render the completed report.

You should see all seven report sections as headings. The assessment should clearly separate the confirmed transport finding from the unconfirmed outcomes.

Are report sections missing from the preview?

  • Check that each required section begins with two hash characters followed by one space.
  • Confirm that the Assessment chunk sits after the Evidence section.
  • Remove any unfinished placeholder text before the final review.

Need help checking the structure? Help me find the missing section in my rendered incident report.

✔️ Awesome, I've got everything!

Great. Save incident-report.md and keep its rendered preview available for the final review.

ⓧ I'd like to double check the full report

# Cleartext HTTP Traffic Investigation

## Executive Summary

This report documents a simulated review of the public `http.cap` training capture.
The capture confirms an HTTP request and response without encrypted transport.
Sensitive-data exposure and compromise are not confirmed by this sample.

## Scope

- Capture: `http.cap`.
- Source: Official Wireshark Sample Captures page.
- Review type: Simulated network investigation using public training evidence.

## Timeline

| Order | Observed Event |
| --- | --- |
| 1 | [[REQUEST_EVENT="your observed request event"]] |
| 2 | [[RESPONSE_EVENT="your observed response event"]] |

## Evidence

- Request event: [[REQUEST_EVENT="your observed request event"]].
- Response event: [[RESPONSE_EVENT="your observed response event"]].
- Response status: [[RESPONSE_STATUS="your observed response status"]].
- Relevant response headers: [[RESPONSE_HEADERS="your relevant observed response headers"]].
- Transport observation: The sample contains HTTP traffic without TLS protection.

## Assessment

Unencrypted HTTP is confirmed in this sample.
Sensitive-data exposure is not confirmed.
Compromise is not confirmed.
CWE-319 applies when sensitive or security-critical data is sent in cleartext.
The sample does not establish that either kind of data was present.

## Limitations

The analysis covers one public training capture.
The finding does not represent a real breach investigation.
The capture alone cannot establish user impact.

## Prioritized Recommendations

1. Replace HTTP with HTTPS.
2. Configure TLS to protect confidentiality.
3. Configure TLS to protect integrity.
4. Validate server authentication through the TLS implementation.
5. Capture a new test exchange to verify that application content no longer travels over HTTP.
Review the rendered report

The rendered preview represents what a reviewer sees when opening the finished report. This final check catches broken structure and overclaimed conclusions before publication.

Before you check the preview, do you expect every section and table to render cleanly?

  • Return to incident-report.md in Visual Studio Code.
  • Press Ctrl+Shift+V to open the rendered preview.
  • Confirm that all seven required sections render as headings.
  • Confirm that the Timeline renders as a two-column table.
  • Confirm that the report identifies the review as simulated.
  • Confirm that the report labels cleartext HTTP as the observed finding.
  • Confirm that the report leaves sensitive-data exposure and compromise unconfirmed.
  • Correct any broken heading or table syntax in the editor.

You should see a readable report with rendered headings and a formatted Timeline table. Its conclusion should remain within the limits of the public training evidence.

Strong work. Your investigation now connects an ordered packet conversation to a defensible risk assessment.

Next, you'll publish the evidence and report as a recruiter-readable case study.

Publish the Recruiter-Ready Case Study

Your cleartext HTTP investigation now has a documented evidence trail. Its incident report separates confirmed observations from potential risk.

Analysis hidden on your computer cannot demonstrate your skills to a recruiter. In this step, you'll turn the local files into a public GitHub case study that a reviewer can understand from the front page.

In this step, get ready to:
  • Turn the initial README into a recruiter-facing case-study front page.
  • Commit the investigation files and push them to the public repository.
  • Check the public case study from a signed-out browser window.
Write the case-study front page

GitHub renders README.md on the repository front page. Clear Markdown lets a recruiter understand the scenario before opening the detailed reports.

  • Switch back to Visual Studio Code.
  • Select README.md in the Explorer sidebar.
  • Replace the initial README contents by copying the first part below:
# Wireshark HTTP Investigation

## Scenario

This case study documents a simulated security review of the public `http.cap` training capture. It demonstrates network analysis and incident reporting without claiming a real breach.

## Key Finding

The capture confirms an HTTP request and response transmitted without encryption. The sample does not confirm sensitive-data exposure or compromise.

## Tools

- Wireshark.
- Visual Studio Code.
- Git.
- GitHub.

## Investigation Workflow

1. Downloaded `http.cap` from [Wireshark Sample Captures](https://wiki.wireshark.org/SampleCaptures).
2. Stored the capture outside this repository.
3. Opened the capture without a display filter to establish a baseline.
4. Applied the `http.request` display filter to isolate the request.
5. Recorded only directly observed packet facts.
6. Used Follow TCP Stream to reconstruct the request and response.
7. Assessed the confirmed finding separately from its potential security risk.

What Does This Section Establish?

  • The scenario identifies the work as a simulated review of a public training capture.
  • The key finding separates confirmed cleartext transport from unconfirmed exposure or compromise.
  • The workflow gives another analyst a reproducible path through the investigation.
  • The tools section shows the practical environment used to complete the review.
  • Save README.md.
  • Press Ctrl+Shift+V to open the Markdown preview.

You should see the title plus the Scenario, Key Finding, Tools, and Investigation Workflow sections in the preview.

Good progress. The repository now explains the investigation before a recruiter opens either report.

Does the Preview Look Wrong?

  • Confirm that README.md is still selected in the Explorer sidebar.
  • Check that every heading starts with the same number of hash characters shown in the code block.
  • Keep one blank line around each heading if the sections appear as plain text.

Still stuck? Help me fix the Markdown preview for my Wireshark investigation README.

The second half turns the investigation into a navigable case study. It connects the summary to the evidence while preserving the report's careful limitation.

  • Place your cursor on a new blank line after the final workflow item.
  • Append the remaining README sections by copying the content below:
## Evidence and Report

- [Review the packet evidence](evidence.md).
- [Read the incident report](incident-report.md).

## Assessment

Unencrypted HTTP is confirmed in the training capture. Sensitive-data exposure and compromise are not confirmed.

CWE-319 applies when sensitive or security-critical data is transmitted in cleartext. HTTPS with correctly implemented TLS is recommended. Correctly implemented TLS can protect confidentiality. It can protect integrity. It can provide server authentication.

## Skills Demonstrated

- Packet capture analysis.
- HTTP request filtering.
- TCP stream reconstruction.
- Evidence handling.
- Event timeline construction.
- Risk assessment.
- Scoped incident reporting.
- Version-controlled documentation.

## Limitation

This is a simulated review of a public training capture. It does not claim a real breach.

What Does This Section Add?

  • The evidence links give the reviewer a direct route to the packet facts and completed report.
  • The assessment states the confirmed observation before discussing the conditional security risk.
  • The skills list translates the workflow into abilities a recruiter can recognize.
  • The limitation prevents the simulated review from being mistaken for a real incident claim.
  • Save README.md.
  • Press Ctrl+Shift+V to refresh the Markdown preview.

You should see the evidence links, assessment, skills list, and limitation below the investigation workflow.

That is the front page complete. A reviewer now has a clear route from your summary to the supporting evidence.

Are the Report Links Missing?

  • Confirm that the link destinations use the exact filenames evidence.md and incident-report.md.
  • Check that both report files remain beside README.md in the Explorer sidebar.
  • Add a blank line before the Evidence and Report heading if it joins the numbered workflow.

Need another pair of eyes? Help me check the links and structure in my case-study README.

✔️ Awesome, I've got everything!

Your rendered README.md should now present the scenario, finding, method, evidence links, assessment, skills, and limitation.

ⓧ I'd like to double check the full code

Compare your complete README.md with this reference:

# Wireshark HTTP Investigation

## Scenario

This case study documents a simulated security review of the public `http.cap` training capture. It demonstrates network analysis and incident reporting without claiming a real breach.

## Key Finding

The capture confirms an HTTP request and response transmitted without encryption. The sample does not confirm sensitive-data exposure or compromise.

## Tools

- Wireshark.
- Visual Studio Code.
- Git.
- GitHub.

## Investigation Workflow

1. Downloaded `http.cap` from [Wireshark Sample Captures](https://wiki.wireshark.org/SampleCaptures).
2. Stored the capture outside this repository.
3. Opened the capture without a display filter to establish a baseline.
4. Applied the `http.request` display filter to isolate the request.
5. Recorded only directly observed packet facts.
6. Used Follow TCP Stream to reconstruct the request and response.
7. Assessed the confirmed finding separately from its potential security risk.

## Evidence and Report

- [Review the packet evidence](evidence.md).
- [Read the incident report](incident-report.md).

## Assessment

Unencrypted HTTP is confirmed in the training capture. Sensitive-data exposure and compromise are not confirmed.

CWE-319 applies when sensitive or security-critical data is transmitted in cleartext. HTTPS with correctly implemented TLS is recommended. Correctly implemented TLS can protect confidentiality. It can protect integrity. It can provide server authentication.

## Skills Demonstrated

- Packet capture analysis.
- HTTP request filtering.
- TCP stream reconstruction.
- Evidence handling.
- Event timeline construction.
- Risk assessment.
- Scoped incident reporting.
- Version-controlled documentation.

## Limitation

This is a simulated review of a public training capture. It does not claim a real breach.
Commit and push the investigation

Git turns your three case-study files into an auditable snapshot. Checking the working tree first confirms exactly what the snapshot includes.

  • Use the menu bar in Visual Studio Code to open the integrated terminal.
  • Confirm that the terminal path ends with wireshark-http-investigation.
  • Review the repository changes by running:
git status

What Does This Check Show?

This check shows tracked changes plus new files in the working tree. It lets you review the publication set before creating the commit.

You should see README.md, evidence.md, and incident-report.md represented in the working-tree changes.

Does Git Miss the Repository?

  • Check whether the terminal path ends with wireshark-http-investigation.
  • Return to the repository window in Visual Studio Code if the terminal points elsewhere.
  • Open the integrated terminal from the correct repository window.

Still not seeing the files? Help me check why Git does not recognize my repository changes.

A commit creates a named snapshot of the investigation. Staging first selects the files that belong in that snapshot.

  • Stage the case-study files and create the snapshot by running these commands:
git add .
git commit -m "Add existing file"

What Do These Commands Do?

  • The first line stages every changed case-study file in the local repository.
  • The second line records the staged files in a commit named Add existing file.

Before you check the working tree, do you think any uncommitted case-study changes remain?

  • Check the local repository after the commit by running:
git status

What Does the Second Check Prove?

This check compares the saved commit with the files currently in your repository. A clean result confirms that the local snapshot contains your latest edits.

Git should report that no uncommitted changes remain.

Did the Commit Stop?

  • Follow the terminal guidance to configure Git author details if the commit stops before creating the snapshot.
  • Run the staging and commit commands again after correcting the author details.
  • Save README.md before repeating the commands if Git still shows it as modified.

Need help reading the result? Help me troubleshoot why my Git commit did not create a clean working tree.

A first push can trigger GitHub's authentication flow.

This credential check can feel sensitive. Keep every credential inside GitHub's own flow.

  • Publish the current branch to the existing remote by running:
git push --set-upstream origin HEAD

What Does This Push Do?

  • The push sends your local commit to the remote named origin.
  • The HEAD value identifies your current branch.
  • The --set-upstream option connects the local branch to its remote counterpart for future pushes.
  • Complete GitHub's authentication flow if it appears.

You should see progress output followed by confirmation that the current branch now tracks its remote counterpart.

That is the publishing hurdle cleared. Your complete investigation now exists in the public repository.

Did the Push Fail?

  • Complete the GitHub authentication flow if the terminal is waiting for authorization.
  • Check your internet connection if the remote cannot be reached.
  • Confirm that the repository still uses the existing origin remote if Git cannot find the destination.

Still blocked? Help me diagnose why my committed Wireshark case study will not push to origin.

Verify the public recruiter view

A signed-out check proves that public access does not depend on your account permissions. It also tests whether a reviewer can follow the result without opening Wireshark.

Before you test the public link, do you think the front page explains both the confirmed finding and the investigation's limitation?

  • Return to the GitHub repository page from earlier.
  • Copy the repository URL from your browser's address bar.
  • Store the copied address here: https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.
  • Open a private browser window that is not signed in to GitHub.
  • Paste https://github.com/YOUR-USERNAME/YOUR-REPOSITORY into the address bar.
  • Press Enter.

You should see the public repository front page with the rendered README.

The page should make the confirmed cleartext finding clear. It should also state the simulated-review limitation.

  • Use the rendered README to answer this question: What did the capture confirm?
  • Use the same README to answer this question: What did the capture fail to confirm?
  • Select Review the packet evidence.

You should see the published packet facts and ordered event sequence render correctly.

  • Return to the repository front page.
  • Select Read the incident report.

You should see the complete incident report render with all seven required sections.

What Does This Public Check Prove?

The signed-out view confirms that recruiters can access the repository without your account permissions. The rendered links also prove that the supporting artifacts traveled with the README.

A reviewer can now move from your conclusion to the evidence behind it. That traceable path makes the case study credible.

Your investigation is now public, reproducible, and recruiter-readable. The repository shows both your packet-analysis method and your judgment about what the evidence can support.

Secret mission

Compare a Gzip-Encoded HTTP Response

Apply your investigation workflow to the official `http_gzip.cap` capture. Publish `gzip-comparison.md` with the observed content-encoding value, three evidence-backed differences, and one limitation.

Clean Up Your Resources

Clean Up Your Resources

Your GitHub Free repository costs $0 USD per month. Decide whether to keep the case study live, archive it for later, or remove every artifact.

Resources you used:

  • Public GitHub repository named wireshark-http-investigation.
  • Local cloned folder named wireshark-http-investigation.
  • Local training capture named http.cap.
  • Local comparison capture named http_gzip.cap.

These options leave Wireshark installed for future packet analysis. They only manage the case study artifacts.

Keep everything running

No action needed. Choose this if you want recruiters to keep seeing your investigation.

  • Your public repository remains available as a portfolio case study.
  • Your local wireshark-http-investigation folder remains available for future edits.
  • Your http.cap capture remains available for more practice.
  • Your http_gzip.cap capture remains available for comparison work.

Pause - I'll come back to this later

Archiving makes the repository read-only until you unarchive it. Your published files remain visible.

  • Return to the public wireshark-http-investigation repository from earlier.
  • Select Settings.
  • Scroll to Danger Zone.
  • Select Archive this repository.
  • Select I understand the consequences, archive this repository.
  • Close the http_gzip.cap capture in the Wireshark window from earlier.
  • Close the Visual Studio Code window containing the cloned repository.

Your case study is safely paused. The repository is read-only while your local evidence remains available.

Delete - I don't want to use this again

Remove the public case study and local artifacts if you want to start fresh. GitHub asks you to acknowledge its warnings before deleting the repository.

  • Return to the public wireshark-http-investigation repository from earlier.
  • Select Settings.
  • Scroll to Danger Zone.
  • Select Delete this repository.
  • Acknowledge GitHub's warnings.
  • Enter wireshark-http-investigation when GitHub asks for the repository name.
  • Confirm the deletion.

You should no longer be able to access the repository from its previous public URL. This confirms that the remote case study is removed.

Your cloned folder and capture files remain on your Linux computer. Remove each local artifact separately so no evidence file is deleted by accident.

  • Use your Linux file manager to search for the wireshark-http-investigation folder.
  • Delete the matching cloned folder.
  • Search for http.cap.
  • Delete the local capture you analyzed.
  • Search for http_gzip.cap.
  • Delete the local comparison capture you analyzed.
  • Confirm that your searches no longer return the cloned folder or either capture.

That clears the complete local case study while leaving Wireshark ready for another investigation.

Nice Work!

Nice Work!

You did it! Your public GitHub case study now turns Wireshark packet evidence into a clear investigation that a recruiter can reproduce.

You've learned how to:

  • Published a recruiter-readable case study through Git. Made the full investigation publicly accessible from the wireshark-http-investigation repository on GitHub.
  • Applied the http.request display filter to isolate the HTTP request. Reconstructed the ordered conversation through a TCP stream.
  • Separated confirmed packet evidence from unconfirmed exposure or compromise in incident-report.md. Connected the conditional risk to CWE-319. Recommended HTTPS with correctly implemented TLS as the secure transport control.
  • Completed the optional Secret Mission by independently analyzing the gzip-encoded HTTP response in http_gzip.cap. Published gzip-comparison.md with at least three observed differences from http.cap plus one limitation.

Ready to quiz yourself?