SMB Explained: SMB2 and SMB3 Dialects, Signing, Encryption and QUIC

SMB (Server Message Block) is the protocol Windows, Samba and most network storage use to share files, printers and named pipes between machines. A client connects to TCP port 445, negotiates a dialect from SMB 2.0.2 up to SMB 3.1.1, authenticates through Kerberos or NTLM, then connects to a share and opens files. Signing proves each message is unaltered; encryption, available from SMB 3.0, also hides its contents.

The details matter because SMB is a family of dialects with very different security properties behind one port number. An SMB 2.0.2 session can be signed but never encrypted; an SMB 3.1.1 session protects its own negotiation, can use AES-256-GCM and can run over QUIC instead of TCP 445. This post walks through the protocol on the wire, every dialect, how signing and encryption actually work, the weakness classes as concepts, and the commands a defender uses to check what their own servers negotiate. Protocol facts come from Microsoft's Open Specifications document MS-SMB2 (revision 88.0, published 28 September 2026), Microsoft Learn and the Samba project's own manual pages.

Key takeaways

• SMB 2 and 3 are one protocol, specified in MS-SMB2, with five dialects: 2.0.2, 2.1, 3.0, 3.0.2 and 3.1.1. SMB 1 is a different wire format, specified in MS-SMB and MS-CIFS, and Microsoft publicly deprecated it in 2014.
• Every SMB 2 and 3 message starts with a 64 byte header carrying a 16 byte signature field. Signing uses HMAC-SHA256 in 2.0.2 and 2.1, AES-128-CMAC in 3.0 and 3.0.2, and a negotiated algorithm (AES-GMAC, AES-CMAC or HMAC-SHA256) in 3.1.1.
• Encryption exists only in the SMB 3.x family. SMB 3.0 and 3.0.2 use AES-128-CCM; SMB 3.1.1 negotiates AES-128-GCM, AES-128-CCM, AES-256-GCM or AES-256-CCM. MS-SMB2 states plainly that 2.0.2 and 2.1 "do not support encryption".
• SMB 3.1.1 pre-authentication integrity chains a SHA-512 hash over the negotiate and session setup messages and feeds it into key derivation, so tampering with negotiation breaks the session. It cannot stop a downgrade to SMB 1 if SMB 1 is still enabled.
• Since Windows 11 24H2 and Windows Server 2025, signing is required by default on all inbound and outbound SMB connections. Encryption is still optional by default.
• SMB over QUIC wraps SMB 3.1.1 in a TLS 1.3 protected QUIC connection on UDP 443. It is available in all editions of Windows Server 2025 and Windows 11, and Samba 4.25 documents support that depends on a separate Linux kernel module.
• Microsoft's guidance is to block TCP 445 inbound and outbound at the internet edge. SMB is a LAN and data center protocol unless you use SMB over QUIC.

What SMB is for: the layer and the standard

SMB is an application layer protocol for remote file and print access. A client asks a server to open, read, write, lock and close files on a share, to list directories, to watch for changes and to talk to named pipes, which Windows uses to carry remote procedure calls. It is stateful: the client builds up a connection, then one or more authenticated sessions, then tree connects to shares, then open handles to files, and the server tracks all of it.

MS-SMB2 section 1.3 describes SMB 2 and 3 as "an extension of the original Server Message Block (SMB) Protocol" and notes that the packet formats are completely different while many concepts carry over. The three documents that define the family today are:

SMB is not an IETF standard. It is a vendor owned protocol, and Microsoft's Open Specifications are the authoritative definition, revised several times a year. MS-SMB2 relies on other specifications for its pieces: SPNEGO (RFC 4178 and MS-SPNG) to choose an authentication mechanism, Kerberos (MS-KILE) or NTLM (MS-NLMP) to authenticate, NIST SP 800-108 for key derivation, and RFC 9000 for QUIC.

Transports and ports

MS-SMB2 section 2.1 lists four transports. Port numbers below come from the IANA service name and port registry, except QUIC, which uses a port Microsoft documents as the default.

Microsoft Learn's hardening page notes that Windows 11 24H2 and Windows Server 2025 removed the NetBIOS ports from the built-in SMB firewall rules, because they were only needed for SMB 1. The same page describes alternative ports: the client can now connect to SMB over TCP, QUIC or RDMA on ports other than 445, 443 and 5445 if the server is configured to listen there.

How SMB works on the wire

MS-SMB2 groups its messages into categories: protocol negotiation (NEGOTIATE), user authentication (SESSION_SETUP, LOGOFF), share access (TREE_CONNECT, TREE_DISCONNECT), file access (CREATE, CLOSE, READ, WRITE, LOCK, IOCTL, QUERY_INFO, SET_INFO, FLUSH, CANCEL), directory access (QUERY_DIRECTORY, CHANGE_NOTIFY), cache coherency (OPLOCK_BREAK) and ECHO. All multi-byte fields are little-endian, and strings are UTF-16.

