# The Connection That Refused to Downgrade: Twenty-Five Years of SMB Cryptography, Finally Default-On
> How SMB 3.1.1 pre-authentication integrity, AES-256-GCM, and SMB-over-QUIC closed a 25-year attack tradition, and which attacks still survive in 2026.
*Published: 2026-05-26*
*Canonical: https://paragmali.com/blog/the-connection-that-refused-to-downgrade-twenty-five-years-o*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**SMB 3.1.1 closed the 25-year-old negotiate-downgrade attack in 2015, but the defaults did not catch up until October 2024.** Pre-authentication integrity hashes every byte of NEGOTIATE and SESSION_SETUP into the SP 800-108 KDF salt, so any tampering produces divergent session keys rather than detectable mismatches. Windows 11 24H2 and Server 2025 finally make SMB signing required by default; encryption is now mandate-able but remains opt-in. The attacks that still work (PetitPotam) route around SMB entirely.
## 1. Three Failures in a Coffee Shop
A laptop opens its first SMB connection to a corporate file share over the wifi of a coffee shop. An attacker on the same network, holding the same family of relay tooling that Sir Dystic first demonstrated on **March 31, 2001 at @lanta.con in Atlanta** [@smbrelay-cdc], watches three packets go by: a NEGOTIATE Request, a NEGOTIATE Response, and an authenticated SESSION_SETUP that finishes with a signed READ.
She tries to relay the credentials to a neighbouring server. She tries to strip the signing-required bit from the NEGOTIATE Response. She tries to inject ciphertext she captured from a previous session of the same user.
All three attempts fail. None of them touch the contents of the file.
That outcome is the 2026 default behaviour of a Windows 11 24H2 client talking to a Windows Server 2025 file server [@pyle-techcom-4226591][@smb-security-hardening]. And it is the punch line of a story that took twenty-five years to land.
"This topic was discussed on March 31, 2001 at @lanta.con in Atlanta, Georgia." -- Sir Dystic, cDc disclosure page for SMBRelay [@smbrelay-cdc]
Sir Dystic was the cDc handle of the researcher who shipped the first practical SMB relay tool."Sir Dystic" is a cult of the Dead Cow pseudonym. The cDc primary disclosure page names only the handle; a legal name attributed in secondary press is not load-bearing for this article, and the primary citation stays with the pseudonym [@smbrelay-cdc]. His attack relayed a client's [NTLM](/blog/ntlmless-the-death-of-ntlm-in-windows/) challenge response, captured on the wire, into a fresh SMB session against another host where that user already had credentials.
The technique generalised, and "SMB relay" became a generic term for an attack family that has, over the intervening years, eaten domain controllers, file shares, and Active Directory Certificate Services enrollment endpoints.
This article walks the twenty-five-year arc of cryptographic responses to that attack family: how each retrofit before 2015 left a load-bearing weakness in the NEGOTIATE handshake; how SMB 3.1.1 closed that weakness with a mechanism that is usually misremembered; how SMB-over-QUIC arrived in 2021 as a parallel transport; how the October 2024 default-on flip in Windows 11 24H2 finally made signing mandatory on every share, not just SYSVOL and NETLOGON [@smb-security-hardening]; and what attacks the SMB team designed against still work in 2026, by routing around SMB entirely.
There will be three aha moments. The first arrives at the end of section 3: every defence before 2015 was applied after-the-fact to a message an attacker already controlled. The second arrives in section 4: pre-authentication integrity is not a signed negotiate, it is a hash chain that becomes a key-derivation salt. The third arrives in section 6: SMB is now cryptographically sufficient at the wire layer, and the attacks that still matter coerce SMB and relay the authentication somewhere else.
To see why the attacker's toolkit failed in 2026, and why the same toolkit worked everywhere from 2001 to 2023, we have to start in 1983.
## 2. The Cleartext Era and the Birth of the Relay Class
Barry Feigenbaum designed SMB at IBM Boca Raton in 1983 [@ms-cifs-landing] as a way to make a PC's open-file table look like it lived on a server. It ran on a single LAN segment, behind a desk, in a room where the only adversary was someone who walked in the door. There was no notion of an attacker on the wire because there was no wire to attack: the protocol predated TCP/IP's commercial reach by a decade.
Microsoft adopted the design for LAN Manager in 1987 and carried it into Windows NT in 1993 [@ms-cifs-landing]. Paul Leach's 1996-1997 IETF draft, eventually known as `draft-leach-cifs-v1-spec-02` [@leach-cifs-draft], rebranded the protocol as the **Common Internet File System** and tried to standardise the dialect at IETF.
The standardisation effort stalled, but the brand stuck for a decade. The normative SMB1 / CIFS reference today is the Microsoft `[MS-CIFS]` open specification [@ms-cifs-landing], which still records the SMB1 dialect strings `PC NETWORK PROGRAM 1.0`, `MICROSOFT NETWORKS 1.03`, `LANMAN1.0`, and `NT LM 0.12` that the protocol negotiates at hello.
In parallel, Andrew Tridgell at the Australian National University started reverse-engineering the SMB wire protocol so he could mount a DEC Pathworks server from his Linux box. His first tentative code appeared in early 1992 [@samba-10years]; that codebase grew into Samba, which is the canonical open-source SMB server in 2026 and ships every algorithm matrix the Microsoft client expects to negotiate.
Microsoft added SMB1 to the Windows Server 2012 R2 deprecation list in **June 2013**, in advance of the Server 2012 R2 October 2013 release, per Jose Barreto's 2015 TechNet post (preserved via the Wayback Machine) [@barreto-archive]. "Deprecation" meant the feature was marked for potential removal in subsequent releases, not yet removed. The actual default-off step came with Windows 10 1709 in the Fall Creators Update and Windows Server 2019 [@smb-interception-defense].
A family of attacks that captures a client's authentication exchange on the wire and replays it, in real time, into a fresh authenticated session against a different target where the same user already has access. The defining property is that the attacker never learns the plaintext credential; she only needs to ferry the cryptographic responses between two sockets. Originally demonstrated by Sir Dystic for SMB on March 31, 2001 [@smbrelay-cdc], the class generalised to NTLM-over-HTTP, NTLM-over-LDAP, NTLM-over-DCOM, and eventually to cross-protocol variants like PetitPotam that coerce SMB authentication and relay it to ADCS Web Enrollment over HTTPS.
### The 2001 disclosure
Sir Dystic's SMBRelay was a small Windows binary that ran a fake SMB server, accepted a connection from a victim, captured the NTLM challenge-response, and immediately forwarded that response to a real SMB server where the victim had access. The technique worked because SMB1 signing was opt-in by default; on a typical Windows network in 2001, signing was negotiated for connections to SYSVOL and NETLOGON on a domain controller and almost nowhere else. Microsoft's response at the time was that signing existed and could be turned on. Technically correct; politically untenable.
The "almost nowhere else" matters. SMB1 did support signing, and the algorithm was a truncated MD5 of the packet concatenated with the session key, mediated by a sequence number, per `[MS-CIFS]` §3.1.4.1 [@ms-cifs-landing]. It was not an HMAC, and it was not a strong MAC by 2001 cryptographic standards. But that was not the load-bearing weakness. The load-bearing weakness was that the **signing-required bit travelled in the NEGOTIATE Response itself**, before any session key existed to protect it. An attacker who could rewrite NEGOTIATE could strip the bit; signing was then mutually disabled and the session continued unsigned.
The cDc primary page dates the disclosure to *March 31, 2001*. The Wikipedia article on SMBRelay says March 21, 2001, and a chain of secondary press has repeated the March 21 date. The primary disclosure page is the dispositive source; the article uses March 31 [@smbrelay-cdc].
### The 2008 patch
Seven years and eight months later, on **November 11, 2008**, Microsoft shipped MS08-068, which addressed CVE-2008-4037, the same-host SMB credential reflection vulnerability [@ms08-068][@nvd-cve-2008-4037]. The fix changed how SMB authentication replies were validated so that an attacker could no longer reflect a client's credentials back to the *same host* that initiated the authentication.
That closed one specific variant of Sir Dystic's attack. It did not close the cross-host case, where the attacker forwards credentials to a different SMB server that the victim has access to. That case was the architectural shape that future relay tooling like Impacket's `smbrelayx` exploited for years.
What MS08-068 demonstrated, more than anything else, was the cost of fixing a protocol with a single-issue patch when the load-bearing weakness was structural. The 2001 disclosure named the class. The 2008 patch closed one variant. The next defence was not another bulletin, and it was not going to be another patch. It was a complete redesign of the SMB header model and a new dialect family.
gantt
title SMB cryptographic generations
dateFormat YYYY
axisFormat %Y
section SMB1
Cleartext on the LAN :1983, 1996
MD5 signing (opt-in) :1997, 2006
section SMB 2.x
HMAC-SHA-256 signing :2006, 2012
section SMB 3.x
AES-CMAC and AES-128-CCM :2012, 2013
Secure Negotiate FSCTL :2013, 2015
section SMB 3.1.1
Pre-auth integrity, AES-128-GCM :2015, 2021
AES-256 ciphers, AES-GMAC, SMB-over-QUIC :2021, 2024
Signing required by default :2024, 2026
## 3. Five Retrofits Before the Real Fix
Between 2006 and 2013, Microsoft tried four different cryptographic primitives and one post-hoc validation message. None of them closed the negotiate-downgrade primitive that SMBRelay opened.
### SMB 2.0 (November 8, 2006) [@ms-smb2-versioning]
Windows Vista RTM shipped a redesigned SMB header. The protocol still carried a sequence number, but the per-packet signature now came from HMAC-SHA-256 keyed by the session key derived from authentication, not from a truncated MD5 [@ms-smb2-versioning]. The new MAC closed all the trivial attacks on the signing algorithm itself.
But signing was still opt-in: a typical Windows network ran it only between domain controllers and member servers, not between general clients and file shares. And the NEGOTIATE Response still travelled unsigned, so the signing-required bit was still strippable by an in-path attacker.
A keyed message authentication code, defined in RFC 2104 with SHA-256 as the underlying hash, that produces a 256-bit tag binding a message and a key. HMAC's security reduces to the pseudorandomness of the underlying hash compression function; SHA-256 with HMAC has no known practical forgery for any key. SMB 2.0 and later use HMAC-SHA-256 to sign each SMB header when AES-CMAC and AES-GMAC are not negotiated [@ms-smb2-versioning].
### SMB 2.1 (October 22, 2009) [@ms-smb2-versioning]
Windows 7 and Server 2008 R2 shipped SMB 2.1, dialect `0x0210` [@ms-smb2-versioning]. The dialect introduced opportunistic locks, branch caching, and large MTUs. The cryptographic primitives did not change: HMAC-SHA-256 signing, still opt-in.
### SMB 3.0 (October 26, 2012) [@ms-smb2-versioning]
Windows 8 and Server 2012 shipped the first cryptographically modern SMB dialect, `0x0300` [@ms-smb2-versioning]. It introduced three things at once:
1. **AES-CMAC signing**, the NIST SP 800-38B [@nist-sp-800-38b] block-cipher MAC, swapping the SHA-256 compression function for an AES-128 cipher operation that runs at hardware speed on chips with AES-NI. The standard identifier in the spec is "AES-CMAC". Cryptographers will sometimes recognise the same construction as OMAC1 from Iwata and Kurosawa, 2003.
2. **AES-128-CCM encryption**, the two-pass AEAD construction from NIST SP 800-38C [@nist-sp-800-38c], which produces an authenticated ciphertext that an attacker cannot tamper with without invalidating the tag.
3. **A proper SP 800-108 key hierarchy.** Every per-session signing key, encryption key, and decryption key derives from a session-level secret via the counter-mode HMAC-SHA-256 KDF in NIST SP 800-108 [@nist-sp-800-108r1].
This was a real cryptographic upgrade. But it did not close the negotiate-downgrade primitive. An attacker on the wire could still rewrite the NEGOTIATE Response to remove the `SMB2_GLOBAL_CAP_ENCRYPTION` capability bit and the `SMB2_NEGOTIATE_SIGNING_REQUIRED` bit; the client and server would then agree on a session that was neither signed nor encrypted, and the cryptographic primitives the attacker was trying to defeat were never invoked at all.
A block-cipher message authentication code standardised in NIST SP 800-38B in 2005 [@nist-sp-800-38b]. CMAC iterates AES in CBC mode over the message and applies a final subkey to the last block. The construction tolerates messages of any length, including the empty message, and has a security bound that matches the generic upper bound for any deterministic MAC built from a pseudorandom permutation. SMB 3.0 through 3.1.1 use AES-CMAC as the default signing algorithm; AES-GMAC, introduced as a negotiable alternative in 2021, replaces it on hardware where Galois-field multiplication is faster than AES-CBC.
Authenticated Encryption with Associated Data. A class of symmetric encryption scheme that simultaneously provides confidentiality of the message body and integrity of both the body and a separate "associated data" header. AES-CCM (SP 800-38C) [@nist-sp-800-38c] and AES-GCM (SP 800-38D) [@nist-sp-800-38d] are the two AEADs SMB 3.x uses. AEADs replace the older "encrypt-then-MAC" or "MAC-then-encrypt" compositions, which historically were a rich source of cryptographic mistakes.
NIST identifies AES-CMAC by the cipher and mode strings; the construction is mathematically equivalent to Tetsu Iwata and Kaoru Kurosawa's OMAC1 from 2003. SP 800-38B notes the lineage, attributing the design to Iwata-Kurosawa with subsequent refinements by Black-Rogaway [@nist-sp-800-38b].
### SMB 3.0.2 Secure Negotiate (October 18, 2013) [@ms-smb2-versioning]
Windows 8.1 and Server 2012 R2 shipped dialect `0x0302` with a post-hoc validation message: `FSCTL_VALIDATE_NEGOTIATE_INFO`. The idea was that after authentication, the client would send the server its view of what NEGOTIATE looked like, signed by the freshly-derived session key. The server compared the client's view against its own, and if they disagreed, the connection terminated. This was the first protocol-level attempt to detect negotiate-downgrade in SMB. It is also, retrospectively, the most instructive failure.
Secure Negotiate had five structural limits, and each of them mattered:
1. **It was post-hoc, not preventive.** The session key was already derived. The encryption capability was already mutually decided. If an attacker had stripped encryption, you were going to *detect* that you were in a degraded session and tear it down. You were not going to prevent the degradation in the first place.
2. **The FSCTL was skippable.** A pre-3.0 client did not send `FSCTL_VALIDATE_NEGOTIATE_INFO`. An attacker who downgraded a 3.0.2 client to 2.0 simply got a session that never asked the question.
3. **It validated capability bits, not every byte of NEGOTIATE.** The FSCTL message contained a fixed structure with specific fields. Tampering that did not touch those specific fields could survive validation.
4. **It inherited the dialect-monopoly extensibility flaw.** Adding a new capability meant adding a new bit to the capability bitmap, which the Secure Negotiate FSCTL would also have to learn about. The structure was not future-proof.
5. **It was trust-on-second-use, not first-use.** The signed FSCTL validated *that this session's NEGOTIATE was not tampered with* only after authentication had completed. The first message of authentication itself, where the attacker could rewrite signing requirements, was still vulnerable.
An attack on a protocol with an in-band cryptographic capability negotiation in which an in-path attacker tampers with the negotiation messages so that the two endpoints agree on a weaker algorithm, or no algorithm at all. SMB-relay-class attacks before 2015 universally relied on negotiate-downgrade: the attacker stripped the `SMB2_NEGOTIATE_SIGNING_REQUIRED` bit from the NEGOTIATE Response, and the resulting session was unsigned and forwardable. The structural defence against negotiate-downgrade is to bind every byte of the negotiation transcript into the key-derivation function, which is what TLS 1.2 Finished and SMB 3.1.1 pre-authentication integrity both do, by different mechanics.
> **Note:** Every SMB defence before 2015 was a tag applied after-the-fact to a message an attacker already controlled. Signing was opt-in. The signing-required bit was strippable during unsigned NEGOTIATE. Secure Negotiate detected tampering only after the attacker had already chosen what to tamper with. The shape of the fix is forced once you state the flaw this way: the negotiation has to bind into the key-derivation function itself, so that tampering does not produce a detectable mismatch -- it produces session keys that simply do not work.
### Five generations, one column
The shape of the failure is easiest to see in a table.
| Generation | Year | Signing | Encryption | NEGOTIATE protection | Why it failed |
|------------|------|---------|------------|----------------------|---------------|
| SMB1 cleartext | 1983-1996 | None | None | None | No cryptography at all |
| SMB1 + MD5 | 1997-2006 | Opt-in MD5 truncated to 8 bytes | None | None | Signing-required bit strippable in unsigned NEGOTIATE |
| SMB 2.0 / 2.1 | 2006-2012 | HMAC-SHA-256 | None | None | Same NEGOTIATE-strip primitive, stronger MAC |
| SMB 3.0 | 2012-2013 | AES-CMAC | AES-128-CCM | None | Strip the `SMB2_GLOBAL_CAP_ENCRYPTION` bit and CCM never runs |
| SMB 3.0.2 | 2013-2015 | AES-CMAC | AES-128-CCM | Post-hoc FSCTL | Detection, not prevention; skippable by older clients |
Read the **NEGOTIATE protection** column top to bottom. *None / None / None / None / Post-hoc FSCTL.* Twenty-five years of cryptographic work without a single defence that bound the negotiation transcript to the eventual session key. Then, in 2015, buried in the unremarkable `.1` of a `.1` dialect bump, the SMB team finally fixed the load-bearing weakness.
sequenceDiagram
participant C as Client
participant M as In-path attacker
participant S as Server
C->>M: NEGOTIATE Request, signing required, ciphers AES-128-CCM
M->>S: NEGOTIATE Request, signing required, ciphers AES-128-CCM
S->>M: NEGOTIATE Response, signing required, encryption capability set
M->>C: NEGOTIATE Response with signing-required bit cleared, encryption capability removed
Note over C,S: Client and server now agree on an unsigned, unencrypted session
C->>M: SESSION_SETUP Request, no signature
M->>S: Relayed SESSION_SETUP Request
Note over M,S: Attacker controls the cleartext channel
## 4. The Hash Chain Becomes the Salt
On **July 29, 2015**, Windows 10 RTM (build 10240, version 1507) shipped a protocol that no relay tool released since has been able to downgrade [@win10-release-info]. The fix was not what most readers remember. It was much stranger and much cleaner.
The dialect was `0x0311`, "SMB 3.1.1" [@ms-smb2-versioning]. Greg Kramer and Dan Lovinger of the Microsoft SMB team presented the design at the SNIA Storage Developer Conference that September [@kramer-lovinger-sdc2015]. The deck contains the single most-quoted sentence in modern SMB cryptography:
"Preauthentication Integrity ... Provides end-to-end, dialect agnostic protection. Session's secret keys derived from hash of the preauthentication messages." -- Greg Kramer and Dan Lovinger, SNIA SDC 2015 [@kramer-lovinger-sdc2015]
Most secondary references to the SDC 2015 deck cite "Greg Kramer" only. The title slide lists two authors: Greg Kramer, Principal Software Engineer, and Dan Lovinger, Principal Software Engineer, both at Microsoft. The 2015 design has two names on it [@kramer-lovinger-sdc2015].
The misremembered framing of SMB 3.1.1 pre-authentication integrity is that "negotiate contexts are signed by the eventual session key." That is not what happens. The actual mechanism is more elegant and structurally stronger.
### The four updates of the hash chain
SMB 3.1.1 defines a per-connection variable called `PreauthIntegrityHashValue`, initialised to 64 zero bytes [@ms-smb2-pdf]. Across the four messages of the pre-authentication phase, both client and server update it with the same rule:
$$H_i = \mathrm{SHA{-}512}(H_{i-1} \mathbin{\|} M_i)$$
The four messages are NEGOTIATE Request, NEGOTIATE Response, SESSION_SETUP Request, and SESSION_SETUP Response. After all four are processed, the running hash `H_4` contains a cryptographic commitment to every byte that crossed the wire during pre-authentication.
This commitment has no value if it stays a local variable. The structural move is in the next step. SMB 3.1.1 uses the NIST SP 800-108 counter-mode KDF [@nist-sp-800-108r1] to derive every per-session key from the authentication-protocol session secret (the NTLM `ExportedSessionKey` or the [Kerberos](/blog/kerberos-in-windows-the-other-half-of-ntlmless/) service-ticket session key). The KDF takes two arguments alongside the secret: a `Label` identifying the role of the derived key, and a `Context` argument.
**The `Context` argument is `PreauthIntegrityHashValue`.**
That is the whole trick. The hash chain enters the key-derivation function as salt. It does not protect the negotiation by tagging it; it protects the negotiation by being part of the input to the function that produces the session keys.
> **Key idea:** Pre-authentication integrity is not a signed negotiate. It is a SHA-512 hash chain over the four pre-authentication messages whose final value becomes the `Context` argument to the SP 800-108 KDF that derives every per-session key. Tampering does not get *detected*. Tampering causes the two sides to compute different keys, and the first signed message after SESSION_SETUP simply fails to verify on both ends.
The SMB 3.1.1 mechanism that binds every byte of the four pre-authentication messages (NEGOTIATE Request and Response, SESSION_SETUP Request and Response) into the salt input of the SP 800-108 key-derivation function that derives all per-session SMB keys [@kramer-lovinger-sdc2015][@ms-smb2-pdf]. The bind is constructed by iterating SHA-512 over each pre-authentication message in turn. The mechanism is mandatory in dialect 0x0311; there is no policy switch to disable it.
A family of key-derivation functions standardised by NIST in Special Publication 800-108 [@nist-sp-800-108r1], parameterised by a pseudorandom function (HMAC, KMAC, or CMAC) and a mode (counter, feedback, double-pipeline). SMB 3.x uses CTR-HMAC-SHA-256. The function takes a secret key, a `Label`, a `Context`, and a desired output length, and returns the requested number of bits as a deterministic, distinguishable derivation of the key. In SMB 3.1.1, the `Context` argument is the pre-authentication hash chain; the `Label` is one of four constant strings naming the role of the derived key.
### The four key labels
The four per-session keys SMB 3.1.1 derives are tagged with constant `Label` strings, lifted directly from [MS-SMB2] §3.2.5.3.1 [@ms-smb2-pdf]:
- `"SMBSigningKey"` -- the key used for the per-packet AES-CMAC or AES-GMAC signature.
- `"SMBAppKey"` -- the application-layer key that some named pipes can use to derive sub-keys.
- `"SMBC2SCipherKey"` -- the client-to-server AES encryption key, fed to AES-CCM or AES-GCM.
- `"SMBS2CCipherKey"` -- the server-to-client encryption key.
Each label is passed as the SP 800-108 `Label` argument; the same `PreauthIntegrityHashValue` is passed as the `Context` argument. Different labels produce different keys from the same secret and the same salt; that is what makes role separation work without four separate hash chains.
The AES-256 ciphers in SMB 3.1.1 consume `Session.FullSessionKey` rather than the truncated 16-byte `Session.SessionKey` that AES-128 ciphers use [@ms-smb2-pdf]. This is the structural reason an AES-256 SMB session is cryptographically 256-bit-secure rather than capped at 128. The detail matters for anyone evaluating SMB against CNSA 2.0 requirements: the implementation does the right thing, but only because the specification said so explicitly.
### Why this is stronger than Secure Negotiate
Place SMB 3.0.2 Secure Negotiate and SMB 3.1.1 pre-authentication integrity side by side:
| Property | Secure Negotiate (SMB 3.0.2) | Pre-auth integrity (SMB 3.1.1) |
|----------|------------------------------|--------------------------------|
| Coverage | Dialect index + capability bitmap | Every byte of all four pre-auth messages |
| When | Post-hoc, after session key derived | At the moment of key derivation |
| Failure mode | Detection: signed FSCTL mismatches | Implicit: derived keys diverge |
| Disable switch | Skipped by pre-3.0 clients | None; mandatory in 0x0311 |
| Extensibility | Hard-coded fields in FSCTL | Hashes whatever bytes flow |
Secure Negotiate had to know *what* it was protecting. Pre-auth integrity does not. The hash chain absorbs whatever bytes the dialect happens to carry: new negotiate contexts in future dialects, new capability bits, new ciphers. The mechanism does not need to be updated to learn about them, because it does not parse them. It hashes them.
### The per-context salts
There is one more subtlety. The `SMB2_PREAUTH_INTEGRITY_CAPABILITIES` negotiate context, defined in [MS-SMB2] §2.2.3.1.1, contains a 32-byte `Salt` field that the client and server populate with fresh PRNG output for each connection [@ms-smb2-pdf]. The salt is hashed in along with everything else, so two different connections from the same client to the same server end up with different `PreauthIntegrityHashValue` values even if every other byte of NEGOTIATE is identical.
The point is not to add entropy to the session key (which already gets entropy from the authentication exchange) but to defeat any attempt at pre-image or rainbow-table attacks on the hash chain itself. SHA-512 is the only hash function currently negotiated, and its 256-bit collision resistance is the protocol floor for pre-authentication integrity.
> **Note:** The Microsoft Learn pages, the docs aggregators, and several widely-cited tertiary references describe SMB 3.1.1 pre-authentication integrity as "signing the negotiate contexts with the session key." That description is wrong in a way that matters. There is no separate signed message validating the negotiation. The protection is constructed by feeding the hash of every pre-authentication message into the KDF that produces the session key. If you remember it as a signed negotiate, you will not understand why it is structurally stronger than Secure Negotiate. The mechanism is a *KDF binding*, not a signature.
### The empirical demonstration
The fastest way to feel the mechanism is to watch keys diverge in real time. The runnable code below produces two parallel SP 800-108-style derivations: an honest one where client and server hash the same four messages, and a tampered one where an in-path attacker flips a single byte in `NEGOTIATE Response`. The two derivations produce identical keys in the honest case and visibly different keys in the tampered case.
{`
const { createHmac, createHash } = require('crypto');
function sha512(buf) {
return createHash('sha512').update(buf).digest();
}
function updateChain(H, message) {
return sha512(Buffer.concat([H, Buffer.from(message)]));
}
// SP 800-108 CTR-HMAC-SHA-256 in its simplest 32-byte-output form
function kdfSP108(secret, label, context, length) {
const out = [];
let i = 1;
while (out.reduce((n, b) => n + b.length, 0) < length) {
const counter = Buffer.alloc(4);
counter.writeUInt32BE(i++, 0);
const block = createHmac('sha256', secret)
.update(counter)
.update(Buffer.from(label, 'utf8'))
.update(Buffer.from([0]))
.update(context)
.update(Buffer.from([0, 0, 1, 0]))
.digest();
out.push(block);
}
return Buffer.concat(out).subarray(0, length);
}
const NEGOTIATE_REQ = 'NEGOTIATE Request (client, signing required)';
const NEGOTIATE_RESP = 'NEGOTIATE Response (server, signing required)';
const SESSION_REQ = 'SESSION_SETUP Request (NTLM challenge response)';
const SESSION_RESP = 'SESSION_SETUP Response (success)';
function derive(messages) {
let H = Buffer.alloc(64, 0);
for (const m of messages) H = updateChain(H, m);
const authSecret = Buffer.from('AUTHENTICATION_PROTOCOL_SHARED_SECRET');
return kdfSP108(authSecret, 'SMBSigningKey', H, 16).toString('hex');
}
const honestClient = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]);
const honestServer = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]);
console.log('honest client:', honestClient);
console.log('honest server:', honestServer);
console.log('match:', honestClient === honestServer);
// Attacker flips one byte in NEGOTIATE Response only on the client side
const tamperedClient = derive([NEGOTIATE_REQ, NEGOTIATE_RESP.replace('required', 'optional'), SESSION_REQ, SESSION_RESP]);
const honestServer2 = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]);
console.log('tampered client:', tamperedClient);
console.log('honest server: ', honestServer2);
console.log('match:', tamperedClient === honestServer2);
`}
The honest pair of keys match. The tampered pair do not. The first signed READ that arrives at the server gets verified with a key that does not match the one the client used to sign it, and the server returns `STATUS_USER_SESSION_DELETED`. The attacker has not been detected by a validation message; she has been routed around by a key-derivation function.
sequenceDiagram
participant C as Client
participant S as Server
Note over C,S: H starts as 64 zero bytes on both sides
C->>S: NEGOTIATE Request
Note over C,S: H = SHA-512(H, NEGOTIATE Request)
S->>C: NEGOTIATE Response
Note over C,S: H = SHA-512(H, NEGOTIATE Response)
C->>S: SESSION_SETUP Request
Note over C,S: H = SHA-512(H, SESSION_SETUP Request)
S->>C: SESSION_SETUP Response
Note over C,S: H = SHA-512(H, SESSION_SETUP Response)
Note over C,S: H enters SP 800-108 KDF as Context, derives SigningKey, CipherKey
flowchart LR
A[Authentication secret] --> B[SP 800-108 CTR-HMAC-SHA-256 KDF]
L[Label: SMBSigningKey or SMBC2SCipherKey or SMBS2CCipherKey or SMBAppKey] --> B
H[Context: PreauthIntegrityHashValue] --> B
B --> K1[SigningKey]
B --> K2[Client-to-server CipherKey]
B --> K3[Server-to-client CipherKey]
B --> K4[AppKey]
A type-length-value carrier introduced in SMB 3.1.1's NEGOTIATE Request and Response so that future dialects can add new cryptographic capabilities without changing the parent message structure. Each context has a 2-byte type identifier, a length, and a body. The defined types include `SMB2_PREAUTH_INTEGRITY_CAPABILITIES` (the hash function and salt), `SMB2_ENCRYPTION_CAPABILITIES` (the encryption ciphers offered), and `SMB2_SIGNING_CAPABILITIES` (the signing algorithms offered, added in 2021 to support AES-GMAC). Because all negotiate contexts are part of the pre-authentication message stream, they are all hashed into `PreauthIntegrityHashValue` automatically [@ms-smb2-pdf].
From this moment forward, every byte of NEGOTIATE and SESSION_SETUP is cryptographically bound to the eventual session key. There is no way an in-path attacker can downgrade a 3.1.1 connection without producing two divergent session keys and therefore no signed message after authentication can possibly verify on both sides. The mechanism does have one limit, and it is the one that the next decade of SMB hardening had to deal with: pre-authentication integrity ensures that *if* signing or encryption is negotiated, an attacker cannot tamper with the negotiation. It does not require either to be negotiated.
## 5. The 2021 Cipher Refresh and SMB-over-QUIC
Six years after pre-authentication integrity shipped, two parallel additions arrived in the same Windows release window. Windows 11 21H2 and Server 2022, both from the second half of 2021, extended the SMB cipher matrix and introduced a new transport that ran SMB inside QUIC instead of TCP.
### The 2021 cipher refresh
The Negotiate Context machinery designed in 2015 absorbed three new values for `EncryptionAlgorithmId` without a dialect bump [@ms-smb2-versioning]:
- `0x0002`: AES-128-GCM (already shipped with SMB 3.1.1 in 2015)
- `0x0003`: AES-256-CCM (added 2021)
- `0x0004`: AES-256-GCM (added 2021)
A fourth addition was the `SMB2_SIGNING_CAPABILITIES` negotiate context, which let the dialect negotiate **AES-GMAC** as a signing algorithm alongside AES-CMAC and HMAC-SHA-256 [@ms-smb2-versioning]. AES-GMAC is the authentication-only mode derived from AES-GCM, defined in NIST SP 800-38D [@nist-sp-800-38d].
| `EncryptionAlgorithmId` | Algorithm | Key | First SMB version | CNSA 2.0 compatible | Notes |
|-------------------------|-----------|-----|-------------------|---------------------|-------|
| `0x0001` | AES-128-CCM | 128 bits | SMB 3.0 (2012) | No | Two-pass AEAD; pre-AES-NI baseline |
| `0x0002` | AES-128-GCM | 128 bits | SMB 3.1.1 (2015) | No | Single-pass AEAD; faster than CCM on AES-NI |
| `0x0003` | AES-256-CCM | 256 bits | SMB 3.1.1 (2021 cipher refresh) | Yes | CNSA-grade; rarely chosen over GCM |
| `0x0004` | AES-256-GCM | 256 bits | SMB 3.1.1 (2021 cipher refresh) | Yes | CNSA-grade and AES-NI / VAES accelerated |
The U.S. National Security Agency's Commercial National Security Algorithm Suite version 2.0, published in 2022 as the symmetric and asymmetric algorithm baseline for protecting U.S. classified information up to TOP SECRET. The symmetric component requires AES-256 in any AEAD mode for confidentiality and AES-256-GMAC or HMAC-SHA-384 for integrity. The SMB combination that satisfies CNSA 2.0 is AES-256-GCM for encryption and AES-GMAC for signing; AES-128 variants are not CNSA-eligible.
### Why AES-GMAC won the speed argument
AES-CMAC runs AES in CBC mode over the message, with one AES block operation per 16 bytes of input. AES-GMAC reuses the GCM mode's Galois-field multiplier, GHASH, which can be implemented in parallel using a single AES key-schedule and the PCLMULQDQ carry-less multiplication instruction that Intel added with the Westmere generation in 2010 [@iacr-2018-392].PCLMULQDQ multiplies two 64-bit operands as polynomials over GF(2), bypassing the carry chain that makes integer multiplication slow. It is the workhorse of every modern AES-GCM implementation.
Drucker, Gueron and Krasnov's 2018 ePrint *Making AES Great Again* documents the performance ceiling on contemporary Intel hardware [@iacr-2018-392]. They measured **0.64 cycles per byte for AES-GCM single-buffer** on Skylake-X with AES-NI and PCLMULQDQ, and projected the theoretical bound at **0.16 cycles per byte** for the AVX-512 + VPCLMULQDQ multi-buffer variant on Ice Lake.
The single-buffer ratio against AES-CMAC, which the same paper notes runs at roughly 2 to 3 cycles per byte on equivalent hardware, is about 3 to 5x. The multi-buffer ratio is larger, often 6x or more, because GMAC parallelises across independent 16-byte blocks where CMAC's CBC chain serialises them.
Taken together, those numbers mean that on a modern file server saturating a 25 Gbit/s NIC, AES-GMAC signing costs roughly one-third the CPU of AES-CMAC for the same packet rate. That is not a marginal optimisation; it is the difference between needing two cores to sign and needing one.
### SMB-over-QUIC
The second 2021 addition was a new transport. Microsoft demoed SMB-over-QUIC in early 2021 and shipped it for general availability in November 2021 with the Windows Server 2022 Datacenter: Azure Edition SKU [@smb-over-quic]. The transport runs SMB inside a QUIC connection (RFC 9000 [@rfc9000]) whose record layer is encrypted by TLS 1.3 (RFC 8446 [@rfc8446]) and bound to QUIC by RFC 9001 [@rfc9001]. The wire-layer port is UDP/443, the same port HTTPS-over-QUIC uses, which means SMB-over-QUIC traverses most firewalls that already pass web traffic.
A UDP-based multiplexed and secure transport protocol designed by Google in 2012 and standardised at IETF in 2021 as RFC 9000 [@rfc9000]. QUIC carries multiple independent streams of reliable bytes inside a single connection, uses TLS 1.3 for the cryptographic handshake (RFC 9001 [@rfc9001]), and identifies connections by a connection ID rather than the 5-tuple, which means a QUIC connection survives an IP address change. SMB-over-QUIC uses QUIC's reliable stream abstraction to carry the SMB packets that would otherwise go over TCP, and inherits QUIC's TLS 1.3 record-layer encryption.
### The trust-anchor shift
SMB-over-TCP/445 trusts only the authentication protocol. If Kerberos or NTLM trusts the principal, the SMB session derives a key from that authentication and proceeds. There is no other trust input.
SMB-over-QUIC adds **server certificate PKI** to the trust model. The QUIC handshake authenticates the server with a TLS 1.3 X.509 certificate chain that must validate against the client's trust store. This is a real change in threat model: a compromised certificate authority in the client's root store can MITM SMB-over-QUIC the same way it can MITM HTTPS. For some organisations that is a feature, a trust anchor that lives in the certificate authority instead of in Kerberos. For others it is a regression.
The original SMB-over-QUIC release was restricted to Windows Server 2022 Datacenter: Azure Edition, a SKU available only as an Azure-hosted virtual machine [@smb-over-quic]. That restriction made SMB-over-QUIC effectively unusable for the on-premises file-server population that the protocol most needed. The restriction was lifted with Windows Server 2025, which broadens SMB-over-QUIC hosting to every edition of the server SKU [@ws-2025-whats-new][@smb-over-quic]. On the client side, Windows 11 24H2 became the first SMB-over-QUIC-capable mainstream desktop client [@smb-feature-descriptions].
Samba 4.15.0 (September 2021) added the SMB3 signing-algorithm-negotiation parameters (`client smb3 signing algorithms`, `server smb3 signing algorithms`) and the SMB3 encryption-algorithm-negotiation parameters, and fixed AES-256-GCM/CCM server-side support that was previously broken under bug 14764 [@samba-4-15-0]. SMB-over-QUIC support for both `smbd` and `smbclient` did not arrive in Samba until 4.23.0, in September 2025, closing a four-year interop gap with the November 2021 Microsoft release [@samba-4-23-0].
The 2021 refresh handed enterprises CNSA-grade ciphers and a no-VPN remote-file-access transport. But signing was still opt-in by default for general SMB shares, and the SMB-relay toolkit that Sir Dystic released in 2001 still worked against any 21H2 client that an administrator had not hardened by hand. The defaults had not caught up.
## 6. The 2024 Defaults: Locks Finally Turned On
On **October 1, 2024**, Windows 11 24H2 shipped to retail [@win11-release-info]. A month later, on November 1, 2024, Windows Server 2025 followed [@ws-2025-whats-new]. The two releases changed seven defaults in one go, and exactly one of those changes mattered most.
The headline change was structural: SMB signing required by default on both outbound and inbound connections for every share, not just SYSVOL and NETLOGON [@smb-security-hardening]. The Microsoft Learn SMB Security Hardening page states it directly:
> Starting with Windows 11 24H2 and Windows Server 2025, all outbound and inbound SMB connections are now required to be signed by default. Previously, SMB signing was only required by default for connections to shares named SYSVOL and NETLOGON, and for clients of AD domain controllers. [@smb-security-hardening]
Ned Pyle, the Microsoft file server product manager who has shipped SMB releases for the better part of a decade, summarised the bundle in a Tech Community post that doubles as the canonical 2024 reference:
"With the release of Windows Server 2025 and Windows 11 24H2, we have made the most changes to SMB security since the introduction of SMB 2 in Windows Vista." -- Ned Pyle, Microsoft [@pyle-techcom-4226591]
### The bundle, in priority order
1. **Signing required by default**, the load-bearing change. The omission-downgrade attack that has worked since 2001 is structurally closed for any 24H2-or-later pair, because the server will refuse an unsigned session [@smb-security-hardening][@pyle-techcom-4226591].
2. **Client-side encryption mandate**, available but **not on by default**. `Set-SmbClientConfiguration -RequireEncryption $true` now refuses any outbound SMB session that does not negotiate AES-GCM encryption [@smb-security-hardening]. The most-misreported fact about the 2024 rollout is whether this is on. It is not.
3. **Authentication rate limiter.** A 2-second delay between failed NTLM or local-KDC Kerberos authentication attempts, configurable but on by default. Microsoft's published arithmetic: an attack that sends 300 guesses per second for 5 minutes (90,000 attempts) now takes 50 hours [@smb-security-hardening].
4. **NTLM blocking for outbound SMB.** `Set-SmbClientConfiguration -BlockNTLM $true` refuses outbound NTLM fallback, forcing Kerberos or failing the session [@smb-security-hardening].
5. **SMB dialect minimum and maximum**, configurable per-host on both client and server [@smb-security-hardening].
6. **SMB alternative ports**, so that an administrator can run SMB-over-QUIC on a non-default UDP port without losing audit support [@smb-security-hardening].
7. **Insecure guest authentication blocked by default**, on every edition of Windows 11, closing a gap that previously only Enterprise and Education had been opted into since Windows 10 1709 [@smb-interception-defense].
The eighth change, also part of the 2024-2025 cycle but described in the Server 2025 release notes rather than the hardening page, was the **broadening of SMB-over-QUIC hosting** from the Azure Edition SKU to every edition of Windows Server 2025 [@ws-2025-whats-new][@smb-over-quic]. That broadening is the transport-side enabler for the rest of the bundle, because it makes SMB-over-QUIC available to organisations that do not run their file servers in Azure.
> **Note:** The 2024-2025 rollout made SMB **signing** required by default. It did not make SMB **encryption** required by default. A 24H2 client speaking to a Server 2025 file share without an administrator's opt-in will still send the file's contents over the wire in cleartext, with only the per-packet AES-CMAC signatures preventing tampering. A passive eavesdropper on the path can still read the file. The fix is one line of PowerShell (`Set-SmbClientConfiguration -RequireEncryption $true`) or a per-share `Set-SmbShare -EncryptData $true`. Several widely-circulated 2024 press summaries got this backwards; the Microsoft Learn page is the source of truth [@smb-security-hardening].
### The arc, closed
The 2001 SMBRelay disclosure to the 2024 default-on flip is twenty-three years and seven months [@smbrelay-cdc][@smb-security-hardening]. That is the arithmetic of the SMB story. The mechanism that closed the omission-downgrade attack family for the typical Windows file share existed in production from July 2015 onwards; the defaults that made the mechanism universal arrived nine years later.
The 2024 default does not retroactively secure the long tail of legacy hosts: the SMB-relay primitive that Sir Dystic shipped in 2001 still works against any pre-24H2 Windows client that an administrator has not turned signing on for by hand, and against any third-party SMB server that does not yet support signing. Default-on protects the leading edge; the legacy fleet upgrades on its own calendar.
### The compatibility breakage
The default-on signing flip broke a long tail of consumer NAS devices that ship SMB server implementations without signing support. Synology and QNAP and NETGEAR home NAS units running older firmware refused 24H2 client connections starting October 2024, and the recovery path required either a firmware update from the vendor or a per-host policy exception. The DSInternals matrix tracks the exact set of clients and servers that pass the new defaults [@dsinternals-24h2].
### What still works: the cross-protocol relay class
Default-on signing closed the *single-protocol* SMB relay. It did nothing about the *cross-protocol* relay class, which routes around SMB entirely. The exemplar attack is [PetitPotam](/blog/ntlmless-the-death-of-ntlm-in-windows/), disclosed by Lionel "Topotam" Gilles in July 2021 [@petitpotam-gh][@nvd-cve-2021-36942], with a sibling variant CVE-2022-26925 on the LSARPC interface [@nvd-cve-2022-26925].
PetitPotam abuses the Encrypting File System Remote Protocol (MS-EFSRPC). The `EfsRpcOpenFileRaw` method, exposed via the LSARPC named pipe over SMB, accepts a UNC path that the server resolves by **opening an outbound SMB connection** to whatever host the path points at, using the calling user's credentials [@petitpotam-gh].
An attacker who can call `EfsRpcOpenFileRaw` on a server with a UNC path pointing back at the attacker's host obtains an outbound NTLM authentication from the server, typically a domain controller, since DCs run the EFSRPC service. The attacker then relays that NTLM authentication, not to another SMB server, but to **[Active Directory Certificate Services](/blog/certified-pre-owned-ad-cs-and-active-directorys-second-trust/) Web Enrollment** at `/certsrv/`, which speaks HTTP and historically did not require client-side signing of the authentication.
Once the relay completes, the attacker has a certificate issued in the name of the coerced principal, which on a domain controller is a domain controller account. From there, the attacker forges Kerberos tickets and the domain is compromised.
A 2019 result by Marina Simakov and Yaron Zinar at Preempt (now CrowdStrike), CVE-2019-1040, sharpens the cross-protocol concern further [@drop-the-mic][@nvd-cve-2019-1040]. The pair found that an in-path attacker could bypass the NTLM Message Integrity Code by manipulating SPNEGO fields, then strip the "signing required" bit from the relayed NTLM message itself.
That meant a relay attack could survive against targets that required NTLM signing, because the signing-required negotiation could be tampered with on the NTLM authentication exchange. Microsoft patched CVE-2019-1040 in 2019, but the result underscored the same lesson at the NTLM layer that SMB had learned at the SMB layer: any signing negotiation that is not bound to the eventual key derivation can be stripped.
A coercion-and-relay attack family disclosed by Lionel Gilles in July 2021 [@petitpotam-gh] in which the attacker invokes MS-EFSRPC `EfsRpcOpenFileRaw` on a target server with a UNC path that the server resolves by opening an outbound SMB connection, leaking the server's NTLM credentials to the attacker. The leaked credentials are then relayed cross-protocol to AD CS Web Enrollment over HTTPS. The class subsumes CVE-2021-36942 (LSA over the LSARPC pipe) and CVE-2022-26925 (a sibling LSARPC variant). The defence is **not** SMB signing on the target; it is Extended Protection for Authentication on the relay-to endpoint [@kb5005413].
A defence against NTLM relay attacks that binds the underlying transport's channel (typically a TLS server certificate hash) into the GSS channel-binding token that the SPNEGO authentication exchange carries [@kb5005413]. An attacker who relays an NTLM authentication from a victim's connection to an attacker-controlled TLS connection finds that the channel bindings disagree, and the relay-to endpoint refuses the authentication. EPA on AD CS `/certsrv/` is the canonical fix for PetitPotam-class attacks [@kb5005413].
> **Key idea:** SMB at the wire layer is now cryptographically sufficient. Modern SMB-related attacks no longer try to break SMB. They coerce SMB into authenticating and then relay the authentication to a protocol that does not require signing. The defence is no longer a single-protocol problem. Extended Protection for Authentication on AD CS, and eventually NTLM removal, are the structural fixes -- nothing at the SMB layer can close the cross-protocol relay class.
sequenceDiagram
participant A as Attacker
participant V as Victim DC
participant ADCS as ADCS Web Enrollment over HTTPS
A->>V: LSARPC EfsRpcOpenFileRaw, UNC path to attacker share
V->>A: Outbound SMB NEGOTIATE with NTLM credentials of DC machine account
Note over A,V: SMB signing on V does not help, V is the client
A->>ADCS: Relayed NTLM authentication to /certsrv/certfnsh.asp
ADCS->>A: Issues certificate for DC machine account
Note over A,ADCS: Without EPA on /certsrv/ the relay succeeds
The 2024 hardening package is real progress. It is also explicitly bounded. The headline change closes one attack class structurally and leaves the cross-protocol class untouched. To see what is still open, we have to leave SMB for a moment and look at the cryptographic limits the protocol still inherits.
### A short PowerShell-equivalent for the audit
To verify the new defaults on a freshly imaged 24H2 client, run `Get-SmbClientConfiguration | Select RequireSecuritySignature` and the server analogue. The runnable snippet below shows the *logic* of those commands in JavaScript: readable, not directly executable on Windows.
{`
const smbClientPolicyOn24H2 = {
RequireSecuritySignature: true,
EnableSecuritySignature: true,
BlockNTLM: false,
RequireEncryption: false,
AuditServerDoesNotSupportEncryption: true,
AuditServerDoesNotSupportSigning: true,
};
function reportPosture(cfg) {
if (cfg.RequireSecuritySignature) {
console.log('Signing: required (24H2 default).');
} else {
console.log('Signing: NOT required. Run Set-SmbClientConfiguration -RequireSecuritySignature true.');
}
if (cfg.RequireEncryption) {
console.log('Encryption: required.');
} else {
console.log('Encryption: opt-in only. Consider Set-SmbClientConfiguration -RequireEncryption true.');
}
if (cfg.BlockNTLM) {
console.log('NTLM outbound: blocked.');
} else {
console.log('NTLM outbound: allowed. Consider -BlockNTLM true on hardened hosts.');
}
}
reportPosture(smbClientPolicyOn24H2);
`}
## 7. What SMB 3.1.1 Cannot Do
Five things SMB 3.1.1 cannot do, even with every default flipped on and every primitive at full strength.
**1. Pre-authentication integrity is dialect-internal.** The mechanism binds the negotiation transcript to the session key inside SMB. It cannot stop an in-path attacker from refusing to forward a connection at all. Denial of service is structurally outside the threat model of any signing or encryption primitive; the only defence is path redundancy.
**2. Signing requires both endpoints to support it.** A 24H2 client refuses to talk unsigned to a pre-24H2 server only if the server is willing to sign. A pre-24H2 server that runs without signing turned on -- the long tail of consumer NAS, embedded appliances, older Linux Samba installs, ESXi datastores -- still answers an unsigned NEGOTIATE and still produces an unsigned session. The omission-downgrade is closed only for 24H2-to-24H2 pairs (or 24H2-to-Samba-4.15+ pairs). The legacy fleet upgrades over years, not weeks.
**3. Encryption is not authenticated key exchange.** The SMB session key derives from the authentication protocol's session secret -- the NTLM `ExportedSessionKey` or the Kerberos service-ticket session key [@ms-smb2-pdf]. SMB inherits whatever weakness the authentication protocol carries. A user with a 30-bit-entropy password who authenticates with NTLM has a session key whose effective entropy is bounded above by the password's. AES-256-GCM does not save that user; the symmetric ciphers are working as advertised, but the secret they are protecting is too weak to survive an offline attack on the password hash.
> **Key idea:** SMB encryption is upper-bounded by the password entropy of the authentication protocol that derived the session key. AES-256 does not improve a weak password. Pre-authentication integrity does not improve a weak password. The cryptographic primitives are doing what they say they do; the limit is one layer higher.
This is the protocol-level analogue of the older cryptographic adage that you cannot create entropy from key-stretching alone. PBKDF2 with a million iterations slows an attacker down by a factor of a million, but if the password has 30 bits of entropy, the work factor is still 2^30 -- a million iterations on a modern GPU is on the order of an hour for a single targeted password.
**4. SMB-over-QUIC binds the trust anchor to TLS 1.3 PKI.** Over TCP/445, SMB trusts only Kerberos or NTLM. Over QUIC, SMB additionally trusts the certificate authorities in the client's TLS trust store.
A compromised CA in that store can MITM SMB-over-QUIC the way it MITMs HTTPS. The inner SMB layer's pre-authentication integrity will catch tampering with the SMB session itself, but the outer QUIC layer is now in the threat model. Whether this is a feature or a regression depends on whether you trust your TLS trust store more than you trust the Kerberos service that issues your tickets.
**5. Cross-protocol relay survives single-protocol hardening.** This is the strongest impossibility result that touches SMB. If protocol A (SMB) coerces an outbound authentication from a victim host, and the attacker relays that authentication cross-protocol to a target running protocol B (HTTPS to AD CS Web Enrollment) that does not require signing, no amount of hardening on protocol A's session layer prevents the attack.
The fix has to live in the target's session layer (EPA on `/certsrv/`) or in the authentication protocol itself (NTLM disablement). Closing it at the SMB layer is, in the precise cryptographic sense, impossible.
The observation that the effective security of an SMB session against an offline attack is bounded above by the entropy of the authentication-protocol shared secret that derived the SMB session key, not by the bit length of the negotiated AES cipher. A 256-bit cipher protecting a session key derived from a 30-bit-entropy password offers, against an offline attacker who can capture the authentication exchange, no more than 30 bits of work-factor security. SMB inherits this property from any authentication protocol whose key-establishment phase is a password-equivalent shared-key derivation.
Of these five, three are deployment posture and two are structural. You can fix #2 by replacing the legacy fleet. You can fix #4 by curating your TLS trust store, removing CAs you do not need to trust, and pinning the AD CS PKI explicitly. You can fix #5 by removing NTLM, which Microsoft is in the middle of doing. Limits #1 (denial of service) and #3 (password-equivalence) are not deployment posture; they are properties of the underlying cryptographic objects, and they will be true of any SMB-shaped protocol that inherits a session key from an authentication exchange.
## 8. Competing Protocols, Parallel Paths
SMB is one of four families of file-sharing protocols a modern enterprise might deploy. Each made different cryptographic choices, and each got something right that the others got wrong.
### NFS v4.2 with `sec=krb5p`
NFS version 4, standardised in RFC 7530 [@rfc7530] and refined in RFC 8881 for the 4.1 minor version [@rfc8881], replaced the optional RPCSEC_GSS security flavour of NFSv3 with a mandatory authentication negotiation step. With `sec=krb5p`, NFS authenticates each user with a Kerberos service ticket and encrypts each RPC payload with the Kerberos session key.
The cipher matrix tracks Kerberos's: RFC 8009 (October 2016) defined enctype 19 (AES-128-CTS-HMAC-SHA-256-128) and enctype 20 (AES-256-CTS-HMAC-SHA-384-192), and `sec=krb5p` on a modern Linux client and server uses enctype 20 by default [@rfc8009]. The cryptographic posture is genuinely comparable to SMB 3.1.1 with AES-256-GCM. The differences are platform (NFS is native to Linux and Unix, SMB is native to Windows) and the way transcript binding is achieved (NFS relies on the underlying GSS context binding rather than a separate hash chain).
NFS-over-QUIC is in IETF draft. The most recent revision of `draft-cel-nfsv4-rpc-over-quicv1`, dated 16 May 2026, is at revision -05 and is not yet on a standards-track timeline [@draft-nfs-rpc-over-quic]. SMB-over-QUIC went generally available in November 2021. NFS is roughly four years behind on this transport.
### WebDAV over HTTPS
WebDAV, defined in RFC 4918 [@rfc4918], is HTTP with the verbs `PROPFIND`, `PROPPATCH`, `MKCOL`, `COPY`, `MOVE`, `LOCK`, and `UNLOCK`. Its security model is "use TLS." The OPTIONS and PROPFIND prologue messages that a WebDAV client exchanges with a server are not transcript-bound at the WebDAV layer. The binding lives entirely in the TLS handshake.
For internet-facing file access that does not need Active Directory integration, WebDAV is a sound choice, and it remains a common SMB alternative for shipping documents to mobile clients. For AD-integrated scenarios, where SMB's Kerberos integration is the point, WebDAV does not compete.
### FTPS and SFTP
FTPS (RFC 4217 [@rfc4217]) adds opt-in TLS to FTP via the `AUTH TLS` command, which is structurally similar to SMTP's STARTTLS or LDAP's StartTLS. The opt-in nature is its weakness; the historical "stripping" attacks against opt-in TLS apply to FTPS just as they applied to opt-in NEGOTIATE bits in SMB.
SFTP runs over SSH-2 (RFC 4253 [@rfc4253]). Because SSH-2 mandatorily encrypts the transport layer, and because the SSH key exchange (§8 of RFC 4253) produces an exchange hash that is signed by the server's host key and binds the entire key-exchange transcript, SFTP gets transcript binding for free from its substrate.
The closest cryptographic posture to SMB 3.1.1's pre-authentication integrity is, structurally, SFTP-over-SSH-2. Both protocols bind the entire negotiation into the session-key derivation. Both make tampering produce key divergence rather than detectable mismatch. SSH took ten years to get there; SMB took twenty-five.
The reason SFTP is a popular SMB alternative in regulatory-burdened environments is precisely that the transport is mandatorily encrypted and the transcript is mandatorily bound. A PCI-DSS auditor who is asked whether a file transfer was protected against in-path tampering can point to RFC 4253 §8 and the SSH exchange-hash signature, and the answer is yes by construction.
### Samba
Samba is the canonical open-source SMB server. The project tracks the Microsoft cipher matrix with a lag that has varied between months and years.
Samba 4.15.0 (September 2021) added the SMB3 signing-algorithm-negotiation parameters and fixed AES-256-GCM/CCM server-side support [@samba-4-15-0]. Samba 4.23.0 (September 2025) added SMB-over-QUIC for both `smbd` and `smbclient`, closing the four-year interop gap with the Microsoft November 2021 SMB-over-QUIC release [@samba-4-23-0]. The Samba team has consistently been the authoritative third-party implementer of the SMB cipher matrix. The gap between Microsoft and Samba is the practical floor on how quickly the SMB world can absorb a new cipher.
### SMB Direct
SMB Direct is not a competitor; it is a parallel transport. Defined in `[MS-SMBD]` and shipped with Windows Server 2012 [@smb-direct], SMB Direct runs SMB over RDMA fabrics (RoCE or iWARP) on the LAN, bypassing the kernel TCP stack for high-throughput, low-latency file workloads.
Encryption with placement was added in Windows Server 2022 [@smb-direct]. SMB Direct does not run over QUIC, because QUIC's user-space encryption is incompatible with RDMA's kernel-bypass placement model. The two transports are deployed for different workloads: SMB Direct on the data centre LAN, SMB-over-QUIC on the wide area.
| Protocol | Transport | Encryption default | Signing default | Authentication | Transcript binding |
|----------|-----------|--------------------|-----------------|----------------|--------------------|
| SMB 3.1.1 over TCP/445 | TCP/445 | Opt-in (Server 2025) | Required by default (24H2) | Kerberos or NTLM | Pre-auth integrity (SHA-512 into SP 800-108 KDF) |
| SMB-over-QUIC | UDP/443 | TLS 1.3 (QUIC) + opt-in SMB AES-GCM | Required by default (24H2 client) | Kerberos or NTLM + TLS 1.3 cert | Pre-auth integrity inside QUIC + TLS 1.3 transcript hash |
| NFSv4.2 `sec=krb5p` | TCP (and QUIC draft) | AES-256-GCM via RFC 8009 | Per-RPC GSS integrity | Kerberos | Kerberos GSS context binding |
| WebDAV over HTTPS | TCP/443 | TLS-mandated | TLS-mandated | HTTP authentication header | TLS 1.3 transcript hash only |
| SFTP over SSH-2 | TCP/22 | Mandatory | Mandatory | SSH user authentication | Exchange-hash signed by host key |
Across the four families, the convergence in 2026 is unmistakable. All paths lead to *authenticated transcript binding plus an AEAD over an established session key.* SMB took twenty-five years to get there. SSH took ten. The two protocols arrived at the same shape from different starting points -- one a file-sharing protocol that picked up TLS-like primitives, the other a remote-shell protocol that always had them.
## 9. Open Problems for 2026 to 2028
Five problems the SMB team is working on now, and at least one nobody has a credible answer to.
**1. When does encryption-required-by-default flip?** The 24H2 client mandate exists, but it is opt-in. Microsoft has not made a public commitment to a default-flip date for `RequireEncryption $true` [@smb-security-hardening].
The stakes are real: passive eavesdropping on an unencrypted SMB session over TCP/445 still recovers the file contents. The deployment-side argument for not flipping yet is the long tail of pre-24H2 clients that cannot negotiate SMB encryption at all. A unilateral server-side flip locks them out. The deployment-side argument for flipping is that signing-required already locks them out of any signed share, and the marginal incompatibility cost is small. The decision is calendar, not cryptography.
**2. NTLM removal interplay.** Microsoft's three-phase NTLM disablement programme is on a multi-year timeline, with the explicit goal of removing the legacy authentication protocol from Windows entirely. The interaction with SMB is structural: an SMB session over Kerberos derives its keys differently than an SMB session over NTLM, and a long tail of NAS appliances and embedded SMB servers still expect NTLM.
The transition pattern is: Kerberos by default, NTLM as a configurable fallback, NTLM disabled for outbound, NTLM removed. The PetitPotam class disappears the moment NTLM is gone. The cross-protocol relay requires the relayed authentication to be NTLM, because Kerberos service tickets are bound to a specific service principal and cannot be relayed to a different service.
**3. Post-quantum key exchange for SMB-over-TCP/445.** SMB-over-QUIC inherits TLS 1.3's [hybrid post-quantum KEM groups](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/) (ML-KEM-based [@nist-fips-203], currently being deployed by major browsers and CDNs). SMB-over-TCP/445 has no protocol-level key-exchange step; it inherits whatever the authentication protocol provides.
Kerberos and NTLM today have no PQC posture. The SMB session key is therefore unprotected against a "harvest now, decrypt later" attacker with a future cryptanalytically relevant quantum computer. The fix is either (a) move long-confidentiality workloads to SMB-over-QUIC to get TLS 1.3's hybrid KEM, or (b) wait for Kerberos to absorb a hybrid PQC enctype.
**4. Cross-protocol relay survival.** PetitPotam-style attacks are not closeable at the SMB layer (see Section 7, limit #5). The structural fix is NTLM removal, which is problem #2 above. In the interim, the deployment-side defence is Extended Protection for Authentication on every NTLM-accepting endpoint -- AD CS Web Enrollment is the canonical one, but the same logic applies to LDAP, WSMan, IIS-hosted enterprise applications, and any internal HTTP service that accepts NTLM [@kb5005413].
**5. Formal analysis of the full SMB 3.1.1 handshake composition.** No published Tamarin or ProVerif model of the full pre-authentication integrity plus SP 800-108 KDF plus Kerberos-or-NTLM composition exists in the academic literature.
Individual analyses of AES-GCM, AES-CMAC, SP 800-108, and SHA-512 are tight at the primitive level. The composition of these primitives in the SMB 3.1.1 handshake is the place where TLS 1.2 historically broke (Lucky 13, Triple Handshake, the renegotiation attack of 2009, the CBC-MAC issues of POODLE). The absence of a published formal model is the single most-cited research gap in the SMB-protocol-security literature.
> **Note:** Problem #5 (formal analysis) is the only one of the five that is a genuine open research problem. Problems #1, #2, and #4 are deployment-posture decisions waiting on calendar dates and platform migration. Problem #3 will look quaint by 2030, when hybrid PQC is everyone's default rather than the SMB team's. Problem #5 is hard in a different way: the composition seam between pre-authentication integrity, the SP 800-108 KDF, and the underlying authentication protocol is exactly the shape that historically produces protocol-composition vulnerabilities, and the SMB community has not yet had its TLS-1.3-formal-analysis moment.
The TLS 1.2 vulnerability history is the standard cautionary tale here. Lucky 13 (2013), POODLE (2014), the Triple Handshake (2014), and the renegotiation attack (2009) all arose at composition seams between primitives that were individually sound. The TLS 1.3 design explicitly tried to remove those seams, and the IETF process required formal models (Tamarin and ProVerif) before the protocol could go to RFC. SMB 3.1.1 has not yet been through that process, and the absence is the strongest argument for funding the work.
None of these five problems undo the 25-year arc that closed in October 2024. Pre-authentication integrity remains structurally sound; the cipher matrix remains at the CNSA 2.0 ceiling; the defaults remain on. The open problems are *what comes next*, not *what is broken*.
## 10. Practical Recipes and Frequently Asked Questions
If you administer Windows estates, run a Samba server, or audit network traffic for a living, here is what changes in 2026.
### A 30-minute audit
> **Note:** A new Windows 11 24H2 client and a new Windows Server 2025 file server arrive with signing required by default. To verify that an existing estate matches the new posture, run on each client `Get-SmbClientConfiguration | Select RequireSecuritySignature, RequireEncryption, BlockNTLM` and on each server `Get-SmbServerConfiguration | Select RequireSecuritySignature, EncryptData, RejectUnencryptedAccess`. Any host where `RequireSecuritySignature` is `False` is at the pre-24H2 posture. Schedule those for either upgrade or a policy push. Pull `Applications and Services Logs\Microsoft\Windows\SmbClient\Audit` to enumerate which third-party peers the estate actually fails to sign with; that audit log is the only practical way to find the long tail of NAS devices and ESXi datastores before they hit a user.
The commands below cover the recipes most administrators reach for first.
- **Verify 24H2 signing defaults**: `Get-SmbClientConfiguration | Select RequireSecuritySignature`; `Get-SmbServerConfiguration | Select RequireSecuritySignature`.
- **Mandate encryption on the client (24H2 or later)**: `Set-SmbClientConfiguration -RequireEncryption $true`.
- **Mandate encryption on a specific share (server)**: `Set-SmbShare -Name MyShare -EncryptData $true`.
- **Block outbound NTLM fallback (24H2 or later)**: `Set-SmbClientConfiguration -BlockNTLM $true`.
- **Deploy SMB-over-QUIC on Server 2025**: install the SMB Server role, bind a TLS 1.3-capable certificate via `New-SmbServerCertificateMapping`, and optionally configure Client Access Control to restrict which principals can connect [@smb-over-quic].
- **Audit which peers refuse to sign**: enable the SmbClient Audit channel and review entries for hosts where signing was negotiated off.
- **Remove SMB1 entirely**: `Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol` [@smb-detect-disable].
- **Block TCP/445 at the network edge**: Microsoft's authoritative recommendation is to block inbound TCP/445 from the public internet at the corporate firewall and to use SMB-over-QUIC for any external file access [@smb-secure-traffic].
- **Audit PetitPotam exposure**: verify Extended Protection for Authentication on AD CS `/certsrv/` per KB 5005413 [@kb5005413], and ensure the AD CS Web Enrollment endpoint is HTTPS-only with channel binding enforced.
On a domain-joined audit workstation that has WinRM open to every member, the following pipeline collects the list of peers that any of those members has talked to over SMB without signing in the last 24 hours: `Invoke-Command -ComputerName (Get-ADComputer -Filter * | Select -Expand DnsHostName) -ScriptBlock { Get-WinEvent -LogName 'Microsoft-Windows-SmbClient/Audit' -MaxEvents 1000 | Where-Object { $_.Id -eq 31010 } } | Sort-Object Message -Unique`. Event ID 31010 is the SmbClient audit signal that the server did not support signing. The output is the deduplicated list of peer hostnames you need a remediation plan for.
### Frequently asked questions
No. SMB signing provides per-packet integrity (AES-CMAC, AES-GMAC, or HMAC-SHA-256 depending on the negotiated algorithm); SMB encryption wraps each packet in an AEAD (AES-CCM or AES-GCM) for confidentiality and integrity. The two are negotiated independently. For 24H2 / Server 2025 default behaviour, see the FAQ entry on the 24H2 default-on push below.
No. SMB signing on the coerced server protects the SMB session that delivers the credentials, but PetitPotam captures and relays those credentials to a different service (AD CS Web Enrollment over HTTPS) -- the defence has to live on the relay-to endpoint as Extended Protection for Authentication, not at the SMB layer [@kb5005413]. See section 6 for the mechanism and section 7 limit 5 for the impossibility framing.
No. SMB-over-QUIC is an additional transport for SMB, primarily intended for clients outside the corporate perimeter that want SMB access without a VPN. Inside the perimeter, TCP/445 remains the default transport on Windows Server 2025 [@smb-over-quic]. SMB Direct over RDMA remains the high-throughput data-centre option [@smb-direct].
No. Secure Negotiate (SMB 3.0.2, 2013) was a post-hoc FSCTL message; pre-authentication integrity (SMB 3.1.1, 2015) is a SHA-512 hash chain that enters the SP 800-108 KDF as salt, causing tampering to produce divergent keys rather than a detected mismatch [@kramer-lovinger-sdc2015][@ms-smb2-pdf]. See section 4 for the mechanism and the five-property comparison table.
AES-128-GCM has no known practical attack at the cipher-level (the GCM forgery bound from RFC 8446 and SP 800-38D applies regardless of key length [@rfc8446][@nist-sp-800-38d]). AES-256-GCM matters because CNSA 2.0 -- the U.S. NSA's algorithm suite for protecting information up to TOP SECRET -- requires a 256-bit symmetric key. Organisations that need CNSA compliance, including most U.S. federal agencies and defence contractors, must negotiate `EncryptionAlgorithmId 0x0004` (AES-256-GCM) [@ms-smb2-versioning].
Probably only on legacy Windows 10 Home or Pro pre-22H2 hosts and a few pre-Server 2019 environments. SMB1 has not been installed by default on Windows 10 since the Fall Creators Update (1709) and not on Windows Server since Server 2019 [@smb-interception-defense]. To check, run `Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol`; the `State` field will be `Disabled` on a modern install. To remove a stray install, use `Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol` [@smb-detect-disable].
No, and this is the single most-misreported fact about the 2024-2025 rollout. The default change was for *signing*, not *encryption*. SMB encryption is now mandate-able from one line of PowerShell or one Group Policy setting, but Microsoft did not flip the default-on switch. A 24H2 client speaking to a Server 2025 file share without explicit opt-in still sends file contents in cleartext on the wire, signed but not encrypted [@smb-security-hardening][@pyle-techcom-4226591].
### Study guide
On March 31, 2001, Sir Dystic walked onto a stage in Atlanta and demonstrated an attack that should have lasted a year. It lasted twenty-three.
The cryptographic primitives that closed it -- AES-CMAC, AES-128-CCM, AES-128-GCM, AES-256-GCM, AES-GMAC, the SP 800-108 KDF, SHA-512 -- arrived between 2006 and 2021. The structural mechanism that bound them into a tamper-resistant SMB session, pre-authentication integrity, arrived in July 2015. The defaults that made all of it universal arrived in October 2024.
The next twenty-five years of SMB security live in the protocols above it: Kerberos, NTLM removal, post-quantum key exchange. Those will be slower, because every protocol seam between SMB and what comes above it is a place where a future Sir Dystic can find new work.