Skip to content

SKILL.md

Latest commit

 

History

History
118 lines (87 loc) · 5.74 KB

SKILL.md

File metadata and controls

118 lines (87 loc) · 5.74 KB
Raw
name wireshark-traffic-analysis
description Use when analyzing packet captures or live network traffic with Wireshark MCP; choose the right workflow for triage, security hunting, incident response, troubleshooting, or CTF work, then produce evidence-backed findings with exact filters, streams, frames, and next steps.

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.
  2. Build a global picture before drilling down.
    • Prefer wireshark_quick_analysis, wireshark_stats_protocol_hierarchy, wireshark_stats_endpoints, and wireshark_stats_conversations.
  3. Choose one mode and follow its playbook.
  4. 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.
  5. Separate observation from interpretation.
    • Facts come from tool output.
    • Inferences must be labeled confirmed, likely, possible, or unresolved.
  6. 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