The connection sequence

Here is a typical SMB 3.1.1 session over Direct TCP, with the security relevant steps marked.

Client                                                    Server
  |                                                          |
  |  TCP handshake to port 445                               |
  |--------------------------------------------------------->|
  |                                                          |
  |  NEGOTIATE request                                       |
  |  Dialects: 0x0202 0x0210 0x0300 0x0302 0x0311            |
  |  SecurityMode: signing enabled or required               |
  |  Negotiate contexts: preauth integrity (SHA-512 + salt), |
  |  encryption ciphers, signing algorithms, compression     |
  |--------------------------------------------------------->|
  |                                                          |
  |  NEGOTIATE response                                      |
  |  DialectRevision: 0x0311, chosen cipher, chosen signing  |
  |  algorithm, server SPNEGO token                          |
  |<---------------------------------------------------------|
  |  (both sides hash request + response into the preauth    |
  |   integrity value)                                       |
  |                                                          |
  |  SESSION_SETUP request (GSS token: Kerberos or NTLM)     |
  |--------------------------------------------------------->|
  |  SESSION_SETUP response (more processing or success,     |
  |  SessionFlags: guest, null or encrypt-data)              |
  |<---------------------------------------------------------|
  |  (each exchange is folded into the preauth hash; the     |
  |   final value is an input to signing and encryption key  |
  |   derivation; the final response is signed)              |
  |                                                          |
  |  TREE_CONNECT request  "\\server\share"                  |
  |--------------------------------------------------------->|
  |  TREE_CONNECT response (ShareFlags, e.g. encrypt-data)   |
  |<---------------------------------------------------------|
  |                                                          |
  |  CREATE, READ, WRITE, QUERY_DIRECTORY, IOCTL ...         |
  |  (signed with the session signing key, or wrapped in a   |
  |   TRANSFORM_HEADER if encryption is on)                  |
  |<-------------------------------------------------------->|
  |                                                          |
  |  CLOSE, TREE_DISCONNECT, LOGOFF, TCP close               |
  |<-------------------------------------------------------->|

Negotiate. The client sends the list of dialects it supports, each as a two byte revision code, and a SecurityMode field with two bits: SMB2_NEGOTIATE_SIGNING_ENABLED (0x0001) and SMB2_NEGOTIATE_SIGNING_REQUIRED (0x0002). For SMB 3.1.1, it also sends negotiate contexts: SMB2_PREAUTH_INTEGRITY_CAPABILITIES (hash algorithm and a random salt), SMB2_ENCRYPTION_CAPABILITIES (cipher list in preference order), SMB2_SIGNING_CAPABILITIES (signing algorithms in preference order), compression capabilities, a netname context carrying the server name it intended to reach, and transport capabilities. The server answers with the single dialect it picked and its choices from each list.

A client that does not yet know whether a server speaks SMB 2 can start with an SMB 1 style negotiate that offers "SMB 2.002" or "SMB 2.???". MS-SMB2 section 1.7 says an SMB 2 capable server answers with an SMB 2 negotiate response, and from then on the connection is SMB 2 only. The two protocols are never mixed on one connection.

Session setup. The client sends one or more SESSION_SETUP requests carrying SPNEGO security blobs. SPNEGO picks Kerberos where possible and falls back to NTLM. When authentication completes, the server returns a SessionId and SessionFlags, which can mark the session as guest (SMB2_SESSION_FLAG_IS_GUEST), anonymous (SMB2_SESSION_FLAG_IS_NULL), or as requiring encryption for the whole session (SMB2_SESSION_FLAG_ENCRYPT_DATA, valid only for SMB 3.x). Authentication also produces a session key, which is the root of every signing and encryption key that follows.

Tree connect. The client names a share by its full path, in the form \\server\share. MS-SMB2 requires the server part to be a NetBIOS name, a fully qualified domain name, or a textual IPv4 or IPv6 address. The response carries ShareFlags, including SMB2_SHAREFLAG_ENCRYPT_DATA when the share demands encryption, and a TreeId the client uses from then on. The special share IPC$ is the doorway to named pipes.

Steady state. File operations carry the SessionId and TreeId in every header. Server granted credits limit outstanding requests, and leases and oplocks let a client cache data until the server sends a break.

Teardown. CLOSE releases file handles, TREE_DISCONNECT leaves a share and LOGOFF ends a session. Durable handles from SMB 2.0.2 and persistent handles from SMB 3.0 let a client reclaim open files after a brief network drop, which is why an SMB session can outlive a single TCP connection.

The SMB2 header

Every SMB 2 and SMB 3 message starts with this fixed 64 byte header, defined in MS-SMB2 section 2.2.1. The synchronous form is shown; asynchronous responses replace Reserved and TreeId with an 8 byte AsyncId.

