Preserve the capture before narrowing the view
Record the original capture, interface, capture filter and snapshot length before applying a display filter. Filtering the view does not sanitize secrets in the file or recover packets that were never captured. Keep a filtered export separately labelled with its selection rule. A packet rhythm or one candidate connection cannot alone prove command execution or a privilege change; correlate only with permitted endpoint evidence. Source and scope.
A new TCP connection, small packets or a changed HTTP response can guide an investigation. None of them alone proves a shell. For an authorized Kioptrix exercise, compare a recorded baseline with a specific permitted action, then correlate the capture with listener output and target-side evidence. Report what happened and what remains unknown.
This is a documentation-based workflow, not a published packet-capture experiment or a personal exploitation account. Examples are illustrative; no supplied PCAP has been analyzed here. Official sources checked: October 16, 2026. Seven checks organize the review—they are not seven mandatory packets or a guaranteed sequence.
Set up a capture you can interpret
Record the VM names, current addresses, enabled adapters, hypervisor network names and intended source-to-destination path. Choose a capture point that can observe that path. Capturing inside the tool VM can help observe its own exchanges; capturing on the physical host does not automatically expose all guest-to-guest traffic.
Wireshark’s Ethernet capture guide explains the difference between observing your own traffic and traffic between other machines on a switched network. Promiscuous mode does not make a switch deliver every conversation to your interface. Any mirror or other capture arrangement must be authorized and checked for the actual topology.
In Capture Options, confirm the interface and associated addresses, capture filter, snapshot length and output file. Snapshot length limits bytes retained per packet; truncation can remove evidence you later need. Start before a known, approved benign service exchange, note its time and verify the expected endpoints in the capture. Missing traffic is a visibility question before it is a verdict about the target.
Keep deliberately vulnerable guests off household and workplace networks. Review additional adapters, forwarding, VPN paths and host integrations. The related VirtualBox network-mode guide explains why Host-Only includes the host and why NAT is not a general isolation guarantee. Do not switch a target to Bridged merely to make a capture appear.
Seven checks for before-and-after analysis
1. Confirm the addressing and route context
An ARP exchange can help explain IPv4 neighbor resolution on a local Ethernet segment; it does not establish application reachability. Cached neighbors can mean no fresh ARP appears, and routed traffic resolves the local next hop rather than the remote target’s MAC address. DNS is not required when an exercise uses a literal address. IPv6 uses Neighbor Discovery rather than ARP.
Nmap’s host-discovery reference distinguishes local ARP/IPv6 discovery from IP probes and notes proxy-ARP caveats. Match observations to the recorded route and approved service exchange. A missing ping reply or absent ARP is not enough to declare the target down or the interface wrong.
2. Separate transport responses from service success
If an authorized baseline scan is part of the exercise, record its actual type and scope. Nmap’s SYN-scan explanation distinguishes SYN/ACK, reset and non-response results. A SYN scan normally does not finish an application conversation. A completed TCP handshake supports a connection observation, not a claim that an exploit ran.
Compare the same endpoint, protocol and port before and after the action. Save capture times and relevant frame numbers. Silence can reflect filtering, loss or a missing observation point; it cannot identify one cause on its own. Do not expand a scan because a narrow comparison is inconclusive.
3. Preserve the application exchange and its limits
Where visible, record the request, response, status and advertised product as observations. A header can be changed, omitted or supplied by a proxy. A banner does not verify the active backend build, security patch status or vulnerability prerequisites. The CVE mapping workflow explains how to keep a candidate version match separate from an affected-build finding.
Wireshark’s reassembly guide explains that application messages can span TCP segments. One frame is not necessarily one request or command. A capture that starts mid-connection, truncates data or drops packets can leave an incomplete application view. Preserve those limits in the report instead of interpreting missing bytes as absent activity.
4. Correlate a permitted action with the capture
Record the action time and expected request path before an approved lab step. Locate matching endpoints, protocol fields and application data where available. A larger request, an HTTP 500 response or a nearby outbound connection is a lead for correlation. Those changes do not independently establish exploit delivery or successful execution.
Keep plausible alternatives, such as an ordinary upload, application error or background request. If the payload is not visible or the endpoint record is missing, state the gap. There is no universal byte-size threshold, response-code transition or timing window that proves exploitation.
5. Identify a candidate connection, then verify its purpose
Use the expected listener address and port, the connection initiator and the action log to identify a candidate stream. A target-initiated connection can be ordinary application activity. A shell can also reuse an existing connection, and some techniques produce no interactive shell. Do not require a new callback to classify every successful lab action.
Wireshark’s Follow Stream guide describes selecting a packet and using Analyze → Follow → TCP Stream or the packet-list context menu. Inspect both directions and record the stream index in this capture. A stream index is a local reference, not an identifier to carry unchanged into a different file. Reopen the stream dialog to refresh it during a live capture.
6. Verify execution with evidence beyond packet rhythm
In an authorized training scenario, correlate an agreed benign command and its expected output with the listener and available target logs. A unique harmless marker can help tie the result to the recorded action. Record the responding endpoint and execution context. A successful identity check supports that observed result; it does not demonstrate administrator privileges, persistence or every possible command.
Many small packets, a quiet interval or one burst cannot establish a stable shell, a failed shell or a TTY problem. Encrypted and binary protocols may not show readable command text. The Wireshark TLS guide explains the need for appropriate secrets for decryption. Use only authorized material; protect key logs and capture files containing secrets. Without decryption or endpoint evidence, keep the execution conclusion unresolved.
7. Describe any data movement precisely
Compare observed destinations, application operations and transferred content with the exercise plan. A TCP byte count does not prove which file was transferred or that a credential was disclosed. When an approved test transfer is necessary, use a harmless test object and compare the endpoint result. Do not retrieve real secrets merely to make a screenshot convincing.
Review unexpected destinations without extending testing beyond scope. Separate “connection observed,” “application transfer observed” and “content verified.” Record capture visibility and encryption limits. Keep only the evidence needed for the agreed purpose, and review data and embedded decryption material before sharing a derived capture.
Use display filters for a specific question
Wireshark’s capture-filter guide uses a different language from display filtering: tcp port 80 is a capture-filter example; tcp.port == 80 is a display-filter example. A capture filter excludes traffic before it is stored. A display filter changes the view and does not sanitize the underlying file or recover traffic never captured.
For the following display-filter examples, replace the documentation-only addresses with the two authorized IPv4 endpoints. The address-pair expression selects either direction; it omits ARP, IPv6 and exchanges with third parties such as a DNS server. For tunneled traffic, identify which protocol layer you are comparing. These examples were checked against documentation, not run on your capture.
(ip.src == 192.0.2.10 && ip.dst == 192.0.2.20) ||
(ip.src == 192.0.2.20 && ip.dst == 192.0.2.10)The display-expression guide explains a critical Boolean distinction: tcp.flags.syn tests whether the field is present; tcp.flags.syn == 1 tests whether SYN is set. Use explicit comparisons when the flag value matters.
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.flags.reset == 1
tcp.stream == 0
tcp.len > 0
http
arpThe TCP field reference documents these fields. The first line selects SYN without ACK; the second selects resets. Replace stream 0 with the index you identified. tcp.len > 0 selects TCP segments with payload, which can be encrypted or retransmitted. http selects decoded HTTP, not all web traffic. Apply each expression to answer its own question; none is a shell detector.
For suspicious loss or reset behavior, consult Wireshark TCP analysis. Analysis flags describe detected or potential conditions in the observed packet sequence. They are not an exploit verdict. Investigate capture completeness and the endpoint behavior before assigning a cause.
Save an evidence record you can reproduce
Use this template to connect each conclusion to an observation and identify missing evidence. Time spent does not measure evidential quality. Keep the original capture and identify any filtered export separately; a later reviewer needs to know what was excluded.
Exercise scope / authorized systems:
VM addresses / adapters / network paths:
Capture point / interface / Wireshark version:
Capture file / start and stop / time zone:
Capture filter / snapshot length / known gaps:
Baseline event / frame numbers / stream:
Permitted action / timestamp / expected result:
Observed change / relevant frame numbers:
Listener or endpoint corroboration:
Conclusion / alternative explanation / missing evidence:
Data handling / derived exports / next action:Questions before drawing a conclusion
How do you confirm the capture point? Match a known approved exchange to its endpoints and time, then review whether that observation point covers the paths relevant to the exercise. One visible exchange does not establish complete visibility of the whole lab.
What if the stream is unreadable or quiet? Check encryption, protocol decoding and capture completeness. Correlate endpoint evidence rather than inferring execution from packet size or silence. Capture duration should cover the planned baseline, action and verification within the authorized collection period; no fixed two-minute interval guarantees completeness.
What should you do next? Open one existing authorized lab capture and document a single exchange with its limits. Avoid rerunning an exploit just to fill an incomplete timeline. Confirm written scope, collection permissions and applicable rules before any new capture; this guide does not make a country-specific legal determination.