OT and Network Forensics

What a Usable Capture Has to Contain

The capture point decides what exists in the file, and no amount of analysis recovers what was never recorded. A network TAP copies the link itself and is not subject to the switch's forwarding load, although an aggregating TAP that merges both directions of a busy full-duplex link into a single output can still oversubscribe that output. A switch mirror, SPAN, or monitor session is a software function competing with forwarding: mirroring several gigabit ports into one gigabit destination discards frames once the summed load exceeds line rate. Many switches expose mirror drop counters, but those drops leave no trace in the capture file itself, so an analyst reading only the file sees a conversation that looks intact and is not.

What the capture point can see is a separate constraint from whether it keeps up. On a switched network, a mirror of a single access port carries that device's traffic and nothing else. Broadcast and multicast are flooded within the VLAN and turn up almost anywhere in it, which is why BACnet Who-Is and I-Am exchanges survive a poorly chosen capture point while a unicast Modbus/TCP poll between two devices on a different switch is simply absent. Traffic between VLANs exists only where it is routed, so the router or firewall interface is the capture point that sees it.

Two capture settings decide what analysis is possible later. A snaplen truncates each frame to a fixed number of bytes, which is enough for flow, topology, and header-level protocol work and destroys payload decode and file carving; captures configured for long unattended runs are the ones most likely to have it set. Duration works the same way: a fault that occurs twice a day is unlikely to appear in a five minute capture, and the window has to be long enough to contain the event rather than long enough to feel thorough.

• A mirror session configured in one direction only yields half of every conversation, which reads as unanswered requests rather than as a capture problem.
• A ring buffer bounds disk use by overwriting the oldest files, so an unattended capture waiting on an intermittent fault needs enough total space that the event is still on disk when someone goes looking for it.
• Capture-time BPF filters are irreversible. Where disk allows, capture unfiltered and filter during analysis.
• Some NIC drivers strip 802.1Q tags before the capture library sees them. If VLAN membership is part of the question, a short test capture confirms whether tags are present.
• Promiscuous mode has to actually be in effect. Virtualized capture hosts and vSwitch port groups commonly reject it by default, and the resulting file contains only traffic addressed to the capture host plus broadcast.
• Which switch and port the file came from, and what was connected to it, are worth recording at capture time, because nothing in the file identifies the capture point.

Ports, Filters, and What They Quietly Exclude

A capture taken "for BACnet" is often taken with a filter naming one port, and that filter settles the investigation before anyone opens the file. Most of these protocols occupy more ports than their headline number, and several of the conditions worth finding live on the ports that got excluded.

The opposite failure is the correct port with the wrong assumption about what a port identifies. A dissector decodes traffic on a well-known port as that protocol by default, so a device configured on a nonstandard port is not decoded at all until an analyst forces it with Wireshark's Decode As, and unrelated traffic that happens to use a reserved port gets decoded as the protocol and produces malformed-packet noise that reads convincingly like a device fault.

Address identity is a related trap. An IP address is not a device identity in several of these protocols: a Modbus/TCP gateway fronting serial devices presents one IP for many devices, and the MBAP unit identifier is the field that separates them. In BACnet, devices are identified by network number and device instance, and an MS/TP device behind a BACnet router never appears with an IP address of its own. Asset inventories built from IP addresses alone undercount exactly the sites that lean hardest on gateways.

• BACnet/IP: UDP 47808 (0xBAC0), with additional networks commonly configured on 47809 through 47823. BBMD traffic arrives on those same ports as Forwarded-NPDU rather than as a plain broadcast.
• Modbus/TCP: TCP 502.
• S7comm: TCP 102, carried over ISO-on-TCP (RFC 1006) with TPKT and COTP beneath it. S7comm-plus on newer controllers uses the same port with a different protocol above it.
• DNP3: TCP or UDP 20000.
• IEC 60870-5-104: TCP 2404.
• EtherNet/IP: explicit messaging on TCP 44818, implicit Class 1 I/O on UDP 2222, multicast or unicast at a fixed requested packet interval. A filter that keeps only 44818 removes the control traffic and keeps the configuration chatter.
• OPC UA: TCP 4840 for the opc.tcp binary transport, with HTTPS-based transports on other ports.
• MQTT: TCP 1883 in the clear, 8883 over TLS.
• SNMP: UDP 161 for polling and 162 for traps. Traps are the unsolicited ones, and the ones a polling-shaped filter drops.
• Omron FINS: UDP 9600, with the TCP variant on the same number.
• GE SRTP: TCP 18245.