Two details from this table matter for security. The signature covers the entire message, including the header fields that say which session and share it belongs to. And the header itself is never encrypted on its own; when encryption is on, the whole SMB2 message, header included, is wrapped inside a separate transform header, described below.

The transform header for encrypted messages

MS-SMB2 section 2.2.41 defines the SMB2 TRANSFORM_HEADER, used only by the SMB 3.x family. It starts with ProtocolId 0xFD followed by "SMB" (value 0x424D53FD), then a 16 byte Signature (the authentication tag from AES-CCM or AES-GCM), a 16 byte Nonce, the OriginalMessageSize, a Flags or EncryptionAlgorithm field, and the SessionId. The encrypted SMB2 message follows. MS-SMB2 says the nonce must not be reused for any other encrypted message within the session. If a message is to be both compressed and encrypted, it is compressed first.

On the wire, then, an encrypted session reveals the transform header (including the SessionId and message size) and nothing about which file, command or share the message concerns. An unencrypted but signed session reveals everything, including file names and contents, but any change is detected.

Versions and history: from SMB 1 to SMB 3.1.1

SMB 1 and CIFS

SMB 1 dates from the 1980s and evolved through many dialects, the last being NT LM 0.12, which Samba's manual calls NT1 and labels "Known as CIFS". Its signing used MD5, as Microsoft Learn's signing overview notes. Microsoft Learn's SMBv1 page says SMB 2 superseded SMB 1 starting in 2007 and that Microsoft publicly deprecated SMB 1 in 2014. Since Windows 10 version 1709 and Windows Server version 1709, SMB 1 is not installed by default, and Windows 11 contains neither the SMB 1 client nor server after a clean installation. Our post on disabling SMBv1 when an old device still needs it covers the migration in depth.

The most widely known SMB 1 flaw is CVE-2017-0144, a remote code execution bug in the Windows SMBv1 server published on 17 March 2017 according to its cve.org record. It was a bug in one implementation, not a design flaw in signing or encryption, but it is a large part of why SMB 1 removal became urgent.

The SMB 2 and SMB 3 dialects

MS-SMB2 section 1.7 lists three dialect families and five revisions. The Windows release that introduced each one comes from Samba's smb.conf manual and Microsoft Learn.

Each dialect includes everything before it. Negotiating 3.1.1 implies support for all of 2.0.2 through 3.0.2.

A few later changes happened inside 3.1.1 rather than as new dialects. Microsoft Learn says Windows Server 2022 and Windows 11 introduced AES-256-GCM and AES-256-CCM for SMB 3.1.1 encryption and AES-128-GMAC for SMB 3.1.1 signing, and that AES-128-GCM is the default cipher negotiated with SMB 3.1.1. Windows Server 2022 Datacenter: Azure Edition brought SMB over QUIC, and Windows Server 2025 made it available in every edition.

Windows 11 24H2 and Windows Server 2025 then changed defaults in one release. Microsoft Learn's SMB security hardening page lists signing required by default, an authentication rate limiter, the option to mandate encryption on the client, dialect minimums and maximums, NTLM blocking on the client, SMB over QUIC client access control, removal of NetBIOS ports from the default firewall rules, guest access disabled on Windows 11 Pro, and remote mailslots disabled. Our post on SMB signing in Windows 11 24H2 covers what that signing change breaks.

What is still deployed

In practice, Windows clients and servers from the last decade negotiate 3.1.1 with each other. Older network storage, printers, scanners and embedded devices are the usual reason a network still accepts 2.x or even SMB 1. Samba, the open source implementation used on Linux servers and inside a great deal of network attached storage, currently defaults to a minimum of SMB2_02 and a maximum of SMB3 (which selects SMB3_11) according to the smb.conf manual for Samba 4.25.0.

How SMB signing works and what it protects

Signing gives each message a cryptographic checksum keyed by a secret that only the client and server share. Microsoft Learn describes it as "a hash of the entire message" placed in the SMB header, which also binds the identities of sender and recipient through the session key.

The algorithm by dialect

MS-SMB2 section 3.1.4.1 spells out the steps. The sender zeros the 16 byte Signature field, computes a MAC over the whole message (including any padding in a compound chain) with the signing key, and copies the result into the field.

• SMB 2.0.2 and 2.1: HMAC-SHA256, producing 32 bytes, of which the first 16 go into the header.
• SMB 3.0 and 3.0.2: AES-128-CMAC (RFC 4493), producing a 16 byte tag.
• SMB 3.1.1: the algorithm agreed in SMB2_SIGNING_CAPABILITIES, whose defined IDs are 0x0000 HMAC-SHA256, 0x0001 AES-CMAC and 0x0002 AES-GMAC. If AES-GMAC is chosen, the 12 byte nonce is built from the MessageId plus a bit that marks whether the sender is the client or the server, and another bit for CANCEL requests. If no signing context was negotiated, 3.1.1 falls back to AES-128-CMAC.

