Wireshark Incident Response Workflow: Packet Analysis for Security Triage

Somewhere between 90 and 95 per cent of the traffic in a modern enterprise capture is encrypted. That single fact should reshape how you think about packet analysis in incident response, and in most teams it has not. The mental model people carry — open the PCAP, follow the stream, read what the attacker sent — describes an internet that stopped existing around 2016.

What you get instead is metadata: who talked to whom, when, how much, how often, over what protocol, with which TLS server name and which certificate. That is less than analysts hope for and considerably more than they usually exploit. Beacon timing does not care that the payload is encrypted. Neither does a 400 MB upload to a hosting provider at three in the morning, or a host suddenly resolving two thousand subdomains of one domain.

So the value proposition is narrower and sharper than “packets show you the truth”. Logs tell you what a system chose to record. Packets tell you what actually crossed the wire, including the connections no agent logged because no agent was installed. Used well, Wireshark answers a specific class of question that nothing else in your stack can. Used as a packet browser — opening a capture and scrolling — it consumes an afternoon and produces a screenshot.

Wireshark incident response workflow

This guide covers how to use Wireshark effectively for defensive, investigation-focused packet analysis in authorised environments.

Why packet evidence belongs in incident response

Logs are summaries produced by software that was configured by someone, running on a host that may be compromised. Packets were observed by a device the attacker does not control. That difference matters most in exactly the situations where it is hardest to think clearly:

Was that outbound connection real, or an artefact of how a parser handled a malformed log line?
What was actually transferred, in which direction, and how much of it?
Did the protocol on the wire match the protocol the port implies?
Is this endpoint scanning, or is it a monitoring agent polling on a schedule that looks like scanning?

There is a fifth question that packets answer uniquely well, and it is the one that most often justifies the effort: what happened on a host whose logs you cannot trust? Once an endpoint is compromised, its own telemetry becomes a statement by the attacker. Packets captured upstream are not.

The complement to that is knowing where packets are weak. They cannot tell you which process opened a socket, which user was at the keyboard, or what a binary did on disk — and on an encrypted connection they cannot tell you what was sent. Endpoint telemetry, authentication logs and proxy data cover exactly those gaps, which is why the correlation step later in this workflow is not a nicety. Packet analysis on its own generates hypotheses. Correlation is what turns them into findings.

Choosing the right source for each investigation question

Packet analysis is expensive in the only currency an incident has: analyst hours during the window when containment decisions are still cheap. An analyst three hours into a capture is an analyst who has not been reading authentication logs, and on most investigations the authentication logs would have answered the question in ten minutes.

The discipline is to know which questions packets are genuinely the fastest source for, and to reach for something else otherwise.

Investigation Question	Best Starting Source	Why
Was there suspicious outbound communication?	Firewall and proxy logs first, PCAP to confirm	Logs cover a far wider timespan; packets settle the specific flow in dispute
Did a user account behave unusually?	Identity and auth logs — packets will not help	Account activity lives in the identity provider, and modern auth traffic is encrypted anyway
Was data transferred externally?	Proxy and endpoint telemetry, PCAP for volume and timing	Packets give byte counts and session shape even when the payload is opaque
Is this endpoint scanning or normal service polling?	PCAP first	Timing regularity and connection-attempt patterns are visible in packets and nowhere else
Did a web or API route receive malformed requests?	Web and WAF logs, packets only if TLS terminates upstream	App logs carry the decoded request; packets show nothing if the capture point sees ciphertext
Is a host beaconing to a C2 server?	PCAP or flow data	Interval regularity and jitter are packet-level properties no log records
What did the attacker actually send?	Endpoint telemetry, not packets	On an encrypted session the payload is unavailable regardless of your capture quality

Two rules follow. Start with logs for breadth, then use packets to resolve the specific unknowns that matter — and do not open Wireshark until you can state, in one sentence, the question you need it to answer. An analyst who cannot articulate that question will scroll, and scrolling produces interesting frames rather than findings.

