Wireshark Traffic Analysis

Use this skill to turn raw packet captures into a disciplined investigation. The goal is not to list packets. The goal is to build a defensible answer from capture-wide context, protocol-level evidence, and clearly labeled inferences.

When to use

• pcap or pcapng analysis
• live traffic review after capture
• security triage, threat hunting, or incident response
• network and protocol troubleshooting
• CTF and forensics-style packet challenges
• any task where packet evidence matters more than intuition

Required inputs

• capture path
• primary goal: triage, security, incident-response, troubleshoot, or ctf
• any known scope: suspicious host, port, domain, time window, protocol, or symptom

If the user does not name a goal, default to triage.

Core workflow

1. Open the capture first.

• Use wireshark_open_file before protocol-specific tools. It activates contextual tools and gives an initial protocol summary.

1. Build a global picture before drilling down.

• Prefer wireshark_quick_analysis, wireshark_stats_protocol_hierarchy, wireshark_stats_endpoints, and wireshark_stats_conversations.

1. Choose one mode and follow its playbook.

• Read references/playbooks.md and use the matching section.

1. Confirm interesting leads with packet-level evidence.

• Use wireshark_follow_stream, wireshark_get_packet_details, wireshark_get_packet_context, wireshark_extract_fields, and wireshark_search_packets.

1. Separate observation from interpretation.

• Facts come from tool output.
• Inferences must be labeled confirmed, likely, possible, or unresolved.

1. End with next actions.

• Suggest exact display filters, stream indexes, frame numbers, fields, or follow-up questions.

Analysis rules

• Start broad, then narrow.
• Prefer Wireshark MCP tools over freehand tshark syntax.
• Never guess display filter syntax. Use wireshark://reference/display-filters.
• Use wireshark://reference/protocol-fields when you need field names for extraction or filters.
• Never decode payloads manually when wireshark_decode_payload can verify the result.
• Treat wireshark_stats_expert_info as a lead generator, not a final verdict.
• When a finding depends on context, follow the full stream before concluding.
• For large captures, paginate instead of treating the first page as representative.
• If the capture vantage point could distort interpretation, say so explicitly.
• If evidence is incomplete, say exactly what is missing.

Statistics notes

• wireshark_stats_protocol_hierarchy is for structure, not naive percentage math. A single packet can contribute to multiple protocol rows across layers.
• wireshark_stats_endpoints is the fastest host inventory view. Use it to identify broadcast, multicast, and heavy talkers before drilling into conversations.
• wireshark_stats_conversations is usually the best place to prioritize long-lived, high-volume, or asymmetric exchanges.
• Stream indexes are tool evidence too. When wireshark_follow_stream explains the finding, include the exact stream index in the report.

For official Wireshark behavior notes and source links, see references/official-wireshark-notes.md.

Evidence standard

For any non-trivial finding, include at least two of the following:

• the tool call that surfaced it
• exact host, port, protocol, or field names
• a stream index or frame number
• a display filter or field extraction query
• a short explanation of why the signal matters

When a pattern looks suspicious but could still be normal, read references/evidence-rubric.md before concluding.

Professional reporting style

• Write like an analyst, not like a chatty observer.
• Do not say "weird", "sketchy", or "probably malware" without evidence.
• Keep severity or impact separate from confidence.
• State scope, assumptions, and gaps when they materially affect the conclusion.
• Prefer "observed", "evidence shows", "likely indicates", and "could not verify" over vague language.
• If the capture alone cannot prove intent, say so directly.

Output shape

Use the structure in references/report-template.md. Keep reports concise, evidence-backed, and action-oriented.

Mode selection

Use the matching playbook in references/playbooks.md:

• triage: unknown capture, fast situational awareness
• security: suspicious traffic, exfiltration, credential exposure, malware behavior
• incident-response: reconstruct the timeline, scope, and affected systems
• troubleshoot: retransmissions, latency, resets, failed handshakes, unstable services
• ctf: flags, hidden payloads, staged transfers, encoded streams

Built-in prompts and references

If the user mainly needs a starting workflow rather than a full investigation, the MCP prompts in this repo can help:

• traffic_overview
• security_audit
• performance_analysis
• incident_response
• ctf_solve

Use wireshark://guide/usage when you need the repo's built-in MCP workflow reference.

Common mistakes to avoid

• calling something malicious because it is uncommon
• calling something benign because it is encrypted
• over-trusting a single heuristic such as long DNS queries or one retransmission
• skipping endpoints and conversations, then missing the real top talker
• reporting a hypothesis as a confirmed root cause