Wireshark Simulator

# Lab: Social Engineering Awareness with SEToolkit — Expert Edition ## Simulated Engagement: Designing a Security Awareness Program for a Fictional Organization **Tool:** SEToolkit Simulator — Awareness Training (Practice Sandbox) **Level:** Expert — complete the Beginner and Intermediate labs first. This lab assumes fluent recall of all six categories and comfort classifying scenarios the tool never shows you directly. **Environment:** Fully offline, defensive training tool. No real emails are sent, no real websites are cloned, and no malware of any kind is created. **Time:** 2–3 hours (can be split across sessions — your saved project preserves your module review history) **Format:** You are not reviewing training content anymore. You are the person **designing** the training program for a real organization, using this tool's six categories as your raw material. --- ## The scenario You've been hired as the security awareness lead for a fictional mid-sized company, **Northfield Logistics** (120 employees, no in-house security team until now, one recent near-miss incident where an employee almost entered credentials on a fake login page before noticing the URL was wrong). Leadership has asked you for one thing: **a working awareness program, not a slideshow.** They don't want a list of six attack types read out loud once a year. They want something that actually changes behavior, gets measured, and gets reported on to the board. The SEToolkit Simulator's six categories are your **content foundation** — the raw material every real awareness program is built from. Your job in this lab is everything a real program needs *around* that content: audience segmentation, delivery strategy, measurement, incident response integration, and a report leadership will actually read. Nothing in this lab involves running anything against a real person or system. Every deliverable is a planning document. --- ## Learning objectives By the end of this lab you will be able to: 1. Translate static training content into an audience-aware program plan 2. Design a phishing-simulation testing approach in principle (not execution) and explain its ethical boundaries 3. Build a measurement framework for whether awareness training is actually working 4. Integrate awareness training with incident reporting and response, not treat them as separate 5. Correctly triage a real incident report against the six categories, including cases that don't cleanly fit any one of them 6. Handle the human factors of security awareness — blame culture, training fatigue, and executive buy-in — not just the technical content 7. Produce a program document that a non-technical executive sponsor could approve as-is --- ## Phase 0 — Program charter (write this first) Before touching the simulator, write a short **program charter**, as if this were a real approved initiative: - **Objective:** reduce successful social-engineering incidents at Northfield Logistics and increase the rate at which employees report suspicious activity (not just avoid clicking — actively report) - **Constraint:** you have a training budget for **one initial rollout plus one refresher per year** — this is not an unlimited-training-hours program, so every design decision below has to justify its cost in time and attention - **Existing signal:** one near-miss incident already occurred (the fake login page). Your program has to explicitly address why that happened and how it won't next time This charter is the document everything else in this lab has to be consistent with. If a later phase's decision contradicts it, that's a flag to revisit — not to ignore. ## Phase 1 — Full content audit Go through all six modules in the simulator one more time, but with a different lens than either previous lab: you're not learning the content now, you're **evaluating it as training material**. **Task:** For each module, rate (High/Medium/Low) how relevant it is specifically to Northfield Logistics employees, given what you know about the company (logistics, 120 employees, no security team, one recent website-related near-miss). Justify each rating in one sentence. Not every category deserves equal training time — an expert-level program prioritizes. ## Phase 2 — Audience segmentation A real awareness program doesn't train every employee identically. **Task:** Define **three employee segments** for Northfield Logistics (you decide what makes sense for a logistics company — e.g., warehouse/operations staff, office/administrative staff, and leadership/finance) and, for each segment: - Which 2–3 modules matter *most* for that group, and why - One module that's genuinely lower-priority for that specific group (not "skip everything else" — pick one real deprioritization and justify it) - The single most likely real-world attack vector that group would actually encounter, based on their day-to-day work **Why this matters:** Finance and leadership face different real risk (executive-targeted spear-phishing, wire-fraud-style social engineering) than warehouse staff (who might be far more likely to encounter Module 3's infectious-media scenario via a delivery-related USB drive, given the company's actual business). Generic, one-size-fits-all training is a well-documented reason real awareness programs fail to change behavior. ## Phase 3 — Delivery and cadence plan **Task:** Design the actual rollout, working within your Phase 0 budget constraint (one initial rollout + one annual refresher): - What order do the segments go through training in, and why that order specifically? - How long is a single training session realistically, given that this is not people's full-time job? - What happens for someone who **fails** a self-check or clearly didn't engage — is there a follow-up, and what does it look like? - How does the refresher differ from the initial rollout? (Hint: repeating the exact same content a year later is a common, low-effectiveness mistake — think about what should change.) ## Phase 4 — Phishing simulation design (planning only) Real awareness programs are often paired with **simulated phishing tests** — sending fake-but-harmless phishing emails to employees to measure real-world response, not just self-reported quiz scores. **Task:** This lab will not have you build or send an actual simulated phishing email — that requires real infrastructure, legal sign-off, and organizational authorization far beyond this tool's scope. Instead: - Describe, at a planning level, how you would structure a simulated phishing test that's **fair and ethical** — what makes a simulation instructive rather than a "gotcha" that damages trust in the security team? - What would you measure from a simulation like this (click rate? report rate? time-to-report?), and why is "report rate" arguably more important to track than "click rate" alone? - What's the single biggest way a badly-run phishing simulation can backfire on an organization's security culture? ## Phase 5 — Incident triage against ambiguous reports Northfield Logistics now has a reporting channel (built as part of your program). Employees have submitted the following four reports. **Triage each one**: primary category, confidence level (High/Medium/Low), and the specific next action a security lead should take. 1. *"A vendor I've worked with for two years emailed asking me to update their bank details for our next invoice payment. The email looked normal, but it came slightly later in the day than they usually email."* 2. *"I got a call from someone claiming to be from our IT helpdesk, asking me to install a 'remote support tool' so they could 'fix an issue with my account' before I'd even reported one."* 3. *"Someone in a delivery uniform asked to be let into our loading dock without a badge, saying their badge reader 'wasn't working today.'"* 4. *"An employee said a friend on social media sent them a link to a 'free logistics industry salary report' that asked them to log in with their work email to view it."* **Task:** For at least one of these four, explain why it does **not** map cleanly onto any single one of the tool's six modules, and what that tells you about the limits of a fixed six-category framework when applied to real, messy incident reports. (Note: report #3 is a physical social-engineering technique — **tailgating/piggybacking** — that isn't one of the tool's six categories at all. Recognizing that gap is itself part of the expert-level skill being tested here.) ## Phase 6 — Metrics and measurement framework Leadership explicitly asked how they'll know this program is working. **Task:** Design a simple measurement framework with **no more than 5 metrics** (more than that, and leadership won't actually read the dashboard). For each metric: - What it measures - Why it's a meaningful signal of real behavior change, not just training completion - One way this specific metric could be gamed or misleading if read in isolation (every metric can be — a mature program plans for that) Example of the *kind* of metric to include (write your own full set — don't just copy this): "percentage of employees who report a simulated phishing email within 24 hours" is a stronger signal than "percentage of employees who completed the training module," because completion doesn't prove retention or behavior change. ## Phase 7 — Culture and human factors **Task:** Answer directly, in 6–8 sentences total: - Northfield's one existing near-miss incident involved an employee who *almost* fell for a fake login page but caught it. How should your program treat that person — and how you treat them sends a signal to everyone else. What's the right response, and why does it matter for future reporting rates? - What's the risk of a security-awareness program that feels punitive (blame-focused) versus one that feels supportive (report-focused)? Which failure mode is more common in real organizations, in your understanding, and why? - Executive/leadership buy-in was mentioned in the scenario. What's one thing you'd specifically ask leadership to do *themselves* (not just approve budget for), to make the program credible to everyone else in the company? --- ## Deliverable: Program Proposal for Leadership Compile everything into a document structured the way a real proposal to executive leadership would be — this is the actual test of the "expert" level. ### 1. Executive Summary (4–6 sentences, no jargon) What the program is, why it's needed now (reference the near-miss without assigning blame to the individual), and the expected outcome. ### 2. Program Charter Your Phase 0 write-up, cleaned up. ### 3. Audience & Content Strategy Your Phase 1 content audit and Phase 2 segmentation, presented as a short table plus explanation. ### 4. Delivery Plan Your Phase 3 rollout and cadence design. ### 5. Testing & Measurement Your Phase 4 simulation design and Phase 6 metrics framework, combined into one section. ### 6. Incident Triage Process Your Phase 5 methodology, using at least one of the four sample reports as a worked example — including the tailgating gap you identified. ### 7. Culture Statement Your Phase 7 answers, reframed as a short statement of how the program will be run, suitable for leadership to read aloud or reference when talking to employees. ### 8. Limitations & Next Steps What this program, as designed, does **not** cover (e.g., physical social engineering beyond what your triage process catches, technical controls like email filtering, multi-factor authentication) — and what you'd propose adding in year two, once budget allows for more than one rollout and one refresher. --- ### Grading rubric | Criteria | What "expert level" looks like | |---|---| | Prioritization under constraint | Phase 1 and Phase 3 make real trade-offs justified by the Phase 0 budget constraint, not "train everyone on everything equally" | | Audience awareness | Phase 2 segments are genuinely differentiated, with real reasoning tied to job function, not generic labels | | Ethical grounding | Phase 4 correctly identifies that live phishing simulation requires real authorization and explains fairness/trust considerations, without attempting to actually design deliverable phishing content | | Handles gaps in the framework | Phase 5 correctly identifies that report #3 (tailgating) falls outside the tool's six categories, and reasons about what that means rather than forcing a bad-fit classification | | Measurement is meaningful, not just measurable | Phase 6 metrics are tied to real behavior change and each includes a stated gaming/misreading risk | | Human factors taken seriously | Phase 7 treats the near-miss employee's reporting as something to reinforce positively, and explains the blame-vs-support trade-off correctly | | Executive-appropriate writing | Executive Summary and Culture Statement are genuinely non-technical and could be read aloud to leadership as-is | --- ## Common mistakes at this level - **Designing a program that's really just "everyone watches all six modules once."** That's the Beginner lab, not a program. Segmentation and prioritization are the actual expert-level skill being tested. - **Forcing report #3 (tailgating) into one of the six categories anyway.** The correct expert-level answer is recognizing the tool's framework has a real gap here, not stretching "infectious media" or another category to cover a physical-access scenario that doesn't fit. - **Designing a phishing simulation as if you were actually going to build and send it.** This lab explicitly stops at planning-level design — actually generating deliverable phishing content is out of scope, both for this lab and generally something requiring real organizational authorization. - **A metrics section that only measures training completion.** Completion rate is the easiest metric to collect and the weakest signal of real change — an expert-level framework goes further. - **Treating the near-miss employee as a cautionary tale in your Culture Statement.** How this lab's fictional program treats that one employee is a direct test of whether you understood Phase 7. Punitive framing is the wrong answer, even implicitly. - **An Executive Summary full of the same terminology as your Technical sections.** If a term needs `Module 1` or `spear-phishing` to explain it, it belongs later in the document, not in the summary. ## Glossary (expert terms used in this lab) - **Awareness program** — an organized, ongoing effort to build employee recognition of and response to security threats, as opposed to a single one-time training - **Phishing simulation** — an authorized, controlled test where an organization sends realistic-but-harmless phishing content to its own employees to measure real response, not just quiz performance - **Report rate** — the percentage of people who correctly report a suspicious message or simulation, as distinct from click rate (who fell for it) - **Tailgating / piggybacking** — a physical social-engineering technique where an attacker gains unauthorized physical access by following an authorized person through a secured entry point - **Training fatigue** — the drop in engagement and retention that happens when security training is repetitive, generic, or perceived as a compliance checkbox rather than genuinely useful - **Blame culture vs. reporting culture** — the organizational contrast between punishing mistakes (which suppresses future reporting) and rewarding early reporting (which surfaces real incidents faster) --- ## Submit your work Click **💾 Save My Training Notes as a Project** inside the simulator to preserve your content-audit review history, then attach your full 8-section Program Proposal (Executive Summary through Limitations & Next Steps) as a separate write-up. Title the saved project `"Social Engineering Awareness — Expert Program Design"`. ## Stretch goals (optional, for going beyond the lab) 1. Draft a single follow-up slide or one-pager specifically for the employee who almost fell for the near-miss incident — not a correction, but genuine positive reinforcement for catching it and reporting it. What tone does this need that's different from your general Culture Statement? 2. Revisit your Phase 6 metrics framework and ask: which single metric, if it were the *only* one leadership looked at, would give the most misleading picture of program success? Explain why, and what you'd pair it with to correct for that. 3. Report #3 in Phase 5 exposed a real gap in the six-category framework (physical social engineering / tailgating). Sketch, in a few sentences, what a **seventh module** for this simulator might look like if the tool were ever expanded — matching the existing structure (description, example, defenses) — without actually writing the full content.

