Skip to content

Commit 96520d1

Browse files
bx33661bx33661
committed
Expand skill discovery across AI clients
1 parent f8ebd1f commit 96520d1

28 files changed

Lines changed: 1394 additions & 4 deletions

‎.claude/skills/wireshark-traffic-analysis/SKILL.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
name: "wireshark-traffic-analysis"
3+
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."
4+
---
5+
6+
# Wireshark Traffic Analysis
7+
8+
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.
9+
10+
## When to use
11+
12+
- `pcap` or `pcapng` analysis
13+
- live traffic review after capture
14+
- security triage, threat hunting, or incident response
15+
- network and protocol troubleshooting
16+
- CTF and forensics-style packet challenges
17+
- any task where packet evidence matters more than intuition
18+
19+
## Required inputs
20+
21+
- capture path
22+
- primary goal: `triage`, `security`, `incident-response`, `troubleshoot`, or `ctf`
23+
- any known scope: suspicious host, port, domain, time window, protocol, or symptom
24+
25+
If the user does not name a goal, default to `triage`.
26+
27+
## Core workflow
28+
29+
1. Open the capture first.
30+
- Use `wireshark_open_file` before protocol-specific tools. It activates contextual tools and gives an initial protocol summary.
31+
2. Build a global picture before drilling down.
32+
- Prefer `wireshark_quick_analysis`, `wireshark_stats_protocol_hierarchy`, `wireshark_stats_endpoints`, and `wireshark_stats_conversations`.
33+
3. Choose one mode and follow its playbook.
34+
- Read [references/playbooks.md](references/playbooks.md) and use the matching section.
35+
4. Confirm interesting leads with packet-level evidence.
36+
- Use `wireshark_follow_stream`, `wireshark_get_packet_details`, `wireshark_get_packet_context`, `wireshark_extract_fields`, and `wireshark_search_packets`.
37+
5. Separate observation from interpretation.
38+
- Facts come from tool output.
39+
- Inferences must be labeled `confirmed`, `likely`, `possible`, or `unresolved`.
40+
6. End with next actions.
41+
- Suggest exact display filters, stream indexes, frame numbers, fields, or follow-up questions.
42+
43+
## Analysis rules
44+
45+
- Start broad, then narrow.
46+
- Prefer Wireshark MCP tools over freehand `tshark` syntax.
47+
- Never guess display filter syntax. Use `wireshark://reference/display-filters`.
48+
- Use `wireshark://reference/protocol-fields` when you need field names for extraction or filters.
49+
- Never decode payloads manually when `wireshark_decode_payload` can verify the result.
50+
- Treat `wireshark_stats_expert_info` as a lead generator, not a final verdict.
51+
- When a finding depends on context, follow the full stream before concluding.
52+
- For large captures, paginate instead of treating the first page as representative.
53+
- If the capture vantage point could distort interpretation, say so explicitly.
54+
- If evidence is incomplete, say exactly what is missing.
55+
56+
## Statistics notes
57+
58+
- `wireshark_stats_protocol_hierarchy` is for structure, not naive percentage math. A single packet can contribute to multiple protocol rows across layers.
59+
- `wireshark_stats_endpoints` is the fastest host inventory view. Use it to identify broadcast, multicast, and heavy talkers before drilling into conversations.
60+
- `wireshark_stats_conversations` is usually the best place to prioritize long-lived, high-volume, or asymmetric exchanges.
61+
- Stream indexes are tool evidence too. When `wireshark_follow_stream` explains the finding, include the exact stream index in the report.
62+
63+
For official Wireshark behavior notes and source links, see [references/official-wireshark-notes.md](references/official-wireshark-notes.md).
64+
65+
## Evidence standard
66+
67+
For any non-trivial finding, include at least two of the following:
68+
69+
- the tool call that surfaced it
70+
- exact host, port, protocol, or field names
71+
- a stream index or frame number
72+
- a display filter or field extraction query
73+
- a short explanation of why the signal matters
74+
75+
When a pattern looks suspicious but could still be normal, read [references/evidence-rubric.md](references/evidence-rubric.md) before concluding.
76+
77+
## Professional reporting style
78+
79+
- Write like an analyst, not like a chatty observer.
80+
- Do not say "weird", "sketchy", or "probably malware" without evidence.
81+
- Keep severity or impact separate from confidence.
82+
- State scope, assumptions, and gaps when they materially affect the conclusion.
83+
- Prefer "observed", "evidence shows", "likely indicates", and "could not verify" over vague language.
84+
- If the capture alone cannot prove intent, say so directly.
85+
86+
## Output shape
87+
88+
Use the structure in [references/report-template.md](references/report-template.md). Keep reports concise, evidence-backed, and action-oriented.
89+
90+
## Mode selection
91+
92+
Use the matching playbook in [references/playbooks.md](references/playbooks.md):
93+
94+
- `triage`: unknown capture, fast situational awareness
95+
- `security`: suspicious traffic, exfiltration, credential exposure, malware behavior
96+
- `incident-response`: reconstruct the timeline, scope, and affected systems
97+
- `troubleshoot`: retransmissions, latency, resets, failed handshakes, unstable services
98+
- `ctf`: flags, hidden payloads, staged transfers, encoded streams
99+
100+
## Built-in prompts and references
101+
102+
If the user mainly needs a starting workflow rather than a full investigation, the MCP prompts in this repo can help:
103+
104+
- `traffic_overview`
105+
- `security_audit`
106+
- `performance_analysis`
107+
- `incident_response`
108+
- `ctf_solve`
109+
110+
Use `wireshark://guide/usage` when you need the repo's built-in MCP workflow reference.
111+
112+
## Common mistakes to avoid
113+
114+
- calling something malicious because it is uncommon
115+
- calling something benign because it is encrypted
116+
- over-trusting a single heuristic such as long DNS queries or one retransmission
117+
- skipping endpoints and conversations, then missing the real top talker
118+
- reporting a hypothesis as a confirmed root cause

