Exercises › Module 08
Packet Trail
An AI-assisted exercise on sniffing, Layer 2 attacks, Intrusion Detection System (IDS) alerts, and firewall evasion, ending in an honest incident report. Suggested time: about 40 minutes.
Goal
Use an AI assistant to generate a fictional network incident case file (notes from a junior analyst, an evidence appendix with a packet capture summary, IDS alerts, and firewall rules, and a draft incident report), then turn it into a report ready for the client. You review documents, not networks: no packets are captured, no traffic is sent, and no tools are run. Your real job is to catch what the draft report got wrong before it ships.
Safety rules
- Everything is fictional: client Harborline Freight Co., security provider Copperleaf Security, suspect workstation WS-DOCK-14.
- Use only
.exampledomains and documentation IP ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). - No attack commands, exploit code, tunneling tools, or live targeting. Hands-on sniffing, evasion, and wireless practice belongs only in the course iLabs.
- Never paste real packet captures, IP addresses, firewall configs, or client data into any AI tool.
1 Generate the case file
Paste this into your AI assistant. It builds three fictional documents. Save the output before moving on.
You are helping me build a fictional training case for an ethical hacking class. Everything must be invented. Do not output exploit code, attack commands, working scripts, real credentials, or real malware. The client is 'Harborline Freight Co.', a fictional shipping and logistics company. The analysts are 'Copperleaf Security', a fictional managed security provider. The office LAN is 192.0.2.0/24 (gateway 192.0.2.1, MAC 00:1A:2B:00:00:01). The suspect workstation is WS-DOCK-14 at 192.0.2.66 (MAC 00:1A:2B:3C:4D:66). External hosts use only 198.51.100.x and 203.0.113.x and .example domains. No real companies, people, or live targets. Create a network incident case file with three documents: Document A, Junior Analyst Notes: confident first-person notes claiming (1) the switch suffered a MAC flooding (CAM table exhaustion) attack starting at 02:14; (2) the Intrusion Detection System (IDS) alert 'Possible DNS tunneling' for host 192.0.2.66 is a false positive caused by a cloud backup agent; (3) the perimeter firewall blocked all outbound Secure Shell (SSH), so nothing left the network. Document B, Evidence Appendix with three parts: B1, Packet capture summary (a table, not raw packets): starting at 01:52, repeated unsolicited ARP replies saying 192.0.2.1 is at 00:1A:2B:3C:4D:66, sent to several hosts; the switch CAM table shows a normal number of entries (about 40) with no flood of random MAC addresses; afterward, traffic from other hosts to the gateway flows through 00:1A:2B:3C:4D:66. B2, IDS alert log: from 02:20 to 04:05, about 3,800 DNS TXT queries from 192.0.2.66 to long random-looking subdomains of sync.cdn-update.example, each label about 60 characters, all sent to resolver 203.0.113.53 instead of the internal resolver 192.0.2.10. Include one line showing the real backup agent uses HTTPS to backup.harborline.example only. B3, Firewall rule excerpt in rule-number order: rule 10 allow TCP 443 any to any; rule 15 allow TCP 22 from 192.0.2.0/24 to 198.51.100.77, comment 'TEMP vendor access - remove after Q2 project'; rule 20 allow UDP 53 any to any; rule 40 deny TCP 22 any to any; rule 99 deny all. Plus a session log line: 192.0.2.66 to 198.51.100.77 port 22, matched rule 15, duration 9 hours 12 minutes, 1.8 GB sent outbound. Document C, Draft Incident Report: a one-page report for the Harborline IT Director with title, severity (Medium), timeline starting at 02:14, technical summary that trusts Document A, evidence bullets, and remediation. The remediation must say: 'Enable port security with a maximum of 2 MAC addresses on each switch port and tune the IDS to suppress DNS tunneling alerts from backup traffic.' It must omit Dynamic ARP Inspection (DAI), DHCP snooping, forcing DNS through the internal resolver, and removing firewall rule 15. IMPORTANT: do not label, flag, or hint at these anywhere, and write them as normal details: - Documents A/C call it MAC flooding; B1 shows ARP poisoning of the gateway with a normal CAM table. - Documents A/C call the DNS alert a false positive; B2 shows a true positive (DNS tunneling to an outside resolver), and the backup agent does not use DNS this way. - Documents A/C say outbound SSH was blocked; B3 shows rule 15 is above the deny rule and allowed a 9-hour SSH session with 1.8 GB out. - Document C's timeline starts at 02:14, but B1 starts at 01:52. - Document C's remediation relies on port security and suppressing the alert. - Everything else should read as a plausible (but flawed) junior write-up.
Tip: if the AI labels or flags any planted problem, ask it to regenerate without flags, or swap case files with a partner.
2 Have AI write the client-ready report
Ask the AI to turn the case file into an incident report for the client.
Act as a senior incident responder at Copperleaf Security. Using only Documents A, B, and C, write a client-ready incident report for the Harborline Freight Co. IT Director with these sections: 1) Title and severity. 2) Affected hosts, IP addresses, and network segments. 3) Timeline of events (with the source document for each time). 4) Technical summary of each attack technique in plain language, mapped to the Module 08 topic (sniffing, Layer 2 attack, IDS alert type, firewall evasion). No attack commands. 5) Evidence table: claim, source document, and confidence. 6) Business impact in two sentences. 7) Remediation recommendations (network, firewall, and monitoring). Then rate your confidence in the overall report (High, Medium, or Low) and explain why.
Watch the Layer 2 diagnosis, the IDS alert classification, the firewall claim, the timeline, and the remediation. The AI tends to trust the junior notes and the draft report.
3 Review it yourself, then fix it
Do this review yourself before you trust the AI's report:
- MAC flooding fills the CAM (Content Addressable Memory) table with random addresses. What does B1 show about the CAM table and the ARP (Address Resolution Protocol) replies? Which attack is it really?
- Look at the DNS (Domain Name System) alert: query count, label length, record type, and which resolver was used. Does the backup agent explain it? Is it a false positive or a true positive?
- Read the firewall rules in order. Firewalls use the first match. Which rule did the SSH session match, and what does 'TEMP' tell you?
- Compare the report's timeline with the first event in the appendix. Do they agree?
- Read the remediation. Does port security stop ARP poisoning? What happens if you suppress the alert?
- Stretch goal: for each problem, name the Module 08 countermeasure that covers it.
Then fill in the brackets and run:
Revise the Harborline Freight Co. incident report: 1) The Layer 2 attack is not MAC flooding. B1 shows [what the ARP replies claimed] and [what the CAM table looked like]. Rewrite it as ARP poisoning that put WS-DOCK-14 on-path between hosts and the gateway. 2) The DNS tunneling alert is a [correct IDS alert type], not a false positive, because [query volume, label length, and outside resolver]. Fix it everywhere. 3) Outbound SSH was not blocked. B3 shows [which rule matched and why rule order mattered], plus [session duration and data sent]. Describe this as firewall evasion through a tunnel over an allowed path. 4) Correct the timeline start to [first evidence time] and explain why the first event matters. 5) Replace the remediation with: enable Dynamic ARP Inspection (DAI) and DHCP snooping; force all DNS through the internal resolver and block outbound DNS to other servers; remove expired rule 15 and review rule order; alert on long-lived outbound sessions; isolate and investigate WS-DOCK-14. Port security may stay as defense in depth only; do not suppress the alert. 6) Raise the severity if needed, update the confidence rating, and explain what changed.
Re-read the revision. The AI sometimes fixes the evidence table but leaves 'MAC flooding' or 'false positive' in the summary.
Review checklist
- Layer 2 attack re-labeled as ARP poisoning of the gateway (192.0.2.1 claimed by WS-DOCK-14's MAC); CAM table was normal, so not MAC flooding.
- DNS tunneling alert re-classified as a true positive: about 3,800 long TXT queries to an outside resolver, unrelated to the HTTPS-only backup agent.
- Firewall claim corrected: rule 15 (expired vendor exception) sits above deny rule 40 and allowed a 9-hour SSH session with 1.8 GB sent out.
- Timeline starts at 01:52, the first ARP poisoning evidence.
- Remediation includes DAI, DHCP snooping, internal-only DNS with outbound DNS blocked, removing rule 15, and alerting on long outbound sessions; port security only as defense in depth.
- Accurate parts (rule 40 does deny SSH in general; the backup agent is legitimate) are kept, not 'fixed' unnecessarily.
Deliverables
- Corrected incident report
- Evidence table (claim, source, confidence)
- Corrected timeline and updated confidence rating
- Five sentences: each problem, why it matters, and the Module 08 control that catches it
Grading rubric (10 pts)
| Criterion | Pts |
|---|---|
| ARP poisoning identified from B1 (not MAC flooding) | 2 |
| DNS tunneling alert re-classified as a true positive and explained | 2 |
| Shadowing rule 15 found and the SSH tunnel described as firewall evasion | 2 |
| Timeline corrected and remediation fixed (DAI, DHCP snooping, DNS egress, remove rule 15) | 2 |
| Corrected report is consistent end to end (summary, evidence, severity, confidence) | 2 |
Answer key (spoilers: finish the exercise first)
What a correct submission shows
- Wrong Layer 2 attack: MAC flooding would overflow the CAM table with random MACs. Here the table is normal (about 40 entries), and unsolicited ARP replies claim the gateway IP 192.0.2.1 belongs to WS-DOCK-14. That is ARP poisoning, an active sniffing technique that puts the attacker on-path. The fix is Dynamic ARP Inspection (DAI) backed by DHCP snooping, not port security.
- True positive dismissed: Thousands of TXT queries with roughly 60-character random labels to one domain, sent to an outside resolver, is classic DNS tunneling. The backup agent only uses HTTPS. Calling it a false positive turns it into a false negative in practice.
- Shadowed firewall rule (subtle): Firewalls stop at the first matching rule. Rule 15, a forgotten 'TEMP' vendor exception, allows SSH from the whole LAN to 198.51.100.77 before rule 40 denies SSH. The 9-hour, 1.8 GB session is a tunnel over an allowed path: firewall evasion and likely exfiltration.
- Wrong timeline (subtle): The poisoning started at 01:52, 22 minutes before the report's 02:14. Starting late hides the first on-path traffic, which may include captured credentials.
- Weak remediation: Two MACs per port does not stop a host with one MAC from sending forged ARP replies, and suppressing the alert blinds the IDS. Add DAI, DHCP snooping, internal-only DNS with outbound DNS blocked, rule 15 removal and a rule review, long-session alerting, and isolation of WS-DOCK-14.
- Final decision: severity rises to High (on-path position plus probable data exfiltration). Confidence in the original draft is Low.
Why it matters
- Wrong diagnosis = wrong fix: port security leaves ARP poisoning wide open.
- Rule order is security: one stale exception above a deny rule undoes it.
- AI lesson: AI inherits the draft's assumptions. Comparing claims to the evidence appendix is the human's job.
Common mistakes
- Keeping 'MAC flooding' because the notes and draft both say it.
- Accepting 'backup traffic' without checking how the backup agent really communicates.
- Reading rule 40 and missing rule 15 above it.
- Leaving the 02:14 start time in the timeline.
Instructor variant (same answer for everyone)
Add this line to the Step 1 prompt:
Make Document A call it MAC flooding starting 02:14, call the DNS tunneling alert a false positive from backup software, and say outbound SSH was blocked. Make Document B show ARP replies from 01:52 mapping 192.0.2.1 to 00:1A:2B:3C:4D:66 with a normal CAM table, 3,800 long DNS TXT queries to 203.0.113.53, and firewall rule 15 (TEMP vendor SSH to 198.51.100.77) above deny rule 40 with a 9-hour, 1.8 GB session. Keep the port-security-only remediation.
Answer: ARP poisoning (not MAC flooding); the DNS tunneling alert is a true positive; rule 15 shadows rule 40 and allowed the SSH tunnel; the timeline starts at 01:52; remediation needs DAI, DHCP snooping, DNS egress control, and rule 15 removed.
