Live Packet Capture, Traffic Analysis and Deep Packet Inspection

A packet capture is only as honest as the point at which the packets are copied. The four common capture points are the host NIC in promiscuous mode, a switch SPAN (also called mirror) port, a passive network tap, and an inline tap on an IDS/IPS path. Each has a known failure mode that the analyst needs to declare in the report.

A switched LAN does not deliver other hosts' frames to a random port. Setting a NIC promiscuous on a port that the switch is not mirroring captures the host's own traffic plus broadcast and multicast, and nothing else. A common analyst error is to connect a laptop to a free access-switch port, enable promiscuous mode in Wireshark, and treat the resulting silence as evidence that the LAN is idle. The fix is either a SPAN configuration on the switch or a tap on the uplink.

A SPAN port on an Indian campus switch (Cisco Catalyst 9300 series, Aruba CX, Juniper EX) is configured with a one-line monitor session 1 source interface ... destination interface ... pair, but the operational gotcha is that SPAN drops are silent. The Catalyst will quietly drop mirrored frames when the destination port is congested, and the only signal is a counter on show monitor session 1. A report that does not record the SPAN counters at start and end of the capture leaves a hole the defence can drive through.

Wireless monitor mode is the corresponding capture point for 802.11. The radio listens on one channel at a time; a survey capture uses channel hopping (a small daemon retunes the radio every 250 ms across the 2.4 GHz and 5 GHz channels). The drawback is that a hopping capture sees only a fraction of any given conversation, so an attack reconstruction usually pins the radio to the suspect channel after the initial survey identifies it.

The Indian SOC toolkit is largely open source. Wireshark is the GUI of record, and Indian cyber-forensics training programmes (CFSL Hyderabad, MHA training and others) build on it. Underneath Wireshark sits libpcap on Linux and macOS or Npcap on Windows; the same library backs tcpdump, tshark and dumpcap.

• Wireshark is the GUI front end. Best for explanation, education and one-off cases. Memory-bound on large PCAPs; a 4 GB PCAP loads slowly on a laptop and crashes on a workstation under 16 GB RAM.
• tcpdump is the canonical CLI capture and read tool. tcpdump -i eth0 -w out.pcap -s 0 -G 600 -W 12 rotates a one-hour ring of twelve files. Production captures should always use rotation; a single ever-growing file is a hostage to disk space.
• tshark is the Wireshark CLI. Same dissectors as the GUI, scriptable, suitable for batch extraction of fields with -T fields -e <fieldname>.
• dumpcap is the low-level capture engine that Wireshark and tshark spawn. Strip-down design, minimal CPU, suitable for high-rate capture on a sensor.
• capinfos prints PCAP metadata (file size, packet count, capture duration, average rate, hash). Run it on every PCAP at acquisition and again before report tender; the SHA-256 from capinfos goes on the chain-of-custody log.
• mergecap merges PCAPs in timestamp order. Useful when two directions of a full-duplex tap are captured on separate NICs.
• editcap trims, splits and time-shifts PCAPs. The -A and -B flags slice by time range; useful for tendering only the relevant window into court.
• Zeek (formerly Bro) is a network analysis framework that produces indexed, human-readable logs (conn.log, dns.log, http.log, ssl.log, files.log, x509.log) instead of raw packets. The right tool when the question is "what happened on this network over six months" and a PCAP ring is impractical.
• Packetbeat (Elastic) ships flow and protocol-decoded events into Elasticsearch for SIEM-style querying.
• NetFlow / sFlow / jFlow collectors (nfdump, SiLK, ntopng, Plixer Scrutinizer) consume flow records from routers and switches. A flow record is one summary line per conversation: addresses, ports, protocol, bytes, packets, start and end time, TCP flags ORed across the flow.

The architectural rule is to capture full PCAP at the sensor for a short window (24 to 72 hours), index Zeek logs for medium term (weeks to months), and keep flow records for long term (years). An Indian Tier-3 bank SOC typically runs all three: full PCAP on a 200 TB SSD ring at the perimeter, Zeek logs into a hot Elasticsearch tier, and IPFIX flow records into a SiLK or nfdump archive.

The classic PCAP file format (libpcap, 1990s vintage) is simple: a global header followed by per-packet records, each with a timestamp, captured length, original length and packet bytes. One link-layer type per file, no annotations, no comments, no per-interface metadata. The format is small, fast and brittle.

PCAPng (PCAP Next Generation) is block-structured. Each block has a type, a length, a body and a length trailer. The relevant blocks for the forensic analyst are:

• SHB (Section Header Block) opens a section and records the writer (Wireshark 4.4.0, tcpdump 4.99, Zeek 6.0), the byte order, and an optional comment.
• IDB (Interface Description Block) describes one capture interface: link-layer type, snap length, time resolution, OS, and the BPF filter that produced the capture. Multiple IDBs in one file means multiple interfaces were captured together.
• EPB (Enhanced Packet Block) carries one packet with timestamp, interface ID, captured length, original length, packet bytes, and an optional comment block. The comment is where analyst annotations go ("payload XOR-decoded below as plaintext").
• ISB (Interface Statistics Block) carries per-interface counters at the end of the capture: packets received, packets dropped, packets accepted by filter.
• DSB (Decryption Secrets Block) carries cryptographic material for offline decryption. The supported types include TLS Key Log (the NSS keylog format that Firefox and Chrome write when SSLKEYLOGFILE is set), WireGuard keys, and IKEv2 keys.
• NRB (Name Resolution Block) carries DNS name-to-address mappings captured during the session, for offline display.