‎.claude/skills/wireshark-traffic-analysis/agents/openai.yaml‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
interface:
2+
display_name: "Wireshark Traffic Analysis"
3+
short_description: "Triage, hunt, and debug packet captures"
4+
default_prompt: "Use $wireshark-traffic-analysis to investigate this capture, choose the right workflow, and produce an evidence-backed packet analysis report."
5+
6+
policy:
7+
allow_implicit_invocation: true

‎.claude/skills/wireshark-traffic-analysis/references/evidence-rubric.md‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
# Evidence Rubric
2+
3+
Use this rubric when a pattern looks suspicious but the capture alone may not be enough to prove intent or root cause.
4+
5+
## Contents
6+
7+
- [Confidence labels](#confidence-labels)
8+
- [Vantage point checks](#vantage-point-checks)
9+
- [Common signals](#common-signals)
10+
11+
## Confidence labels
12+
13+
Use these labels consistently:
14+
15+
- `confirmed`: directly supported by packet evidence with little ambiguity
16+
- `likely`: multiple signals support the conclusion, but another explanation is still plausible
17+
- `possible`: one or two weak indicators exist, but the conclusion is not stable
18+
- `unresolved`: the capture suggests a question, not an answer
19+
20+
## Vantage point checks
21+
22+
Before concluding, ask:
23+
24+
- Is this capture from the client, server, gateway, mirror port, or only one side of the path?
25+
- Could packet loss in the capture itself create fake retransmissions or gaps?
26+
- Are missing packets making application behavior look incomplete?
27+
- Is TLS decryption unavailable, limiting what can be claimed about payloads?
28+
29+
If vantage point uncertainty affects the conclusion, mention it explicitly.
30+
31+
## Common signals
32+
33+
### DNS tunneling
34+
35+
Treat DNS as suspicious only when several indicators align:
36+
37+
- unusually long query names
38+
- many unique subdomains under one base domain
39+
- repetitive TXT or NULL queries
40+
- regular beacon-like cadence
41+
- high-entropy labels
42+
- weak or failed response patterns
43+
44+
Counterexamples:
45+
46+
- CDN hostnames
47+
- telemetry platforms
48+
- service discovery
49+
- anti-malware lookups
50+
51+
Good confirmation tools:
52+
53+
- `wireshark_detect_dns_tunnel`
54+
- `wireshark_extract_dns_queries`
55+
- `wireshark_extract_fields` with `dns.qry.name`, `dns.qry.type`, `ip.src`, `ip.dst`
56+
57+
### Port scanning
58+
59+
Treat scanning as stronger when you see:
60+
61+
- one source probing many ports or many hosts
62+
- many SYN-only attempts with little follow-through
63+
- short-lived connections with consistent fan-out
64+
65+
Counterexamples:
66+
67+
- vulnerability scanners you already own
68+
- health checks
69+
- inventory tooling
70+
- load balancer probes
71+
72+
Good confirmation tools:
73+
74+
- `wireshark_detect_port_scan`
75+
- `wireshark_extract_fields` with `ip.src`, `ip.dst`, `tcp.dstport`, `tcp.flags.syn`
76+
- `wireshark_stats_conversations`
77+
78+
### Credential exposure
79+
80+
Only call credentials exposed when the capture actually contains the secret or credential-bearing field.
81+
82+
Examples:
83+
84+
- `http.authbasic`
85+
- FTP `PASS`
86+
- Telnet plaintext login flows
87+
88+
Good confirmation tools:
89+
90+
- `wireshark_extract_credentials`
91+
- `wireshark_follow_stream`
92+
- `wireshark_get_packet_details`
93+
94+
### Exfiltration or suspicious data transfer
95+
96+
Treat exfiltration as stronger when you see:
97+
98+
- sustained asymmetric upload volume
99+
- repetitive uploads to a narrow destination set
100+
- encoded or staged payloads
101+
- suspicious destinations plus meaningful payload movement
102+
103+
Counterexamples:
104+
105+
- backups
106+
- software updates
107+
- sync clients
108+
- log shipping
109+
110+
Good confirmation tools:
111+
112+
- `wireshark_stats_conversations`
113+
- `wireshark_follow_stream`
114+
- `wireshark_extract_http_requests`
115+
- `wireshark_export_objects`
116+
117+
### TLS suspicion
118+
119+
TLS alone is not suspicious. Treat it as more interesting when it overlaps with:
120+
121+
- failed or unusual handshakes
122+
- uncommon SNI targets
123+
- self-signed or mismatched certificates
124+
- suspicious destinations found elsewhere in the capture
125+
126+
Counterexamples:
127+
128+
- internal PKI
129+
- TLS interception
130+
- test environments
131+
132+
Good confirmation tools:
133+
134+
- `wireshark_extract_tls_handshakes`
135+
- `wireshark_check_threats`
136+
- `wireshark_follow_stream`
137+
138+
### TCP health problems
139+
140+
One retransmission rarely proves a network issue. Stronger cases include:
141+
142+
- repeated retransmissions in the same conversation
143+
- duplicate ACK bursts
144+
- zero-window events
145+
- resets aligned with user-visible failures
146+
147+
Counterexamples:
148+
149+
- capture loss
150+
- transient congestion
151+
- intentionally closed connections
152+
153+
Good confirmation tools:
154+
155+
- `wireshark_analyze_tcp_health`
156+
- `wireshark_stats_expert_info`
157+
- `wireshark_follow_stream`
158+
159+
## Reporting rule
160+
161+
Whenever a claim could be disputed, include:
162+
163+
- the signal
164+
- the counter-interpretation
165+
- why your conclusion still holds, or why it remains unresolved

‎.claude/skills/wireshark-traffic-analysis/references/official-wireshark-notes.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# Official Wireshark Notes
2+
3+
This file distills the official Wireshark and TShark documentation into a few high-value rules for the skill. Use it when a statistic or workflow seems ambiguous.
4+
5+
## Sources
6+
7+
- Wireshark User's Guide: Protocol Hierarchy
8+
- <https://www.wireshark.org/docs/wsug_html_chunked/ChStatHierarchy.html>
9+
- Wireshark User's Guide: Endpoints
10+
- <https://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html>
11+
- Wireshark User's Guide: Conversations
12+
- <https://www.wireshark.org/docs/wsug_html_chunked/ChStatConversations.html>
13+
- Wireshark User's Guide: Expert Information
14+
- <https://www.wireshark.org/docs/wsug_html_chunked/ChAdvExpert.html>
15+
- Wireshark User's Guide: Display Filters
16+
- <https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html>
17+
- TShark Manual: `follow` stream syntax
18+
- <https://www.wireshark.org/docs/man-pages/tshark.html>
19+
20+
## What to remember
21+
22+
### Protocol hierarchy is structural
23+
24+
The protocol hierarchy view is meant to explain how packets are dissected through the stack. It is great for spotting whether the capture is mostly TCP, DNS, TLS, HTTP, ARP, and so on.
25+
26+
Do not treat the rows as mutually exclusive buckets. A single packet can contribute to multiple rows across layers, so percentages are not a simple pie chart.
27+
28+
### Endpoints answer "who exists"
29+
30+
The endpoints view is the best fast inventory of hosts or addresses present in the capture. It also includes separate tabs by protocol family and may include broadcast or multicast addresses.
31+
32+
Use it early to identify:
33+
34+
- top talkers
35+
- unexpected hosts
36+
- broadcast-heavy behavior
37+
- whether IPv4, IPv6, TCP, or UDP dominate the capture
38+
39+
### Conversations answer "who exchanged meaningful traffic"
40+
41+
The conversations view is better than endpoints when you need to prioritize investigations. Official Wireshark docs note that conversations include fields such as relative start time, duration, bits per second, and a graphable timeline.
42+
43+
Use it to identify:
44+
45+
- long-lived sessions
46+
- asymmetric uploads or downloads
47+
- spikes tied to a specific pair
48+
- the best candidate streams to follow
49+
50+
### Expert Info is triage, not truth
51+
52+
Expert Information is useful because it collects warnings, chats, notes, and errors in one place. It is an accelerator for investigation, not a substitute for it.
53+
54+
Treat it as:
55+
56+
- a fast anomaly shortlist
57+
- a hint about retransmissions, malformed packets, handshakes, or protocol issues
58+
- something that still needs confirmation with streams, packet details, or field extraction
59+
60+
### Display filters are exact syntax, not vibes
61+
62+
The official display filter builder documentation is a reminder to stay exact. When you are unsure about operators, field names, or compound expressions, use the MCP reference resource instead of improvising.
63+
64+
### Stream following uses explicit stream selectors
65+
66+
The official `tshark` manual documents `follow` stream selection by protocol and stream index. For TCP, the stream index behavior is zero-based. When reporting or handing off work, include the stream index so another analyst can reproduce the same view quickly.

0 commit comments

Comments
 (0)