Overview
SMB2/3 (MS-SMB2) is the Windows protocol for file shares, named pipes and remote administration over TCP port 445. It is a binary, framed protocol—each message is prefixed by a 4-byte Direct-TCP length header and requests may be compounded—so a single capture carries the full story of who connected, how they authenticated, which shares and files they touched, and how the server answered. From a PCAP/PCAPNG you can follow dialect negotiation (2.0.2 through 3.1.1), NTLM vs Kerberos authentication, tree connects and administrative-share access, file/pipe opens, and NTSTATUS results. My Network Consultant decodes each command and lays them out per session.
- What you’ll see: NEGOTIATE dialects offered and selected, SESSION_SETUP authentication (NTLM/Kerberos, guest/null grants), TREE_CONNECT share paths, CREATE file/pipe opens, and NTSTATUS results (logon failure, access denied)
- Best for: File-share and permission troubleshooting, authentication problems, SOC triage, incident response, lateral-movement detection
- Works with: SMB2 and SMB3 over TCP 445, named pipes and remote-admin (IPC$) traffic, NTLMSSP and Kerberos-authenticated sessions
What to look for
- Weak-dialect downgrade: the legacy SMB 2.0.2 dialect offered—it predates SMB3 encryption,
- NTLM authentication: NTLMSSP instead of Kerberos → relay and offline-crack exposure; prefer Kerberos and enable signing,
- Guest / null sessions: a server granting anonymous access without proper credentials,
- Administrative-share access: connects to
C$, ADMIN$ or IPC$ → remote admin or lateral movement (e.g. PsExec),
- Logon-failure bursts: STATUS_LOGON_FAILURE (0xC000006D) across accounts/servers → password spraying or brute force,
- Access-denied clusters: STATUS_ACCESS_DENIED (0xC0000022) → permission probing on shares or files,
- SMB1 presence: SMB1/CIFS is a different, deprecated format that is not decoded—seeing it at all is a finding.
Capture tips
- Capture TCP 445 for the full session; include the TCP handshake so flows are cleanly delimited.
- Start the capture before the connection so you get NEGOTIATE and SESSION_SETUP, not just mid-session commands.
- Capture near the file server or the client under investigation to isolate who is initiating share access.
- Remember that SMB3 encryption hides command bodies; the envelope (auth type, share, status) may still be visible, but file names and payloads inside an encrypted session are not.
- Use a focused time window that reproduces the issue and stays within the 10 MB demo limit.
Example walkthrough
- Browse to SMB2.
- Check NEGOTIATE: which dialects the client offered and which the server selected; flag legacy 2.0.2.
- Inspect SESSION_SETUP: NTLM or Kerberos, and whether the response granted a guest or null session.
- Follow TREE_CONNECT share paths; watch for
C$/ADMIN$/IPC$ administrative shares.
- Review CREATE opens and the NTSTATUS results—logon failures and access-denied clusters.
- Open the parsed SMB2 view: each command with dialects, auth type, share path, filename, and status; export evidence for the ticket.
SMB2/3 FAQ
This analysis covers SMB2 and SMB3. Legacy SMB1/CIFS uses a different wire format and is not decoded—its presence is itself a finding, as SMB1 is deprecated and should be disabled.
Access to C$/ADMIN$/IPC$ exposes whole drives and the service pipe and is a common lateral-movement path (e.g. PsExec). Guest or null sessions mean the server accepted a connection without proper credentials—both are highlighted.
STATUS_LOGON_FAILURE (0xC000006D) is a rejected SMB logon from a wrong user or password. Repeated failures across accounts or servers indicate password spraying or brute force; STATUS_ACCESS_DENIED (0xC0000022) clusters instead suggest permission probing.
No. The analysis works from the SMB2 command envelope—dialects, authentication method, share and file names, access masks and status codes. File contents (READ/WRITE payloads) are not reconstructed, and SMB3 encryption hides the command bodies entirely.