The second rule is about capture position, and it decides more outcomes than tool skill does. A capture taken inside the TLS termination point sees decrypted HTTP; one taken outside sees ciphertext. Same incident, same tooling, completely different answer to “did this request contain an injection payload”. Establish where your capture sat before you invest hours in what it might contain.

Handling PCAPs before you open Wireshark

Nobody has ever regretted hashing a capture. Plenty of people have watched a solid technical finding get discarded eight months later because nobody could establish that the file analysed was the file collected — and by then the sensor has rotated its buffer, so there is no way to go back and do it properly.

The other reason to care is more immediate than legal admissibility. Wireshark writes to files when you apply certain operations, and an analyst working directly on the only copy can alter it without intending to. Read-only originals mean the worst outcome of a mistake is redoing an hour of work.

PCAP preservation checklist:

Preserve the original as read-only before anything else — copy it, set the permission, work exclusively from the copy
Record the collection source, capture tool and version, and the exact interface
Hash with SHA-256 and store the hash somewhere other than beside the file
Record whether the capture was filtered at collection time, and with what BPF expression — a capture filter destroys what it excludes, permanently and invisibly
Note snap length: a truncated capture that kept only headers cannot be made to yield payloads later, no matter who asks
Document the timezone and how timestamps were normalised across systems
Use a case ID and keep a chain-of-custody log for every transfer
Redact in shared exports only; never touch the originals

Chain-of-custody table:

Field	What to Record
Case ID	Unique incident identifier
Evidence ID	PCAP filename and storage path
Collected by	Name, role, and timestamp of collection
Source	Sensor, TAP, host, or capture point
Integrity hash	SHA-256 value
Access log	Who accessed the evidence and when
Transfer notes	Any storage moves and access approvals

Two entries in that table earn their place more than the rest. Source determines what the capture could possibly contain — a SPAN port that only mirrored one direction, or a tap inside the load balancer rather than outside it, changes the meaning of every conclusion drawn afterwards. And integrity hash is the one field that cannot be reconstructed later; everything else can be recovered from memory or tickets, but a hash taken next week proves nothing about the file’s state last week.

This takes five minutes at the start of a case. It protects weeks of work from being unpickable on procedural grounds, and it protects you from the much more common and less dramatic failure of not being able to remember, three months on, which of four files on the share was the original.

A note on privacy that is easy to skip and awkward to fix afterwards: a full packet capture from a corporate network contains employees’ personal browsing, credentials submitted over any remaining plaintext protocols, and message content. In jurisdictions with GDPR or equivalent regimes, that is personal data with retention obligations and access constraints attached. Decide who may open these files, and how long they are kept, before an incident forces the question.

A step-by-step Wireshark triage workflow

The workflow’s purpose is to make analysis reproducible by someone who is not you, and to stop the drift into chasing interesting frames. Work top-down: the capture as a whole, then flows, then protocols, then individual packets. Analysts who invert that order — starting from the one alerted packet — consistently miss the context that would have explained it.

Step 1: Profile the capture first

Before applying a single display filter, establish what you are holding. Statistics → Capture File Properties gives you the timeframe, packet count and whether a capture filter was applied. Protocol Hierarchy gives the distribution in one screen.

What you are looking for at this stage is shape, not detail. Does the capture window actually cover the incident, or does it start twenty minutes late? Does the protocol mix look like this network — and if a segment that should be almost entirely HTTPS shows 30% DNS, that is the finding, before you have filtered anything. Note what is absent as well as what is present: a capture with no ARP and no broadcast traffic is not seeing the whole segment, which tells you something important about the SPAN configuration.

Step 2: Identify conversations and sessions

Statistics → Conversations, sorted by bytes, then by duration, then by packet count. Each sort surfaces a different kind of anomaly: bytes finds bulk transfer, duration finds long-lived sessions that should not be, and packet count with low bytes finds the small, regular exchanges that look like beaconing.

Prioritise external destinations, then ask the boring question first — is this a CDN, a software update service, a monitoring agent? Most of what looks alarming in a first pass is a vendor you had forgotten you use, and confirming that quickly is what leaves time for the flows that are genuinely unexplained.

Step 3: Review protocol behaviour in detail

