Parag Mali - tag: ntlm-relay

SYSTEM in Ten Seconds: How the Potato Family Survived Every Microsoft Mitigation

noreply@paragmali.com (Parag Mali) — Sun, 31 May 2026 00:00:00 GMT

The Potato family is a decade of Windows local privilege escalation, eleven named variants disclosed between January 2016 (HotPotato) and August 2024 (FakePotato), all pivoting on the same primitive: `SeImpersonatePrivilege` (introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy]) plus `ImpersonateNamedPipeClient` (a Win32 primitive documented as supported since Windows XP for clients and Windows Server 2003 for servers [@ms-impersonate-api]). Each variant -- HotPotato (January 2016), RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, RemotePotato0, JuicyPotatoNG, GodPotato (the 2026 default), LocalPotato (CVE-2023-21746), SilverPotato, FakePotato (CVE-2024-38100) -- defeats a specific Microsoft mitigation, but no mitigation closes the family. The structural reason is the MSRC Windows Security Servicing Criteria, which treats the `SeImpersonatePrivilege`-to-SYSTEM transition as a safety boundary, not a security boundary. The Potato class is therefore an architectural decision, not a bug.

1. A Web Shell, Ten Seconds, SYSTEM

A red teamer drops a web shell on an Internet Information Services server running as IIS APPPOOL\DefaultAppPool. Ten seconds later, the shell prints nt authority\system. The operator did not exploit a memory-corruption bug, did not bypass a kernel security boundary, did not even use an undocumented API. They invoked CoCreateInstance against a Distributed COM (DCOM) class identifier, waited for the SYSTEM-context RPCSS service to authenticate to a named pipe they owned, and called ImpersonateNamedPipeClient [@ms-impersonate-api]. Every step was documented Win32 behaviour. The exploit is that Microsoft has spent a decade refusing to call any of those steps a security boundary [@msrc-servicing-criteria; @troopers24].

The artefact in the operator's hand is one of several. In May 2026 it is most likely GodPotato.exe -cmd "cmd /c whoami" -- a single Apache 2.0-licensed binary that BeichenDream published on GitHub on December 23, 2022 [@beichendream-god]. The README says it works on every supported Windows release from Windows 8 through Windows 11, and from Server 2012 through Server 2022 [@beichendream-god]. Community testing has since extended the working range to Server 2025 with default Distributed COM hardening enabled [@compass-three-headed].

A Windows user-rights assignment that lets a thread substitute another user's security context for its own (typically via `ImpersonateNamedPipeClient` or `ImpersonateLoggedOnUser`). Granted by default to `LOCAL SERVICE`, `NETWORK SERVICE`, every Internet Information Services application-pool identity, and most service accounts [@ms-impersonate-policy]. Introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 service-hardening cycle that MSRC discusses in its 2009 Token Kidnapping retrospective [@msrc-token-kidnapping], after which possessing it has been one named-pipe round-trip away from being SYSTEM.

The IIS context matters. The default application-pool identity holds SeImpersonatePrivilege because IIS depends on it for legitimate request-scoped impersonation [@itm4n-printspoofer]. So does the default SQL Server service account, the Background Intelligent Transfer Service (BITS) account, the Spooler service account, and every account that hosts a Windows service that may need to "act as" a calling user. Anyone who can run code inside one of those accounts can run code as SYSTEM in seconds.

Note: Every step the operator takes -- CoCreateInstance, the SYSTEM-context RPCSS authentication, ImpersonateNamedPipeClient, the subsequent CreateProcessWithToken -- is in Microsoft's published Win32 contract [@ms-impersonate-api; @ms-dcom-spec]. None of them is a memory-corruption bug. The "exploit" is the existence of a documented call sequence that turns a service account into SYSTEM, on a fully-patched Windows 11 box, in 2026.

This is the puzzle the rest of the article is here to solve. The technique has been a one-binary operation for nearly a decade [@troopers24]. Microsoft has shipped three named hardening waves against it (a 2019-2020 OXID-resolver fix [@forshaw-pz-2021]; the three-phase CVE-2021-26414 Distributed COM hardening rollout from June 2021 to March 2023 [@ms-kb5004442]; and per-variant CVE patches in 2023 and 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]). None of those waves closed the family. Why?

2. The Architectural Primitive

The answer is in a Microsoft document called the Windows Security Servicing Criteria [@msrc-servicing-criteria]. It defines what Microsoft will and will not service as a security vulnerability. Quoting the document directly: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-servicing-criteria]. The page then lists the boundaries Microsoft has defined for Windows -- kernel mode versus user mode, virtual machine versus host, session versus session, and so on. The list is the enumeration that decides which bug classes get CVEs and which do not.

The Potato family pivots on a transition that is conspicuously not on the list: a service account that holds SeImpersonatePrivilege becoming SYSTEM. As Andrea Pierini and Antonio Cocomazzi articulated in the Troopers 24 retrospective, Microsoft's published position is that the Windows Service Hardening boundary is a safety boundary rather than a security boundary, which is why so many Potato exploits continue to work on fully updated Windows systems [@troopers24]. WSH is Microsoft's own shorthand for Windows Service Hardening -- the family of post-XP-SP2 protections that isolate service accounts from one another. The position is consistent with everything Microsoft has shipped: per-variant patches when a specific vehicle becomes too embarrassing, and silence on the underlying primitive. (The verbatim Troopers 24 articulation appears in §13.)

The boundary *definition* on `microsoft.com/en-us/msrc/windows-security-servicing-criteria` is rendered in static HTML and can be fetched directly [@msrc-servicing-criteria]. The boundary *enumeration table* immediately below it, which lists the bug classes that do and do not get CVEs, is JavaScript-rendered and does not appear in static fetches. The community-canonical secondary source for what is on that list is the Troopers 24 talk by Pierini and Cocomazzi [@troopers24], cross-referenced against James Forshaw's Project Zero retrospective from October 2021 [@forshaw-pz-2021] and Mark Russinovich's `aka.ms/win-security-boundaries` paraphrase. This article cites the primary for the definition and the Troopers retrospective for the enumeration.

Three primitives, taken together, mechanically determine the entire family. Once they are stated, the only remaining question is which SYSTEM-context service is cheapest to coerce.

Primitive one: SeImpersonatePrivilege

SeImpersonatePrivilege is a Windows user-rights assignment that permits a thread to call ImpersonateNamedPipeClient, ImpersonateLoggedOnUser, and the related impersonation APIs [@ms-impersonate-policy]. By Windows default, it is granted to LOCAL SERVICE, NETWORK SERVICE, every Internet Information Services application-pool identity, and most service accounts that need to act on behalf of clients [@itm4n-printspoofer]. (For when the right was introduced and a working definition, see §1; Decoder's one-sentence summary of what the grant means in practice is the climactic PullQuote in §6.3.)

Primitive two: ImpersonateNamedPipeClient

A Win32 API that lets the server end of a named pipe adopt the security context of whoever just connected to that pipe. After the call, the calling thread holds an impersonation token for the client identity, and any subsequent system call (including `CreateProcessWithToken`) executes as that identity. The function has been part of `namedpipeapi.h` since Windows XP for clients and Windows Server 2003 for servers, with no deprecation notice as of the 2025-07-01 documentation revision [@ms-impersonate-api].

The mechanism is exactly the one a SYSTEM-context service uses for legitimate request-scoped impersonation. The Potato class subverts it by getting a SYSTEM-context service to connect to a pipe the attacker owns. No memory corruption, no kernel exploit, no undocumented API. The Win32 reference describes the call as the standard way for a pipe server to "impersonate the client end" [@ms-impersonate-api].

Primitive three: the MSRC servicing-criteria carve-out

The third primitive is policy, not code. The MSRC document distinguishes a security boundary (whose violation gets a CVE and a security update) from a safety boundary (where Microsoft will patch when convenient but does not commit to a service-level objective). The defensible reading, articulated explicitly by Pierini and Cocomazzi at Troopers 24, is that the SYSTEM-from-SeImpersonate transition lives on the safety side [@troopers24]. The implication is structural: a service account holding SeImpersonatePrivilege "is already privileged" in Microsoft's policy view. Promoting it to SYSTEM is therefore not a privilege escalation that requires a security update.

flowchart LR A[Service account with SeImpersonatePrivilege] --> B[Coerce SYSTEM-context service to connect to attacker-owned named pipe] B --> C[Call ImpersonateNamedPipeClient on server thread] C --> D[Thread now holds SYSTEM impersonation token] D --> E[CreateProcessWithToken spawns SYSTEM process] F[MSRC servicing criteria carve-out] -.->|"Allows step A to remain a default grant"| A F -.->|"Allows step C to remain a documented Win32 API"| C

Taken together, the three primitives reduce the entire Potato family to a single problem statement: find the cheapest SYSTEM-context service to coerce into a callback. Every named variant since 2016 is an answer to that problem.

Key idea: Microsoft does not consider the SeImpersonatePrivilege-to-SYSTEM transition a security boundary; it considers it a safety boundary. The Potato family is the consequence. Variants change vehicles -- NetBIOS spoofing, BITS DCOM, Print Spooler RPC, EFS RPC, RPCSS OXID, ShellWindows -- but every one of them lives on the same architectural carve-out [@troopers24; @msrc-servicing-criteria].

The phrase aka.ms/win-security-boundaries was popularised by Mark Russinovich's Channel 9 talks of the late 2010s. Channel 9 was retired on December 1, 2021, so the link is now mostly cited as a memorable handle for the boundary list rather than as a clickable URL. The live equivalent is the MSRC servicing criteria document itself [@msrc-servicing-criteria].

Given primitives this old and this widely default-granted -- both the named-pipe impersonation API and the SeImpersonatePrivilege user right have been in their current form since the Windows 2000 SP4 / Server 2003 / XP SP2 service-hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy; @ms-impersonate-api] -- the natural question is why the named Potato family did not appear until 2016. The next section is the answer.

3. The Long Pre-Potato Era, 2001-2015

In March 2008, Cesar Cerrudo stood on a stage in Dubai at Hack-in-the-Box and demonstrated that a SYSTEM-context Windows service holding SeImpersonatePrivilege was, in effect, one named-pipe call away from SYSTEM [@cerrudo-hitb-slides; @msrc-token-kidnapping]. Microsoft acknowledged the technique on the MSRC blog on April 14, 2009, and shipped MS09-012 -- the patch Cerrudo later nicknamed "Chimichurri" in his Black Hat USA 2010 follow-up [@msrc-token-kidnapping; @blackhat-2010-cerrudo]. Cerrudo extended the work two years later at Black Hat USA 2010 in a paper titled "Token Kidnapping's Revenge" [@blackhat-2010-cerrudo]. Microsoft patched the specific NetworkService-to-SYSTEM vehicle. They did not revoke the privilege from the service accounts that held it [@msrc-token-kidnapping].

That pattern -- patch the vehicle, leave the primitive -- is the family's bequest from Cerrudo.

NTLM **relay** forwards an NTLM authentication captured from victim A to a different server B, where the attacker authenticates as A. NTLM **reflection** is the special case where B is the same machine (often the same protocol) as A. Microsoft fixed the most obvious same-protocol case with MS08-068 in 2008 [@ms-ms08-068]. Cross-protocol reflection (HTTP-to-SMB, DCOM-to-RPC) was not closed by that patch and became the doorway through which the Potato family entered.

Seven years before Cerrudo, on March 31, 2001, Sir Dystic of the Cult of the Dead Cow stood on a different stage at @lanta.con in Atlanta and released SMBRelay, the first public same-protocol NTLM relay tool [@cultdeadcow-smbrelay]. Microsoft eventually responded with MS08-068, a same-protocol-only fix [@ms-ms08-068]. Cross-protocol relay -- HTTP to SMB, DCOM to local RPC -- remained open.

That opening was the canvas James Forshaw painted on. In December 2014, then at Google Project Zero, Forshaw filed Issue 222 ("Windows: Local WebDAV NTLM Reflection EoP") demonstrating that the WebClient service performs NTLM authentication when asked to open a WebDAV URL, and that the resulting NTLM session can be reflected cross-protocol to the local SMB service [@forshaw-pz-2021]. A few months later Forshaw filed Issue 325, showing that CoGetInstanceFromIStorage could coerce a DCOM activation into authenticating to an attacker-controlled TCP endpoint. Microsoft patched the 2015 issue as CVE-2015-2370 [@nvd-cve-2015-2370]. In his October 2021 retrospective Forshaw wrote, with the laconic precision of a researcher whose contributions are still being weaponised seven years later:

The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits. -- James Forshaw, Project Zero, October 2021 [@forshaw-pz-2021]

Cerrudo nicknamed the MS09-012 patch "Chimichurri" after the Argentine green sauce, and used the name when he reprised the work at Black Hat USA 2010 [@blackhat-2010-cerrudo]. Cerrudo was at Argeniss and later IOActive when he developed the technique [@msrc-token-kidnapping; @blackhat-2010-cerrudo].

The primary artefact for Cerrudo's March 2008 Hack-in-the-Box Dubai talk (slides, video, abstract) is no longer reachable on the conference site; the MSRC blog's retrospective is the canonical secondary that anchors the date and venue [@msrc-token-kidnapping]. The Black Hat USA 2010 "Token Kidnapping's Revenge" whitepaper [@blackhat-2010-cerrudo] is the durable primary for the underlying technique.

gantt title Pre-Potato lineage 2001-2015 dateFormat YYYY-MM section NTLM relay SMBRelay (Sir Dystic) :a1, 2001-03, 1M MS08-068 same-protocol fix :a2, 2008-10, 1M section Token escalation Token Kidnapping HITB Dubai (Cerrudo) :b1, 2008-03, 1M MS09-012 Chimichurri :b2, 2009-04, 1M Token Kidnapping's Revenge (Cerrudo) :b3, 2010-07, 1M section DCOM primitive Project Zero Issue 222 (Forshaw) :c1, 2014-12, 1M Project Zero Issue 325 (Forshaw) :c2, 2015-04, 1M CVE-2015-2370 patch :c3, 2015-07, 1M