The Decryption Secrets Block matters more than any other change. Before DSB, an analyst who wanted to decrypt a TLS session in Wireshark had to ship a sidecar keylog file alongside the PCAP and ensure both arrived at court together as separately authenticated artefacts. With a DSB the keys travel inside the PCAPng, hashable as one artefact, certifiable under Section 63 BSA as one electronic record. Wireshark since 3.0 reads and writes DSB; tshark can inject keys with editcap --inject-secrets tls,keylog.txt in.pcapng out.pcapng.

The practical rule for Indian cases is to write PCAPng with secrets blocks when TLS decryption is in scope, write classic PCAP only when interoperability with an older toolchain demands it, and never strip the comments out of an EPB during evidence handling because the comments carry the analyst's working notes that the trial court is entitled to see.

The five-tuple is the smallest unit of network identity that the analyst quotes in a report: source IP, destination IP, source port, destination port, and the L4 protocol number. Two packets with the same five-tuple belong to the same conversation; the same five-tuple swapped (src and dst exchanged) is the return half of the same conversation. Wireshark's Conversations dialog and tshark's -z conv,ip and -z conv,tcp aggregate by five-tuple and quote bytes and packets each way.

TCP flag analysis is the next reading skill. The six classic flags carry meaning that the analyst reads at a glance.

Stream reassembly is the third skill. A TCP stream is a sequence of segments with monotonically increasing sequence numbers; Wireshark's Follow Stream rebuilds the full byte stream in each direction from the segments and presents it as readable text or hex. From the rebuilt stream the analyst extracts the HTTP request, the SMB write, the FTP RETR, or the IRC line. File > Export Objects in Wireshark walks the HTTP, SMB, FTP, IMF (email) and TFTP dissectors and writes every file body the capture observed to disk, named by the URL or filename in the protocol. This is the function that recovers the malware binary that the dropper fetched, the exfiltrated CSV, or the document that the suspect uploaded.

VoIP call decode is the loud demonstration of stream reassembly. Wireshark's Telephony menu walks the SIP signalling and the matching RTP streams; the RTP Player tab decodes G.711, G.722, GSM and AMR codecs to playable audio. A captured VoIP call from a cooperative ISP under a lawful intercept warrant is rendered as audible evidence with a few clicks, with the SIP INVITE timestamps as the timeline.

A network IDS (Snort, Suricata, Zeek) sits inline or on a SPAN and matches traffic against a rule set. Snort rules and Suricata rules share most of the syntax: an action, a header (protocol, src, sport, direction, dst, dport) and a body of options (content, pcre, flowbits, classtype, sid, rev).

A simplified rule that flags a common SQLMap user-agent reads:

alert http any any -> $HTTP_SERVERS any (msg:"SQLMap probe via User-Agent"; flow:to_server,established; http.user_agent; content:"sqlmap"; nocase; classtype:web-application-attack; sid:1000101; rev:1;)

Rule categories that an Indian SOC actively tunes include exploit-kit (Fallout, RIG, Underminer), malware-callback (Cobalt Strike default profiles, Sliver C2, AsyncRAT), scan (Nmap fingerprint, masscan), policy-violation (Tor traffic, BitTorrent on a corporate VLAN), and web-application-attack (SQL injection, XSS, command injection, path traversal). The Emerging Threats Open rule set, ET Pro, and the Snort VRT community set are the three feeds most SOCs combine.