DNS: query volume and rate, subdomain entropy and length, TXT and NULL record types, and repeated NXDOMAIN responses. High-volume queries to many random subdomains of a single registered domain is the classic tunnelling and C2 pattern, and it stays visible regardless of encryption elsewhere
HTTP: methods, path patterns, response codes and host headers — but be honest about how little unencrypted HTTP remains, and treat plaintext HTTP to an external host as itself worth explaining
TLS: the SNI in the client hello, the JA3/JA4 client fingerprint, certificate validity periods and issuers where visible. A self-signed certificate with a one-year validity and a nonsense subject on a long-lived outbound session is a strong signal even though you cannot read a byte of the content
Port and protocol mismatches: Wireshark’s dissector shows you what the traffic is, not what the port claims. SSH on 443, or a non-HTTP protocol on 80, is exactly the kind of thing a port-based log will never report

Step 4: Correlate with your other telemetry

Align packet timestamps with firewall events, then map the source host to endpoint telemetry and process execution, then check authentication activity in the same window. The goal is to name the process that opened the socket — that single fact converts “unexplained outbound connection” into either a resolved false positive or a confirmed incident, and nothing in the capture will give it to you.

Do the timezone reconciliation explicitly and write down what you did. Wireshark displays in local time by default while your SIEM is likely in UTC, and a silent one-hour offset produces a timeline in which effects precede causes. This wastes more investigative time than any other single error in packet work.

Step 5: Document before you close the capture

Record the filters you applied and the order you applied them, not just the conclusions — a finding another analyst cannot reproduce is an opinion. Export the relevant frames with exact timestamps. State each hypothesis as confirmed, plausible or ruled out, with the evidence for each, and say plainly what the capture could not tell you. Then the recommended action: contain, investigate further, or close, with the criteria for each.

Write this while the capture is still open. Reconstructing which filter surfaced which frame two days later is slow, and the reconstruction is often quietly wrong.

Useful Wireshark filters for defensive triage

One distinction to get right before any of this, because it is the most consequential detail in Wireshark and the interface does very little to signal it. Capture filters (BPF syntax, applied at collection) discard traffic permanently — what they exclude never reaches the file and cannot be recovered. Display filters (Wireshark syntax, applied afterwards) only change what you are shown; the data remains. They use different, superficially similar syntaxes, and host 10.0.0.5 versus ip.addr == 10.0.0.5 is the difference between them.

The practical rule: filter conservatively at capture, aggressively at display. An over-narrow capture filter during an incident throws away the context you will want tomorrow, and nothing about the resulting file will indicate what is missing.

Apply display filters progressively, and keep a note of the sequence — it is both your reproducibility record and the thing that stops you losing your place after an hour of pivoting.

Goal	Filter Approach	What It Surfaces
DNS triage	`dns`	Lookup volume, subdomain patterns, record types, NXDOMAIN rates
DNS tunnelling candidates	`dns` with a query-name length constraint	Long encoded labels typical of data smuggled in queries
HTTP request review	`http`	Methods, paths, response codes, host headers — where plaintext survives
TLS metadata review	`tls.handshake.type == 1`	Client hellos only: SNI and client fingerprint without the noise of the full session
Single host traffic	`ip.addr == <host_ip>`	The complete network timeline for one host, both directions
External destination focus	Negate your internal ranges	Outbound candidates, with internal chatter removed
Session establishment pattern	`tcp.flags.syn == 1 && tcp.flags.ack == 0`	Connection attempts — the shape that distinguishes scanning from polling
Error and retransmission review	TCP analysis flags	Instability, dropped sessions, and capture quality problems worth knowing about

Two cautions on that last row. Retransmissions and out-of-order frames frequently indicate a problem with the capture rather than the network — an overloaded SPAN port drops packets, and Wireshark reports the resulting gaps as network errors. Before treating packet loss as a finding, rule out the sensor. And be wary of concluding anything from a capture with heavy loss: absence of evidence in a lossy capture is not evidence of absence.

A consistent triage table for every investigation

