CRS-WSH-02
Wireshark packet capture, TLS handshake analysis, and network traffic forensics
Application logs record only what software authors chose to print, whereas raw network frames show every actual byte leaving or entering a network interface. Wireshark and its command-line companion tshark enable an engineer to reconstruct transport sessions, verify negotiated cipher suites, and spot unauthorized outbound connections.
1. Privilege-separated packet capture and TLS 1.3 frame anatomy
dumpcap filters raw frames in kernel memory into bounded pcapng files, while unprivileged dissectors inspect transport flags and plaintext TLS 1.3 handshake extensions.2. Separating capture filters from display filters and reading encrypted flows
Protocol dissectors parse complex binary structures from untrusted network traffic, so running the graphical Wireshark interface with superuser privileges creates unnecessary attack surface. Production engineers capture packets into ring-buffered pcapng files using minimal dumpcap capabilities and analyze those saved captures under an unprivileged workstation account.
Beginners frequently confuse Berkeley Packet Filter (BPF) capture syntax such as tcp port 443, which discards unselected frames at the kernel buffer, with Wireshark display filters such as tls.handshake.type == 1, which selectively query parsed protocol fields inside a recorded trace.
Even when application payloads are encrypted under TLS 1.3, passive packet inspection reveals destination network addresses, DNS queries, Server Name Indication (SNI) hostnames, Application-Layer Protocol Negotiation (ALPN) tokens, and payload timing patterns. In an isolated laboratory stand, setting the SSLKEYLOGFILE environment variable in a test client allows full session decryption inside Wireshark without installing middlebox certificates.
| Command, Display Filter, or Primitive | Observed Technical Artifact | Operational Interpretation |
|---|---|---|
tcp.flags.syn == 1 && tcp.flags.ack == 0 | Initial TCP connection attempts across the trace | Pinpoints outbound connection bursts, port sweeps, or unexpected backend callbacks |
tls.handshake.type == 1 | All TLS ClientHello handshake frames | Exposes requested SNI hostnames, offered protocol versions, and cipher lists |
dns.flags.rcode != 0 || frame.len > 240 && dns | Failed domain lookups and unusually long DNS packets | Detects domain-generation lookups or encoded data exfiltration over port 53 |
http.request || http2.headers.method | Cleartext HTTP/1.1 and decrypted HTTP/2 request headers | Reveals unencrypted internal service traffic and leaked bearer credentials |
tshark -r trace.pcapng -T fields -e ip.dst -e tls.handshake.extensions_server_name | Tab-separated summary of destination addresses and target server names | Extracts a complete inventory of external hosts contacted during an agent or service run |
3. Laboratory capture practicum and connection to in-path wire filtering
pcapng files with unprivileged dissectors, reconstructing TCP streams, inspecting plaintext TLS handshake extensions, and isolating anomalous outbound calls.In the exercise below, the practitioner records sixty seconds of loopback and staging traffic into a size-bounded capture file, extracts every contacted server name with tshark, and checks whether any third-party analytics or metadata address was contacted.
# 1. Capture scoped traffic on interface eth0 into a 50 MB ring buffer (no root GUI)
dumpcap -i eth0 -f "tcp port 443 or port 53" -b filesize:51200 -b files:4 -w /tmp/lab_egress.pcapng
# 2. Extract every TLS ClientHello destination IP and SNI hostname with tshark
tshark -r /tmp/lab_egress.pcapng -Y "tls.handshake.type == 1" \
-T fields -e frame.time_epoch -e ip.dst -e tls.handshake.extensions_server_name
# 3. Verify zero cleartext HTTP or metadata 169.254.169.254 requests in the trace
tshark -r /tmp/lab_egress.pcapng -Y "ip.dst == 169.254.169.254 || http.request" While Wireshark inspects frames passively after or during transmission, preventing damage to live databases requires stopping hazardous payloads before they reach the kernel socket. That exact pre-socket principle drives Stage L3 of INDRA (IB30-ZHS-03), class SSRF-INT, and the passive cross-border scanner TOOL-152-02.
4. Engineering reference notes for module CRS-WSH-02
Inspecting HTTPS traffic in a laboratory environment without breaking certificate validation
When running curl, Python test scripts, or Chromium in an isolated lab, exporting SSLKEYLOGFILE=/tmp/tls_keys.log writes per-session ephemeral secrets to disk so Wireshark can decrypt the captured TLS 1.3 frames cleanly.
Reason to run packet capture with dumpcap instead of launching Wireshark as root
Wireshark contains millions of lines of protocol dissector code that parse untrusted packet bytes; capturing with minimal CAP_NET_RAW rights in dumpcap and opening the file as a regular user prevents dissector bugs from compromising the host.
Advantage of the pcapng container format over legacy pcap files during forensic audits
Unlike legacy pcap files, pcapng stores interface hardware metadata, packet drop counters, name-resolution blocks, and optional embedded decryption secrets directly alongside captured frames for reproducible verification.
Preventing disk exhaustion during multi-hour packet captures on busy network links
Passing ring-buffer flags -b filesize:51200 -b files:4 together with a strict BPF kernel filter bounds total disk consumption deterministically while retaining recent frames surrounding an incident.
Enterprise pilot packages and air-gapped delivery
Perimeter posture, transport security & localization
Streebog-256 verification passport.Air-gapped interface verification (indra-core)
OpenAPI schemas and an isolated staging container as input, delivering a thirty-class paired decoy assessment with zero false positives, compiled mcp-sentinel contracts, and a full ledger passport.Autonomous agent runtime gate (MITR)
mcp.json manifests and tool schemas as input, delivering compiled satisfiability policies and pre-socket parameter enforcement.Request the offline kit or schedule a pilot
--no-index --find-links) and standalone verifier scripts are provided for isolated laboratory testing and enterprise pilot evaluations. Submit a work email below without page reload or write directly to af@isslab.ai.
Institutional developer and platform operator
OGRN 1267700083617, INN 9731161602, KPP 773101001, 18 Davydkovskaya Street, Suite VIII, Moscow, 121352). Under the Security 3.0 research and engineering program, the institute develops and operates the MITR runtime action gateway and the INDRA verification stand, publishes the monograph Proven Action, and maintains open Apache-2.0 software packages with zero outside subcontractors.