SMBv1 vs SMBv2 vs SMBv3: Wireshark Filters

SMB (Server Message Block) supports file sharing, printer access, named pipes, and other Windows network services. The important packet-analysis detail is that “SMBv1,” “SMBv2,” and “SMBv3” are not three simple Wireshark protocol filters.

• Wireshark uses the smb dissector for SMB1.
• Wireshark uses the smb2 dissector for both SMB2 and SMB3 dialects.
• To distinguish SMB2 from SMB3, inspect the dialect selected during protocol negotiation.

The older version of this article incorrectly suggested smb2 && smb2.cmd == 0x11 for SMB3. That filter selects the SMB2/3 SET_INFO command; it does not identify an SMB version.

For a focused legacy-detection workflow, see how to identify SMBv1 traffic in a capture.

SMB version comparison

SMB3 is not automatically “secure” merely because a 3.x dialect was selected. Check whether signing is required, encryption is actually used where expected, authentication avoids weak or guest modes, and downgrade paths are controlled.

How to identify SMB1 in Wireshark

Use:

smb

SMB1 traffic commonly uses TCP port 445 or the older NetBIOS session path on TCP port 139. Port numbers can locate candidates, but the decoded protocol is stronger evidence than the port alone.

If SMB1 appears, determine which endpoint initiated it, which server accepted it, and whether it represents an obsolete host, scanner, appliance, or required exception. Do not stop at the packet count.

How to distinguish SMB2 and SMB3

Start with:

smb2

Then inspect the SMB2 Negotiate Protocol Response and the smb2.dialect field. Common selected values are:

A useful display filter for negotiation packets is:

smb2.cmd == 0x00

Command 0x00 is NEGOTIATE. Select the server's response and expand the SMB2 header and negotiate response to confirm the chosen dialect. If the capture begins after negotiation, the later packets may show SMB2/3 operations but may not prove which dialect was selected; obtain the beginning of the connection.

What happens in an SMB connection

1. Negotiate

The client advertises supported dialects and capabilities. The server selects one dialect and returns its capabilities and security mode. This exchange is the authoritative place to identify SMB2 versus SMB3.

2. Session setup

The client and server establish the authenticated SMB session. Inspect the surrounding SPNEGO, Kerberos, or NTLMSSP exchange. A successful session setup proves that the server accepted the authentication exchange; it does not by itself prove that the account or method meets policy.

3. Tree connect

The client connects to a share such as \\server\share. The response establishes access to that tree and exposes useful status codes when permissions or paths fail.

4. Create, read, write, and query

SMB uses CREATE to open files and directories, then READ, WRITE, QUERY_DIRECTORY, QUERY_INFO, SET_INFO, and related commands. File IDs tie later operations to the opened object. Credits allow multiple operations to remain outstanding and reduce the strict request/response chattiness associated with SMB1.

Verify the security properties, not just the version

Signing

SMB signing protects message integrity and helps resist tampering. Inspect the negotiate and session flags to determine whether signing is supported, enabled, or required. “Supported” is weaker than “required.”

Encryption

SMB3 can encrypt SMB payloads. Verify encrypted transform records in the actual session rather than inferring encryption from dialect 3.x. Encryption visibility also changes what a passive capture can decode.

Authentication

Identify whether Kerberos, NTLM, or guest/anonymous access was used. If NTLM appears, distinguish expected compatibility from an avoidable fallback. A modern dialect does not repair weak credentials or overly broad share permissions.

Dialect downgrade

Compare the dialects offered by the client with the dialect selected by the server. An unexpected lower dialect can indicate configuration, compatibility, or downgrade concerns. The trace can show what was negotiated; endpoint policy and logs are needed to explain why.

Practical Wireshark filters

# SMB1 only
smb

# SMB2 and SMB3 family traffic
smb2

# SMB2/3 negotiation request and response
smb2.cmd == 0x00

# Session setup
smb2.cmd == 0x01

# Tree connect
smb2.cmd == 0x03

# Create/open
smb2.cmd == 0x05

# Read or write
smb2.cmd == 0x08 || smb2.cmd == 0x09

# SET_INFO: not an SMB3 detector
smb2.cmd == 0x11

Field availability can vary with Wireshark version and whether the negotiation is present. Confirm the field names in the packet-details pane for your installed version.

A defensible SMB investigation

1. Find the client/server pair and complete TCP connection.
2. Identify SMB1 with smb, or locate the SMB2/3 NEGOTIATE response.
3. Record the selected smb2.dialect and the offered alternatives.
4. Verify signing, encryption, and authentication from the session, not from version assumptions.
5. Correlate status codes and command timing with the user's failed file operation.
6. Compare a successful session to the same server or share.
7. State what packet evidence proves and what still needs server, identity, or policy logs.

The PacketSafari packet-understanding workflow helps teams turn protocol fields into a reviewable explanation. You can also analyze a capture in the PacketSafari PCAP analyzer while keeping exact frames and limitations attached to the finding.

Bottom line

Use smb for SMB1 and smb2 for the entire SMB2/SMB3 family. Use the negotiated smb2.dialect, not a command filter, to distinguish 2.x from 3.x. Then verify the properties that matter: signing, encryption, authentication, share access, and whether the selected dialect matches policy.