Where the keys come from

In the SMB 3.x family, MS-SMB2 section 3.1.4.2 derives the signing, encryption and decryption keys from the session key using the NIST SP 800-108 key derivation function in counter mode, with HMAC-SHA256 as the pseudorandom function, a 32 bit counter, and an output length of 128 or 256 bits depending on the negotiated cipher. In 3.1.1 the pre-authentication integrity hash is one of the inputs. MS-SMB2's own security considerations (section 5.1) warn that if session keys are non-random or can be forced to repeat, an attacker could deduce the signing and decryption keys. Microsoft Learn adds the practical consequence: the session key is ultimately derived from the user's credentials, so a long password and Kerberos rather than NTLMv2 give signing a stronger root.

When signing actually happens

Microsoft Learn's signing overview explains the Windows rule. The EnableSecuritySignature setting is ignored for SMB 2 and later and only matters for SMB 1. For SMB 2.0.2 onward, the only switch is RequireSecuritySignature: if either the client or the server requires signing, the session is signed. Signing is skipped only when neither side requires it. Before 24H2 and Server 2025, Windows required signing only on domain controllers and for connections to the SYSVOL and NETLOGON shares; it now requires it everywhere by default.

Samba's manual makes a related point from the other side: for SMB 2, "by design, signing cannot be disabled", so a server signing = disabled setting is treated as auto when SMB 2 is negotiated, and mandatory still forces clients to sign.

What signing protects, and what it does not

MS-SMB2 section 5.1 is explicit about the first gap in the right hand column: unsigned oplock breaks could let an attacker affect performance but not alter data, and unsigned cancel requests could let an attacker cancel earlier requests on the same connection.

How SMB encryption works and what it protects

SMB encryption, introduced in SMB 3.0, wraps each SMB2 message in a transform header and protects it with an authenticated encryption cipher. Microsoft Learn describes it as end-to-end protection between client and file server "regardless of the networks traversed".

Ciphers by dialect

Because these are authenticated ciphers, an encrypted message is also integrity protected. Microsoft Learn notes that encrypted shares get data integrity validation regardless of the separate signing settings.

How encryption is turned on

Encryption can be required for a whole session (the server sets SMB2_SESSION_FLAG_ENCRYPT_DATA) or for individual shares (SMB2_SHAREFLAG_ENCRYPT_DATA). On Windows, Set-SmbServerConfiguration -EncryptData $true turns it on server-wide and Set-SmbShare -EncryptData $true per share. Since 24H2 and Server 2025, the client can also mandate encryption on all outbound connections, after which it only connects to servers that support SMB 3.0 or later and SMB encryption.

The RejectUnencryptedAccess setting, true by default, decides what happens to a client that cannot encrypt. With it on, only encryption capable SMB 3.x clients reach an encrypted share; older clients get "Access denied" and the server logs Event ID 1003 to Microsoft-Windows-SmbServer/Operational. Microsoft Learn advises against turning it off.

Samba's equivalent is the server smb encrypt parameter, with values off, if_required (the default), desired and required, settable globally or per share. The manual notes one difference: Windows applies RejectUnencryptedAccess globally, while Samba lets you enforce encryption per share.

What encryption protects, and what it does not

Encryption hides file names, paths, share names after the tree connect, file contents and every command inside the session. It does not hide that SMB is in use, the IP addresses, the port, message sizes and timing, or the transform header's SessionId. It is not encryption at rest; Microsoft Learn points out that SMB encryption is unrelated to BitLocker and to EFS. And in SMB 3.x over TCP, the negotiate and session setup exchanges happen before keys exist, so they travel in the clear. That includes the NTLM challenge and response if NTLM is used, which is one of the reasons SMB over QUIC exists.

Pre-authentication integrity: protecting the part before the keys

If the negotiation itself travels unprotected, an attacker in the path could try to edit it: remove the high dialects from the client's list, clear the signing-required bit, or drop the stronger ciphers. SMB 3.0 and 3.0.2 handle this after the fact with an IOCTL called FSCTL_VALIDATE_NEGOTIATE_INFO, in which the client repeats what it originally offered over the now-signed session so the server can compare.

SMB 3.1.1 replaces that with pre-authentication integrity, which MS-SMB2 makes mandatory for 3.1.1. Each side starts a hash value at zero, then hashes it together with the full NEGOTIATE request, then with the NEGOTIATE response, then with each SESSION_SETUP request and response in turn. The only defined hash is SHA-512. The final value becomes an input to key derivation, so if anyone changed a byte of negotiation, the client and server derive different keys and the first signed message fails verification. Microsoft Learn summarises the effect: the hash protects "against any tampering with Negotiate and Session Setup messages".