Asking the same questions in the same order across cases does two things. It makes handoffs work — an analyst picking up your case at shift change knows what has been asked and what has not. And it prevents the availability bias that shapes most unstructured triage, where you find the kind of thing you looked for last time and miss the category you did not think to check.

Note the final row in particular. Explicitly documenting what the capture could not show is a finding in its own right, and the one most often left out.

Question	Where to Look	Evidence to Capture	Next Step
Is there suspicious outbound communication?	Conversations view, external destination flows	Session timeline, destination profile, byte counts	Correlate with endpoint process data and firewall policy
Did DNS behaviour deviate from baseline?	DNS query and response patterns	Query volume anomalies, rare domain patterns	Check endpoint timeline and available threat intel
Is there a potential data transfer anomaly?	Long sessions, large payloads, repeated external posts	Flow duration and transfer metadata	Validate against approved application behaviour
Are there signs of unauthorised service discovery?	Port and protocol scans, connection bursts	Sequential connection attempts and host targeting patterns	Segment the source host and run endpoint triage
Is encrypted traffic limiting visibility?	TLS sessions	Metadata-only visibility — document the limitation	Use proxy, firewall, and endpoint logs for complementary context

Common incident scenarios and how to approach them

Suspicious outbound connection

The single most valuable fact is which process opened the socket, and it is not in the capture. Get it from EDR first, because it resolves most of these in one step — a connection from chrome.exe to a CDN and the same connection from a binary in %TEMP% are entirely different incidents with identical packets.

Then ask whether this host has ever contacted this destination before. A new destination for a host with three years of consistent behaviour is far more interesting than a rare destination that host contacts every Tuesday. Classify as known service, misconfiguration, or genuine unknown — and resist promoting “I have not heard of this domain” to “suspicious”, which is where most false escalations begin.

Possible data exfiltration indicator

Look at direction and volume together. Outbound bytes substantially exceeding inbound on a session to a host that is not a known upload destination is the shape you are after, and it survives encryption entirely.

Then check whether it recurs. A single 2 GB transfer is often a backup job nobody documented. The same 40 MB going out at 02:00 every night to a hosting provider is a different matter. Correlate with file access on the endpoint and, if the destination is a cloud storage or paste service, with whatever DLP or proxy telemetry exists. Note the limitation honestly in your write-up: over TLS you can establish that data moved and roughly how much, not what it was.

Potential malware callback

Beaconing is a timing property, and timing survives encryption — which makes this the scenario where packet analysis most outperforms everything else in the stack.

Look for connections at regular intervals, allowing for jitter: modern implants randomise the sleep by 10–50%, so perfectly identical intervals are actually more likely to be a monitoring agent than malware. Small, consistent payload sizes with a long-lived pattern are the shape. Beware the enormous false-positive population here — telemetry agents, update checkers, certificate revocation checks and mail clients all beacon beautifully, and the way to tell them apart is not the pattern but the process and the destination. Isolate on corroboration, not on periodicity alone.

DNS anomaly

Query volume and subdomain structure are the primary signals. A host generating thousands of queries for long, high-entropy subdomains of one registered domain is either tunnelling or staging, and neither is benign. Rare record types — TXT and NULL especially — carrying substantial data are worth immediate attention.

Two things that complicate this in practice. Some legitimate security and antivirus products use DNS-based reputation lookups that generate exactly this pattern, so establish the baseline before escalating. And if endpoints are using DoH, their DNS traffic is inside HTTPS to a resolver and is invisible to this analysis entirely — which is itself worth knowing about your environment.

Unauthorised service discovery pattern

Sequential connection attempts across many ports or hosts in a short window, typically with SYNs that receive RSTs. The signature is unmistakable; the attribution is the work.

Check the boring explanations first, in this order: is the source your own vulnerability scanner, is there a change ticket, is it a monitoring or asset-discovery tool that somebody deployed without telling security? In most organisations the majority of internal scan patterns are authorised and undocumented, which is a process finding worth raising separately. Where it is not explained, treat lateral scanning from a workstation as high priority — workstations have no business enumerating the network, and this pattern often appears early enough to matter.