By the end of 2015 the three pieces were on the table. A long-standing default privilege grant (Cerrudo's "SeImpersonate equals SYSTEM" thesis). A specific cross-protocol reflection technique (Forshaw's WebDAV-to-SMB Issue 222). A specific DCOM-activation coercion primitive (Forshaw's CoGetInstanceFromIStorage Issue 325). Microsoft had patched the literal bug in the third piece and explicitly declined to revoke the privilege in the first. The technique was published, the proof-of-concept code was on GitHub, and the family was a binary release away. The next chapter is the moment someone shipped the binary.

4. HotPotato, January 16, 2016

On January 16, 2016, Stephen Breen of Foxglove Security published a blog post titled "Hot Potato" [@foxglove-hotpotato]. He had just spoken at ShmooCon. The repository, foxglovesec/Potato, would land on GitHub three weeks later, on February 9, 2016 [@foxglove-potato-repo]. The post's opening sentence is the family's birth certificate:

Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing. -- Stephen Breen, Foxglove Security, January 16, 2016 [@foxglove-hotpotato]

Breen had not invented NTLM reflection. He had combined three existing primitives into a single-binary, one-click privilege escalation that worked on every default Windows install from Windows 7 through Server 2012 [@foxglove-hotpotato]. The Foxglove post acknowledges the lineage explicitly: "a similar technique was disclosed by the guys at Google Project Zero ... In fact, some of our code was shamelessly borrowed from their PoC" [@foxglove-hotpotato].

How HotPotato works

The exploit chains three independent tricks. Step one is UDP-port exhaustion. The tool opens enough UDP sockets that the local NetBIOS Name Service (NBNS) name lookups fail, forcing Windows to fall back to broadcast-based name resolution [@foxglove-hotpotato]. Step two is NBNS spoofing of the WPAD hostname, pointed at 127.0.0.1. Step three is the actual reflection: when Windows Update or Windows Defender polls for an update, it consults the WPAD URL, gets the attacker's proxy auto-configuration script, and routes its HTTP requests through the attacker's local listener -- which then relays the SYSTEM-context NTLM negotiation to the local SMB service [@foxglove-hotpotato].

sequenceDiagram participant Atk as Hot Potato tool participant NBNS as NetBIOS Name Service participant WU as Windows Update (SYSTEM) participant WPAD as WPAD HTTP listener (attacker) participant SMB as Local SMB service Atk->>NBNS: UDP-flood to exhaust ports and force broadcast Atk->>NBNS: Spoof WPAD hostname pointing at 127.0.0.1 WU->>WPAD: GET wpad.dat over HTTP WPAD-->>WU: Attacker-supplied proxy auto-config WU->>WPAD: HTTP request with SYSTEM-context NTLM negotiate WPAD->>SMB: Reflect the NTLM exchange to local SMB SMB-->>Atk: SMB session authenticated as SYSTEM Atk->>Atk: ImpersonateNamedPipeClient and spawn SYSTEM shell

The result was a single binary that produced a SYSTEM shell from any local user account on the target host -- because on a default Windows install every authenticated local user can run code, open UDP sockets, and bind a loopback HTTP listener, which is all HotPotato needs to bootstrap.

Note: HotPotato does not use Distributed COM activation at all. It uses NetBIOS spoofing, WPAD hijacking, and HTTP-to-SMB cross-protocol relay. The family is named for HotPotato but the defining primitive of every later variant -- DCOM activation -- is absent. HotPotato is in the family because it pivots through the same SeImpersonatePrivilege plus named-pipe-impersonation core, which is the actual definition of the family. The repository name Potato and the family naming convention are both Breen's [@foxglove-potato-repo].

The naming pattern that has now produced eleven variants started with the GitHub repository name foxglovesec/Potato [@foxglove-potato-repo]. Breen later wrote that "Hot" was a riff on the fact that the SYSTEM token was passed around like a hot potato; the suffix convention spread from there organically.

Why HotPotato did not last

HotPotato had three structural weaknesses. NetBIOS spoofing is unreliable: the UDP-port exhaustion can fail under load, group policy can pin a real WPAD URL, and a legitimate WPAD response can win the race. NetBIOS is disabled in security-hardened environments as a matter of routine. And the HTTP-to-SMB cross-protocol path was the very thing Extended Protection for Authentication and SMB channel-binding tokens were designed to close [@crowdstrike-drop-mic]. On a Windows 10 1607 host with EPA on the SMB server, HotPotato failed.

Researchers needed a coercion vehicle that was deterministic, did not rely on broadcast spoofing, and used a protocol Microsoft had not yet hardened end-to-end. Forshaw's Project Zero Issue 325 -- the CoGetInstanceFromIStorage DCOM trigger -- met all three criteria [@forshaw-pz-2021]. The next variant weaponised it.

5. The DCOM-Activation Breakthrough, 2016-2018

5.1 RottenPotato (DerbyCon 6, September 2016)

Eight months after HotPotato, Stephen Breen returned with a co-author and a new vehicle. The talk was on September 23, 2016 -- the Friday of DerbyCon 6 -- and the blog post followed three days later [@foxglove-rottenpotato]. The Foxglove post identifies the co-author by name: "myself and my partner in crime, Chris Mallz (@vvalien1) spoke at DerbyCon about a project we've been working on for the last few months" [@foxglove-rottenpotato].

Many secondary sources credit Andrea Pierini (Decoder) as the RottenPotato co-author. The Foxglove primary disproves this verbatim [@foxglove-rottenpotato]. Decoder enters the family lineage two years later, with JuicyPotato in 2018 [@ohpe-juicy]. Chris Mallz is the actual RottenPotato co-author.

RottenPotato replaced HotPotato's NetBIOS-and-WPAD chain with Forshaw's DCOM-activation primitive. The hard-coded target was the Background Intelligent Transfer Service (BITS) Distributed COM server, class identifier {4991d34b-80a1-4291-83b6-3328366b9097}, and the hard-coded listener port was 127.0.0.1:6666 [@foxglove-rottenpotato; @foxglove-rotten-repo].

A Win32 OLE function that instantiates a Distributed COM object using a marshalled `IStorage` interface pointer as the activation source. By marshalling an `IStorage` whose object exporter identifier (OXID) resolves to an attacker-controlled TCP endpoint, the activator can redirect the resulting authentication callback to a listener it owns. Forshaw filed this as Project Zero Issue 325 in 2015 [@forshaw-pz-2021]; RottenPotato weaponised it. sequenceDiagram participant Atk as RottenPotato (service account) participant Pipe as Local listener on 127.0.0.1:6666 participant DCOM as DCOM activation (RPCSS) participant BITS as BITS COM server (SYSTEM) participant RPC as Local RPC on port 135 Atk->>Pipe: Start TCP listener on 127.0.0.1:6666 Atk->>DCOM: CoGetInstanceFromIStorage with BITS CLSID and marshalled IStorage DCOM->>BITS: Spawn BITS under SYSTEM context BITS->>Pipe: Callback to the marshalled endpoint Pipe->>RPC: Forward COM packets to local RPC on port 135 RPC-->>Pipe: Reply containing SYSTEM-context NTLM exchange Pipe-->>Atk: SYSTEM authentication captured Atk->>Atk: ImpersonateNamedPipeClient and CreateProcessWithToken

The technique was 100% reliable on Windows 7 through Windows 10 1803 and Server 2008 R2 through Server 2016 [@foxglove-rottenpotato]. There was no broadcast spoofing on the wire, no race condition, and no dependence on Windows Update polling. The price was rigidity: the hard-coded BITS class identifier and port 6666 made the tool brittle to BITS being disabled, and the original release depended on the Metasploit framework.

5.2 RottenPotatoNG and lonelypotato

In December 2017, the user breenmachine published RottenPotatoNG, a C++ port that removed the Metasploit dependency: "New version of RottenPotato as a C++ DLL and standalone C++ binary - no need for meterpreter or other tools" [@breenmachine-rottenng]. The codebase that JuicyPotato would later generalise was now in place.

Many surveys date the `decoder-it/lonelypotato` variant to "early 2018" and place it as the link between RottenPotatoNG and JuicyPotato. The GitHub REST API reports `created_at: 2020-02-08T16:30:00Z` for the repository [@decoder-lonely], a full two years later. Decoder's first appearance in the Potato lineage is actually the December 6, 2019 post "We thought they were Potatoes but they were Beans" [@decoder-beans], with `lonelypotato` arriving in February 2020 as a post-OXID-hardening cleanup variant adjacent to RoguePotato [@decoder-lonely]. The 2017-2018 attribution is a citation error that has propagated across several survey papers.

5.3 JuicyPotato (Pierini + Trotta, July-August 2018)

What if any class identifier, not just the BITS one, could be the activation target? On July 27, 2018, Andrea Pierini and Giuseppe Trotta published the answer. The repository ohpe/juicy-potato was created that day per the GitHub REST API; the blog post followed on August 10, 2018 [@ohpe-juicy]. The repository description reads: "Juicy Potato (abusing the golden privileges) -- A sugared version of RottenPotatoNG, with a bit of juice" [@ohpe-juicy].

The original JuicyPotato blog post at decoder.cloud/2018/08/10/juicy-potato-abusing-the-golden-privileges/ returns HTTP 404 in 2026, and no Wayback Machine snapshot exists for that exact URL. The ohpe/juicy-potato README is the live verbatim mirror of the title and the technique walkthrough [@ohpe-juicy]. Pierini's blog has reorganised several times; older posts that survive elsewhere on decoder.cloud include the October 2018 "No more Rotten/Juicy Potato" [@decoder-no-more-rotten] and the December 2019 "We thought they were Potatoes" [@decoder-beans].

JuicyPotato turned RottenPotato into a search engine. The README ships a per-Windows-version class identifier matrix: each row a Windows release, each column a CLSID that activates under SYSTEM context and implements the IMarshal interface [@ohpe-juicy]. The tool accepts a tunable listener port (replacing the hard-coded 6666), a tunable process-creation mode (CreateProcessWithToken for SeImpersonate holders, CreateProcessAsUser for SeAssignPrimaryToken holders, or both), and a TEST mode for class-identifier discovery [@ohpe-juicy].

Microsoft does not freeze the set of registered Distributed COM class identifiers across Windows builds. Default COM-server registrations change between releases as components are added, removed, or refactored. A class identifier that activates under SYSTEM on Windows 10 1709 may not exist on Server 2019. JuicyPotato's CLSID matrix is therefore not a static lookup table -- it is the precomputed result of an empirical per-build search [@ohpe-juicy]. Every red-team handbook published between 2018 and 2020 references this matrix; subsequent variants (RoguePotato, JuicyPotatoNG) inherit and update it. flowchart TD A[Enumerate registered DCOM CLSIDs on target build] --> B{"For each CLSID"} B --> C[Attempt CoGetInstanceFromIStorage with marshalled IStorage] C --> D{"Activation reaches attacker listener?"} D -->|No| B D -->|Yes| E{"Callback authenticates as SYSTEM?"} E -->|No| B E -->|Yes| F[Log CLSID into per-OS matrix] F --> B B --> G[Output: working CLSID for this Windows build]

The Potato class was now universal. From mid-2018 through 2019 it was the default tool in every red-team handbook, every Metasploit-adjacent post-exploitation cheat-sheet, and every penetration-testing certification's lab. Microsoft had noticed.

6. The Mitigation Arms Race, 2020-2024

Every subsection below is the same shape: Microsoft ships a mitigation, researchers find a counter-move, MSRC produces an artifact (a CVE, a "Won't Fix" decision, or silence), and the architectural reading gets one more empirical confirmation.

6.1 The first Distributed COM mitigation, 2019-2020

In late 2018, Windows 10 1809 and Server 2019 began shipping a change to RPCSS. JuicyPotato stopped working. Researchers who reverse-engineered the change discovered that the OXID resolver address on the local Distributed COM activation path was now hard-coded to 127.0.0.1:135. The marshalled IStorage callback could no longer be redirected to an arbitrary loopback port. Forshaw described it bluntly three years later:

Being able to redirect the OXID resolver RPC connection locally to a different TCP port was not by design and Microsoft eventually fixed this in Windows 10 1809/Server 2019. -- James Forshaw, October 2021 [@forshaw-pz-2021]

No CVE was assigned. The change shipped silently as part of the regular Patch Tuesday cycle [@forshaw-pz-2021]. Pierini and Cocomazzi tested it on their own workloads and confirmed the failure mode publicly in October 2018: "Recently I downloaded the new Windows server 2019 and upgraded my Win10 box to 1809 ... the juicy/rotten exploit ... did not work on both OS" [@decoder-no-more-rotten].

Note: The 2019-2020 OXID-resolver change is the first Microsoft response to the Potato family. It does not declare Distributed COM activation a security boundary. It narrows the resolver port to 135 and leaves the underlying primitive (coerce SYSTEM context via OXID resolver, then impersonate the resulting token) intact. The mitigation defines exactly one specific bypass; researchers had to discover that themselves [@forshaw-pz-2021; @decoder-no-more-rotten].

6.2 RoguePotato (Cocomazzi + Pierini, May 2020)

On May 10, 2020, Antonio Cocomazzi published the RoguePotato repository on GitHub [@antonio-rogue]. The disclosure post appeared the next day, May 11. The README banner is "RoguePotato @splinter_code & @decoder_it" -- the same Pierini-and-Cocomazzi team that goes on to author RemotePotato0, JuicyPotatoNG, LocalPotato, and SilverPotato [@antonio-rogue].

The counter-move accepts the hard-coded port-135 constraint and works around it. RoguePotato is two pieces. On an attacker-controlled remote host, run a port forwarder that listens on TCP 135 and redirects to a chosen attacker port. On the target, run RoguePotato.exe pointing the OXID resolver at the remote forwarder. RPCSS dutifully sends the resolution request to the remote host on port 135 (since Microsoft hard-coded the port, not the host); the forwarder bounces the traffic back to the target on the attacker-chosen port; RoguePotato impersonates the OXID resolver and steers the activation back to a SYSTEM-context COM server [@antonio-rogue]. Standard NTLM relay and named-pipe impersonation finish the job.

flowchart LR A[RoguePotato.exe on target] --> B[RPCSS sends OXID resolution to remote-host port 135] B --> C[Remote port forwarder on attacker VPS] C --> D[Forward to target on attacker-chosen port] D --> E[Fake OXID resolver inside RoguePotato] E --> F[Steer activation to SYSTEM-context COM server] F --> G[Named-pipe impersonation, CreateProcessWithToken, SYSTEM shell]

{// Step 1 -- on an attacker-controlled remote host (any internet-reachable VPS): const forwarder = "socat tcp-listen:135,reuseaddr,fork tcp:10.0.0.3:9999"; // Step 2 -- on the target with SeImpersonatePrivilege: const exploit = 'RoguePotato.exe -r 10.0.0.3 -e "C:\\\\windows\\\\system32\\\\cmd.exe" -l 9999'; console.log("Remote forwarder:", forwarder); console.log("Target exploit :", exploit); console.log("Expected output : nt authority\\\\system");}

RoguePotato proved that the mitigation Microsoft chose did not break the underlying primitive. It only forced the attack to phone home. Two failure modes followed: in egress-filtered networks where outbound TCP 135 is blocked, the technique cannot run, and the remote forwarder is operationally noisy. Researchers needed a workaround that lived entirely on the target.

6.3 PrintSpoofer (Clément Labro, early May 2020)

Around the same time as RoguePotato, in early May 2020 (GitHub repository itm4n/PrintSpoofer created April 28, 2020; blog post first archived in the Wayback Machine on May 3, 2020), Clément Labro -- writing as itm4n -- published "PrintSpoofer -- Abusing Impersonation Privileges on Windows 10 and Server 2019" [@itm4n-printspoofer]. The mechanism uses no Distributed COM at all.

The Print Spooler service exposes an RPC call, RpcRemoteFindFirstPrinterChangeNotificationEx, that accepts a UNC path; the Spooler -- running as SYSTEM -- connects to that path to deliver printer-change notifications. Point the path at an attacker-owned named pipe; the Spooler connects; call ImpersonateNamedPipeClient; done [@itm4n-printspoofer]. Labro articulated the family's thesis statement in the post, attributing it to Decoder:

If you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- attributed to Andrea Pierini (@decoder_it), quoted by Clément Labro in the PrintSpoofer writeup, May 2020 [@itm4n-printspoofer] sequenceDiagram participant Atk as PrintSpoofer (SeImpersonate holder) participant Pipe as Attacker-owned named pipe participant Spooler as Print Spooler (SYSTEM) Atk->>Pipe: Create named pipe and start accept loop Atk->>Spooler: RpcRemoteFindFirstPrinterChangeNotificationEx with attacker UNC Spooler->>Pipe: Connect to UNC path under SYSTEM context Pipe->>Atk: ImpersonateNamedPipeClient on server thread Atk->>Atk: CreateProcessWithToken spawns SYSTEM shell

This is the moment the architectural reading clicks. The family is not about Distributed COM activation. Closing DCOM would not close the family. The next variant would use Spooler RPC, the one after that would use the Encrypting File System RPC, and the one after that would use Microsoft Distributed Transaction Coordinator RPC. Forshaw's contemporaneous April 2020 tiraniddo.dev post on shared logon sessions makes the same architectural point from a different angle [@forshaw-tiraniddo-2020].

Key idea: The Potato family is about the primitive, not the vehicle. SeImpersonatePrivilege plus ImpersonateNamedPipeClient plus any SYSTEM-context Windows service with a callback-style API equals SYSTEM. Closing one vehicle (Distributed COM activation) leaves every other vehicle (Spooler RPC, EFS RPC, the next service that gets a callback interface) wide open [@itm4n-printspoofer; @forshaw-tiraniddo-2020].

6.4 RemotePotato0 and the "Won't Fix"

In April 2021, Cocomazzi and Pierini pushed the technique across the network in a SentinelLabs post titled "Relaying Potatoes: DCE/RPC NTLM Relay EoP" [@sentinellabs-relaying]. The repository tagline names the outcome bluntly: "Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin" [@antonio-remote].

The mechanism is cross-session NTLM relay over Distributed COM and RPC. An unprivileged local user triggers the Distributed COM activation service to make another user logged on the same machine (typically an administrator in an interactive RDP session) authenticate via NTLM. The captured NTLM exchange is then cross-protocol relayed (RPC to LDAP, with a port forwarder bridging the gap) to a domain controller with LDAP signing disabled. The attacker writes their own account into a privileged group or registers resource-based constrained delegation, and the engagement is over [@sentinellabs-relaying].

Microsoft's response is the most quoted sentence in the family's history:

The current status of this vulnerability is 'won't fix' ... Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as 'Won't Fix'. -- SentinelLabs disclosure of RemotePotato0, April 2021 [@sentinellabs-relaying]

Note: RemotePotato0 was a fully working exploit chain that promoted any local low-privilege user to Domain Admin. Microsoft was given the disclosure, replicated the technique, and declined to issue a CVE. This is the moment the architectural reading stops being a researcher narrative and becomes a documented MSRC decision [@sentinellabs-relaying]. Microsoft eventually shipped a partial mitigation in October 2022 that broke the RPC-to-LDAP scenario specifically, but the underlying primitive survives in adjacent variants [@antonio-remote].

6.5 The CVE-2021-26414 Distributed COM hardening rollout

Two months after the RemotePotato0 disclosure, Microsoft began the only DCOM-side hardening it would ship under a CVE. KB5004442 documents a three-phase rollout, quoted verbatim from the article: "The first phase of DCOM updates was released on June 8, 2021. In that update, DCOM hardening was disabled by default. ... The second phase of DCOM updates was released on June 14, 2022. ... The final phase of DCOM updates will be released in March 2023. It will keep the DCOM hardening enabled and remove the ability to disable it" [@ms-kb5004442].

Phase	Date	Behaviour
Phase 1	June 8, 2021	DCOM hardening shipped, disabled by default. Administrators may opt in via registry.
Phase 2	June 14, 2022	Hardening enabled by default. Registry opt-out still available.
Phase 3	March 14, 2023	Hardening enforced with no opt-out. The `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` minimum is mandatory.

The RPC authentication-level constant that requires every packet of an RPC exchange to be signed for integrity (level 5 of 6). CVE-2021-26414 raises the *minimum* DCOM activation authentication level to this constant, rejecting legacy Distributed COM clients that activate at lower levels. The full rejection appears in Windows Event ID 10036 as "The server-side authentication level policy does not allow the user %1\\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application" [@ms-kb5004442].

The hardening raised the bar for legacy Distributed COM client authentication. It did not declare Distributed COM activation a security boundary [@ms-kb5004442; @ms-techcommunity-dcom]. The "Manage changes" framing in the KB title is deliberate: this is a compatibility migration with telemetry events (10036 server-side, 10037 and 10038 client-side) so enterprises can find legacy clients before the final cut [@ms-kb5004442].

Note: Distributed COM is everywhere in Windows. Removing the ability to activate at a lower authentication level breaks legacy Distributed COM applications that have not been updated since at least 2014. Microsoft's 21-month rollout window between Phase 1 (June 2021) and Phase 3 (March 2023) was a compatibility migration -- the telemetry events let enterprise IT find and fix the legacy clients before the final cut [@ms-kb5004442; @ms-techcommunity-dcom]. The hardening is the most aggressive Distributed COM mitigation Microsoft has ever shipped, and even so it does not declare Distributed COM activation a security boundary.

Researchers had 21 months to find a way around it. They took 18.

6.6 JuicyPotatoNG (Pierini + Cocomazzi, September 21, 2022)

Pierini and Cocomazzi returned on September 21, 2022, with JuicyPotatoNG -- the last pre-Phase-3 Distributed COM activation variant [@decoder-juicyng]. The blog post is titled "Giving JuicyPotato a second chance: JuicyPotatoNG" and walks through three counter-moves combined into a single binary [@decoder-juicyng; @antonio-juicyng].

First, the tool embeds Forshaw's October 2021 local-OXID trick. Forshaw had shown that an OXID resolution request could be answered by a local Distributed COM server on a randomly selected port, dropping the need for an external forwarder [@forshaw-pz-2021]. JuicyPotatoNG ships that trick as a default. Second, it falls back to a tight set of usable class identifiers; the default is {854A20FB-2D44-457D-992F-EF13785D2B51}, the PrintNotify class [@antonio-juicyng]. Third, it calls LogonUser with LOGON32_LOGON_NEW_CREDENTIALS to sidestep the INTERACTIVE-group restriction that constrained earlier post-RoguePotato attempts [@decoder-juicyng].

The cross-pollination is worth marking. Forshaw's October 2021 Project Zero post on relaying Distributed COM authentication described the local-OXID trick as a research result [@forshaw-pz-2021]. Pierini and Cocomazzi picked it up eleven months later and shipped it as the default mode of JuicyPotatoNG [@decoder-juicyng]. SilverPotato (April 2024) and the Compass Security follow-on (September 2024) cite the same trick [@compass-three-headed]. Forshaw's blog has been the unofficial reference implementation for the lineage's offensive primitives for half its lifetime.

JuicyPotatoNG also implements a Security Support Provider Interface (SSPI) hook on AcceptSecurityContext to capture the SYSTEM token without requiring RpcImpersonateClient. The effect is to make the tool work for both SeImpersonate and SeAssignPrimaryToken holders [@decoder-juicyng]. The result is a clean, single-binary, no-external-infrastructure local-DCOM-activation exploit -- which is the version that worked between Phase 2 (June 14, 2022, enabled by default) and Phase 3 (March 14, 2023, enforced with no opt-out) of the CVE-2021-26414 rollout [@ms-kb5004442].

The next variant would need to survive Phase 3.

6.7 GodPotato (BeichenDream, December 23, 2022)

Three months after JuicyPotatoNG, on December 23, 2022, the Chinese-speaking researcher BeichenDream published GodPotato to GitHub [@beichendream-god]. The README is bilingual English and Chinese, and it opens with a precise summary of where the variant fits in the lineage:

Based on the history of Potato privilege escalation for 6 years, from the beginning of RottenPotato to the end of JuicyPotatoNG, I discovered a new technology by researching DCOM, which enables privilege escalation in Windows 2012 - Windows 2022 ... There are some defects in rpcss when dealing with oxid, and rpcss is a service that must be opened by the system, so it can run on almost any Windows OS, I named it GodPotato. -- BeichenDream, GodPotato README, December 2022 [@beichendream-god]

The mechanism manipulates the OXID-handling flow inside RPCSS so the activated Distributed COM server's authentication callback returns to a tool-controlled endpoint without requiring the OXID resolver to be redirected. Because the redirect itself is what the CVE-2021-26414 hardening rejects, GodPotato sidesteps the hardening entirely [@beichendream-god]. RPCSS is a mandatory Windows service -- it cannot be disabled without breaking the operating system -- so the technique works on every supported Windows release as of disclosure.

{// On a target host where the calling account holds SeImpersonatePrivilege // (default for every IIS app-pool identity, MSSQL service account, BITS account, etc.) const command = 'GodPotato -cmd "cmd /c whoami"'; console.log("Run:", command); console.log("Expected output: nt authority\\\\system"); console.log("Working OS coverage: Windows 8 through Windows 11; Server 2012 through Server 2025"); console.log("Underlying primitive: RPCSS OXID-handling defect, no external infra, single binary");}

Microsoft has not assigned a CVE to the underlying RPCSS defect [@beichendream-god; @compass-three-headed].Apache 2.0 licensing matters here: red-team operators routinely recompile GodPotato from source to bypass binary-hash signatures, and the permissive license makes redistribution unproblematic [@beichendream-god]. The pattern is consistent with the servicing-criteria reading. GodPotato is in May 2026 the practitioner default on every in-support Windows release: single binary, no external infrastructure, no separate OXID resolver, Apache-2.0-licensed and freely re-buildable when EDR vendors signature the public binary [@beichendream-god].

Key idea: GodPotato survives every Microsoft mitigation because Microsoft has not declared the underlying primitive a security boundary. Three named hardening waves (the 2019-2020 OXID-resolver change, the three-phase CVE-2021-26414 rollout from June 2021 to March 2023, and the per-variant CVE patches in 2023 and 2024) leave GodPotato working on Server 2025 and Windows 11 24H2 as of this writing [@beichendream-god; @ms-kb5004442; @compass-three-headed].

6.8 LocalPotato and CVE-2023-21746

Three weeks after GodPotato landed, Microsoft assigned the first-ever CVE in the local Potato lineage. The variant was LocalPotato, the CVE was CVE-2023-21746, and the patch shipped in the January 2023 Patch Tuesday [@nvd-cve-2023-21746; @msrc-cve-2023-21746]. The Decoder writeup, published February 13, 2023, walks through the timeline:

"We reported our findings to the Microsoft Security Response Center (MSRC) on September 9, 2022, and it was resolved with the release of the January 2023 patch Tuesday and assigned the CVE number CVE-2023-21746." -- Andrea Pierini, "LocalPotato" writeup, February 2023 [@decoder-localpotato]

LocalPotato is not a Distributed COM activation Potato. It attacks the local NTLM authentication protocol itself. During a local NTLM exchange, the Type 2 (Challenge) message carries a "Reserved" field that, in the local-NTLM case, encodes the upper bytes of the local server context handle the client should associate with. By racing two simultaneous local NTLM authentications -- one privileged client to attacker server, one attacker client to a real local server -- and swapping the Reserved fields in the two Type 2 messages, LSASS binds the privileged identity to the attacker's low-privilege context [@decoder-localpotato; @localpotato-com]. The result is an arbitrary file-read and file-write primitive that chains cleanly to SYSTEM.

Note: Pierini and Cocomazzi had been pushing on the architectural carve-out for seven years before they got a CVE. The boundary that made the difference: LocalPotato attacks the local user-to-local-user NTLM authentication context, which is on the servicing-criteria boundary list. The underlying SeImpersonate-to-SYSTEM primitive is not. Microsoft will service the parts of the protocol that are inside the boundary; it will not service the parts that are outside [@decoder-localpotato; @msrc-servicing-criteria].

The LocalPotato writeup credits Elad Shamir for the original hint that started the research [@decoder-localpotato]. The dedicated companion site localpotato.com carries the canonical title "LocalPotato -- When swapping the context leads you to SYSTEM" and links the CVE [@localpotato-com].

6.9 SilverPotato (Pierini + Cocomazzi, April 24, 2024)

A year later, on April 24, 2024, Pierini and Cocomazzi extended the cross-session Distributed COM activation primitive that RemotePotato0 had pioneered into a fully practical domain attack. The blog post title is "Hello, I'm your domain admin and I want to authenticate against you" [@decoder-silverpotato]. The Troopers 24 abstract refers to the technique by its other name, ADCSCoercePotato [@troopers24; @decoder-adcs-coerce-repo]; both names refer to the same primitive.

The mechanism: members of the Distributed COM Users or Performance Log Users built-in groups can remotely trigger an NTLM authentication from any user currently logged on the target server -- including a Domain Administrator on a Domain Controller -- and relay it. The specific vehicle is the sppui Distributed COM application (class identifier F87B28F1-DA9A-4F35-8EC0-800EFCF26B83, "SPPUIObjectInteractive Class", hosted in slui.exe), which runs under the Interactive User identity [@decoder-silverpotato]. Pierini's wording in the post is unsparing:

"Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers." -- Andrea Pierini, "SilverPotato" writeup, April 2024 [@decoder-silverpotato]

The captured authentication is relayed via ntlmrelayx to AD CS Web Enrollment or LDAP, then chained with ForgeCert and Rubeus into a full Domain Admin Kerberos TGT [@decoder-silverpotato]. The Compass Security follow-on from September 2024 extends the chain further by modifying the KrbRelay project to make it remote and cross-session capable: "I modified the KrbRelay project to make it remote and cross-session capable, because Andrea did not release his PoC code ... DCOM hardening only allows relay to HTTP or unprotected LDAP" [@compass-three-headed]. Tianze Ding's Black Hat Asia 2024 talk on "CertifiedDCOM" landed in the same window [@blackhat-asia-2024]. Pierini's February 2024 post on the ADCS server side of the same surface foreshadowed the chain a few weeks earlier [@decoder-adcs-server].

flowchart LR A[Member of Distributed COM Users on target DC] --> B[Cross-session DCOM activation against sppui CLSID] B --> C[Logged-on Domain Admin session authenticates via NTLM] C --> D[ntlmrelayx forwards NTLM to AD CS Web Enrollment] D --> E[Computer-template certificate issued] E --> F[ForgeCert and Rubeus mint Domain Admin Kerberos TGT] F --> G[Domain compromise]

Note: The Troopers 24 abstract describes SilverPotato as "still in review by MSRC" as of June 2024 [@troopers24]. The Compass Security follow-on demonstrates a working end-to-end chain four months later [@compass-three-headed]. The default Distributed COM group memberships on Domain Controllers that grant the activation rights SilverPotato weaponises have not changed in any shipping Windows release as of May 2026. No CVE has been assigned [@decoder-silverpotato; @troopers24].

6.10 FakePotato and CVE-2024-38100

Four months after SilverPotato, on August 2, 2024, Pierini published the most recent named variant. He called it FakePotato, and he was up front about the name:

"You might be wondering why I called it the 'Fake' Potato. Initially, I thought it could be exploited using the same techniques as the *Potato families, but it turned out to be different and much simpler in this case." -- Andrea Pierini, "The Fake Potato" writeup, August 2024 [@decoder-fakepotato]

FakePotato abuses the ShellWindows Distributed COM application (AppID {9BA05972-F6A8-11CF-A442-00A0C90A8F39}), hosted in explorer.exe and registered to run under the Interactive User identity. Cross-session activation via BindToMoniker("session:N!new:<CLSID>") invokes ShellExecute in the target session. There is no NTLM relay, no token impersonation, no SeImpersonatePrivilege requirement -- any Authenticated User suffices because explorer.exe in High Integrity Level (UAC-disabled administrator) granted the Authenticated Users group execute permission via the DCOM Access Security ACL [@decoder-fakepotato].

{$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39") $p = $obj.item(0).document.application $p.ShellExecute("c:\\temp\\reverse.bat", "", "c:\\windows", $null, 0)}

Microsoft assigned CVE-2024-38100 and shipped the patch in the July 2024 Patch Tuesday cumulative updates on July 9, 2024 (KB5040434 for Windows 10 1607 / Windows Server 2016; equivalent KBs for Windows 11, Server 2019, Server 2022, and Server 2025) -- four weeks before the public disclosure [@decoder-fakepotato; @nvd-cve-2024-38100; @msrc-cve-2024-38100]. The patch corrects the explorer.exe ACL in High Integrity Level contexts so the Authenticated Users permission required for activation is no longer granted. The underlying cross-session Distributed COM activation primitive that SilverPotato and FakePotato share is untouched [@decoder-silverpotato; @decoder-fakepotato].

FakePotato is not, in the relay sense, a Potato at all. It is a misconfiguration of the ShellWindows Distributed COM application's permissions in High Integrity Level contexts [@decoder-fakepotato]. Pierini's "Fake" framing acknowledges the divergence from the NTLM-reflection pattern that defined the family from RottenPotato through GodPotato. The naming choice is itself a small piece of taxonomy: not every member of the family is a token-relay exploit, even if every member exploits the same architectural carve-out.

After nearly a decade of patching specific vehicles and refusing to declare the underlying primitive a boundary, Microsoft's pattern is hard to miss.

7. Eleven Variants at a Glance

Nine years of named-variant disclosures, eleven named variants, one architectural argument. The table below is sourced cell by cell from the preceding sections.

Variant	Date	Authors	Coercion vehicle	Mitigation it bypassed	Microsoft response	Still works in 2026?
HotPotato [@foxglove-hotpotato]	Jan 16, 2016	Stephen Breen	NBNS spoof + WPAD + HTTP-to-SMB relay	MS08-068 same-protocol-only fix	None named; EPA/SMB hardening eventually closed the vehicle	Only on pre-1607 builds
RottenPotato [@foxglove-rottenpotato]	Sep 23, 2016	Stephen Breen + Chris Mallz	DCOM activation via BITS CLSID on 127.0.0.1:6666	(none yet)	None	Only pre-1809 builds
RottenPotatoNG [@breenmachine-rottenng]	Dec 29, 2017	breenmachine	Same as RottenPotato (C++ port; no Metasploit)	(none yet)	None	Only pre-1809 builds
JuicyPotato [@ohpe-juicy]	Jul 27, 2018	Andrea Pierini + Giuseppe Trotta	Generalised DCOM activation; CLSID matrix	(none yet)	OXID-resolver hard-coding in Win10 1809 / Server 2019 [@forshaw-pz-2021]	Only pre-1809 builds
RoguePotato [@antonio-rogue]	May 10, 2020	Antonio Cocomazzi + Andrea Pierini	DCOM activation through remote TCP-135 forwarder	2019-2020 OXID-resolver hardening	None (no CVE)	Only pre-Phase-3 builds
PrintSpoofer [@itm4n-printspoofer]	Early May 2020	Clément Labro	Print Spooler RPC `RpcRemoteFindFirstPrinterChangeNotificationEx`	All DCOM-side hardening (irrelevant)	None (no CVE)	Yes, when Spooler is running
RemotePotato0 [@sentinellabs-relaying]	Apr 2021	Antonio Cocomazzi + Andrea Pierini	Cross-session DCOM/RPC NTLM relay	(defines a new threat surface)	"Won't Fix"; partial Oct 2022 RPC-to-LDAP mitigation	Partially (primitive intact)
JuicyPotatoNG [@antonio-juicyng; @decoder-juicyng]	Sep 21, 2022	Andrea Pierini + Antonio Cocomazzi	Local-OXID trick + LogonUser NewCredentials	CVE-2021-26414 Phase 1 and Phase 2	None (no CVE)	Only pre-Phase-3 builds
GodPotato [@beichendream-god]	Dec 23, 2022	BeichenDream	RPCSS OXID-handling defect (no resolver redirect)	All three CVE-2021-26414 phases	None (no CVE)	Yes -- the 2026 default
LocalPotato / CVE-2023-21746 [@decoder-localpotato; @nvd-cve-2023-21746]	Patched Jan 10, 2023	Andrea Pierini + Antonio Cocomazzi	NTLM Type-2 "Reserved" field context swap	(orthogonal -- attacks LSASS)	CVE-2023-21746 (first local-Potato CVE)	No -- patched
SilverPotato / ADCSCoercePotato [@decoder-silverpotato; @troopers24]	Apr 24, 2024	Andrea Pierini + Antonio Cocomazzi	Cross-session DCOM against `sppui` AppID	Post-RemotePotato0 partial mitigations	Still in review by MSRC as of mid-2026	Yes -- unpatched
FakePotato / CVE-2024-38100 [@decoder-fakepotato; @nvd-cve-2024-38100]	Disclosed Aug 2, 2024	Andrea Pierini	Cross-session DCOM against `ShellWindows` AppID (ACL bug)	(orthogonal)	CVE-2024-38100 in the July 2024 Patch Tuesday (KB5040434 for 1607/Server 2016; per-build KBs elsewhere)	No -- patched

Two CVEs in nine years of named-variant disclosures. One "Won't Fix" decision on a working Domain Admin escalation. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary. The pattern is consistent across every column [@troopers24; @msrc-servicing-criteria].

Key idea: Two CVEs in a decade, against a family with eleven named variants. The first CVE was for a piece of the local NTLM protocol that is on the servicing-criteria list, not for the underlying SeImpersonate-to-SYSTEM primitive. The second was for a Distributed COM access-control list misconfiguration, not for cross-session activation as a class. Microsoft will assign CVEs to specific vehicles when forced. It will not declare the architectural primitive a security boundary [@nvd-cve-2023-21746; @nvd-cve-2024-38100; @troopers24].

8. The 2026 Decision Surface

In May 2026, an operator with SeImpersonatePrivilege on a default Windows 11 box has a small menu of working tools, plus three legacy variants that remain useful on unpatched fleets. The current toolkit:

Method	Coercion vehicle	OS coverage	When to use it
GodPotato [@beichendream-god]	RPCSS OXID defect	Win 8 to Win 11; Server 2012 to Server 2025	Default first try on any in-support Windows
SweetPotato [@ccob-sweet]	Selectable: PrintSpoofer (default), DCOM, EfsRpc, WinRM	Win 7+ depending on selected mode	When GodPotato's binary signature is blocked
SharpEfsPotato [@bugch3ck-efs]	EFS RPC (`EfsRpcOpenFileRaw`)	Server 2019+, Win 10/11 with EFS RPC enabled	DCOM locked down and Spooler disabled
PrintSpoofer [@itm4n-printspoofer]	Print Spooler RPC	Any host with Spooler running	The lowest-noise option on Spooler-enabled hosts
JuicyPotatoNG [@antonio-juicyng]	Local-OXID + legacy CLSID	Pre-Phase-3 DCOM hardening only	Corporate fleets with delayed CVE-2021-26414 rollout
RoguePotato [@antonio-rogue]	Remote TCP-135 forwarder	Pre-Phase-3 DCOM hardening	Pre-2022 hardened-OXID-only systems with attacker remote infra
SilverPotato [@decoder-silverpotato]	Cross-session DCOM against DC	Default DCs with `Distributed COM Users` or `Performance Log Users` membership	Domain-tier escalation -- the only currently-unpatched cross-session variant

Plus three legacy variants worth knowing about: JuicyPotato on pre-1809 builds, RottenPotato on Server 2008 R2 / Windows 7 ESU-eligible builds, and HotPotato as the canonical naming origin and the source of the family's "documented Win32 calls" framing [@ohpe-juicy; @foxglove-rotten-repo; @foxglove-hotpotato]. Embedded Windows builds (Windows 10 IoT LTSC 2019, some industrial controllers, ATM images) frequently fall behind the OXID-resolver mitigation and remain JuicyPotato-vulnerable through 2026.

SharpEfsPotato's canonical repository is `github.com/bugch3ck/SharpEfsPotato` [@bugch3ck-efs]. A widely shared `ly4k/SharpEfsPotato` fork exists and is referenced in some red-team writeups, but the upstream is the `bugch3ck` repo per the README's own credit chain ("Built from SweetPotato by @\_EthicalChaos\_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0") [@bugch3ck-efs]. Operators citing the `ly4k` URL are pointing at a fork.

Every one of these tools has a Microsoft mitigation in its history. None of those mitigations closed the family. The next section asks what mitigation could.

9. What Would It Take To Close the Family?

A counterfactual sharpens the question. Suppose Microsoft decided in 2026 that the family must end. Three closure options exist, and each carries a compatibility cost.

Closure option	Mechanism	Compatibility cost
1. Declare `SeImpersonatePrivilege` a security boundary	Revoke the privilege from default service accounts (IIS app pools, SQL Server, BITS, Task Scheduler, the Spooler)	Operationally prohibitive: thousands of third-party services depend on the default grant
2. Declare Distributed COM activation a security boundary	Validate the activator's identity against the activated CLSID's registered identity on every activation	Breaks 25 years of legacy Distributed COM applications written between 1996 and 2021 [@ms-dcom-spec]
3. Deprecate `ImpersonateNamedPipeClient` as a Win32 primitive	Remove the call from `namedpipeapi.h` or gate it behind a Trustlet validation	Breaks parts of CSRSS, the console subsystem, and LSASS itself; no deprecation notice exists in the API reference as of mid-2026 [@ms-impersonate-api]

The CVE-2021-26414 hardening creeps toward option 2 for remote Distributed COM but explicitly does not for local Distributed COM [@ms-kb5004442]. The Adminless direction in Windows 11 24H2 -- Microsoft's "Administrator protection" platform feature, currently a preview shipped first via Windows Insider builds and not yet generally available [@ms-administrator-protection] -- introduces a per-application admin-elevation gate, but operates above the SYSTEM-impersonation primitive, not below it. Credential Guard isolates LSASS secrets in a Virtualization-Based Security Trustlet -- which protects NTLM hashes from extraction but does not gate ImpersonateNamedPipeClient or SeImpersonatePrivilege [@ms-credential-guard]. Smart App Control restricts arbitrary binary execution but does not block in-process exploitation by a SYSTEM-running service [@ms-smart-app-control].

The lower bound on attack cost is therefore O(1) per invocation, and it stays O(1) as long as the servicing-criteria carve-out holds. No combination of currently-shipping mitigations moves it.

Key idea: The Potato family is a fixed point of the current Windows architecture. Every closure option carries a compatibility cost that no currently-announced Microsoft release accepts. Until the MSRC Windows Security Servicing Criteria changes the position on SeImpersonatePrivilege and Distributed COM activation, the family's lower attack cost is O(1) and no servicing patch can move it [@msrc-servicing-criteria; @troopers24].

The claim is empirical, not formal. A "fixed point" in the algorithmic sense is a value where a function returns its own input. For the Potato family the analogue is: every Microsoft mitigation that does not change the servicing-criteria document returns a family that is still alive. The fixed-point status is consistent with eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) against three named hardening waves. It would be invalidated by a major-version Windows release that explicitly revoked the default `SeImpersonatePrivilege` grant on service accounts. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria].

10. Open Problems

Five questions sit at the research frontier in 2026.

The next coercion vehicle. Each Potato variant is one SYSTEM-context service with a callback-style API. As the family has matured, researchers have mapped a growing surface of candidates: EFS RPC (which SharpEfsPotato already weaponises [@bugch3ck-efs]), Print Spooler async RPC (MS-PAR), Windows Search remote protocol (MS-WSP), and Microsoft Distributed Transaction Coordinator RPC. The community-empirical conjecture, repeated across Troopers 24 [@troopers24] and the Compass Security retrospective [@compass-three-headed], is that any SYSTEM-context Windows service with a callback-style API becomes a Potato vehicle within roughly eighteen months of operational need.

The "eighteen-month vehicle cadence" is an informal community claim, not a measured statistic. It originates in the Troopers 24 retrospective by Pierini and Cocomazzi [@troopers24] and is reinforced by the Compass Security follow-on documenting how the SilverPotato chain was productised within months of Pierini's February 2024 ADCS-server post [@decoder-adcs-server; @compass-three-headed]. The number should be read as a rule of thumb, not a benchmark.

Linux and Windows Subsystem for Linux extension. No Linux analogue of SeImpersonatePrivilege exists. There are partial precedents in the impacket cross-protocol relay work, but no Potato-class primitive that produces a SYSTEM token on a Linux host. Open.

Will defence-in-depth combine to close the family without ever declaring a new boundary? Microsoft has shipped Credential Guard [@ms-credential-guard], Hypervisor-Protected Code Integrity [@ms-hvci], Smart App Control [@ms-smart-app-control], and the experimental Administrator-protection direction in Windows 11 24H2 [@ms-administrator-protection]. Each changes the runtime trust model in some way. No combination of currently-shipping technologies closes the family as of May 2026 -- the Potato primitives live below the layer those technologies operate on [@troopers24; @compass-three-headed].

A defensive detection primitive that catches every variant. The unifying invariant is ImpersonateNamedPipeClient being called from a thread that holds SeImpersonatePrivilege against a named pipe that has just received a SYSTEM-context authentication originating from a service the calling process did not initiate. Per-variant detection rules exist for each named tool (GodPotato, PrintSpoofer, JuicyPotato). A generalising rule has not been published [@ms-impersonate-api]. The informal community position is that the family is non-detectable as a class because the primitive is in the legitimate hot path of nearly every Windows service.

MSRC servicing-criteria position on cross-session Distributed COM activation. LocalPotato (CVE-2023-21746) received a CVE for a piece of the local NTLM protocol [@nvd-cve-2023-21746]. FakePotato (CVE-2024-38100) received a CVE for an access-control list misconfiguration on the ShellWindows AppID [@nvd-cve-2024-38100]. SilverPotato is still unpatched [@decoder-silverpotato; @troopers24]. The boundary that distinguishes these three is unclear: why was the ShellWindows cross-session activation patched while the sppui cross-session activation has not been? The answer determines the next decade of the family. The defensible reading is that Microsoft will service variants that look like permission misconfigurations on a single AppID but not the underlying cross-session Distributed COM activation primitive itself.

11. How to Use a Potato in 2026

The practitioner question is operational. Given a foothold and a goal, which Potato variant does the job? The decision tree below walks through the path researchers settle into on red-team engagements.

The first-try heuristic is short. GodPotato first, because it is the single binary that works on every in-support Windows release [@beichendream-god]. If the GodPotato binary signature is blocked by Endpoint Detection and Response, SweetPotato with -e PrintSpoofer (or -e EfsRpc on a Domain Controller where Spooler is off) [@ccob-sweet]. If both are blocked, SharpEfsPotato as the lower-public-exposure third choice [@bugch3ck-efs]. For pre-2023 unpatched fleets, JuicyPotatoNG during the Phase-2 hardening window and JuicyPotato on pre-1809 builds [@antonio-juicyng; @ohpe-juicy]. For domain escalation against a DC, SilverPotato with the Compass Security KrbRelay modifications [@decoder-silverpotato; @compass-three-headed].

Note: GodPotato. If signature-blocked, SweetPotato with -e PrintSpoofer. If both blocked, SharpEfsPotato. The rest of the family is for situations the first three do not cover (legacy fleets, DC escalation, technique illustration of patched variants) [@beichendream-god; @ccob-sweet; @bugch3ck-efs].

Several implementation pitfalls catch new operators. The named-pipe path that GodPotato uses (\pipe\<token>\pipe\epmapper) is widely signatured by EDR vendors -- see the detection-engineering Spoiler below for the specific Sigma and Elastic rules [@sigma-potato-hktl; @elastic-rogue-pipe] -- and recompiling from source with a different pipe template is the standard countermeasure. A token holding SeImpersonatePrivilege does not necessarily enable it -- explicit AdjustTokenPrivileges with SE_PRIVILEGE_ENABLED is required, and custom adaptations frequently miss the step [@ms-adjusttokenprivileges]. SweetPotato's default -e PrintSpoofer mode fails silently on a Domain Controller where Spooler is disabled per the PrintNightmare aftermath; the correct DC default is GodPotato or SharpEfsPotato. RoguePotato's outbound TCP 135 to attacker infrastructure is blocked by default in most enterprise networks. FakePotato and SilverPotato both require the victim identity to be actively logged in, since both depend on a live cross-session activation surface [@itm4n-printspoofer; @antonio-rogue; @decoder-silverpotato; @decoder-fakepotato].

If you defend Windows rather than attack it, the detection target is the conjunction of (a) named-pipe creation by an IIS or SQL or service account, (b) a SYSTEM-context process connecting to that pipe shortly after, and (c) `CreateProcessWithToken` from the original service-account process. None of the three events alone is anomalous. The conjunction is. Sysmon Event ID 1 (Process Create) paired with Event IDs 17 and 18 (PipeEvent: Pipe Created and Pipe Connected) plus ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` cover the activation-plus-pipe half [@ms-sysmon]; Sysmon Event ID 10 (ProcessAccess) on `lsass.exe` from the originating service account is the third pillar that surfaces the impersonation handle acquisition [@ms-sysmon]. Per-variant signatures are published as Sigma rules for the public LocalPotato, CoercedPotato, JuicyPotato, RottenPotato, and EfsPotato binaries [@sigma-potato-hktl; @sigma-localpotato], and Elastic's `privilege_escalation_via_rogue_named_pipe` rule fires on the PrintSpoofer / EfsPotato pipe-path pattern that GodPotato shares [@elastic-rogue-pipe]. A class-generalising rule that fires on the *primitive* (rather than per-binary) has not been published.

Library and framework support follows the same shape as any post-exploitation primitive (the picture here is community-empirical, drawn from public BOF and module repositories rather than vendor reference architectures). Cobalt Strike Beacon Object Files wrapping GodPotato, PrintSpoofer, and SweetPotato are widely shared in the red-team community -- incursi0n/GodPotatoBOF is one publicly published example that integrates with BeaconUseToken() for in-Beacon SYSTEM-token application [@godpotato-bof] -- and the same wrappers load into Sliver. PowerShell wrappers around PrintSpoofer and JuicyPotato are integrated into Empire and Starkiller. The Metasploit incognito post-exploitation module handles token impersonation as a primitive but does not wrap GodPotato directly [@msf-incognito]. The impacket toolkit's ntlmrelayx is the canonical relay engine for the tail of SilverPotato [@fortra-impacket], and OleViewDotNet -- Forshaw's tool -- is the discovery oracle that surfaced the sppui and ShellWindows AppIDs in the first place [@tyranid-oleview; @decoder-silverpotato; @decoder-fakepotato].

12. Frequently Asked Questions

The name `Potato` originates with Stephen Breen's `foxglovesec/Potato` repository, created February 9, 2016, three weeks after the January 16, 2016 HotPotato blog post [@foxglove-potato-repo; @foxglove-hotpotato]. HotPotato is in the family because it pivots through the same `SeImpersonatePrivilege` plus named-pipe-impersonation primitive that every later variant exploits -- the vehicle is different (NetBIOS spoofing + WPAD + HTTP-to-SMB rather than Distributed COM) but the architectural carve-out is the same. See §4 for the bracketing-variant framing. Because every Internet Information Services application-pool identity is granted the privilege by Windows default [@itm4n-printspoofer]. The grant exists for legitimate request-scoped impersonation -- it is the mechanism IIS uses to "act as" a calling user during authenticated request handling. The same default grant is the entire vulnerability surface for the Potato family. The Microsoft Security Servicing Criteria document treats the resulting `SeImpersonate`-to-SYSTEM transition as a safety boundary rather than a security boundary [@msrc-servicing-criteria; @troopers24]. No. CVE-2021-26414 hardening raises the *authentication* bar for Distributed COM clients to `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` and was fully enforced on March 14, 2023 in Phase 3 of the rollout [@ms-kb5004442]. It does not declare Distributed COM activation a security boundary. The proof is that GodPotato, which exploits an RPCSS OXID-handling defect rather than the activation authentication level, survives all three phases of the rollout and remains the practitioner default in 2026 [@beichendream-god]. Open question, with a defensible reading. LocalPotato attacks the local-user-to-local-user NTLM authentication context handle, which *is* on the servicing-criteria boundary list [@decoder-localpotato; @msrc-servicing-criteria]. RemotePotato0 attacks the `SeImpersonate`-to-SYSTEM transition via cross-session Distributed COM activation, which is *not* on the list and was therefore deemed an extension of the existing carve-out [@sentinellabs-relaying; @troopers24]. The two boundaries (local NTLM authentication context vs cross-session Distributed COM activation) are not equivalent in Microsoft's published servicing position. Yes, on every patched Windows 11 / Server 2025 build as of this writing [@beichendream-god]. The RPCSS OXID-handling defect that GodPotato weaponises survives all three CVE-2021-26414 hardening phases [@ms-kb5004442; @compass-three-headed]. Microsoft has not assigned a CVE to the underlying defect, consistent with the servicing-criteria reading. Operationally, the only thing that changes between releases is the binary signature -- EDR vendors signature the public Apache-2.0 binary by hash, and operators recompile from source with cosmetic changes to evade [@beichendream-god]. Does not exist as of May 2026. If a 2025-2026 variant appears under an unfamiliar name -- French or otherwise -- verify against the canonical sources before citing: `decoder.cloud` for the Pierini and Cocomazzi line, `github.com/antonioCoco/*` for the Cocomazzi-authored repositories, `github.com/BeichenDream/*` for the BeichenDream line, and `itm4n.github.io` for the PrintSpoofer / SweetPotato line [@decoder-silverpotato; @antonio-rogue; @beichendream-god; @itm4n-printspoofer]. The Troopers 24 retrospective is the community-canonical lineage list as of the most recent consolidated talk [@troopers24]. Informally, no. The primitive `ImpersonateNamedPipeClient` is in the legitimate hot path of nearly every Windows service [@ms-impersonate-api]. Per-variant signatures exist for the public binaries (GodPotato, PrintSpoofer, JuicyPotato), and ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` surface the activation-and-RPC events that the Distributed COM variants generate. A class-generalising detection rule has not been published as of May 2026, and the false-positive rate on legitimate Windows services is high for any rule that fires on `ImpersonateNamedPipeClient` alone [@troopers24].

13. The Architectural Decision

Return to the opening scene. The same Internet Information Services web shell, the same GodPotato.exe, the same ten-second SYSTEM shell. The reader now knows this is not a zero-day. It has been a single-binary operation for the better part of a decade. Every step is documented Win32 behaviour. And every step is permitted by Microsoft's published servicing position [@beichendream-god; @msrc-servicing-criteria; @troopers24].

Nine years of named-variant disclosures. Eleven named variants. Three Microsoft hardening waves. Two CVEs -- LocalPotato in January 2023, FakePotato in July 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]. One "Won't Fix" decision on a working Domain Admin escalation in April 2021 [@sentinellabs-relaying]. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary [@troopers24; @msrc-servicing-criteria]. The MSRC Windows Security Servicing Criteria document, the one whose boundary definition fetches in static HTML and whose enumeration table is JavaScript-rendered, is the through-line [@msrc-servicing-criteria]. Pierini and Cocomazzi say it bluntly in the Troopers 24 abstract:

Microsoft does not consider WSH a security boundary but rather a safety boundary; for this reason, many Potato exploits work (and have been working) on fully updated Windows systems. -- Pierini and Cocomazzi, Troopers 24 abstract [@troopers24]

Microsoft will never fix the Potato class because fixing it requires declaring Distributed COM activation a security boundary, and they have spent twenty-five years insisting it is not. What would change that? A major-version Windows release that explicitly revokes the default SeImpersonatePrivilege grant from service accounts -- a compatibility-breaking change that breaks IIS, SQL Server, BITS, the Spooler, and most third-party services that depend on the legitimate impersonation contract. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria; @ms-kb5004442; @beichendream-god].

Until then, the family is alive, and the ten-second SYSTEM shell is the default outcome of any IIS or service-account foothold on a fully-patched Windows machine. That is not the unintended consequence of an unpatched bug. That is the intended consequence of a published architectural decision.

Key idea: The Potato family is not a stack of bugs Microsoft is slowly working through. It is the long-running consequence of a published architectural decision: that the SeImpersonatePrivilege-to-SYSTEM transition is a safety boundary, not a security boundary. Eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) are the empirical proof of how stable that decision is [@troopers24; @msrc-servicing-criteria].

The following retention block summarises the six key terms above. Citations for each definition live in §2.1, §2.2, §6.5, §6.1, §3, and §2 of the body respectively (the StudyGuide MDX wrapper does not render @ref-id links inline).

The Connection That Refused to Downgrade: Twenty-Five Years of SMB Cryptography, Finally Default-On

noreply@paragmali.com (Parag Mali) — Tue, 26 May 2026 00:00:00 GMT

**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 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.

Paul Leach (Microsoft) circulated a CIFS Internet Draft at the IETF in 1996-1997 [@leach-cifs-draft], hoping to take SMB through the standards-track process. Microsoft kept revising the spec internally; the IETF draft never advanced to RFC. The "CIFS" name persisted as marketing for SMB1 well after Microsoft had moved on to SMB 2.0 in 2006, which is why product documentation continued to refer to "CIFS shares" through the 2010s even though the wire protocol had changed twice. Today the only meaningful use of the word is as a label for the SMB1 wire dialect family, normatively documented in `[MS-CIFS]` [@ms-cifs-landing].

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:

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.
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.
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:

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.
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.
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.
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.
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 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.

Some descriptions of SMB-over-QUIC suggest the SMB application layer is unencrypted because QUIC already encrypts everything. That is wrong in a way that matters. SMB-over-QUIC still negotiates SMB 3.1.1 pre-authentication integrity and SMB signing; the SMB session key derives independently from the authentication protocol, not from the TLS 1.3 session secret. There are two layers of encryption (TLS 1.3 at the QUIC layer and AES-GCM at the SMB layer) precisely because the two layers have independent trust anchors. If the QUIC TLS 1.3 session is MITM'd by a rogue CA, the SMB-layer signing keys still verify against the authentication protocol's session key; the inner layer is the structural backstop.

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

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].
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.
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].
NTLM blocking for outbound SMB. Set-SmbClientConfiguration -BlockNTLM $true refuses outbound NTLM fallback, forcing Kerberos or failing the session [@smb-security-hardening].
SMB dialect minimum and maximum, configurable per-host on both client and server [@smb-security-hardening].
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].
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].

The audit channel for tracking which peers an organisation's clients fail to sign with is `Applications and Services Logs\Microsoft\Windows\SmbClient\Audit`, populated by the SMB client itself whenever it refuses an unsigned session [@smb-security-hardening]. The transitional pattern administrators were forced to adopt in late 2024 was: (a) leave signing required globally, (b) maintain a per-host exception list for unupgradable NAS devices, (c) put the exception list under change control with a target removal date. A few months of audit-log data is usually enough to enumerate the long tail of peers an organisation actually depends on; the policy-exception approach is structurally sound because the exception is narrow and time-bounded.

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, 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 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, };

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 (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.

NTLMless: The Death of NTLM in Windows

noreply@paragmali.com (Parag Mali) — Sun, 10 May 2026 00:00:00 GMT

**NTLM is the 30-year-old fallback authentication protocol that Active Directory still rests on whenever Kerberos cannot do the job -- and every consequential modern AD attack (pass-the-hash, NTLM relay, PetitPotam, ESC8) lives in that fallback path.** Microsoft's exit plan (IAKerb, Local KDC, NEGOEX, the Negotiate-everywhere refactor) closes the four reasons NTLM survived, and the January 2026 roadmap names "disabled by default in the next major Windows release" as Phase 3. This article tells the whole arc as one story: how NTLM works on the wire, every attack class against it, exactly what is being removed -- and what is not.

1. Eight Minutes

A defender has done every retrofit Microsoft has shipped over twenty years. SMB signing enforced on every member server. EPA enabled on every IIS endpoint. Credential Guard on. Restrict NTLM in audit mode. KB 5005413 applied to AD CS. An attacker with no credentials joins their network, runs Coercer against a domain controller, and a handful of seconds later holds a Kerberos ticket-granting ticket for the Domain Admin account [@gh-coercer, @specterops-cert-preowned-blog]. Total elapsed time: less than the time it took you to read this paragraph. Total prerequisites for the chain: that NTLM still exists as a fallback path on Windows.

The chain has a name. ESC8, from Will Schroeder and Lee Christensen's "Certified Pre-Owned" whitepaper, published June 17, 2021 [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]. Its coercion primitive has another name. PetitPotam, from Lionel Gilles, published the next month. Together they take a fully retrofitted Active Directory environment to Domain Admin in four steps.

Note: 1. Coerce. Call EfsRpcOpenFileRaw against any Windows server -- including a DC -- over LSARPC. The service, running as SYSTEM, NTLM-authenticates back to an attacker-controlled UNC path. No credentials required. 2. Relay. ntlmrelayx.py from Impacket sits on the listening side and forwards the live NTLM exchange to the AD CS Web Enrollment endpoint at /certsrv/certfnsh.asp [@gh-impacket]. 3. Enroll. The relayed authentication enrolls the DC's machine account for a client certificate against the Machine template (or any default-enabled template that allows enrollment) [@specterops-cert-preowned-pdf]. 4. Forge. The attacker uses the certificate to perform PKINIT against the KDC, obtains a TGT for the DC's machine account, and uses the DC machine account's TGT to DCSync the domain's hashes -- including the krbtgt hash -- achieving full domain compromise. Domain Admin in under ten minutes [@specterops-cert-preowned-blog].

Pause on what is and is not true here. SMB signing did not fail; SMB signing was not in the chain. EPA failed because it was deployed on IIS authentication endpoints generally but the /certsrv/ deployment lagged [@ms-kb5005413]. Credential Guard did not fail; Credential Guard protects the NT-hash, and the attacker never touched a hash. Restrict NTLM in audit mode worked exactly as labelled: it audited.

The retrofits are not wrong. They patch the named primitives. The chain exploits the existence of the fallback path, not a primitive. Every protective control is honest about what it does and silent about what it does not.

sequenceDiagram autonumber actor A as Attacker (no creds) participant DC as Domain Controller participant R as ntlmrelayx listener participant CA as AD CS /certsrv/ participant KDC as KDC (PKINIT) A->>DC: EfsRpcOpenFileRaw -- UNC to attacker share DC->>R: NTLM AUTHENTICATE (SYSTEM (DC machine account)) R->>CA: Relay NTLM, enroll Machine cert as DC CA-->>R: Client certificate for DC R->>KDC: PKINIT AS-REQ with DC cert KDC-->>A: TGT for DC, request service tickets at will

This is the question that drives the rest of the article: how did Windows arrive at a state where the most catastrophic modern Active Directory attack chain depends on a thirty-year-old fallback nobody wants?

2. Origins: Why NTLM Existed at All

Rewind to 1987. IBM and Microsoft ship LAN Manager 1.0 for OS/2. PCs are still mostly file-and-print islands on Token Ring or 10BASE-2 coax; networking exists, but "domain" is a word for what a single server controls. LAN Manager needs an authentication scheme that can run on hardware with 640 KB of RAM, no DES export licence, and roughly zero institutional knowledge about cryptography. What it produces, the LM hash, is a near-perfect snapshot of every constraint and assumption of its moment [@wp-lan-manager].

The construction is short enough to write out. Take the password. Uppercase it. Pad or truncate to exactly fourteen ASCII characters. Split into two seven-byte halves. Convert each half into a 56-bit DES key (the eighth bit of each byte is a parity bit). Use each key to DES-encrypt the eight-byte constant KGS!@#$%. Concatenate the two eight-byte ciphertexts. That is the LM hash [@wp-lan-manager, @wp-nt-lan-manager].

The LAN Manager password hash from 1987. Constructed by uppercasing the password, truncating or padding to 14 characters, splitting into two 7-byte halves, and DES-encrypting the constant `KGS!@#$%` with each half as a key. The two halves are independent, the password is case-insensitive, and there is no salt. Every property of this construction enables an attack class that survives into NTLMv2 [@wp-lan-manager].

The eight-byte constant KGS!@#$% is what you get when somebody types "KGS" and then mashes shift-1, shift-2, shift-3, shift-4, shift-5 on a 1980s American IBM keyboard. The constant is in the protocol because the protocol predates the cryptographic-engineering norm that constants should look random. It would not survive a 2026 design review; in 1987 nobody asked.

Every choice tells a story about 1987. Uppercase, because some clients normalised case anyway and the developers wanted authentication to "just work" across mixed locale settings. Fourteen characters, because that was the field width DOS dictated. Two halves, because a 56-bit DES key already maxed out the practical computation; nobody was going to chain two DES operations through a feedback function with that much per-keystroke latency. No salt, because the deployment model was one server, one user database, and identical-password collisions were a feature for the help desk, not a leak.

The result is password-equivalent: anyone who possesses the LM hash is the user, forever, regardless of how the wire protocol presents the credential.

Six years later, July 27, 1993, Windows NT 3.1 ships. NTLM(v1) arrives with it [@wp-nt-lan-manager]. The NT-hash is what you would design if you started over with mid-1990s assumptions but were not yet willing to abandon DES at the response layer. It is simpler than the LM hash and stronger in exactly one place: NT-hash = MD4(UTF-16LE(password)) [@wp-nt-lan-manager]. No truncation. No case folding. Sixteen bytes of output. The hash is still password-equivalent; what changes is that the input to the hash is now whatever Unicode string the user typed, in full.

The wire protocol around the NT-hash is the famous three-message handshake. NEGOTIATE from the client. CHALLENGE from the server (an eight-byte random nonce). AUTHENTICATE from the client, carrying a DES-based response computed from the NT-hash and the server challenge. The whole exchange is self-contained: nothing in the three messages binds the authentication to a particular transport, a particular client, a particular server, or a particular service [@ms-nlmp]. That property -- the absence of binding -- is the property NTLM relay will eat for the next twenty-five years.

`MD4(UTF-16LE(password))`. Sixteen bytes. The single long-term secret that every NTLM authentication ever performed for a given user derives from. Possession of the NT-hash is mathematically equivalent to possession of the password for every authentication purpose. NTLMv2 changes the response computation but not the hash [@wp-nt-lan-manager]. timeline title NTLM and Windows authentication, 1987-2027 1987 : LAN Manager 1.0 ships : LM hash construction 1993 : Windows NT 3.1 : NTLMv1 + NT-hash MD4(UTF-16LE(pwd)) 1998 : NT 4.0 SP4 : NTLMv2 with HMAC-MD5 and AV_PAIRS 2000 : Windows 2000 : Kerberos is the default; NTLM demoted to fallback 2008 : MS08-068 patches SMB self-relay (CVE-2008-4037) 2015 : Windows 10 RTM ships Credential Guard 2019 : CVE-2019-1040 Drop the MIC (Simakov/Zinar) 2021 : PetitPotam (Gilles) + ESC8 (Schroeder/Christensen) 2023 : Palko commits to removing NTLM (October 11) 2024 : NTLM marked deprecated (June); NTLMv1 removed in 24H2/Server 2025 2025 : KB 5064479 enhanced NTLM auditing 2026 : Phase 1 (audit) + IAKerb/Local KDC pre-release (Phase 2) 2027 : Phase 3 -- NTLM disabled by default (next major Windows release)

The third revision arrives with NT 4.0 Service Pack 4, October 1998. NTLMv2 throws away DES at the response layer and replaces it with HMAC-MD5. It introduces a client challenge (so the response is no longer purely a function of the server's choice). It introduces AV_PAIRS, a small TLV structure carrying the target name, a timestamp, and -- in much later retrofits -- the channel binding hash and message integrity field [@ms-nlmp, @wp-nt-lan-manager]. NTLMv2 defeats pre-computation attacks against the response. It does not change the long-term secret. The NT-hash is still the NT-hash; possession is still authority.An intermediate variant, NTLM2 Session Security, shipped in NT 4.0 SP4 alongside NTLMv2 and is the dead end most often confused for v2. It added an 8-byte client challenge to the NTLMv1 DES envelope without touching the long-term hash, hoping to defeat pre-computation while preserving wire compatibility. It survived only as a transitional LMCompatibilityLevel setting; nothing in the modern attack catalogue treats NTLM2 SS as a distinct target [@ms-nlmp].

Property	LM hash (1987)	NTLMv1 (1993)	NTLMv2 (1998)
Hash function for the long-term secret	DES of constant with password halves	MD4(UTF-16LE(password))	MD4(UTF-16LE(password))
Case-sensitive	No (uppercase only)	Yes	Yes
Max input length	14 characters (truncated)	Unlimited Unicode	Unlimited Unicode
Salted	No	No	Per-exchange client challenge + timestamp
Response keyed MAC	DES (3 keys, 56-bit each)	DES (3 keys, 56-bit each)	HMAC-MD5
Binds to target server name	No	No	AV_PAIR `MsvAvTargetName` (retrofit)
Binds to TLS endpoint	No	No	AV_PAIR `MsvAvChannelBindings` (retrofit)
Possession of hash = authority	Yes	Yes	Yes

The two production response constructions on top of the same NT-hash. NTLMv1 chains three 56-bit DES operations across `K1 = NT-hash[0:7]`, `K2 = NT-hash[7:14]`, `K3 = NT-hash[14:16] || \x00\x00\x00\x00\x00`, encrypting the eight-byte server challenge under each. The third sub-key has only 16 bits of real entropy. NTLMv2 replaces all three DES operations with one HMAC-MD5 over `server_challenge || client_challenge || timestamp || av_pairs`, keyed by `NTOWFv2 = HMAC_MD5(NT-hash, UNICODE(Upper(user) || domain))` [@ms-nlmp, @wp-nt-lan-manager].

Then comes Windows 2000, and Kerberos. Microsoft's plan was simple: in a domain, Kerberos handles everything; NTLM stays around as a compatibility blanket for the cases Kerberos cannot cover yet [@microsoft-ntlm-overview]. The trouble was that "the cases Kerberos cannot cover yet" turned out to be a permanent set, not a transitional one. Twenty-three years later, the same four cases would be the table-of-contents of Microsoft's NTLM-removal plan [@palko-2023-evolution]:

No domain-controller line-of-sight. A laptop on a hotel Wi-Fi authenticating to a corporate file share through a VPN tunnel terminator has no Kerberos KDC to talk to. NTLM does not need one.
Local accounts. A user signing into a workgroup machine or a domain-joined machine's local SAM has no domain at all; Kerberos has nothing to authenticate against.
No service principal name. Kerberos requires a known SPN for the target service. Connect to a server by raw IP, by an alias DNS name not yet in the SPN database, or by a CNAME the operator forgot to register -- there is no SPN, so Kerberos cannot run.
Hard-coded NTLM. Application code that calls AcquireCredentialsHandleW(..., "Ntlm", ...) or RPC code that asks for RPC_C_AUTHN_WINNT directly bypasses the negotiator and forces NTLM regardless of what is available.

The Simple and Protected GSS-API Negotiation Mechanism. When two parties want to authenticate but do not know which security mechanism they share, SPNEGO offers a list and picks the best one both support. On Windows the SSPI provider is called `Negotiate`, and it has historically chosen Kerberos when possible and NTLM otherwise [@microsoft-ntlm-overview]. The "otherwise" path is where every modern NTLM attack lives.

Each fallback case is one shutter through which NTLM continues to leak into a Kerberos-by-default world. The demotion was supposed to be terminal. Why did the four fallback cases turn out to cover most of the real-world authentication surface, and what does that look like on the wire?

3. The Wire: Three Messages and One Hash

Most defenders have never read an NTLM authentication off the wire. The cryptography is short enough to fit on one screen, and the structural property that drives the next 28 years of attacks is visible inside those three messages. The point of this section is to make that property impossible to miss.

NEGOTIATE, CHALLENGE, AUTHENTICATE

The client opens with NEGOTIATE, advertising its capability flags: which signing modes it supports, whether it is willing to do session security, whether it is asking for extended session keys, and so on. The server replies with CHALLENGE. The body of CHALLENGE contains a single 64-bit nonce (the server challenge) and a TLV blob called TargetInfo: a list of attribute-value pairs the server wants to bind into the authentication [@ms-nlmp].

The client computes its response and sends AUTHENTICATE. That message contains the user name, the workstation name, the response itself, the AV_PAIRS the client wants to echo back, a Message Integrity Code field (HMAC-MD5 of the concatenation of all three NTLM messages), and -- in EPA-enforced deployments -- a hash of the TLS endpoint certificate placed in the MsvAvChannelBindings AV_PAIR [@ms-nlmp, @ms-epa-wcf].

sequenceDiagram autonumber participant C as Client participant S as Server C->>S: NEGOTIATE (capability flags) S->>C: CHALLENGE (server nonce 8B, TargetInfo AV_PAIRS) Note over C: NTOWFv2 = HMAC_MD5(NT-hash, UNICODE(Upper(user) plus domain)) Note over C: NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge plus temp) where temp = version plus Z(6) plus Time plus ClientChallenge plus Z(4) plus ServerName plus Z(4) C->>S: AUTHENTICATE (user, NTProofStr, temp, MIC, CBT) Note over S: Server replays the same HMAC_MD5 with its copy of the NT-hash to verify

The NTLMv2 response, verbatim

[MS-NLMP] §3.3.2 gives the response algorithm in three lines of pseudocode [@ms-nlmp]:

$$\text{NTOWFv2} = \text{HMAC-MD5}\big(\text{NT-hash},\ \text{UNICODE}(\text{Upper(user)} \mathbin{|} \text{domain})\big)$$

$$\text{temp} = \text{Responserversion} \mathbin{|} \text{HiResponserversion} \mathbin{|} Z(6) \mathbin{|} \text{Time} \mathbin{|} \text{ClientChallenge} \mathbin{|} Z(4) \mathbin{|} \text{ServerName} \mathbin{|} Z(4)$$

$$\text{NTProofStr} = \text{HMAC-MD5}\big(\text{NTOWFv2},\ \text{ServerChallenge} \mathbin{|} \text{temp}\big)$$

The temp byte string carries two version bytes, six zero bytes, the 8-byte FILETIME, the 8-byte client challenge, four zero bytes, the AV_PAIR list the spec calls ServerName, and a final four zero bytes. The client sends NTProofStr || temp as the response. The server, which holds its own copy of NT-hash for the user (cached or fetched from the domain controller), recomputes the same three lines and checks equality. That is the entire response protocol.

Notice what NTOWFv2 is. It is a function of two inputs: the NT-hash, and a normalised user/domain string. Both inputs are static once the user logs in. Knowing the NT-hash is sufficient to compute every NTLMv2 response forever, against every server, for every challenge, until the password changes [@wp-pass-the-hash].Why is HMAC-MD5 considered fine for the response side but considered weak for the key side? The response side is being asked: given a known key, can a verifier check a freshly computed tag? HMAC-MD5 still answers that without a known break. The key side is being asked: given a stolen 16-byte value, how hard is it to mount a precomputation attack on candidate passwords? MD4 of UTF-16LE is so cheap on modern GPUs that an 8-character password is in the minutes-to-hours range. Hashcat lists NetNTLMv2 (mode 5600) as the practical attack format and benchmarks NTLM cracking accordingly.

AV_PAIRS, MIC, and channel binding -- retrofits all the way down

AV_PAIRS is a TLV structure. The server places target NetBIOS, target DNS, a timestamp, and various flags into the TargetInfo of CHALLENGE. The client echoes the structure into AUTHENTICATE and adds two retrofit fields when both ends agree to use them [@ms-nlmp]:

MsvAvFlags is a bit field signalling that the client has computed a MIC and is therefore willing to bind all three NTLM messages together.
MsvAvChannelBindings holds a hash of the server's TLS endpoint certificate when the authentication is happening over an HTTPS-style transport that the client can see. This is the Extended Protection for Authentication (EPA) channel-binding-token mechanism [@ms-epa-wcf].

The MIC field itself is added to AUTHENTICATE. It is HMAC_MD5(ExportedSessionKey, NEGOTIATE || CHALLENGE || AUTHENTICATE). ExportedSessionKey coincides with SessionBaseKey in the common case; when NTLMSSP_NEGOTIATE_KEY_EXCH is set, the client generates a random session key, encrypts it under KeyExchangeKey, and ExportedSessionKey is the random key. The MIC always uses ExportedSessionKey, and it is intended to make tampering with any of the three messages detectable [@ms-nlmp].

A length-prefixed TLV list carried inside the `TargetInfo` byte string of NTLM `CHALLENGE` and the AV-list byte string of `AUTHENTICATE`. AV_PAIRS hold the target server names, a timestamp, the `MsvAvFlags`, the `MsvAvChannelBindings` (EPA), and the optional `MsvAvTargetName` (SPN). NTLMv2 reserved AV_PAIRS in 1998 but most of the fields are 2009-2019-era retrofits onto the original wire format [@ms-nlmp]. A 16-byte HMAC-MD5, keyed by `ExportedSessionKey`, computed over the concatenation of the NTLM `NEGOTIATE`, `CHALLENGE`, and `AUTHENTICATE` messages and embedded in `AUTHENTICATE`. (`ExportedSessionKey` equals `SessionBaseKey` unless `NTLMSSP_NEGOTIATE_KEY_EXCH` is negotiated; the MIC always uses the exported key.) Introduced as a retrofit so that a man-in-the-middle relay could not silently strip the signing-required flags from the negotiate phase. Drop-the-MIC (CVE-2019-1040) demonstrated that the *presence* of the MIC was itself a negotiated property and could be stripped [@ms-nlmp, @nvd-cve-2019-1040]. A hash of the server's TLS endpoint certificate placed in `MsvAvChannelBindings` so the authentication is bound to the specific TLS channel the client believed it was talking over. When both ends enforce CBT, an attacker who terminates one TLS channel and opens a different TLS channel to the real server cannot reuse the captured NTLM response. Microsoft documents three enforcement modes: None, Partial, and Full [@ms-epa-wcf].

Run it

The whole thing fits in a few dozen lines of JavaScript. The point of the runnable demo is not to teach you to crack hashes; it is to make the password-equivalence claim land as code rather than as an assertion.

{` // Demonstrates the [MS-NLMP] NTLMv2 response algorithm. // // The point: NTProofStr is a deterministic function of the NT-hash plus // values that travel in the clear or that the attacker controls. If you // possess the NT-hash, you can compute NTProofStr for any (challenge, // client_challenge, timestamp, av_pairs). That is the protocol-level // proof of password-equivalence. // // In a real client, NT-hash = MD4(UTF-16LE(password)). MD4 is removed from // most modern browser/Node crypto providers, so we use a precomputed // NT-hash for password "Summer2026!" and focus on the structural property // that matters: knowledge of those 16 bytes is sufficient forever.

const crypto = require("crypto");

// Precomputed NT-hash for password "Summer2026!" (16 bytes, hex): // reference value verified against impacket's NTOWFv1() helper offline. const ntHash = Buffer.from("41aed72cec76816423703d8e545eea31", "hex");

const user = "alice", domain = "CONTOSO";

// NTOWFv2 = HMAC-MD5(NT-hash, UNICODE(Upper(user) || domain)) const userDomain = Buffer.from((user.toUpperCase() + domain), "utf16le"); const ntowfv2 = crypto.createHmac("md5", ntHash).update(userDomain).digest();

// NTProofStr = HMAC-MD5(NTOWFv2, ServerChallenge || temp) // where temp = ResponserVersion(0x01) || HiResponserVersion(0x01) || Z(6) || // Time(8) || ClientChallenge(8) || Z(4) || ServerName || Z(4) const serverChal = Buffer.from("0123456789abcdef", "hex"); const clientChal = Buffer.from("fedcba9876543210", "hex"); const ts = Buffer.alloc(8); // any 8-byte FILETIME const serverName = Buffer.from("00000000", "hex"); // empty AV_PAIR list const tempBuf = Buffer.concat([ Buffer.from("0101000000000000", "hex"), // version 1.1 || Z(6) ts, clientChal, Buffer.from("00000000", "hex"), // Z(4) serverName, Buffer.from("00000000", "hex"), // Z(4) ]); const ntProofStr = crypto.createHmac("md5", ntowfv2) .update(Buffer.concat([serverChal, tempBuf])).digest();

console.log("NT-hash :", ntHash.toString("hex")); console.log("NTOWFv2 :", ntowfv2.toString("hex")); console.log("NTProofStr :", ntProofStr.toString("hex")); console.log(""); console.log("Now change serverChal/clientChal/ts and rerun: NTProofStr changes,"); console.log("but only the first line of input (the NT-hash) is a secret. The"); console.log("rest travels in the clear inside the three NTLM messages. Possessing"); console.log("ntHash IS possessing the credential -- forever, on every server."); `}

The demo prints three lines, then a punchline. The lines are not impressive; the punchline is.

Key idea: The NT-hash is not a credential; it is the credential. Knowing the hash IS authentication. Every pass-the-hash tool ever written, from Paul Ashton's modified Samba in 1997 to the present, is a different packaging of the same realisation: an authentication that is a deterministic function of a static secret turns possession of that secret into permanent authority [@wp-pass-the-hash].

If possession of the hash is the protocol, the last 28 years of attacks are not surprises -- they are obvious next steps. What are those steps?

4. The Three-Decade Attack Cascade

Five generations of attacks. Each one is named, each one is dated, each one took Microsoft years to respond to, and each Microsoft response always closed the primitive and left the class alive. They are not five surprises; they are five logical consequences of the wire protocol you just read.

Generation 1 -- 1997: Pass-the-Hash (Paul Ashton)

The first published exploit of password-equivalence comes from Paul Ashton, posted to the Bugtraq mailing list in 1997. Ashton ships a patch against the Samba SMB client that takes a 16-byte NT-hash directly on the command line, instead of asking for a cleartext password [@wp-pass-the-hash]. The patch is a one-paragraph change against an open-source codebase, and that fact -- the brevity of the change -- is the lesson.

The NTLM response function has no input that depends on knowing the plaintext password. Replacing the plaintext-password input with a literal NT-hash input does not change the bytes that go on the wire. The server cannot tell the difference.

Microsoft's response, for more than a decade, is do not lose your hashes. There is no protocol fix because there is no protocol bug to fix; the design is doing exactly what it was designed to do. The response is operational guidance: tier your admins, scrub LSASS, do not run privileged sessions on workstations.

Generation 2 -- 2001: NTLM Relay (Sir Dystic / SMBRelay)

If you do not have to steal the hash to use the credential, you also do not have to steal the live exchange. You can simply relay it. On March 31, 2001, at the @lanta.con conference, Sir Dystic of the Cult of the Dead Cow (Josh Buchbinder) releases SMBRelay: a small program that accepts an SMB connection on port 139, opens a second SMB connection back to another server, and shuttles the NEGOTIATE / CHALLENGE / AUTHENTICATE messages between the two sides [@cdc-smbrelay].

The attack works because the three NTLM messages are not bound to a particular client, server, or service. Whoever sits between them can replay the credential against whatever destination the attacker chooses, as that user, for the duration of the exchange.The colourful provenance matters. The Cult of the Dead Cow released SMBRelay alongside Back Orifice 2000; "Sir Dystic" is the same Josh Buchbinder who later wrote the SMBProxy authentication-relay framework. The point is not the chrome -- it is that the relay class was disclosed publicly at a conference in 2001, with working code on the cDc website, and Microsoft did not ship a fix for the trivial case (self-relay) until November 2008 [@cdc-smbrelay].

Microsoft's response is incomplete and slow. SMB signing exists from Windows 2000 onward, but it is off by default on member servers for more than a decade [@ms-smb-signing]. MS08-068, in November 2008, finally patches the self-relay case (CVE-2008-4037): the SMB server now refuses to accept an authentication that the client itself just generated against the same server [@nvd-cve-2008-4037]. NVD notes that reliable sources report the original fix as insufficient for CVE-2000-0834 -- meaning the patch closed exactly the self-relay case and nothing else [@nvd-cve-2008-4037]. Seven years to fix the simplest variant; the cross-server relay class is still wide open.

Generation 3 -- 2008-2014: Credential Theft as a Service

By 2008, the operational guidance "do not lose your hashes" stops being defensible. On February 29, 2008, Hernan Ochoa releases the Pass-the-Hash Toolkit v1.3, two native Windows binaries called iam.exe and whosthere.exe that read the NT-hash out of LSASS memory and inject it into a new logon session. PtH stops being a Linux-and-Samba trick and becomes a Windows-everywhere reality.

Three years later, Benjamin Delpy publishes Mimikatz. The first version is closed-source, released in May 2011 [@wired-greenberg-mimikatz]. By April 6, 2014, the GitHub repository goes public with the version string "mimikatz 2.0 alpha (x86) release 'Kiwi en C' (Apr 6 2014 22:02:03)" [@gh-mimikatz]. The repo description is a near-perfect summary of what LSASS is to an attacker: "extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets" [@gh-mimikatz]. LSASS becomes the universal credential oracle.Delpy did not intend Mimikatz to be a weapon. Wired's Andy Greenberg documents the trajectory in detail: Delpy "released it publicly in May 2011, but as a closed source program." In mid-2011, Delpy learned for the first time that Mimikatz had been used in an intrusion of an unnamed foreign government network. That September, it appeared again in the landmark DigiNotar hack. An unidentified man was found at his laptop in his Moscow conference hotel room -- the stranger apologised and quickly left, claiming a wrong room. A second man in a dark suit later demanded a copy of Mimikatz on a USB drive. He went open-source partly fearing for his own safety after the hotel confrontations, and partly to make the security industry confront what lived in LSASS [@wired-greenberg-mimikatz].

Microsoft's response is structural and specific. Credential Guard ships in Windows 10 RTM (Enterprise and Education editions), July 29, 2015 [@ms-credential-guard]. It uses Virtualization-Based Security to isolate lsaiso.exe in VTL1 within the same root partition; the kernel can no longer read NTLM hashes or Kerberos TGTs even at SYSTEM-level privilege. Protected Users and Restricted Admin in Server 2012 R2 / Windows 8.1 narrow the surface further. LSASS-as-PPL adds a process-protection layer between user-mode debuggers and the LSASS address space [@ms-credential-guard].

Credential Guard works -- against the credential-theft class. It does nothing against credential-use. An attacker who never extracts a hash, because they never need to, sails right past it. Relay does not need the hash. Coercion does not need the hash. ESC8 does not need the hash. That is the next generation.

Generation 4 -- 2018-2021: Forced-Authentication Coercion

In 2018 at DerbyCon 8, Lee Christensen releases SpoolSample, known publicly as "PrinterBug." The GitHub description is exact: "PoC tool to coerce Windows hosts authenticate to other machines via the MS-RPRN RPC interface" [@gh-spoolsample]. The trick is that the Print Spooler service runs as SYSTEM, accepts a remote RPC call (RpcRemoteFindFirstPrinterChangeNotificationEx) that takes a UNC path, and dutifully NTLM-authenticates back to whatever path the caller named -- on behalf of the machine account. Any Windows service running as SYSTEM that accepts a UNC path is a confused deputy that will authenticate on demand.

Microsoft's initial classification of SpoolSample was *authenticated-only / by design*: a caller needed valid domain credentials to reach the spooler endpoint, and authenticated callers triggering machine-account authentications was deemed within spec. The classification held through 2018, 2019, and most of 2020. PetitPotam broke it, because PetitPotam used MS-EFSRPC over LSARPC, which accepts *unauthenticated* binds on a domain controller's named-pipe interface. With the authentication requirement gone, "by design" stopped being a coherent defence. Microsoft started shipping fixes.

Marina Simakov and Yaron Zinar of Preempt (now CrowdStrike) publish "Drop the MIC" on June 11, 2019. The vulnerability is CVE-2019-1040: a tampering bug where "a man-in-the-middle attacker is able to successfully bypass the NTLM MIC (Message Integrity Check) protection" [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]. The bypass works by stripping the NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_ALWAYS_SIGN flags from the initial NEGOTIATE, removing the MIC field from AUTHENTICATE, and removing the Version field that drives MIC detection.

Servers that should have required a MIC silently accept the modified message. The MIC -- the retrofit integrity layer that was supposed to make tampering detectable -- turns out to be itself untethered to the negotiation [@crowdstrike-drop-the-mic].

Lionel Gilles (topotam77) publishes PetitPotam in July 2021, CVE-2021-36942. The GitHub repository description reads: "PoC tool to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw or other functions". The decisive new property compared to SpoolSample is that PetitPotam needs no credentials against a domain controller: LSARPC accepts unauthenticated binds, so the coercion can be triggered by an attacker who has merely joined the network.

In 2022, Remi Gascou (p0dalirius) publishes Coercer, a Python script that consolidates the coercion class across MS-RPRN, MS-EFSR, MS-DFSNM, MS-FSRVP, and many more RPC interfaces. The README describes it succinctly: "A python script to automatically coerce a Windows server to authenticate on an arbitrary machine through many methods" [@gh-coercer].

Generation 5 -- 2021: ADCS Web-Enrollment Relay (ESC8)

On June 17, 2021, Will Schroeder and Lee Christensen of SpecterOps publish "Certified Pre-Owned," a whitepaper and matching blog post that maps eight new attack classes against Active Directory Certificate Services [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]. ESC1 through ESC7 are template and configuration weaknesses. ESC8 is the keystone of this article.

ESC8 says: AD CS Web Enrollment endpoints (/certsrv/) accept NTLM authentication. Coerce a server's machine account to authenticate to your relay listener; relay the authentication to /certsrv/; enroll the relayed identity for a machine-template certificate; use that certificate to perform PKINIT against the KDC and request a TGT [@specterops-cert-preowned-blog]. The NTLM-vs-Kerberos boundary stops being a meaningful one. NTLM is the protocol on the front side of the attack; Kerberos is the trust token on the back side; the certificate is the conduit between them.

The point of ESC8 is not just that it works. The point is that it works against a perfectly retrofitted environment. SMB signing did not enter the chain. LDAP signing did not enter the chain. EPA was supposed to enter the chain on the /certsrv/ side but was unevenly deployed. Credential Guard never had a hash to protect.

flowchart TD A[Gen 1 -- 1997 Pass-the-Hash
Paul Ashton, modified Samba] A --> A1[Response: operational guidance
Do not lose your hashes] A1 --> B[Gen 2 -- 2001 SMBRelay
Sir Dystic, atlanta.con] B --> B1[Response: MS08-068 2008
Patches self-relay only] B1 --> C[Gen 3 -- 2008-2014 LSASS extraction
Ochoa PtH Toolkit, Delpy Mimikatz] C --> C1[Response: Credential Guard 2015
Closes theft; not use] C1 --> D[Gen 4 -- 2018-2021 Coercion
SpoolSample, Drop-the-MIC, PetitPotam, Coercer] D --> D1[Response: KB 5005413, EPA
Closes primitive; not class] D1 --> E[Gen 5 -- 2021 ESC8
Schroeder/Christensen Certified Pre-Owned] E --> E1[Response: remove NTLM] sequenceDiagram autonumber actor A as Attacker participant V as "Victim SYSTEM service (Spooler, EFSR, DFSNM)" participant R as Attacker NTLM relay participant T as "Target service (LDAP, SMB, certsrv)" A->>V: RPC call with UNC path \\attacker\share V->>R: NTLM NEGOTIATE (as machine account) R->>T: Open new authenticated session T->>R: NTLM CHALLENGE R->>V: Forward CHALLENGE V->>R: NTLM AUTHENTICATE (signed by machine account) R->>T: Forward AUTHENTICATE -- T treats attacker session as the victim

Generation	Primitive	Public date	Microsoft response	What survived
1. Pass-the-Hash	Use the hash directly	1997, Paul Ashton, Bugtraq [@wp-pass-the-hash]	Operational guidance	Hash is still password-equivalent on the wire
2. NTLM relay (SMB)	Forward live exchange	March 31, 2001, Sir Dystic, @lanta.con [@cdc-smbrelay]	MS08-068 (Nov 2008) -- self-relay only [@nvd-cve-2008-4037]	Cross-server, cross-protocol relay
3. LSASS extraction	Steal hashes from memory	Feb 2008 (Ochoa); May 2011 closed / Apr 2014 open (Delpy) [@gh-mimikatz, @wired-greenberg-mimikatz]	Credential Guard (Jul 29, 2015) [@ms-credential-guard]	Hash use outside LSASS path; SYSTEM-level Mimikatz on the SAM
4. Coercion	Make SYSTEM authenticate on demand	2018 SpoolSample [@gh-spoolsample]; 2019 Drop-the-MIC [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]; 2021 PetitPotam; 2022 Coercer [@gh-coercer]	Per-interface patches; KB 5005413 EPA recipe [@ms-kb5005413]	The pattern of "SYSTEM holds an unanchored credential"
5. ESC8 ADCS Web Enrollment relay	NTLM coerce -> /certsrv/ -> TGT via PKINIT	June 17, 2021, Schroeder/Christensen, "Certified Pre-Owned" [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]	KB 5005413; AD CS hardening; eventually Phase 3 of NTLM removal	Kerberos relay class on the other side (KrbRelay/KrbRelayUp) [@gh-krbrelayup]

KrbRelayUp -- a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings). -- Dec0ne, KrbRelayUp README [@gh-krbrelayup]

The reader who started Section 4 believing "if I patch each named NTLM attack, the protocol is safe" finishes Section 4 believing something else. Every retrofit patches a primitive; none addresses the existence of the fallback path. The next attack is always one cross-protocol step away. The retrofit strategy is structurally incapable of closing the class.

By the end of 2021, NTLM-the-protocol cannot be removed because four use cases require it, and NTLM-the-fallback cannot be kept because ESC8 turned it into a domain-takeover oracle. Something has to change. What?

5. The Retrofit Strategy and Its Funeral

Before naming the answer, name the strategy that failed. Microsoft's defensive cadence between 2001 and 2021 splits into three families, each effective against a named primitive, each defeated by an unanchored cousin of that primitive.

Family A -- Per-protocol message authentication

SMB signing. LDAP signing and sealing. The idea is to anchor the content of each authenticated request inside a per-session signature derived from the authentication. SMB signing introduces an HMAC over every SMB message keyed by a per-session SigningKey; LDAP signing and sealing do the equivalent for LDAP operations [@ms-smb-signing].

Family A works when the target protocol enforces it. SMB-to-SMB relay against an SMB server with required signing fails; LDAP-to-LDAP relay against an LDAP server with required signing fails. The strategy assumes the attacker stays in the same protocol family. Cross-protocol relay -- SMB authentication relayed to LDAP, or SMB authentication relayed to /certsrv/ -- defeats it. The MS-EFSR coercion can produce an authentication that originates "as if from SMB" and gets accepted by an unrelated HTTPS service that ignores the SMB signing flag entirely [@nvd-cve-2019-1040, @specterops-cert-preowned-blog].

Family B -- Per-channel binding tokens and the MIC

EPA (channel binding) and the NTLMv2 MIC are the response to cross-protocol relay. Both try to tie the authentication to the specific channel the client believes it is using. EPA places a hash of the TLS endpoint certificate into the MsvAvChannelBindings AV_PAIR; an HTTPS server with EPA required compares it to its own certificate's hash and rejects the authentication if they do not match [@ms-epa-wcf]. The MIC binds all three NTLM messages together so a relay cannot strip the signing-required flags from NEGOTIATE after the client sets them [@ms-nlmp].

Family B works when both ends agree to enforce. Drop-the-MIC (CVE-2019-1040) demonstrated that the presence of the MIC was negotiated and could be stripped, so a server that supported MIC-less clients silently accepted MIC-less messages from a relay [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]. EPA suffers from the same enforcement-asymmetry: when an IIS endpoint runs with policyEnforcement="None" or "Partial", the binding is not checked. KB 5005413 published the explicit <extendedProtectionPolicy policyEnforcement="Always" /> recipe for /certsrv/ because field deployments had been running with weaker settings [@ms-kb5005413].

Family C -- Credential isolation

Credential Guard. LSASS-as-PPL. Protected Users. Restricted Admin. These attack the theft surface. Credential Guard moves the NT-hash into lsaiso.exe inside VTL1; the kernel can no longer read it. Microsoft now ships it enabled by default on domain-joined, non-DC systems running Windows 11 22H2 and Server 2025 on hardware that meets the requirements [@ms-credential-guard].

Family C is honest about what it covers. It does nothing about coercion flows that never touch the NT-hash. PetitPotam and ESC8 do not need a hash; the relay session uses the live NTLM exchange and is never persisted. Credential Guard cannot help.

Family	What it closes	What it does not close	Defeating attack
A. Per-protocol message auth (SMB/LDAP signing)	Same-protocol relay against the target	Cross-protocol relay; targets that do not enforce	LDAP relay from SMB coercion [@nvd-cve-2019-1040]; ESC8 relay to /certsrv/
B. Channel binding (EPA) + MIC	Same-channel relay through TLS termination	MIC stripping in negotiation; EPA at None/Partial; non-TLS targets	Drop-the-MIC [@nvd-cve-2019-1040]; under-enforced EPA [@ms-kb5005413]
C. Credential isolation (Credential Guard, LSASS-PPL)	Hash theft from running LSASS	Hash use in live relay; SAM extraction from disk; coercion	ESC8 + PetitPotam [@specterops-cert-preowned-blog]; SAM hive offline [@ms-credential-guard]

Key idea: Every retrofit Microsoft has shipped against NTLM attacks one primitive of NTLM. None address the existence of NTLM as a fallback path. ESC8 was the funeral of the retrofit strategy because ESC8 turned a fully retrofitted environment into a domain takeover without defeating any retrofit.

Note: "Certified Pre-Owned" did not break a Microsoft fix; it composed the existing infrastructure. The chain assumes SMB signing is on, EPA is on (somewhere), and Credential Guard is on. It still works, because none of those controls cover the path that goes Coercer -> NTLM relay -> AD CS Web Enrollment -> PKINIT. After 2021, the question stopped being "what's the next retrofit?" and became "what does it take to remove the fallback?" [@specterops-cert-preowned-blog, @ms-kb5005413].

To remove ESC8 without rebuilding AD CS, Microsoft has to remove NTLM. To remove NTLM, Microsoft has to remove the four reasons NTLM existed as a fallback in the first place. What does that look like in shippable form?

6. The Breakthrough: Closing the Fallback

October 11, 2023. Matthew Palko, Windows IT Pro Blog. "The evolution of Windows authentication." For the first time in twenty-three years, Microsoft publicly commits to removing NTLM, not restricting it, and names the three load-bearing features that make removal possible [@palko-2023-evolution].

The plan starts where every honest plan starts -- by stating the problem in its own words. There are four fallback reasons NTLM persisted: no DC line-of-sight, no domain at all (local accounts), no SPN for the target, and hard-coded NTLM in application code [@palko-2023-evolution]. Each gets an engineered answer. The four-to-three correspondence (three protocols plus one refactor) is the new architecture.

Our end goal is eliminating the need to use NTLM at all to help improve the security bar of authentication for all Windows users. -- Matthew Palko, Microsoft Windows IT Pro Blog, October 11, 2023 [@palko-2023-evolution]

IAKerb -- closing "no DC line-of-sight"

IAKerb stands for Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. The IETF draft has a four-author list -- Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman -- and a quiet history [@draft-ietf-kitten-iakerb].

The premise is simple. A client wants to authenticate to an application server with Kerberos but cannot reach a KDC -- maybe the client is behind a firewall, maybe the KDC is only reachable from the server's side of a VPN. IAKerb wraps the Kerberos AS-REQ and TGS-REQ messages inside GSS-API tokens and asks the application server to proxy them to a KDC that the server can reach. The client never opens a direct TCP/UDP connection to a KDC; the application server acts as the carrier.

The honesty duty: IAKerb's IETF draft (`draft-ietf-kitten-iakerb`) was marked "Dead WG Document" on August 29, 2019, by Robbie Harwood [@draft-ietf-kitten-iakerb]. Harwood's note read, roughly, that IAKerb was historical at that point and the working group had no interest left. The last revision (`-03`) is from March 30, 2017, by Benjamin Kaduk. Microsoft is now reviving the protocol in 2023-2026 for Windows 11 and Windows Server 2025 -- without acknowledging the dead-WG status in its own blog posts. This is the gap between an IETF standards-track document and what a vendor ships; the article reports both [@draft-ietf-kitten-iakerb, @palko-2023-evolution]. Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. A GSS-API-wrapped Kerberos exchange in which the client cannot reach a KDC directly and the application server proxies `AS-REQ` / `TGS-REQ` on the client's behalf. Defined by `draft-ietf-kitten-iakerb` (IETF kitten WG, currently a Dead WG Document). MIT Kerberos has shipped IAKerb since 1.9 (released February 2011); Apple ships `GSS_IAKERB_MECHANISM` since macOS 10.14. Microsoft is implementing IAKerb in Windows 11 / Server 2025 [@draft-ietf-kitten-iakerb, @palko-2023-evolution, @ms-cuomo-ad2025].

Local KDC -- closing "no domain at all"

Local accounts in the machine SAM have never had a KDC. Workgroup machines have no domain at all. Both cases force NTLM today. The fix is conceptually trivial: run a tiny Kerberos KDC against the local SAM, exposed only through IAKerb-wrapped exchanges so the wire protocol is the same as the trust-traversing case [@palko-2023-evolution, @ms-cuomo-ad2025].

This is the late-adopter move that surprises Linux-side practitioners. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Samba has been working on a localkdc for years. At FOSDEM 2025 (February 2, 2025), Alexander Bokovoy and Andreas Schneider gave a talk explicitly framed as "localkdc -- a general local authentication hub" [@cryptomilk-localkdc]. Schneider's companion blog post the next week summarised the work: a parallel local-authentication hub for Linux that interoperates with the IAKerb wire format Windows is now adopting [@cryptomilk-localkdc].

A small Kerberos Key Distribution Center process that runs against a machine's local user database (the SAM on Windows; a file or sssd on Linux) and is exposed only through IAKerb. It lets local-account authentications use Kerberos under the same Negotiate / NEGOEX wire envelope used by domain authentications -- removing one of the four reasons NTLM persisted. Shipping in Windows 11 / Server 2025 [@palko-2023-evolution, @ms-cuomo-ad2025]; parallel Linux/Samba work coordinated under the FOSDEM 2025 `localkdc` umbrella [@cryptomilk-localkdc].

NEGOEX -- carrying IAKerb under the existing `Negotiate` API

You do not want to teach every application a new SSPI provider. Existing code calls AcquireCredentialsHandle("Negotiate", ...); that should keep working, and IAKerb should be one of the mechanisms Negotiate is willing to pick. The piece of plumbing that makes this possible is NEGOEX: SPNEGO Extended Negotiation [@ms-negoex, @draft-zhu-negoex].

NEGOEX adds a pair of meta-data messages on top of the standard SPNEGO NegTokenInit / NegTokenResp exchange, so that mechanisms (like IAKerb) that need a richer negotiation can ride inside the Negotiate envelope. The Microsoft Open Specification [MS-NEGOEX] is currently at revision 4.0 (April 23, 2024), with the original revision dated July 9, 2020 [@ms-negoex]. The expired Microsoft IETF draft draft-zhu-negoex from January 2011 is the historical anchor; four Microsoft authors -- Michiko Short, Larry Zhu, Kevin Damour, and Dave McPherson -- are listed verbatim in the draft metadata [@draft-zhu-negoex].

A correction is owed here. Scope notes inherited from earlier in this project cited "RFC 8143" as the NEGOEX standard. RFC 8143 is actually titled "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)" and updates RFC 4642; it has nothing to do with NEGOEX [@rfc-8143]. The correct primary references for NEGOEX are [MS-NEGOEX] and draft-zhu-negoex, both used consistently throughout this article [@ms-negoex, @draft-zhu-negoex].

The SPNEGO Extended Negotiation security mechanism. Adds a meta-data exchange inside the SPNEGO envelope so that richer mechanisms (like IAKerb) can be negotiated without changing the SSPI surface. Primary sources: Microsoft Open Specification `[MS-NEGOEX]` revision 4.0 (April 2024); expired IETF draft `draft-zhu-negoex` (January 2011). Despite a common scope-doc error, RFC 8143 is *not* NEGOEX; RFC 8143 is "Using TLS with NNTP" [@ms-negoex, @draft-zhu-negoex, @rfc-8143].

Negotiate-everywhere refactor -- closing "hard-coded NTLM"

The last fallback case is the most prosaic: application code that calls AcquireCredentialsHandleW(..., "Ntlm", ...) or RPC code that asks for RPC_C_AUTHN_WINNT. Both bypass Negotiate and force NTLM no matter what is on the wire. The fix is editorial -- audit Windows internals, replace each hard-coded Ntlm call with Negotiate -- and very large in surface area. Dan Cuomo's "Active Directory improvements in Windows Server 2025" post summarises the Windows Server Summit 2024 session in one sentence: "we have created completely new Kerberos features to minimize use of NTLM in your environments. This session explains and demonstrates IAKerb, Local KDC, IP SPN, and the roadmap to the end of NTLM" [@ms-cuomo-ad2025].

Fallback reason	Closure mechanism	Primary source	Ship target
No DC line-of-sight	IAKerb (GSS-wrapped Kerberos through the app server)	`draft-ietf-kitten-iakerb` (Dead WG, revived by Microsoft) [@draft-ietf-kitten-iakerb]	Windows 11 / Server 2025 [@palko-2023-evolution, @ms-cuomo-ad2025]
No domain at all (local accounts)	Local KDC over IAKerb	Palko 2023; Samba `localkdc` parallel [@palko-2023-evolution]	Windows 11 / Server 2025
No SPN	IP-SPN policy under Negotiate	`[MS-NEGOEX]`; Cuomo 2024 session [@ms-negoex, @ms-cuomo-ad2025]	Windows Server 2025
Hard-coded NTLM	Audit + replace `AcquireCredentialsHandle("Ntlm")` with `Negotiate`	Palko 2023 [@palko-2023-evolution]	Editorial, ongoing through Phase 2

flowchart LR R1[No DC line-of-sight] --> M1[IAKerb
draft-ietf-kitten-iakerb] R2[No domain at all
local accounts] --> M2[Local KDC
over IAKerb] R3[No SPN for target] --> M3[IP-SPN policy
under Negotiate] R4[Hard-coded NTLM
in app code] --> M4[Negotiate-everywhere
refactor] M1 --> N[NEGOEX
SPNEGO extension] M2 --> N M3 --> N N --> P[Negotiate SSPI
same call sites] sequenceDiagram autonumber participant C as Client (no KDC reach) participant S as Application server (KDC reach) participant K as KDC C->>S: SPNEGO NegTokenInit with NEGOEX MetaData, mechs=[Kerberos, IAKerb] S-->>C: NegTokenResp, server picks IAKerb C->>S: IAKerb token wrapping AS-REQ S->>K: AS-REQ K-->>S: AS-REP S-->>C: IAKerb token wrapping AS-REP -> client now has TGT C->>S: IAKerb token wrapping TGS-REQ for service ticket S->>K: TGS-REQ K-->>S: TGS-REP (service ticket) S-->>C: IAKerb token wrapping TGS-REP Note over C,S: From now on, ordinary AP-REQ / AP-REP over Kerberos -- no NTLM needed

What does this mean for Linux and macOS clients in a Windows domain? IAKerb is a GSS-API mechanism, and MIT's krb5 library shipped IAKerb in 1.9 (released February 2011) -- well before Microsoft. Apple's Heimdal-derived GSS framework has shipped GSS_IAKERB_MECHANISM since macOS 10.14 (Mojave, 2018). The cross-platform interoperability story is therefore better in 2026 than it has been in years: a Linux client using MIT 1.9+ or an Apple client using macOS 10.14+ can already speak IAKerb to a Windows Server 2025 Local KDC. The parallel Samba localkdc effort closes the symmetric case: a Linux machine acting as the IAKerb server [@cryptomilk-localkdc].

The reader who started Section 6 believing "NTLM is too entrenched to remove" finishes Section 6 believing something else. The entrenchment is exactly four named cases, and each one has been given an engineered answer. Removal is now a sequencing problem, not an architecture problem.

The engineering existed by October 2023. The shipping commitment came in January 2026. What is Microsoft actually shipping, and on what schedule?

7. The Three-Phase Roadmap

January 29, 2026. The Windows IT Pro Blog publishes "Advancing Windows security: Disabling NTLM by default" under the byline mariam_gewida [@gewida-2026-disabling]. The post documents Microsoft's published roadmap and opens with a caveat that the rest of this article works hard not to forget.

Note: "Disabling NTLM by default does not mean completely removing NTLM from Windows yet... during phase 3, NTLM will remain present in the OS and can be explicitly re-enabled via policy if you still need it." -- mariam_gewida, "Advancing Windows security: Disabling NTLM by default," Microsoft Windows IT Pro Blog, January 29, 2026 [@gewida-2026-disabling]

The plan has three phases. They are sequenced; each phase produces the inputs the next phase needs.

Phase 1 (now) -- Audit

Phase 1 is auditing. The deliverable is enhanced NTLM logging in Windows 11 24H2 and Windows Server 2025, documented in KB 5064479 (published July 11, 2025) [@ms-kb5064479]. The new logging surface is Applications and Services Logs > Microsoft > Windows > NTLM > Operational, gated by two GPOs called "NTLM Enhanced Logging" and "Log Enhanced Domain-wide NTLM Logs." For each NTLM authentication, the event tells the administrator three things: who called (the process), why (the negotiated SSPI provider chose NTLM), and where (the target service). The KB also names per-event warning classes for NTLMv1, MIC-less, and EPA-not-supported authentications [@ms-kb5064479].

Phase 1 also closes the oldest residual: NTLMv1. Microsoft's deprecation page added an NTLM entry in June 2024 with verbatim language: "All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated. Use of NTLM will continue to work in the next release of Windows Server and the next annual release of Windows. Calls to NTLM should be replaced by calls to Negotiate" [@ms-deprecated-features].

The same row adds: "NTLMv1 is removed starting in Windows 11, version 24H2 and Windows Server 2025" -- the November 2024 update note [@ms-deprecated-features]. The KB 4090105 pre-24H2 NTLMv1 auditing surface (Event ID 4624 with Package Name (NTLM only): NTLM V1) remains valid for legacy environments [@ms-ntlmv1-dc-audit].

Phase 2 (H2 2026) -- IAKerb + Local KDC + Negotiate-first refactor in pre-release

Phase 2 puts the engineered closures from Section 6 into pre-release. IAKerb and Local KDC ship for Windows Insiders and Server preview channels. The Negotiate-first refactor lands -- Microsoft's own subsystems audit their AcquireCredentialsHandleW("Ntlm", ...) and RPC_C_AUTHN_WINNT call sites and replace them with Negotiate calls. Per-machine policy controls for NTLM scope make finer-grained restriction possible. IP-SPN policy lands so the "no SPN" case can be closed without naming every server by FQDN [@gewida-2026-disabling, @ms-cuomo-ad2025].

The Microsoft outreach mechanism for Phase 2 is the ntlm@microsoft.com mailbox; the January 2026 post names it explicitly as the channel for surfacing cross-forest, federated, and ISV-edge cases that need engineering help before Phase 3 [@gewida-2026-disabling].

Phase 3 (next major Windows / Windows Server release) -- Disabled by default

Phase 3 is the default-off flip. Network NTLM authentication is disabled by default in the next major Windows and Windows Server release. The disablement is a configuration, not a binary removal: NTLM remains in the OS, callable through Negotiate only when a policy explicitly re-enables it for a named scope [@gewida-2026-disabling]. The Hacker News' summary of the roadmap published February 2026 documents the same three-phase structure for industry-press consumption [@thn-2026-ntlm-phaseout].

flowchart LR P1[Phase 1 -- NOW
KB 5064479 enhanced auditing
NTLMv1 removed in 24H2 / WS2025] --> P2 P2[Phase 2 -- H2 2026
IAKerb + Local KDC pre-release
Negotiate-first refactor
Per-machine NTLM scope policy] --> P3 P3[Phase 3 -- next major Windows
Network NTLM disabled by default
Re-enablement requires explicit policy]

Phase	Deliverable	Date / target	Prerequisite	Primary
Phase 1	Enhanced NTLM auditing	KB 5064479, July 11, 2025	Windows 11 24H2 / Server 2025	[@ms-kb5064479]
Phase 1	NTLMv1 removal	Windows 11 24H2 / Server 2025, November 2024	NTLM family deprecation (June 2024)	[@ms-deprecated-features]
Phase 2	IAKerb + Local KDC pre-release	H2 2026, Windows Insider channel	Phase 1 audit data identifies callers	[@gewida-2026-disabling, @ms-cuomo-ad2025]
Phase 2	Negotiate-first refactor of Windows subsystems	H2 2026	Phase 1 audit data	[@palko-2023-evolution, @gewida-2026-disabling]
Phase 2	IP-SPN policy for "no SPN" case	Windows Server 2025 + flighting	NEGOEX in Negotiate	[@ms-cuomo-ad2025]
Phase 3	Network NTLM disabled by default	Next major Windows / Server release	All Phase 2 features GA	[@gewida-2026-disabling]

Phase 3 is the first default configuration in 30 years that does not include NTLM. It is not the first configuration in 30 years without authentication-relay attacks. Why not?

8. What Disabling NTLM Cannot Buy You

A blunt section. Phase 3 is real progress. It is not the end of authentication attacks on Windows. Three structural ceilings survive the transition; the article will not pretend otherwise.

Disabled is not removed

Phase 3 still ships NTLM in the OS. The default is off; the policy lockout is exactly as strong as the domain's tier-0 administrative segregation, not stronger. An attacker who reaches a domain controller with Group Policy edit rights can flip the policy and re-enable NTLM for the scope they want. The wording in the January 2026 post is precise: "during phase 3, NTLM will remain present in the OS and can be explicitly re-enabled via policy if you still need it" [@gewida-2026-disabling].

This is the design choice Microsoft has to make, because removing NTLM binaries entirely would brick every third-party application that hard-codes Ntlm and every legacy device that has not been firmware-updated since 2018. "Disabled by default with policy override" is the only configuration that has any chance of getting deployed.

Kerberos has its own relay class

The relay class does not depend on NTLM. KrbRelay, KrbRelayUp, RBCD abuse, unconstrained-delegation abuse, S4U2Self / S4U2Proxy chains -- the entire taxonomy survives the move to Kerberos with different named primitives. Dec0ne's KrbRelayUp README, quoted at the end of Section 4, calls the class a universal no-fix local privilege escalation; the rest of the README enumerates the LDAP-signing default and the RBCD primitive that drive the post-NTLM relay surface [@gh-krbrelayup].

What changes is the protocol. What does not change is that an application server that receives an authenticated message without enforcing message integrity or channel binding can be coerced into accepting an attacker-relayed authentication. The named primitives change. The class survives.

Local SAM hashes remain password-equivalent

The Local KDC reads the SAM. An attacker with SYSTEM-level access to the same machine reads the SAM too. Once they have the hash in hand, they can either feed it to a Local KDC running on a machine they control, or they can attempt offline cracking. IAKerb does not change either of those facts; what it changes is whether the wire exposes the password-equivalent secret. Defence in depth -- TPM-backed key wrapping, Credential Guard for VBS isolation of process credentials, BitLocker for the cold-boot scenario -- remains necessary [@ms-credential-guard].

Key idea: Phase 3 is a transition between tradeoffs, not a transition out of them. The exit from NTLM-the-protocol is not the exit from the authentication-relay class, or from the chip-layer credential class. The arc closes one specific 30-year-old attack surface and opens different conversations about the next.

If the structural classes survive, what practical problems remain that an administrator should worry about between today and Phase 3?

9. Open Problems and the 2026-2027 Edge

Five named problems sit between Phase 1 (now) and Phase 3 GA. Each one has a primary source and a "best partial result" available today.

ESC8 field deployment of EPA on /certsrv/ is uneven. Microsoft published KB 5005413 on July 23, 2021 with the dispositive recipe: <extendedProtectionPolicy policyEnforcement="Always" /> on every /certsrv/ virtual directory, plus disabling plain HTTP. Server 2025 hardening pushes EPA to required-by-default in many AD CS templates. Many environments are not on Server 2025 yet, and CISA's Known Exploited Vulnerabilities catalog still lists CVE-2021-36942 as actively exploited. CVE-2022-26925 ("Windows LSA Spoofing Vulnerability") is the LSARPC NTLM-relay variant that emerged after the initial PetitPotam patches; it is on the same KEV list [@ms-kb5005413].
Third-party and legacy-app hard-coded NTLM. Microsoft's Negotiate-everywhere refactor covers Microsoft's own code. Independent software vendors must do the same audit for theirs. Phase 1's enhanced auditing surface (KB 5064479) is the practical instrument for identifying the callers: every NTLM authentication carries the calling process name and a reason code [@ms-kb5064479]. The post-Phase-3 default-off configuration will surface these as outages on any environment that has not run the audit first.
Cross-forest and federated IAKerb edges. Single-forest IAKerb is well-defined. Multi-forest, federated, and partner-trust scenarios get implementation-defined quickly: NEGOEX has to carry IAKerb tokens through Negotiate across trust boundaries where the proxying server may not be in the same forest as the KDC. Microsoft's ntlm@microsoft.com outreach mailbox exists precisely to surface these edge cases before Phase 3 [@draft-ietf-kitten-iakerb, @gewida-2026-disabling].
Linux and macOS parallel. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Apple ships GSS_IAKERB_MECHANISM since macOS 10.14. The Samba and localkdc effort from Bokovoy and Schneider (FOSDEM 2025) is the parallel open-source path: a Linux machine that can act as the IAKerb application server for a Windows client, or vice versa, under the same Negotiate envelope [@cryptomilk-localkdc]. The interoperability story should be better in 2026-2027 than it has been in twenty years.
Policy pressure. EU NIS2 mandates cybersecurity risk-management measures for entities in critical sectors; the Cyber Resilience Act adds mandatory security requirements for products with digital elements. Both frameworks make legacy authentication a documented compliance concern. Deprecation of NTLM under Microsoft's own deprecation page (ms-deprecated-features) gives a clean audit surface that did not exist before; an organisation can point to KB 5064479 audit data showing NTLM call sites with named callers and target services, and demonstrate progress on retirement [@ms-deprecated-features].The EU regulatory framing here is touched lightly because the primary texts (NIS2 Directive, Cyber Resilience Act) are extensive regulatory documents this article does not quote verbatim beyond the European Commission's official summaries. The relevant connection is operational: deprecation pages and audit logs give compliance teams an artifact for "we are retiring this class of credential under a published deprecation," which is the kind of evidence regulators ask for.

All five problems converge to one question for the AD engineer reading this article: what should I do this quarter?

10. What an AD Engineer Should Do This Quarter

Six numbered actions, ordered by impact. No filler, no compliance boilerplate.

Note: This is the prerequisite. Without Who/Why/Where data, Phase 3 surfaces breakage as outage. Enable the "NTLM Enhanced Logging" and "Log Enhanced Domain-wide NTLM Logs" GPOs on every domain controller and member server you operate. Subscribe to the Applications and Services Logs > Microsoft > Windows > NTLM > Operational channel. Identify every process that initiates NTLM, the reason Negotiate declined Kerberos, and the target service. Triage by call volume and criticality [@ms-kb5064479].

Note: Set LDAPClientIntegrity = 2 and LdapEnforceChannelBinding = 2 on every domain controller. This closes SMB-to-LDAP relay regardless of whether the originating authentication was NTLM or Kerberos. KrbRelayUp's existence makes this more urgent post-NTLM, not less: the relay class on Kerberos uses the same un-anchored LDAP target [@gh-krbrelayup].

Note: The KB 5005413 recipe is verbatim: add <extendedProtectionPolicy policyEnforcement="Always" /> to the authentication element of the IIS virtual directory and disable plain HTTP. /certsrv/ is the dispositive ESC8 target. Web Enrollment proxy endpoints (/certenroll/, /adpolicyprovider_cep_kerberos/ and similar) are the second tier. Audit every IIS authentication endpoint in the estate and confirm policyEnforcement="Always" is the value, not "None" or "Partial" [@ms-kb5005413].

Note: The Print Spooler service is the single highest-impact MS-RPRN coercion surface. Disabling Spooler on every server that does not actually print closes the entire RpcRemoteFindFirstPrinterChangeNotificationEx coercion class on those hosts. Microsoft's hardening guidance and the PrintNightmare disclosures (2021) made this an explicit recommendation [@gh-spoolsample].

Note: Coercer's scan mode is the canonical defensive auditing tool: it inventories which RPC coercion methods a given server still answers. Run it against every server you operate, in scan mode. The output is a list of unauthenticated and authenticated coercion endpoints to either patch, disable, or compensate around. Treat unauthenticated endpoints (LSARPC, \PIPE\lsarpc) as P0 [@gh-coercer].

Note: Microsoft's preferred sequence: Windows Insider flighting -> pilot non-production NTLM-off configurations -> identify hard-coded Ntlm SSPI calls in your in-house code -> stage Phase-3 rollout against your audit data. If you wait, the cut-over surfaces breakage as outage. If you audit, the cut-over is uneventful [@gewida-2026-disabling].

The Phase 1 audit is the load-bearing piece. Action 1 produces the data that makes Actions 2-6 prioritise correctly. The following snippet sketches the audit-event query logic an administrator would express in PowerShell -- the JavaScript runs the same logic so you can think through edge cases interactively.

{` // Sketch of the triage logic an administrator would run against // "Applications and Services Logs > Microsoft > Windows > NTLM > Operational" // after enabling the KB 5064479 enhanced auditing GPOs. The point of running // this in JavaScript is to make the rules explicit so you can think through // edge cases without standing up a Windows event channel.

const sampleEvents = [ { process: "C:\\app\\legacy.exe", reason: "NoSPN", target: "ldap/dc01.example.local", count: 142 }, { process: "C:\\Program Files\\Backup\\agent.exe", reason: "ExplicitNtlm", target: "cifs/backup02.example.local", count: 9 }, { process: "C:\\Windows\\System32\\spoolsv.exe", reason: "NoDcReach", target: "cifs/attacker.example.local", count: 1 }, { process: "C:\\Windows\\System32\\lsass.exe", reason: "LocalAccount", target: "host\\WORKGROUP-PC01", count: 38 }, { process: "C:\\Windows\\System32\\svchost.exe", reason: "NoSPN", target: "host/aliased.example.local", count: 7 }, ];

for (const row of triage(sampleEvents)) { console.log(`[${row.severity.toUpperCase()}] ${row.process}`); for (const a of row.actions) console.log(" -> " + a); } `}

Note: - LMCompatibilityLevel = 5 without audit. Forcing NTLMv2-only on every DC is correct as an endpoint, but flipping it without first running KB 5064479 audit will outage legacy applications that still attempt NTLMv1 [@ms-kb5064479]. - RestrictNTLM:Deny without exceptions. The Restrict NTLM family of GPOs supports per-server exemptions. Going straight to Deny without an exemption list is the classic outage path. - EPA on HTTPS-only while leaving plain HTTP enabled. KB 5005413 explicitly requires both policyEnforcement="Always" and disabling plain HTTP on /certsrv/. Leaving HTTP up makes the EPA enforcement moot [@ms-kb5005413]. - Trusting Credential Guard against coercion. Credential Guard protects against credential theft. It does not protect against ESC8, PetitPotam, or any other relay-of-live-authentication chain [@ms-credential-guard].

On a non-production Windows 11 Insider machine, the per-machine NTLM scope policy lives under `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`. Microsoft's pre-release documentation will name the value used to gate the Phase 2 IAKerb / Local KDC behaviours; consult the Windows Insider release notes that ship with the Phase 2 flight rather than hard-coding a value here -- the keys are subject to change up to GA. Use the `ntlm@microsoft.com` outreach channel for any environment-specific question [@gewida-2026-disabling].

This is the work. The Phase 3 deadline is the next major Windows release; the Phase 1 audit window is right now. If you wait, the cut-over surfaces breakage as outage. If you audit, the cut-over is uneventful.

11. Frequently Asked Questions

No. NTLMv2 is the version Drop-the-MIC, PetitPotam, and ESC8 all attack [@nvd-cve-2019-1040, @specterops-cert-preowned-blog]. The HMAC-MD5 response is strong against the response side, but the password-equivalence of the NT-hash and the lack of binding to the underlying transport are the structural properties every modern attack exploits. NTLMv2 is the *least bad* NTLM, not a safe NTLM. Phase 1 controls let you *audit*. Phase 2 features (IAKerb, Local KDC, IP-SPN, the Negotiate refactor) are what make disabling *survivable* for most organisations. If you go straight to `RestrictNTLM:Deny` without running the KB 5064479 audit first, you will outage legacy applications and possibly your help-desk laptops. The honest answer is: audit now, pilot Phase 2 in H2 2026, default-off at Phase 3 [@gewida-2026-disabling, @ms-kb5064479]. No. Credential Guard fixes credential *theft* from LSASS. It does nothing about credential *use* (relay), coercion (PetitPotam), or cross-protocol chains (ESC8). It is necessary -- ESC8 + Mimikatz is worse than ESC8 alone -- but it is not sufficient against the relay class [@ms-credential-guard]. No. KrbRelay and KrbRelayUp demonstrate the relay *class* survives on Kerberos. What changes is the named primitives, not the existence of relay. Defence is the same shape after Phase 3 as before: LDAP signing and channel binding everywhere, EPA enforced on every authentication endpoint, message integrity required at every level [@gh-krbrelayup]. Because the four fallback reasons (no DC, local accounts, no SPN, hard-coded NTLM) had no engineered answer until IAKerb, Local KDC, NEGOEX, and the Negotiate refactor existed in shippable form. The standards work, the IETF drafts (one of which was marked Dead WG Document in 2019 and is being revived), the MIT 1.9 parity, and the Apple precedent all had to exist before Microsoft had a credible removal path that did not break enterprise deployments [@palko-2023-evolution, @draft-ietf-kitten-iakerb]. Yes. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Apple ships `GSS_IAKERB_MECHANISM` since macOS 10.14 (Mojave, 2018). The Samba `localkdc` effort from Bokovoy and Schneider (FOSDEM 2025) is the parallel open-source path for a Linux local KDC. Heterogeneous Windows-domain estates with Linux file servers and macOS clients are positioned to interoperate with Phase 3 *better* than they did with NTLMv2 [@cryptomilk-localkdc].

NTLM was the answer to a 1987 problem and a 1993 problem. It survived because removing it required engineering four orthogonal capabilities that did not exist. They exist now. The next major Windows release ships without it on by default. The attacks that follow it -- KrbRelayUp, RBCD chains, S4U2Self abuse, certificate-template misconfiguration -- target a different protocol with a different vocabulary. The relay class persists. The protocol it targets is no longer NTLM.

If you read this article as part of a sequence, the prior pieces cover the access-control model (SeAccessCheck and its inputs), the chip-layer credential story (TPM, Pluton, Credential Guard, BitLocker), and the application-identity layer (Authenticode, signed binaries, AppLocker, smart application control). NTLM removal is one strand of the broader move from "trust the perimeter" to "tie every credential to a token, a chip, or a Kerberos ticket whose lifetime you can name." Each strand by itself is incomplete; together they are how the next decade of Windows authentication looks.