There is one documented limit. Microsoft Learn states that pre-authentication integrity prevents a downgrade from 3.1.1 to SMB 2.x, but "doesn't prevent a downgrade to SMB 1.0". SMB 1 has no knowledge of the SMB 3.1.1 hash. That is why disabling SMB 1 on servers is part of making encryption meaningful, not just a cleanup task.

SMB over QUIC

SMB over QUIC runs SMB 3.1.1 over QUIC, the UDP based transport that always encrypts with TLS 1.3. Microsoft Learn calls it an "SMB VPN" for remote workers and mobile users: a file server can be reached over the internet on UDP 443 without exposing TCP 445 and without a separate VPN.

How it works

MS-SMB2 lists QUIC as a transport for dialect 3.1.1 only, identified in TLS by the ALPN value "smb". The server presents a certificate; Microsoft Learn's requirements include the Server Authentication extended key usage, a subject alternative name for every DNS name clients use, and ECDSA P-256 or RSA 2048 or larger keys. Inside the QUIC connection, SMB works as usual: signing, multichannel, compression and leasing all still apply. Authentication happens inside the encrypted tunnel, so an NTLM exchange, if one happens, is not visible on the network.

Some operational facts from Microsoft Learn:

• The administrator must opt in on the server. A client cannot force a server to enable it.
• Windows clients still try TCP first and only use QUIC if TCP fails, unless told to use QUIC with NET USE ... /TRANSPORT:QUIC or New-SmbMapping -TransportType QUIC.
• Without line of sight to a domain controller, the client falls back to NTLMv2. Microsoft recommends configuring a KDC proxy so Kerberos tickets can be fetched over HTTPS instead.
• In Windows Server 2025 and Windows Server 2022 Azure Edition, client access control can require each client to present its own certificate and be on an allowlist before any SMB traffic flows.
• Do not use IP addresses as certificate names, because IP based connections force NTLM.
• Renewing the certificate changes its thumbprint, and the SMB server's certificate mapping must be updated.
• Windows 11 24H2 clients can audit SMB over QUIC connections, logged as event 30832 under SMBClient\Connectivity.

When QUIC already provides TLS encryption, SMB-level encryption on top would encrypt the data twice. Windows' DisableSmbEncryptionOnSecureConnection server setting, shown as True in Microsoft's example output, and Samba's server smb encryption over quic parameter (default yes, meaning Samba still applies its normal encryption rules) control that choice.

Samba and QUIC

Samba 4.25.0's smb.conf manual documents server smb transports and client smb transports, which accept tcp, nbt and quic, with QUIC defaulting to port 443. The manual notes that QUIC "requires the quic.ko kernel module for Linux" from a separate project, tested with Linux 6.14. Treat it as something to test, not a drop-in replacement for the Windows implementation.

When to use SMB over QUIC

Use it when people outside the office need native file shares and the alternative is a full VPN just for file access. Do not deploy it without the controls Microsoft lists: client access control where available, Kerberos through a KDC proxy, strong or passwordless sign-in, and account lockout.

Security properties and weakness classes

This section explains what can go wrong as concepts, for defenders. It contains no attack steps.

What SMB guarantees, by configuration

Credential relay (NTLM relay)

NTLM is a challenge and response protocol. A client proves it knows a password by answering a challenge, but in plain NTLM nothing in that answer ties it to the specific server the user meant to reach. If an attacker can get a client to authenticate to a machine they control, for example through a link to a file share, they can forward the client's answers to a different server and be logged in there as that user. Kerberos and signing are the two controls. Kerberos tickets are issued for a named service, so they cannot be redirected to another server. Signing means the relayed session is useless without the session key, which the attacker never learns. Microsoft Learn says signing "prevents data tampering and relay attacks that steal credentials". Windows 11 24H2 and Server 2025 add client side NTLM blocking for SMB. Our comparison of Kerberos and NTLM explains how to tell which one your applications use.

Dialect and capability downgrade

Any protocol that negotiates options in the clear can be pushed toward weaker options by someone in the path. In SMB, the weaker options are a lower dialect without encryption, signing turned off, or a weaker cipher. SMB 3.1.1's pre-authentication integrity closes this within SMB 2 and 3. The remaining gap is SMB 1, which is outside the hash. The fix is configuration: disable SMB 1 everywhere, set a dialect minimum on Windows 11 24H2 and Server 2025, and require signing or encryption.

Guest and anonymous access

