Expert Info and Anomaly Indicators
Wireshark's Expert Information system automatically flags protocol anomalies — TCP window zero, retransmissions, malformed packets, protocol violations — and categorizes them by severity. For a forensics analyst, these flags aren't just network health indicators; they're potential attack signals. TCP window zero can indicate a SYN flood victim; protocol violations can indicate a crafted-packet attack or evasion technique; malformed TLS records may indicate a Heartbleed-style exploit attempt.
You've loaded a capture from during an active attack. You open Analyze → Expert Information. There are 847 "Note" level items (mostly retransmissions from legitimate congested network traffic), 23 "Warning" items (TCP window zero and protocol violations), and 3 "Error" items (malformed packets that don't parse correctly under any known protocol). Those 3 Error items are the first thing to investigate — malformed packets are either bugs or attacks.
Expert Information Severity Levels
Wireshark Expert Information Categories ═══════════════════════════════════════════════════════════════════ Analyze → Expert Information (or Ctrl+Shift+I) Severity levels (most to least severe): ┌──────────┬─────────────────────────────────────────────────────┐ │ ERROR │ Packet doesn't parse correctly — malformed or │ │ (red) │ truncated. Protocol dissector rejected it. │ │ │ Forensic meaning: could be exploit attempt, │ │ │ crafted packet, or partial capture │ ├──────────┼─────────────────────────────────────────────────────┤ │ WARNING │ Protocol violation or unusual condition. │ │ (yellow) │ Examples: TCP zero window, incorrect checksum, │ │ │ TCP sequence number out of order. │ │ │ Forensic meaning: network health issue OR attack │ ├──────────┼─────────────────────────────────────────────────────┤ │ NOTE │ Notable condition, not necessarily an error. │ │ (blue) │ Examples: TCP retransmission, duplicate ACK, │ │ │ reassembly required. │ │ │ Forensic meaning: usually network noise, not attack │ ├──────────┼─────────────────────────────────────────────────────┤ │ CHAT │ Normal protocol state changes. │ │ (grey) │ Examples: connection established, connection reset. │ │ │ Forensic meaning: informational, not an anomaly │ └──────────┴─────────────────────────────────────────────────────┘ Groups: ├── Sequence: TCP sequence number issues ├── Protocol: protocol-level violations ├── Malformed: packets that don't parse └── Reassemble: fragmentation/reassembly issues Click any Expert Info entry → jump to that packet in packet list
TCP Anomalies with Forensic Significance
| Expert Info type | Display filter | Forensic meaning |
|---|---|---|
| TCP Zero Window | tcp.window_size == 0 | Receiver's buffer full — either legitimate congestion or SYN flood victim. Under attack: high rate of zero-window packets from the same destination indicates it's overwhelmed. |
| TCP Retransmission | tcp.analysis.retransmission | Usually network congestion. Forensically: consistent retransmits in one session suggest an IPS/DLP dropping specific segments. |
| TCP Fast Retransmit | tcp.analysis.fast_retransmission | 3 duplicate ACKs triggered immediate retransmit. Usually benign packet loss. High rate in one session = suspicious. |
| TCP Dup ACK | tcp.analysis.duplicate_ack | Receiver signaling a gap. Normal in lossy networks. Excessive dup ACKs from one host = targeted packet dropping. |
| TCP Window Full | tcp.analysis.window_full | Sender filled receiver's window — receiver is slow or overwhelmed. |
| TCP Spurious Retransmit | tcp.analysis.spurious_retransmission | Retransmit of a segment that was already ACKed — TCP stack bug or capture artifact from SPAN. |
| TCP Keep-Alive | tcp.analysis.keep_alive | Keep-alive probe on a long-lived idle connection. Forensic red flag: C2 sessions often generate keep-alives. |
| TCP Previous Segment Not Captured | tcp.analysis.lost_segment | Wireshark didn't see a preceding segment — PCAP gap or capture missed a packet. |
Malformed Packets — Attack Signatures
Malformed packets in forensics PCAP — what they indicate:
1. Malformed TLS records
Display filter: ssl.record.length > 16384
OR: packets flagged as "Malformed Packet: SSL"
├── Normal TLS record max size = 2^14 = 16384 bytes
├── Oversized TLS record = Heartbleed-style exploit probe
│ (CVE-2014-0160 sent a heartbeat with length > actual payload)
└── Malformed ClientHello = evasion probe or fuzzing
2. ICMP with mismatched type/code combinations
├── Normal ICMP types: 0=Echo Reply, 3=Unreachable, 8=Echo Request
├── Type/code combination not in RFC = crafted packet
└── Used by Nping, hping, and some C2 tools for covert channels
3. IP fragmentation anomalies
Display filter: ip.flags.mf == 1 OR ip.frag_offset > 0
├── Fragmented packets: fragmentation is rare on modern networks
│ (path MTU discovery prevents it for most TCP flows)
├── Teardrop attack: overlapping fragments with bad offsets
└── Fragment offset = last fragment but MF bit set = malformed
4. TCP flag anomalies
Display filter: tcp.flags == 0 (NULL scan)
OR: tcp.flags.syn == 1 and tcp.flags.fin == 1 (SYN+FIN)
├── NULL scan (no flags): Nmap -sN — evades some stateless firewalls
├── XMAS scan (SYN+FIN+PSH+URG): Nmap -sX
├── FIN scan (FIN only, no ACK): Nmap -sF
└── These are anomalous; legitimate TCP never has these combinations
5. HTTP protocol violations
Display filter: http.response.code >= 400 followed by large body
OR: http.request.method that isn't GET/POST/HEAD/PUT/DELETE
├── CONNECT method to non-port-443 = tunneling attempt
├── HTTP method PROPFIND/MKCOL = WebDAV (often legitimate)
└── HTTP/0.9 requests = very old client or evasionMost Expert Info Notes are benign — retransmissions and duplicate ACKs are normal in any busy network. But Expert Info Errors and unusual Warnings deserve individual inspection before dismissal. Open Expert Info, click "Error" tab first, then "Warning" tab. For each entry, click it to jump to the packet, examine the raw bytes in the Bytes pane, and ask: does this look like a random network error, or does it look like a crafted packet? A single malformed TLS record in 2 million packets is not network noise — it's a probe or exploit attempt. The volume of normal Expert Info items makes it easy to miss the one attack-related entry if you dismiss the category wholesale.
Checksum Offload — False Positive Warnings
TCP/IP Checksum Offload — Why Wireshark Shows "Bad Checksum"
═══════════════════════════════════════════════════════════════════
Modern NICs perform TCP/IP checksum calculation in hardware (offload).
When Wireshark captures on the SENDING host, the NIC hasn't filled in
the checksum yet when Wireshark sees the packet — the checksum field
is 0x0000 (placeholder).
Wireshark reports this as:
[EXPERT WARNING: Bad TCP checksum 0x0000, should be 0x3f2a]
This is NOT an error in your capture. It is an artifact of capturing
on the originating host vs. capturing on the wire.
How to distinguish:
├── If you capture on a tap or SPAN: checksums will be correct
├── If you capture on the originating host: checksums will be "bad"
└── The warning is uniform across all packets from that host
To suppress the false-positive warnings:
Edit → Preferences → Protocols → TCP
→ Uncheck "Validate the TCP checksum if possible"
(Same setting exists under IPv4, UDP)
Forensic implication:
A "bad checksum" in a capture from a tap/SPAN (not the originating host)
IS suspicious — it suggests a crafted packet or off-path injection.
Q & A
Q: I see TCP packets with a window size of 0 from the same host over and over. Is this an attack?
Repeated TCP zero-window from the same host can indicate three different scenarios: (1) Legitimate resource exhaustion: the host's TCP receive buffer is full because the application isn't reading data fast enough. This is common when a server is overloaded. Look at the follow-up: does the window re-open (window update packet from that host) after a short delay? If yes, it's resource pressure, not an attack. (2) SYN flood attack victim: if the host under attack has many half-open connections consuming its TCP backlog, it may advertise zero-window to slow down all incoming data. Correlate with: are there large numbers of SYN packets from many sources to this host? (3) Throttling/flow control by design: some application-layer protocols deliberately slow down transfer by shrinking the window. This is rare but legitimate in some streaming applications. The key distinction: if zero-window is appearing on connections to/from a host that also shows a high rate of new SYN connections from diverse sources → SYN flood victim. If zero-window appears on one or two specific sessions → resource pressure or throttling.