Writing a network forensics summary that drives decisions

The person who reads your summary will decide whether to isolate a host, notify a regulator, or send everyone back to bed — and they will do it from your document, not from the capture. That places two obligations on it: state what you found, and state clearly what you could not determine.

The second is where most summaries fail. An analysis that reports only positive findings implies the absence of everything unmentioned, and the reader has no way to distinguish “we checked and it was clean” from “the capture started after the event” or “that traffic was encrypted”. Write the limitations down, in the same document, with the same prominence.

Effective summary structure:

Case context: why packet analysis was initiated and what question it was trying to answer
Data scope: capture source, timeframe, and what the capture doesn’t cover
Key observations: the three to five most significant findings with timestamps and supporting evidence
Correlation findings: what endpoint, firewall, and authentication data confirmed or disproved
Assessment: likely benign, suspicious but unconfirmed, or confirmed incident path
Recommended actions: specific containment steps, deeper forensic work required, or closure criteria

One-page summary table:

Section	What to Include
Scope	Capture window, sensors used, host focus
Findings	Three to five evidence-backed observations
Confidence	Low, medium, or high — with rationale
Impact	Potential business or operational effect
Actions	Immediate steps, short-term follow-up, and longer-term requirements

Be disciplined about the language of certainty. “The host connected to 203.0.113.45 over TLS on port 443 at 02:14 UTC, transferring 41 MB outbound” is an observation. “The host exfiltrated data to an attacker-controlled server” is a conclusion that the same evidence does not support on its own. Both may belong in the document; they must not be in the same sentence, and the second needs its supporting correlation named.

The habit that separates useful summaries from the rest is stating confidence and reasoning together. “High confidence — beacon interval, unsigned binary in EDR, and destination registered four days ago” tells a reader exactly how much weight to put on it. “High confidence” on its own tells them nothing they can check.

Mistakes that undermine packet-based triage

These recur across teams and across skill levels. The first two cause the most wasted time; the last two cause the most damage.

Drawing a conclusion from one suspicious packet before correlating anything. A single frame is almost never sufficient evidence of anything
Ignoring timezone alignment between Wireshark, the SIEM and endpoint tooling. Wireshark defaults to local time, most SIEMs to UTC, and the resulting offset produces timelines where the response precedes the attack. This wastes more hours than any other error here
Working on the original capture rather than a copy
Treating encrypted traffic as “no evidence available”. Timing, volume, direction, SNI and client fingerprints are all still there, and they answer more questions than analysts expect
Forgetting that a capture filter silently deleted traffic at collection time — the file gives no indication of what is missing
Mistaking capture-point loss for network anomalies. An oversubscribed SPAN port drops packets, and Wireshark reports those gaps as retransmissions and errors
Missing normal administrative and scanner traffic that was simply never documented. This is the largest single source of false escalations in most environments
Not recording which filters were applied in which order, making the finding impossible for anyone else to reproduce
Reporting observations with no confidence level and no statement of what the analysis could not determine
Assuming a capture covers the incident window without checking. A capture that began after the initial access will show you a clean start and tell you nothing about it

Quick anti-error checklist before finalising findings:

Time alignment confirmed across packet, SIEM, and endpoint timelines
Original evidence hashed and stored read-only
Suspicious signals corroborated by at least one additional source
Analysis notes include filters used, pivots made, and reasoning behind each step

Wireshark IR checklist for recurring use

Consistency is the point. A checklist that gets run on the straightforward cases is a checklist that gets run correctly on the 3 a.m. case, which is the only time it actually matters.

Phase	Checklist Item	Done
Preparation	Case ID created and evidence handling plan documented	☐
Preservation	Original PCAP stored read-only with integrity hash	☐
Triage	Capture window and top talkers identified	☐
Protocol review	DNS, HTTP, TLS, and port behaviour reviewed	☐
Correlation	Firewall, endpoint, and auth logs cross-checked	☐
Evidence	Key packet findings timestamped and documented	☐
Assessment	Confidence level and limitations clearly stated	☐
Handoff	Summary and recommended actions delivered	☐