A guest session authenticates nobody and has no meaningful session key, so it cannot be signed or encrypted. Microsoft Learn lists the risks of insecure guest logons: a user can be steered to a spoofed server "without producing credential errors or prompts", malicious code can arrive through a guest share, and the traffic is exposed to adversary-in-the-middle attacks. Windows 10 version 1709 and Windows Server 2019 stopped SMB 2 and 3 clients from using guest access or falling back to guest by default on Enterprise, Education and Pro for Workstations editions, and Windows 11 Pro followed. A related legacy issue is anonymous access to the IPC$ share, covered in our post on SMB null sessions. In Samba, map to guest (default Never) and restrict anonymous (default 0) are the controls to review.

Exposure of port 445 to the internet

SMB was built for trusted networks. A server listening on TCP 445 to the internet offers attackers the authentication service for password guessing, the parser for any memory safety bug in the implementation, and, if guest or anonymous access is on, the data. Microsoft Learn's guidance is to block TCP 445 inbound and outbound at the corporate firewall. Outbound matters too: a laptop that can reach any SMB server on the internet can be tricked into sending its authentication there. CVE-2020-0796, published on 12 March 2020 according to cve.org, was a remote code execution bug in the way SMB 3.1.1 handled certain requests, and it showed that even the newest dialect's code needs patching and should not face the internet.

Password guessing

Because SMB authentication is cheap to attempt, an exposed or internally reachable server can be hammered with guesses. Windows 11 24H2 and Server 2025 enable an authentication rate limiter by default, with a two second delay after each failed NTLM or local KDC Kerberos attempt. Microsoft Learn's example: 90,000 attempts that would have taken five minutes now take 50 hours.

Implementation bugs

The SMB protocol is large and stateful, and every implementation has to parse complex, attacker reachable input before authentication completes. The two CVEs named above were implementation bugs rather than flaws in SMB's cryptography. Patching the implementation, and knowing which implementation you run, matters as much as the protocol settings.

Secure configuration, with defender-side checks

Only run the commands below against systems you own or are authorised to administer. Every command and setting name comes from the Microsoft Learn or Samba documentation linked in the sources.

Windows: check which protocol versions are enabled

From the "detect, enable and disable SMBv1, SMBv2 and SMBv3" page:

# Is the SMB 1 feature installed? (elevated prompt)
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# Is SMB 1 or SMB 2/3 enabled on the server component?
Get-SmbServerConfiguration | Select EnableSMB1Protocol
Get-SmbServerConfiguration | Select EnableSMB2Protocol

# Remove SMB 1 (restarts the computer)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Do not disable SMB 2 to troubleshoot unless you mean to: on Windows 8 and Windows Server 2012 and later, SMB 2 and SMB 3 share a stack, so disabling one disables both.

Windows: check signing, encryption and ciphers on the server

Get-SmbServerConfiguration with no arguments prints every setting. The ones that matter here are shown in Microsoft's documented output:

Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EncryptData, RejectUnencryptedAccess, EncryptionCiphers, EnableSMBQUIC, EnableSMB1Protocol

What you want to see: RequireSecuritySignature True (the default on Server 2025), EncryptData True where your data needs confidentiality, RejectUnencryptedAccess True, EncryptionCiphers listing only AES modes you accept, and EnableSMB1Protocol False. The client side settings appear in Get-SmbClientConfiguration. The signing requirement is also visible in the registry values Microsoft Learn names: RequireSecuritySignature under HKLM\System\CurrentControlSet\Services\LanManServer\Parameters for the server and under ...\LanManWorkstation\Parameters for the client.

Windows: check what live connections actually negotiated

Configuration shows what is allowed; connections show what is used. On a client, Get-SmbConnection lists every connection with its dialect, and its documented properties include Encrypted:

Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Dialect, Encrypted

On a server, Get-SmbSession lists sessions from clients, including their Dialect. Anything below 3.1.1 is worth investigating. Any connection that shows 2.0.2 or 2.1 cannot be encrypted.

Windows: require stronger settings

These commands come from the Microsoft Learn pages on SMB encryption, dialect management and NTLM blocking. Test them on a pilot group first, because each one will refuse clients or servers that cannot comply.

# Encrypt everything this server serves, or one share
Set-SmbServerConfiguration -EncryptData $true
Set-SmbShare -Name <sharename> -EncryptData $true

# Windows 11 24H2 / Server 2025: only accept SMB 3.1.1 on the server
Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB311

# ...and on the client
Set-SmbClientConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB311

# Windows 11 24H2 / Server 2025: stop the client from sending NTLM over SMB
Set-SmbClientConfiguration -BlockNTLM $true

Windows: audit before you enforce

Windows 11 24H2 added auditing so you can find the devices that would break before you require signing or encryption. Events land in SMBClient\Audit (IDs 31998 and 31999) and SMBServer\Audit (IDs 3021 and 3022).

Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportEncryption $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Windows: confirm what is listening on 445

Get-NetTCPConnection from the NetTCPIP module shows listening sockets:

Get-NetTCPConnection -LocalPort 445 -State Listen