What a Passive Capture Cannot Tell You

Encryption bounds what a capture yields, and the bound is not uniform. OPC UA offers three security modes: None leaves the payload readable, SignAndEncrypt hides it, and Sign signs each message without encrypting it, so the payload remains readable and only integrity is guaranteed. MQTT on 8883 and HTTPS management interfaces hide payload outright. What survives encryption is metadata: which endpoints talk, when, how often, in what volume, and which certificates and cipher suites were offered during the handshake. That is enough to build topology and notice a new talker, and not enough to reconstruct a transaction.

A capture contains only what crossed the wire during the window. Changes made at a controller's front panel, over a serial console, from a USB stick, or from an engineering laptop plugged into a service port leave nothing in a network capture. Modbus RTU and BACnet MS/TP traffic on RS-485 is invisible for the same reason; only the gateway's IP-side conversations exist as packets.

Some things look measurable from the file and are not. A packet's timestamp is the capture host's timestamp, so latency read from a capture is the round trip as observed at the capture point, and delay added downstream of the mirror gets attributed to a controller that did not cause it. Devices that were powered off, unplugged, or simply idle during the window do not appear at all, which makes an inventory built from a capture a lower bound on what is on the network rather than a census.

Handling a Capture as Evidence

A capture is an ordinary file, and almost everything that makes one hold up as evidence is procedural rather than technical. Standard forensic practice is to hash each file as received, keep the received copy untouched, and work from copies, so that the file examined can be shown to be the file that was handed over. Rotated captures are hashed per file rather than only after a merge, because merging produces different bytes than the set it came from.

Format matters more than it appears to. Classic pcap stores one link type for the whole file, microsecond or nanosecond timestamps depending on the magic number, and no place for interface or capture-host metadata. pcapng stores multiple interfaces in a single file, per-interface link types and timestamp resolution, comments attached to individual packets, and a section header block recording the capture host and application. Converting pcapng to pcap discards all of that permanently, which is why the conversion done for a tool that cannot read pcapng is done on a copy.

Packet timestamps are stored as an offset from the Unix epoch, which is UTC; the local time shown is the reading program's interpretation using its own time zone. Two captures taken at different sites and lined up by wall clock are off by whatever the two capture hosts' clocks were off by, and nothing in either file discloses that offset. Any timeline built from packets is therefore anchored to a clock whose synchronization is known, or stated with the uncertainty attached.

Choosing This or an Adjacent Engagement

What separates capture analysis from an assessment is the object of study, not the timing. An OT and ICS security assessment examines architecture, segmentation, remote access paths, and device and firewall configuration, which are facts about how the network is built and remain true whether or not any traffic was ever recorded. Capture analysis examines one recorded window and can report only what was observable inside it. A site asking whether its remote access is exposed is asking a configuration question; a site asking what was actually talking last Tuesday afternoon is asking a capture question.

Continuous detection is a third category. A site that wants an alert when a new device appears or a controller is written to needs a monitoring system deployed on the network and evaluating traffic as it arrives; capture analysis is a bounded look at a recorded window and does not become continuous by being repeated.

Some problems are cheaper to settle without forensics at all. When a symptom is reproducible on demand, a controller's own diagnostics, a switch's interface error counters, and the vendor's engineering tool usually identify it faster than a capture will. Capture analysis earns its place when the problem is intermittent, when the question is what happened rather than what is happening, or when the answer has to survive being disputed.