Parag Mali - tag: ntlm

Five Ways Windows Authentication Breaks: A Machine-Checked Tour -- and Why Finding Nothing New Is the Point

noreply@paragmali.com (Parag Mali) — Fri, 12 Jun 2026 00:00:00 GMT

Twenty-three Windows `[MS-*]` authentication protocols, machine-checked in the Tamarin prover under one network ("Dolev-Yao") adversary, each as a flawed/fixed pair reproducing a known, published break -- turned up **zero new vulnerabilities**. That is the point. Nearly every Windows-auth failure within symbolic reach collapses into **five recurring structural patterns**: missing channel binding, keyed-vs-unkeyed integrity, symmetric-credential reflection, identity-binding gaps, and delegation or composition failure. Deepening the models proved *positive* guarantees too -- forward secrecy and key-compromise-impersonation resistance for PKINIT-DH and IKE, hybrid post-quantum transcript binding, Silver-Ticket containment. The catch, and the honest core, is the **symbolic/computational boundary**: a perfect-crypto model sees protocol *logic*, not the probabilistic flaws (like Zerologon's zero-IV) that live one layer down.

1. Was Kerberos Broken, or Did It Just Look Broken?

In 2014, a domain user could become a domain administrator by changing a single field in a Kerberos ticket [@cve-2014-6324]. Not by breaking any cryptography. The attacker built a Privilege Attribute Certificate that claimed membership in the administrators group, signed it with a checksum that needed no secret key, and handed it to the domain controller. The controller checked the signature, found it valid, read the forged groups, and issued back a ticket carrying full administrative authority [@cve-2014-6324]. Microsoft shipped MS14-068, the hole closed, and the penetration testers moved on [@ms14-068].

A signed data structure that Kerberos carries inside a ticket to tell a service who you are and which groups you belong to. Windows trusts the PAC for authorization decisions, so anyone who can forge a PAC the server will accept can rewrite their own group memberships [@ms-pac].

The patch fixed the bug. It never answered the question underneath it: was Kerberos broken, or did it just look broken? The whole escalation turned on one mechanism -- whether the controller demanded a keyed signature or accepted an unkeyed checksum. Flip that one switch and the verdict flips with it.

flowchart TD A[User submits a ticket request with a self-made PAC] --> B{"Does the KDC require a keyed signature on the PAC?"} B -->|"No, pre-patch"| C[Unkeyed checksum, recomputable by anyone] C --> D[Forged group memberships accepted] D --> E[User gains domain administrator authority] B -->|"Yes, MS14-068 fix"| F[Forged PAC fails verification] F --> G[Request rejected, privileges unchanged]

Windows runs dozens of authentication protocols, each specified in a Microsoft [MS-*] open specification and each broken, at some point, by its own published CVE. The bulletin recorded MS14-068 only as a privately reported vulnerability and named no discoverer.The widely repeated attribution to Tom Maddock is community folklore, not a vendor confirmation; the bulletin itself says only "privately reported" [@ms14-068]. So here is the question this article answers. I took 23 of those [MS-*] protocols and machine-checked them in the Tamarin prover under one network attacker, each modeled as a flawed version that reproduces its real break and a fixed version that closes it. The result was zero new vulnerabilities -- and that is the finding worth your time.

Three claims, in order. First, the analysis surfaced nothing new: every break it exhibits was already published. Second, nearly every one of those breaks, across protocols that share no code, collapses into just five recurring structural patterns. Third, finding nothing new across a corpus this well-studied is not an anticlimax -- it is the evidence that the five patterns are real and that the protocols, within the model, behave as their specifications claim.

Note: This is a tour of protocol logic -- the failures a symbolic model can see. It does not cover offline password cracking, credential theft, or stolen-key attacks. Those live one layer down, and Section 9 explains exactly why a perfect-crypto model is blind to them.

By the end you will have a vocabulary that predicts where an authentication protocol is likely to break before you have read a line of its CVE history. To explain why finding nothing can be a finding, though, we have to back up four decades -- to the first time a machine found a break that every human had missed.

2. Why Anyone Models Protocols at All

The Needham-Schroeder public-key protocol was published in 1978 and taught as correct for seventeen years [@needham-schroeder].Lowe's first attack appeared in 1995 -- seventeen years after the 1978 publication -- with the model-checked break-and-fix following in 1996 [@lowe-nsfdr-ps]. The protocol was used, taught, and trusted the entire time -- which is precisely why a machine-checkable method, rather than careful reading, turned out to matter. Then Gavin Lowe pointed a model checker at it and the tool found a man-in-the-middle in an afternoon: an attacker can interleave two runs so that the responder completes believing it authenticated the initiator, when it actually ran with the attacker [@lowe-nsfdr-ps]. The attack had been sitting in plain sight the whole time. How did we get a machine that could find what a generation of careful readers had missed?

The answer is a forty-year lineage, and it starts with a precise definition of the enemy. Needham and Schroeder gave the field its genre -- the challenge-response authentication handshake -- and, with it, a habit of arguing informally that a protocol "obviously" works [@needham-schroeder]. Five years later Danny Dolev and Andrew Yao replaced the hand-waving with a model so pessimistic it became the foundation of everything after it [@dolev-yao-ieee].

The attacker *is* the network. It can read, drop, replay, reorder, and inject any message; it can start any number of sessions; and it composes honest parties however it likes. The one thing it cannot do is break cryptography, which the model treats as perfect: ciphertext reveals nothing without the key, and signatures cannot be forged. Security means holding against this worst-case network attacker [@dolev-yao-ieee].

That single abstraction is the load-bearing assumption behind every result in this article, and behind its central limitation. By assuming perfect cryptography, the Dolev-Yao model throws away the bit-level details so it can reason cleanly about message flow -- which is exactly why it sees logic flaws and misses arithmetic ones.

Symbolic analysis models messages as abstract terms and assumes cryptography is perfect, so it reasons about protocol *logic* under a Dolev-Yao attacker. Computational analysis models messages as bitstrings and the attacker as a probabilistic polynomial-time algorithm, so it reasons about *probabilities*, key sizes, and the strength of primitives. The two methods answer different questions and see different failures [@sok-cac].

Next came a tool to reason inside the model. Burrows, Abadi, and Needham published BAN logic in 1990, a belief calculus that let analysts write down what each party is entitled to conclude from the messages it sees, layered on top of the Dolev-Yao attacker rather than inventing it [@ban-logic]. BAN made formal reasoning usable. It also showed how a verification method can be confidently wrong.

In 1990 Dan Nessett published a protocol that BAN logic "proves" secure even though it transmits the session key signed under a private key, so anyone with the corresponding public key can recover it -- the key is effectively in the clear [@nessett]. The lesson is not that BAN was useless; it is that a proof inherits the blind spots of its model. The same caution governs everything a symbolic prover tells us today.

Then the machines arrived. Lowe's 1996 break used the FDR refinement checker, and his paper did something subtle that turned out to matter for decades: it did not just break the protocol, it fixed it and re-checked the repair [@lowe-nsfdr-ps]. Break, patch, prove the patch -- that loop is the direct ancestor of the method in this article. Automated provers followed, in two families ordered by power rather than by date. Lowe's FDR sits at the head of the bounded, finite-state lineage -- explore every protocol run up to a fixed size -- a line later consolidated into toolsets such as AVISPA in 2005 [@avispa]. The unbounded symbolic provers, which lift that ceiling to arbitrarily many sessions, were led by ProVerif in 2001 [@blanchet-proverif] and eventually Tamarin in 2013 [@tamarin-cav].The split is conceptual, not a timeline: AVISPA (CAV 2005) [@avispa] postdates ProVerif (CSFW 2001) [@blanchet-proverif] by four years, and the genuinely earlier bounded exemplar is Lowe's FDR in 1996 [@lowe-nsfdr-ps].

Machines find what intuition misses. Lowe's 1996 result was not a cleverer human reading; it was a tool exploring runs a human would never enumerate by hand.

While that method matured, a second, separate history was unfolding inside Windows. The protocols Kerberos, NTLM, CredSSP, LDAP, and their relatives were each specified in a Microsoft [MS-*] document [@ms-nlmp] [@ms-pac] and each broken, in turn, by its own CVE across more than twenty years -- the breaks Section 4 lays out end to end. The two lineages -- method and application -- ran side by side and barely touched.

flowchart LR subgraph M["Method lineage"] M1[Needham-Schroeder 1978] --> M2[Dolev-Yao adversary 1983] M2 --> M3[BAN belief logic 1990] M3 --> M4[Lowe and FDR model checker 1996] M4 --> M5[Unbounded provers, ProVerif 2001] M5 --> M6[Tamarin 2013] end subgraph A["Windows application lineage"] A1[SMBRelay 2001] --> A2[MS08-068 2008] A2 --> A3[MS14-068 2014] A3 --> A4[Relay family 2017-2019] A4 --> A5[Bronze Bit 2020 and Certifried 2022] end M6 --> C[One adversary, whole corpus] A5 --> C

Lowe broke one protocol and fixed it. The Windows world had dozens, and for two decades each one was broken, and patched, entirely on its own. The first people to point the new machines at these specific protocols could say something rigorous about each -- but only one at a time.

3. One Protocol at a Time

The machines did get pointed at the protocols Windows actually runs, and the early results were genuinely good. They were also, by construction, local.

Start with public-key Kerberos. PKINIT lets a client authenticate to the Key Distribution Center with a certificate instead of a password, extending the Kerberos V5 service defined in RFC 4120 [@rfc4120].PKINIT is the public-key front door to Kerberos: it is how smart-card logon [@ms-pkca] and Windows Hello for Business [@whfb-auth] get an initial ticket. In 2006, Cervesato, Jaggard, Scedrov, Tsay, and Walstad formally analyzed it and found a man-in-the-middle: the KDC's reply was not bound to the requesting client's identity, so an insider could sit between a client and the KDC and make the client accept a session it never established [@cjstw-eprint]. They did not stop at the break. They specified fixes that bind the reply to the client and machine-checked the repair [@cjstw-asian], with the canonical journal version following in 2008 [@cjstw-infcomput]. Break, fix, prove the fix -- Lowe's loop, applied to a protocol shipping in every enterprise.

Two years later, in 2008, Armando, Carbone, Compagna, Cuellar, and Tobarra turned the same lens on SAML 2.0 web-browser single sign-on, the protocol family behind federated login. A missing binding between an assertion and its intended audience let a dishonest service provider redirect a user's authentication to a different one, breaking SSO for Google Apps as their worked example [@armando-saml]. A few years later Cas Cremers re-analyzed IPsec's IKEv1 and IKEv2 and showed cross-mode confusion: properties that hold for one authentication mode can fail once an attacker mixes modes the designers reasoned about separately [@cremers-ipsec].

Underneath two of those results sat one idea that had already been named. In 2003, Asokan, Niemi, and Nyberg described the man-in-the-middle in tunnelled authentication protocols: when an inner authentication runs inside an outer protected channel without being bound to it, an attacker can relay the inner exchange through a channel of its own choosing [@asokan-spw-doi]. Their fix was a cryptographic binding between the inner authentication and the protection protocol [@asokan-eprint] -- the academic root of what Windows would later call channel binding, and the seed of the first of our five patterns.

Each of these was rigorous. Each shipped a real fix that is still in the specifications today. But notice the shape of the work: every analysis built its own model of the attacker, its own idealization of the protocol, its own security goals. PKINIT's adversary was not SAML's adversary, which was not IKE's. So when a practitioner squinted and said "these all feel like the same mistake," that intuition had nowhere rigorous to land. The recurrence was an analogy across papers that did not share a model.

That is the wall the rest of this article is built to climb. Every one of these was a verdict on a single protocol. Nobody had asked, in a checkable way, what the breaks had in common -- because with a different model under each one, nobody could.

4. Twenty Years, the Same Five Mistakes

Lay the famous Windows-auth breaks end to end and a shape jumps off the page. SMBRelay in 2001, NTLM credential reflection in 2008, the unkeyed Kerberos checksum in 2014, a cluster of relay and channel-binding failures from 2017 to 2019, the Bronze Bit delegation bypass in 2020, the Certifried certificate misissuance in 2022. Different teams, different protocols, different decades -- and a small number of mistakes underneath, repeating.

Year	Public break	Protocol	The mechanism that failed	Pattern
2001	SMBRelay [@cdc-smbrelay]	SMB / NTLM	authenticator not bound to the channel it was used on	1
2008	MS08-068, CVE-2008-4037 [@ms08-068]	NTLM (SMB)	a credential reflected straight back at its sender	3
2014	MS14-068, CVE-2014-6324 [@cve-2014-6324]	Kerberos PAC	an unkeyed checksum accepted where a keyed signature was required	2
2017	CVE-2017-8563 [@cve-2017-8563]	LDAP	the bind not bound to the TLS channel underneath it	1
2018	CVE-2018-0886 [@cve-2018-0886]	CredSSP	the key-authentication value not bound to the TLS session	1
2019	CVE-2019-1040 [@cve-2019-1040]	NTLM	an integrity field stripped without invalidating the signature	1
2020	CVE-2020-17049 (Bronze Bit) [@cve-2020-17049]	Kerberos S4U	a delegation restriction not protected by a keyed signature	5
2022	CVE-2022-26923 (Certifried) [@cve-2022-26923]	AD CS	a certificate subject not bound to the requester's identity	4

The first entry is the oldest and the least formal. SMBRelay was demonstrated by the handle Sir Dystic in 2001, and its provenance is an archived Cult of the Dead Cow page rather than an academic paper [@cdc-smbrelay].That archival fragility is itself worth noting: a foundational attack in Windows security history survives mainly as a web-archive snapshot, not a citable primary [@cdc-smbrelay]. It showed that an NTLM authenticator, captured on one connection, could be forwarded to a second service that would happily accept it.

timeline title Windows authentication breaks, 2001-2022 2001 : SMBRelay, NTLM relayed to a second service 2008 : MS08-068, NTLM credential reflection 2014 : MS14-068, unkeyed PAC checksum forged 2017 : CVE-2017-8563, LDAP bind unbound from TLS 2018 : CVE-2018-0886, CredSSP TLS splice 2019 : CVE-2019-1040, drop-the-MIC integrity strip 2020 : CVE-2020-17049, Bronze Bit delegation bypass 2022 : CVE-2022-26923, Certifried misissuance

Every one of these got a fix, and every fix was sound. Channel binding closed the relay and tunnelling failures, formalized for TLS as the bindings in RFC 5929 [@rfc5929]. Requiring a keyed signature closed the forged-PAC escalation [@cve-2014-6324]. Detecting and rejecting a reflected authenticator stopped NTLM credential reflection: MS08-068 changed the way SMB validates authentication replies, so a credential bounced straight back at its sender no longer passes [@ms08-068]. Binding an issued token to its audience and its requester closed the misissuance and redirection failures [@cve-2022-26923]. Protecting a delegation flag with a key closed the Bronze Bit bypass [@cve-2020-17049]. Each repair was correct, shipped quickly, and -- this is the important part -- entirely local to its own protocol.

That locality is the trap. NTLM reflection [@ms08-068] and the unkeyed PAC checksum [@cve-2014-6324] are the same family of mistake -- trusting an integrity value that carries no secret or no direction -- yet they live in protocols that share no code and were fixed years apart by different teams. The relay family of 2017 through 2019 [@cve-2017-8563] [@cve-2018-0886] [@cve-2019-1040] is one idea, missing channel binding, wearing three protocol costumes. Bronze Bit [@cve-2020-17049] and Certifried [@cve-2022-26923] rhyme with breaks a decade older. The pattern is real, but it is spread across the seams between protocols, exactly where per-protocol work cannot look.

Key idea: Per-CVE point-fixing is indispensable engineering and a terrible microscope for structure. Each patch is local to one protocol, and each one-protocol analysis rebuilds the attacker model from scratch. So the recurring shape is invisible by construction: you cannot see a cross-protocol pattern one protocol at a time. The fixes were never wrong -- they were just the wrong instrument for the question "what keeps going wrong?"

Which sets up the move the rest of the article depends on. If the shapes are real, you should be able to prove they are real -- not protocol by protocol, but all of them at once, every model facing the same attacker, with the recurrence stated as a checkable claim rather than a feeling. What would it take to build that?

5. One Adversary, One Method, the Whole Corpus

The move that makes the recurrence checkable is almost embarrassingly simple to state: model 23 of the [MS-*] protocols in a single prover, under one shared attacker, and for each known break build not two models but three. I used the Tamarin prover for this, and its feature list is the reason [@tamarin-cav].

Tamarin represents a protocol as multiset-rewriting rules over a mutable global state, reasons natively about Diffie-Hellman exponentiation, and verifies properties over an unbounded number of sessions rather than a fixed few [@tamarin-cav]. It produces both proofs and concrete attack traces, and it has been used on protocols at the scale of TLS 1.3, 5G-AKA, and EMV [@tamarin-home]. Windows authentication needs exactly that combination: key exchange with real DH and post-quantum KEMs, credential state that changes as tickets are issued, unbounded concurrent sessions, and the ability to show both that a fix works and that the flawed version breaks. Security goals are written as trace properties.

A security goal phrased as a statement about every possible run of the protocol: on no trace does something bad happen. Secrecy says no run ever leaks the secret to the attacker. Agreement says that whenever one party finishes believing it authenticated another, that other party really did take part in a matching run [@tamarin-manual]. Agreement strengthened with a one-to-one matching between a party's completed runs and its peer's genuine runs, so that no single legitimate exchange can be replayed to satisfy two separate acceptances. Injectivity is the part of the property that rules out replay [@tamarin-manual].

The third model is the one that turns analogy into evidence.

Three models of the same protocol. The *fixed* model includes the defended mechanism and verifies the security lemma. The *flawed* model removes exactly that one mechanism, and the same lemma falsifies -- reproducing the published break. The *control* re-enables the mechanism and the lemma verifies again. Because only one thing changed between the three, the cause of the break is pinned to that mechanism rather than to some accident of how the model was written [@lowe-nsfdr-ps].

Here is one lemma, in Tamarin's own property language, for the MS14-068 case -- the claim that only the KDC can produce a PAC a server will accept:

lemma pac_only_kdc_can_sign:
  "All srv pac #i.
       AcceptPAC(srv, pac) @i
   ==> ( Ex #j. KdcSignedPAC(pac) @j & j < i )
     | ( Ex #r. RevealKey('krbtgt') @r )"

Read it as: on every trace, if a server accepts a PAC at time i, then either the KDC actually produced that PAC's keyed signature earlier, or the long-term krbtgt key was revealed [@tamarin-manual]. In the fixed model, where the integrity check is a keyed signature under krbtgt, Tamarin finds no violating trace and the lemma holds for unbounded sessions. In the flawed model, where the server accepts an unkeyed checksum, Tamarin returns a concrete counterexample -- an acceptance with no prior KDC signature and no key reveal -- which is the forged-PAC escalation, machine-checked [@cve-2014-6324]. The operators and templates are standard Tamarin; the action-fact names are the model's own and are not themselves a citable claim.

Two disciplines keep this honest. The first guards against a lemma that is true only because nothing ever reaches it.A property can be vacuously satisfied if no honest run ever triggers its premise. Non-vacuity sanity lemmas prove an honest party really can complete the protocol, so a "verified" guarantee has teeth rather than being true by absence [@tamarin-manual]. The second guards against overclaiming: every falsification is matched to a published CVE or paper before I call it a reproduction. Nothing in this corpus is presented as a discovery.

flowchart TD P[One protocol, one Dolev-Yao adversary] --> F[Fixed model, mechanism present] P --> X[Flawed model, one mechanism removed] P --> K[Control model, mechanism re-enabled] F --> FR[Security lemma verifies] X --> XR[Same lemma falsifies, the published break] K --> KR[Same lemma verifies again] FR --> D{"Did only the toggled mechanism move the verdict?"} XR --> D KR --> D D -->|Yes| C[Cause localized to the mechanism, not the harness]

Key idea: The control model is the difference between a story and a proof. Without it, "these breaks are all the same pattern" is a nice grouping of war stories. With it, the claim becomes machine-checked and specific: toggle this one mechanism and the security property flips, restore it and the property returns. The recurrence is no longer an analogy across papers -- it is a falsifiable statement about a mechanism, repeated across protocols that share no code.

Finding nothing new across a well-studied corpus is not a null result. It is the evidence that the taxonomy is real -- the protocols behave, within the model, exactly as their fixes claim.

With the instrument built, the corpus gives up its structure without much further argument. There are five shapes. Here is each one, with the worked break behind it.

6. The Five Patterns

Before you read a single CVE, ask five questions of any authentication protocol. Each question targets one of the recurring shapes, and a "no" to any of them names the family of break to expect. This decision tree is the article's centerpiece -- the audit you can run from memory.

flowchart TD S[Any authentication protocol] --> Q1{"Is every authenticator bound to the channel and endpoint it is used on?"} Q1 -->|No| P1[Pattern 1, relay and MITM] Q1 -->|Yes| Q2{"Is every integrity check keyed, never a bare checksum?"} Q2 -->|No| P2[Pattern 2, keyed-vs-unkeyed confusion] Q2 -->|Yes| Q3{"Does every symmetric credential carry a direction or role tag?"} Q3 -->|No| P3[Pattern 3, credential reflection] Q3 -->|Yes| Q4{"Does every signed token bind requester, key, and audience?"} Q4 -->|No| P4[Pattern 4, identity-binding gap] Q4 -->|Yes| Q5{"Does every delegation chain keep its restriction under composition?"} Q5 -->|No| P5[Pattern 5, delegation and composition] Q5 -->|Yes| OK[No break in these five shapes within symbolic reach]

Pattern	The mechanism that fails	Worked break	The fix	Public anchor
1. Channel binding	authenticator not bound to its channel or endpoint	NTLM relay, drop-the-MIC, CredSSP, LDAP	TLS channel binding, SPNEGO mechListMIC	[@rfc5929] [@cve-2019-1040]
2. Keyed-vs-unkeyed	an unkeyed checksum accepted as integrity	MS14-068 PAC forgery	require a keyed KDC signature	[@cve-2014-6324]
3. Reflection	a symmetric credential with no direction tag	NTLM credential reflection (MS08-068)	reflection/replay detection (a direction tag in the model)	[@ms08-068] [@cve-2008-4037]
4. Identity binding	a token not bound to requester, key, or audience	PKINIT, SAML SSO, Certifried	bind reply, audience, and subject	[@cve-2022-26923] [@rfc4556]
5. Delegation	a restriction not preserved across a chain	Bronze Bit S4U	protect the flag with a keyed signature	[@cve-2020-17049]

Note: These five questions are a predictive vocabulary. You do not need to formally model a protocol to ask them, and you do not need its CVE history. A "no" to any question tells you which family of failure to look for first -- which is what a taxonomy is for.

Pattern 1: Missing or ignored channel binding

The first pattern is the relay. An authenticator -- an NTLM response, a signed bind, a delegated credential -- is computed without naming the channel it is supposed to travel on, so an attacker can carry it to a different service that will accept it just the same. This is the modern form of the tunnelled-authentication man-in-the-middle that Asokan, Niemi, and Nyberg described in 2003 [@asokan-spw-doi].

Channel binding ties an inner authenticator to the outer channel it travels on, usually identified by the TLS endpoint [@rfc5929]. Windows ships it as Extended Protection for Authentication (EPA) and a Channel Binding Token (CBT) [@adv190023]. With the binding present, an authenticator captured on one connection is useless on another, because it names the channel it was made for.

The worked model is NTLM. With no channel binding, a victim's NTLM exchange relays cleanly to a second service [@ms-nlmp]; add the binding and the relayed authenticator no longer matches the channel it arrives on, and the target rejects it.

sequenceDiagram participant V as Victim client participant M as Attacker relay participant T as Target server V->>M: Connect, NTLM NEGOTIATE M->>T: Relay NEGOTIATE as the victim T->>M: NTLM CHALLENGE, server nonce M->>V: Forward the same CHALLENGE V->>M: NTLM AUTHENTICATE over the nonce M->>T: Relay AUTHENTICATE unchanged Note over M,T: No channel binding, so the target cannot tell the response came from a different connection T->>M: Access granted as the victim

The same shape recurs across protocols that share no code. CredSSP failed to bind its pubKeyAuth value to the TLS session, so a man-in-the-middle could splice itself into an RDP credential handshake [@cve-2018-0886]. LDAP accepted a bind without tying it to the TLS channel underneath, and Microsoft's own documentation is blunt that the default performed no channel-binding validation at all [@kb4034879] [@cve-2017-8563]. The companion guidance spells out the man-in-the-middle risk [@kb4520412] under the umbrella advisory for LDAP hardening [@adv190023]. And drop-the-MIC removed NTLM's integrity check without invalidating the surrounding signature.drop-the-MIC strips the NTLM message-integrity check from the negotiated flags without invalidating the outer signature, so a tampered exchange still verifies as authentic [@cve-2019-1040].

The fixes are all the same idea wearing different names: the TLS channel bindings tls-server-end-point and tls-unique defined in RFC 5929 [@rfc5929], and the SPNEGO mechListMIC that stops a negotiation downgrade [@rfc4178]. One subtlety decides whether the fix actually closes the door.RFC 5929's tls-server-end-point hashes the server certificate, so it is per-certificate, not per-service. Two services sharing one certificate share one binding value -- which is exactly the gap that kept some LDAP deployments relayable even after binding was nominally enabled [@rfc5929].

Pattern 2: Keyed-vs-unkeyed integrity

The second pattern is a confusion between two things that look alike and behave nothing alike: a checksum and a keyed signature.

A checksum -- a CRC, a bare hash -- detects accidental corruption and needs no secret, so anyone can recompute it over data they forged. A message authentication code or signature is *keyed*: producing a valid tag requires a secret held by the legitimate sender -- a shared key the verifier also holds (a MAC), or a private key the verifier checks against the sender's public key (a signature). A verifier that accepts an unkeyed checksum where a keyed tag was required is trusting a value any attacker can produce [@cve-2014-6324].

This is MS14-068 exactly. The KDC accepted a PAC whose integrity "signature" could be an unkeyed checksum, so a user could forge group memberships and compute a matching checksum themselves [@cve-2014-6324]. Require that the PAC carry a keyed signature under the krbtgt key, and the same forgery fails because the user cannot produce the tag [@ms14-068]. The identical class shows up at the server-to-domain-controller PAC validation step, where a service asks a DC to vouch for a ticket's PAC [@ms-pac]. The fix and the failure are one mechanism, toggled.

{` // A toy checksum: no secret, so anyone can recompute it over any data. function checksum(data) { let sum = 0; for (const ch of data) sum = (sum + ch.charCodeAt(0)) % 65521; return sum; } // A toy keyed tag: the value depends on a secret the attacker does not hold. function tag(key, data) { let acc = key.length * 131; for (const ch of (key + data)) acc = (acc * 31 + ch.charCodeAt(0)) % 1000003; return acc; }

const forged = "groups=domain-admins";

// Unkeyed: the attacker computes the same checksum the verifier will recompute. const attached = checksum(forged); const verifier = checksum(forged); console.log("unkeyed checksum accepts forged data:", attached === verifier); // true

// Keyed: without the KDC secret, the attacker cannot match the expected tag. const kdcSecret = "krbtgt-secret"; const serverExpects = tag(kdcSecret, forged); const attackerTag = tag("no-secret", forged); console.log("forged keyed tag accepted:", attackerTag === serverExpects); // false `}

Pattern 3: Symmetric-credential reflection

The third pattern is reflection. A credential computed by a keyed function that carries no direction or role tag can be bounced back at the party that produced it. The canonical Windows instance is NTLM credential reflection, fixed in MS08-068 [@ms08-068]: an attacker who receives a victim's challenge-response can send that same authenticator back to the victim's own machine and be accepted as the victim [@cve-2008-4037]. It sits in the SMBRelay lineage that opened our timeline [@cdc-smbrelay].

The toggle is a direction tag. Remove it and the value a client produces is exactly the value a server will accept, so the reflection works. Restore a role offset -- so the two directions compute different values -- and the reflected response no longer matches.

{` // A symmetric response: both ends compute the same function of nonce and key. function respond(key, nonce, role) { let acc = 0; for (const ch of (role + key + nonce)) acc = (acc * 33 + ch.charCodeAt(0)) % 1000003; return acc; }

const key = "shared-session-key"; const nonce = "server-nonce-1234";

// No direction tag: what a client sends equals what a server would accept. const clientSends = respond(key, nonce, ""); const serverAccepts = respond(key, nonce, ""); console.log("reflected response accepted, no tag:", clientSends === serverAccepts); // true

// With a direction tag, the two directions diverge and reflection fails. const clientTagged = respond(key, nonce, "client-to-server"); const serverTagged = respond(key, nonce, "server-to-client"); console.log("reflected response accepted, tagged:", clientTagged === serverTagged); // false `}

There is one place this pattern is easy to overclaim, and the honesty frame of this whole article depends on not doing so.In my Tamarin model of [MS-NRPC], a client may pick its Netlogon NetrServerAuthenticate3 challenge to coincide with the server's -- a structural reflection the symbolic model can express. This is a modeling observation, not a separately published Netlogon weakness; the famous Zerologon escalation turns on the computational AES-CFB8 zero-IV weakness that a perfect-crypto model cannot represent. Zerologon appears here only as the Section 9 boundary illustration -- encoded as an equation, never discovered [@cve-2020-1472].

Pattern 4: Identity-binding gaps in signed tokens

The fourth pattern is a signed thing -- a reply, a ticket, an assertion, a certificate -- that is correctly signed and yet fails to bind who it is for. PKINIT is the textbook case: the KDC's reply was not bound to the requesting client's identity, the gap Cervesato and colleagues formalized [@cjstw-infcomput]. In Diffie-Hellman mode this becomes an unknown-key-share risk, where a client can be steered into misattributing a key. The fix binds the request itself with the paChecksum defined in RFC 4556 Section 3.2.1, a checksum over the request body [@rfc4556]. RFC 8636 later made its hash negotiable under "paChecksum Agility" -- it did not add the field, it standardized the field's agility [@rfc8636].

The same gap appears wherever a token crosses a trust boundary. SAML single sign-on needed an audience restriction so an assertion minted for one service could not be redirected to another [@armando-saml]. AD CS certificate enrollment needed the issued certificate's subject bound to the requester's real identity -- absent that, the Certifried technique let a low-privilege account enroll a certificate for a domain controller [@cve-2022-26923], a later escalation across the AD CS attack surface that SpecterOps's Certified Pre-Owned had first mapped in June 2021 [@specterops-cpo]. OAuth's on-behalf-of exchange needs its token audience checked to avoid a confused-deputy redirection [@rfc6819], and device registration needs a proof-of-possession binding so a bearer token cannot be replayed against a key the device never held [@rfc7800].

Pattern 5: Delegation and composition

The fifth pattern is the subtlest, because every component is sound on its own. The failure lives in the chain. Kerberos constrained delegation lets a service act on a user's behalf, gated by whether a ticket is marked forwardable. The Bronze Bit technique flipped that restriction: a compromised service could tamper with a service ticket that was not valid for delegation and force the KDC to accept it, because the relevant integrity was not protected by the KDC's own ticket signature [@cve-2020-17049]. Restore the check on the krbtgt ticket signature and the tampered ticket is rejected [@netspi-bronzebit].

Composition multiplies the surface. Resource-based constrained delegation chains can be assembled into escalation paths that no single hop authorizes [@shamir-wagging]. A cross-protocol NTLM relay shares one credential across SMB, LDAP, and CredSSP at once, so a binding omitted in any one leg reopens the whole composition. And IKE's cross-mode confusion is a composition failure at the key-exchange layer, where mixing modes defeats a property each mode satisfies alone [@cremers-ipsec].

You can run these five questions against a protocol you have never modeled formally and never will: channel binding, keyed integrity, direction tags, identity binding, and a restriction that survives composition. Asked of a design document, they catch the families behind two decades of Windows-auth CVEs before any of them ships. Section 11 turns them into a checklist, each paired with the fix that already exists.

Every pattern so far is a way something broke. But the instrument that exhibits a break can also prove a guarantee -- and when I pushed twelve of these models under stronger attackers, what came back was not new bugs but stronger proofs. What did the deep models actually prove?

7. What the Deep Models Proved

A prover does not only produce counterexamples. When a lemma holds, you get a proof -- a statement that across every run, under this attacker, nothing violates the property. So I took twelve of the models and deepened them: same protocols, stronger attacker. The headline stayed the same. No new breaks. What changed is that the guarantees got stronger, and I can say precisely which attacker capability each one now survives. Everything below is my Tamarin verification within the Dolev-Yao model, each item anchored to the public specification or CVE it concerns -- not an independently published finding.

A session's keys stay secret even if the parties' long-term keys are compromised later. Traffic captured today remains protected against a key leak tomorrow, because the session key depended on ephemeral values that no longer exist [@rfc4556]. Compromising a party's own long-term key obviously lets an attacker impersonate that party. KCI resistance is the narrower guarantee that it does not *also* let the attacker impersonate other parties *to* the compromised one [@cremers-ipsec].

The deepenings follow a single recipe: add an attacker capability the per-protocol models had assumed away, then see which lemma still holds.

Guarantee	Attacker capability added	Lemma that still holds	Public anchor
Forward secrecy, PKINIT-DH	reveal both client and KDC long-term signing keys after the run	AS reply key stays secret; only the two ephemerals protect it	[@rfc4556]
KCI resistance, PKINIT-DH	compromise the client's own long-term key	client still authenticates the genuine KDC	[@rfc4556]
Mutual auth and PFS, IPsec IKE	ephemeral reveal, then both parties' long-term keys	injective mutual authentication and forward secrecy survive	[@cremers-ipsec]
Hybrid PQ-KEX transcript binding	reveal both the DH and KEM legs (both-leg compromise)	acceptance still binds the genuine transcript and key	author's Tamarin model
Per-channel bindings under composition	one shared NTLMv2 credential feeding SMB, LDAP, and CredSSP under a relay attacker	each acceptor's binding holds inside the composition	[@cve-2019-1040] [@cve-2018-0886] [@cve-2017-8563] [@rfc5929]
SID filtering and Silver-Ticket containment	cross-domain referrals, the full four-signature PAC, and service-key reveal	external forests stay contained; DC-validated PACs defeat Silver Tickets	[@ms-pac]
Bronze-Bit and Protected-User non-delegation	arbitrary service-key compromise across S4U, RBCD, and PKINIT at once	every delegated impersonation traces to a legitimate KDC grant; Protected Users are never delegated	[@cve-2020-17049] [@protected-users] [@shamir-wagging]

A few deserve a sentence. PKINIT's public-key-encryption mode structurally cannot offer forward secrecy, because the reply key arrives encrypted to a long-term key; the DH mode can, and the deepened model proves it does even when both signing keys leak after the run [@rfc4556]. The hybrid post-quantum result is the strongest-sounding and has no public primary, so I flag it as model-only: binding the KEM ciphertext into the transcript keeps a client's acceptance tied to the genuine server even when both the classical and post-quantum legs are revealed. The delegation result matters most operationally: a Protected Users account is never delegated by any path -- classic, resource-based, or PKINIT-issued -- even under arbitrary service-key compromise [@protected-users].

Honesty requires one scar on this table.One deepening did not yield an independent re-proof in my sandbox. The heaviest cross-domain four-signature-PAC model exhausted memory -- an out-of-memory EXIT 137 -- before Tamarin terminated. I record that result as reported, not independently re-proved [@ms-pac]. A guarantee I cannot re-derive is a guarantee I report with an asterisk, not one I assert.

These proofs are strong, but they are exactly as strong as the model they live in -- no stronger. So the fair next question is how Tamarin compares with the other instruments on the bench, and, more pointedly, what it is choosing not to see.

8. Symbolic, Computational, and the Tools Between

Tamarin was the right instrument for this corpus, but it is one of several, and the honest comparison is about what each one buys and what it costs. The computer-aided cryptography community's own survey lays out the taxonomy, and I follow it here [@sok-cac].

The first split is the model. Symbolic tools -- Tamarin, ProVerif, Scyther -- work in the Dolev-Yao world of perfect cryptography and reason about protocol logic. Computational tools -- CryptoVerif, EasyCrypt -- model the attacker as a probabilistic polynomial-time algorithm and produce bounds on its success probability [@sok-cac]. They answer different questions, which is why a single benchmark number rarely transfers between them.

Tool	Model	Termination	DH and state	Style	Best at
Tamarin	symbolic, Dolev-Yao	may not terminate	DH plus mutable state, unbounded	automated and interactive	stateful key exchange, proofs and attack traces [@tamarin-cav]
ProVerif	symbolic, applied pi and Horn clauses	usually terminates, over-approximates	limited state	automated	fast unbounded analysis, but can report false attacks [@proverif-home]
Scyther	symbolic, pattern refinement	guaranteed on its protocol class	limited	automated	guaranteed termination on a restricted class [@scyther-repo] [@scyther-cav-2008-tool]
CryptoVerif	computational, game-based	semi-automated	not applicable	guided	concrete probability bounds [@cryptoverif-home]
EasyCrypt	computational, proof assistant	manual	not applicable	interactive	primitive-level and game-based proofs [@easycrypt-home]

Why Tamarin for Windows authentication, then? Because these protocols need Diffie-Hellman and post-quantum KEMs, credential state that mutates as tickets are issued, unbounded sessions, and both proofs and concrete attack traces in one tool [@tamarin-cav]. ProVerif is often faster, but its Horn-clause over-approximation makes stateful DH flows awkward and can surface attacks that do not really exist [@proverif-home]. Scyther guarantees termination, but only on a restricted protocol class that this corpus repeatedly steps outside of [@scyther-repo]. The pattern-refinement technique behind Scyther is worth reading in its own right [@scyther-ccs-2008].

Could a symbolic proof simply hand off to a computational guarantee? Sometimes, and that bridge has a name.

A theorem that carries a symbolic proof over to a computational guarantee, provided the cryptographic primitives satisfy specific conditions. The Abadi-Rogaway results established it for formal encryption, but only under strong, primitive-specific side-conditions [@abadi-rogaway-ifip]. There is no universal computational-soundness theorem [@abadi-rogaway-joc].

So the bridge is real but partial, which is why the survey's recommendation is not "pick the best tool" but "combine them": symbolic for protocol logic at scale, computational for primitive strength, and a third layer for the code [@sok-cac]. That third layer is the active frontier. DY* embeds Dolev-Yao symbolic analysis as a library for executable F* code and used it to mechanize Signal end to end, closing the gap between a model and the program that ships [@dystar-ieee] [@dystar-repo]. Verifpal trades some expressiveness for a gentler modeling language with formal semantics, aiming to lower the rate of modeling mistakes [@verifpal-eprint].

Every one of those tools, the symbolic ones especially, shares a single blind spot. It is not a defect in any implementation. It is the definition of the model itself -- and it is where this article has been heading all along.

9. The Boundary the Method Cannot Cross

Return to the question from the first paragraph: was Kerberos broken, or did it just look broken? The honest answer is that a perfect-crypto model can prove a protocol's logic sound and still be completely blind to a flaw that ships a domain takeover. Two results make that boundary precise, and neither is a defect you could engineer away.

The first is about decidability. Durgin, Lincoln, Mitchell, and Scedrov showed that secrecy for protocols with an unbounded number of sessions is undecidable [@dlms-2004]. Restrict to a bounded number of sessions and the problem becomes "merely" NP-complete, as Rusinowitch and Turuani proved [@rusinowitch-turuani]. Put those together and you get a hard fact about tooling: no symbolic verifier can be simultaneously sound, complete, and guaranteed to terminate. Each tool gives up one. Tamarin may not terminate; ProVerif sacrifices completeness and can report false attacks; Scyther restricts the protocol class it accepts [@sok-cac].

The second boundary is sharper, and it is the heart of the whole article. The Dolev-Yao model abstracts cryptography to perfect operations, so it provably cannot represent a flaw that lives in the cryptographic arithmetic itself. Zerologon is the flagship example. The Netlogon credential used AES in CFB8 mode with an all-zero initialization vector, and with probability $\approx 1/256$ per attempt an all-zero plaintext produced an all-zero ciphertext, letting an unauthenticated attacker forge the credential and ultimately seize a domain controller [@cve-2020-1472]. The mechanism is laid out in the disclosure whitepaper [@secura-zerologon]. No symbolic model sees this, because the model has no notion of an IV, a block-cipher mode, or a $1/256$ probability. There is nothing to find.

flowchart TD F[A protocol failure] --> Q{"Is it in the message logic or in the cryptographic arithmetic?"} Q -->|Message logic| S[Symbolic model sees it: relay, reflection, missing binding, signature confusion] Q -->|Cryptographic arithmetic| C[Symbolic model is blind: zero-IV, weak hash, probability gaps] C --> Z[Zerologon lives here, encoded as an equation, never discovered] S --> V[Tamarin can verify or falsify]

This is why the article has been so insistent about one phrase. Where the corpus shows a computational consequence, it encoded the published weakness as an equation in the model; it did not find it.

Note: A symbolic prover that "reproduces" Zerologon has not discovered anything about the cipher. It has had the weakness hand-fed to it as an algebraic identity. Reporting an encoded computational flaw as a symbolic finding is the single most tempting way to overclaim with these tools, and it is wrong every time.

Note: A proof inherits the blind spots of its model. "Verified in Tamarin" means the protocol logic holds against a Dolev-Yao attacker -- it says nothing about the primitives, the probabilities, or the implementation. Always validate the model against the specification, and never read "verified" as "safe."

Key idea: The boundary is the result, not a failure. Unbounded verification is undecidable, and a perfect-crypto model provably cannot represent a probabilistic flaw. So "nothing new across a well-studied corpus" is not an anticlimax. It is the model telling you, precisely, that the protocol logic is sound and that whatever risk remains must live one layer down. That is the most useful thing a symbolic prover can say -- and it can only say it honestly if you respect the wall.

Verified means: within this model, against this adversary, no trace violates this property. Nothing more, and nothing less.

The boundary also tells you which famous attacks were never in scope to begin with.

Kerberoasting [@attack-t1558-003] and AS-REP roasting [@attack-t1558-004] are offline password cracking. Pass-the-Hash is credential theft [@attack-t1550-002]. Golden and Silver tickets are forgeries that start from a compromised key [@attack-t1558-001] [@attack-t1558-002]. DCSync is permission abuse over a replication interface [@attack-t1003-006]. None of these is a protocol-logic flaw, so a perfect-crypto symbolic model cannot see them -- not because the model failed, but because they live, by definition, outside it. A model can encode a stolen key and check whether a containment holds; it cannot "discover" theft as a logic bug.

If the boundary is permanent -- and it is -- then the most interesting questions live right up against it. Where does the method, and this particular corpus, still strain?

10. Where the Method Still Strains

The boundary is not the end of the work; it is where the hardest open problems begin. Five of them bound this corpus.

Computational soundness at full-protocol scale. The dream is to lift a symbolic proof of a deployed protocol automatically to a computational guarantee covering the real primitives -- exactly the gap that hides Zerologon-class flaws. Soundness theorems exist, but only for restricted primitives and conditions [@abadi-rogaway-ifip]. The working answer today is the survey's layered stack -- combine symbolic, computational, and code-level tools -- not a universal bridge [@sok-cac].

Termination with full algebraic theories. Tamarin reasons about Diffie-Hellman and exclusive-or, but with those theories it may not terminate, and terminating results exist only for restricted equational fragments such as Scyther's class. The undecidability wall keeps this an open trade between expressiveness and automation [@dlms-2004].

Composition and whole deployments. Composition theorems are provable for specific seams -- per-channel bindings survive a shared-credential relay, for instance. But scaling to a whole interacting deployment is unsolved, and this corpus hit the wall directly: the heaviest cross-domain four-signature-PAC model exhausted memory on independent re-proof, a concrete state-explosion failure rather than a theoretical one [@cremers-ipsec].

Privacy and equivalence at scale. Secrecy and authentication are reachability properties. Privacy properties -- unlinkability, anonymity -- are equivalence properties, which are markedly harder and scale worse. Tamarin's observational equivalence and ProVerif's equivalence checking handle modest protocols, but the frontier here is genuinely hard [@sok-cac].

From verified models to verified deployments. A proof about a model is only as good as the model's fidelity to the running code. DY* mechanized Signal end to end from executable F* code [@dystar-ieee], and Verifpal lowers the modeling-error rate with friendlier semantics [@verifpal-eprint]. But [MS-*] implementations are closed, so for this corpus model fidelity has to be argued from the public specification rather than mechanically derived from the binaries.

Those are the frontier's problems, and none of them has to be solved before the five patterns become useful. Here is what you can do with them this afternoon.

11. Auditing With the Five Patterns

The taxonomy earns its keep as a checklist. You do not need Tamarin to use it -- you need a specification, a design review, and five questions. Each maps to a concrete Windows mechanism and a documented fix.

Note: 1. Channel binding. Is every authenticator bound to the endpoint it is used on? The fix is a TLS channel binding such as tls-server-end-point, Extended Protection for Authentication, and the SPNEGO mechListMIC against downgrade [@rfc5929] [@rfc4178]. 2. Keyed integrity. Is every integrity check keyed, never a bare checksum? The fix is the keyed PAC signature MS14-068 should have required [@cve-2014-6324]. 3. Direction tags. Does every symmetric credential carry a direction or role tag? In a model the remedy is a direction/role offset; MS08-068 itself shipped it as reflection/replay detection -- the SMB endpoint records the challenge it issued and rejects an authenticator that comes back carrying it [@ms08-068]. 4. Identity binding. Does every signed token bind requester, key, and audience? For PKINIT that is the paChecksum request-binding of RFC 4556 Section 3.2.1, whose hash RFC 8636 made agile [@rfc4556] [@rfc8636]. 5. Delegation. Does every delegation chain keep its restriction under composition? The fix is the krbtgt ticket signature Bronze Bit bypassed [@cve-2020-17049].

A "no" to any question does not prove a break -- it tells you where to look first, and which published fix already exists. That is the difference between a taxonomy and a vulnerability scanner: the taxonomy makes you faster at the questions, not lazier about the answers.

If you go further and model a protocol yourself, the corpus's method carries two warnings worth repeating.

Note: Keep each flawed/fixed pair minimal: toggle exactly one mechanism, so a falsification points at one cause. Always add a control that re-enables the mechanism and flips the verdict back, or you cannot tell a real break from a modeling artifact. Validate the model against the specification it claims to represent. And never report an encoded probabilistic flaw as a symbolic finding [@sok-cac].

The most common channel-binding gaps in a real domain are LDAP, RDP, and SMB. Microsoft's guidance is to move `LdapEnforceChannelBinding` toward enforcement once clients are ready [@kb4034879], following the staged requirements in the LDAP hardening advisory [@adv190023] and its companion timeline [@kb4520412]; to keep CredSSP patched so the `pubKeyAuth` binding is enforced [@cve-2018-0886]; and to require SMB signing so a relayed session cannot be tampered mid-stream [@ms-smb-signing]. None of these is exotic -- they are Pattern 1, three times.

Run those five questions and you are doing by hand what the corpus did by machine. Which leaves only the questions people ask out loud when they hear the phrase "I verified Windows authentication and found nothing."

12. Questions People Ask

No, and that is the point. Every break in this article was already published, with its own CVE, RFC, or paper. The contribution is not a bug; it is the unified, machine-checked taxonomy that shows these breaks are five recurring shapes rather than two dozen unrelated accidents. Finding zero new vulnerabilities across a corpus this well-studied is the evidence the taxonomy is real, not a disappointment. No -- "verified" and "secure" are different claims. A Dolev-Yao proof certifies that the protocol *logic* holds against the modeled adversary, and nothing more: the strength of the primitives, the probabilities, and the shipped implementation all sit outside the model. Section 9 draws that line precisely and explains why a clean proof narrows where the remaining risk can live without eliminating it. No. Zerologon is a computational flaw -- AES in CFB8 mode with a zero initialization vector -- that a perfect-crypto symbolic model cannot represent [@cve-2020-1472]. In my Tamarin model, Netlogon also exhibits a structural reflection a symbolic prover can express -- a modeling observation, not a separately published Netlogon weakness -- but the real escalation turns on that arithmetic weakness, which a symbolic model can only be told about, not derive. Section 6 introduces the distinction where the pattern appears, and Section 9 places it exactly on the symbolic/computational boundary. No. The computational layer -- primitives, key sizes, probabilities -- and the implementation layer are both outside symbolic scope. A clean symbolic proof narrows where the risk can live; it does not eliminate it. The right move is to combine symbolic, computational, and code-level tools [@sok-cac]. Because a single one-adversary model turns scattered analogies into a checked taxonomy, and because the same models prove *positive* guarantees that the per-CVE view could never produce -- forward secrecy, key-compromise-impersonation resistance, delegation containment under composition [@cremers-ipsec]. The known breaks are the calibration; the guarantees and the structure are the payoff. Both, for different questions. Symbolic analysis scales to protocol logic across a whole corpus; computational analysis bounds the strength of the primitives; code-level analysis binds a model to the program that runs. The survey's recommendation is a layered stack, not a single winner [@sok-cac]. Section 8 has the full tool-by-tool comparison; the short answer is that ProVerif's speed advantage does not buy much here. The features that define this corpus -- Diffie-Hellman and post-quantum KEM key exchange, credentials whose state changes with every issued ticket, and unbounded sessions that need a concrete counterexample when a proof fails -- are exactly the combination that falls outside ProVerif's comfortable analysis fragment and lands inside Tamarin's [@tamarin-cav] [@proverif-home].

So: was Windows authentication broken, or did it just look broken? The answer the corpus gives is precise. Twenty-three protocols, one adversary, twelve of them pushed harder -- and every break it could exhibit was one already on the record, each reducible to one of five structural shapes: a missing channel binding, an unkeyed integrity check, an untagged symmetric credential, an unbound token, or a restriction that dissolves under composition. The same models that exhibit those breaks also prove the fixes hold, even when you hand the attacker more power than the original analyses dared.

The shapes themselves are old news. Channel binding, keyed integrity, direction tags, audience binding, and delegation protection were each understood when they were each invented. What was missing was a way to say, in one breath and with a machine to back it, that they are the same five mistakes recurring across protocols that share no code -- and to draw the line, exactly, where a symbolic prover stops seeing and Zerologon's arithmetic begins.

That line is the gift. It tells you that "nothing new" is not the tool shrugging; it is the tool reporting, honestly, that the logic is sound and the remaining risk lives one layer down. Carry the five questions with you. The next authentication protocol has not been written yet -- but when it is, you already know the five ways it is most likely to break.

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	No (per-exchange challenge + timestamp added to the response, not a hash salt)
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 the 16-byte MD5 hash of the GSS channel-bindings structure; for TLS EPA, that structure carries the RFC 5929 tls-server-end-point certificate hash, binding the authentication to the HTTPS channel 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]. An MD5 hash of the GSS channel-bindings structure (which carries the server's `tls-server-end-point` certificate hash) 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 enforcement as off, when-supported, and required (WCF `Never` / `WhenSupported` / `Always`) [@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 AD CS web endpoint runs with EPA disabled or merely opportunistic (WCF policyEnforcement="Never" or "WhenSupported"), the binding is not enforced. 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.