Skip to content
Back to skills

Protocol Traffic Analysis

ASecurity

Analyzes supplied PCAP and packet-capture evidence into hosts, conversations, dependencies, authentication exposure, timing patterns, blind spots, and defensible follow-up. Use when reviewing network traffic without transmitting to the observed systems.

  • 53 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 16, 2026
securitygo

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned October 16, 2026

npx -y skills add zero-lab-ai/skills --skill protocol-traffic-analysis --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Protocol Traffic Analysis?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Protocol Traffic Analysis
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/zero-lab-ai-protocol-traffic-analysis/badge)](https://www.skillsdirectory.com/skills/zero-lab-ai-protocol-traffic-analysis)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: protocol-traffic-analysis
description: "Analyzes supplied PCAP and packet-capture evidence into hosts, conversations, dependencies, authentication exposure, timing patterns, blind spots, and defensible follow-up. Use when reviewing network traffic without transmitting to the observed systems."
allowed-tools: Read Grep Glob
---

# Protocol traffic analysis

A packet capture contains what reached one collection point during one time
window under one filter. It does not contain every host, service, packet, or
direction in the environment. Preserve that boundary while turning packets into
an evidence-backed map.

This skill analyzes supplied captures. It does not authorize capture placement,
active probing, credential cracking, replay, poisoning, exploitation, or target
contact. Send active discovery to a reconnaissance workflow and active protocol
validation to a separately authorized assessment.

## When to Use

- Reviewing network traffic without transmitting to the observed systems.
- Use only within explicit authorization and the stated rules of engagement.

## When NOT to Use

- Do not treat this skill as permission to access, test, or change a target.
- Do not convert missing evidence into a clean result or a stronger claim.

## Workflow

1. Hash each capture and record its source, authorization, collection point,
   time window, packet and byte counts, filter, snap length, directionality,
   clock basis, and reported packet drops.
2. State handling rules before reading payloads. Keep credentials, tokens,
   personal data, and session material in restricted evidence storage. Put only
   redacted references in the analysis record.
3. Build evidence locators from frame numbers, streams, fields, or deterministic
   aggregates. A narrative without a locator is not packet evidence.
4. Inventory hosts from observed addresses and names. Record role and operating
   system as `observed`, `inferred`, or `unknown`, with evidence for each claim.
5. Build directional conversations with endpoints, transport, time range,
   counts, service claim, authentication exposure, encryption state, and evidence.
   If the supplied facts do not include per-conversation counts or timestamps,
   mark those metrics unknown; never substitute `1` or the full capture window.
6. Separate protocol identity from port convention. Mark a service `observed`
   only when dissection, payload, negotiation, or equivalent evidence supports it.
7. Record dependencies, timing patterns, naming and broadcast intelligence,
   authentication exposure, and anomalies. Include alternative explanations for
   every inferred pattern.
8. Cover capture integrity, host inventory, service dependencies,
   authentication, naming and broadcast, encrypted traffic, timing, blind spots,
   and data handling. Blocked or absent coverage remains visible.

## Interpretation rules

- No observed packet is not evidence that a host, service, or protocol is absent.
- A filtered capture cannot answer questions about traffic excluded before storage.
- Packet drops, truncation, one-sided capture, and clock uncertainty weaken timing
  and completeness claims; they do not disappear because analysis succeeded.
- TTL, window size, user agent, naming, and protocol mix support hypotheses about
  host role or operating system. Preserve them as inferred unless direct evidence exists.
- Encrypted traffic exposes metadata and behavior, not plaintext content.
- Regular timing can indicate automation, monitoring, backup, or command and
  control. State the alternatives before recommending active follow-up.
- A captured challenge-response proves exposure in the capture. It does not prove
  that the credential is crackable, relayable, privileged, or still valid.

## Rationalizations to reject

- **"The capture is clean."** A capture has coverage and limitations; it is not a
  verdict on traffic it could not see.
- **"Port 443 means HTTPS."** Port convention is an inference until protocol
  evidence supports it.
- **"The periodic flow is command and control."** Regular services and health
  checks produce the same shape. Preserve alternatives.
- **"We can paste the credential into the report for proof."** Store the secret
  under access control and cite a redacted reference.
- **"Zero dropped packets means complete visibility."** It says nothing about
  the capture point, filter, direction, or traffic outside the time window.
- **"The PCAP showed a relay target, so relay is authorized."** Observation does
  not grant permission to crack, replay, poison, relay, or contact anything.

Files in this skill

  • SKILL.md4.5 KB
  • agents/openai.yaml241 B
  • assets/zero-lab-mark.svg10.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.