Followed consistently, this turns Wireshark from a tool one person happens to be good at into a capability the team has.

Escalation decisions: not every suspicious packet warrants a major incident

Escalation is the judgement call that most affects whether the team is trusted, and it is asymmetric in a way people underestimate. Over-escalate and you spend organisational goodwill you cannot buy back — after the third false alarm, the next genuine call gets a slower response from the same people. Under-escalate and an incident progresses while it was still cheap to contain.

Because the pressure runs in both directions, the decision should not rest on an individual analyst’s judgement at 3 a.m. A written matrix means the decision is defensible afterwards regardless of the outcome, which is the only thing that lets people make the call confidently while tired.

Signal Strength	Business Context	Recommended Action
Low — single weak indicator	Low-criticality asset	Continue monitoring and gather more context before deciding
Medium — multiple suspicious indicators from different sources	Standard production service	Open an investigation case and assign an analyst owner
High — clear malicious pattern with corroborating evidence	Critical service or sensitive data path	Escalate to incident response and initiate containment immediately
High but uncertain scope	Mixed or unknown asset ownership	Escalate with limited containment and rapid ownership validation

Two things make this work in practice. Containment is not binary — blocking one destination at the firewall is a proportionate step available long before “isolate the host”, and having intermediate options prevents the all-or-nothing framing that drives both failure modes. And the matrix needs revising when it gets a call wrong, in either direction, which is what post-incident review is for. A matrix that has never been amended is one nobody is using.

Building team capability: the 30-minute packet triage drill

Packet analysis decays faster than most incident response skills, because most analysts touch it a handful of times a year. The tooling stays fine; the fluency does not. What degrades first is not knowledge of filter syntax but the judgement about where to look — the thing that separates fifteen minutes from three hours.

Thirty minutes is deliberate. It is short enough to actually happen on a working day, and the time pressure is the point: real triage happens under pressure, and an unlimited-time exercise trains a skill nobody gets to use.

Drill structure:

Minutes 0–5: Confirm case context, capture scope, and the specific question the analysis needs to answer
Minutes 5–15: First-pass conversation and protocol analysis
Minutes 15–25: Correlate one suspicious signal with endpoint, firewall, or authentication logs
Minutes 25–30: Produce a one-page summary and make an escalation decision

Drill scoring areas:

Area	What to Score
Evidence quality	Are observations timestamped and reproducible by another analyst?
Correlation quality	Did the analyst validate the packet signal with a second source?
Decision quality	Was the escalation logic justified and consistent with the matrix?
Communication quality	Is the summary clear enough for both responders and managers?

Two things make drills worth the hour. Use real captures — Malware-Traffic-Analysis.net and the Wireshark sample repository both provide labelled scenarios, and public CTF packet challenges work well — because synthetic captures teach synthetic instincts. And include benign scenarios in the rotation without saying which is which; a drill set where every capture contains something teaches analysts to keep looking until they find it, which is precisely the habit that generates false escalations on the real queue.

Monthly is better than quarterly. Quarterly is enormously better than never, which is what most teams currently do.

Organisational readiness: making sure captures are usable when you need them

The most common way packet analysis fails during a real incident has nothing to do with analysis. Somebody asks for a capture from the affected segment, and the answer is that there is no sensor there, or the buffer rotated eleven hours ago, or the person with access to the tap infrastructure is on leave, or nobody is certain whether legal approval is needed to open a file containing employee traffic.

By then it is too late to fix any of it. Capture capability is infrastructure, and infrastructure has to exist before the event.

The one decision that shapes everything else is where the sensors sit. Perimeter capture sees traffic leaving the organisation and misses lateral movement entirely. Internal capture at core switching sees east-west traffic and generates volume most organisations cannot retain. Most teams need some of both and can afford full retention of neither, which is the real argument for flow records — NetFlow or Zeek logs — as a long-retention layer with full packet capture only in short rolling buffers at chosen points.

Capture policy basics:

Topic	Standard
Where to capture	Defined choke points — edge, data centre, key VLANs — chosen knowing that perimeter-only capture is blind to lateral movement
When to capture	Rolling buffers at chosen points, plus triggered full capture during incidents and periodic baselines
Retention	Short for full packets, long for flow records; state the actual window so nobody assumes more
Access	Least privilege over PCAPs and any TLS key material, with access itself logged
Privacy	Documented redaction and handling, agreed with legal and HR before an incident forces the question
Approval	A named path for authorising capture out of hours that does not depend on one person being reachable

What makes a “good PCAP” from an investigation standpoint:

Accurate timestamps from NTP-synchronised sources, with the timezone recorded rather than inferred
Interface and capture point documented at collection time, including which direction the SPAN was mirroring
Full frames rather than truncated ones — a snap length set to headers only cannot be undone later
Filtering decisions recorded: what the capture filter excluded, and why
No drops at the sensor, or the drop count recorded if there were
Associated artefacts linked: host logs, proxy logs, alert tickets, case IDs

Integrating capture capability into your IR runbook:

Define “capture now” versus “capture on request” trigger criteria, so the first response to an alert is not a debate
Pre-stage capture tools or scripts on critical hosts and segments — installing tcpdump on a host you suspect is compromised is both slow and evidentially awkward
Document the escalation path to network engineering, with an out-of-hours contact, since most capture requests need someone with switch access
Record who may authorise capture of traffic containing employee data, and how that is obtained at 3 a.m.

Training and validation:

Run a quarterly end-to-end drill on a deliberately benign scenario — a DNS lookup and a TLS handshake from a known host is enough. The analysis is not the point. The point is to exercise the whole chain: request the capture through the real approval path, have the network team produce it, confirm the timestamps line up with the SIEM, and check that the analyst who needs it can actually get access.

What this surfaces is consistently the same set of problems, and all of them are cheaper to find now: a segment with no sensor, a buffer far shorter than anyone believed, a switch whose SPAN configuration was changed during a migration, an approval that requires a person who has left. Every one of those is invisible until you ask for a capture, and finding them mid-incident costs hours you will not have.

90-day plan for building a packet analysis capability

Days 1–30: Establish the foundation

Establish where you can actually capture today, and write down the segments where you cannot — the gap list is the most valuable output of the first month
Standardise PCAP handling and summary templates so every case produces comparable artefacts
Run weekly triage drills on labelled public captures, mixing benign scenarios in unannounced
Baseline current analyst timing and decision quality, so later improvement is measurable rather than asserted

Days 31–60: Improve integration and decision quality

Fix timeline correlation first: confirm every relevant system is NTP-synchronised and that everyone records in one timezone. This is the least interesting item here and reliably the highest-value one
Refine the escalation matrix using what the drills reveal about where analysts disagree
Build a library of reusable filter sets and playbook snippets for the scenarios you actually see
Close the highest-priority capture gaps identified in the first month, or record a formal decision not to

Days 61–90: Embed into operations

Feed packet findings back into detection engineering — every confirmed pattern that packets caught and the SIEM did not is a detection rule waiting to be written
Track decision time and false escalation rate together, since improving either alone is easy and meaningless
Publish the operating standard the team has converged on, and set a date to revise it

KPI	Why It Matters
Cases with a complete evidence chain	Whether findings would survive scrutiny months later
Mean time to triage decision	Response efficiency — meaningless without the accuracy measure beside it
Multi-source corroboration rate	How often conclusions rest on packets alone, which they should not
False escalation rate	Decision accuracy, and the leading indicator of eroding trust
Capture request fulfilment time	Whether the capability exists at all when someone asks for it

Almost none of this guide is about Wireshark. That is the honest summary: filter syntax takes an afternoon to learn, while knowing which question to ask, whether the capture could ever have answered it, and what to do with a partial answer takes practice and structure. Encryption has narrowed what packets reveal and sharpened what they uniquely prove — timing, volume, direction, and the connections no agent ever logged.

The teams that get value from this are not the ones with the best analysts. They are the ones where the sensors were already in place, the timestamps already line up, the approval path already works at 3 a.m., and the workflow is the same on the quiet Tuesday case as on the bad one.