SQL injection detection in HTTP traffic is a payload-pattern problem at the IDS layer and a behavioural problem at the WAF and DB-log layer. The classic SQL injection patterns the IDS matches include single quote followed by OR followed by digit-equals-digit (' OR 1=1), UNION SELECT, INFORMATION_SCHEMA.TABLES, and the SQLMap-specific shape of a probe request (a long parameter value with quote, semicolon, comment marker --). The cross-link to the broader attack catalogue is the Network Attacks topic which walks the SQL injection, XSS and ARP poisoning attack chains end to end.

Deep Packet Inspection (DPI) goes beyond IDS pattern matching to classify the application generating the traffic. nDPI (open source from ntop) and Cisco NBAR (proprietary, IOS) maintain protocol signatures for thousands of applications, classifying by combinations of port, payload heuristic, TLS SNI, and timing. DPI answers questions like "is this UDP/443 stream QUIC, WireGuard, or DNS over QUIC", which port-only analysis cannot.

Encrypted traffic forces a different style of analysis. Without the keys (no DSB, no key log, no MITM with a trusted CA on the endpoint), the analyst cannot read the body. What is still visible is the TLS handshake: the Client Hello carries the TLS version, cipher suites in the offered order, extensions in the offered order, supported elliptic curves and EC point formats. The MD5 hash of these ordered fields is the JA3 fingerprint of the client. The server's reply (Server Hello) hashes the same way to a JA3S fingerprint.

VPN traffic analysis applies the same fingerprinting. WireGuard sends a Noise IK handshake with characteristic packet sizes (148 bytes for handshake initiation, 92 bytes for response). OpenVPN over UDP has a recognisable opcode in the first byte of each datagram. Both, even when the payload is encrypted, present flow-record signatures (regular keepalive intervals, MTU-shaped data packets) that a NetFlow analyst can isolate. The point is that "encrypted" does not mean "invisible" at the network forensics layer.

NetFlow (Cisco), IPFIX (IETF standard, NetFlow v10 in practice), sFlow (Inmon, packet-sampling), and jFlow (Juniper) are flow record protocols. A router or switch with flow export enabled emits one UDP datagram per finished flow to a collector, summarising the conversation. Fields commonly present include src IP, dst IP, src port, dst port, protocol, ToS, ingress interface, byte count, packet count, start time, end time, and TCP flags ORed across the life of the flow.

Flow records are roughly three orders of magnitude smaller than full PCAP for the same traffic, so a flow archive can hold years where a PCAP ring holds days. Top-talkers, port-pair analysis, beacon detection (small periodic flows from one internal host to one external host), and exfiltration detection (large outbound flow on an unusual port) are flow-record questions. The collectors in production Indian deployments are nfdump and SiLK on the open-source side, and Plixer Scrutinizer, Cisco Stealthwatch (now Secure Network Analytics) and ntopng on the commercial side.

1. Confirm capture clock and SPAN counters
   Record NTP sync state and `show monitor session` counters before any capture. Note the timezone (IST, UTC+5:30) in the chain-of-custody log.
2. Start a rotating PCAP ring on the sensor
   tcpdump or dumpcap with -G and -W flags, writing PCAPng with snap length 0 (full frames). One-hour rotation is a workable default; tune to disk.
3. Bring Zeek up against the same SPAN
   Zeek produces conn.log, dns.log, http.log, ssl.log, files.log within minutes. These survive longer than the PCAP ring and index well in Elasticsearch or Splunk.
4. Enable flow export on the edge router
   Cisco: ip flow-export destination, ip flow-export version 9, and ip flow ingress on the relevant interface. Confirm flows arriving at the collector before relying on them.
5. Correlate firewall + DNS + endpoint logs
   In Splunk SPL, Elastic KQL or Wazuh, join firewall events by 5-tuple with DNS resolutions by query name and endpoint Sysmon events by process. The correlated event, not any single log source, surfaces the relevant activity.
6. Tender the artefacts with Section 63 BSA certificates
   Hash the PCAPng, the Zeek logs, the flow archive, and the SIEM export. One certificate over the source set, one over the derivative report.

Log correlation is the discipline that turns a flood of single-source events into a usable timeline. The classic Indian-SOC join is firewall accept events (source IP, dest IP, dest port, timestamp) against DNS query logs (which name resolved to that dest IP at that time) against Sysmon event 3 on the endpoint (which process opened the outbound socket). Splunk SPL expresses this as a transaction or a join on dest_ip plus a time window of 60 seconds. The result row reads "process powershell.exe on host HDFC-LAP-1124 made a DNS query for evil.example, resolved to 198.51.100.42, and opened TCP/443 to that address at 14:32:11 IST".

Honeypots and honeynets are the inverse strategy. Instead of filtering noise out of real traffic, deploy systems that only attackers would touch, and treat every byte as an alert. Low-interaction honeypots simulate a service: Cowrie emulates SSH and Telnet and logs every command typed by the attacker; Dionaea emulates SMB, FTP, MSSQL and lures malware to upload itself; Honeyd is the original tcp/udp simulator. High-interaction honeypots are real VMs (often Windows servers) with monitoring. The T-Pot framework from Deutsche Telekom Security bundles a dozen honeypots and a unified dashboard, and is the standard deployment in Indian academic honeynet projects (IIT Madras, IIIT Hyderabad, Indian Honeynet Project chapter). Honeyfiles and honeytokens are the lighter cousins: a fake credentials file in a network share, a fake row in a customer database with a unique email that pages the SOC when accessed.

Router and switch evidence collection closes the chain. The console log captures interactive commands typed at the device; the NVRAM dump preserves the startup configuration; the running configuration snapshot (show running-config) freezes the live config; show ip route, show arp, show mac address-table, show ip cef, and show interface counters preserve the live forwarding state. Memory analysis on routers (analogous to Volatility on Windows) is vendor-specific and rare; Cisco IOS XE supports request platform software process core to write a process core, and Cisco's CCAT (Cisco Compromise Assessment Tool) reads it. For the trial court, the running-config snapshot and the interface counters are the two artefacts the prosecution almost always quotes. Cross-link our Network Security topic for the full SIEM, firewall and PKI background that this section assumes.