# Lab: Reading Packet Captures with Wireshark Simulator (Intermediate) — Expanded Edition **Tool:** Wireshark Simulator (Practice Sandbox) **Level:** Intermediate — complete the Beginner lab first. This lab assumes you can already read a packet list, click into layers, and write single-condition filters like `http` or `tcp.port==443` without help. **Environment:** Fully offline, synthetic packet capture. **Time:** 75–90 minutes **Format:** 7 parts — combined filters, negation, and following a full conversation end-to-end, then a written investigation summary. --- ## What's different at this level The Beginner lab taught you to filter for one thing at a time and read one packet at a time. Real analysts rarely work that way — a real capture is too large to read packet-by-packet, and a single-condition filter is rarely precise enough to isolate what actually matters. This lab is about **combining** filters to ask more precise questions, and about following one conversation across multiple packets instead of treating each packet as its own isolated event. Open the simulator and keep the filter bar and packet list both visible throughout — you'll be iterating on filters, not just applying one and stopping. ## Learning objectives By the end of this lab you will be able to: 1. Combine two or more filter conditions using logical operators (`&&`) 2. Use negation filters (`!`) to remove noise instead of only ever narrowing toward a target 3. Follow a single conversation's packets from first packet to last, in order, and narrate what's happening at each stage 4. Distinguish a full TCP conversation's phases (setup, data transfer, teardown) as separate, recognizable stages 5. Filter for a specific flag or status value, not just a protocol or port 6. Build filters incrementally — broad, then narrower, then narrower again — instead of trying to write the "perfect" filter from scratch --- ## Part 1 — Warm-up: rebuild your basics without hints Before combining anything, prove to yourself you still remember the fundamentals. **Task:** From memory, write the filter syntax for: - All HTTP traffic - All traffic on port 443 - All UDP traffic Then apply each one and confirm you got the syntax right. If you got any of these wrong, that's worth noting honestly before moving on — this lab builds directly on top of them. ## Part 2 — Combine two conditions Try a combined filter: ``` tcp.port==443 && ip.addr== ``` Replace the address with one you actually noticed earlier in this capture (from the Beginner lab or your Part 1 warm-up). **Task:** - How many packets does the combined filter return, compared to `tcp.port==443` alone? - In your own words, explain what `&&` is doing here — is it widening the results or narrowing them? - Try swapping the address for a different one you saw in the capture. Does the result change the way you'd expect? **Why this matters:** A single-condition filter usually gives you a starting point, not an answer. Real investigative work is almost always a combination — "this port, and this specific host" — not one or the other alone. ## Part 3 — Filter out the noise with negation Try: ``` !arp ``` then ``` !dns ``` **Task:** Compare the list before and after each negation filter. Which protocol, when hidden, made the biggest visible difference to how easy the list was to scan? Why do you think that particular protocol tends to generate a lot of routine "background noise" traffic in a real network, even when nothing suspicious is happening? **Guided question:** Negation filters are a mindset shift from everything you did in the Beginner lab. Instead of asking "show me what I'm looking for," you're asking "hide what I already know isn't relevant." Why is that second approach sometimes more efficient when you don't yet know exactly what you're looking for? ## Part 4 — Pick a conversation and follow it Go back to your unfiltered (or lightly filtered) view and pick one packet that looks like part of a larger back-and-forth conversation between the same two addresses. **Task:** Using a combined filter (an address, and possibly a port), isolate every packet belonging to that one conversation — from its very first packet to its last, in time order. - List the packets in order. - For each one, write a one-sentence narration of what's happening — not the raw technical field, but the plain-English translation of it. - Identify where the conversation begins (setup), where the actual data exchange happens, and where it ends (teardown), if all three phases are visible in this capture. **Why this matters:** A single packet, out of context, tells you very little. The *sequence* is where the actual story is — this is the core skill that separates "I can read one row of a table" from "I can reconstruct what actually happened." ## Part 5 — Filter for a specific flag or status If this capture includes any packet with a distinct flag or status value (for example, something indicating a failed request, an error response, or a specific TCP flag), try filtering directly for it. **Task:** - Write the filter you used. - How many packets does it return, and how does that compare to how long it would have taken to find the same packets by scrolling manually? - Pick one of the returned packets and explain, using its layer detail, exactly what that flag or status actually means in context — not just that it exists. **Why this matters:** This is where filters stop being a convenience and start being the primary way real analysts work. On a large capture, scrolling to find a single error response by eye simply isn't realistic — targeted filtering is the actual job. ## Part 6 — Repeat without hints Pick a **second** suspicious-looking flow — different from the one you followed in Part 4 — and repeat the same process: isolate it with a combined filter, list the packets in order, narrate each one, and identify setup/data/teardown phases if present. **Task:** Do this one with less scaffolding than Part 4 — don't re-read the instructions above while you work through it. Afterward, write one sentence comparing how much faster or slower this second pass felt compared to the first, and why. ## Part 7 — Build incrementally, on purpose **Task:** Pick any one thing in this capture you haven't investigated yet, and deliberately build your filter in three visible steps rather than jumping straight to the final version: 1. Start broad — a single protocol or port 2. Narrow — add a host or address 3. Narrow again — add a flag, status, or second condition if relevant Write down all three filter versions, not just the final one, and one sentence on what each step removed from the list. **Why this matters:** Writing the "perfect" filter from scratch, first try, is rarely how it actually happens in practice — even experienced analysts build filters incrementally, watching the result shrink at each step to confirm they're narrowing toward the right thing rather than accidentally filtering out something relevant. --- ## Deliverable: Filtering & Conversation Notes Compile a short write-up with: 1. **Your Part 2 and Part 3 filter syntax**, with one sentence each on what it does 2. **Your two full conversation narrations** (Parts 4 and 6), in order, phase-labeled where visible 3. **Your Part 5 flag/status finding**, with the filter and explanation 4. **Your Part 7 incremental build**, showing all three steps --- ## Common mistakes at this level - **Treating `&&` as "or" instead of "and."** A combined filter narrows results — if your combined filter is returning *more* packets than either condition alone, something's wrong with how you wrote it. - **Following a conversation out of time order.** The narration in Part 4/6 only makes sense as a sequence — jumping around defeats the purpose. - **Jumping straight to the "final" filter and skipping Part 7's incremental steps.** The skill being built here is the *process* of narrowing, not just landing on a working filter by trial and error. - **Narrating packets in technical field-names instead of plain English.** "This is the ACK packet" is not the same skill as "this confirms the previous packet was received" — Part 4 and 6 are testing the second one. ## Glossary (new terms at this level) - **Logical AND (`&&`)** — combines two filter conditions so only packets matching *both* are shown - **Negation filter (`!`)** — excludes packets matching a condition, used to remove known-routine noise rather than search for something specific - **Conversation / flow** — the full sequence of packets exchanged between the same two endpoints for a single interaction, from start to finish - **Setup / data transfer / teardown** — the three general phases of a connection-oriented conversation: establishing the connection, exchanging the actual data, and closing the connection cleanly --- ## Submit your work Save your session with a short note on what you filtered for and why, before closing the simulator. Title it `"Wireshark Intermediate Lab — Filters & Conversations"`, and attach your full Deliverable write-up alongside the saved session. ## Stretch goals (optional) 1. Take your Part 4 conversation narration and rewrite it as if explaining it to someone who has never seen a packet capture — no field names, no jargon, just "first this happened, then this." 2. Go back to Part 3's negation filters and combine **two** of them at once (e.g. `!arp && !dns`). How much cleaner is the resulting list, and is there a point where removing more noise stops helping and starts hiding things you'd actually want to see? 3. Without re-reading this lab, try to explain from memory why analysts build filters incrementally (broad → narrow → narrower) instead of writing the final filter on the first try. If you can't explain it confidently, Part 7 is worth repeating before moving to the expert lab.