A workstation that does not share files does not need to listen on 445 for anyone outside its management network. Pair this with firewall rules, as Microsoft Learn's "secure SMB traffic" page describes, and block TCP 445 at the internet edge in both directions.

Samba: check the effective configuration

testparm checks smb.conf for errors and prints the effective settings. The -s option suppresses the prompt, -v includes parameters left at their defaults, and --parameter-name dumps one parameter:

testparm -s
testparm -s -v | grep -Ei 'min protocol|max protocol|signing|smb encrypt|ntlm auth|map to guest|restrict anonymous|smb transports'
testparm -s --parameter-name "server min protocol"

A hardened Samba file server's global section usually includes settings like these. Every parameter name and value comes from the Samba 4.25.0 smb.conf manual:

[global]
    server min protocol = SMB3_11
    server signing = mandatory
    server smb encrypt = required
    server smb3 encryption algorithms = AES-256-GCM, AES-128-GCM
    server smb3 signing algorithms = AES-128-GMAC, AES-128-CMAC
    ntlm auth = ntlmv2-only
    map to guest = Never
    restrict anonymous = 2

Two caveats from the manual. Removing AES-128-CCM from the encryption list makes SMB3_00 and SMB3_02 unavailable, and removing AES-128-CMAC from the signing list does the same, so only do that once every client speaks 3.1.1. And restrict anonymous = 2 disallows anonymous IPC$ connections entirely, which very old clients that rely on NetBIOS browsing may notice.

Samba: check what live sessions negotiated

smbstatus lists current connections. With -j, its JSON output includes each session's session_dialect (for example SMB3_11) and its encryption and signing state:

smbstatus -b
smbstatus -j

Logging

On Windows, the SMBServer and SMBClient operational and audit logs record rejected unencrypted access (event 1003), signing and encryption capability audits, insecure guest logons and SMB over QUIC connections. Microsoft Learn also suggests auditing File Share access for a limited period to learn which machines really use SMB.

SMB vs NFS vs SFTP for file sharing

All three move files across a network. They differ in what they assume about the network and the client.

A rough rule: SMB 3.1.1 with signing, and encryption for sensitive shares, inside Windows and mixed estates; NFS with Kerberos for Linux clusters; SFTP for exchanges with outside parties; SMB over QUIC for remote workers who need a mapped drive. Our post on the file transfer protocol covers why plain FTP is no longer one of the choices, and the TCP vs UDP post explains what any network observer can still see when the payload is encrypted.

Which SMB implementations are inside your software

Windows' SMB client and server ship with the operating system and are patched through Windows Update. Everything else is software you may be carrying without knowing it: Samba packages in Linux base images and appliances, SMB client libraries pulled into Python, Java, Go or Node.js applications to read from network shares, and backup or scanning tools that bundle their own SMB code. Each of those has its own version, its own default dialect range, and its own vulnerability history.

Safeguard's software composition analysis, generally available, builds a full transitive dependency inventory for repositories and container images, so an SMB client library three levels deep or a Samba package in a base image shows up by name and version. SBOM generation and analysis, also generally available, records it in SPDX or CycloneDX, and vulnerability management with EPSS and CISA KEV enrichment and reachability analysis, both generally available, tell you which findings are exploited in the wild and whether your code calls the vulnerable path. Safeguard does not inspect SMB traffic, configure Windows or Samba, or tell you which dialect a live connection negotiated; the commands above do that.

Common mistakes

• Thinking SMB 2 means encrypted. SMB 2.0.2 and 2.1 cannot encrypt. Encryption needs SMB 3.0 or later and has to be switched on, per share or per server.
• Leaving SMB 1 enabled "just in case". Pre-authentication integrity cannot stop a downgrade to SMB 1. As long as a server accepts SMB 1, a client that also allows it can be pushed there.
• Turning off signing to fix a 24H2 connection failure. Microsoft Learn says plainly not to disable signing or protocol versions to work around these failures; enable signing on the remote device or replace it.
• Enabling insecure guest logons for one old NAS, on every machine. If a device needs guest access, isolate or replace the device. Turning on guest access on the client weakens every SMB connection that client makes.
• Connecting by IP address or CNAME. Microsoft Learn notes that using an IP address or a CNAME makes Windows use NTLM instead of Kerberos, which weakens the session key and reopens relay.
• Setting RejectUnencryptedAccess to false and forgetting it. It was meant for a migration window. Left off, an encrypted share silently serves older clients in the clear.
• Treating EnableSecuritySignature as the signing switch. It does nothing for SMB 2 and later. Only RequireSecuritySignature matters.
• Assuming SMB over QUIC is just "SMB on 443". It needs a proper certificate, a renewal process that updates the thumbprint mapping, Kerberos through a KDC proxy to avoid NTLM, and client access control on Server 2025.
• Allowing outbound 445 to the internet. Blocking inbound protects servers; blocking outbound stops your clients sending authentication to someone else's server.
• Hardening Windows and forgetting the Samba inside appliances and images. Samba defaults differ from Windows defaults, especially for signing on non domain controllers.