# Lab: Reading Packet Captures with Wireshark Simulator (Intermediate) — Expanded Edition **Tool:** Wireshark Simulator (Practice Sandbox) **Level:** Intermediate — complete the Beginner lab first. This lab assumes you can already read a packet list, click into layers, and write single-condition filters like `http` or `tcp.port==443` without help. **Environment:** Fully offline, synthetic packet capture. **Time:** 75–90 minutes **Format:** 7 parts — combined filters, negation, and following a full conversation end-to-end, then a written investigation summary. --- ## What's different at this level The Beginner lab taught you to filter for one thing at a time and read one packet at a time. Real analysts rarely work that way — a real capture is too large to read packet-by-packet, and a single-condition filter is rarely precise enough to isolate what actually matters. This lab is about **combining** filters to ask more precise questions, and about following one conversation across multiple packets instead of treating each packet as its own isolated event. Open the simulator and keep the filter bar and packet list both visible throughout — you'll be iterating on filters, not just applying one and stopping. ## Learning objectives By the end of this lab you will be able to: 1. Combine two or more filter conditions using logical operators (`&&`) 2. Use negation filters (`!`) to remove noise instead of only ever narrowing toward a target 3. Follow a single conversation's packets from first packet to last, in order, and narrate what's happening at each stage 4. Distinguish a full TCP conversation's phases (setup, data transfer, teardown) as separate, recognizable stages 5. Filter for a specific flag or status value, not just a protocol or port 6. Build filters incrementally — broad, then narrower, then narrower again — instead of trying to write the "perfect" filter from scratch --- ## Part 1 — Warm-up: rebuild your basics without hints Before combining anything, prove to yourself you still remember the fundamentals. **Task:** From memory, write the filter syntax for: - All HTTP traffic - All traffic on port 443 - All UDP traffic Then apply each one and confirm you got the syntax right. If you got any of these wrong, that's worth noting honestly before moving on — this lab builds directly on top of them. ## Part 2 — Combine two conditions Try a combined filter: ``` tcp.port==443 && ip.addr== ``` Replace the address with one you actually noticed earlier in this capture (from the Beginner lab or your Part 1 warm-up). **Task:** - How many packets does the combined filter return, compared to `tcp.port==443` alone? - In your own words, explain what `&&` is doing here — is it widening the results or narrowing them? - Try swapping the address for a different one you saw in the capture. Does the result change the way you'd expect? **Why this matters:** A single-condition filter usually gives you a starting point, not an answer. Real investigative work is almost always a combination — "this port, and this specific host" — not one or the other alone. ## Part 3 — Filter out the noise with negation Try: ``` !arp ``` then ``` !dns ``` **Task:** Compare the list before and after each negation filter. Which protocol, when hidden, made the biggest visible difference to how easy the list was to scan? Why do you think that particular protocol tends to generate a lot of routine "background noise" traffic in a real network, even when nothing suspicious is happening? **Guided question:** Negation filters are a mindset shift from everything you did in the Beginner lab. Instead of asking "show me what I'm looking for," you're asking "hide what I already know isn't relevant." Why is that second approach sometimes more efficient when you don't yet know exactly what you're looking for? ## Part 4 — Pick a conversation and follow it Go back to your unfiltered (or lightly filtered) view and pick one packet that looks like part of a larger back-and-forth conversation between the same two addresses. **Task:** Using a combined filter (an address, and possibly a port), isolate every packet belonging to that one conversation — from its very first packet to its last, in time order. - List the packets in order. - For each one, write a one-sentence narration of what's happening — not the raw technical field, but the plain-English translation of it. - Identify where the conversation begins (setup), where the actual data exchange happens, and where it ends (teardown), if all three phases are visible in this capture. **Why this matters:** A single packet, out of context, tells you very little. The *sequence* is where the actual story is — this is the core skill that separates "I can read one row of a table" from "I can reconstruct what actually happened." ## Part 5 — Filter for a specific flag or status If this capture includes any packet with a distinct flag or status value (for example, something indicating a failed request, an error response, or a specific TCP flag), try filtering directly for it. **Task:** - Write the filter you used. - How many packets does it return, and how does that compare to how long it would have taken to find the same packets by scrolling manually? - Pick one of the returned packets and explain, using its layer detail, exactly what that flag or status actually means in context — not just that it exists. **Why this matters:** This is where filters stop being a convenience and start being the primary way real analysts work. On a large capture, scrolling to find a single error response by eye simply isn't realistic — targeted filtering is the actual job. ## Part 6 — Repeat without hints Pick a **second** suspicious-looking flow — different from the one you followed in Part 4 — and repeat the same process: isolate it with a combined filter, list the packets in order, narrate each one, and identify setup/data/teardown phases if present. **Task:** Do this one with less scaffolding than Part 4 — don't re-read the instructions above while you work through it. Afterward, write one sentence comparing how much faster or slower this second pass felt compared to the first, and why. ## Part 7 — Build incrementally, on purpose **Task:** Pick any one thing in this capture you haven't investigated yet, and deliberately build your filter in three visible steps rather than jumping straight to the final version: 1. Start broad — a single protocol or port 2. Narrow — add a host or address 3. Narrow again — add a flag, status, or second condition if relevant Write down all three filter versions, not just the final one, and one sentence on what each step removed from the list. **Why this matters:** Writing the "perfect" filter from scratch, first try, is rarely how it actually happens in practice — even experienced analysts build filters incrementally, watching the result shrink at each step to confirm they're narrowing toward the right thing rather than accidentally filtering out something relevant. --- ## Deliverable: Filtering & Conversation Notes Compile a short write-up with: 1. **Your Part 2 and Part 3 filter syntax**, with one sentence each on what it does 2. **Your two full conversation narrations** (Parts 4 and 6), in order, phase-labeled where visible 3. **Your Part 5 flag/status finding**, with the filter and explanation 4. **Your Part 7 incremental build**, showing all three steps --- ## Common mistakes at this level - **Treating `&&` as "or" instead of "and."** A combined filter narrows results — if your combined filter is returning *more* packets than either condition alone, something's wrong with how you wrote it. - **Following a conversation out of time order.** The narration in Part 4/6 only makes sense as a sequence — jumping around defeats the purpose. - **Jumping straight to the "final" filter and skipping Part 7's incremental steps.** The skill being built here is the *process* of narrowing, not just landing on a working filter by trial and error. - **Narrating packets in technical field-names instead of plain English.** "This is the ACK packet" is not the same skill as "this confirms the previous packet was received" — Part 4 and 6 are testing the second one. ## Glossary (new terms at this level) - **Logical AND (`&&`)** — combines two filter conditions so only packets matching *both* are shown - **Negation filter (`!`)** — excludes packets matching a condition, used to remove known-routine noise rather than search for something specific - **Conversation / flow** — the full sequence of packets exchanged between the same two endpoints for a single interaction, from start to finish - **Setup / data transfer / teardown** — the three general phases of a connection-oriented conversation: establishing the connection, exchanging the actual data, and closing the connection cleanly --- ## Submit your work Save your session with a short note on what you filtered for and why, before closing the simulator. Title it `"Wireshark Intermediate Lab — Filters & Conversations"`, and attach your full Deliverable write-up alongside the saved session. ## Stretch goals (optional) 1. Take your Part 4 conversation narration and rewrite it as if explaining it to someone who has never seen a packet capture — no field names, no jargon, just "first this happened, then this." 2. Go back to Part 3's negation filters and combine **two** of them at once (e.g. `!arp && !dns`). How much cleaner is the resulting list, and is there a point where removing more noise stops helping and starts hiding things you'd actually want to see? 3. Without re-reading this lab, try to explain from memory why analysts build filters incrementally (broad → narrow → narrower) instead of writing the final filter on the first try. If you can't explain it confidently, Part 7 is worth repeating before moving to the expert lab.