FAQ

What port does SMB use?

TCP 445 for modern SMB over Direct TCP, registered with IANA as microsoft-ds. Legacy NetBIOS framing uses TCP 139, with UDP 137 and 138 for NetBIOS name and datagram services. SMB Direct over RDMA uses 5445, and SMB over QUIC uses UDP 443 by default.

Is SMB encrypted?

Not by default. SMB 3.0 and later can encrypt with AES-CCM or AES-GCM when the server or share requires it, or when a Windows 11 24H2 or Server 2025 client mandates it. SMB 2.0.2 and 2.1 cannot encrypt at all. SMB over QUIC is always encrypted by TLS 1.3.

What is the difference between SMB signing and SMB encryption?

Signing adds a MAC to each message so changes and relayed sessions are detected, but anyone on the path can still read the data. Encryption wraps each message in AES authenticated encryption, which hides the content and also protects integrity. Encrypted sessions do not need separate signing.

What are the SMB dialects?

SMB 2.0.2, 2.1, 3.0, 3.0.2 and 3.1.1, with revision codes 0x0202, 0x0210, 0x0300, 0x0302 and 0x0311. SMB 1 (also called CIFS or NT1) is a separate, deprecated protocol. Client and server normally pick the highest dialect both support.

How do I check which SMB version a connection is using?

On a Windows client, run Get-SmbConnection and read the Dialect column. On a Windows server, Get-SmbSession shows each client's dialect. On Samba, smbstatus -j reports session_dialect for each session.

Is SMB 3.1.1 secure?

It is the strongest dialect: negotiated AES-256 encryption, AES-GMAC signing and pre-authentication integrity against downgrade. It is only as secure as its configuration, though. Signing or encryption must actually be required, SMB 1 must be off, guest access must be off, and Kerberos should be used instead of NTLM.

Should port 445 be open to the internet?

No. Microsoft Learn recommends blocking TCP 445 inbound and outbound at the corporate firewall. If people outside the network need file shares, use SMB over QUIC or a VPN.

Does SMB signing stop NTLM relay?

Signing defeats relay into SMB, because the attacker cannot sign messages without the session key. It does not stop the attacker relaying the same authentication to a different protocol that does not require signing. Using Kerberos and blocking NTLM where you can removes the underlying problem.

Fix it without waiting for upstream

SMB vulnerabilities live in implementations: the Windows SMB stack, Samba, and the SMB client libraries your applications and container images pull in. Windows fixes come through Windows Update, but Samba packages and SMB libraries in the software you build are dependencies you can upgrade yourself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency and SBOM workflows, not SMB traffic monitoring or Windows configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at a container image built on a Linux base that includes Samba, or at an application that reads from network shares, the same scan lists the SMB packages and libraries inside with their versions and known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is an SMB client library pinned in your manifest.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular Samba or SMB library version, and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Microsoft Open Specifications, MS-SMB2: Server Message Block (SMB) Protocol Versions 2 and 3, revision 88.0, 28 September 2026
• MS-SMB2 full specification, PDF
• Microsoft Open Specifications, MS-SMB: Server Message Block (SMB) Protocol, revision 55.0
• Microsoft Learn: SMB security enhancements (encryption, preauthentication integrity, signing algorithms)
• Microsoft Learn: SMB security hardening in Windows 11 24H2 and Windows Server 2025
• Microsoft Learn: Overview of SMB signing
• Microsoft Learn: SMB over QUIC
• Microsoft Learn: SMBv1 is not installed by default in Windows
• Microsoft Learn: How to detect, enable and disable SMBv1, SMBv2 and SMBv3
• Microsoft Learn: Manage SMB dialects
• Microsoft Learn: Secure SMB traffic in Windows Server
• Microsoft Learn: Block NTLM connections on SMB
• Microsoft Learn: Enable insecure guest logons in SMB2 and SMB3
• Microsoft Learn: Get-SmbServerConfiguration
• Microsoft Learn: Get-SmbClientConfiguration
• Microsoft Learn: Get-SmbConnection
• Microsoft Learn: Get-SmbSession
• Microsoft Learn: Get-NetTCPConnection
• Samba: smb.conf(5) manual, version 4.25.0
• Samba: testparm(1) manual
• Samba: smbstatus(1) manual
• IANA Service Name and Transport Protocol Port Number Registry
• CVE-2017-0144 record (cve.org)
• CVE-2020-0796 record (cve.org)

Last reviewed: 23 October 2026. Windows and Samba SMB defaults change between releases; confirm against the documentation for the versions you run.