Parag Mali - tag: active-directory

The Twenty-Year Local Admin Password Crisis: From GPP cpassword to Windows LAPS

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

**Eleven years separated Microsoft's December 2012 architectural articulation of the shared-local-admin problem from the April 11, 2023 in-box default.** Group Policy Preferences "encrypted" the local Administrator password with an AES key Microsoft published in its own protocol specification (2008-2014). MS14-025 disabled new authoring but deleted no SYSVOL artefacts (2014). Legacy LAPS shipped as a separate MSI with plaintext in `ms-Mcs-AdmPwd` (2015-2023). In-box Windows LAPS finally added CNG DPAPI encryption-at-rest, Microsoft Entra ID backup, and post-authentication rotation. The 2026 default is `BackupDirectory = 2` (AD) or `1` (Entra), `PasswordAgeDays` \<= 30, `ADPasswordEncryptionEnabled` left at its default `True` (the failure mode is silent fallback to plaintext when the domain functional level is below Windows Server 2016, not an off-by-default bit), `ADPasswordEncryptionPrincipal` overridden to a dedicated decryptor group, and `PostAuthenticationActions` left at default `3` (reset + sign out). The residual attack surface is delegated-decryptor compromise, the screenshotted-password OPSEC tail, unmanaged BYOD endpoints, and the multi-decade tail of un-cleaned SYSVOL `cpassword` XMLs that MS14-025 never deleted.

1. One Password, Fifty Thousand Laptops

In May 2012, a domain user with twelve lines of PowerShell could read the local Administrator password for every machine in the organisation. The tool was Get-GPPPassword.ps1 [@obscuresec-gpp-2012]. The "encryption" was AES-256-CBC with a 32-byte key Microsoft had published in its own protocol specification [@ms-gppref-aes-key] -- not leaked, published, as a feature, so that third-party Group Policy implementations could read the format. Eleven years later, on April 11, 2023, Microsoft finally shipped the in-box fix [@tc-windows-laps-ga-2023].

This is an article about those eleven years.

A lateral-movement technique in which an attacker uses the NTLM hash of a captured password directly in an authentication exchange, without recovering the cleartext. If the same local Administrator password is reused across a fleet, one dumped hash unlocks every machine. MITRE catalogues the technique as **T1550.002**.

The pattern was old before 2012. Through the 2000s, the only practical way to provision the local Administrator account on a Windows fleet was to bake one shared password into the reference image and ship the image to every endpoint. Helpdesk knew the password. Pentesters guessed at it. And once Benjamin Delpy's Mimikatz had pulled the hash from a single phished workstation in 2011, the rest of the org fell to a single psexec spray. Microsoft documented the threat model precisely in its December 2012 Mitigating Pass-the-Hash whitepaper [@ms-pth-whitepaper], which named the shared local Administrator credential as the architectural enabler of the entire intrusion class [@mitre-t1550-002].

Microsoft also had a fix. It had shipped one in 2008 with Group Policy Preferences (GPP), the feature that could push a per-machine local-admin password from a Group Policy Object to every endpoint. GPP put the password in an XML file in SYSVOL. SYSVOL was world-readable to every authenticated user in the domain. Microsoft encrypted the password with AES-256-CBC -- and then published the key. The result, after a four-author weaponisation chain in mid-2012 [@sogeti-2012-wayback; @obscuresec-gpp-2012; @rewtdance-gpp-2012; @metasploit-gpp], was that GPP made the original problem worse: instead of one shared password recoverable by physical access to a help-desk laptop, it was now one shared password recoverable by any authenticated domain user with a copy of Get-GPPPassword.ps1. Microsoft "patched" it on May 13, 2014 with MS14-025 [@ms14-025-bulletin], which disabled new authoring but deleted nothing already deployed. Twelve years later, PingCastle still finds the artefacts in production AD [@pingcastle-rules].

The first real fix was Generation 2: the legacy Microsoft LAPS, shipped May 1, 2015 as a separate MSI [@ms-advisory-3062591-wayback]. It stored a per-machine random password in the ms-Mcs-AdmPwd attribute on the computer object, marked CONFIDENTIAL [@adsec-laps-2016]. The directory-side ACL was tighter than SYSVOL, but the deployment surface (install on every endpoint, extend the schema, delegate the OU) capped its real coverage; the password sat in plaintext in AD, one DCSync from "plaintext everywhere"; and a delegation pattern that helpdesks regularly issued -- "All Extended Rights" on the computer OU -- silently included read access to the CONFIDENTIAL attribute [@adsec-laps-2016]. SpecterOps modelled that bypass as the ReadLAPSPassword BloodHound edge on August 7, 2018 [@specterops-bh2].

Generation 3 -- Windows LAPS, in-box, no MSI -- shipped on Patch Tuesday April 11, 2023 [@tc-windows-laps-ga-2023] across Windows 11 22H2 and 21H2, Windows 10 22H2, Windows Server 2022, Windows Server 2019, and Windows Server Annual Channel. Windows Server 2016 was explicitly excluded [@ms-laps-overview]. The new architecture wrapped the password with CNG DPAPI's group key-protector against a configurable principal, exposed Microsoft Entra ID as a peer backup directory [@tc-entra-laps-ga-2023], and added a post-authentication rotation primitive that closed the screenshotted-password OPSEC tail on the next managed-account logon [@ms-laps-policy-settings].

The local Administrator account always has the well-known relative identifier (RID) 500 in the machine's SAM, irrespective of any administrative renaming. Renaming the account at the friendly-name level does not change its SID, which is why Windows LAPS resolves the target account by SID and not by name -- and why an empty AdministratorAccountName policy still finds the right account even on a renamed-built-in host.

Key idea: Microsoft knew the right architecture for managing local Administrator passwords in December 2012, when its own Pass-the-Hash whitepaper named the shared-credential pattern as the architectural enabler of lateral movement. It took until April 11, 2023 to ship that architecture as a Windows default. Eleven years is a long time. The intervening generations each solved part of the previous problem and introduced a new one. The 2026 baseline is, for the first time, an OS-default solution rather than an out-of-band one -- and for the first time, the residual attack surface is the actual surface rather than an artefact of incomplete shipping.

gantt dateFormat YYYY-MM-DD axisFormat %Y title Local-administrator password management on Windows, 1998-2026

section Generation 0 -- Imaged-build era
Shared local admin password baked into image          :gen0, 1998-01-01, 2008-02-26

section Generation 1 -- GPP cpassword
Group Policy Preferences ships in WS2008 RTM           :g1a, 2008-02-27, 2014-05-12
Linda Moore re-posts "Passwords in GPP (Updated)"     :milestone, 2009-04-22, 1d
Sogeti / obscuresec / rewtdance / Metasploit chain    :crit, 2012-04-01, 2012-07-31
MS PtH whitepaper v1 (architecture articulated)       :milestone, 2012-12-01, 1d
MS14-025 disables new authoring (no remediation)      :milestone, 2014-05-13, 1d

section Generation 2 -- Legacy MSI LAPS
Microsoft LAPS GA (KB3062591 MSI)                      :g2a, 2015-05-01, 2023-04-10
Metcalf publishes All-Extended-Rights bypass           :milestone, 2016-08-01, 1d
SpecterOps BloodHound 2.0 ships ReadLAPSPassword edge :milestone, 2018-08-07, 1d

section Generation 3 -- In-box Windows LAPS
Windows LAPS ships in-box (AD backup)                  :crit, 2023-04-11, 2026-12-31
Windows LAPS with Entra ID GA                          :milestone, 2023-10-23, 1d
Win 11 24H2 passphrases and Automatic Account Mgmt    :milestone, 2024-10-01, 1d
Win 11 25H2 Administrator Protection (orthogonal)     :milestone, 2025-11-19, 1d

The article that follows traces the architecture of each generation, the attacks each one solved and each one enabled, and what "standard local admin password management" looks like as a 2026 default. To see why this took twenty years, we have to start in 1998, before Active Directory.

2. Origins: Why Every Workstation Had the Same Local-Admin Password (1998-2008)

Picture a system administrator in 2005. They are holding a CD-R labelled Win-Build-7.iso and a sticky note with a 12-character password. Those two artefacts are the entire local-Administrator-credential lifecycle for ten thousand desktops. The CD will be cloned to a USB drive, the USB drive will reseed Norton Ghost, and Ghost will paint the build onto every new workstation the company buys for the next eight months. Each painted machine will boot with the sticky-note password as its built-in local Administrator. Helpdesk knows the password because they typed it into the image. Five hundred field technicians know the password because they have to be able to recover unmanaged laptops off-network. The pentester who shows up in March will know the password by Tuesday lunch.

This was not a deviation. It was the architecture.

Every Windows machine ships with a built-in local Administrator account whose security identifier ends in the **relative identifier 500**. The RID is constant across machines, languages, and SKUs. Renaming the account changes the friendly name but not the RID, so identity-aware tooling (including Windows LAPS) resolves the account by SID rather than by name. Disabling the account is a configuration choice, not a deletion: the account remains in SAM and can be re-enabled at any time.

The mechanics were a function of how Windows was deployed at scale. Microsoft Sysprep /generalize strips a reference image's machine SID before duplication, but it leaves the SAM intact. Whatever local Administrator password sits in the reference image is the local Administrator password on every endpoint painted from that image. Imaging pipelines were built around this: Norton Ghost in the late 1990s, Microsoft Deployment Toolkit (MDT) and later System Center Configuration Manager Operating System Deployment in the 2000s, all assumed the same SAM. Sean Metcalf's December 2015 SYSVOL retrospective walks the era end-to-end and explains why every shop in the world ended up with a single password [@adsec-gpp-2015].

The operational reality kept the pattern alive. Help-desk needed one known credential to break-glass a laptop that had wandered off the corporate network for six months. Field technicians needed one known credential to swap a failed hard drive on a roof-top kiosk in Houston without phoning home. A known-to-the-org local-admin password was the only realistic fallback path, and the alternative -- a different password per machine, stored somewhere retrievable -- required a retrieval primitive Microsoft had not yet shipped.

The threat model that made the trade-off catastrophic did not get articulated by Microsoft itself until December 2012, in version 1 of the Pass-the-Hash whitepaper [@ms-pth-whitepaper]. The chain was already common knowledge in offensive-security circles: phish a single user, run Benjamin Delpy's 2011-vintage Mimikatz to pull credentials from LSASS, capture the NT hash of the built-in Administrator account, replay that hash to every other host via psexec or wmiexec, and pivot up to the first server an enterprise admin has touched. MITRE catalogues the default-account abuse as T1078.001 [@mitre-t1078-001] and the hash-replay step as T1550.002 [@mitre-t1550-002]. The whitepaper's recommended controls included exactly the architecture Microsoft would eventually ship as LAPS: per-machine random local-admin passwords, rotated frequently, retrievable only by an authorised principal.

The hard part was never the cryptography. It was the operations. A pre-2008 sysadmin who proposed "let's give every workstation a random local-Administrator password" was correctly told that the answer required, at minimum, a directory-scoped retrieval primitive that did not exist; an ACL model that could distinguish "help-desk can read this for their own OU" from "any authenticated user can read this for the whole forest"; and a rotation pipeline that did not depend on the workstation being on the corporate network. Microsoft would not ship those primitives until 2008 (GPP, badly), 2015 (legacy LAPS, well), and 2023 (Windows LAPS, with encryption-at-rest). Until then, "do not get compromised" was the entire mitigation.

The third-party prehistory matters because it set the terms Microsoft would eventually use. PolicyMaker, the engineering parent of what became Group Policy Preferences, was a product of DesktopStandard Corporation that Microsoft acquired in October 2006 [@adsec-gpp-2015]. Thycotic was founded in 1996 by Jonathan Cogley and shipped its Secret Server vault from the mid-2000s [@kuppingercole-cogley]; Lieberman Software (later acquired by Bomgar in January 2018) had operated as Lieberman and Associates since 1978 [@wikipedia-lieberman]; Quest Software was founded in 1987 in Newport Beach, California and was a public company well before the mid-2000s LAPS prehistory began -- its August 14, 1999 NASDAQ IPO saw its shares surge to $47 in a single Wall Street session [@wikipedia-quest; @latimes-quest-ipo-1999]. None of those vendors solved the local-admin-on-every-Windows-machine problem from inside the OS, and Microsoft's own first-party tooling -- restricted groups, logon scripts, Group Policy Object security templates -- offered no rotation primitive at all. The gap was not a knowledge gap; it was a first-party-feature gap.

In February 2008, Microsoft shipped Windows Server 2008. With it came Group Policy Preferences -- and with GPP came a "Local Users and Groups" preference that could push a per-machine local-admin password from a domain GPO to every endpoint in scope. It was the first first-party rotation mechanism Microsoft had ever shipped. It made the problem dramatically worse.

3. Decoration Is Not Encryption: GPP cpassword (2008-2012)

Microsoft Server 2008 reached release-to-manufacturing in February 2008. Group Policy Preferences shipped with it. The new "Local Users and Groups" preference -- alongside Scheduled Tasks, Services, Data Sources, Drive Maps, and Printers -- could push a password from a GPO down to every endpoint in scope. The password went into an XML file in SYSVOL, the domain's replicated policy share. SYSVOL was world-readable to every authenticated user in the domain. The password was AES-256-CBC encrypted in the XML, in a field called cpassword. The key was a 32-byte value published in [MS-GPPREF] section 2.2.1.1.4 [@ms-gppref-aes-key], in Microsoft's own Open Specifications protocol corpus -- as a feature, so that third-party Group Policy implementations could interoperate.

A file share replicated to every Domain Controller in an Active Directory domain, used to distribute Group Policy templates and logon scripts. The default share permissions allow **Read** access to every Authenticated User in the forest. Any file placed in SYSVOL is, operationally, readable by every domain user. The XML attribute defined by `[MS-GPPREF]` that carries an encrypted password inside a Group Policy Preferences item. The encryption is AES-256-CBC with a 16-byte zero IV and a static 32-byte key published in the same protocol specification. The name is short for "ciphertext password" and was the canonical search term for finding deployed credentials in SYSVOL between 2012 and 2026. A loadable component on each Windows endpoint that processes one class of Group Policy setting. Each preference type (Local Users and Groups, Scheduled Tasks, Services, etc.) is implemented by its own CSE, which runs during the Group Policy refresh cycle. CSEs read the policy XML out of SYSVOL, decrypt any `cpassword` field locally, and apply the setting to the host.

Microsoft was not unaware. On April 22, 2009, the Group Policy Team blog re-posted (and updated) a piece by Linda Moore titled "Passwords in Group Policy Preferences (Updated)" [@ms-gp-blog-grouppolicy-2009-wayback]. The phrasing is unambiguous.

the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. -- Linda Moore, Group Policy Team blog, April 22, 2009 [@ms-gp-blog-grouppolicy-2009-wayback]

The post recommended a list of mitigations: prefer secure mechanisms, audit who can read the SYSVOL share, prefer not to use the field at all. None of those mitigations could rotate the key. None could revoke the static AES-256 key value published in [MS-GPPREF]. Microsoft was telling its customers, in 2009, three years and eight months before the public weaponisation, that the credential they were storing was decryptable by every user in the domain by design.

Three years later, the offensive-security community spent twelve weeks turning the publication into a default-on red-team primitive.

In April and May of 2012, Emilien Girault of Sogeti ESEC published a Python decryptor on the firm's research blog [@sogeti-2012-wayback]. The site has since been retired and the canonical reference is the Wayback Machine capture. In mid-May 2012, Chris Campbell (@obscuresec) published Get-GPPPassword.ps1, a PowerShell port that fetched the relevant XML from SYSVOL, decoded the base64, and called .NET's AES primitives with the published key [@obscuresec-gpp-2012]. The script was folded into PowerSploit at Exfiltration/Get-GPPPassword.ps1, where its header still reads "Author: Chris Campbell (@obscuresec)" [@powersploit-getgpppwd] and explicitly credits Emilien Girault for the underlying research. In June 2012, Ben Campbell (the rewtdance.blogspot.com blog handle), working with scriptmonkey (a named collaborator with his own blog at blog.owobble.co.uk), extended the attack to all six XML wire-format carriers that [MS-GPPREF] permits [@rewtdance-gpp-2012]. The rewtdance post body credits the collaboration verbatim: "Working with scriptmonkey (http://blog.owobble.co.uk/), who already had a DC configured, we verified this theory." On July 25, 2012, the Metasploit module post/windows/gather/credentials/gpp.rb landed [@metasploit-gpp] with five co-authors: Ben Campbell, Loic Jaquemet, scriptmonkey, theLightCosine, and mubix. A companion auxiliary scanner, auxiliary/scanner/smb/smb_enum_gpp.rb, was authored independently by Joshua D. Abraham of Praetorian [@metasploit-smb-enum-gpp].

Note: A widespread folk attribution credits Get-GPPPassword.ps1 to "scriptjunkie." The primary sources do not support that claim. The PowerSploit script header credits Chris Campbell (@obscuresec) [@powersploit-getgpppwd]; the rewtdance June 2012 follow-up is by Ben Campbell with scriptmonkey as a named collaborator (scriptmonkey blogs at blog.owobble.co.uk, not at rewtdance) [@rewtdance-gpp-2012]; the Metasploit gpp.rb module's author field names Ben Campbell, Loic Jaquemet, scriptmonkey, theLightCosine, and mubix [@metasploit-gpp]; and the smb_enum_gpp scanner is by Joshua D. Abraham [@metasploit-smb-enum-gpp]. No primary source ties "scriptjunkie" (Matt Weeks) to the GPP cpassword research chain at all. The names are similar; the people are different.

The whole exercise was twelve lines of code. The interesting part was not the cryptography. The interesting part was that the operation was decryption-by-reference: with a published key, the AES envelope was not protecting a secret, it was carrying a secret in a format the protocol specification told everyone how to read.

``` 4e 99 06 e8 fc b6 6c c9 fa f4 93 10 62 0f fe e8 f4 96 e8 06 cc 05 79 90 20 9b 09 a4 33 b6 6c 1b ``` These bytes are reproduced verbatim from Microsoft's published `[MS-GPPREF]` Group Policy Preferences specification [@ms-gppref-aes-key]. They have appeared in the public Microsoft Open Specifications corpus since the `[MS-GPPREF]` protocol document was first published as part of the Windows Server 2008 protocol-documentation programme; the earliest tangible third-party reuse of the key dates to the April-July 2012 Sogeti / obscuresec / rewtdance / Metasploit research chain [@sogeti-2012-wayback; @obscuresec-gpp-2012; @rewtdance-gpp-2012; @metasploit-gpp]. The key is *not* a secret; it is an interoperability primitive.

ReadSucceeds["Read succeeds (silent CONTROL_ACCESS bypass)"]
ReadFails["Read fails (correctly ACL-gated)"]
Endpoint --> GPRefresh
GPRefresh --> Rotate
Rotate --> SAMWrite
Rotate --> ADWrite
ADWrite --> LDAPRead
LDAPRead --> Bypass
Bypass -- yes --> ReadSucceeds
Bypass -- no --> ReadFails

The other structural limit was the directory's own integrity boundary. The password sat in plaintext in the directory. A stolen NTDS.dit -- obtained via DCSync, NTDSUtil dump, or physical theft of a DC's disk -- exposed every managed local-Administrator password in the forest at once. There was no encryption-at-rest in legacy LAPS, by design. The trust model was "the directory is tier 0 and DCSync is a domain-compromise event already," which is operationally true and architecturally lazy.

Microsoft fixed both of those structural defects on April 11, 2023. The fix shipped in the operating system, with no MSI. We come to it next.

6. The In-Box Era: Windows LAPS (April 11, 2023 to Present)

Patch Tuesday, April 11, 2023. The April cumulative update for Windows 11 22H2 was KB5025239. The Windows 11 21H2 update was KB5025224. Windows 10 22H2 was KB5025221. Windows Server 2022 was KB5025230. Windows Server 2019 was KB5025229. The Server Annual Channel shipped it too. Windows Server 2016 was, and remains, explicitly excluded -- the per-SKU April-2023 cumulative-update KB numbers are catalogued in the Tenable retrospective on the Windows LAPS GA wave [@tc-windows-laps-ga-2023] and the official Microsoft LAPS overview page [@ms-laps-overview]. The MSI was gone. The admpwd.dll Client-Side Extension was gone. In its place: exactly three OS binaries -- laps.dll for core LAPS logic, lapscsp.dll for the Microsoft Intune Configuration Service Provider, and lapspsh.dll for the LAPS PowerShell module -- all shipped together, all part of the OS, all available without installing anything [@ms-laps-concepts-overview; @tc-windows-laps-ga-2023]. The Microsoft Learn laps-concepts-overview page enumerates the three binaries verbatim and lists no fourth.

The most consequential architectural change is the one most often missed.

Note: The legacy admpwd.dll was a Group Policy CSE; its rotation cycle was driven by the GP refresh interval (90 minutes plus jitter on member computers). The new laps.dll is not a CSE. It runs on a hard-coded in-process background timer of approximately one hour inside laps.dll itself -- not a Windows Task Scheduler task, and not configurable. The cited Microsoft Learn page is unambiguous: "Windows LAPS uses a background task that wakes up every hour to process the currently active policy. This task isn't implemented with a Windows Task Scheduler task and isn't configurable." The polling cycle is decoupled from the Group Policy refresh cycle entirely [@ms-laps-concepts-overview]. The implications: the rotation cadence is not configurable below one hour; reducing the GP refresh interval does not accelerate LAPS rotation; the Task Scheduler library will not show a LAPS task because there isn't one; and Windows LAPS will rotate a password on an off-network domain-joined machine the moment it re-establishes line-of-sight to a Domain Controller, regardless of whether a GP refresh has fired.

The new schema added six attributes to the Computer object: msLAPS-Password (the plaintext-fallback location), msLAPS-EncryptedPassword (the CNG-DPAPI-wrapped ciphertext blob), msLAPS-EncryptedPasswordHistory (rotation history), msLAPS-PasswordExpirationTime, msLAPS-EncryptedDSRMPassword (Directory Services Restore Mode account on a DC), and msLAPS-EncryptedDSRMPasswordHistory [@ms-laps-concepts-overview]. The DSRM pair is a Windows-LAPS-only capability; legacy LAPS never covered Domain Controller DSRM accounts. The schema extension is performed once per forest by Update-LapsADSchema, which is idempotent and coexists with the legacy ms-Mcs-AdmPwd attribute [@ms-laps-mig-scenarios].

A seventh attribute, msLAPS-CurrentPasswordVersion, exists in the Windows Server 2025 forest schema only. It is added automatically when the first Windows Server 2025 Domain Controller is promoted -- not by running Update-LapsADSchema -- and is used by laps.dll to mitigate a virtual-machine-snapshot torn-state class. The attribute is read-only as far as the LAPS feature is concerned and is not part of the ReadLAPSPassword BloodHound edge's calculus [@ms-laps-concepts-overview].

Encryption-at-rest with CNG DPAPI

The load-bearing addition is encryption of the password before it leaves the client. The mechanism is the CNG DPAPI group key-protector (still commonly called DPAPI-NG in Microsoft's older documentation) [@ms-cng-dpapi]. The client generates the new local-Administrator password, then wraps the plaintext against a security principal SID using the Active Directory Key Distribution Service (KDS) root key infrastructure. The wrapped blob is the only thing the LDAP write places into msLAPS-EncryptedPassword. To decrypt, a reader Kerberos-authenticates to the KDC; only members of the configured principal group at decryption time can derive the protector. The directory itself never sees plaintext, and a stolen NTDS.dit yields ciphertext only [@ms-laps-concepts-overview].

A protection mechanism in Windows's CNG (Cryptography API: Next Generation) Data Protection API in which a payload is encrypted against a security principal -- typically an AD group SID -- rather than against a local user. Decryption is gated by Kerberos authentication and the principal's group membership at the time of decryption [@ms-cng-dpapi]. Microsoft Learn currently spells the primitive *"CNG DPAPI"* on the canonical reference; older Microsoft documentation and Win32 references continue to use the shorthand *"DPAPI-NG"*. They are the same primitive.

There are two policy settings that gate the encryption path, and the failure modes are operationally important.

Note: Microsoft Learn's laps-management-policy-settings page lists ADPasswordEncryptionEnabled with a default of True [@ms-laps-policy-settings]. The genuine failure mode is not an unset default; it is silent fallback to plaintext in msLAPS-Password when (a) the forest's Domain Functional Level is below Windows Server 2016, or (b) the BackupDirectory value is not 2 (AD). Configure the policy explicitly anyway: the explicit configuration makes the choice visible to policy audits and forces the operator to verify the DFL prerequisite. Do not flip a bit that is already True; do verify the prerequisites that make True work.

Note: When ADPasswordEncryptionPrincipal is unspecified, Windows LAPS wraps the password against the Domain Admins group of the computer's domain [@ms-laps-concepts-overview; @ms-laps-policy-settings]. Most fleets do not want every Domain Admin to be a routine LAPS reader. Configure a dedicated, audited, minimum-membership decryption group (a common naming convention is LAPS-DPAPI-Decryptors) and assign it explicitly. Decryption authority is delegated separately from LDAP read authority; minimising membership of the decryption group is the single most useful hardening lever on a Windows LAPS deployment.

The backup-directory choice

The CSP / GPO node `BackupDirectory` selects where Windows LAPS writes the rotated password. The three valid values are **0** (do not back up; passwords rotate locally but are not retrievable), **1** (Microsoft Entra ID via the `deviceLocalCredentials` resource on Microsoft Graph), and **2** (Active Directory via the `msLAPS-*` attribute set). The values are mutually exclusive per device; a hybrid-joined device can choose either backend but not both [@ms-laps-policy-settings; @ms-laps-entra-scenarios].

The Entra-backup path went generally available on October 23, 2023 [@tc-entra-laps-ga-2023]. With BackupDirectory = 1, the local LAPS component posts the rotated password to the deviceLocalCredentials resource on the device object in Microsoft Entra ID via the Microsoft Graph API [@ms-graph-localcredinfo]. Retrieval is via Get-LapsAADPassword (a thin wrapper over the Graph endpoint), the Entra portal Devices blade, or a direct GET /directory/deviceLocalCredentials/{deviceId} call [@ms-laps-entra-scenarios].

The Entra-backup path has a seven-day minimum for PasswordAgeDays. The AD-backup path's minimum is one day. A tier-0 fleet that targets daily rotation on Entra-joined endpoints will not get daily rotation -- Entra-side policy validation rejects the value. Section 7's baseline table reflects this asymmetry.

Policy surface and the FQ-anchored corrections

Windows LAPS is configurable via Group Policy (for AD-joined hosts), the LAPS Configuration Service Provider at ./Device/Vendor/MSFT/LAPS/Policies/* for Intune-managed hosts [@ms-laps-csp], local policy, or the legacy LAPS GPO if PolicySourceMode selects emulation mode. The settings include BackupDirectory, PasswordComplexity (values 1 through 8), PasswordLength, PasswordAgeDays, PostAuthenticationActions, PostAuthenticationResetDelay, AdministratorAccountName, PassphraseLength, ADPasswordEncryptionEnabled, ADPasswordEncryptionPrincipal, and ADBackupDSRMPassword. On Windows 11 24H2 and Windows Server 2025 and later, the policy surface adds Automatic Account Management settings: AutomaticAccountManagementEnabled, AutomaticAccountManagementNameOrPrefix, AutomaticAccountManagementRandomizeName, AutomaticAccountManagementTarget, and AutomaticAccountManagementEnableAccount [@ms-laps-policy-settings; @ms-laps-account-modes].

The action Windows LAPS performs after the managed account has authenticated to the host. Valid values are **1** (reset the password), **3** (reset and sign out the interactive session; default), **5** (reset and reboot, with a one-minute reboot delay), and **11** (reset, sign out, and terminate remaining processes; Windows 11 24H2 / Windows Server 2025 and later). The action fires after `PostAuthenticationResetDelay` hours have elapsed since the authentication that triggered it [@ms-laps-policy-settings].

Note: A widespread misreading of the older Microsoft documentation lists PostAuthenticationActions as a 1-2-3 enum. The correct enumeration per the current Microsoft Learn reference [@ms-laps-policy-settings] is 1 (reset password), 3 (reset + sign out; default), 5 (reset + reboot), and 11 (reset + sign out + terminate remaining processes; Win 11 24H2 / Server 2025+). Value 11 is not "force shutdown without warning"; interactive users receive the same non-configurable two-minute warning as on value 3, and remaining processes are terminated after the warning expires. SMB sessions on the host are deleted on values 3 and 11.

PostAuthenticationResetDelay defaults to 24 hours. The range is 0 to 24 hours; a value of 0 disables the post-authentication action entirely [@ms-laps-policy-settings]. A tier-0 fleet aiming to close the screenshotted-password OPSEC tail aggressively will configure this down to 1 hour; tier-2 deployments typically leave it at 8 or 24.

PasswordComplexity values 5 through 8 (Windows 11 24H2+ / Windows Server 2025+)

PasswordComplexity values 1 through 4 are character-class modes (uppercase only; uppercase plus lowercase; uppercase plus lowercase plus numbers; and -- value 4, the default -- all four character classes). Value 5 is not a "no vowels or numbers" mode, despite a common folk attribution; it is the "improved readability" four-class variant of value 4, equivalent to value 4 with the visually ambiguous glyphs I, O, Q, l, o, 0, 1 removed and the symbols :, =, ?, * added [@ms-laps-passwords-passphrases]. Microsoft's own documented example password for value 5 is vnJ!!?MTb5=U7Y -- which retains vowels and digits 2 through 9. Values 6, 7, and 8 are passphrase modes drawn from a Microsoft-curated wordlist derived from the EFF Diceware wordlists [@eff-dice; @eff-wordlists-2016] with internal modifications. The published word counts after Microsoft's curation are 7776 / 1276 / 1276 for modes 6 / 7 / 8 respectively; the EFF originals (the EFF Long Wordlist, EFF Short Wordlist #1, and EFF Short Wordlist #2 published July 2016) are 7776 / 1296 / 1296 [@eff-dice; @eff-wordlists-2016]. Values 5 through 8 are all gated on Windows 11 24H2 / Windows Server 2025 and later -- not only values 6-8. The cited Microsoft Learn page reads verbatim for value 5: "The PasswordComplexity setting of '5' is only supported in Windows 11 24H2, Windows Server 2025, and later releases." [@ms-laps-passwords-passphrases]. Passphrase modes exist for DSRM-account scenarios where the password must be typed by a human under duress; the article's section 7 baseline recommends them for tier-0 break-glass accounts.

PowerShell surface and one important cmdlet name

The native LAPS PowerShell module ships eight cmdlets the article calls out by name: Get-LapsADPassword, Reset-LapsPassword, Update-LapsADSchema, Set-LapsADAuditing, Set-LapsADComputerSelfPermission, Set-LapsADReadPasswordPermission, Set-LapsADResetPasswordPermission, and Find-LapsADExtendedRights [@ms-laps-ps-overview; @ms-laps-get-adpassword]. The auditing cmdlet is Set-LapsADAuditing -- not Set-LapsADAuditingSettings, which does not exist as a cmdlet name [@ms-laps-set-adauditing]. The Entra-backup retrieval cmdlet is Get-LapsAADPassword, a wrapper around Microsoft Graph.

Note: A common copy-paste error in deployment runbooks is to write Set-LapsADAuditingSettings. The cmdlet name is Set-LapsADAuditing [@ms-laps-set-adauditing], and the cmdlet emits Directory Service audit event 4662 on configured attribute reads. The SACL it installs targets the LAPS attribute set; you still need the host-side Audit Directory Service Access subcategory enabled on Domain Controllers for the event to land in the Security log.

Migration coexistence

Legacy LAPS and Windows LAPS can coexist on the same host only if they target different local accounts. The documented coexistence pattern is to run legacy LAPS against the built-in RID 500 Administrator while introducing Windows LAPS against a named secondary local-admin account, then retire the legacy MSI once Windows LAPS coverage is verified [@ms-laps-mig-scenarios]. The cross-pointer in section 11 details the seven-step migration sequence.

flowchart TD Tick["laps.dll background timer (~1 hr)"] ReadPolicy["Read effective policy
CSP > GPO > local > legacy emulation"] BackupDir{"BackupDirectory
1 (Entra) / 2 (AD) / 0?"} EntraPath["Write to Graph deviceLocalCredentials
(min PasswordAgeDays = 7)"] ADPath["Write to msLAPS-* attribute set
(min PasswordAgeDays = 1)"] EncryptionGate{"ADPasswordEncryptionEnabled = True
AND DFL ≥ Server 2016?"} Encrypted["msLAPS-EncryptedPassword
(DPAPI-NG, principal = ADPasswordEncryptionPrincipal)"] Plaintext["msLAPS-Password (plaintext fallback)"] SetSAM["Set SAM password on
AdministratorAccountName (empty = RID 500)"] Auth["Managed account authenticates"] PAA{"PostAuthenticationActions
0 / 1 / 3 / 5 / 11?"} Wait["Wait PostAuthenticationResetDelay (default 24 h)"] Action1["1: reset password"] Action3["3: reset + sign out, 2-min warning, DEFAULT"] Action5["5: reset + reboot, 1-min delay"] Action11["11: reset + sign out + terminate procs (24H2 / WS2025+)"] Tick --> ReadPolicy ReadPolicy --> BackupDir BackupDir -- 1 --> EntraPath BackupDir -- 2 --> EncryptionGate BackupDir -- 0 --> SetSAM EncryptionGate -- yes --> Encrypted EncryptionGate -- no --> Plaintext EntraPath --> SetSAM Encrypted --> SetSAM Plaintext --> SetSAM SetSAM --> Auth Auth --> Wait Wait --> PAA PAA -- 1 --> Action1 PAA -- 3 --> Action3 PAA -- 5 --> Action5 PAA -- 11 --> Action11

With the in-box era settled, what does a 2026 deployment actually look like? A short list of policy settings, and a slightly longer list of footguns.

7. The 2026 Baseline as a Settings Table

Architecture is interesting. Audits are not. Here is the 2026 settings table that, in production, separates a deployment that meets its goal from one that quietly does not. Every row carries the policy node, the documented default, the recommended tier-2 value (a typical end-user fleet), the recommended tier-0 value (Domain Controllers and break-glass), and the citation. Cross-check the row against the Microsoft Learn policy-settings page before you ship it.

Policy	Default	Recommended (tier 2)	Recommended (tier 0)	Why	Citation
`BackupDirectory`	`0` (no backup)	`2` (AD) for AD-joined and hybrid-joined; `1` (Entra) for pure Entra-joined	same as tier 2	One directory per device; AD for hybrid where on-prem identity is canonical	[@ms-laps-policy-settings]
`PasswordComplexity`	`4` (all character classes)	`4`	`6` (3-word passphrase) for accounts a human must type under duress (DSRM / break-glass); `4` for automated retrieval	Passphrases for human typing; character-set for tool-only retrieval. Values 5 through 8 are gated on Windows 11 24H2 / Windows Server 2025 and later: value 5 is the "improved-readability" four-class variant of 4 (not a "no vowels" mode); values 6/7/8 are passphrase modes with Microsoft-curated EFF-derived wordlists of 7776 / 1276 / 1276 entries (EFF originals: 7776 / 1296 / 1296)	[@ms-laps-passwords-passphrases; @eff-dice; @eff-wordlists-2016]
`PasswordLength`	`14`	`24`	`24`	Eliminates the rainbow-table threat class	[@ms-laps-passwords-passphrases]
`PasswordAgeDays`	`30` (1-day minimum AD; 7-day minimum Entra; 365-day max)	`30`	`1` (AD) / `7` (Entra; lower fails policy validation)	Caps the blast radius of an undetected credential theft to one rotation window	[@ms-laps-policy-settings]
`PostAuthenticationActions`	`3` (reset + sign out)	`3`	`3`, or `11` on Win 11 24H2+ if process termination is required	Closes the screenshot-leak OPSEC tail on the next managed-account interactive logon. Value `11` is not "force shutdown without warning" -- it is reset + sign out + terminate remaining processes with the same two-minute warning as `3`	[@ms-laps-policy-settings]
`PostAuthenticationResetDelay`	`24` (hours)	`8`	`1`	Trade-off between operational task completion and exposure window	[@ms-laps-policy-settings]
`ADPasswordEncryptionEnabled`	`True` per Microsoft Learn's defaults table -- not off-by-default	`True`, configured explicitly so the choice is visible in policy audits and the DFL prerequisite is verified	same	The genuine failure mode is silent fallback to plaintext when DFL is below Server 2016 or `BackupDirectory` is not `2`, not a default-off bit	[@ms-laps-policy-settings; @ms-laps-csp]
`ADPasswordEncryptionPrincipal`	`Domain Admins` of the computer's domain when unspecified	Dedicated `LAPS-DPAPI-Decryptors` group, not Domain Admins	same, with PIM-gated activation	Decryption authority is delegated separately from LDAP read; minimise membership	[@ms-laps-concepts-overview]
`AdministratorAccountName`	empty (manages built-in RID 500)	empty on Server SKUs; named account (e.g. `lapsadmin`) on Client SKUs with the built-in disabled	On Win 11 24H2 / WS2025+, prefer Automatic Account Management with random name and disabled-by-default	Defeats predictable-RID-500 enumeration	[@ms-laps-policy-settings; @ms-laps-account-modes]
`ADBackupDSRMPassword`	`False`	n/a (member servers)	`True` on Domain Controllers	Brings DSRM-account management into LAPS scope -- a capability legacy LAPS never had	[@ms-laps-concepts-overview]

Tier-0 deviations from the tier-2 baseline are narrow but consequential. (a) `PasswordAgeDays` to 1 (AD) or 7 (Entra) caps the undetected-theft window. (b) `PostAuthenticationResetDelay` to 1 hour aggressively rotates after legitimate use. (c) `ADPasswordEncryptionPrincipal` to a dedicated decryptor group with PIM-gated activation [@ms-entra-pim] -- not standing membership. (d) `ADBackupDSRMPassword = True` only on DCs, so the Directory Services Restore Mode account is in LAPS scope. (e) `PasswordComplexity = 6` on accounts that a human must type under duress (DSRM, ESAE break-glass), `4` everywhere else. The tier-0 baseline is more expensive operationally -- daily rotation and 1-hour post-auth delay create a non-trivial volume of password reads through the decryption group -- and the cost is the entire point. Anything cheaper does not warrant the tier-0 label.

Note: The single most useful hardening move on a Windows LAPS deployment is to explicitly set ADPasswordEncryptionPrincipal to a dedicated group with minimum membership. Default = Domain Admins of the computer's domain is operationally correct (Domain Admins should be the readers of last resort) but architecturally lazy (most fleets do not want their DA group to be the routine LAPS-read group). Name the group something searchable -- LAPS-DPAPI-Decryptors is a defensible convention -- and put helpdesk LAPS-read permissions in that group, gated by Entra PIM activation [@ms-entra-pim] for non-emergency reads.

The audit-primitives sub-table

The decision of which tool answers which question is, in practice, the difference between a LAPS deployment that meets its goal and one that quietly does not. The five (and a half) primitives:

Primitive	Question it answers	Primary source
BloodHound `ReadLAPSPassword` edge	Which principals can read the LAPS password on which computer objects, transitively across the graph?	[@bloodhound-edge-readlaps]
PingCastle `A-LAPS-Not-Installed`	Does this domain have any LAPS solution installed for the native local administrator account?	[@pingcastle-rules]
PingCastle `A-LAPS-Joined-Computers`	Can a user who manually domain-joined a computer (via `mS-DS-CreatorSID` ownership) still read that computer's LAPS password?	[@pingcastle-rules]
PingCastle `A-PwdGPO`	Does this domain still have residual GPP `cpassword` artefacts in SYSVOL? (MITRE T1552.006)	[@pingcastle-rules; @mitre-t1552-006]
Windows event 4662 on `msLAPS-*` (SACL via `Set-LapsADAuditing`)	Who read which LAPS attribute on which computer object, and when?	[@ms-laps-set-adauditing; @ms-laps-ps-overview]
Entra audit log + Graph `GET /directory/deviceLocalCredentials/{deviceId}` reads	Who retrieved which LAPS password from Microsoft Entra ID (`BackupDirectory = 1`), and when?	[@ms-graph-localcredinfo; @ms-laps-entra-scenarios]

No Microsoft Defender for Identity alert in the current public taxonomy names LAPS specifically [@ms-defender-alerts]; instead, lean on the event 4662 SACL primitive plus advanced hunting in the IdentityDirectoryEvents table for principal-pattern anomalies. Microsoft's Compromised Credentials and Lateral Movement categories surface the downstream behaviour when a stolen LAPS password gets used.

{` // In production, run: Get-LapsADPassword -Identity * | Where-Object { // $.ExpirationTimestamp -lt (Get-Date) -or $.Source -eq 'Plaintext' // } // This in-browser demo mirrors the same logic against an array of mock computer objects.

const ONE_DAY_MS = 86400000; const computers = [ { name: "WS-001", msLapsExpiry: Date.now() + 5 * ONE_DAY_MS, encrypted: true }, { name: "WS-002", msLapsExpiry: Date.now() - 2 * ONE_DAY_MS, encrypted: true }, { name: "WS-003", msLapsExpiry: null, encrypted: false }, { name: "WS-004", msLapsExpiry: Date.now() + 1 * ONE_DAY_MS, encrypted: false }, ];

console.log(gaps.length === 0 ? "All computers have current, encrypted LAPS passwords" : "Coverage gaps:\n " + gaps.join("\n ")); `}

The AdministratorAccountName decision deserves one paragraph of its own. On Server SKUs, the built-in Administrator (RID 500) is enabled by default, and leaving the policy empty manages it -- this is what most deployments want. On Client SKUs the built-in is disabled by default; many shops create a named admin account (a common convention is lapsadmin) and set AdministratorAccountName to that name. On Windows 11 24H2 and Windows Server 2025 and later, the better answer is Automatic Account Management: set AutomaticAccountManagementEnabled = 1, AutomaticAccountManagementRandomizeName = 1, and AutomaticAccountManagementEnableAccount = 0, and the host will auto-create a randomised-name disabled-by-default local-admin account that Windows LAPS owns end to end [@ms-laps-account-modes]. The result is that an attacker enumerating local accounts cannot guess the LAPS-managed account name from RID 500, RID 1000, or any other predictable identifier.

This is the baseline. But LAPS is not the only answer to "who knows the local admin password." For three classes of fleet, the right answer is something else.

8. When LAPS Is Not the Right Tool

Three classes of fleet should not -- or should not only -- run Windows LAPS. The first wants a workflow LAPS does not offer. The second wants no standing local admin at all. The third is orthogonal: it changes the in-session elevation surface without changing the recoverable break-glass.

Third-party Privileged Access Management (PAM) vaults. Delinea Secret Server [@delinea-secretserver], CyberArk Endpoint Privilege Manager [@cyberark-epm], and BeyondTrust Password Safe are the dominant 2026 commercial offerings in the category. The case for running a PAM vault alongside (or instead of) Windows LAPS is rarely about cryptography and almost always about workflow. PAM vaults bring multi-factor authentication on checkout, full session recording, dual-approval gates for high-risk accounts, and cross-OS scope (Windows, macOS, Linux, network gear, hypervisors) under one ACL model. The total cost of ownership is higher than LAPS; the security model, properly deployed, is comparable. Many shops run both: Windows LAPS for the workstation floor, PAM for tier-0 break-glass with session recording. The split is a workflow trade-off, not an architectural one.

Zero standing local admin plus Entra PIM JIT elevation. Tier-0 fleets that have reached the "no routine local admin" architectural state disable the built-in RID 500 entirely and gate every admin operation through just-in-time elevation. Microsoft Entra Privileged Identity Management [@ms-entra-pim] supports the eligibility / activation / approval workflow at scale: an operator is eligible for an admin role, activates it for a bounded duration with optional MFA and ticket reference, and an approver signs off on the activation if policy requires. Windows LAPS coexists in this model as the absolute-last-resort break-glass mechanism -- for the case where Entra itself is down, the network is partitioned, and a human has to walk to a console and type a password. The architectural alignment is with MITRE T1078.001 (Default Accounts) [@mitre-t1078-001]: if the default account is permanently disabled and only re-enabled under PIM workflow, the entire technique class is bounded by the PIM activation log.

Windows 11 25H2 Administrator Protection. Per-elevation transient admin sessions arrived as a Tech Community preview in late 2025 [@tc-admin-protection-win11]. The feature creates a temporary, isolated "shadow admin" identity for the duration of each elevation prompt, brokering UAC-class elevation through a per-elevation token that is destroyed when the elevated process exits. This is orthogonal to LAPS, not a replacement. Administrator Protection addresses in-session UAC elevation; Windows LAPS addresses the recoverable break-glass password for off-network and non-bootable recovery. The two systems answer different questions. Conflating them produces designs that drop LAPS in favour of Administrator Protection and then discover, six months later, that there is no recovery primitive for a laptop the user has dropped off the corporate network for a year.

Situation	Recommended method
On-premises AD-joined, no Entra ID	A -- in-box Windows LAPS with AD backup
Microsoft Entra hybrid-joined, on-prem AD authoritative	A -- Microsoft's current hybrid recommendation
Pure Entra-joined, no on-prem AD	B -- in-box Windows LAPS with Entra ID backup
Stuck on Windows Server 2016 (excluded from Windows LAPS)	C -- legacy MSI LAPS until OS migration completes
In active migration from legacy LAPS to Windows LAPS	C in side-by-side mode with different managed accounts
Non-Windows scope (Linux, macOS, network gear) needs unified vaulting	D -- third-party PAM vault, often alongside A/B
Regulated industry requiring session recording / MFA checkout	D alongside A/B
Tier-0 fleet with a zero-standing-credential goal and Entra ID P2	E -- PIM-gated JIT elevation layered on A or B
Windows 11 fleet wanting in-session credential-theft mitigation	F -- Administrator Protection alongside A/B (orthogonal)
BYOD, workgroup, or unmanaged endpoints	None of A through F -- enrollment is the answer, not LAPS

flowchart TD Start["Local-admin password problem for a fleet"] BYOD{"BYOD or unmanaged?"} EnrollFirst["Enrollment is the answer, not LAPS"] Join{"AD-joined / hybrid / Entra-joined?"} WS2016{"Stuck on WS2016 or in migration?"} Tier0{"Tier 0 with zero-standing-credential goal?"} CrossOS{"Non-Windows scope or checkout workflow needed?"} WinElev{"Win 11 25H2 in-session elevation hardening?"} MA["Method A: Windows LAPS, AD backup"] MB["Method B: Windows LAPS, Entra backup"] MC["Method C: legacy MSI LAPS"] MD["Method D: PAM vault, alongside A/B"] ME["Method E: PIM-gated JIT, layered on A/B"] MF["Method F: Administrator Protection (orthogonal)"] Start --> BYOD BYOD -- yes --> EnrollFirst BYOD -- no --> Join Join -- AD or hybrid --> MA Join -- pure Entra --> MB MA --> WS2016 MB --> WS2016 WS2016 -- yes --> MC WS2016 -- no --> Tier0 Tier0 -- yes --> ME Tier0 -- no --> CrossOS CrossOS -- yes --> MD CrossOS -- no --> WinElev WinElev -- yes --> MF The terminology is genuinely confusing. *Microsoft Entra hybrid joined* is a device join state: the workstation is joined to both an on-premises AD domain and Microsoft Entra ID, and both directories know about it. *Microsoft Entra hybrid runbook worker*, by contrast, is an Azure Automation primitive that runs Automation runbooks on a worker process inside an on-premises environment. They share a word and nothing else. Windows LAPS policy for hybrid-*joined* devices is a `BackupDirectory` choice (typically AD for on-prem-authoritative hybrid fleets, Entra for Entra-authoritative); Hybrid runbook workers are an Azure Automation concern and entirely outside the LAPS scope.

All five answers above -- methods A through F -- have a structural ceiling. There is one bound none of them can break.

9. What LAPS Structurally Cannot Solve

Every recoverable-secret system has a privileged reader. Whether you call it ADPasswordEncryptionPrincipal, a "CyberArk vault admin," or a "PIM eligible approver," somebody can break the glass -- which means somebody can compromise the glass. This is a lower bound, not an implementation defect.

The eleven-year arc converged on a tight bound. It did not abolish the underlying problem. Four structural limits are worth naming, because each maps onto a real residual attack surface in 2026 deployments.

Bound 1: at least one reader exists, by construction. Symbolically, $|\text{readers}| \geq 1$. CNG DPAPI's group-key-protector substitution does not eliminate the privileged class; it relocates the trust boundary. The boundary moves from "every principal with LDAP read on the attribute" (legacy LAPS) to "every principal in the configured ADPasswordEncryptionPrincipal group at decryption time" (Windows LAPS). The relocation tightens the bound by orders of magnitude in typical fleets -- a LAPS-DPAPI-Decryptors group with five members beats an "All Extended Rights on the helpdesk OU" delegation with five hundred -- but it does not move the bound to zero. The directory that stores the LAPS secret remains a tier-0 asset, and the decryptor group remains a tier-0 principal class.

Every recoverable secret has a privileged reader. The architectural game is to make the reader class small, audited, time-bounded, and reachable from the directory only through Kerberos. The game is not to make the reader class empty. That game has no winning move.

Bound 2: the out-of-protocol OPSEC tail. Once a plaintext password leaves the directory -- pasted into a helpdesk ticket, screenshotted into a Slack DM, stored in a shared KeePass database that the team forgot to rotate -- the protocol's rotation knob is the only remaining mitigation. PostAuthenticationActions only fires after the next managed-account interactive logon [@ms-laps-policy-settings]; pre-logon exposure is bounded only by PasswordAgeDays. A password screenshotted into a chat log at 10:14 AM and never used is the password on that endpoint for the remainder of the configured rotation window, regardless of whether anyone has noticed the leak. The protocol does not, and cannot, solve "the password is now in a chat log."

Bound 3: unmanaged and BYOD endpoints. A machine that is neither AD-joined nor Microsoft Intune-managed has no LAPS policy applied to it. Personal-device BYO MAM scope is outside the LAPS protection model entirely. The fix for these endpoints is enrollment, not LAPS. A non-trivial portion of the residual local-admin-password risk in 2026 is concentrated on the long tail of unmanaged endpoints that exist precisely because management was politically or contractually infeasible. The protocol does not solve this; governance solves this.

Bound 4: verification asymmetry. The directory's audit log says what it chose to log. An unprivileged observer cannot verify enforcement from outside the directory. This is the structural ceiling that motivates external audit primitives -- PingCastle [@pingcastle-rules], BloodHound [@bloodhound-edge-readlaps], Defender for Identity [@ms-defender-alerts] -- because they sit outside the directory's own self-report. The bound cannot be closed inside the protocol; only an out-of-band attestation primitive can certify enforcement to a party that does not trust the directory.

Key idea: Somebody has to break the glass. The decryptor group is the new tier-0 asset; LAPS bounds the problem, it does not abolish it. The eleven-year arc was a convergence on a tighter bound, not an arrival at a clean answer. The right framing for the 2026 baseline is "the residual attack surface is now the actual attack surface, rather than an artefact of incomplete shipping." That is real progress -- it just is not closure.

A structurally tighter design would have three properties: threshold cryptography so no single principal can decrypt (an $m$-of-$n$ Shamir secret-sharing scheme over the password protector, with $m \geq 2$ in tier-0 fleets); attestation-bound retrieval so the decryptor's device state is part of the decryption policy (Azure Managed HSM's secure-key-release policy grammar [@ms-mhsm-policy-grammar] is the closest shipping primitive that approaches this -- a key-release decision conditioned on attestation claims like `x-ms-attestation-type` or `tee:sevsnpvm`); and a ledger-of-reads so every retrieval is recorded on a tamper-evident substrate that the directory itself cannot rewrite (Azure Confidential Ledger [@ms-conf-ledger] is the closest shipping primitive on the Microsoft side). None of these three are wired into Windows LAPS in 2026. Each exists as an adjacent Microsoft product. The architectural integration -- a Windows LAPS that requires two `LAPS-DPAPI-Decryptors` members to co-sign a retrieval, attests the retrieving device's state at decryption time, and writes the retrieval event to an append-only ledger the directory cannot edit -- is engineering work that nobody has shipped.

Some of those structural bounds map onto open problems with no clean 2026 answer. We close on six of them.

10. Open Problems in 2026

Six open problems in local-admin password management for which no first-party Microsoft answer ships in 2026. Each is one paragraph, framed as "what is the question," "what has been tried," and "what is the current best partial result."

Open question	What has been tried	Current best partial result
Legacy SYSVOL `cpassword` cleanup at scale	MS14-025 (UI disable, no remediation); PingCastle scanning; community `Get-GPPDeployedPasswords`	Third-party scan-and-manual-delete; no first-party cmdlet ships in the OS
Cross-tenant / cross-directory LAPS coverage report	Microsoft Intune compliance reports; manual `Get-LapsADPassword` and `Get-LapsAADPassword` joins	DIY KQL across two directories; no unified portal report
Hybrid-joined `BackupDirectory` ambiguity	Microsoft Learn guidance ("AD for hybrid")	Most shops configure both and reconcile downstream
Win 11 25H2 Administrator Protection and LAPS interaction	Tech Community guidance; Microsoft Learn architectural notes	Operate them as orthogonal, with no architectural integration
LDAP channel binding / signing enforcement migration	Microsoft KB4520412 enforcement push 2020-2024; cross-platform tool updates	Some Linux pentest tooling still incomplete; `bloodyAD` / `lapsv2decrypt` lead the field [@kb4520412-canonical]
Retrieval-event audit gap (cross-directory)	Event 4662 SACL via `Set-LapsADAuditing`; Entra audit log; Defender for Identity hunting	DIY KQL unification across AD + Entra; no unified audit pane

1. Legacy SYSVOL cpassword cleanup at scale. MS14-025 disabled new authoring twelve years ago; it never deleted what it patched [@ms14-025-bulletin]. No first-party Find-GPPPassword or Remove-GPPPassword cmdlet ships in the OS in 2026. PingCastle's A-PwdGPO rule and Semperis Purple Knight's equivalent scanner fill the gap [@pingcastle-rules]. The 2026 answer is: scan with a third-party tool, rotate the discovered credentials in whatever account-management primitive owns them, then delete the XML. The open question is why Microsoft has not shipped this in the twelve years since the bulletin. The blast-radius argument from 2014 -- "we cannot risk auto-deleting policy XMLs from SYSVOL" -- is now strictly weaker than the cleanup-tail argument that the residual artefacts keep showing up on internal pentest reports a decade later.

2. Cross-tenant and cross-directory LAPS coverage view. No portal-level "every Entra-joined and every AD-joined device that does not have a current LAPS password" report exists. Microsoft Intune compliance reports help on the Intune-managed side; Get-LapsADPassword -Identity * covers the AD side; Get-LapsAADPassword covers the Entra side. There is no single pane that unifies them. The 2026 answer is custom KQL or PowerShell that joins the three result sets on a normalised device identifier. The bottleneck is identity: Intune device IDs, AD objectGuid values, and Entra deviceId values are three different surrogate keys, and a fleet's mapping table is its own engineering investment.

3. Hybrid-joined BackupDirectory ambiguity. Microsoft Learn's current guidance is that hybrid-joined devices should typically use BackupDirectory = 2 (AD) when on-premises AD is the canonical identity store, and may use BackupDirectory = 1 (Entra) when Intune is the primary policy-delivery mechanism [@ms-laps-entra-scenarios]. In practice, the documentation hedges, and many shops configure both directions (one via GPO, one via Intune CSP) and rely on the per-device evaluation order to pick one. The result is a coverage-verification problem: a device that is "configured for AD backup" by GPO and "configured for Entra backup" by CSP can end up with the password in either backend, and the source of truth depends on policy precedence rules most operators do not memorise.

4. Windows 11 25H2 Administrator Protection and LAPS interaction. Administrator Protection's per-elevation transient admin tokens and Windows LAPS's recoverable break-glass password are operationally adjacent but architecturally disjoint [@tc-admin-protection-win11]. The documentation covers each feature on its own; the interaction matrix -- "what does a LAPS-managed RID 500 look like under Administrator Protection on a Win 11 25H2 host" -- is not laid out in one place. Tier-0 architects who want both behaviours have to assemble the answer from two product pages.

5. LDAP channel binding and signing enforcement migration. Microsoft has been hardening LDAP channel binding through a multi-year 2020-2024 enforcement push tracked under KB4520412 [@kb4520412-canonical]. The original March 10, 2020 update introduced Channel Binding Token (CBT) signing events 3039, 3040, and 3041; the manual enablement step was removed on November 14, 2023 for Windows Server 2022 and on January 9, 2024 for Windows Server 2019, after which the hardening became the default posture; starting with Windows Server 2022 23H2, all new versions ship with the full set of changes in the KB applied [@kb4520412-canonical]. Tooling that does not speak LDAPS-with-channel-binding will break when enforcement reaches its terminal state. Modern attack-graph tooling -- bloodyAD [@bloodyad-repo] and the lapsv2decrypt reference implementation [@lapsv2decrypt-repo] -- has tracked the changes. Not every Linux pentest stack has. Practitioners building Linux-based LAPS retrieval pipelines should validate their stack against the channel-binding-required posture before the enforcement wave reaches them.

6. The retrieval-event audit gap (cross-directory). Active Directory does not natively log every read of msLAPS-EncryptedPassword; Set-LapsADAuditing installs a SACL that emits Directory Service event 4662 for configured attribute reads [@ms-laps-set-adauditing]. Microsoft Entra ID logs LAPS retrieval through its own audit log, surfaced via the Graph endpoint [@ms-graph-localcredinfo]. The two log streams have different schemas, different timestamp normalisations, and different principal identifiers. Cross-pane unification of "who read which LAPS password when" across both backends is a DIY engineering problem in 2026. Microsoft Defender for Identity surfaces some of the AD-side reads under the Compromised Credentials and Lateral Movement categories [@ms-defender-alerts] but does not name LAPS specifically in the public alert taxonomy.

The threshold-cryptography open problem (an $m$-of-$n$ Shamir scheme over the LAPS password protector, with $m \geq 2$ in tier-0 fleets) is theoretically closed by the 1979 Shamir secret-sharing construction. The deployment-side block is that no Microsoft-shipped primitive wires the construction to the LAPS rotation pipeline. Adjacent shipping primitives (Azure Managed HSM key-release [@ms-mhsm-policy-grammar], Azure Confidential Ledger [@ms-conf-ledger]) exist on the Azure side, but the integration with on-premises LAPS clients is not on any public roadmap. The companion posts on DPAPI internals (#20) and Defender for Identity (#87) cover adjacent territory but do not close this gap.

None of those six dissolves the architectural lesson the eleven-year arc taught: the right defaults take a decade to ship. Here is the practitioner field manual for the meantime.

11. Practitioner Field Manual and FAQ

What follows is a seven-step deployment list, three named sidebars that surface the most common misconceptions, and a seven-question FAQ. Lift the step list verbatim into your deployment runbook; the sidebars exist because the article would not be defensible without them.

The audit-and-migrate seven-step list

Audit SYSVOL for cpassword first. Run PingCastle's A-PwdGPO (MITRE T1552.006) [@pingcastle-rules; @mitre-t1552-006] before touching anything else. A Windows triage one-liner -- findstr /s /i cpassword \\domain\SYSVOL\*.xml -- will land on most environments in under a minute. Remediate the discovered XML files (rotate the underlying account passwords, then delete the XMLs) before deploying Windows LAPS so the attack surface and the defence are not co-evolving in the same window.
Extend the AD schema for Windows LAPS. Run Update-LapsADSchema once per forest from a Domain Admin context. The cmdlet is idempotent and coexists with the legacy ms-Mcs-AdmPwd attribute on the same Computer object [@ms-laps-mig-scenarios].
Delegate. Run Set-LapsADComputerSelfPermission on each target OU so that computer accounts can write their own msLAPS-* attributes. Audit existing "All Extended Rights" delegations with Find-LapsADExtendedRights and remove any that do not have an explicit operational justification [@ms-laps-ps-overview]. This is the legacy-LAPS lesson applied to the new attribute set.
Configure encryption-at-rest. Verify that the forest's Domain Functional Level is Windows Server 2016 or higher. Configure ADPasswordEncryptionEnabled = 1 explicitly even though the default is True -- the explicit configuration makes the choice visible in policy audits and forces the operator to verify the DFL prerequisite [@ms-laps-policy-settings]. Assign ADPasswordEncryptionPrincipal to a dedicated LAPS-DPAPI-Decryptors group, not Domain Admins [@ms-laps-concepts-overview].
Deploy policy. GPO for AD-joined, Intune CSP for Entra-joined and hybrid-joined [@ms-laps-csp]. Settings as per section 7's baseline table. Validate via Get-LapsADPassword -Identity <computer> against a representative sample of hosts after the first one-hour rotation timer has fired [@ms-laps-get-adpassword].
Migrate from legacy LAPS. Use the documented coexistence pattern: the legacy MSI's CSE keeps running against the built-in RID 500, the new in-box LAPS takes over against a named secondary local-admin account, then retire the legacy ms-Mcs-AdmPwd schema readers and uninstall the MSI once Windows LAPS coverage is verified [@ms-laps-mig-scenarios]. The legacy MSI's installation is blocked on Windows 11 23H2 and later [@ms-laps-msi-download].
Continuous audit. PingCastle for coverage rules (A-LAPS-Not-Installed, A-LAPS-Joined-Computers, and the GPP A-PwdGPO) [@pingcastle-rules]; BloodHound for the ReadLAPSPassword edge across the graph [@bloodhound-edge-readlaps]; Defender for Identity for downstream behaviour under Compromised Credentials and Lateral Movement [@ms-defender-alerts]; and a custom KQL on the Entra audit log for LapsPasswordRetrieved events. None of these is optional in a deployment that intends to detect compromise.

Sidebar A: MS16-072 is NOT the LAPS attribute-readability bulletin

A recurring misattribution credits MS16-072 / KB3163622 / CVE-2016-3223 (June 14, 2016) [@ms16-072-bulletin; @ms16-072-kb; @cve-2016-3223] with closing the legacy LAPS attribute-readability issue. It does not. MS16-072 is a Group Policy retrieval-context fix: it moved user-side GPO fetch into the computer's security context to defeat a man-in-the-middle class on policy traffic. The actual LAPS attribute-readability issue -- "All Extended Rights" delegations silently including CONTROL_ACCESS on the CONFIDENTIAL ms-Mcs-AdmPwd attribute -- has no Microsoft-assigned CVE or bulletin. The canonical write-up is Sean Metcalf's August 2016 ADSecurity piece [@adsec-laps-2016], and the operational primitive is SpecterOps's ReadLAPSPassword BloodHound edge [@bloodhound-edge-readlaps].

Sidebar B: "Hybrid joined" is not "Hybrid Worker"

Microsoft Entra hybrid joined devices are workstations joined to both an on-premises AD domain and Microsoft Entra ID. The LAPS conversation about hybrid joined is a BackupDirectory choice. Microsoft Entra hybrid runbook workers, on the other hand, are an Azure Automation primitive -- worker processes that execute Automation runbooks against on-premises resources. They share a word and nothing else. A LAPS policy targeted at "hybrid devices" means hybrid joined; it has nothing to do with hybrid runbook workers. The article's section 8 includes the same disambiguation because operators conflate them with surprising frequency.

Sidebar C: How GPP cpassword still gets found in 2026

MS14-025 disabled new authoring but did not delete the artefacts [@ms14-025-bulletin]. The artefacts persist because SYSVOL replication is conservative -- nothing in the forest's design deletes anything from SYSVOL just because the editor UI was hot-patched on the administrative workstation. A fresh PingCastle scan against a long-lived forest will routinely surface 2010-era Groups.xml files [@pingcastle-rules], and the third-party scanner cohort is the only practical defence. The one-shot remediation pattern is: find with A-PwdGPO, rotate the underlying password via the replacement tool (Windows LAPS for built-in local admin; a PAM vault for service accounts that were stored in GPP), then delete the Groups.xml and let SYSVOL replication propagate the deletion.

No. Administrator Protection addresses in-session UAC-class elevation by brokering each elevation through a per-elevation transient shadow-admin identity [@tc-admin-protection-win11]; it does not provide a recoverable break-glass password for an off-network or non-bootable endpoint. The two systems are orthogonal and Microsoft recommends running them together on Windows 11 25H2 fleets. Replacing LAPS with Administrator Protection produces designs that lose the recovery primitive for laptops that have wandered off the corporate network for a year. Defence in depth, plus a coverage-leak primitive. An LDAP reader who is not in `ADPasswordEncryptionPrincipal` gets only an opaque ciphertext blob [@ms-laps-concepts-overview] -- but the same reader can still enumerate which computer objects have a current `msLAPS-EncryptedPassword`, which gives them target-selection telemetry on managed-versus-unmanaged hosts. The canonical write-up of this class is Sean Metcalf's August 2016 ADSecurity piece on the legacy `ms-Mcs-AdmPwdExpirationTime` attribute [@adsec-laps-2016], and the architectural lesson carries forward to Windows LAPS unchanged. Yes, in seconds. The 32-byte AES-256-CBC key is published verbatim in `[MS-GPPREF]` section 2.2.1.1.4 of Microsoft's Open Specifications corpus [@ms-gppref-aes-key] and that publication is permanent under the Open Specifications Promise. Any residual `Groups.xml` (or five sibling carriers including the asymmetric `Printers.xml` [@rewtdance-gpp-2012]) in SYSVOL that contains a `cpassword` attribute is operationally plaintext. The 2026 answer is to find them with PingCastle's `A-PwdGPO` rule [@pingcastle-rules] and remediate -- not to expect the artefacts to expire on their own. No. The rotation cycle is the `PasswordAgeDays` interval (default 30 days, minimum 1 on AD backup, minimum 7 on Entra backup) [@ms-laps-policy-settings]. After authentication, `PostAuthenticationActions` (default `3` = reset + sign out) fires once the `PostAuthenticationResetDelay` window (default 24 hours) has elapsed. Value `11` (Windows 11 24H2 / Server 2025+) adds termination of remaining processes; it is *not* a forced shutdown without warning -- the standard two-minute warning still applies and SMB sessions are deleted. Yes. LAPS rotates the password on a disabled account; the account simply cannot be used to log on until it is enabled. The break-glass runbook is: enable the account, retrieve the LAPS password, perform the recovery, rotate immediately, re-disable. On Windows 11 24H2 and Windows Server 2025 and later, Microsoft's recommendation is to enable Automatic Account Management with a randomised name and `AutomaticAccountManagementEnableAccount = 0` so the managed account ships disabled-by-default with a non-predictable name [@ms-laps-account-modes]. The pattern defeats predictable-RID-500 enumeration entirely. Microsoft Entra ID. With `BackupDirectory = 1` [@ms-laps-policy-settings], the local LAPS component posts the rotated password to the `deviceLocalCredentials` resource on the Entra device object via Microsoft Graph [@ms-graph-localcredinfo]. Retrieval is via `Get-LapsAADPassword` (a wrapper around the Graph endpoint), the Microsoft Entra portal Devices blade, or a direct `GET /directory/deviceLocalCredentials/{deviceId}` call [@ms-laps-entra-scenarios]. Read permission requires the Cloud Device Administrator or Intune Service Administrator Entra role. No. `CanReadGMSAPassword` is the edge for **Group Managed Service Accounts** -- a different Active Directory feature with a different ACL on a different attribute (`msDS-GroupMSAMembership`). The correct LAPS edge is **`ReadLAPSPassword`**, introduced in BloodHound 2.0 on August 7, 2018 [@specterops-bh2], and the current edge documentation covers both the legacy `ms-Mcs-AdmPwd` and the modern `msLAPS-*` attribute paths [@bloodhound-edge-readlaps].

The companion posts in this series cover Pass-the-Hash itself (#76), DPAPI internals (#20), Microsoft Entra Privileged Identity Management (#90), Active Directory tiering (#72), Microsoft Defender for Identity (#87), and BloodHound (#77). Each of those is referenced in this article at the point where the topic would otherwise demand a digression; each has its own deep treatment elsewhere.

Twenty years. Eleven years of which separated Microsoft's December 2012 articulation of the architecture from the April 11, 2023 in-box default [@ms-pth-whitepaper; @tc-windows-laps-ga-2023]. Four residual attack surfaces -- delegated-decryptor compromise, the pre-rotation OPSEC tail, BYOD endpoints, and the multi-decade MS14-025 cleanup tail [@ms14-025-bulletin] -- still resist the architecture rather than fall to it. One through-line: this is what shipping the right default a decade late looks like. The right defaults are now in the box. The directory is still tier 0. Somebody still has to break the glass. The architectural game from here is not to invent a new generation; it is to make sure the one we finally have is actually deployed, audited, and clean.

Pass-the-Hash to Pass-the-PRT: Twenty-Nine Years of Windows Credential Replay in One Family Tree

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

Twenty-nine years of Windows credential-replay attacks -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Pass-the-Certificate, Pass-the-PRT -- are a single lineage, not five techniques. Each generation finds the next long-term authentication artefact that lives outside the latest Microsoft isolation boundary, then commoditises extraction in tooling that runs anywhere with local administrator. Credential Guard (2015) and KB5014754 (2022) bought years but not closure; Pass-the-PRT (Mollema + Delpy, 2020) already defeats both because the Primary Refresh Token lives in the CloudAP plug-in, which is not inside any current isolation scope. The next decade of Windows credential theft turns on whether Microsoft extends hypervisor-based isolation to CloudAP before commodity offensive tooling makes the attack universal.

1. Two Afternoons, Twenty-Nine Years Apart

On the afternoon of Tuesday, April 8, 1997, between 5:27 p.m. and 8:57 p.m. -- a window we can narrow to about three and a half hours from the file timestamps preserved in the patch he posted -- a researcher named Paul Ashton sat down with the Samba source tree and made the smallest possible change to smbclient.The bracketing mtimes Tue Apr 8 17:27:29 1997 and Tue Apr 8 20:57:43 1997 are preserved verbatim in the unified diff's *** and --- header lines on Exploit-DB advisory 19197 [@ashton-exploitdb-19197]. You can still download the diff today and confirm the timestamps yourself. Where the unpatched client computed a network response from a typed-in password, his version read the password's LM hash from smbpasswd on disk and fed it straight to the same encryption primitive, skipping the password entirely.

He posted the diff to NTBugtraq the same evening with a five-line advisory: "A modified SMB client can mount shares on an SMB host by passing the username and corresponding LanMan hash of an account that is authorized to access the host and share. The modified SMB client removes the need for the user to 'decrypt' the password hash into its clear-text equivalent." [@ashton-exploitdb-19197]

Twenty-nine years later, every Windows credential-replay attack in commodity offensive tooling is a direct descendant of that afternoon.

Fast-forward to 2026. A Windows 11 23H2 laptop, hardened to Microsoft's published baseline. Credential Guard on. KB5014754 strong certificate mapping in full enforcement. Conditional Access enabled, with Token Protection where supported. An attacker has local admin -- the same starting position the 1997 attack assumed.

Two commands run on that machine, in the same paragraph. Mimikatz sekurlsa::logonpasswords returns empty NT hash and TGT buffers; Credential Guard has done its job. Then Mimikatz dpapi::cloudapkd /unprotect returns a valid Primary Refresh Token session key and proof-of-possession material [@mollema-prt-digging]. On a different machine across the internet, the attacker pastes that material into Dirk-jan Mollema's roadtx prt, mints an x-ms-RefreshTokenCredential cookie, and authenticates to Entra ID as the laptop's user [@mollema-prt-abusing] [@roadtools-github]. Every Microsoft defense shipped in 2015, 2022, and 2024 is running. The attack still wins.

Note: The empty buffer from sekurlsa::logonpasswords is the artefact of twenty-nine years of architectural lessons. The PRT extraction from dpapi::cloudapkd is the architecture of the next five-to-ten years. Both scenes are the same attack class. The credential changed; the protocol that consumes it changed; the long-term storage location changed; the lineage did not.

You will meet seven people in this article. Paul Ashton (1997, the patch). Hernan Ochoa (2008, the toolkit that put the technique inside Windows itself). Benjamin Delpy (2011, Mimikatz; and the Kerberos generations that followed). Sean Metcalf (2014, who named Overpass-the-Hash and wrote the practitioner reference that taught a generation of red and blue teams).

Will Schroeder and Lee Christensen (2021, "Certified Pre-Owned," the AD CS catalog that became Pass-the-Certificate). Oliver Lyak (2022, Certifried, the CVE that forced Microsoft to ship KB5014754). And Dirk-jan Mollema (2020, the Primary Refresh Token research this article argues is the most consequential credential-theft work since 2008). The cast is small. The lineage they built is the load-bearing structure of every Windows penetration test in 2026.

How is it possible that the same attack works in 1997 and 2026? The answer is structural, not coincidental -- and once you see it, you cannot unsee it.

2. The Architectural Property the Family Shares

NTLM authentication never asks for the password as a string. It asks for a function of the hash. The hash is the password.

That sentence is the article's load-bearing claim, and the rest of this section is its proof.

The Microsoft specification for the NTLM protocol -- [MS-NLMP], sections 3.3.1 and 3.3.2 -- writes the response computation in pseudocode. For NTLMv1, the server sends an 8-byte challenge; the client computes NtChallengeResponse = DESL(ResponseKeyNT, challenge), where ResponseKeyNT = NTOWFv1(password) = MD4(UNICODE(password)) [@ms-nlmp-3-3-1]. DESL is a variant of DES that pads the 16-byte NT hash to 21 bytes with five zero bytes, splits the result into three 7-byte sub-keys, runs DES on the 8-byte challenge under each sub-key, and concatenates the three 8-byte ciphertexts to form a 24-byte response.

NTLMv2 is more elaborate -- the response key is NTOWFv2 = HMAC_MD5(MD4(UNICODE(password)), UNICODE(Uppercase(User) + UserDom)), and the proof string is HMAC_MD5 of the challenge concatenated with a target-info structure -- but the structural property is identical: the cleartext password appears in exactly one place in the entire protocol, the input to the hash function on the client. The verifier performs the same computation against the stored NT hash from the SAM or NTDS.dit, and compares. Neither side ever transmits the password [@ms-nlmp-3-3-2].

This is what Microsoft means when its institutional documentation says Pass-the-Hash "cannot be patched at the protocol level." There is nothing to patch.The same property holds for any challenge-response protocol whose verifier stores a determinable function of the password rather than the password itself: Kerberos with stored long-term keys, CHAP with shared secrets, OAuth client_credentials with shared secrets, every HMAC-based proof-of-possession scheme.

The protocol takes a stored hash and produces a response. Swap the user's hash for the attacker's hash, and the protocol still produces a valid response, signed by the substituted key. The bug is not a bug; it is a documented property.

A family of Windows authentication protocols (NTLMv1 and NTLMv2) in which a server sends a random challenge and the client returns a response computed by applying a keyed cryptographic primitive (DES or HMAC-MD5) to that challenge under a key derived from the user's password. The verifier holds the same key and recomputes the response to confirm. The cleartext password is never transmitted [@ms-nlmp-3-3-1] [@ms-nlmp-3-3-2]. The 16-byte MD4 of the user's password as UTF-16 little-endian (`MD4(UNICODE(Passwd))` in the NLMP pseudocode). Unsalted by design, because NT was originally specified for an offline domain controller that has to verify against a fixed reference value. The NT hash is the long-term symmetric Windows authentication secret for every account, stored locally in the SAM and centrally in the NTDS.dit Active Directory database [@ms-nlmp-3-3-1]. The technique of authenticating to a service that uses NTLM (or any protocol descended from the same family) by feeding a stolen NT hash directly to the response-construction function, instead of typing a password the function would then hash. The terminology and the first working demonstration are due to Paul Ashton, NTBugtraq, April 1997 [@ashton-exploitdb-19197]. sequenceDiagram participant Client participant Server participant Verifier as SAM or NTDS.dit Client->>Server: NTLM_NEGOTIATE Server->>Client: NTLM_CHALLENGE with 8-byte nonce Note over Client: ResponseKeyNT equals NTOWFv1 of stored NT hash Note over Client: NtChallengeResponse equals DESL of ResponseKeyNT and nonce Client->>Server: NTLM_AUTHENTICATE with response Server->>Verifier: Look up stored NT hash for user Verifier-->>Server: Stored NT hash Note over Server: Recompute DESL of stored hash and nonce Server->>Client: Authentication succeeds if responses match

Key idea: The hash is the password. Any long-term authentication artefact reachable by the process that uses it is replayable -- and every credential type the rest of this article discusses (Kerberos TGT, certificate private key, Primary Refresh Token session key) is a different instance of this same property. Defenses can isolate one artefact at a time; the property is intrinsic to the architecture.

Ashton's 1997 patch was the protocol-disclosure proof. He swapped a single function call -- SMBencrypt(pass, cryptkey, pword) became E_P24(p21, cryptkey, pword), where p21 is the user's LM hash read directly from smbpasswd -- and Samba's smbclient authenticated to NT 3.51 and NT 4.0 file servers without ever knowing the user's password [@ashton-exploitdb-19197]. You can read the patch in five minutes. It is also, in a precise sense, the first proof that NTLM's response computation is hash-equivalent: if substituting the hash works, then mathematically the hash is what the protocol wanted all along.

And then nothing happened for eleven years.

That gap deserves its own explanation, because the eleven-year interregnum is the cleanest failure mode in the lineage.

Wikipedia's modern summary of the pre-2008 limitation reads: "even after performing NTLM authentication successfully using the pass the hash technique, tools like Samba's SMB client might not have implemented the functionality the attacker might want to use. This meant that it was difficult to attack Windows programs that use DCOM or RPC. Also, because attackers were restricted to using third-party clients when carrying out attacks, it was not possible to use built-in Windows applications, like Net.exe or the Active Directory Users and Computers tool amongst others, because they asked the attacker or user to enter the cleartext password to authenticate, and not the corresponding password hash value." [@wikipedia-pass-the-hash]

Inside Microsoft the 1997 patch was treated as confirming a known property of LSASS-resident credentials, not as a new attack class. The institutional position was that any compromise yielding the hash already implied SYSTEM-equivalent access, and that the realistic chain was "exfiltrate the hash and crack it offline," not "replay the hash." The architectural counter-claim -- that *replaying* the hash from inside a Windows process bypasses every native-tool obstacle -- took a decade to land in the practitioner literature. The 2012 Duckwall + Campbell Black Hat USA paper named the lag in its title: "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012]

If the obstacle is "built-in Windows tools ask for cleartext," the architectural answer is to put the substituted hash inside the Windows process that those tools rely on. That insight took eleven years to operationalise. The person who operationalised it was Hernan Ochoa, in 2008.

3. From Patch to Toolkit: The Windows-Native Pivot

By 2008, Ashton's 1997 patch had been sitting on NTBugtraq for eleven years. Hernan Ochoa had a different idea: instead of patching the client, patch the credential cache.

The artefact Ochoa shipped at CanSecWest 2008 and Black Hat USA 2008 was called the Pass-the-Hash Toolkit, distributed through Core Security Technologies' open-source projects page [@corelabs-pshtoolkit-wayback]. It contained two executables. IAM.EXE opened the LSASS process with PROCESS_VM_WRITE, located the cached credential block for the current interactive logon session, and overwrote the NT hash and username fields with attacker-supplied values. PTH.EXE spawned a target process under a substituted hash.

Once the substitution was in place, every native Windows SSO consumer -- net.exe, wmic, mstsc once Restricted Admin RDP shipped years later, SMB, RPC, DCOM -- transparently picked up the attacker-supplied hash, because the OS handed them what it believed were the legitimate user's credentials.

Wikipedia summarises the architectural pivot in one paragraph: "It allowed the user name, domain name, and password hashes cached in memory by the Local Security Authority to be changed at runtime after a user was authenticated -- this made it possible to 'pass the hash' using standard Windows applications, and thereby to undermine fundamental authentication mechanisms built into the operating system." [@wikipedia-pass-the-hash] The eleven-year limitation was gone. Pass-the-Hash was now a Windows-native attack that worked against any tool that read its credentials from LSASS -- which in practice meant every Windows tool.

The user-mode Windows process (`lsass.exe`) that handles interactive logon, owns the Security Reference Monitor's policy decisions, and -- relevant to this article -- caches the in-memory credential material that supports Single Sign-On for the duration of each logon session: NT hashes for NTLM, Kerberos TGTs and session keys, certificate handles, and (since Azure AD / Entra ID device join) Primary Refresh Token material in the CloudAP plug-in. Every credential-replay technique in this article reaches its target by reading LSASS in some form.

The 2012 retrospective is where the security industry stopped pretending Pass-the-Hash was solved. Alva Duckwall and Christopher Campbell shipped a Black Hat USA 2012 paper titled, unambiguously, "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012] The title is the load-bearing pull-quote: it named Ashton 1997 as the origin, Ochoa 2008 as the Windows-native pivot, and the industry's continued failure to ship a structural fix as the central fact. From this point onwards Microsoft itself acknowledged Pass-the-Hash as a structural property of NTLM rather than a fixable bug.

Hernan Ochoa's Windows Credentials Editor (WCE), released a year after the Pass-the-Hash Toolkit, developed the same LSASS-injection primitive on a separate code base. Two independent implementations converging on the same memory-access pattern in the same window is the clearest indication that the architectural insight -- "the credential is sitting in a process you can write to" -- was overdetermined once anyone went looking for it.

What did Ashton's 1997 patch leave on the table? The other long-term credentials that LSASS held. The NT hash was the first. There would be more.

If you can read the NT hash from LSASS, you can read the Kerberos TGT from LSASS. The same memory-access primitive that animates IAM.EXE is one commit away from animating sekurlsa::tickets. That commit shipped in May 2011. Its author was a twenty-five-year-old French programmer named Benjamin Delpy.

4. Mimikatz and the Kerberos Turn

In May 2011, Benjamin Delpy posted his first public release of a program he had been writing as a side project to learn C. He was twenty-five, working as an IT manager at an institution he has never publicly named. Andy Greenberg's Wired profile records the date: "He released it publicly in May 2011, but as a closed source program." [@wired-greenberg-mimikatz] Wikipedia corroborates: "He released the first version of the software in May 2011 as closed source software." [@wikipedia-mimikatz] The program was called Mimikatz.

What made Mimikatz architecturally different from Ochoa's toolkit was that it was modular. The credential-extraction primitives lived in named command groups: sekurlsa::logonpasswords dumped NT hashes from LSASS; sekurlsa::tickets dumped Kerberos tickets from LSASS; kerberos::ptt injected a stolen ticket into the current Kerberos cache via the documented LsaCallAuthenticationPackage API with the KerbSubmitTicketMessage message [@ms-lsa-call-auth-package]; lsadump::dcsync (added August 2015, in collaboration with Vincent Le Toux) impersonated a domain controller and asked another DC for the krbtgt hash via the IDL_DRSGetNCChanges replication RPC [@adsec-dcsync-p1729].

Same LSASS, different artefact, different protocol surface. The architectural property section 2 named had two artefacts to work with on Windows: the NT hash, and the Kerberos TGT.

This is Pass-the-Ticket (Generation 2). The stolen TGT plus its session key authenticates the holder as the original principal for the ticket's lifetime, which on a default AD deployment is ten hours, renewable for seven days. Time complexity per replay: O(1). The TGT session key is the load-bearing piece -- without it, the ticket is opaque encrypted bytes that the holder cannot decrypt, sign, or present back to the KDC. Mimikatz's sekurlsa::tickets /export writes the ticket as a .kirbi file on disk; kerberos::ptt <file> re-injects on any machine where the user has a Kerberos credentials cache.

The long-lived Kerberos credential issued by the KDC's Authentication Service (AS-REP) in response to a successful AS-REQ. The TGT is encrypted under the KDC's own krbtgt-account long-term key and contains a session key that the client uses to subsequently request service tickets from the Ticket Granting Service (TGS). Specification: RFC 4120, section 3 [@rfc-4120]. On a Windows Active Directory deployment the default TGT lifetime is 10 hours with renewal up to 7 days. The technique of extracting a Kerberos TGT (and its session key) from one machine's LSASS-resident Kerberos cache and injecting it into another machine's cache, so that subsequent service-ticket requests authenticate as the ticket's original principal. Tool of record: Mimikatz `sekurlsa::tickets` + `kerberos::ptt`; equivalent functionality in Rubeus and Impacket. sequenceDiagram participant Victim as Victim host participant Attacker as Attacker host participant KDC Note over Victim: User logged in, TGT cached in LSASS Kerberos package Attacker->>Victim: mimikatz sekurlsa::tickets export Victim-->>Attacker: TGT.kirbi (ticket plus session key) Note over Attacker: mimikatz kerberos::ptt TGT.kirbi Attacker->>KDC: TGS-REQ presenting injected TGT KDC-->>Attacker: TGS-REP service ticket Attacker->>Attacker: Authenticate to any Kerberos service as the victim

Note: A common shorthand says that Microsoft's Credential Guard isolated NT hashes, so attackers shifted to TGTs. That arrow runs backwards in time. Pass-the-Ticket predates Credential Guard by years -- the Mimikatz Kerberos primitives developed between the May 2011 closed-source release and the April 6, 2014 open-source commit (the earliest verifiable source-level evidence for sekurlsa::tickets and kerberos::ptt), and were presented in detail at Black Hat USA 2014 by Duckwall and Delpy [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. Pass-the-Ticket exists because TGTs are also in LSASS, not as a defensive response. The shift to a new artefact happened because the architectural property of credential extraction generalised, not because Credential Guard pushed attackers there.

The third generation followed shortly. Overpass-the-Hash observes that for the RC4-HMAC Kerberos encryption type -- the Windows default from Windows 2000 through November 2022 -- the user's long-term Kerberos key is the unchanged NT hash.

RFC 4757, authored by K. Jaganathan, L. Zhu, and J. Brezak of Microsoft and published as informational in December 2006, specifies the RC4-HMAC enctype's long-term key as the existing NT hash without modification [@rfc-4757]. An attacker who holds the NT hash can drive a legitimate Kerberos AS-REQ to the KDC, encrypt the timestamp pre-auth blob with the NT hash as the RC4-HMAC key, and receive a real TGT signed by the real krbtgt.

The economic effect is large. Pass-the-Hash gets you NTLM-based services -- SMB, RPC, and any protocol over them. Overpass-the-Hash gets you the entire Kerberos surface: Kerberos-only services, services that require Kerberos for delegation, services with NTLM disabled at the GPO level. Same NT hash. Different downstream protocol. Strictly larger attack surface.

The technique of presenting a stolen NT hash to the KDC as the user's long-term RC4-HMAC Kerberos key (per RFC 4757 [@rfc-4757]), obtaining a real TGT signed by the real krbtgt, and operating as a real Kerberos client for the ticket's lifetime. Tool of record: Mimikatz `sekurlsa::pth /user: /domain: /ntlm: /run:` and Rubeus `asktgt /user: /rc4:`. Per Sean Metcalf's adsecurity.org reference, the technique is named "over" because the hash is promoted one notch up the protocol stack from NTLM into Kerberos [@adsec-mimikatz-p556] [@adsec-kerberos-p2293]. sequenceDiagram participant Attacker participant KDC participant Service as Kerberos service Note over Attacker: Holds NT hash for user (e.g. from sekurlsa::logonpasswords) Attacker->>KDC: AS-REQ with PA-ENC-TIMESTAMP encrypted under RC4-HMAC(NT hash) KDC->>KDC: Verify PA-ENC-TIMESTAMP decrypts cleanly KDC-->>Attacker: AS-REP with real TGT signed by krbtgt Attacker->>KDC: TGS-REQ for Service KDC-->>Attacker: TGS-REP service ticket Attacker->>Service: AP-REQ authenticate as user Service-->>Attacker: Access granted

The naming has its own story. The Mimikatz capability is Delpy's; the term "Overpass-the-Hash" and the taxonomic framing that distinguishes it from straight Pass-the-Hash spread through the practitioner community via Sean Metcalf's adsecurity.org reference [@adsec-mimikatz-p556] and the Duckwall + Delpy Black Hat USA 2014 talk and whitepaper [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. The earliest archived snapshot of the adsecurity.org reference is October 1, 2014; the talk timestamp is August 7, 2014. The two sources are essentially contemporaneous, and Metcalf's later "Red vs. Blue" Black Hat USA 2015 whitepaper consolidates the practitioner taxonomy [@metcalf-bh2015-red-vs-blue].

The "Overpass" coinage is a deliberate semantic argument that the technique is one notch above Pass-the-Hash on the protocol stack: the NT hash, which began life as an NTLM response key, is being promoted into Kerberos as a long-term encryption key. The naming credit is socially distributed -- Metcalf, Delpy, Duckwall, and Mimikatz's own command group all carry traces of it -- so this article uses Metcalf's reference as the canonical practitioner explainer rather than as a single inventor citation.

The DigiNotar incident in September 2011 is the first publicly attributed criminal use of Mimikatz, four months after Delpy's first public release. The Dutch certificate authority DigiNotar -- founded 1998, acquired by VASCO in January 2011, hacked in June 2011, declared bankrupt in September 2011 [@wikipedia-diginotar] -- was used to issue hundreds of fraudulent certificates that were then used in man-in-the-middle attacks on Iranian Gmail users [@wikipedia-diginotar] [@fox-it-operation-black-tulip].

Greenberg's Wired profile records that Delpy was told by the breach investigators that Mimikatz had been used during the intrusion [@wired-greenberg-mimikatz]. The single-source attribution warrants a hedge -- Greenberg's source is Delpy himself, quoting investigators -- but the underlying breach timeline is solid.

The decision to open-source Mimikatz on April 6, 2014 is dated by the GitHub repository banner: `mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03)` [@mimikatz-github]. The precipitating event, as Delpy told Wired, was a trip to Moscow: he returned to his hotel room to find a stranger at his laptop; a second man approached him in the lobby that evening and demanded source code on a USB stick. He decided defenders needed the source as much as the attackers already did, and pushed it to GitHub when he got home [@wired-greenberg-mimikatz].

By 2014, the credential-replay family had three generations -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash -- and Microsoft's only documented response was a forty-page PDF. The next section is what that PDF said, and why documentation alone cannot end an attack class.

5. Documentation Is Not Defense

By December 2012, Microsoft had a problem. Duckwall and Campbell had just shipped a Black Hat USA paper titled "Still Passing the Hash 15 Years Later" [@duckwall-campbell-bh2012]. Mimikatz was eighteen months old. The institutional position that Pass-the-Hash was a "post-compromise issue" -- the line Microsoft had held since 1997 -- was no longer survivable in public.

The institutional response came in two waves. Mitigating Pass-the-Hash Attacks and Other Credential Theft, version 1, shipped in late 2012 (most practitioner secondaries place it in December 2012; no primary Microsoft URL with a verifiable v1 timestamp survives today).

Version 2 followed in July 2014, extending the v1 playbook with the new defensive surfaces that shipped in Windows 8.1 and Windows Server 2012 R2: Protected Users as a deployable security group, Restricted Admin RDP as a default-available feature, LSA Protection (RunAsPPL) as a registry-toggleable defense, and Authentication Policies and Silos as KDC-side restrictions [@ms-download-mitigating-pth-v2]. The two whitepapers are the closest thing the industry got to an institutional Microsoft acknowledgment that Pass-the-Hash was a load-bearing operational problem requiring a defensive playbook rather than a patch.

What did the playbook recommend? Three orthogonal stopgaps, each with a published bypass.

Protected Users (Windows Server 2012 R2). A security group whose membership bans, on the DC side, NTLM authentication, DES and RC4 Kerberos pre-authentication, and Kerberos unconstrained delegation; and, on the device side, NTLM caching of the user's plaintext credentials or NTOWF and Kerberos DES/RC4 long-term keys. Member TGTs are capped at 240 minutes (four hours) with no renewal [@ms-protected-users]. Documented bypasses: requires explicit opt-in per account, breaks any service that depended on unconstrained delegation, does not apply to computer accounts or service accounts by default, and has no effect on Kerberos AES-key extraction from LSASS (since AES keys are not banned; only RC4 is).

Restricted Admin RDP (introduced in Windows 8.1 / Server 2012 R2 RTM, October 2013; backported to Windows 7 / Server 2008 R2 / Windows 8 / Server 2012 by KB2871997 on May 13, 2014 [@ms-kb2871997-may2014]). An opt-in RDP mode that authenticates to the target without sending credentials, so a compromised target cannot harvest the RDP user's hash from its own LSASS. Documented bypass: opt-in per session, applies only to RDP, leaves SMB, WMI, and RPC unprotected. And it enables Pass-the-Hash for RDP -- the BloodHound CanRDP edge documents the abuse path with the exact Mimikatz command for injecting a stolen NT hash into mstsc.exe /restrictedadmin [@bloodhound-canrdp].

LSA Protection / RunAsPPL (Windows 8.1). A registry toggle that marks LSASS as a Protected Process Light, so non-PPL processes (including unsigned admin tools) cannot open it with PROCESS_VM_READ. Documented bypass: any signed kernel driver -- including loadable third-party drivers -- can still read PPL memory, and an attacker with local admin can load such a driver. The itm4n analysis includes the verbatim Mimikatz output where sekurlsa::logonpasswords returns access-denied against a PPL-marked LSASS, and shows that an attacker who loads a signed driver via the BYOVD pattern ("bring your own vulnerable driver") or escalates to kernel mode bypasses the marking. itm4n's framing -- "Credential Guard and LSA Protection are actually complementary" [@itm4n-lsass-runasppl] -- is also the prediction: PPL is part of the answer, but only when paired with the architectural pivot still to come.

A Windows Server 2012 R2 security group whose membership applies a set of restrictions, enforced jointly by the device and the domain controller, that block the most commonly extracted long-term credential material: no NTLM, no Kerberos RC4 or DES pre-auth, no unconstrained delegation, no NT-hash caching, and a 240-minute TGT lifetime with no renewal [@ms-protected-users].

The structural point is this. Documentation tells administrators what to do. It does not prevent the underlying LSASS-resident credential extraction. Every defense documented in v1 and v2 of the Mitigating-PtH whitepapers is bypassable, with a known and published technique, on any system where the attacker already has local administrator -- and local administrator is exactly what Pass-the-Hash exploitation already implies. The defender's win condition is to keep the attacker from ever getting to local admin in the first place; once they have it, every documented mitigation is a speed bump rather than a wall.

Note: The 2012-2014 era's load-bearing failure mode was assuming that telling administrators where credentials should live would prevent extraction from where they do live. Protected Users, Restricted Admin RDP, RunAsPPL, and Authentication Silos are all useful, and stacked together they raise the cost of post-admin exploitation. None of them moves the credential out of the address space the attacker can read.

A common secondary characterisation cites a "v3 2017" of the whitepaper alongside v1 and v2. That document does not exist in Microsoft Download Center ID 36036; the page lists Version 2.0; the 2023 Wayback snapshot of the same Download Center page records Date Published 7/7/2014, while the live page now shows a 2024 republication date for the same Version 2.0 PDF without a version bump [@ms-download-mitigating-pth-v2]. The Download Center page carries v2 metadata only -- v1's late-2012 date is sourced through contemporary practitioner literature rather than a primary Microsoft timestamp. After 2014 the post-v2 institutional documentation moves to the Microsoft Learn Credential Guard page rather than to a third whitepaper revision -- a structural choice, because by 2015 the architectural answer has shifted from prose to code.

By mid-2014 Microsoft's institutional position was that the protocol-level fix was unavailable and the architectural answer would need to relocate the credentials. If credentials cannot stay in LSASS where every admin process can read them, the credentials have to be moved to a place admin processes cannot read. That insight produces Credential Guard.

6. Credential Guard and the Architectural Pivot

On July 29, 2015, Microsoft shipped Windows 10 Enterprise [@ms-lifecycle-w10-enterprise]. Hidden in the RTM build was the first defense in the credential-replay lineage that wasn't documentation: hardware-rooted isolation. They called it Credential Guard.

The architecture is worth unpacking carefully, because every later generation of the family is best read as "what does this attack do to the assumptions Credential Guard makes?"

Credential Guard runs on top of Virtualization-Based Security. The Windows hypervisor partitions user mode into two virtual trust levels. VTL0 is the normal user partition: normal user-mode processes, including the normal LSASS, and the normal kernel. VTL1 is the isolated user partition: a small set of trustlets, signed user-mode processes the hypervisor protects from VTL0 inspection. Credential Guard's trustlet is LSAISO ("LSA Isolated"), a stripped-down clone of the LSA credential cache holding the material Microsoft wants out of VTL0. Hypervisor-enforced Code Integrity (HVCI) below enforces W^X on the VTL0 kernel, blocking kernel-mode bypasses that would otherwise read VTL1 memory directly.

The Windows architecture that runs a Type-1 hypervisor below the normal Windows kernel and partitions user mode into VTL0 (the normal partition) and VTL1 (the isolated partition). VTL1 hosts trustlets that the hypervisor protects from VTL0 inspection, even from kernel-mode VTL0 code. VBS is the substrate for Credential Guard, HVCI, the System Guard secure-launch chain, and the secure kernel. The Windows feature that relocates NT hashes, Kerberos TGT session keys, and "credentials stored by applications as domain credentials" from the in-VTL0 LSASS to the in-VTL1 LSAISO trustlet, so that the credential cache is unreadable from any VTL0 process or driver. Shipped in Windows 10 RTM (July 2015); default-enabled on hardware-eligible domain-joined non-DC systems in Windows 11 22H2 (September 2022) [@ms-learn-credential-guard]. The isolated-user-mode LSA process (`lsaiso.exe`) that holds Credential Guard's protected credential material. Runs in VTL1, unreadable from VTL0 kernel or user processes. Communicates with the VTL0 LSASS through a small RPC surface for authorised authentication operations only.

What does Credential Guard isolate? The Microsoft Learn page is unambiguous: "Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials." [@ms-learn-credential-guard] Those three categories are also the three categories the previous three generations of the family targeted. Pass-the-Hash hits NTLM password hashes. Pass-the-Ticket hits Kerberos TGTs. Overpass-the-Hash hits NTLM password hashes promoted into Kerberos. Credential Guard moves all three out of VTL0 LSASS into VTL1 LSAISO. On a hardware-eligible domain-joined Windows 10/11 system with Credential Guard enabled, all three attacks return empty buffers.

The institutional importance of the change is that under Microsoft's own Windows Security Servicing Criteria, Credential Guard is a security boundary -- which means a bypass is a CVE-class vulnerability rather than a documentation gap.

The criteria's load-bearing definitions: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" and "Does the vulnerability violate the goal or intent of a security boundary or a security feature?" [@msrc-windows-servicing-criteria] Pre-2015 Pass-the-Hash defenses were documentation; Credential Guard is the first defense the criteria treats as CVE-class under the boundary "admin -> VBS (LSAISO trustlet)."

flowchart TD subgraph VTL0[VTL0 normal partition] A[User processes] B[LSASS] K[VTL0 kernel] end subgraph VTL1[VTL1 isolated partition] L[LSAISO trustlet] SK[Secure kernel] end H[Hypervisor] A --> B K --> B B -- authorised RPC only --> L H --> VTL0 H --> VTL1 SK --> L K -. blocked by HVCI .-> L

What does Credential Guard not isolate? This is the load-bearing question for the rest of the article. The same Microsoft Learn page enumerates four caveats, each verbatim.

First, the Active Directory database and the SAM. "Credential Guard doesn't provide protections for the Active Directory database or the Security Accounts Manager (SAM)." [@ms-learn-credential-guard] This is the DCSync gap: an attacker with the right replication privileges can ask a DC to hand over every hash in the directory, and Credential Guard cannot intervene because the data is being released through a legitimate, authorised API rather than being read from LSASS.

Second, domain controllers. "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers." [@ms-learn-credential-guard] The KDC must read the krbtgt account's long-term key in cleartext to issue tickets; the architectural exception is intrinsic to Kerberos rather than a Microsoft oversight.

Third, application credentials outside the "domain credentials" scope. Certificate private keys held by CryptoAPI key containers, third-party authentication package secrets, and -- the one this article eventually argues is the most consequential -- the Primary Refresh Token material held by the CloudAP authentication plug-in, are all out of scope by construction.

Fourth, and most importantly, the institutional acknowledgment of the supersession pattern. Microsoft Learn reproduces it verbatim on the same page, the prophecy the rest of this article spends its time documenting being fulfilled:

While Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques, and you should also incorporate other security strategies and architectures. -- Microsoft Learn, *Credential Guard overview* [@ms-learn-credential-guard]

That sentence, written about the 2015 Credential Guard architecture, accurately predicts the 2021-2022 shift to Pass-the-Certificate and the 2020-present shift to Pass-the-PRT. It is Microsoft's own structural prediction that the family will continue to evolve to the next artefact Credential Guard's verbatim scope does not cover. The rest of this article reads as the unfolding of that prediction.

The Kerberos KDC must read the krbtgt account's long-term key to encrypt the TGT issued in every AS-REP. That key has to be available to the LSA process in cleartext, on every DC, on every ticket issuance, by protocol. Putting krbtgt behind LSAISO would mean issuing every TGT through an inter-trust-level RPC call -- a non-trivial performance penalty on every authentication in an Active Directory forest -- and would not actually close the architectural gap, because the trustlet itself would still need to do the cleartext work that LSASS does today. The exception is honest about an architectural reality rather than concealing it.

PPL and Credential Guard are complementary, not alternatives. itm4n's analysis [@itm4n-lsass-runasppl] makes the case carefully: RunAsPPL raises the bar from "any admin process can read LSASS" to "any signed driver can read LSASS," and Credential Guard closes the signed-driver bypass with hardware-rooted hypervisor isolation. They stack. The 2026 best-practice Windows endpoint has both turned on.

The default-enablement window shows how long this took to land. Credential Guard shipped enabled-by-policy in Windows 10 RTM in 2015, but did not become default-enabled on hardware-eligible domain-joined non-DC systems until Windows 11 22H2 in September 2022 [@ms-learn-credential-guard]. Seven years of uneven deployment.

Note: Four residuals from the Microsoft Learn page: the Active Directory database and the SAM are out of scope; domain controllers are out of scope by recommendation; application credentials outside the "domain credentials" category (certificates, CloudAP material, third-party authentication packages) are out of scope by construction; and persistent threats are expected to shift to new attack techniques. Each residual maps to a later generation of this article: AD database -> DCSync; certificates -> Pass-the-Certificate; CloudAP -> Pass-the-PRT.

Each new credential type needs its own isolation boundary. Credential Guard isolates NT hashes and TGT session keys. It does not isolate certificate private keys, because in 2015 nobody was replaying certificates at scale. And it does not isolate the Primary Refresh Token, because in 2015 the Primary Refresh Token did not yet exist.

Key idea: Each new credential type needs its own isolation boundary. The pattern is reusable but does not transfer automatically -- and the gap between "what fits in the boundary" and "what credentials Windows actually uses" is exactly the territory where the next attack generation grows.

7. Pass-the-Certificate: The Predictable Response

If the NT hash is isolated and RC4-HMAC is banned, what is the next long-term credential Windows accepts? The answer was hiding in plain sight: every Active-Directory-integrated enterprise had been running Microsoft's PKI since 2008, and almost every PKI deployment had at least one template-level catastrophe.

On June 17, 2021, Will Schroeder and Lee Christensen posted "Certified Pre-Owned" on Medium, with the accompanying 143-page whitepaper [@specterops-certified-pre-owned] [@specterops-certified-pre-owned-pdf]. The post named ESC1 through ESC8 in a single document, with paired DETECT and PREVENT recommendations, and shipped three pieces of tooling at the same Black Hat USA 2021 cycle: Certify (offensive enrollment), ForgeCert (golden-certificate forging using a stolen CA private key), and PSPKIAudit (defensive enumeration). The Medium post's tone was unsubtle:

Of note, nearly every environment with AD CS that we've examined for domain escalation misconfigurations has been vulnerable. It's hard for us to overstate what a big deal these issues are. -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* [@specterops-certified-pre-owned]

The ESC catalog organises certificate misconfigurations by the abuse primitive they enable. ESC1 is the canonical example: a published certificate template that allows the enrollee to supply the Subject Alternative Name, contains a client-authentication Extended Key Usage, has permissive enrollment rights, and has no effective approval gates.

An attacker who can enroll for such a template requests a certificate naming a victim principal -- say, the domain administrator -- in the SAN. The certificate's private key is now the attacker's. PKINIT-authenticate to the KDC with that certificate, and the KDC issues a TGT for the named principal. Domain escalation, in three commands.

Microsoft's enterprise PKI. Issues X.509 certificates from administrator-defined templates that pin a certificate's permitted uses (Extended Key Usages), its enrollment authorisation rules, its subject and SAN generation policy, and its revocation behaviour. Ships as a Windows Server role; deployed in essentially every Active-Directory-integrated enterprise. Kerberos pre-authentication using a certificate's private key in place of a long-term symmetric key. Specified by RFC 4556 (L. Zhu and B. Tung, Microsoft and Aerospace, June 2006) [@rfc-4556]. The certificate's UPN SAN (or its dNSHostName for computer accounts) maps the certificate to the principal whose TGT the KDC will issue. PKINIT is the protocol surface most commonly exercised by Pass-the-Certificate against domain controllers that support certificate-based authentication. The Windows TLS implementation. Supports TLS client-certificate authentication, which authenticated LDAPS uses. When a domain controller does not support PKINIT (Schroeder + Christensen documented this case in the original catalog; AlmondOffSec built tooling for it), an attacker can authenticate to LDAPS over Schannel with a stolen client certificate and perform high-privilege LDAP operations without traversing the KDC. The technique of authenticating to Active Directory with a stolen X.509 certificate's private key, via PKINIT to the KDC or via Schannel client-certificate authentication to LDAPS. Named in this form by Yannick Méheut's PassTheCert tool and blog post (May 2022) [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog], though the technique class was catalogued by Schroeder and Christensen eleven months earlier [@specterops-certified-pre-owned]. Tool of record: Certify (C#), Certipy (Python, ESC1-ESC16 [@certipy-wiki-privesc]), and Rubeus PKINIT mode. sequenceDiagram participant Atk as Attacker (user) participant CA as Enterprise CA participant KDC Atk->>CA: Enrol for template ESC1, SAN field set to Domain Administrator CA-->>Atk: X.509 certificate plus private key Note over Atk: Now holds a certificate naming the victim principal Atk->>KDC: AS-REQ with PKINIT pre-auth using the stolen private key KDC->>KDC: Validate certificate, map SAN to victim principal KDC-->>Atk: AS-REP with TGT for victim principal Atk->>KDC: TGS-REQ for any service KDC-->>Atk: TGS-REP service ticket

The CVE-class case lands on May 10, 2022. Oliver Lyak of IFCR discloses Certifried, CVE-2022-26923, an Active Directory Domain Services elevation-of-privilege vulnerability in which the combination of three Microsoft defaults -- ms-DS-MachineAccountQuota = 10 (any authenticated user can add up to 10 computer accounts to the domain), the default Machine template (which a computer account can enroll for), and the KDC's permissive dNSHostName-to-SAN binding logic -- lets any authenticated user obtain a certificate for any computer account in the forest, including domain controllers.

PKINIT-authenticate as a domain controller, and the KDC issues you a TGT for the DC; from there, DCSync extracts the krbtgt key and the domain is yours. Domain escalation from any authenticated user, with the only required misconfiguration being Microsoft's defaults [@nvd-cve-2022-26923] [@semperis-cve-2022-26923].

The defensive response shipped the same day. Microsoft published KB5014754 on May 10, 2022 -- coordinated disclosure, with the patch shipping in the same window as the CVE -- introducing a new X.509 extension szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) that carries the requesting principal's SID at certificate issuance.

The KDC's new strong-mapping logic refuses certificates that fail one of four conditions: the SID extension is present and matches; an issuer-serial mapping is present; a Subject Key Identifier mapping is present; or a SHA1-public-key mapping is present. The KB's load-bearing sentence: "In Full Enforcement mode, if a certificate fails the strong (secure) mapping criteria (see Certificate mappings), authentication will be denied." [@ms-kb5014754]

The KB5014754 change-log preserves a forensic artefact of the coordinated-disclosure timeline that is easy to miss. The current change-log row reads, verbatim: "9/10/2025 - Corrected the Enforcement mode date from September 10, 2025, to September 9, 2025." [@ms-kb5014754] An off-by-one date correction, captured in the public KB. The kind of detail that only shows up when a small team has had to ship a date repeatedly against a multi-year audit-to-enforcement schedule.

The enforcement timeline tells you how long even a CVE-class fix took to drive through deployment. Audit mode (May 10, 2022). Enforcement mode with a registry escape that admins could use to revert to compatibility (February 11, 2025). Final cutover with no escape (September 9, 2025) [@ms-kb5014754]. Three years and four months between the patch and the day Microsoft stopped accepting non-strong certificate mappings. Faster than the Credential Guard default-enablement window, but still measured in years.

The naming history deserves a disambiguation. The catalog -- ESC1 through ESC8, the full taxonomy of AD CS misconfigurations -- is Schroeder and Christensen, June 2021 [@specterops-certified-pre-owned]. The wire-level technique name "Pass-the-Certificate" is popularised by AlmondOffSec's PassTheCert PoC (Yannick Méheut, May 4, 2022), which targets LDAP/S via Schannel client-cert authentication when PKINIT is unavailable, as a fallback path for environments where domain controllers do not support certificate-based Kerberos pre-authentication [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog]. The blog post documents the KDC_ERR_PADATA_TYPE_NOSUPP error path that diverts the PKINIT-blocked attacker into Schannel.

The AlmondOffSec blog post acknowledges the social attribution of the term: "Note for Googlers: this tool extends the notion of Pass the Certificate, thus dubbed by @_nwodtuhs in his Twitter thread on AD CS and PKINIT." [@almondoffsec-passthecert-blog] The technique name is socially attributed; the catalog framing is editorial.

Note: A common shorthand says that KB5014754 bound NTOWFs to Kerberos, and that this is what forced attackers to shift to certificates. That arrow runs backwards in time. KB5014754 is the response to Certifried, not the cause of Pass-the-Certificate. The technique class was catalogued by Schroeder and Christensen in June 2021, eleven months before KB5014754 shipped, and the PassTheCert tool that gave the technique its wire-level name appeared six days before Certifried's disclosure. The shift to certificates happened because certificates were the next long-term credential type Credential Guard did not isolate.

What does KB5014754 actually close? Three specific CVEs in the Certifried family: CVE-2022-26923 (the original SID-spoof Certifried disclosure), CVE-2022-26931 (UPN / sAMAccountName collision spoof), and CVE-2022-34691 (the certificate-pre-dating-account-creation case) [@ms-kb5014754]. What does it not close? The broader ESC2 through ESC8 catalog, which is administrative hardening rather than CVE-class control. And it does not close ESC9 through ESC16, which were enumerated after KB5014754 shipped and include cases like the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension the patch introduced [@specterops-certs-patches-2022] [@certipy-wiki-privesc].

The current state of the catalog: as of the 2025 Certipy 5.x documentation, ESC1 through ESC16 is the practitioner enumeration, with each technique characterised by a template-level, ACL-level, CA-administrator-level, NTLM-relay-level, SID-extension-level, or mapping-level abuse primitive [@certipy-wiki-privesc]. Microsoft Defender for Identity's certificates posture assessment tracks nine distinct ESC numbers as of the 2025 documentation -- ten posture assessments, because ESC4 owner and ESC4 ACL are tracked as separate sub-cases (ESC1, ESC2, ESC3, ESC4 owner, ESC4 ACL, ESC6 preview, ESC7, ESC8, ESC11, ESC15) [@ms-defender-id-certs]. Same pattern as Pass-the-Hash in 2012-2014: documentation tells administrators what to do; the structural exposure is downstream of how each enterprise built its templates years earlier.

ESC ID	Class	Closed by KB5014754
ESC1	Template -- enrollee supplies SAN, client-auth EKU, permissive enrollment	Partial: SID extension binds requester at issuance; ESC1 still works if the SID extension is absent
ESC2	Template -- enrollee supplies SAN, Any-Purpose or no EKU	No -- administrative hardening
ESC3	Template -- Certificate Request Agent enrollment-agent abuse	No -- administrative hardening
ESC4	ACL -- writeable template configuration	No -- administrative hardening
ESC6	CA -- `EDITF_ATTRIBUTESUBJECTALTNAME2` flag set on the CA	No -- CA-level hardening (was MS22-23, separately patched)
ESC8	NTLM relay -- HTTP enrolment endpoints reachable from low-privilege contexts	No -- relay-defence hardening
ESC9	Template -- `CT_FLAG_NO_SECURITY_EXTENSION` exempts template from the SID extension	No -- by design
ESC11	NTLM relay -- ICPR RPC endpoint without sign / seal	No -- relay-defence hardening
ESC16	CA -- security-extension disabled at the CA level	No -- CA-level hardening

Table 1. A representative slice of the ESC1-ESC16 catalog showing what KB5014754 closes and what remains administrative hardening [@specterops-certify-wiki] [@certipy-wiki-privesc] [@specterops-certs-patches-2022].

KB5014754 is a CVE-class fix for one sub-case. The broader ADCS catalog is administrative hardening. And the next credential type -- the one that defeats Credential Guard, Protected Users, and KB5014754 simultaneously -- was already shipping in commodity Mimikatz code by August 2020.

8. Pass-the-PRT: The CloudAP Frontier

By August 2020, Microsoft had two architectural defenses against credential replay that the security industry actually trusted: Credential Guard for local Active Directory credentials, and (eighteen months later) KB5014754 for the certificate-replay class. Then a Dutch security researcher named Dirk-jan Mollema published a 21-minute read that broke both, in the same paragraph, by stealing a different credential type.

The credential is the Primary Refresh Token. The two foundational write-ups are Mollema's "Abusing Azure AD SSO with the Primary Refresh Token" [@mollema-prt-abusing] and its follow-on "Digging further into the Primary Refresh Token" [@mollema-prt-digging], both posted in August 2020. The second post is the single most-cited primary source in the fifth generation of the family. Read it once and you understand why Pass-the-PRT is structurally different from everything that came before.

A PRT is a JSON Web Token refresh token issued by Microsoft Entra ID (formerly Azure AD) to Entra-joined or Hybrid-joined Windows devices, paired with a session key (HMAC-SHA256 secret) and bound to a device key registered at device join.

The Microsoft Entra documentation describes the artefact precisely: "A Primary Refresh Token (PRT) is a key artifact of Microsoft Entra authentication ... Once issued, a PRT is valid for 90 days and is continuously renewed as long as the user actively uses the device." [@ms-entra-concept-prt] On Windows the PRT is renewed every four hours during sign-in. The device-key registration binds the PRT to the device that owns it -- and is what an attacker has to work around to use a stolen PRT on a different device.

The Microsoft Entra-issued long-lived refresh token for SSO on Entra-joined or Hybrid-joined Windows devices. Carries a session key (HMAC-SHA256) used to sign per-request `x-ms-RefreshTokenCredential` cookies, and binds to a device transport key registered at device join. Default lifetime is 90 days with sliding renewal as long as the user actively uses the device; an inactivity timeout governs when an idle PRT must be re-acquired [@ms-entra-concept-prt]. The PRT is the load-bearing artefact for Single Sign-On to every Entra-integrated resource the device's user can reach.

The PRT default lifetime is 90 days per the Microsoft Entra documentation, with renewal every four hours during Windows sign-in [@ms-entra-concept-prt]. The 14-day figure that sometimes appears in secondary references is the inactivity timeout on certain device states, not the PRT lifetime itself; this article uses the Microsoft Entra documentation's value to avoid the conflation.

Where the PRT lives is what makes the rest of the architecture work -- and what makes it vulnerable. The PRT is hybrid: issued and revoked cloud-side by Entra ID, stored and used client-side via the CloudAP authentication plug-in, which is loaded into LSASS like any other Windows authentication package.

The load-bearing structural fact is that CloudAP is in LSASS, not behind the LSAISO trustlet. Credential Guard's classical isolation does not extend to the CloudAP plug-in's working memory, because Credential Guard's scope is the three credential categories its design predates -- NT hashes, Kerberos TGTs, and "domain credentials" -- and the PRT is none of those [@mollema-prt-abusing].

The Windows authentication package (`cloudap.dll`, loaded into LSASS) that handles authentication against Microsoft Entra ID for Entra-joined and Hybrid-joined devices. Holds the device's Primary Refresh Token, its session key, and the derived material used to sign per-request PRT cookies. Sits inside LSASS in VTL0, *not* inside the LSAISO trustlet in VTL1; Credential Guard does not currently extend its isolation to CloudAP's working memory.

The mechanism, as Mollema and Delpy developed it through the second half of 2020, runs as follows. Mimikatz dpapi::cloudapkd /unprotect extracts the PRT (the encrypted-by-Entra refresh-token blob) and the session key from CloudAP's working memory.

The attacker constructs an x-ms-RefreshTokenCredential JWT carrying the PRT in the refresh_token claim, is_primary: true, and a request_nonce obtained by an unauthenticated POST against the Entra ID v1 token endpoint at https://login.microsoftonline.com/common/oauth2/token with form-encoded body grant_type=srv_challenge (the server-challenge nonce pattern used by the ROADtools roadtx prt reference implementation; the response is a JSON object with a Nonce field). The signature is HMAC-SHA256 over the JWT under the session key. The completed cookie is presented to login.microsoftonline.com from any machine, and Entra ID returns access and refresh tokens for any resource the original user can reach. Mollema's second post describes the collaboration that built the tooling:

Around the same time Benjamin Delpy took up my 'challenge' of recovering PRT data from `lsass` with mimikatz. We combined forces and ended up with tooling that is not only able to extract the PRT and associated cryptographic keys (such as the session key) from memory, but can also use these keys to create new SSO cookies or modify existing ones. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The operational tooling closed quickly. Mollema's roadtx prt (part of ROADtools [@roadtools-github]) automates the full chain end-to-end -- extract the material, mint the cookie, complete the OAuth dance, hand the attacker an access token. The Mimikatz dpapi::cloudapkd command landed in the open-source repository the same window. Pass-the-PRT moved from research artefact to commodity tooling in months, not years.

sequenceDiagram participant Victim as Victim device (Entra-joined) participant Attacker as Attacker device participant Entra as login.microsoftonline.com Note over Victim: PRT plus session key held by CloudAP in LSASS Attacker->>Victim: mimikatz dpapi::cloudapkd /unprotect Victim-->>Attacker: PRT (encrypted blob) plus session key Attacker->>Entra: POST /common/oauth2/token grant_type=srv_challenge (unauthenticated) Entra-->>Attacker: request_nonce Note over Attacker: Build x-ms-RefreshTokenCredential JWT Note over Attacker: Sign HMAC-SHA256 with extracted session key Attacker->>Entra: POST /token with PRT cookie Entra-->>Attacker: Access and refresh tokens Attacker->>Attacker: Authenticate to any Entra resource as victim user

Now the analytical core. Pass-the-PRT defeats three Microsoft defenses simultaneously.

First, Credential Guard is out of scope. The CloudAP material is not an NT hash, not a Kerberos TGT, and not "credentials stored by applications as domain credentials" in the verbatim sense the Credential Guard documentation uses. Credential Guard's VBS-based isolation does not extend to CloudAP. The defense was designed in 2015 against the three credential types the family had then; the PRT is a credential type the family had not yet evolved into [@ms-learn-credential-guard].

Second, KB5014754 is out of scope. The PRT cookie does not traverse the KDC's certificate-mapping logic at all; it is a JWT signed by an HMAC and authenticated at the Entra ID token endpoint. The strong certificate mapping that Microsoft drove through five years of audit-to-enforcement timeline has no relevance to a credential that never touches the KDC [@ms-kb5014754].

Third, Protected Users is out of scope. Protected Users is an Active-Directory-only construct, enforced on Windows Server domain controllers and on AD-joined member devices. Entra ID is a separate identity provider with separate enforcement; the 240-minute TGT cap, the NTLM ban, and the RC4 ban that Protected Users enforces simply do not apply [@ms-protected-users].

The TPM-sealing finding is where the architectural pattern becomes most precise. Microsoft began sealing the PRT session key to a TPM-bound key on TPM-2.0-eligible hardware -- a defense that, in principle, makes the raw session key cryptographically non-exportable. Mollema's finding in the August 2020 second post is that the seal does not close the attack, because CloudAP holds derived PRT-cookie-signing material in its own working memory in LSASS, and the attacker only needs the derived material:

despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. The result of this is that regardless of whether the PRT is protected by the TPM or not, with Administrator access it is possible to extract the PRT from LSASS and use the PRT on a different device than it was issued to. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The structural reason the standard hardware-rooted defense pattern does not transfer: the attacker does not need the raw session key out of the TPM. They need only the in-memory derived material CloudAP itself uses to sign the cookies, and that derived material lives in the same address space Credential Guard does not isolate.

The TPM seals the key. CloudAP uses the key. Whatever CloudAP can read, an attacker with administrator and a memory-access primitive can also read. The defense pattern that worked for NT hashes (move them out of the address space) has not been applied to CloudAP -- and until it is, the TPM seal is a speed bump rather than a wall.

{` // Pedagogical demonstration of the JWT structure used in Pass-the-PRT // cookie minting. Uses placeholder values throughout; no real PRT material.

const base64url = (buf) => Buffer.from(buf).toString('base64') .replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_');

const header = { alg: 'HS256', ctx: 'AAAAAAAA' }; const payload = { // The PRT itself, an opaque refresh-token string Entra issued to the // device. In a real attack this comes from mimikatz dpapi::cloudapkd. refresh_token: 'AQABAAAAAAA...redacted...', // Marks this cookie as a primary refresh token cookie. is_primary: 'true', // Fresh nonce from an unauthenticated POST against the v1 token endpoint // at login.microsoftonline.com/common/oauth2/token with form body // grant_type=srv_challenge (returns JSON with Nonce field; the canonical // server-challenge pattern used by ROADtools roadtx prt). request_nonce: 'AwABAAEAAAAC...', iat: Math.floor(Date.now() / 1000), };

// HMAC-SHA256 over the JWT under the session key recovered from CloudAP. // Placeholder key for demonstration only. const sessionKey = Buffer.alloc(32); // 32 bytes of zeros (fake) const crypto = require('crypto');

const h = base64url(JSON.stringify(header)); const p = base64url(JSON.stringify(payload)); const sig = base64url( crypto.createHmac('sha256', sessionKey).update(h + '.' + p).digest() );

console.log('Header segment: ' + h); console.log('Payload segment: ' + p); console.log('Signature segment: ' + sig); console.log(); console.log('Full PRT cookie: ' + h + '.' + p + '.' + sig); // In a real attack the attacker would now POST this as the // x-ms-RefreshTokenCredential cookie to login.microsoftonline.com. `}

The current partial mitigations are worth enumerating, because none of them closes the gap.

Token Protection (a Conditional Access session control) attempts to ensure that only device-bound sign-in session tokens are accepted at the Entra ID token endpoint for protected resources. The Microsoft Learn page is explicit about both the design intent and the deployment limits: "Token Protection is a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources." [@ms-entra-token-protection] As of the current documentation the supported resources are five named applications: Exchange Online, SharePoint Online, Microsoft Teams, Azure Virtual Desktop, and Windows 365. Browser applications are out of scope; "Token Protection currently supports native applications only. Browser-based applications are not supported." [@ms-entra-token-protection] Most Entra-integrated SaaS is unbound.

Continuous Access Evaluation (CAE) shortens the window during which a stolen PRT is operationally usable, by allowing the token endpoint to revoke tokens within minutes of a triggering signal (password change, risk-based detection, conditional-access policy update) [@ms-entra-cae]. CAE is evaluation-time, not isolation. It shortens the window between extraction and detection-driven revocation; it does not prevent extraction.

Hybrid-joined PRT renewal binding partially closes the cross-tenant case for hybrid Azure AD Join configurations, but does not address the same-tenant Pass-the-PRT case that Mollema's original 2020 posts described [@ms-entra-hybrid-join-plan].

The institutional acknowledgment of the supersession pattern is the verbatim Microsoft Learn sentence already quoted in section 6 [@ms-learn-credential-guard]: written about the 2015 Credential Guard architecture, it accurately predicts the 2020 Pass-the-PRT shift. The credential-replay family has reached the point where every Microsoft defense in the on-prem stack runs in parallel against an attack the on-prem stack cannot reach.

Key idea: Pass-the-PRT defeats Credential Guard, KB5014754, and Protected Users simultaneously because each defense was designed around a different long-term artefact, and the PRT is none of them. The architectural property -- a long-term authentication artefact reachable from the using process is replayable -- is unchanged. The artefact moved.

Six years after Mollema's disclosure, the TPM-resilience finding still holds. The CloudAP plug-in is still in LSASS. Credential Guard still does not extend its boundary. Pass-the-PRT remains the operational frontier in 2026.

9. The 5x5 Matrix and the Irregular Cadence

Five generations of attack. Five generations of defense. They map onto each other unevenly; the gaps are not five years.

The matrix below consolidates the lineage at a glance. Rows are the attack generations (in the order they entered the practitioner literature). Columns are the defense generations (in the order they shipped). Each cell records whether that defense closes that attack on a fully-deployed hardware-eligible 2026 Windows 11 endpoint with the control turned on. "Closed" means the attack returns empty buffers or fails authentication; "Partial" means the defense increases attacker cost or closes one sub-case; "Open" means the defense's design scope does not include that attack.

Attack \ Defense	Mitigating-PtH whitepapers (2012/2014)	Protected Users + RunAsPPL + Restricted Admin (2013-2014)	Credential Guard / LSAISO (2015)	KB5014754 strong mapping (2022)	Token Protection + CAE (2023-2025)
Pass-the-Hash (Ashton 1997, Ochoa 2008)	Open (documentation)	Partial (Protected Users members)	Closed (on enabled endpoints)	Open (not in scope)	Open (not in scope)
Pass-the-Ticket (Delpy 2011, Duckwall+Delpy 2014)	Open (documentation)	Partial (4-hour TGT cap for Protected Users)	Closed (TGT session key in LSAISO)	Open (not in scope)	Open (not in scope)
Overpass-the-Hash (Delpy / Metcalf 2014)	Open (documentation)	Partial (RC4 banned for Protected Users)	Closed (NT hash in LSAISO)	Open (not in scope)	Open (not in scope)
Pass-the-Certificate (Schroeder + Christensen 2021, Méheut 2022)	Open (documentation)	Open (cert keys outside scope)	Open (cert keys outside scope)	Partial (closes Certifried sub-case; ESC2-ESC16 remain)	Open (not in scope)
Pass-the-PRT (Mollema + Delpy 2020)	Open (Entra ID is separate IDP)	Open (Entra ID is separate IDP)	Open (CloudAP not in LSAISO)	Open (not in scope)	Partial (5 named resources; browser apps out of scope)

Table 2. The 5x5 attack/defense matrix. The union of every cell in the rightmost column of "Closed" entries is the set of attacks Microsoft's published 2026 defenses close on hardware-eligible non-DC endpoints with every control turned on; that set is precisely the first three rows.

The matrix makes the structure visible. No single defense closes all attacks, and no single attack is closed by all defenses. The union of every defense closes Pass-the-Hash, Pass-the-Ticket, and Overpass-the-Hash on hardware-eligible non-DC Windows 10/11 systems with all controls enabled. It partially closes Pass-the-Certificate (for the Certifried sub-case) and partially closes Pass-the-PRT (for five named resources). Both of the most recent generations remain operationally open against any deployment that does not run those specific controls -- which is most deployments.

The cadence is just as uneven as the matrix. The original input that prompted this article claimed "every Windows defense against credential replay buys about five years before the attack class evolves to the next credential type." Memorable. Also wrong. The actual timeline produces gaps from eleven months to eleven years, with one negative interval:

1997 -> 2008 (eleven years) for the Samba-patch -> Windows-native pivot. Pass-the-Hash existed for over a decade as a Unix-side novelty before Ochoa's LSASS-injection insight made it Windows-native.
2008 -> 2011 (three years) for the Mimikatz Pass-the-Ticket extension. The same memory-access primitive that animated IAM.EXE was retargeted at a different artefact.
2012/2014 -> 2015 (one to three years) for the Mitigating-PtH whitepapers -> Credential Guard pivot. Documentation took a year and a half to ship; the architectural counter took another.
2021 -> 2022 (eleven months) for the AD CS catalog -> KB5014754 response. Coordinated disclosure compressed this gap; Certifried's CVE-class status forced a CVE-class response.
2020 -> 2025+ (open-ended) for Pass-the-PRT with no Credential-Guard-equivalent shipped. As of the Windows 11 25H2 cycle there is no public roadmap for VBS-class isolation of CloudAP material.

The most striking gap is the 2020/2021 negative interval. Pass-the-PRT (Mollema, August 2020) and the AD CS catalog (Schroeder + Christensen, June 2021) are siblings rather than sequential; Pass-the-PRT predates Pass-the-Certificate as a named technique by ten months, even though the article treats them as Generation 4 and Generation 5 in narrative order. The Generation N -> N+1 framing is taxonomic, not strictly chronological. The reader needs this distinction to read the lineage accurately: the attack class evolves along the architectural property, not along the calendar.

Note: The "every Windows defense buys five years" framing is what you see if you select the cleanest pairings (Mitigating-PtH 2012/2014 to Credential Guard 2015 plus an artificial 2020-targeted "next attack"). When you look at the actual intervals, you see eleven years (1997-2008), three years (2008-2011), eleven months (2021-2022), and an open-ended interval (2020 onwards). The pattern is the architectural property persisting across artefact changes, not a calendar drumbeat.

The storage-class progression is the cleanest way to see the property hold across the lineage. Each row names the long-term artefact, where it lives, and which defense moved or shielded that storage class.

Generation	Long-term artefact	Storage location	Defense that isolated it	Status 2026
1A (1997 Samba)	NT hash (and LM hash)	Local SAM file on disk	"Do not store LAN Manager hash" policy (Vista default-on); SAM hash extraction still works	LM hash retired; NT hash extraction still works
1B (2008 Windows-native)	NT hash	LSASS credential cache	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
2 (2011 Mimikatz)	Kerberos TGT plus session key	LSASS Kerberos package	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
3 (2014)	NT hash promoted to RC4-HMAC Kerberos key	LSASS, same buffer as Pass-the-Hash	Credential Guard relocates to LSAISO; KB5021131 makes AES the default	Closed on Credential-Guard-enabled endpoints; RC4 deprecated in favour of AES [@ms-kb5021131]
4 (2021 AD CS catalog)	X.509 certificate private key	CryptoAPI key container, TPM, or smart card	TPM-resident or VSC-resident keys are cryptographically non-exportable; KB5014754 binds certificates to SIDs at issuance	Partial; ESC2-ESC16 misconfigurations remain administrative hardening
5 (2020 Pass-the-PRT)	PRT session key plus derived signing material	CloudAP plug-in in LSASS (session key optionally TPM-sealed)	None deployed; Token Protection partially shields five resources	Open

Table 3. Storage-class progression. Each attack generation targets the next long-term artefact whose storage location is not isolated by the previous generation's defense.

The matrix and the storage-class table jointly produce the structural prediction: each generation shifts to the next available long-term artefact whose storage class the latest defense does not isolate. The graph-based formalisation of these storage-class transitions is the BloodHound edge catalog -- the HasSession, AdminTo, and CanRDP family that operationalises "which principal can reach which credential from where" as a queryable property of an enterprise's directory [@bloodhound-edges]. The pattern predicts a Generation 6 outside whatever isolation scope arrives next.

The most credible candidate today is Pass-the-DeviceKey: extraction or abuse of the device transport key the PRT binds to, or of the CloudAP-derived material the cookie-signing process produces from it [@mollema-prt-phishing]. Mollema's 2023-2025 continuation work documents the underlying device-transport-key primitives in detail; the September 2025 Actor-tokens disclosure shows that cross-tenant abuse of related Entra-side material is also operational in the wild [@mollema-actor-tokens] [@mollema-federated-credentials].

flowchart TD A1[Pass-the-Hash 1A Samba
Ashton 1997] A2[Pass-the-Hash 1B Windows-native
Ochoa 2008] A3[Pass-the-Ticket
Delpy 2011] A4[Overpass-the-Hash
Delpy / Metcalf 2014] A5[Pass-the-Certificate
Schroeder + Christensen 2021] A6[Pass-the-PRT
Mollema + Delpy 2020] A7[Pass-the-DeviceKey forecast] D1[Mitigating-PtH whitepapers
v1 2012, v2 2014] D2[Protected Users + RunAsPPL + Restricted Admin
2013-2014] D3[Credential Guard / LSAISO
2015, default 2022] D4[KB5014754 strong mapping
2022, enforced 2025] D5[Token Protection + CAE
2023-2025] D6[CloudAP isolation forecast] A1 --> A2 A2 --> A3 A3 --> A4 A4 --> A5 A4 --> A6 A6 --> A7 D1 --> D2 D2 --> D3 D3 --> D4 D4 --> D5 D5 -.- D6 A2 -.- D1 A2 -.- D2 A3 -.- D3 A4 -.- D3 A5 -.- D4 A6 -.- D5 A7 -.- D6

If the pattern holds, Generation 6 is already in research literature. Mollema's 2023-2025 continuation work [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens] documents the device-transport-key extraction primitives. The only things missing are the name and the commodity tool. The historical pattern says we probably get both before VBS-class CloudAP isolation ships.

10. Open Problems and the 2026-2030 Forecast

The credential-replay family has six load-bearing open problems in 2026. Each is structural rather than mathematical; the cryptographic primitives that would close them already exist.

The architectural lower bound -- the only configuration that closes the family in principle -- is the union of three things.

Universal hardware-rooted non-extractable keys: every long-term authentication artefact lives in a TPM, secure enclave, FIDO2 authenticator, or smart card, with key attestation, and is never released to software memory. Universal protocol-layer token binding: every issued token (Kerberos service ticket, OAuth refresh token, OIDC ID token, SAML assertion) is cryptographically bound to the device that requested it, and a verifier rejects any presentation from a non-bound device. Universal continuous evaluation: every protected resource queries the issuer in near-real-time and revokes within minutes of a triggering signal. Each component is deployed somewhere; none is deployed everywhere; no single vendor controls all three layers.

The five concrete open problems flow from the lower bound.

The CloudAP isolation problem. When does Microsoft extend VBS-class isolation to the CloudAP plug-in's working memory in LSASS? No public roadmap as of 2026. Until it ships, Pass-the-PRT remains operationally open against every Entra-joined Windows endpoint.

The token-binding adoption problem. Token Protection's verbatim 2026 scope is the five named resources enumerated in section 8 [@ms-entra-token-protection], which covers approximately five percent of typical Entra-integrated SaaS surface area; every other Entra-integrated resource accepts unbound tokens. The OAuth working group's RFC 9449 (DPoP, September 2023) standardises proof-of-possession at the OAuth layer [@rfc-9449], but adoption across SaaS providers and enterprise applications is uneven.

The Pass-the-DeviceKey forecast. Mollema's 2023-2025 continuation work exercises device-transport-key extraction primitives, federated-credential persistence on Entra applications, and cross-tenant Actor-token abuse [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens]. The pattern of every previous generation predicts that whichever of these primitives commoditises first will be the next named "Pass-the-X" technique.

The ESC9-ESC16 hardening problem. The AD CS catalog has grown from 8 entries (June 2021) to 16 (current Certipy and Certify wikis [@certipy-wiki-privesc] [@specterops-certify-wiki]); most additions are misconfiguration-class rather than CVE-class. ESC9 specifically describes the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension KB5014754 introduced -- so administrators who turn that flag on for legacy compatibility reasons silently re-enable the Certifried-class abuse path on those templates.

Hardware-backed identity ubiquity. When does the union of Pluton + FIDO2 + virtual smart cards + TPM key attestation eliminate the long-term software-extractable artefact class? Human interactive sign-in to Entra ID can already be fully passwordless on supported hardware. The long tail of service accounts, scheduled tasks, on-prem AD workflows, and legacy applications resists migration; the migration is a years-long enterprise project, not a feature flag.

The non-Microsoft sibling lineages. The credential-replay family is not Windows-specific. Okta session-cookie theft, Google IDP refresh-token reuse, Apple ASWebAuthSession token replay, and AWS STS session-token theft all face the same architectural property. An enterprise running Microsoft plus Okta plus Google inherits the union of every vendor's residual replay surface. The family generalises beyond Microsoft because the architectural property generalises beyond Microsoft.

Okta's `sessionToken` and OAuth `refresh_token` artefacts live on the device that requested them, and have been used in commodity offensive tooling since at least 2022. Google's IDP refresh tokens face the same exposure surface on managed Chromebooks. Apple's ASWebAuthSession tokens are device-bound at the platform level, which closes the cross-device replay case but not the same-device extraction case. AWS STS session tokens are not device-bound at all. The credential-replay family is a property of long-term software-extractable authentication artefacts in general; this article is Windows-specific only because Windows has the longest documented lineage.

The institutional position is that the protocol-level fix is unavailable -- Microsoft's framing of Pass-the-Hash as a structural property of NTLM generalises directly to every later generation. A universal fix would require replacing every long-term software-extractable artefact globally with hardware-bound primitives, with mandatory token binding at every issuer and every resource server, with continuous evaluation everywhere. Each step is incrementally closable; the union has not yet closed for any deployment.

Note: Universal hardware-rooted non-extractable keys, universal protocol-layer token binding, universal continuous evaluation. Each component is deployed somewhere; none is deployed everywhere. No single vendor controls all three layers.

The architectural property the family shares has held for twenty-nine years; the defensive lineage will not close it without making every long-term artefact live in hardware-rooted isolation that exceeds the host's privilege. Whether that happens in the next five years, the next ten, or the next twenty-five, is the open question the next chapter of this lineage will answer.

11. The 2026 Defender Playbook

Architectural humility does not mean defensive passivity. The 2026 estate is defensible against generations 1 through 3 and partially against generation 4; the playbook is to deploy every available control while reading Mollema's 2025 posts to know what's coming for generation 5 and beyond.

Credential Guard everywhere it can run. Hardware-eligible non-DC Windows 10/11 endpoints, with the four-residual disclosure (AD database, DCs, certificate keys, CloudAP) documented for the SOC so that detection engineering does not assume Credential Guard covers categories it explicitly excludes [@ms-learn-credential-guard].
LSA Protection (RunAsPPL), UEFI-anchored stacked underneath, per itm4n's "complementary" framing [@itm4n-lsass-runasppl]. The UEFI-anchored variant resists the registry-based bypass that a kernel-mode attacker can otherwise apply at boot.
Authentication Silos and Protected Users for Tier-0 accounts. Expect to encounter unconstrained-delegation breakage on legacy services and budget remediation; the 240-minute TGT cap is the lever that prevents long-lived Tier-0 ticket reuse [@ms-protected-users].
KB5014754 strong-mapping enforcement -- fully on by the September 9, 2025 cutover -- plus an annual certificate-template audit cycle against the ESC1-ESC16 catalog using Certipy or PSPKIAudit [@ms-kb5014754] [@certipy-wiki-privesc]. The audit is the load-bearing control because the strong-mapping fix only closes Certifried-class abuses; the template misconfigurations Schroeder and Christensen catalogued are still administrative responsibility.
Conditional Access with Token Protection where supported -- the five resources Microsoft Learn enumerates [@ms-entra-token-protection]. Device-bound sign-ins for privileged accounts; FIDO2 for human interactive sign-in. Know that the long tail of Entra-integrated SaaS does not enforce binding, and that a stolen PRT used against an unbound resource will still authenticate.
PRT-extraction telemetry. Detect CloudAP-plug-in token access from non-CloudAP processes; tie to Endpoint DLP; alert on out-of-band access to cloudap.dll-owned regions of LSASS memory. Mollema's roadtx and BARK produce signal patterns worth modelling.
Mental model: assume the PRT is the next NT hash. Architect today as if Credential Guard for CloudAP shipped tomorrow -- which means TPM-attested device joins as standard, FIDO2 for every human sign-in, hardware-backed identity for service accounts wherever the vendor supports it, and conditional access policies that treat unmanaged or non-attested devices as untrusted by default.

Open PowerShell as administrator and run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List

The result of interest is SecurityServicesRunning. A value of 1 in that list means Credential Guard is actively running (per the Win32_DeviceGuard documentation: 1 = Credential Guard, 2 = HVCI, 3 = System Guard secure launch, etc.). SecurityServicesConfigured tells you what the policy intends; SecurityServicesRunning tells you what the hypervisor is actually enforcing right now. The two values disagree more often than you would expect, usually because the hardware did not meet a prerequisite at boot.

Note: The minimum-viable layer: Credential Guard on every hardware-eligible non-DC endpoint, KB5014754 enforcement-mode certificate strong mapping with an annual ESC catalog audit, and PRT-extraction telemetry tied to a real detection workflow. The first two are commodity Microsoft features that close real attack classes today; the third is the only meaningful signal you can get on the attack class that none of the published defenses currently closes.

None of this closes Pass-the-PRT. All of it shortens the dwell time.

12. Frequently Asked Questions

No. The Primary Refresh Token sits in the CloudAP plug-in, which is outside Credential Guard's verbatim three-credential scope -- see section 6 ("What does Credential Guard isolate?") and section 8 ("Pass-the-PRT defeats three Microsoft defenses simultaneously") for the full mechanism. No. The 1997 Ashton patch and the 2008 Ochoa Windows-native pivot are both pre-Mimikatz; see section 1 and section 3 for the full origin story. Mimikatz is the dominant *tool* (May 2011 first release) but it is not the *origin* of Pass-the-Hash. No. The PRT is *hybrid* -- issued and revoked cloud-side by Entra ID, but stored and used client-side via the CloudAP plug-in inside LSASS. See section 8 ("Where the PRT *lives*") for why this hybrid architecture is what makes Pass-the-PRT operationally tractable today. No. It closed the three Certifried-class CVEs (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) but not the broader ESC2 through ESC16 catalog. See section 7 ("What does KB5014754 actually close?") and Table 1 for the per-template breakdown. For human interactive sign-in to Entra ID, mostly, if the entire enterprise migrates -- the FIDO2 authenticator holds a non-extractable private key in hardware, and the resulting authentication is bound to that key. For service accounts, scheduled tasks, on-prem Kerberos workflows, hybrid identity scenarios, and the long tail of legacy applications, no -- those paths still rely on long-term software-extractable artefacts (passwords, hashes, keys) by construction. The architectural counter is universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation; the operational reality is partial coverage. No public v3. See section 5 ("The Mitigating-PtH v3 that never shipped") for the source-by-source disambiguation against Microsoft Download Center ID 36036.

13. The Pattern That Outlived Six Defenses

The 1997 patch and the 2026 attack are the same attack because the architectural property the family shares is unchanged. The artefact moved; the property did not.

A long-term authentication artefact reachable by the using process is replayable. The NT hash sat in LSASS on Windows NT 4.0 and replayed against SMB. The Kerberos TGT sat in LSASS on Windows Server 2003 and replayed against Kerberos services. The NT hash sat in LSASS on Windows Server 2008 and replayed against the KDC's RC4-HMAC authentication path as a real Kerberos client.

The X.509 certificate private key sat in a CryptoAPI key container on Windows Server 2012 R2 and replayed against PKINIT-supporting domain controllers as the principal in the SAN. The Primary Refresh Token sits in the CloudAP plug-in inside LSASS on Windows 11 23H2 today, and replays against Entra ID as the device's user from any machine that holds the extracted session key.

Each defense relocated the artefact to a harder-to-reach storage class. The "Do not store LAN Manager hash" policy retired LM. RunAsPPL marked LSASS as a Protected Process Light. Credential Guard moved NT hashes and TGT session keys out of LSASS in VTL0 into the LSAISO trustlet in VTL1. KB5014754 bound certificates to SIDs at issuance, so that a certificate without the SID extension fails strong mapping at the KDC. Token Protection bound PRTs to devices, so that a stolen PRT used against a supported resource from a non-bound device fails.

Each defense was real. Each closed a generation. The family did not close.

The reason the family does not close is structural. Every generation finds the next long-term artefact whose storage class the latest defense did not isolate. Pass-the-Hash worked because the NT hash was reachable. Pass-the-Ticket worked because the TGT was reachable. Overpass-the-Hash worked because the NT hash was reachable and the KDC accepted RC4-HMAC. Pass-the-Certificate worked because certificate templates were misconfigured and the SID extension did not exist. Pass-the-PRT works because CloudAP is in LSASS in VTL0 and Token Protection covers five resources.

The architectural lower bound -- universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation -- is the only configuration that closes the family, and it is not deployed anywhere as a complete stack.

The playbook in the previous section is what to do today. The forecast in section 10 is what to architect for next. The closing observation is the one this article exists to register: when you read about the next named "Pass-the-X" technique, you already know what it will look like. A long-term authentication artefact, reachable from the process that holds it, replayed from a different machine, defeating the latest defense because that defense was designed for a different artefact.

Generation 6 is already in research literature. The only thing missing is the name.

Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps

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

**Microsoft Defender for Identity (MDI) is the cloud-backed, on-DC defensive sensor that watches for almost every offensive Active Directory primitive in the SpecterOps / Mimikatz / Certipy corpus** -- DCSync, DCShadow, Golden / Silver / Diamond ticket forgery, Kerberoasting, AS-REP roasting, NTLM relay, and AD CS abuse -- by parsing Kerberos, NTLM, LDAP, and DRSUAPI on the wire and running per-principal behavioural baselines in a multi-tenant cloud backend. The product began as the Israeli startup Aorato (acquired by Microsoft in November 2014), shipped on-prem as Microsoft ATA in 2015, moved to the cloud as Azure ATP in 2018, was renamed to MDI in 2020, folded into Microsoft Defender XDR at Ignite 2023, and reached its current MDE-integrated v3.x sensor in October 2025. The alert catalogue maps cleanly onto MITRE ATT&CK, and the residual blind spots are knowable: the Credential Guard wall, the Sapphire Ticket's cryptographic indistinguishability, the encrypted-channel DCSync class, the cross-forest under-instrumentation tail, and legitimate-principal compromise. The operator question in 2026 is not whether MDI detects the attack, but whether the sensor is deployed, the alert was triaged inside the batched-emission window, and the residuals are covered by KQL, Sigma rules, or out-of-band controls.

1. A Friday Afternoon at the Domain Controller

Friday, 14:33. A red-team contractor in conference room C runs Rubeus.exe asreproast on a corporate laptop she was issued an hour ago. A junior auditor on the fourth floor, working from a desk with read-only Active Directory access, runs bloodhound-python -c All for a routine quarterly review. A quiet service account on the SQL host in rack 14 runs mimikatz "lsadump::dcsync /domain:contoso.com /user:Administrator". The operator at the other end of that session is not on the payroll. Three different workstations. Three different intents. One domain controller on the receiving end of all three.

The Security Operations Center has not noticed any of them yet. The watcher on the domain controller, however, has. By 14:35 three named alerts are sitting in the Defender XDR queue, each tagged with a MITRE ATT&CK technique ID, each waiting for someone to triage. Suspected AS-REP Roasting attack (T1558.004) for the Rubeus invocation [@mslearn-mdi-alerts-xdr]. Security principal reconnaissance (LDAP) for the BloodHound enumeration [@mslearn-mdi-alerts-mdi-classic]. Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006, for the Mimikatz call [@mslearn-mdi-alerts-mdi-classic][@mitre-t1003-006]. The watcher is Microsoft Defender for Identity.SOC operators inside Microsoft customers describe this with a stock phrase: "the watcher was already on the DC." The phrase shows up in incident-response runbooks, vendor training decks, and the Microsoft Defender for Identity Tech Community archive. It captures what is, architecturally, a strange thing -- the defender's sensor is co-located with the attacker's target, not perched outside it.

A Windows Server hosting the Active Directory Domain Services role, responsible for processing Kerberos authentication, NTLM challenges, LDAP queries, and inter-DC directory replication (DRSUAPI) for a domain. Every named MDI runtime alert in this article fires on signal that originates on or transits a domain controller; the deployment model assumes one MDI sensor per DC, plus optional sensors on AD FS, AD CS, and Microsoft Entra Connect servers when those identity roles run on dedicated hosts.

Almost every offensive AD primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus already knows has a runtime alert or a posture assessment shipped by Microsoft on that same DC. Almost is the load-bearing word. The alert fires only if three things are true: the sensor is deployed on the surface the attack touches, the audit subcategory the alert depends on is enabled, and the SOC opens the Defender XDR incident inside the batched-emission window the cloud backend uses to aggregate signal. This article is about all three conditions, the twelve-year arc that built the watcher, and the structural blind spots no future MDI release will close.

The watcher was not always on the domain controller. For the first decade of Active Directory, nothing on the DC saw what BloodHound today maps. To understand where the watcher came from -- and why its blind spots look the way they do -- we have to start with three founders in Herzliya and a Kerberos forgery presentation in Las Vegas.

2. Origins -- Aorato, the Israeli Startup That Became the Watcher

August 2014, Black Hat USA. Tal Be'ery and Michael Cherny take the stage with Alva Duckwall and Benjamin Delpy to present "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It," a demonstration that a stolen krbtgt key lets an attacker mint Kerberos ticket-granting tickets that survive every password rotation in the standard remediation playbook [@blackhat-us14-briefings]. The audience is Active Directory operators who thought their password-reset runbook covered them. By the end of the talk it does not. The startup behind the research is Aorato, three years old, headquartered in Herzliya, Israel. Three months later, Microsoft buys it.

The credential a Kerberos client receives from the Key Distribution Center (the KDC, which on a Windows network runs on every DC) after successful pre-authentication. The TGT is encrypted with the KDC's own long-term key -- on Active Directory, the password hash of the `krbtgt` account. Possession of the `krbtgt` hash therefore lets an attacker forge a valid TGT for any principal in the domain, since the KDC has no other way to distinguish a forged ticket from a real one. This forged-ticket class is what MITRE catalogues as T1558.001 Golden Ticket [@mitre-t1558-001].

The Aorato deal closed on November 13, 2014, announced on the Microsoft Official Blog by Takeshi Numoto, then Corporate Vice President of Cloud and Enterprise Marketing [@msblog-aorato]. The post named the central technology Microsoft was acquiring: Aorato's Organizational Security Graph, described as "a living, continuously-updated view of all of the people and machines accessing an organization's Windows Server Active Directory." Pre-acquisition Microsoft had Azure AD on the cloud side and per-DC event log auditing on the on-prem side, but no first-party behavioural-analytics product over Active Directory. Aorato's pre-acquisition product, the Directory Services Application Firewall, did exactly that -- it parsed Kerberos, NTLM, LDAP, and DRSUAPI on the wire and ran per-principal behavioural baselines against the parsed protocol stream. Microsoft wanted that capability inside Windows Server, and inside Office 365.Aorato's three founders, per the Globes coverage of the acquisition in November 2014, were Idan Plotnik (CEO), Michael Dolinsky (VP R&D), and Ohad Plotnik (VP professional services). Tal Be'ery was VP of Research. A popular reading of the deal names "the Plotnik brothers and Tal Be'ery" as the co-founder trio, which compresses out Dolinsky's role -- the contemporaneous record names four people, not three [@globes-aorato-2014].

The product lineage that follows is twelve years long and runs through five names. Microsoft Advanced Threat Analytics (ATA) was announced as generally available on August 27, 2015 (build 1.4.2457, dated August 31, 2015) -- the on-prem productisation of Aorato's wire-side parser, packaged as a SPAN-mirror appliance ("ATA Gateway") plus an on-prem analytics server ("ATA Center") with its own MongoDB-style document store [@mstc-ata-ga][@atadocs-versions]. Azure ATP went GA on March 1, 2018 -- the cloud-side rewrite that kept the on-DC sensor but moved the analytics engine to a multi-tenant cloud backend [@mstc-azureatp-ga][@mstc-azureatp-intro]. Microsoft Defender for Identity was the September 22, 2020 rename announced at Ignite 2020, part of Microsoft's broader brand consolidation that also rebranded Office 365 ATP to Microsoft Defender for Office 365 and Microsoft Defender ATP to Microsoft Defender for Endpoint [@mssecblog-unified-xdr][@itpro-defender-rebrand][@infusedinnov-names]. The November 2023 Ignite keynote consolidated Microsoft 365 Defender into Microsoft Defender XDR [@virtreview-ignite2023][@handsontek-defender-rebrand]. In October 2025 the v3.x sensor GA folded MDI's on-DC sensor into the Microsoft Defender for Endpoint agent that organisations were already running on every server [@mslearn-mdi-whats-new][@modernsec-v3x][@jeffreyappel-v2v3]. The May 2026 release notes extended the v3.x sensor to cover AD FS, AD CS, and Microsoft Entra Connect identity roles directly when those roles run on a domain controller, and raised the per-workspace sensor cap from 350 to 1,000 [@mslearn-mdi-whats-new].

gantt title Microsoft Defender for Identity lineage, 2012-2026 dateFormat YYYY-MM-DD axisFormat %Y section Aorato Aorato startup (DSAF product) :a1, 2012-01-01, 2014-11-13 section Microsoft ATA ATA initial release SPAN-mirror Gateway :a2, 2015-08-27, 2016-05-01 ATA 1.6-1.9 Lightweight Gateway :a3, 2016-05-01, 2018-03-01 ATA Extended Support window :a4, 2018-03-01, 2026-01-31 section Cloud rewrite Azure ATP GA :a5, 2018-03-01, 2020-09-22 Microsoft Defender for Identity name :a6, 2020-09-22, 2023-11-15 section Defender XDR era MDI inside Defender XDR (v2.x) :a7, 2023-11-15, 2025-10-01 MDI v3.x MDE-integrated sensor :a8, 2025-10-01, 2026-05-27

Aorato's pitch in 2014 was that the Windows Security event log -- the thing every SIEM in the world was ingesting -- could not see the attacks an Active Directory operator most needed to catch. To believe that pitch you have to know exactly what the event log misses.

3. Why the Event Log Could Not See Golden Tickets

Present a Golden Ticket to a domain controller, and the LSA writes a successful event 4769 -- a Kerberos service ticket request. Present a legitimate ticket from the same principal, and the LSA writes a successful event 4769. Nothing in the event log's schema, anywhere in any field, distinguishes the two. The ticket is forged with the real krbtgt key, so the KDC's signature checks pass. The event log records that an authentication happened, not whether the ticket presented was genuine. This is the structural ceiling the SIEM industry could not work around for the first decade of its existence, and it is the gap Aorato was built to close [@mitre-t1558-001][@semperis-golden-ticket].

The bare-event-log model has three structural failure modes, each of which drove a generation of detection engineering. Forged-ticket invisibility is the first: the LSA logs that an auth happened, but every byte in the 4769 event matches the legitimate case. Per-DC silo is the second: a Kerberos auth against one DC and a follow-up auth against another DC five seconds later sit in two different Security.evtx files, on two different machines, with no aggregation layer to ask "did the same principal hit ten DCs in five minutes?" Manual-review throughput collapse is the third: a medium-sized forest emits thousands of 4624, 4768, 4769 events per minute per DC, and the human analyst hand-walking them never catches up.

DCSync makes the first two failure modes vivid. Sean Metcalf's September 2015 ADSecurity writeup walks through running lsadump::dcsync /domain:contoso.com /user:Administrator from a workstation: the DC handles the DRSUAPI replication request, the LSA emits a 4662 event for the directory-service-object access, and the attacker walks away with the password hash [@adsec-dcsync].Metcalf's companion DerbyCon V talk, Red vs. Blue: Modern Active Directory Attacks & Defense (September 2015), is the canonical operator-grade introduction to the same material [@adsec-dump-ad]. The 4662 event is structurally indistinguishable from a legitimate replication request between two DCs. A SIEM rule that flagged 4662 events whose source IP was not a DC could catch it -- but only if the analyst maintained the IP allowlist (a single Microsoft Entra Connect server in the wrong subnet broke the rule), and only if 4662 was enabled at all (it was high-volume, and many SOCs disabled it to stay under the SIEM's GB/day licence).

Key idea: The SIEM was not failing at Active Directory detection because the rules were wrong. It was failing because the event log -- the data source every SIEM relied on -- could not see what the SIEM needed it to see. Better rules over the same event log would not have closed the gap. Aorato's contribution was to find a different data source: the wire itself.

Aorato's three primitives, none of which the SIEM-plus-event-log model had, were: per-principal behavioural baselines so that a long-tail anomaly stood out without anybody writing a rule for it; on-DC network capture so that the ticket structure, the DRSUAPI opnum, and the LDAP search filter were available to detection logic; and a graph over the directory so that the path from compromised workstation to crown-jewel asset could be computed rather than inferred. ATA shipped the first two in 2015. The graph took longer.

4. Early Approaches -- ATA 1.x and the Generations That Tried Before

By the time Aorato shipped its first product, four prior generations of Active Directory detection had already tried and stalled. Each one could see something the previous generation could not. Each one had a structural ceiling an attacker primitive eventually pushed through. The seven generations that follow are the real spine of the article.

flowchart LR G1["Gen 1: bare per-DC
event log audit"] --> G2["Gen 2: SIEM-centralised
events with static rules"] G2 --> G3["Gen 3: first-generation UEBA
over SIEM events"] G3 --> G4["Gen 4: Aorato DSAF and
ATA 1.4-1.5 (SPAN mirror)"] G4 --> G5["Gen 5: ATA 1.6-1.9
(Lightweight Gateway + LMP)"] G5 --> G6["Gen 6: Azure ATP, MDI v1.x-v2.x
(cloud analytics)"] G6 --> G7["Gen 7: MDI v3.x
(MDE-integrated + Identity Explorer)"]

Generation 1 -- bare per-DC event log auditing (1999-2008) was already covered above. It was the only model that existed for the first decade of Active Directory, and its structural ceilings became Aorato's pitch deck.

Generation 2 -- SIEM-centralised event log ingestion with static correlation rules (2005-2014) is the era of ArcSight, Splunk, QRadar, and LogRhythm. Windows Event Forwarder agents on every DC streamed Security event log entries into a central index, and SOC operators wrote rule-based correlation searches in the vendor's query language. The model gave the SOC cross-DC correlation, a query language, and an audit trail that satisfied PCI-DSS Requirement 10. It did not give the SOC anything new about the data the LSA emitted. Mimikatz's lsadump::dcsync was committed to the public Mimikatz repository in March 2015 [@mimikatz-github][@adsec-dcsync]. Sean Metcalf's longer ADSecurity writeup of the technique followed in September 2015. At commit time, every SIEM in production was correlating DC event logs and not one was emitting a DCSync alert, because the 4662 event was structurally identical to a legitimate DC-to-DC replication.

Generation 3 -- first-generation UEBA on SIEM event data (2013-2017) was Securonix, Exabeam, and Splunk UBA. Per-principal behavioural baselines layered on top of the SIEM event index could catch novel TTPs without prior signatures -- a Kerberoasting variant whose SPN list had never been seen before could still trip "this account is requesting an unusual number of service tickets compared to its baseline." UEBA also closed Generation 2's per-principal context gap. It did not, however, see ticket structure: a Golden Ticket replayed against ten DCs produces ten successful auths that are behaviourally indistinguishable from the legitimate Domain Admin's pattern unless the attacker's source IP or geographic distribution breaks the baseline. This is the legitimate-principal-compromise non-detection class that survives every defensive generation into 2026.

Generation 4 -- on-wire protocol analytics via off-DC SPAN-mirror Gateway is where Aorato's product, and then Microsoft ATA 1.4 and 1.5, lived. A switch SPAN port mirrored DC traffic to a dedicated ATA Gateway appliance, which ran libpcap-equivalent capture and parsed Kerberos AS-REQ / TGS-REQ / AP-REQ, NTLM challenges, LDAP searches, and DRSUAPI replication calls. Parsed events streamed to the on-prem ATA Center, which ran detection logic and surfaced alerts in a web console [@mstc-ata-ga]. The wire-side parse closed Generation 1-3's biggest blind spot: ticket structure was finally visible. The SPAN-port operational tax killed the architecture in nine months. Many enterprises could not provision a SPAN mirror. Virtualised DCs on shared hypervisors had no equivalent of a physical SPAN. And the security review of "all DC traffic now mirrors to this appliance" was non-trivial.

Generation 5 -- ATA 1.6 Lightweight Gateway through ATA 1.9 (May 2016 to March 2020) moved the Gateway in-process onto the DC itself. ATA 1.6 (May 2016) introduced the Lightweight Gateway with dynamic resource management that capped the sensor's CPU and memory footprint and let the sensor consume events locally rather than via mirrored network traffic [@mslearn-ata-1-6]. ATA 1.7 (August 31, 2016) added Role-Based Access Control for the ATA Console, Windows Server Core support, and detection of reconnaissance through directory-services enumeration [@mssupport-ata-1-7][@atadocs-versions]. ATA 1.8 (June 30, 2017; announced July 26, 2017) shipped behavioural-brute-force detection, a Golden Ticket lifetime detector, and the abnormal-modification-of-sensitive-groups alert [@mslearn-ata-1-8][@mstc-ata-1-8][@ataversions-1-8-availability]. ATA 1.9 (March 21, 2018) shipped both the entity-profile lateral-movement-aware view and the Lateral movement paths to sensitive accounts report [@mslearn-ata-1-9][@atadocs-versions][@atadocs-lmp-usecase].A widespread reading of the ATA timeline anchors LMP to ATA 1.7 in late 2017. The primary record contradicts this on both date and feature: ATA 1.7 shipped on August 31, 2016 per the Microsoft Support KB and the ATA-versions table, and the 1.7 release notes do not mention Lateral Movement Paths. Neither do the 1.8 release notes -- LMP first appears in ATA 1.9 (March 21, 2018), which introduced both the entity-profile lateral-movement view and the full Lateral movement paths to sensitive accounts report in the same release [@mssupport-ata-1-7][@atadocs-versions][@mslearn-ata-1-8][@mslearn-ata-1-9].

Note: A popular framing of the LMP timeline says "Microsoft adopted BloodHound-style graph attack paths in 2022." The primary sources contradict this. Graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), not in any 2022 adoption event. What did happen in 2022 was the start of the deprecation arc for the SAM-R-based discovery the LMP graph depended on, which culminated in Message Center notice MC1073068 in May 2025 when Microsoft disabled SAM-R-based local-administrators collection across MDI tenants [@handsontek-mc1073068]. The 2022 date that lingers in operator memory is the deprecation anchor, not the adoption anchor.

An attack chain through Active Directory in which a non-sensitive account whose credentials are exposed on one workstation can be used to authenticate to a second workstation where a sensitive account's credentials are cached, which in turn can be used to reach a third workstation, and so on until a Domain Admin or comparable target is reached. ATA 1.9's Lateral Movement Paths report was the first graph-anchored defensive surface that computed the chain in advance; the report was populated by SAM-R queries that enumerated each host's local-administrators group. Microsoft disabled the SAM-R-based collection in May 2025 (MC1073068), and the post-LMP graph layer migrated to the Defender XDR hunting graph plus the April 2026 Identity Explorer preview.

The limitation that drove Generation 5 into Generation 6 was the on-prem ATA Center's release cadence. Benjamin Delpy and Vincent Le Toux disclosed DCShadow at BlueHat IL 2018 in January 2018 -- the technique of registering a rogue domain controller via nTDSDSA object creation plus SPN registration, then pushing arbitrary updates into AD via legitimate DRSUAPI replication that the event log records as ordinary inter-DC traffic [@dcshadow-com][@mitre-t1207]. ATA 1.9 shipped two months later, in March 2018, with no DCShadow detection. Azure ATP -- the cloud-side rewrite, also GA in March 2018 -- shipped paired alerts External ID 2028 (Suspected DCShadow attack -- domain controller promotion) and External ID 2029 (Suspected DCShadow attack -- domain controller replication request) five months later, in July 2018 [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-whats-new-archive]. The on-prem release cadence could not have closed that five-month gap. The cloud rewrite was the structural answer.

5. The Breakthrough -- Azure ATP and the Inverted Data Path

If the wire was the right data layer, the cloud was the right place to run the analytics. That is the architectural decision Azure ATP committed to in March 2018, and it is what distinguishes the Microsoft defensive product from every prior generation. The on-DC sensor stayed on the DC. The analytics engine moved.

Four architectural shifts followed. First, the on-DC sensor became a thin parser. Sensors no longer hosted detection logic; they captured the Kerberos / NTLM / LDAP / DRSUAPI traffic, parsed it into a stream of structured events, and shipped the stream upstream. Second, the data path inverted. Generation 4 sent unparsed packets from the wire to the off-DC Gateway, which parsed them and stored them on-prem; Azure ATP sent parsed events from the on-DC sensor upstream to a multi-tenant cloud backend that ran detection logic and wrote alerts back into a tenant-specific workspace. Third, per-principal behavioural baselines accumulated centrally rather than per-DC, so a baseline survived DC reboots, sensor restarts, and migrations across data centres. Fourth, identity signal joined endpoint and email signal in the same incident queue once Azure ATP folded into Microsoft 365 Defender -- the cross-product correlation that no on-prem product had ever offered [@mstc-azureatp-ga][@mstc-azureatp-intro][@mslearn-xdr-overview].

Then came the brand-and-architecture history every operator has to know to read a 2026 runbook. The September 22, 2020 rename from Azure Advanced Threat Protection to Microsoft Defender for Identity was a brand consolidation, not an architecture change -- the same sensor, the same alerts, the same workspace [@mssecblog-unified-xdr]. The legacy portal.atp.azure.com standalone portal was retired on June 30, 2023 via Message Center notice MC567494, with all requests automatically redirected to security.microsoft.com [@handsontek-mc567494][@mslearn-mdi-portal]. The November 15, 2023 Ignite keynote renamed Microsoft 365 Defender to Microsoft Defender XDR (Message Center MC696570) [@handsontek-defender-rebrand][@virtreview-ignite2023]. Again a brand change, again not an architecture change: the sensors stayed on the DC, the analytics stayed in the cloud, and the KQL schema -- IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents -- stayed the same [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory].The legacy portal.atp.azure.com URL is worth remembering because runbooks and SOAR rules from 2018 to 2023 frequently hard-coded it. Any rule that referenced the old portal needs an update; the redirect handles browser traffic but not API calls.

What the sensor actually feeds into the cloud backend, in 2026, is four data-input layers, ordered roughly by evidence strength. First, the Windows Security event log -- the audit subcategories that the MDI event-collection page lists as required, including Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Directory Service Access, and Audit Computer Account Management among others [@mslearn-mdi-event-collection]. These are public, documented, and easy to verify with auditpol /get /category:*. Second, on-DC network capture of Kerberos, NTLM, LDAP, and DRSUAPI -- well-documented because the sensor's network requirements are part of the public deployment guide. Third, Event Tracing for Windows providers that the sensor subscribes to in order to get signal the event log does not surface. Fourth, AD CS audit-log subscriptions added with the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023].

Microsoft has never published the canonical list of Event Tracing for Windows providers that the MDI sensor subscribes to. Any specific list of providers a reader encounters traces back to community reverse-engineering: Synacktiv's *A primer on Microsoft Defender for Identity* by Guillaume Andre and Mickael Benassouli (November 2022) is the canonical operator-research primary [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive]. The methodological precedent is Olaf Hartong's *Microsoft Defender for Endpoint Internals* series, specifically the 0x02 entry on audit settings and telemetry, which documents the binary-side enumeration approach: run Matt Graeber's Get-TraceLoggingMetadata script against the sensor executable to enumerate the providers it registers, then use Sealighter to trace those providers to a file for further analysis [@falconforce-mde-0x02][@gist-tracelogging-metadata][@github-sealighter]. Hartong's 0x02 article reports "roughly 111 public and MDE-exclusive providers used" by MsSense.exe -- the MDI sensor binary is amenable to the same technique, and the provider mix differs (MDI subscribes heavily to LDAP, Kerberos, DRSUAPI, and SAM-R-class providers; MDE subscribes heavily to process, file, network, and image-load providers) but the methodology is shared [@falconforce-mde-0x03][@github-olafhartong]. Read any community-published MDI provider list as a snapshot of what the community has reverse-engineered, not as Microsoft-published ground truth. The breakthrough was not better detection algorithms. The breakthrough was moving the analytics off the DC entirely, so the per-principal baselines could accumulate centrally and the detection set could ship on a cloud cadence instead of an on-prem one. That decision is why MDI shipped DCShadow detection within five months of disclosure -- a cadence the on-prem product could not have matched.

That is the move that turned a wire-side parse into a sustained detection program. The proof is the DCShadow timeline: five months from disclosure to detection, on a cadence the on-prem product could not have matched. Now we can ask the question every reader of the offensive-AD corpus actually wants answered. What does the watcher catch in 2026?

6. MDI in 2026 -- Sensors, Alerts, KQL, and the Graph in Transition

This is the article's bookmarking section. Four parts: what is on the DC, what alerts fire, what KQL the operator writes when the alerts miss, and where the graph layer that began as ATA 1.9's Lateral Movement Paths report actually lives in 2026.

6.1 Sensor topology in 2026

What is on a Windows Server 2022 (or 2025) domain controller running MDI in May 2026? Two sensor families, two target-server matrices, and a workspace cap.

The v2.x sensor is the legacy standalone agent: supported on Windows Server 2016 and earlier domain controllers, and on AD FS, AD CS issuing certificate authorities, and Microsoft Entra Connect servers that are not themselves domain controllers, per the v2.x prerequisites page [@mslearn-mdi-prereq-sensor-v2]. v2.x carries its own installer, its own update cadence, and its own packet capture stack (NPCap). It also requires a Directory Service Account (DSA) -- a gMSA configured during install whose forest-wide read rights let the sensor enumerate AD objects.

A group Managed Service Account configured during MDI v2.x sensor installation, granted forest-wide read permissions on Active Directory objects so the sensor can resolve principal identities, enumerate group memberships, and read schema attributes that the wire-side parse refers to by SID. The v3.x sensor replaces the DSA pattern with LocalSystem impersonation -- the sensor impersonates the local-system account of the domain controller it runs on, which has equivalent on-DC read rights without needing a separate gMSA per tenant [@mslearn-mdi-deploy-sensor-v3][@mslearn-mdi-action-accounts].

The v3.x sensor is the current path. It requires Windows Server 2019 or later with the March 2026 (or later) cumulative update installed, the Defender for Endpoint agent already deployed and onboarded, and -- critically -- there is no separate MDI installer at all. The MDI sensor capability ships as an extension of the MDE SENSE service. Self-imposed resource caps: CPU at most 30% of the host DC's CPU, memory at most 1.5 GB, with explicit Hyper-V Dynamic Memory and VMware reservation guidance that ensures the cap is honoured under contention [@mslearn-mdi-deploy-sensor-v3]. v3.x uses LocalSystem impersonation for AD reads rather than a gMSA-based DSA. The May 2026 release notes added direct v3.x support for AD FS, AD CS, and Microsoft Entra Connect identity roles when those roles run on a domain controller (which is the recommended deployment pattern for most mid-sized tenants) [@mslearn-mdi-whats-new].The 30% CPU cap is honoured by the MDE SENSE service's scheduling, but Hyper-V Dynamic Memory and VMware ballooning can break the assumption -- if the hypervisor reclaims memory under contention the sensor cannot get its 1.5 GB and the local capture buffer drops events. Microsoft's deployment guide recommends a static memory reservation on virtualised DCs for that reason.

The four target server roles are domain controllers (every DC, including RODCs), AD FS federation servers (not Web Application Proxies), AD CS online issuing certificate authorities (not offline root CAs), and Microsoft Entra Connect servers (both active and staging). The May 2026 release notes also raised the per-workspace capacity ceiling from 350 sensors to 1,000 sensors per workspace [@mslearn-mdi-whats-new].

flowchart TD DC1["Domain Controller
(WS2019+, v3.x sensor
inside MDE SENSE)"] DC2["Domain Controller
(WS2016, v2.x sensor)"] ADFS["AD FS server
(v2.x sensor, non-DC)"] ADCS["AD CS issuing CA
(v2.x or v3.x sensor)"] EC["Entra Connect server
(v2.x sensor)"] CLOUD["MDI cloud backend
(multi-tenant analytics,
per-principal baselines)"] XDR["Microsoft Defender XDR
(security.microsoft.com)
Identity tables + alerts"] DC1 --> CLOUD DC2 --> CLOUD ADFS --> CLOUD ADCS --> CLOUD EC --> CLOUD CLOUD --> XDR

The deployment matrix below is the operator-grade reference -- which role gets which sensor, which audit subcategories the sensor depends on, and what posture data the role unlocks.

Server role	Sensor version	Required audit subcategories	Posture coverage unlocked
Domain controller (WS 2019+)	v3.x (preferred)	Credential Validation; Kerberos AS; Kerberos TGS; Logon; DS Access; Computer Account Mgmt	Full Identity Security Posture (entity hygiene, dormant accounts, weak crypto)
Domain controller (WS 2016)	v2.x	Same as above	Same as above, minus v3.x-only enhancements
AD FS federation server	v2.x (or v3.x if also a DC)	AD FS audit logs (Application + Security)	Hybrid auth signal (Entra ID + on-prem)
AD CS issuing CA	v2.x (or v3.x if also a DC)	AD CS audit logs (certificate request and template events)	Nine ESC posture assessments (ESC1-Preview, ESC2, ESC3, ESC4, ESC6-Preview, ESC7, ESC8, ESC11, ESC15) [@mslearn-mdi-certificates-posture]
Entra Connect server	v2.x (or v3.x if also a DC)	Sync engine event log	Sync-engine attribute-flow signal

Note: For new DC deployments on Windows Server 2019 or later, use v3.x: no separate installer, no gMSA, no NPCap, and the sensor ships its updates with the MDE agent. For AD FS, AD CS, or Entra Connect roles that run on dedicated Windows Server 2016 hosts, v2.x is the supported path until those hosts are upgraded. Mixed environments are normal during the migration window; the cloud backend handles both versions without operator intervention [@modernsec-v3x][@jeffreyappel-v2v3]. One known limitation as of May 2026: Windows Server 2025 domain controllers that currently run a v2.x sensor cannot be migrated to v3.x; Microsoft's What's New page is explicit that "migration of domain controllers with Windows Server 2025 from sensor v2.x to sensor v3.x is not supported" and the operator should continue on v2.x on those hosts until migration support ships [@mslearn-mdi-whats-new].

Sensor topology determines coverage. Coverage determines which alerts can fire.

6.2 The alert taxonomy mapped to MITRE ATT&CK

Every offensive Active Directory primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus knows has a row in MDI's alert catalogue. The catalogue is the article's bookmarkable artifact, and the table below is the load-bearing data-density object. Four MITRE-aligned categories, the named alert for each primitive, and the ATT&CK technique ID the alert maps to.

Category	MDI alert (External ID / detector)	MITRE ATT&CK technique
Reconnaissance	Account enumeration reconnaissance (LDAP) -- External ID 2437	T1087 Account Discovery
Reconnaissance	Network-mapping reconnaissance (DNS)	T1018 Remote System Discovery
Reconnaissance	Security principal reconnaissance (LDAP)	T1069 Permission Groups Discovery
Reconnaissance	User and IP address reconnaissance (SMB)	T1018
Persistence and privilege escalation	Honeytoken activity (authentication / attribute / group)	T1098 Account Manipulation
Persistence and privilege escalation	Suspected Skeleton Key attack	T1556 (Modify Authentication Process)
Persistence and privilege escalation	Suspected Golden Ticket usage (encryption downgrade)	T1558.001 Golden Ticket [@mitre-t1558-001]
Persistence and privilege escalation	Suspected Golden Ticket usage (forged authorization data)	T1558.001
Persistence and privilege escalation	Suspected DCShadow attack (DC promotion) -- External ID 2028	T1207 Rogue Domain Controller [@mitre-t1207]
Persistence and privilege escalation	Suspected DCShadow attack (DC replication request) -- External ID 2029	T1207
Persistence and privilege escalation	Suspicious additions to sensitive groups	T1098 Account Manipulation
Credential access	Suspected DCSync attack (replication of directory services) -- External ID 2006	T1003.006 DCSync [@mitre-t1003-006]
Credential access	Suspected Brute Force attack (Kerberos, NTLM)	T1110 Brute Force
Credential access	Suspected AS-REP Roasting attack	T1558.004 AS-REP Roasting [@mitre-t1558-004]
Credential access	Suspected Kerberos SPN exposure / Kerberoasting	T1558.003 Kerberoasting [@mitre-t1558-003]
Credential access	Suspected over-pass-the-hash attack	T1550.002 Pass the Hash
Lateral movement	Suspected identity theft (pass-the-hash)	T1550.002
Lateral movement	Suspected identity theft (pass-the-ticket)	T1550.003 Pass the Ticket
Lateral movement	Remote code execution attempt	T1021 Remote Services
Lateral movement	Suspected NTLM relay attack (the ESC8 class)	T1187 Forced Authentication
Lateral movement	Suspected NTLM authentication tampering	T1557.001 LLMNR / NBT-NS / Man-in-the-Middle

Both alert documentation surfaces -- the classic-format alert reference and the XDR-format alert reference -- are the canonical primaries for this catalogue [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-alerts-xdr]. Reading either page in sequence is the single most useful afternoon a SOC operator new to MDI can spend.The numeric External IDs (2006 for DCSync, 2028 and 2029 for DCShadow, 2437 for LDAP account enumeration, and so on) are a Microsoft-internal stability anchor that survives alert-name renames over time. Microsoft has renamed alerts -- "Suspected DCSync attack" was named differently in early Azure ATP -- but the External IDs do not change. Production SOAR rules should match on the External ID, not the alert name string.

An offensive primitive in which a principal that has been granted the *Replicating Directory Changes* and *Replicating Directory Changes All* extended rights uses the DRSUAPI replication interface (specifically `IDL_DRSGetNCChanges`) to request a full or partial replication of directory contents from a domain controller -- typically targeting the `unicodePwd` attribute on sensitive accounts like `krbtgt` and `Administrator`. The technique requires no code execution on the DC, no `Ntds.dit` copy, and no presence on a domain-joined machine other than network connectivity to a DC. Mimikatz's `lsadump::dcsync` command, written by Benjamin Delpy and Vincent Le Toux, is the canonical implementation; MITRE catalogues the technique as T1003.006 [@mitre-t1003-006][@adsec-dcsync]. A specific adversary behaviour catalogued in the MITRE ATT&CK framework, identified by a stable ID (for example T1003.006 for DCSync, T1558.001 for Golden Ticket, T1207 for Rogue Domain Controller). MITRE updates the framework periodically; the IDs themselves do not change, which is why detection-engineering tooling -- including MDI's per-alert MITRE mapping -- anchors to the IDs rather than the human-readable names.

Concrete mechanism, for one named alert. Suspected DCSync attack -- replication of directory services, External ID 2006, fires on the structural pattern that an IDL_DRSGetNCChanges request reached a domain controller from a source that is not itself a domain controller. The mechanism is the one place where MDI's wire-side capture pays for itself most visibly -- the 4662 event the LSA emits records the directory-service-object access but does not identify the source as not-a-DC; only the wire view sees the calling host's IP and resolves it against the directory's serverReference set.

sequenceDiagram autonumber participant Attacker as Attacker workstation (Mimikatz) participant DC as Domain Controller participant MDI as MDI v3.x sensor (on DC) participant Cloud as MDI cloud backend participant XDR as Defender XDR portal Attacker->>DC: IDL_DRSGetNCChanges (DRSUAPI replication request) DC->>DC: LSA writes event 4662 (DS object access) DC-->>Attacker: Replication response (unicodePwd, supplementalCredentials) MDI->>MDI: Wire parse: caller IP not in serverReference set MDI->>Cloud: Stream parsed event (caller, target object, attributes) Cloud->>Cloud: Correlate against known-DC IPs, fire detector Cloud->>XDR: Write alert External ID 2006 (T1003.006) XDR->>XDR: Surface in unified incident queue

The alert taxonomy makes the bookmarkable promise the rest of the article rests on. The trigger logic that fires each row, however, depends on signal the sensor can only acquire on the wire or in the event log -- and when the trigger logic misses, the operator's last-mile coverage is KQL.

6.3 The advanced-hunting schema and a worked KQL example

When the alert template misses, the hunter writes Kusto Query Language. Defender XDR exposes three identity-specific tables that the MDI sensor populates -- IdentityLogonEvents for authentication activity captured against on-prem AD, IdentityQueryEvents for queries performed against AD objects, and IdentityDirectoryEvents for events involving an on-prem domain controller including password changes, expirations, UPN changes, scheduled tasks, and PowerShell activity [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory]. Cross-product context is available from the unified AlertInfo, AlertEvidence, and DeviceLogonEvents tables.

The worked example below is the structural DCSync detector that catches the encrypted-channel case the alert can miss. The runner in this environment cannot execute KQL directly, so the block is annotated rather than runnable -- a non-runnable KQL detector is stronger pedagogy here than a hand-rolled Python simulation, because the query as written is exactly what an operator would paste into the Defender XDR advanced-hunting console against the actual IdentityDirectoryEvents table.

// Structural DCSync detector -- DRSUAPI from non-DC IPs
// Run against the Defender XDR advanced-hunting IdentityDirectoryEvents table.
IdentityDirectoryEvents
| where Timestamp > ago(24h)                                  // tune window per triage cadence
| where ActionType == "DRSReplicate"                          // the DRSUAPI replication call
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")  // tenant DC IPs go here
| where AccountName !startswith "MSOL_"                       // Entra Connect Cloud Sync FP class
| where AccountName !in ("ADConnectSync")                     // Entra Connect on-prem FP class
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

The output rows that survive the filters are the operator's investigation queue: DRSUAPI replication requests against a DC from a source that is not itself a DC, and not a recognised hybrid-identity sync principal. The two cleanup principals -- MSOL_* (the Microsoft Entra Connect Cloud Sync service account, with a stable MSOL_ prefix and an 8-character random suffix) and ADConnectSync (the on-prem Entra Connect service account) -- are the two most common false positives every MDI tenant sees. Adding them to the !startswith and !in clauses cuts the FP rate by an order of magnitude in most environments. The third FP class that operators tune for is legitimate vulnerability scanners triggering the LDAP / SMB reconnaissance alerts -- the scanner's authenticated enumeration looks behaviourally identical to a SharpHound collector unless the scanner's source IP is in an allowlist.

flowchart LR A["IdentityDirectoryEvents
(DRSReplicate)"] --> B["Filter: source IP
not in known_dc_ips"] B --> C["Filter: account
not in sync allowlist"] C --> D["Suspect rows
(operator triage)"]

Beyond the three identity tables there is one more surface worth naming. The April 2026 Identity Explorer Preview in the Defender XDR Identity page builds on the Microsoft Sentinel data lake -- Microsoft's 2026 cross-product cold-storage and analytics layer with up to 12 years of retention in Parquet format [@mslearn-sentinel-datalake][@mslearn-mdi-whats-new]. Identity Explorer uses the Defender XDR hunting graph to visualise identity attack paths as interactive graphs with predefined scenarios for lateral movement, privilege escalation, and credential-access risk [@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users].

The query language is the operator's last-mile coverage layer. Everything in section 6 so far is what MDI gives you. KQL is what you do when MDI does not.

6.4 The graph layer in transition

The graph that began as ATA 1.9's Lateral Movement Paths report no longer exists in the form most operators remember. The history is a clean three-step arc and a transition still in progress.

ATA 1.9 (March 2018) shipped the Lateral movement paths to sensitive accounts report, built on SAM-R-based local-administrator discovery: the sensor remotely enumerated each member host's local-administrators group and computed the chain of "who can become whom" through cached credentials [@mslearn-ata-1-9][@atadocs-lmp-usecase]. That report carried through Azure ATP, through the Microsoft Defender for Identity rename, and through the Microsoft Defender XDR rebrand essentially unchanged for seven years.

In May 2025, Microsoft disabled the SAM-R-based discovery via Message Center notice MC1073068, citing alignment with the broader Windows NTLM-deprecation roadmap [@handsontek-mc1073068]. The message body is explicit: "Disabling this feature will impact the ability to map potential lateral movement paths (using SAM-R queries) because the data used to calculate potential lateral movement paths will no longer be collected by the Defender for Identity sensor." SAM-R as a remote-discovery primitive had become a security debt as much as a feature; the deprecation brought MDI's collection behaviour into line with Restricted SAM and Microsoft's NTLM-deprecation posture, but it left the LMP surface without its primary data source.

The replacement is in two pieces. The first is the unified attack-path exploration surface in Microsoft Defender XDR, driven primarily by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) attack-path engine [@mslearn-defenderforcloud-attack-path], with MDI feeding identity signal into the same correlation. The second is the Identity Explorer Preview that launched in April 2026 on the Microsoft Sentinel data lake, specifically for identity attack paths -- visible from the Identity page in Defender XDR for tenants with a Sentinel data lake licence [@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users]. The honest framing in 2026 is that the post-SAM-R LMP coverage is not yet fully closed by either replacement -- the Defender XDR hunting graph is rich, the Identity Explorer is improving, but the seven-year-old SAM-R-derived LMP report had operator workflows around it that the new surfaces have not all reproduced.

MDI's graph layer is in transition. The cloud rewrite handed Microsoft the platform to ship a better graph than ATA ever could; in 2026 the build-out is still in progress. Section 9 will name this as one of the article's open problems. First, though, we have to look at the competitive market the watcher sits inside.

7. Competing Approaches -- the 2026 Identity-Detection Market

If MDI is the watcher on the DC, what is everybody else? Five named methods share the 2026 identity-threat detection market with MDI, each optimising for a different trade-off. The table below is the six-column shorthand; the prose that follows is the per-method analysis.

Vendor / project	On-DC sensor model	Data-input mix	Alert taxonomy	Graph model	Pricing model
MDI	On-DC sensor (v2.x standalone or v3.x MDE-integrated)	Wire + event log + ETW + AD CS audit	MITRE-aligned alert catalogue + nine ESC posture	Hunting graph + Identity Explorer Preview	Bundled with M365 E5 / E5 Security / F5 Security
CrowdStrike Falcon Identity Protection	Connector on/near DC + endpoint agent	Wire (via connector) + endpoint telemetry	ITDR-style alerts, less granular ATT&CK mapping	Identity attack-path view (inline enforcement)	Falcon ITDR module add-on
Semperis DSP + ADFR	Off-DC change-tracking agent	AD object-change events (LDAP / replication)	IoC and IoE runtime alerts plus drift / tamper alerts	Tier 0 exposure graph + rollback graph	Standalone licence per AD object
SpecterOps BloodHound Enterprise	Off-DC collector (SharpHound CE)	AD permissions graph + Azure / Okta / Mac extensions	Attack-path exposure findings	Pure graph (Cypher over Postgres / Neo4j)	Standalone SaaS licence
Microsoft Sentinel native UEBA	None on DC (consumes MDI + other sources)	Sentinel data lake (cross-product)	UEBA risk scores, anomaly events	None on identity graph directly	Sentinel ingestion + UEBA add-on
Sigma + SIEM (open source)	None on DC (event forwarder agents)	Windows event logs, ETW via OSQuery / Velociraptor	Custom rule library	None	Free (rule library); SIEM cost separate

CrowdStrike Falcon Identity Protection is the post-acquisition rename of Preempt Platform, the product line CrowdStrike bought when it completed the Preempt Security acquisition on September 30, 2020 [@businesswire-cs-preempt]. Architecturally distinct from MDI: rather than relying on an on-DC sensor that parses wire traffic and event logs, Falcon Identity Protection inspects authentication traffic via a connector deployed on or near each DC and correlates it with Falcon-agent telemetry already collected from every protected endpoint. Identity-policy enforcement is inline -- the product can require an MFA challenge or block an authentication at the point of decision rather than emit a post-hoc alert [@crowdstrike-falcon-id]. This is the only commercial product in the survey that does inline enforcement on AD Kerberos and NTLM authentications; it is also the only one that is not bundled with a Microsoft 365 licence.

The product category that combines runtime detection of identity-targeted attacks (Kerberos forgery, credential theft, lateral movement) with response capabilities (force MFA, disable user, revoke session). Gartner formalised the term in 2022. CrowdStrike Falcon Identity Protection and SentinelOne Singularity Identity are the largest ITDR-positioned products outside the Microsoft stack; MDI plus the Defender XDR remediation actions surface effectively functions as Microsoft's ITDR offering for tenants already inside the Microsoft 365 estate [@mslearn-mdi-remediation-actions].

Semperis Directory Services Protector (DSP) and the companion Active Directory Forest Recovery (ADFR) product are best known for change-tracking and recovery, layered over a runtime Indicators-of-Compromise and Indicators-of-Exposure detection set that overlaps with MDI's alert taxonomy on classes like DCSync, DCShadow, and Golden Ticket replay [@semperis-dsp][@semperis-adfr]. DSP tracks AD object changes in near-real-time, fires IoC and IoE alerts on the same primitives MDI watches, and offers post-attack rollback as its primary differentiator; ADFR handles malware-free forest recovery in minutes-to-hours rather than days-to-weeks. The pair is partly complementary, partly overlapping with MDI: DSP catches the post-attack drift (the unauthorised group membership change, the rogue ACL) and offers a rollback path MDI does not have; MDI's per-principal behavioural baselines and unified Defender XDR incident queue are the differentiator on the in-flight detection axis; ADFR handles "the worst day of your career" forest-recovery scenarios where rebuilding the directory is the only remediation. Many tenants run all three.

SpecterOps BloodHound Enterprise (BHE) is the commercial form of the BloodHound 2016 graph model that Andy Robbins, Rohan Vazarkar, and Will Schroeder published at DEF CON 24 [@defcon-six-degrees][@bloodhound-github-specterops][@neo4j-bh]. Pure graph attack-path exposure model: BHE maps the paths that exist (Tier Zero hygiene, principal-to-principal cross-domain trust paths, Entra to on-prem pivots) rather than alerts on attacks in flight [@specterops-bhe]. Complementary to MDI: BHE tells you the attack path exists in the directory, MDI tells you someone is walking it right now. The SpecterOps team's Certified Pre-Owned whitepaper (June 2021) by Will Schroeder and Lee Christensen is the source of the ESC1-ESC8 vocabulary that downstream MDI ADCS posture assessments map to [@specterops-cpo-pdf][@specterops-cpo-blog].

Microsoft Sentinel native UEBA is the SIEM-side behavioural-baselines product over the broader event corpus that Sentinel ingests. Sentinel UEBA uses machine learning to build dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities, with named data-source connectors including Defender for Identity [@mslearn-sentinel-ueba]. Sentinel UEBA is the "outside the identity tables" layer -- detection that needs to correlate identity signal with email, endpoint, network, and SaaS signal lives there rather than in the identity tables themselves. The Defender XDR-to-Sentinel connector unifies the surfaces [@mslearn-sentinel-defender-connector].

Open-source detection stacks -- Sigma rules deployed against Sentinel, Splunk, or Elastic, plus Velociraptor and Wazuh -- can match many of MDI's pattern-based alerts but cannot match MDI's per-principal behavioural baselines without significant in-house investment [@sigmahq-github]. The SigmaHQ rule corpus contains over 3,000 detection rules in a vendor-neutral SIEM format. Olaf Hartong's FalconForce team publishes the FalconFriday hunting-query repository (MDE-schema KQL queries for DLL injection, COM hijacking, LOLBins, LDAP anomalies, and SMB NULL sessions) -- the operator-side companion to community-built detection libraries [@github-falconfriday][@falconforce-blog].

MDI is the high-coverage, low-effort identity-threat detection product if you already have Microsoft 365 E5 or E5 Security. The third-party products in this market win on differentiation -- inline enforcement, change-tracking, exposure-graph mastery -- rather than baseline coverage. The interesting question for an architect in 2026 is not which to buy. The interesting question is what MDI, by design, cannot see at all.

8. Theoretical Limits -- the Five Structural Ceilings

There are attacks no version of MDI will ever detect. Not because Microsoft has not shipped the alert yet, and not because the engineering team has not gotten around to it. Because the alert is structurally impossible.

Five named ceilings, each anchored to a primary source. Together they are the residual blind-spot inventory every operator should be able to name from memory.

flowchart TD subgraph causes ["Attacker-side cause"] C1["OS does not expose
the credential operation"] C2["Forged ticket is
cryptographically identical"] C3["Wire traffic is wrapped
in an encrypted channel"] C4["Attack pivots through
a forest without a sensor"] C5["Attacker uses real DA
real credentials"] end subgraph gaps ["Defender-side gap"] G1["Credential Guard wall"] G2["Sapphire Ticket class"] G3["Encrypted-channel DCSync"] G4["Cross-forest tail"] G5["Legitimate principal
non-detection"] end C1 --> G1 C2 --> G2 C3 --> G3 C4 --> G4 C5 --> G5

Ceiling 1 -- the Credential Guard wall. Anything the operating system itself cannot see is invisible to MDI. The DCSync class is the canonical example with a twist: Credential Guard isolates the LSASS process so that credentials in memory cannot be scraped from a compromised endpoint, but it does not prevent DRSUAPI-level secret extraction against the DC because the DRSUAPI replication interface is supposed to return password hashes to legitimate replication partners. MDI catches DCSync by detecting the wire-side pattern (DRSUAPI from a non-DC source), not by Credential Guard's protection. Anything the OS does not expose in event log, wire traffic, or instrumented API -- a custom kernel driver that reads secrets through a side channel, a hypervisor-level credential extraction on a non-Secured-core host -- is, by construction, outside MDI's data layer.

Ceiling 2 -- forged-ticket cryptographic indistinguishability, the Sapphire Ticket. This is the most important ceiling, and the one whose permanence the rest of this section orbits.

A forged Kerberos Ticket Granting Ticket whose Privileged Attribute Certificate (PAC) is a verbatim copy of a legitimate principal's PAC, obtained via the S4U2self plus User-to-User PAC-copy flow against the target principal and then encrypted with the stolen `krbtgt` key. The technique was disclosed by Charlie Bromberg (Synacktiv / Shutdown) in October 2022 and documented on The Hacker Recipes wiki [@hackerrecipes-sapphire]. The defining property: every byte of the forged ticket's PAC matches the byte pattern of a ticket the genuine KDC would have issued for the legitimate principal, including the group SID set, the user ID, the logon time, and the authorisation-data fields. The classic Golden Ticket leaves PAC anomalies that MDI's *Suspected Golden Ticket usage (forged authorization data)* alert fires on; the Sapphire Ticket leaves no PAC anomaly because there is no anomaly to leave. The Sapphire Ticket attack obtains a target principal's PAC via the S4U2self plus User-to-User PAC-copy technique -- a Kerberos protocol flow Microsoft published as part of MS-SFU and MS-KILE -- which extracts a genuine PAC into a usable form without ever needing to authenticate as the target. The attacker then forges a new ticket whose PAC is the captured PAC, encrypted with the stolen `krbtgt` key. The mechanical sequence is: S4U2self against the target produces a ticket containing the target's PAC; the U2U flow lets the attacker decrypt the embedded PAC blob; the attacker then mints a fresh TGT around that PAC with the genuine signing key. The KDC's signature checks pass because the signing key is real, and the PAC's structural fields pass because they were lifted from a ticket the genuine KDC just issued. Only the original credential compromise that produced the `krbtgt` hash leaves a trail.

Key idea: Cryptographic indistinguishability is a permanent class. No future MDI release fixes the Sapphire Ticket without breaking Kerberos itself.

Rotate `krbtgt` twice on a defined cadence -- 90 days is common; some Tier Zero playbooks rotate every 30 days. The "twice" is non-optional: a single rotation leaves the prior `krbtgt` key valid for the duration of any tickets the KDC has previously issued, so the stolen key is still usable for up to 10 hours (or longer, on `MaxRenewAge` extensions). Combine with Authentication Policy Silos for Tier Zero service accounts, Tier Zero access reviews, and Privileged Access Workstations for any administrator who can read `krbtgt`. None of these closes the Sapphire Ticket; together they shrink the window in which a stolen key remains weaponisable. Sample PowerShell for the double rotation is in the Microsoft-published `Reset-KrbTgt` script in the GitHub samples repository [@msdefender-id-github].

Ceiling 3 -- the encrypted-channel DCSync class. When DRSUAPI is wrapped in a transport the on-DC capture cannot decode -- DCSync over LDAPS via a SPN-bound impersonation chain, for instance -- the wire-side pattern recognition that powers the External ID 2006 alert degrades. The structural detector in Section 6.3 catches the unencrypted case; the encrypted case requires either a different observation surface (the DRSUAPI handler's own instrumentation) or behavioural baselining on the post-fact replication-log signal. MDI's coverage in this case is partial, not complete.

Ceiling 4 -- the cross-forest under-instrumentation tail. MDI sees the forests its sensors are deployed in. Pivot through an external trust to a forest without MDI coverage and the signal is incomplete -- the attacker's pre-pivot reconnaissance, the actual trust traversal, and any post-pivot actions on the trusting side that do not also touch an MDI-monitored forest will be invisible. This is a deployment property, not a product property: a tenant with MDI on every forest in its environment does not have this ceiling. A tenant whose acquisition portfolio includes three forests it does not yet monitor does.

Ceiling 5 -- legitimate-principal compromise non-detection. When the attacker uses a real Domain Admin's real credentials, every action is behaviourally indistinguishable from the legitimate principal unless timing, geolocation, or device fingerprint breaks the baseline. The 2025 and 2026 Suspected session cookie theft and related XDR-format alerts close part of this gap by adding behavioural side channels that the older Azure ATP alert catalogue did not cover [@mslearn-mdi-alerts-xdr]. The residual is permanent: a sufficiently disciplined attacker operating from the legitimate principal's normal workstation, during the legitimate principal's normal hours, doing things the legitimate principal might plausibly do, is, by construction, indistinguishable from the legitimate principal.

A sixth honourable mention sits adjacent to these five: out-of-band physical access -- a stolen Ntds.dit backup, an attacker-controlled DC's offline export, supply-chain firmware compromise on the DC hardware -- is outside the data layer MDI operates over. The hardware-trust-root community owns this class of mitigation, not the identity-threat detection community.

Note: The five structural ceilings are knowable, not surprises. A SOC that names them ahead of time has a better incident-response runbook than one that does not -- specifically, the runbook for "we just realised the attacker used a Sapphire Ticket" is fundamentally different from the runbook for "MDI fired and we ignored it." The first runbook starts with krbtgt rotation and Tier Zero hygiene review; the second starts with disciplinary review and SOAR-rule tuning. Knowing which runbook to pick depends on naming the ceiling correctly.

These five named residuals are why the rest of the article exists. If MDI caught everything, the operator playbook in Section 10 would be unnecessary. Because MDI does not, and because the gaps are knowable, the playbook in Section 10 is the difference between MDI as a licence line item and MDI as a working part of the SOC's day. But before the playbook, one last open-problem inventory: where is the research roadmap actually working?

9. Open Problems -- What the Research Roadmap Is Working On

Five open problems sit between the 2026 floor and a hypothetically perfect identity-threat detector. Each one has a current best partial result and a citation. None of them is closed.

Open Problem 1 -- the post-PKINIT NTLM-relay class beyond ESC8. Synacktiv's Understanding and evading Microsoft Defender for Identity PKINIT detection paper (Guillaume Andre, 2024) reverse-engineered MDI's PKINIT-class detection: MDI fingerprints offensive-tool-generated AS-REQ messages by the encryption types they advertise, which differ from the encryption-type list a legitimate Windows API PKINIT request generates [@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. The companion Invoke-RunAsWithCert PowerShell tool generates AS-REQ messages via the Windows API itself, producing requests structurally identical to legitimate enterprise PKINIT authentication and bypassing the fingerprint-based detection [@synacktiv-runascert-gh][@deepwiki-runascert]. Aura Security's follow-on writeup confirms the technique against the current MDI version and walks through modifying Certipy to produce matching AS-REQ shapes [@aurainfosec-mdi-pkinit]. The partial mitigation in 2026 is the additional posture-side coverage in the nine MDI Certificates assessments, which closes some of the configurations the offensive tools target [@mslearn-mdi-certificates-posture]. The runtime detection arms race continues.

Open Problem 2 -- the graph-layer transition from SAM-R LMP to Identity Explorer. Section 6.4 covered the deprecation of SAM-R-based LMP discovery in May 2025 (MC1073068) and the two replacement surfaces: the Defender XDR attack-path exploration driven by Defender for Cloud's CSPM engine, and the April 2026 Identity Explorer Preview on the Sentinel data lake [@handsontek-mc1073068][@mslearn-defenderforcloud-attack-path][@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph]. The honest open question is whether either surface reproduces, in 2026, the operator workflows the seven-year-old SAM-R-derived LMP report had built up around itself. The Defender XDR hunting graph is richer than the LMP report ever was, but its data model is different; the Identity Explorer is closer in spirit but in Preview rather than GA.

Open Problem 3 -- the Sentinel data lake correlation and the Identity Explorer GA path. Microsoft Sentinel data lake, the cross-product cold-storage and analytics layer, went public preview in 2025 and ships with up to 12 years of retention in Parquet format, a clean separation of storage and compute, and KQL plus Jupyter notebook query surfaces [@mslearn-sentinel-datalake][@mstc-sentinel-datalake-preview]. Identity Explorer is the first identity-specific surface built on top of the data lake; it is in Preview as of April 2026 with no GA date published. The open problem is whether the data-lake-tier correlation can match the alert-tier MDI quality for long-running attacker dwell -- the months between Sapphire Ticket use and discovery class -- without producing more noise than signal.

Open Problem 4 -- the MDI evasion research arms race. Synacktiv's two papers (the sensor primer by Andre and Benassouli in 2022; the PKINIT evasion paper by Andre in 2024) plus the operator notes on alert-timing exploitation that show up in adsecurity.org and SpecterOps content are the public record of the offensive-research community's targeting of MDI specifically [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. FalconForce's reverse-engineering of the MDE sensor (via Olaf Hartong's MDE Internals series) is the methodological precedent for the same approach against MDI; the FalconForce blog and the FalconFriday hunting-query repository are the operator-facing primaries [@falconforce-mde-0x02][@falconforce-mde-0x03][@falconforce-blog][@github-falconfriday][@github-olafhartong]. The Charlie Bromberg Sapphire Ticket disclosure (October 2022) is the cryptographic-attack-class research that Section 8's third ceiling rests on [@hackerrecipes-sapphire]. The arms-race property is permanent; the defensive product team's job is to keep the detection-shipping cadence faster than the evasion-shipping cadence, which the cloud rewrite (see Section 5) made structurally possible.

Open Problem 5 -- the non-Windows directory coverage tail. MDI covers Active Directory and (via the Microsoft Entra Connect sensor) the on-prem-to-Entra-ID sync surface. Native Entra ID attacks (token theft against Entra ID itself, OAuth consent phishing, Conditional Access bypass) are covered by Defender for Cloud Apps and Entra ID Protection, not by MDI. The boundary between MDI's scope and the adjacent products is operationally meaningful: a SOC operator reading "MDI did not fire" on an Entra-ID-only attack should not conclude the attack went undetected -- another product likely did fire, in another part of the same Defender XDR portal. The unified incident queue stitches the alerts together; the operator's mental model has to know which sensor surface to look at when triaging.

The article does not claim "BloodHound CE forced MDI to add ADCS detections in 2024." The framing is parallel evolution: as BloodHound CE expanded ADCS attack-path coverage in 2024-2025, MDI extended its ADCS posture assessments and PKINIT-class runtime detections during the same window. The two product communities watch each other; neither one "forces" the other.

The roadmap is real, the build-out is in progress, and the operator decision in 2026 is not "wait for the perfect product." It is "deploy what works now, and cover the residuals with KQL."

10. The MDI Deployment and Triage Playbook

Four lanes, mapped to four operator personas: the architect who designs the sensor footprint, the SOC analyst who triages the alerts, the threat hunter who writes the KQL that fills the gaps, and everyone who needs to know what does not work.

Lane 1 -- sensor placement and prerequisite hygiene

Deploy the v3.x sensor on every domain controller running Windows Server 2019 or later, paired with the MDE agent. The deployment path is the Microsoft Defender portal's migration wizard or the standalone install via the MDE agent's onboarding flow [@mslearn-mdi-deploy-sensor-v3][@modernsec-v3x][@jeffreyappel-v2v3].

Deploy the v2.x sensor on every AD FS federation server, every AD CS online issuing certificate authority, and every Microsoft Entra Connect server (both active and staging), unless those roles already run on a domain controller covered by a v3.x sensor with the May 2026 identity-role extension enabled [@mslearn-mdi-prereq-sensor-v2][@mslearn-mdi-whats-new].

Configure the required Windows audit subcategories via the Group Policy Subcategory Settings path that the MDI event-collection page enumerates -- Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Directory Service Access, Audit Computer Account Management, plus the additional subcategories for AD CS and AD FS roles. The v3.x sensor includes an Automatic Windows auditing configuration toggle that uses the Windows LSA audit-policy APIs to set the subcategories directly, eliminating the GPO step [@mslearn-mdi-event-collection].

Set the MDI Action Account in the Defender portal. The default is LocalSystem impersonation on the sensor host, which works for response actions targeting AD objects (force password reset, disable user). A gMSA-based Action Account is the alternative for tenants that want least-privilege response identities scoped per workspace [@mslearn-mdi-action-accounts][@mslearn-mdi-remediation-actions]. Avoid configuring the same gMSA across multiple sensor hosts -- the documented anti-pattern is to use one Action Account for DC-side actions only.

Verify the Microsoft Defender portal role assignments so that SOC analysts have the correct read-and-respond permissions on identity alerts. The Microsoft Defender for Identity enterprise application (ID 60ca1954-583c-4d1f-86de-39d835f3e452) is the consent surface for the response actions; tenants that have not granted consent will see "remediation action unavailable" on identity-targeted incidents [@mslearn-mdi-remediation-actions].

Lane 2 -- alert triage SLAs

The triage matrix maps alert category to response-time target and the named SOC role that owns triage. Numbers below are typical Tier 1 / Tier 2 SOC targets; tune to your environment's incident-response policy.

Alert category	Response-time target	Owning SOC role	Notes
DCSync, DCShadow, Golden Ticket	1 hour	Tier 2 (privileged-account-compromise specialist)	Treat as confirmed compromise pending evidence to the contrary
AS-REP Roasting, Kerberoasting	4 hours	Tier 2	Higher-FP class; verify offending principal pattern before escalation
NTLM relay (ESC8 class)	4 hours	Tier 2	ADCS-aware; coordinates with CA team
Reconnaissance (LDAP / SMB / DNS)	24 hours	Tier 1	Highest-FP class; allowlist legitimate scanners
Honeytoken activity	1 hour	Tier 1 plus Tier 2 escalation	Near-zero FP; any hit is investigation-worthy

Two false-positive cleanup patterns appear in nearly every tenant. The Azure AD Connect Cloud Sync service principal -- MSOL_ plus an 8-character random suffix -- legitimately performs DRSUAPI-like operations as part of the hybrid identity sync flow, and will fire DCSync-class alerts unless allowlisted. Legitimate vulnerability scanners (Tenable, Rapid7, Qualys) perform authenticated enumeration that triggers the LDAP and SMB reconnaissance alerts; scanner IPs go in an exclusion list per the Defender XDR portal's identity-alert tuning surface.

The MDI Action Accounts and Remediation Actions surface lets the responder disable a user, force a password reset, revoke an Entra ID session, or mark an account as compromised -- triggered manually from the alert flow or automatically via the Defender XDR automatic attack disruption engine, which requires 99 percent or higher detector precision before taking containment action [@mslearn-xdr-attack-disruption][@mslearn-mdi-remediation-actions][@mslearn-xdr-investigate-users]. Automatic attack disruption is opt-in per containment action; the conservative default leaves analyst confirmation in the loop for password-reset-class actions and automates disable-user only on the highest-precision detector classes.

Note: The cloud-side analytics pipeline aggregates signal across the per-principal baseline window before deciding to emit. Empirically the alert latency is minutes-cadence, not seconds-cadence. Incident response runbooks that assume sub-second alert arrival will be wrong; the operator clock starts when the alert hits the Defender XDR queue, which is itself minutes after the wire-side event. Plan for this in the SLA matrix above -- the "1 hour" target for DCSync starts from the alert timestamp, not the attack timestamp, and the attack itself may have happened five or ten minutes earlier. The Microsoft alerts-overview page is explicit that MDI is "not designed to serve as an auditing or logging solution that captures every single operation or activity on the servers where the sensor is installed; it only captures the data required for its detection and recommendation mechanisms" [@mslearn-mdi-alerts-overview].

Lane 3 -- advanced-hunting queries that fill the gaps

Three structural detectors in KQL form, each one targeting a class the named alerts can miss. Each query names the table, the columns, and the threshold tuning the operator will need.

The structural DCSync detector runs against IdentityDirectoryEvents and catches the encrypted-channel case the External ID 2006 alert may miss:

IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType == "DRSReplicate"
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")   // tenant DC IPs
| where AccountName !startswith "MSOL_" and AccountName !in ("ADConnectSync")
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: keep the time window short (24 hours) for daily triage. Cleanup principals (MSOL_*, ADConnectSync, plus any per-tenant sync identities) go in the !startswith and !in clauses. The query produces a clean queue of "DRSUAPI replication from a host that should not be doing DRSUAPI." False-positive class: legitimate Azure AD Connect Cloud Sync service principals; resolve by adding the principal to the allowlist.

The slow-burn Kerberoasting detector runs against IdentityLogonEvents and catches the rate-limited Kerberoast pattern that modern attackers use to stay below the MDI behavioural-baseline threshold:

IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| where ActionType == "ServiceTicketRequest"
| extend EncType = tostring(parse_json(AdditionalFields).EncryptionType)
| where EncType in ("RC4-HMAC", "DES-CBC-MD5")
| summarize SpnCount = dcount(TargetSpn), SpnList = make_set(TargetSpn) by AccountName, bin(Timestamp, 1d)
| where SpnCount > 5     // tune per tenant baseline
| order by Timestamp desc, SpnCount desc

Threshold tuning: the SpnCount > 5 threshold is the load-bearing knob. Tenants with legitimate operational accounts that request many SPNs per day (privileged service accounts running scheduled tasks across many target hosts) will need a higher threshold and an allowlist. The seven-day window catches the slow-burn pattern that a one-hour window misses.

The PKINIT-relay structural detector runs against IdentityLogonEvents and watches for AS-REQ with PA-PK-AS-REQ pre-auth coming from unexpected client subnets:

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where ActionType == "InitialAuthentication"
| extend PreAuth = tostring(parse_json(AdditionalFields).PreAuthType)
| where PreAuth == "PA-PK-AS-REQ"
| extend ClientSubnet = strcat(split(IPAddress, ".")[0], ".", split(IPAddress, ".")[1])
| where ClientSubnet !in ("10.0.5", "10.0.6")    // legitimate smartcard subnets
| project Timestamp, AccountName, IPAddress, DeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: PKINIT is legitimate when smartcard logon is in use. Identify the legitimate smartcard-issuing subnets and add them to the !in clause. The residual queue is PKINIT from unexpected sources -- the structural pattern behind both the post-ESC8 NTLM-relay class and the Synacktiv Invoke-RunAsWithCert evasion class.

Tenants that want the alert and event corpus in their SIEM as well as in Defender XDR should configure the MDI to Microsoft Sentinel connector through the Defender XDR-to-Sentinel integration; the connector is auto-enabled when Sentinel is onboarded to the Defender portal [@mslearn-sentinel-defender-connector].

Lane 4 -- what does NOT work

Five named operator myths, each refuted with a one-paragraph structural reason.

Myth 1: "MDI without the DC sensor still catches Kerberos attacks via the Entra ID side." Wrong. The Kerberos protocol layer is on-prem; the analytics require on-DC capture of the AS-REQ / TGS-REQ / AP-REQ exchange. Entra ID's side of the hybrid auth flow does not carry the same protocol detail. A tenant with MDI licensed but the sensor not deployed on the DCs has no Kerberos detection at all -- the licensed state is necessary but not sufficient.

Myth 2: "Disabling the v2.x sensor on AD FS is fine since it is covered by the DC sensor." Wrong. The AD FS authentication flow generates federation-side events (SAML assertions, OAuth tokens, the Application and Security event logs that AD FS itself writes) that the DC sensor does not see. AD FS deserves its own sensor unless the AD FS role is collapsed onto a domain controller, in which case the May 2026 v3.x identity-role extension covers it.

Myth 3: "Defender for Endpoint covers what MDI covers." Wrong. MDE catches endpoint behaviour -- process creation, file access, network connections, registry writes. MDI catches protocol-level Kerberos, NTLM, LDAP, and DRSUAPI patterns. The two products share an agent surface in the v3.x architecture, but the signal classes are different. An MDE-only deployment will not catch a DCSync from a workstation if MDI is not licensed and the sensor is not deployed; the MDE agent on the DC sees the local process activity but not the wire-side replication call's source.

Myth 4: "MDI alerts are real-time." Wrong. As Callout in Lane 2 above. The cloud-side batched-emission cadence is minutes-not-seconds, and incident response runbooks need to account for it.

Myth 5: "MDI requires no tuning." Wrong. Every environment has unique false-positive patterns from internal tooling that need exclusions. Microsoft ships the default detector thresholds; tenants tune them through the Defender XDR portal's identity-alert configuration surface. A tenant that has not tuned the recon-alert allowlist for its vulnerability scanners will receive far more noise than signal.

Coverage, triage, KQL, and humility about what does not work. The four lanes are the difference between MDI as a licence item on a renewal sheet and MDI as a working part of the SOC's day.

11. Frequently Asked Questions and Closing

Six questions that come up every time MDI is on a whiteboard, each in the misconception-removal pattern: wrong answer named first, then refuted.

No. See the *common misreading worth fixing* Callout in Section 4: graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), and the 2022 anchor in operator memory is the start of the SAM-R-discovery deprecation arc that culminated in MC1073068 in May 2025 [@mslearn-ata-1-9][@handsontek-mc1073068]. Not as one alert per ESC class. The MDI Certificates posture page documents **nine ADCS posture assessments** -- ESC1 (Preview), ESC2, ESC3, ESC4 (template-owner and template-ACL variants), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 [@mslearn-mdi-certificates-posture]. The runtime detection surface for the ESC8 NTLM-relay class is the *Suspected NTLM relay attack* alert in the XDR catalogue [@mslearn-mdi-alerts-xdr]. PKINIT-class runtime detection (the post-ESC8 chain) is the AS-REQ encryption-type fingerprint that Synacktiv documented and partially evaded; the August 2023 AD CS sensor release is the prerequisite for posture coverage [@mstc-adcs-sensor][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. Coverage is "nine posture assessments plus one runtime alert," not "one alert per ESC1 through ESC15." Microsoft has never published the canonical list; community reverse-engineering is the only source. See the *honest provenance of the ETW provider list* Aside in Section 5 for the full provenance (Synacktiv's November 2022 primer; Olaf Hartong's FalconForce MDE Internals 0x02 methodology; the Get-TraceLoggingMetadata + Sealighter toolchain) and the snapshot-not-ground-truth framing [@synacktiv-primer-mdi][@falconforce-mde-0x02]. In the cloud since Azure ATP went GA in March 2018 [@mstc-azureatp-ga][@mstc-azureatp-intro]. The on-DC sensor is a thin parser that captures Kerberos / NTLM / LDAP / DRSUAPI on the wire, parses the protocols into structured events, and streams the parsed signal to the multi-tenant cloud backend over HTTPS. The detection logic, the per-principal behavioural baselines, and the alert-emission pipeline all run in the cloud. The legacy on-prem ATA Center model ended with Azure ATP; ATA itself shipped its last release (1.9.3) in September 2020 and Extended Support ends January 2026 [@mstc-ata-eol][@atadocs-versions]. No. The framing is parallel evolution, not a "forcing" relationship. BloodHound CE expanded ADCS attack-path coverage substantially in 2024 and 2025; during the same window MDI extended its ADCS posture assessment surface and added the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023]. Both product communities watch each other -- the Defender team uses BloodHound to red-team its own environments, the SpecterOps team uses MDI when consulting in enterprise Microsoft shops -- but the causal claim "BloodHound forced MDI" is not supported by the public release record. The two communities' work has been concurrent and mutually informing. Almost. The MITRE-aligned alert catalogue in Section 6.2 covers the most-prevalent offensive primitives. Section 8 names the five structural ceilings that remain by-construction unclosable; *almost* is the load-bearing word.

Friday, 14:35. The watcher on the domain controller has written three named alerts into the Defender XDR queue. The red-team contractor's Rubeus.exe asreproast fired Suspected AS-REP Roasting attack (T1558.004). The junior auditor's bloodhound-python -c All fired Security principal reconnaissance (LDAP). The Mimikatz DCSync against the SQL host's service account fired Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006. Three alerts. Three MITRE technique IDs. Three rows in a Tier 1 analyst's queue.

The watcher's job is done. Whether the analyst opens the right one first, whether the Tier 2 escalation happens inside the one-hour SLA, whether the response action gets approved before the attacker has moved on -- none of that is MDI's problem to solve. It is yours.

AD Is a Graph: How BloodHound Made Defenders Think Like Attackers

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

**AD is a graph.** In April 2015 John Lambert named the missing model in two sentences. In August 2016 Andy Robbins, Rohan Vazarkar, and Will Schroeder shipped the tool that made it operational: BloodHound treats Active Directory as a directed graph of privilege relationships, queries it with Neo4j's Cypher, and turns weeks of red-team whiteboard work into a 200 ms shortest-path lookup. By November 2024 Microsoft itself shipped the same mental model as Microsoft Security Exposure Management. This article is half tool history (1998 academic attack graphs through OpenGraph 2025) and half graph-theory exposition: property graphs, BFS shortest paths, the edge taxonomy, and the open problem of *weighting* what is currently treated as one BFS hop per privilege.

1. How do I get from this user to Domain Admin?

In 2014, a red-team analyst with a help-desk account inside a 40,000-user Active Directory forest asks the question every red-team analyst asks: is there a path from here to Domain Admins? The answer takes two analysts five days of PowerView scripts, hand-drawn whiteboard diagrams, and per-host RDP probing. The same question in 2024 is a ninety-character Cypher query that returns in 200 milliseconds.

What happened in those ten years is the story of one sentence -- defenders think in lists, attackers think in graphs -- becoming, in turn, a tool, a discipline, and a Microsoft product.

The 2014 reality was a stack of CSV files. PowerView, the PowerShell enumeration toolkit Will Schroeder first published in August 2014 [@powersploit-repo], could dump every group membership, every Access Control Entry, and every active session from a low-privilege account [@powertools-powerview]. The outputs were rows. Hundreds of thousands of rows. Composing them into a coherent attack path was a job for a marker and a whiteboard, and the join keys were Distinguished Names that wrapped twice across an analyst's notebook page. Five days to map a single 40,000-user forest was not unusual. It was the price of doing business.

The 2024 reality is a query. The analyst loads SharpHound's JSON dump into a Neo4j graph, opens the BloodHound web interface in a browser, types

MATCH p = shortestPath(
  (u:User {name:'HELPDESK@CORP.LOCAL'})-[*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})
) RETURN p

and clicks Run. The graph renders. The shortest path is highlighted. The pivot points are circled. Time elapsed: 200 milliseconds on the database, plus a second for the browser to draw the SVG [@bloodhound-ce-repo].

Whatever happened in those ten years has to be more than a software release. It has to be a change in how the entire community models the problem. The change has a date and a sentence. Both arrived in April 2015. Let us start with the sentence.

2. From ACL lists to graphs -- why the model matters

An access-control list is not the same as a graph -- and the difference is everything.

Consider five accounts in a hypothetical CORP.LOCAL forest. Bob, a help-desk operator, has been granted ForceChangePassword on Carol's account by a long-departed administrator who once needed to delegate password resets. Carol is a member of Server Operators. Server Operators, by default, can log on locally to Domain Controllers and back up the directory database. The Domain Controller hosts the krbtgt account.

Three rows in three different audit reports. One attack path.

A per-object Access Control List audit looks at Bob's row, sees a ForceChangePassword ACE, and flags it as "an over-broad delegation." It looks at Carol's row, sees that she belongs to Server Operators, and flags it as "a privileged group membership." It looks at the Domain Controller and sees that Server Operators has logon rights, which is the default. Nothing in the audit composes the three facts. Reachability is not a property the report computes.

A set of nodes (vertices) and directed edges (arrows) between them. Each edge points from one node to another. A *path* is a sequence of edges that can be traversed in the direction of their arrows. A node B is *reachable* from a node A if some path leads from A to B. A property of two nodes A and B in a directed graph: B is reachable from A if there exists a sequence of edges leading from A to B, regardless of length. Reachability is fundamentally a graph property and cannot be answered by inspecting any single edge in isolation.

Now draw the same five accounts as a directed graph. Bob is a node. Carol is a node. Server Operators is a node. The Domain Controller is a node. The krbtgt account is a node. There is an edge from Bob to Carol labelled ForceChangePassword. There is an edge from Carol to Server Operators labelled MemberOf. There is an edge from Server Operators to the Domain Controller labelled CanRDP. There is an edge from the Domain Controller to krbtgt labelled DCSync. Trace the arrows. Bob can reach krbtgt.

The graph form makes reachability visually obvious. The list form does not. This is not a presentation difference. It is a data-model difference, and it is the difference that decides whether a tool can answer the question "is there a path from A to B?" at all.

Key idea: Reachability is a property of the graph that the list does not, in general, express. This is not a UX difference. It is a data-model difference, and it is the entire reason BloodHound exists.

The sentence that named this gap appeared on April 26, 2015. John Lambert, then a Distinguished Engineer in the Microsoft Threat Intelligence Center, published a short essay to a personal GitHub repository [@lambert-2015-defenders-lists-attackers-graphs]. No peer review. No formal venue. Two declarative opening sentences that every defender attack-path product since has cited approvingly.

Defenders don't have a list of assets -- they have a graph. Assets are connected to each other by security relationships. As long as defenders use a list and attackers use a graph, attackers win. -- John Lambert, April 26, 2015.

Lambert then enumerated five concrete classes of "security dependencies" that constitute edges in any real network: shared local-admin passwords; logon scripts on file servers; print-driver propagation from print servers; certificate authorities that mint smart-card logon certificates; and database administrators who run code as a privileged DB process. The essay closed with a defender prescription: "The first step is to visualize your network by turning your lists into graphs."

If the diagnosis is so obvious in retrospect, why was every mainstream AD audit tool from 2000 through 2015 list-shaped? The answer is that the academic literature had the right model but the wrong substrate, and the operator community had the right substrate but the wrong model. The two did not meet until April 2015.

3. Attack graphs before BloodHound, 1998 to 2015

The phrase attack graph is older than Active Directory itself.

In September 1998, two researchers at Sandia National Laboratories presented a paper titled A Graph-Based System for Network-Vulnerability Analysis at the New Security Paradigms Workshop in Charlottesville, Virginia. The authors, Cynthia Phillips and Laura Painton Swiler, proposed that a network's worst-case attack was a graph traversal problem [@phillips-swiler-1998-nspw]. Nodes encoded network states (the set of attacker privileges across the set of hosts). Edges encoded atomic attack steps (an exploit that, given prerequisite privileges, granted new ones). The shortest path from "attacker outside the network" to "attacker has goal asset" was the worst-case attack.

Phillips and Swiler observed in a now-canonical sentence that "the security of a network is more than the sum of the security of its hosts." It is the conceptual ancestor of every attack-path tool that followed.

Four years later, at IEEE Symposium on Security and Privacy 2002, Oleg Sheyner (then a CMU PhD student) along with Joshua Haines and Richard Lippmann (MIT Lincoln Lab), Somesh Jha (Wisconsin), and Jeannette Wing (CMU) made the construction automatic [@sheyner-et-al-2002-attack-graphs]. They encoded the network and attacker model as an NuSMV model-checker specification, treated the negation of the security goal as a temporal-logic property, and let the model checker generate every counterexample. The union of counterexamples was the attack graph.

They also proved that the minimum set of edges whose removal disconnects the attacker from the goal is NP-hard, but admits an O(log n) approximation -- the first asymptotic bound for the defender-hardening problem.

Sheyner's companion 2004 thesis -- Scenario Graphs and Attack Graphs, CMU-CS-04-122 -- remains the most readable book-length treatment of the academic-attack-graph generation [@sheyner-2004-thesis].

By 2005 the academic line had a scale solution. Xinming Ou, Sudhakar Govindavajhala, and Andrew Appel at Princeton released MulVAL at USENIX Security 2005 [@mulval-usenix-2005], encoding network state and attacker rules as Datalog facts and running them through XSB Prolog. From the paper's abstract: "Once the information is collected, the analysis can be performed in seconds for networks with thousands of machines." NetSPA at MIT Lincoln Lab (2006) and TVA / CAULDRON at George Mason (2003 to 2005) achieved similar scale through different mechanisms.

In parallel, on the Windows operator side, Sean Metcalf was running adsecurity.org and documenting AD misconfiguration patterns one writeup at a time [@adsecurity-org]. Microsoft was rolling out its Enhanced Security Administrative Environment ("Red Forest") tiered-administration model -- the predecessor that the Enterprise Access Model later replaced [@ms-enterprise-access-model] -- which was implicitly graph-aware (the entire ESAE prescription is a tier diagram) but never exposed the tier graph as a queryable structure. ESAE was a deployment blueprint, not a tool.

gantt title Three parallel tracks converging on the attack-path graph dateFormat YYYY axisFormat %Y

section Academic CVE line
Phillips and Swiler NSPW   :a1, 1998, 1999
Sheyner et al. IEEE SP     :a2, 2002, 2003
MulVAL USENIX              :a3, 2005, 2006
NetSPA TVA                 :a4, 2006, 2008

section Windows operator line
adsecurity.org writeups    :b1, 2014, 2016
PowerView                  :b2, 2014, 2016
Lambert essay              :milestone, b3, 2015-04-26, 1d
BloodHound DEF CON 24      :b4, 2016, 2018
AzureHound BloodHound 4.0  :b5, 2020, 2023
BloodHound CE 5.0          :b6, 2023, 2024
ADCS attack paths          :b7, 2024, 2025
Butterfly v6.3             :b8, 2024, 2026
OpenGraph v8.0             :b9, 2025, 2026

section Microsoft defender stack
ESAE Red Forest blueprint  :c1, 2015, 2018
Azure ATP LMPs preview     :c2, 2018, 2020
Defender CSPM attack paths :c3, 2022, 2024
MSEM GA                    :milestone, c4, 2024-11-19, 1d

The April 2015 essay sat between the two tracks. Lambert was inside Microsoft. He had read the academic literature. He worked next to the threat-intelligence teams who watched real intrusions unfold. The essay was the moment the two communities' vocabularies met. The diagnosis was right. The cure was sixteen months away. It would not come from Microsoft, and it would not come from academia. It would come from a red-team consultancy and a free graph database, and it would debut on a Saturday in August at a hacker convention in Las Vegas.

4. Defenders evaluating Active Directory as a list of ACLs

If you were a Microsoft-aligned AD security engineer in 2013, your job was to read ACLs. One object at a time. Down a list.

The mainstream defender toolchain of the era was, almost without exception, list-shaped. Microsoft shipped dsacls.exe and PowerShell's Get-Acl; both produced row-oriented output that an analyst read sequentially. The commercial AD-audit market -- NetWrix Auditor [@netwrix-auditor], ManageEngine ADAudit Plus [@manageengine-adaudit-plus], Quest ActiveRoles [@quest-activeroles], and others -- produced HTML reports with one section per directory object, one row per non-default Access Control Entry, and severity classifications based on a fixed checklist of "dangerous rights" (GenericAll, WriteDacl, WriteOwner, and a handful of others).

Microsoft's own Best Practices for Securing Active Directory document codified this approach. Its central recommendation was per-object delegation review: walk the directory tree, evaluate each object's ACL against a hardening checklist, and remediate non-default ACEs that exceed the documented privilege model [@ms-best-practices-ad]. The document is excellent at what it sets out to do. What it does not do -- because the format does not permit it -- is compose multi-hop reachability.

This was the failure mode Lambert described. A help-desk operator with ForceChangePassword on a junior service account appears as one row in the audit. The junior service account's MemberOf Server Operators membership appears in a different report section. The Server Operators group's logon rights on the Domain Controller appear in the Domain Controller's own report. Three findings in three places, with no machinery to compose them. The data model cannot represent the question.

A reader trained on Phillips and Swiler, Sheyner et al., MulVAL, NetSPA, and TVA might object that *the field already had* graph-based attack-path analysis a decade before BloodHound. True -- in academia. The academic line solved the scale problem (MulVAL: *"seconds for networks with thousands of machines"*) but spoke the wrong vocabulary. Its atomic attack step was a CVE exploit -- a buffer overflow, a format-string bug, a daemon remote code execution. The dominant AD attack primitive is not a CVE. A user with `WriteDacl` on a group is not exploiting any vulnerability; they are using the system as designed. None of MulVAL, NetSPA, or TVA developed an AD-style privilege-graph input format, and the operator community never adopted them. The academic line was substrate-mismatched and delivered as research-PDF tarballs rather than as `git clone`-able tools.

Two communities, both wrong in different ways. The academic one had the right algorithm with the wrong substrate. The operator one had the right substrate with no algorithm at all. The fix was to fuse them. That happened on August 6, 2016.

5. The breakthrough -- BloodHound and Six Degrees of Domain Admin

Saturday, August 6, 2016. 1:00 PM. DEF CON 24, Track 2, Paris and Bally's hotel-casinos in Las Vegas [@defcon-24-archive]. Three speakers from Veris Group's adaptive threat division step on stage: Andy Robbins, Rohan Vazarkar, Will Schroeder. The talk is titled Six Degrees of Domain Admin: Using Graph Theory to Accelerate Red Team Operations [@defcon24-bloodhound-slides]. The Veris Group team would spin out as SpecterOps the following year, but the August 2016 attribution -- Robbins (@_wald0), Vazarkar (@CptJesus), and Schroeder (@harmj0y) -- is the canonical one [@bloodhound-legacy-repo].

The talk demonstrated three design decisions that in retrospect look obvious and at the time were not.

First, model Active Directory as a directed property graph. Nodes are typed security principals (User, Computer, Group, Domain, OU, GPO). Edges are typed privilege relationships (MemberOf, AdminTo, HasSession, GenericAll, GenericWrite, WriteDacl, ForceChangePassword, and others). This was Lambert's framing made concrete: every ACE that grants a dangerous right becomes an edge from the trustee to the target.

Second, reuse Neo4j as the engine. Do not build a custom graph database; piggyback on Cypher's pattern-matching query language. The cost of building a path-finding engine from scratch was non-trivial; the cost of standing up Neo4j was a single Docker container.

Third, ship a collector that emits typed JSON edges, not raw NTSecurityDescriptors. The collector's value is the interpretation of an ACE as a graph edge -- the mapping from a binary security descriptor to the typed edge that says "trustee X has GenericWrite on object Y" is the hard part, and a defender re-creating that mapping per query would lose. SharpHound (initially SharpHound.ps1, then a C# binary) does the interpretation once at collection time and writes the edges to disk [@bloodhound-ce-repo].

SharpHound's enumeration calls are visibly descended from PowerView. The November 2020 SpecterOps blog announcing BloodHound 4.0 acknowledges the lineage explicitly, naming Schroeder's joint authorship of both projects and crediting PowerView as the data-collection precursor [@specterops-2020-bloodhound-4]. PowerView's August 2014 release was the substrate that made BloodHound's August 2016 synthesis possible. The chain is unbroken: enumeration in 2014, framing in April 2015, graph synthesis in August 2016.

The five-day-of-whiteboard-work figure comes from the SpecterOps team's own internal benchmark from the original DEF CON 24 talk. The 200 ms query latency is the typical 2024 figure on a mid-size enterprise forest of roughly 10^5 nodes and 10^6 edges, retained as the company's marketing framing across subsequent blog posts.

Key idea: BloodHound's breakthrough was neither an algorithm nor an architecture. It was the decision to interpret Active Directory's access-control data as a typed graph and ship that interpretation as a tool the operator community could actually run.

Crucially, the choice to use Neo4j's free shortestPath() function rather than building a custom path-finder was a delivery decision as much as a technical one. Neo4j already did breadth-first shortest paths. The team did not need to invent anything. The hard work was in the edge taxonomy and the collector, not in the graph database.

The talk made a promise the rest of the article must now cash: that there is a real algorithm under the hood, that the algorithm has a name, and that the name is not Dijkstra.

6. The algorithmic core -- property graphs, Cypher, and shortest paths

If you have never written a Cypher query in your life, the next ninety seconds is the entirety of the syntax you need.

A graph in which both nodes and edges are typed and can carry key-value properties. A node might have type `User` and properties `name='BOB@CORP.LOCAL'`, `enabled=true`, `pwdlastset=1719234234`. An edge might have type `GenericWrite` and properties `source='ACE'`, `isacl=true`. This is the data model Neo4j implements and the model BloodHound uses.

A Cypher pattern is a parenthesised node, a bracketed edge, and a parenthesised node, with arrows showing direction. (u:User)-[:MemberOf]->(g:Group) reads "find a node u of type User connected by a MemberOf edge to a node g of type Group." A full query has four parts: MATCH for the pattern, optional WHERE for filters, RETURN for the output. That's it.Cypher patterns visually mimic ASCII graph drawings: parentheses are nodes, square brackets are edges, and the arrow direction matches the edge direction. The syntax was deliberately designed to look like the diagram you would sketch on a whiteboard.

The pattern-matching query language originally created for the Neo4j graph database. Cypher's syntax is declarative: you describe the shape of the data you want, and the engine plans the traversal. Since April 2024 Cypher has been the basis of the ISO/IEC 39075:2024 GQL standard -- the first ISO-standardised graph query language [@iso-39075-2024-gql] [@opencypher-home].

Here is the canonical BloodHound query, with annotations:

MATCH p = shortestPath(
  (u:User {name:'BOB@CORP.LOCAL'})       // start node: Bob
    -[*1..]->                            // any number of typed edges
  (g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'})  // end node: Domain Admins
)
RETURN p

The shortestPath() wrapper tells Neo4j to short-circuit at the first solution. The variable-length quantifier [*1..] says "one or more edges of any type." The p = binds the entire matched path to the variable p, which the RETURN then emits as a sequence of node-edge-node triples that the BloodHound frontend renders as an SVG.

What does shortestPath() actually run? Here is where the misconception that BloodHound uses Dijkstra needs to die. The current Neo4j Cypher manual is explicit that shortestPath() runs an unweighted bidirectional traversal -- BFS in the classical sense -- between the source and target nodes [@neo4j-cypher-shortest-paths]. Not Dijkstra. Not A*. BFS.

A graph-traversal algorithm that explores all nodes at the current depth before proceeding to the next depth. Starting from the source, it visits all 1-hop neighbours, then all 2-hop neighbours, and so on. For unweighted graphs, BFS is guaranteed to find a shortest path (in number of edges) the first time it reaches the target. Worst-case time is O(V + E) where V is the node count and E is the edge count -- the trivial information-theoretic lower bound for any algorithm that must read the input.

Cypher does support weighted shortest paths via the Neo4j Graph Data Science library, but the BloodHound CE distribution does not enable it. There is no natural cost metric on Active Directory privilege edges in 2026; every edge is treated as one hop.

Why BFS rather than Dijkstra? Dijkstra is BFS's generalisation to weighted graphs. If your edges have natural costs -- road distances, link latencies, dollar prices -- Dijkstra (with a Fibonacci heap, $O(E + V\log V)$) gives you shortest paths under that cost metric. Active Directory privilege edges do not have a natural cost metric. MemberOf, GenericAll, and CanRDP are all "the attacker can take this step." Some are easier than others, but quantifying how much easier is itself an unsolved problem (see Section 11). Treating every edge as one hop is the load-bearing simplification that makes the model tractable.

Of a binary relation R: the relation R+ that contains the pair (a, c) whenever there is a chain a R b R ... R c. For a graph, the transitive closure tells you, for every pair of nodes, whether one is reachable from the other. BloodHound's `shortestPath()` queries can be thought of as on-demand evaluation of the transitive closure restricted to one source-target pair.

The per-query complexity is $O(V + E)$, the standard BFS bound from any algorithms textbook. On a mid-size enterprise forest -- roughly 10^5 nodes and 10^6 edges -- a single user-to-group shortest path returns in sub-second wall-clock time.

The variable-length quantifier [*1..N] for general path enumeration is a different matter. Cyclic graphs admit exponentially many paths in N, and Neo4j's documentation explicitly warns that quantified path patterns can return exponentially many results in the worst case [@neo4j-cypher-variable-length]. The shortestPath() short-circuit avoids this by returning on the first hit; allShortestPaths() enumerates only paths tied for shortest; unbounded enumeration is intractable on any non-trivial graph.

A concrete demonstration is in order. The runnable snippet below is a 35-line implementation of unweighted BFS over a six-node toy graph. It returns the shortest path from a helpdesk user to the domain-admin group. This is, structurally, the same algorithm Neo4j's shortestPath() runs. The numerical answer ("path of length 4") is the same number BloodHound would report on the same graph.

{` // Edges modelled as a typed adjacency list. const edges = { helpdesk: [{ to: 'carol', via: 'ForceChangePassword' }], carol: [{ to: 'serverops', via: 'MemberOf' }], serverops: [{ to: 'dc01', via: 'CanRDP' }], dc01: [{ to: 'krbtgt', via: 'DCSync' }], krbtgt: [{ to: 'domain-admin', via: 'GoldenTicket' }], domain_admin: [] };

function shortestPath(start, goal) { const queue = [[start]]; // queue holds candidate paths const seen = new Set([start]); // each node enqueued at most once

while (queue.length) { const path = queue.shift(); // BFS = FIFO const node = path[path.length - 1]; if (node === goal) return path; for (const e of (edges[node] || [])) { if (!seen.has(e.to)) { seen.add(e.to); queue.push([...path, e.to]); } } } return null; // unreachable }

const path = shortestPath('helpdesk', 'domain-admin'); console.log('Path:', path.join(' -> ')); console.log('Length:', path.length - 1, 'hops'); `}

The algorithm fits on a single screen. The hard work of BloodHound is not in this loop. The hard work is in deciding which edges to insert into the graph in the first place. That decision -- the edge taxonomy -- is what makes BloodHound a security tool rather than a graph-database demo.

sequenceDiagram participant Client as Cypher client participant Planner as Cypher planner participant Engine as BFS engine participant Graph as Property graph Client->>Planner: MATCH shortestPath(u to g) Planner->>Engine: plan(start=u, end=g, bidirectional=true) Engine->>Graph: expand 1-hop frontier from u Engine->>Graph: expand 1-hop frontier from g Graph-->>Engine: neighbours of u, neighbours of g Engine->>Graph: expand 2-hop frontier (both sides) Engine->>Graph: expand 3-hop frontier (both sides) Graph-->>Engine: frontiers intersect at node m Engine-->>Planner: reconstruct path u to m to g Planner-->>Client: return path

7. The edge taxonomy -- what Active Directory actually looks like as a graph

The BloodHound graph is not every privilege relationship in Active Directory. It is the set of relationships that the SpecterOps team has decided -- by iterative discovery, often in response to specific community-reported abuse primitives -- to model. The taxonomy has grown roughly monotonically since 2016; the rate has accelerated since the BloodHound CE 5.0 reboot in August 2023 [@specterops-2023-bloodhound-ce].

Eight families dominate the 2026 graph. They map, family by family, onto the substrates of a modern hybrid enterprise.

1. Group membership. MemberOf is the simplest edge. Cypher's variable-length quantifier ([:MemberOf*1..]) walks transitive memberships in one expression, which is why nested-group reachability is a one-liner.

2. ACL write-equivalents. GenericAll, GenericWrite, WriteDacl, WriteOwner, Owns, AllExtendedRights, ForceChangePassword, AddSelf, AddMember, and AddKeyCredentialLink (the shadow-credentials primitive). Each names a specific dangerous-right pattern on a directory object's security descriptor. SharpHound's interpreter scans the nTSecurityDescriptor attribute and emits one typed edge per matching ACE.

3. Sessions. HasSession is the dynamic edge that goes stale fastest. SharpHound enumerates active sessions via NetSessionEnum and SAMR; the resulting edges describe "user U is currently logged into computer C." The graph is whatever the most recent collection captured.

4. Remote execution rights. AdminTo, CanRDP, ExecuteDCOM, CanPSRemote, SQLAdmin. Each describes a code-execution primitive granted to a principal on a computer object.

5. Kerberos delegation. AllowedToDelegate (constrained delegation), AllowedToAct (resource-based constrained delegation, via msDS-AllowedToActOnBehalfOfOtherIdentity), unconstrained delegation surfaced as node properties on Computer objects, and -- from BloodHound CE v6.3 in December 2024 [@bloodhound-v6-3-release] -- a CoerceToTGT edge that replaces the older UnconstrainedDelegation finding for BHE customers.

6. ADCS edges (early-access January 2024). ADCSESC1 through ADCSESC10, plus the CoerceAndRelayNTLMToADCS edge for ESC8 [@specterops-2024-adcs-bloodhound]. These edges land in BloodHound roughly thirty months after Will Schroeder and Lee Christensen first published the ESC1 to ESC8 catalog in Certified Pre-Owned: Abusing Active Directory Certificate Services [@specterops-2021-certified-preowned]. Each ADCS edge in BloodHound is the most complex in the taxonomy because each is composed from multiple raw facts (see the traversable / non-traversable discussion below).

7. Azure / Entra ID edges (via AzureHound, November 20, 2020) [@specterops-2020-bloodhound-4]. AZGlobalAdmin, AZRoleAssignment, AZContains, AZOwns, AZUserAccessAdministrator, AZAddSecret, AZMGAddOwner, plus AzureRM-side resource roles. Microsoft Entra Privileged Identity Management (PIM) role coverage was added in BloodHound v8.0 in July 2025 [@specterops-2025-opengraph].

8. OpenGraph custom edges (v8.0, July 29, 2025). User-defined edges for arbitrary substrates: GitHub, Snowflake, Microsoft SQL Server, ServiceNow, Tailscale, Duo. The schema is intentionally generic so that a community contributor can ship edges for any system whose privilege model can be drawn as a graph [@bloodhound-opengraph-library].

Family	Representative edges	Underlying AD mechanism	What it gives the attacker
Group membership	`MemberOf`	`member` attribute on group object	Inherits all permissions held by the group
ACL write-equivalents	`GenericAll`, `GenericWrite`, `WriteDacl`, `WriteOwner`, `ForceChangePassword`, `AddKeyCredentialLink`	Specific dangerous-right ACE patterns in `nTSecurityDescriptor`	Take control of the target principal (reset password, modify object, plant shadow credentials)
Sessions	`HasSession`	`NetSessionEnum` and `SAMR` enumeration on member computers	Pivot via credential theft from the logged-in user's memory
Remote execution	`AdminTo`, `CanRDP`, `ExecuteDCOM`, `CanPSRemote`, `SQLAdmin`	Local-admin membership, RDP / DCOM / WinRM / SQL group rights	Run arbitrary code as the target principal on the target host
Kerberos delegation	`AllowedToDelegate`, `AllowedToAct`, `CoerceToTGT`	Constrained and resource-based delegation attributes	Forge service tickets and impersonate other accounts
ADCS composite	`ADCSESC1` through `ADCSESC10`, `CoerceAndRelayNTLMToADCS`	Certificate template misconfigurations plus CA trust plus enrollment ACEs	Obtain a certificate usable for authentication as a privileged account
Azure / Entra	`AZGlobalAdmin`, `AZRoleAssignment`, `AZAddSecret`, `AZOwns`, `AZMGAddOwner`	Entra role assignments, AzureRM RBAC	Cross the on-prem to cloud boundary; pivot via tenant or subscription privileges
OpenGraph	User-defined	Any substrate the contributor models	Anything the contributed schema encodes

The ADCS family deserves a closer look because it introduced an important new modelling vocabulary.

A *traversable* edge is one the shortest-path query can step through directly: `MemberOf`, `ForceChangePassword`, `CanRDP`. A *non-traversable* edge is a precondition relationship that is only exploitable when several others appear together. A certificate template's `Enroll` ACE is non-traversable on its own; combined with eight other facts about the template, the issuing CA, and the domain's trust posture, it composes into `ADCSESC1`. The post-processor scans for the full pattern and synthesises a single traversable edge that the BFS can then treat as one hop [@specterops-2024-adcs-bloodhound].

For ESC1 the pattern has nine numbered prerequisites: six template and CA requirements, two enterprise-CA trust facts, and one implicit constraint. None of the nine raw facts is exploitable in isolation. All nine together are. The post-processor's job is to walk the candidate sub-graphs, check every requirement, and write the composed ADCSESC1 edge when the pattern holds.

This is a non-trivial graph-modelling contribution because it gives the field a vocabulary for "an edge that is real only as a join over several facts." It also generalises beyond ADCS: any future attack primitive composed from a fixed pattern of raw facts can be modelled the same way.

ESC8 -- the NTLM relay primitive against an HTTP-enrollment certificate authority -- is the most delicate case, and the one most commonly mis-modelled in early secondary writeups.

Note: The CoerceAndRelayNTLMToADCS edge is a Group(Authenticated Users) to Computer(coerced target) edge, not a Computer to Computer edge as some early secondary writeups described. The relay-target CA and the certificate template are carried as edge metadata, not as additional graph nodes. The canonical edge documentation is explicit: Source: Authenticated Users [Group] / Destination: Computer / Traversable: Yes [@bloodhound-coerce-relay-edge].

The schema correction matters because the source-principal choice affects every shortest-path query that crosses ESC8. If the edge is mis-modelled as Computer to Computer, queries that begin from a low-privilege user account miss the path entirely. The Group-to-Computer schema correctly captures that any authenticated principal can coerce.

What the graph does not yet model is also worth naming. The SpecterOps/TierZeroTable README states it verbatim: "DISCLAIMER: The table does not include all Tier Zero assets yet." [@specterops-tier-zero-table] Several edge classes remain partially or fully out of scope; the full enumeration appears in Section 11 (open problems). Coverage expansion is iterative and community-fed; OpenGraph (Section 9) is the structural answer to "where does the graph end?"

flowchart TD subgraph OnPrem["On-prem Active Directory"] Members["MemberOf, Owns"] ACL["ACL write-equivalents
GenericAll, WriteDacl, ForceChangePassword,
AddKeyCredentialLink"] Sessions["HasSession"] Exec["AdminTo, CanRDP, ExecuteDCOM,
CanPSRemote, SQLAdmin"] Krb["Kerberos delegation
AllowedToDelegate, AllowedToAct, CoerceToTGT"] end subgraph Entra["Entra ID and AzureRM"] EntraRoles["AZGlobalAdmin, AZRoleAssignment,
AZAddSecret, AZUserAccessAdministrator,
PIM roles"] AzureRM["AZContains, AZOwns,
AzureRM resource roles"] end subgraph ADCS["ADCS composite edges"] ESC["ADCSESC1 to ADCSESC10,
CoerceAndRelayNTLMToADCS"] end subgraph Open["OpenGraph user-defined"] Custom["GitHub, Snowflake, SQL Server,
ServiceNow, Tailscale, Duo, custom"] end OnPrem --> Cypher((Cypher query layer)) Entra --> Cypher ADCS --> Cypher Open --> Cypher

If this is what one community modelled, the natural question is: what did Microsoft model? And when?

8. The defender adoption -- Microsoft catches up, 2018 to 2024

The defender vendor whose product BloodHound was mapping is also a defender vendor with a graph product of its own. Three of them, in fact, shipped in three different years for three different substrates. They are easy to confuse; press releases sometimes do.

The first arrived on November 27, 2018, when Tali Ash (then a Program Manager on the Azure Advanced Threat Protection team) announced a preview feature called Lateral Movement Paths (LMPs) in a Microsoft tech-community post [@ms-azure-atp-lmp-2018]. LMPs were a graph-shaped visualisation, but a constrained one: restricted to "sensitive accounts" (a configurable set defaulting to Domain Admins and similar) plus non-sensitive accounts that had shared a session on the same host as a sensitive account.

The portal rendered one- and two-hop credential-theft pivots as a static SVG. There was no Cypher equivalent, no LMP-export API, and no way to write a custom query. Azure ATP was rebranded Microsoft Defender for Identity in 2020, and the LMP feature came along under the new name [@ms-mdi-lmp-docs].

Several secondary sources date Lateral Movement Paths to "June 2019," which corresponds to the general-availability and rebrand window rather than the original preview announcement. The primary Microsoft tech-community post is November 27, 2018; treat the year-not-month for any third-party claim and prefer the November 2018 preview date as the canonical first ship.

The second arrived in October 2022, when Microsoft Defender for Cloud's Defender CSPM plan added a cloud security graph with attack-path analysis (public preview at Ignite October 2022; generally available March 28, 2023) [@ms-defender-cloud-attack-path]. This product is a cloud attack-path graph: Azure plus AWS plus GCP asset inventory, with inferred edges for permissions, network reachability, vulnerability presence, and internet exposure. It is explicitly not the Active Directory identity graph; it covers the multi-cloud workload surface.

A common mistake conflates this 2022-2023 product (Defender for Cloud) with Microsoft Defender for Identity (the LMP product from November 2018). The substrate, the team, and the year are all different. Worth flagging here because secondary writeups repeat the confusion often.

The Microsoft Defender XDR product family is a naming minefield. *Defender for Identity* (MDI) is the on-prem AD identity-threat product; LMPs are its graph view. *Defender for Cloud* (MDC) is the multi-cloud workload-protection product; its CSPM plan ships cloud-security-graph attack-path analysis. *Defender for Endpoint* (MDE) is the EDR product; it does not ship its own attack-path graph but feeds telemetry into MSEM. *Microsoft Security Exposure Management* (MSEM, GA November 19, 2024) is the unified exposure-graph layer that subsumes the others. Four products, four substrates, four ship dates. The naming overlap is unfortunate but the distinctions are real.

The third arrived on November 19, 2024, at the Ignite 2024 keynote in Chicago. Satya Nadella, in the opening keynote, announced that Microsoft Security Exposure Management (MSEM) had reached general availability [@ms-ignite-2024-msem]. MSEM is the product whose attack-path model is structurally equivalent to BloodHound's: cross-substrate (identity plus endpoint plus multi-cloud), first-class attack-path objects with choke-point and blast-radius dashboards, and continuous data feed via the Defender XDR signal plane.

Microsoft's unified exposure-graph product, generally available November 19, 2024, at Ignite 2024 in Chicago. MSEM ingests telemetry from Defender for Endpoint, Defender for Identity, Defender for Cloud, Entra ID, and the Defender XDR plane into a single graph. Attack paths are first-class objects with three dashboard views: an attack-path list, choke-point analysis (small sets of nodes whose compromise enables disproportionately many downstream paths), and blast-radius (downstream reach of a selected node) [@ms-msem-attack-paths].

The MSEM docs page introduces the model verbatim: "Attack paths in Microsoft Security Exposure Management help you to proactively identify and visualize potential routes that attackers can exploit using vulnerabilities, gaps, and misconfigurations across endpoints, cloud environments, and hybrid infrastructures." And, on choke points: "By focusing on these choke points, you can reduce risk by addressing high-impact assets."

The query interface is the Defender XDR portal plus KQL (Kusto Query Language), not Cypher. The graph engine is proprietary; Microsoft does not publish per-query latency numbers or the underlying algorithms. But the model -- nodes, typed edges, attack paths as the unit of analysis, choke-point and blast-radius views -- is the model BloodHound shipped at DEF CON 24 in August 2016.

The arc takes eight years. From the August 6, 2016 BloodHound talk to the November 19, 2024 MSEM general-availability announcement is eight years and three months. The defender vendor whose product the original BloodHound was mapping ships a defender product whose attack-path model is structurally equivalent to the one a red-team consultancy shipped in a conference talk eight years earlier.

Microsoft adopted the model. The community kept extending it. By 2026 the frontier is no longer "does the graph exist?" It is "how do we make the graph weighted, complete, and substrate-independent?" That is the state of the art.

9. State of the art -- Tier Zero, ADCS edges, and OpenGraph, 2023 to 2026

By the time MSEM shipped, SpecterOps had already moved past "is there a graph?" and was asking three sharper questions. Where does the graph end? How do we model attack primitives that compose from raw facts? And does the AD-specific schema even matter?

The first question is what "Tier Zero" means. On June 22, 2023, Jonas Bülow Knudsen, Elad Shamir, and Justin Kohler at SpecterOps published What is Tier Zero -- Part 1, which reframed Microsoft's tiered-administration concept -- introduced in the 2012-2014 Securing Privileged Access guidance and renamed the Enterprise Access Model with the "Control Plane" vocabulary in December 2020 [@ms-enterprise-access-model] -- as a property of the graph [@specterops-2023-tier-zero].

A Tier Zero asset (see Definition below) reframes Microsoft's tiered concept from the set of things in the high-privilege tier to the set of things from which the high-privilege tier is reachable. Microsoft's own Tier 0 definition -- "Direct Control of enterprise identities... and all the assets in it" -- becomes a graph property. The two formulations are equivalent if and only if the graph is complete. If the graph is incomplete (which it is), the Tier Zero set computed from the graph is the floor, not the ceiling.

Any node in the attack-path graph whose compromise lets an attacker reach an administrative privilege in the forest. The companion `SpecterOps/TierZeroTable` GitHub project is the community-maintained inventory; the README discloses that the table is the floor, not the ceiling [@specterops-tier-zero-table].

The Tier Zero definition is the answer to "shortest path to what?" -- the target side of every BloodHound shortest-path query. Without a defined Tier Zero set, the question has no endpoint.

The second question is how to model attack primitives that compose. The January 24, 2024 SpecterOps blog by Knudsen formalised this with the traversable / non-traversable edge distinction discussed in Section 7. The mechanism generalises: any attack primitive whose exploitability is a conjunction of raw facts can be encoded as a composed edge that the post-processor synthesises when the pattern is present.

ESC1, walked through in Section 7, is the canonical example: nine numbered prerequisites that the post-processor checks before writing the composed ADCSESC1 edge [@specterops-2024-adcs-bloodhound]. Subsequent posts in the series extended the same machinery to ESC3, ESC4, ESC6, ESC7, ESC8 (the CoerceAndRelayNTLMToADCS edge), ESC9, ESC10, and -- on February 14, 2024 -- ESC13 [@specterops-2024-esc13].

In December 2024 BloodHound v6.3 introduced an early-access "improved analysis algorithm" internally referred to as Butterfly [@bloodhound-v6-3-release]. Butterfly is the first production attempt at bi-directional impact analysis. Pre-v6.3 BloodHound Enterprise quantified risk as "who can reach this node?" (incoming attack-path count). v6.3 also quantifies "who can this node reach if compromised?" (outgoing blast radius).

The release notes describe the outcome but not the algorithm: "Improve risk scoring fidelity for all finding types... Measure risk at each individual finding... Support the inclusion of hybrid paths in risk scoring (Azure assets will now contribute to measured risk in AD and vice versa)."

The same release also announced that BloodHound Enterprise had begun migrating off Neo4j onto PostgreSQL as the graph database, with the release notes reporting ">50% improvement in the time it takes to perform post-processing during the Analysis process." Cypher continues to be the query language; the engine underneath changed.

The third question -- whether the AD-specific schema matters -- got its answer on July 29, 2025, when SpecterOps released BloodHound v8.0 with OpenGraph [@specterops-2025-opengraph]. OpenGraph decouples the graph engine from the AD-specific schema. Users (and SpecterOps partners) define their own node and edge kinds and ingest attack-path data from arbitrary substrates. The initial release included GitHub organisations, Snowflake role hierarchies, Microsoft SQL Server logins, ServiceNow groups, and Tailscale ACLs. Subsequent community contributions extended the library.

BloodHound OpenGraph is a foundational shift toward... identity risk management across the entire enterprise. -- Justin Kohler, SpecterOps Chief Product Officer, July 29, 2025.

OpenGraph is the closing observation of an arc that began with Phillips and Swiler in 1998: the model is the abstraction; the substrate is whatever your enterprise runs. The same shortestPath() that finds Active Directory attack paths now finds attack paths over a GitHub organisation, a Snowflake role hierarchy, or a Microsoft SQL Server login graph, with no engine change. The 2026 BloodHound release (v9.1.0, May 6, 2026, per the public release-notes index [@bloodhound-release-notes-index]) extends OpenGraph and adds incremental edge updates -- the first step toward a streaming graph rather than a snapshot.

10. Competing approaches -- BloodHound versus Microsoft versus the alternatives

In 2026 no single product covers every substrate. The field is plural.

A practitioner choosing among attack-path tools answers four questions, in order. What substrate do you need to cover? Self-host or SaaS? Snapshot or continuous? Open query language or vendor portal? The table below assembles the answers on the dimensions a 2026 practitioner actually uses.

Tool	Substrate	Engine	Query language	Deployment	Licensing	Edge weighting	ADCS coverage	Best fit
BloodHound CE 9.x	AD + Entra + AzureRM + OpenGraph	Neo4j + Postgres app DB	Cypher	Self-hosted Docker Compose	Apache-2.0	No (unweighted BFS)	Yes -- ESC1 through ESC10 + ESC8 composite	Authorised offensive testing + DIY blue team
BloodHound Enterprise	Same as CE	PostgreSQL-as-graph (in-progress migration off Neo4j)	Cypher	SaaS	Commercial	Bi-directional (Butterfly v6.3+); weighting function not public	Yes	Continuous AD/Entra attack-surface management at enterprise scale
Adalanche	AD (on-prem; LDIF or live LDAP)	In-memory Go	AQL (GQL-like)	Single Go binary	Open source	No	Yes (per README)	Offline / air-gapped analysis from LDIF
Microsoft Security Exposure Management	Defender XDR signal: identity + endpoint + multi-cloud + Entra	Proprietary	KQL + portal	SaaS	Microsoft licensing	Implicit (filter against exploitability oracle)	Indirect via MDI signals	Hybrid Microsoft-substrate unified exposure
MDI Lateral Movement Paths	On-prem AD (sensitive-account paths only)	Proprietary	None -- portal only	SaaS	Microsoft licensing	n/a	Implicit via separate MDI alerts	Default-on credential-hopping detection
Defender for Cloud CSPM attack-path analysis	Multi-cloud (Azure + AWS + GCP)	Proprietary	Cloud Security Explorer + KQL	SaaS	Microsoft licensing	Implicit	n/a	Multi-cloud workload protection
PingCastle / Semperis DSP / ADAudit Plus	On-prem AD (+ limited Entra)	None -- list-of-findings	None -- HTML / portal	Self-hosted or SaaS	Commercial / mixed	n/a	Single-finding hygiene only	Compliance auditing and change tracking

A few rows deserve commentary.

Note: BloodHound CE ships under Apache-2.0 per the current repository [@bloodhound-ce-repo]. The GPL-3.0 license you may see in older treatments applies only to the deprecated BloodHound Legacy v4 repository [@bloodhound-legacy-repo], which was last updated in 2023 and is no longer maintained. The licensing difference is material: GPL-3.0 is copyleft, Apache-2.0 is permissive. Downstream use cases that need permissive licensing should rely on the current CE.

Older blog posts and conference talks frequently call BloodHound CE GPL-3.0. The CE-Legacy LICENSE block does carry the GPL-3.0 copyright header, which is the source of the confusion. The current CE codebase at github.com/SpecterOps/BloodHound is Apache-2.0; the GPL-3.0 LICENSE applies only to the deprecated Legacy v4 repository.

Adalanche, by Lars Karlslund, is the load-bearing counter-example to the claim that "the graph model requires Neo4j" [@adalanche-repo]. Adalanche reads AD data from an LDIF dump or live LDAP, builds the graph entirely in process memory, and exposes a web GUI plus an Adalanche Query Language (AQL) -- described in the README as "a GQL-like language that allows for complex queries."

The README's headline claim is verbatim: "Adalanche gives instant results, showing you what permissions users and groups have in an Active Directory." The trade is no continuous monitoring, no multi-user web app, and a smaller community in exchange for zero deployment friction. The model is identical; the engine is replaceable.

MSEM is the closest Microsoft analogue to BloodHound (see Section 8 for substrate and query interface). Reasonable defenders run both MSEM and BloodHound (CE or Enterprise) on the same forest. The tools are complementary rather than substitutionary: MSEM brings the EDR plus workload-protection telemetry that BloodHound does not natively ingest, while BloodHound brings the precise AD edge semantics that SpecterOps's research community has validated. Running both is not double-counting.

The hygiene scanners -- PingCastle [@pingcastle], Semperis DSP [@semperis-dsp], ManageEngine ADAudit Plus [@manageengine-adaudit-plus] -- are the surviving descendants of the per-object ACL-inspection generation, with risk-scoring layered on top. They are valuable for compliance auditing and change tracking. They do not expose a queryable attack-path graph. The compliance auditor and the attack-path analyst are different personas with different tools.

If the field is plural and every tool has a gap, what is the shape of the problem that no tool yet solves? The next section is the honest answer.

11. Theoretical limits and open problems

Some of the gaps in attack-path analysis are engineering gaps. Others are not.

The single most consequential open problem is edge weighting. BloodHound's BFS treats every edge as one hop. In reality, MemberOf is effectively free; ForceChangePassword requires the attacker to log in as the changed principal afterwards; AddKeyCredentialLink requires shadow-credential infrastructure; CoerceAndRelayNTLMToADCS requires an active SMB-coercion primitive, NTLM relay tooling, and an ESC8-vulnerable certificate authority. A shortest-hop path is not in general the shortest-exploitation-cost path.

BloodHound Enterprise v6.3 shipped the Butterfly analysis as the first production attempt to relax this assumption. As the v6.3 release notes acknowledge (see Section 9), Butterfly's weighting function is not publicly documented [@bloodhound-v6-3-release].

Academic intuition suggests weighting edges by an exploitation-success probability and computing most-likely-exploited paths via shortest paths under negative-log-probability weights. The complexity ceiling is well-known: Dijkstra (with non-negative weights) runs in $O(E + V\log V)$ time with a Fibonacci heap; Bellman-Ford handles negative weights at $O(VE)$. Either fits comfortably inside the per-query budget BloodHound already operates within.

The unsolved part is the empirical calibration: what numerical weight is the right weight on a ForceChangePassword edge versus a CoerceAndRelayNTLMToADCS edge? There is no published peer-reviewed answer.

The second open problem is coverage. The TierZeroTable README is the authoritative self-disclosure: file-system ACLs on member servers, fine-grained GPO delegation, on-host service-account permissions, some Entra conditional-access logic, and cross-tenant Entra B2B trust paths remain partially or fully out of scope [@specterops-tier-zero-table]. This is an engineering problem -- more collectors, more edge definitions -- rather than an algorithmic one. OpenGraph is the structural answer: shift coverage from "what edges has SpecterOps modelled?" to "what edges has the community contributed to the shared library?" [@bloodhound-opengraph-library].

The third is graph privacy. A continuously-collected, complete AD privilege graph shipped to a third-party SaaS backend is, in adversarial hands, a pre-computed attack plan for the customer's forest. Tenant isolation, encryption at rest, SOC 2 and FedRAMP attestation, and customer-managed key encryption do not eliminate the structural risk: a compromised SaaS backend yields the customer's graph regardless of compliance posture.

Cryptographic approaches -- homomorphic graph queries, secure multi-party computation for path enumeration -- exist in the theoretical literature but are not in production attack-path products at time of writing. Adalanche and self-hosted BloodHound CE remain the privacy-preserving options at the cost of forgoing continuous monitoring.

The fourth is the the graph is alive problem. Session edges (HasSession) go stale in hours. New ACEs, new group memberships, new sessions appear continuously. SharpHound's snapshot model is yesterday's view; continuous collectors (BloodHound Enterprise, MSEM agent streams) trade stealth for freshness. The May 6, 2026 release notes describe BloodHound CE's first move toward a streaming model: "incremental edge updates that reduce unnecessary writes during post-processing" [@bloodhound-release-notes-index]. No production attack-path tool yet ships a fully streaming graph.

The fifth is combinatorial intractability. These are not engineering gaps; they are complexity-theoretic facts.

Counting all attack paths is #P-complete. Leslie Valiant's 1979 result on the complexity of counting solutions to combinatorial problems applies directly: counting the simple paths between two nodes in a general graph cannot be done in polynomial time unless P = #P [@valiant-1979-permanent]. BloodHound's path-count UI is necessarily an approximation or a length-truncation; this is the theoretical reason why.
The minimum-edge-cut "defender hardening" problem is NP-hard. Choose the smallest set of edges whose removal disconnects the attacker from the goal. Sheyner et al. 2002 proved the result is NP-hard but admits an $O(\log n)$ approximation [@sheyner-et-al-2002-attack-graphs]. BHE choke-point ranking and MSEM choke-point analysis necessarily implement heuristic approximations.
Finding regular simple paths is NP-complete. Mendelzon and Wood 1995 proved that finding a simple path matching a regular expression over edge labels in a graph database is NP-complete [@mendelzon-wood-1995-dblp]. Cypher's shortestPath() does not enforce simple-path semantics, which is why it remains in P; quantified path patterns with DIFFERENT RELATIONSHIPS semantics (available since Neo4j 5.x and documented in the current Cypher manual [@neo4j-cypher-variable-length]) do enforce simple paths and so cross into the NP-complete regime.

Key idea: BloodHound's per-query algorithm (BFS, $O(V + E)$) is optimal up to constants. The frontier of the field is no longer the algorithm. It is what question we ask the algorithm: weighted? regular-path? simple-path? bi-directional? cross-substrate? Each open question is a different model, not a different implementation.

Three further honest framings deserve a mention.

First, the standardisation of OpenGraph edge taxonomies is unsettled. Without community convergence on edge naming, different contributors may model the same substrate with incompatible schemas. Historical precedent (MITRE ATT&CK technique IDs, CVE identifiers) suggests that convergence happens when a single high-trust curator becomes the de-facto registry; whether SpecterOps will operate OpenGraph as a vendor-neutral standards body or as a SpecterOps-owned artefact is a governance question, not an algorithmic one.

Second, the adversarial robustness of the collector is an open question: SharpHound runs as an authenticated principal, and an attacker with prior compromise can poison the collection. There is no closed-form defence.

Third, the absence of any public head-to-head benchmark of BloodHound CE versus BHE versus Adalanche versus MSEM on the same forest under controlled conditions is structural: Microsoft does not publish per-query latency, SpecterOps publishes only relative improvement claims, and the academic line uses 2005-era hardware figures that are not comparable.

12. Practical guide -- running BloodHound today

If the previous sections sold you on the model, the next few paragraphs are the minimum you need to stand it up.

Stand up BloodHound CE with the Docker Compose file in the repository [@bloodhound-ce-repo]. The stack is four containers: a PostgreSQL application database (users, roles, sessions, audit logs, saved queries); a Neo4j graph database holding the property graph; a Go REST API; and a React plus Sigma.js single-page frontend. Five minutes to first boot on a developer laptop. The repository README is the authoritative deployment reference.

Run SharpHound on a domain-joined Windows host as the collection identity. The default invocation -- SharpHound.exe --CollectionMethods all,GPOLocalGroup -- enumerates every group membership, every recognised ACL pattern, every active session, every local-admin relationship, and every Kerberos delegation. Run AzureHound with appropriate Entra ID credentials for Entra and AzureRM coverage. Both emit JSON dumps in the same envelope; the BloodHound CE upload tab in the web UI ingests both.

Open the web UI. The stock pre-built queries are a reasonable starting palette: Find Shortest Paths to Domain Admins, Find Principals with DCSync Rights, Find Computers with Unsupported Operating Systems, and Shortest Paths from Owned Principals to High-Value Targets (after marking some accounts as owned). Custom Cypher goes in the Cypher tab at the top right; the Section 6 query is a good template.

The most important interpretation discipline: treat the result as a risk register, not a vulnerability list. A finding is "Bob can reach Domain Admins via a four-hop path." The edge is "Bob has GenericWrite on Carol." Closing the edge breaks the finding and every other path that passed through it. Edges are the unit of remediation, not findings. SpecterOps's own 2021 customer-anonymous essay Active Directory Attack Paths -- Is It Always This Bad? reports findings from hundreds of engagements, and the recurring observation across forests is that a small number of high-blast-radius edges explain most of the discovered paths [@specterops-2021-ad-attack-paths].

A few pitfalls are worth naming. HasSession collection generates measurable LDAP and SAMR traffic that Microsoft Defender for Identity alerts on; coordinate with the blue team or expect detections. The stealth collection mode trades coverage for traffic volume.

Unconstrained variable-length Cypher queries (MATCH p=(a)-[*]->(b)) can pin Neo4j's heap; CE's "protected Cypher" cost limits help but do not eliminate the problem, so prefer shortestPath() or bound the path length explicitly. The wildcard-principal post-processing for Authenticated Users and Everyone requires v6.0 or later to be correct; older versions miscount these edges [@bloodhound-v6-0-release]. And the CoerceAndRelayNTLMToADCS edge is Group to Computer, not Computer to Computer, as discussed in Section 7.

```cypher MATCH (n) WHERE n.system_tags CONTAINS 'admin_tier_0' WITH collect(n) AS tier_zero MATCH p = shortestPath((u:User {enabled:true})-[*1..6]->(t)) WHERE t IN tier_zero AND NOT u.system_tags CONTAINS 'admin_tier_0' RETURN u.name AS source, t.name AS target, length(p) AS hops ORDER BY hops ASC LIMIT 25 ```

This returns up to 25 enabled non-Tier-Zero users with the shortest paths into Tier Zero. The [*1..6] bound prevents the pathological cyclic-graph cost explosion. Bound length aggressively until you have indexed your graph.

BloodHound is dual-use. Authorised defensive use on your own forest, or contracted penetration testing within written scope, is the standard legal posture. Running it against a directory you are not authorised to assess is unlawful in most jurisdictions: the Computer Fraud and Abuse Act in the United States; the Computer Misuse Act 1990 in the United Kingdom; equivalents in most EU jurisdictions. The dual-use posture is fundamental to the tool; the legal posture depends on you.

The tool is the easy part. The hard part is what you do with the answer.

13. Frequently asked questions

The misconceptions worth disposing of, in order of how often they recur.

No. BloodHound is the SpecterOps-maintained, evolving set of edge families. File-system ACLs on member servers, fine-grained GPO delegation, on-host service-account permissions, and some Entra conditional-access logic remain partially or fully out of scope. The `SpecterOps/TierZeroTable` README is explicit about this limitation [@specterops-tier-zero-table]. Coverage expansion is iterative and community-fed; OpenGraph is the structural answer to scope generalisation. The original BloodHound (2016) shipped Neo4j only. The modern BloodHound CE uses *both*: PostgreSQL as the application database (users, roles, sessions, audit logs) and Neo4j as the graph layer [@bloodhound-ce-repo]. BloodHound Enterprise has begun migrating entirely off Neo4j onto PostgreSQL-as-graph (announced in v6.3, December 2024) [@bloodhound-v6-3-release]; Cypher continues to be the query language on the new backend. The model is engine-independent; Adalanche proves the same point by doing it all in process memory in Go [@adalanche-repo]. Authorised defensive use on your own forest, yes. Contracted penetration testing within written scope, yes. Running it against a directory you are not authorised to assess is unlawful in most jurisdictions: the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act 1990 in the United Kingdom, and equivalents in most EU jurisdictions. The dual-use posture is fundamental to the tool; legal compliance is the operator's responsibility.

Epilogue

The 2014 analyst with the whiteboard and the 2024 analyst with the Cypher query are doing the same work. The unit of analysis has shifted, and once the unit shifts, the field does not go back.

John Lambert diagnosed it in two sentences in April 2015 [@lambert-2015-defenders-lists-attackers-graphs]. Andy Robbins, Rohan Vazarkar, and Will Schroeder shipped it as BloodHound in August 2016 [@bloodhound-legacy-repo]. SpecterOps extended it through AzureHound in 2020, the CE 5.0 web architecture in 2023, the Tier Zero formalisation in 2023, ADCS composed edges in 2024, Butterfly bi-directional analysis in 2024, and OpenGraph in 2025 [@specterops-2025-opengraph].

Microsoft validated the model with Lateral Movement Paths in 2018, cloud security graph attack-path analysis in 2022 to 2023, and Microsoft Security Exposure Management at Ignite in 2024 [@ms-msem-attack-paths]. The community that shipped the graph won; the community that kept shipping lists is selling compliance reports to the auditors.

The frontier in 2026 is not whether to model attacks as a graph -- that argument is settled. The frontier is how to make the graph weighted (so the shortest path approximates the easiest), how to make it complete (so the unmodelled edges shrink toward zero), and how to make it substrate-independent (so the next enterprise primitive worth modelling -- whatever it turns out to be -- can be ingested without changing the engine). Each of these is a research direction with its own asymptotic ceiling, its own engineering practice, and its own community of contributors.

What started as a sentence in a 1,100-word essay on a personal GitHub repository is now an ISO-standardised query language [@iso-39075-2024-gql], a shipped Microsoft product family, an open-source repository with hundreds of thousands of downloads, and a discipline taught at most major security conferences. The graph wins because the graph is the right model. The right model wins because, eventually, the right model always does.

Certified Pre-Owned: AD CS and Active Directory's Second Trust Root

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

**Microsoft Certificate Services shipped in Windows 2000 Server on February 17, 2000 and was renamed Active Directory Certificate Services in Windows Server 2008.** Its misconfigurations remained admin-tunable knobs without numbered names for twenty-one years. In June 2021, Will Schroeder and Lee Christensen at SpecterOps published *Certified Pre-Owned* and named eight of them ESC1 through ESC8. Through 2025 the community extended the catalog to ESC16 across IFCR, Compass Security, SpecterOps, TrustedSec, and independent researchers, each one abusing one of six primitives: the template, the issuing authority, the transport, the mapping, the authentication step, or the persistence substrate. Two ESCs have cleanly received CVE-class Microsoft patches (EKUwu / ESC15 -> CVE-2024-49019; ESC8 received KB5005413 *hardening guidance* rather than a CVE, and the adjacent Certifried CVE-2022-26923 patches the dNSHostName impersonation chain on the Machine template rather than a numbered ESC); the rest are administrative hardening matters per Microsoft's Windows Security Servicing Criteria. The KB5014754 strong-mapping rollout closed ESC9 and ESC10 but is bypassed by ESC16. The architectural property -- that every CA in NTAuth is a key parallel to krbtgt that can mint a Domain Admin authenticator -- is not closable by any patch. The operational playbook is to run Locksmith, BloodHound CE, MDI, PSPKIAudit, and Certipy in parallel, ingest CA logs, and prepare a Lane-3 CA rebuild before you need it.

1. Two Hours, No KRBTGT, No Touch on Tier Zero

The operator's stopwatch reads two hours and seven minutes when the SOCKS proxy lights up with a Ticket-Granting Ticket for the Domain Administrator account. No service was crashed. No LSASS process was touched. No Tier-Zero principal had its password reset. The krbtgt account hash from last quarter's rotation is still good. The certificate that minted the ticket was issued, signed, and logged by the enterprise's own Certificate Authority -- the one the IT director's slide deck calls "internal PKI" -- against a template the help desk uses to enroll Wi-Fi clients.

Walk the chain backwards. The operator joined Domain Users four hours ago via a phishing payload that never escalated past medium integrity. They ran one tool. Certipy find enumerated every certificate template the foothold account was permitted to enroll in [@certipy-gh]. One of those templates -- call it WiFi-Auth -- had three properties: low-privilege enrollment open to Authenticated Users, the Client Authentication Extended Key Usage attached, and the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit flipped on. Certipy req produced a Certificate Signing Request that supplied DOMAIN\Administrator as the Subject Alternative Name. The Enterprise CA, doing exactly what its template configured it to do, issued the certificate. Certipy auth -pfx exchanged the certificate for a TGT via the Public Key Cryptography for Initial Authentication extension to Kerberos. Mimikatz ptt loaded the TGT into the operator's session. Domain Admin.

What did not fire is the part that frustrates the incident response team. There was no Windows Event 4624 for the Administrator account anywhere on the domain. Microsoft Defender for Identity raised no lateral-movement alert. No Pass-the-Ticket detection triggered, because the ticket was minted as fresh PKINIT authentication, not replayed. The only artifact in the entire chain was a single Event ID 4886 in the CA's issuance log -- the event the SOC's SIEM does not ingest, because the SOC's SIEM was built to follow krbtgt and not to follow PKI.

RFC 4556's Public Key Cryptography for Initial Authentication in Kerberos. The protocol extension that lets a Kerberos client present a certificate to a Key Distribution Center and receive a Ticket-Granting Ticket in return. Authored by L. Zhu (Microsoft) and B. Tung (Aerospace), published in June 2006 [@rfc4556]. PKINIT is the authentication step that converts an issued certificate into a TGT, and therefore the step every ESC must cross to convert a misconfigured template into Domain Admin.

The TGT in this scenario is produced by Active Directory's Key Distribution Center after it validates the certificate against its trusted certificate stores. The KDC does not call back to the CA -- it trusts any certificate signed by a CA published into the forest's NTAuthCertificates container. That trust relationship is the load-bearing detail; we will return to it in section eight.

So how is any of this possible? The operator's organization rotated krbtgt twice last quarter, runs a top-quartile EDR product, and bought Microsoft Defender for Identity with the AD CS sensor add-on. The simple answer is: rotating krbtgt closes one of the keys that can mint a Domain Admin authenticator in this forest. It does not close the others. The forest has more than one such key, and nobody told the IR plan.

Key idea: Every domain whose CA can issue authentication certificates has two trust roots that can mint a Domain Admin authenticator, not one. The first is the krbtgt account hash. The second is the private key of any Certificate Authority published into the forest's NTAuthCertificates container. Rotating one does not touch the other. The catalog this article walks through is the community's attempt to enumerate the misconfigurations that turn the second trust root into a path low-privilege users can walk.

The vocabulary for this surface -- the named techniques, the numbered identifiers, the tool that enumerates them in eleven seconds -- did not exist until June 2021. The misconfigurations did. They had been shipping as customer-tunable knobs in Microsoft's identity stack since Windows Server 2003. If this surface has been available for twenty-one years, why did it take twenty-one years for someone to give the misconfigurations names?

2. Twenty-One Years of Unnamed Knobs

February 17, 2000. Windows 2000 Server reaches general availability. Microsoft Certificate Services -- the AD-integrated CA role -- ships as an optional server component on day one [@wikipedia-w2k]. The role is not yet called Active Directory Certificate Services; that rename arrives with Windows Server 2008. The shipping defaults that the operator in section one just exploited were already buildable on the 2000 release.

You will see both anchor dates in the literature. Semperis's CVE-2022-26923 retrospective writes that "In Windows Server 2008, Microsoft introduced AD CS" [@semperis-cve]. The Microsoft Learn current overview describes AD CS as a "Windows Server role for issuing and managing public key infrastructure (PKI) certificates" [@msl-adcs-current] without distinguishing the ship date from the rename date. This article uses the dual anchor: the role *shipped* in 2000 as Microsoft Certificate Services, and was *renamed* Active Directory Certificate Services in 2008. The misconfigurations the ESC catalog enumerates were enabled by Windows Server 2003's V2 templates and have not been default-off since.

The misconfigurations the catalog later attacks did not all arrive at once. Three Microsoft releases between 2000 and 2008 built the surface piece by piece.

Windows Server 2003 (general availability April 24, 2003 [@wikipedia-ws2003]) shipped Version 2 (V2) certificate templates, user and computer autoenrollment over the V2 schema, and the AD-stored template store [@msl-ws2003-ca]. Most of the surface ESC1 and ESC4 later attack first appears in this release: msPKI-Certificate-Name-Flag, the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit, per-template DACLs editable in Active Directory Sites and Services, and the modifiable Extended Key Usage list. The Enrollee-Supplies-Subject flag, in particular, is a customer-tunable bit; it ships off by default on the stock templates but is a one-click enable in certtmpl.msc [@msl-adcs-2012r2]. Microsoft's documentation warned against it on sensitive templates. It did not warn against it as a numbered identifier.

Certificate templates have version numbers tied to the Active Directory schema. V1 templates ship with Windows 2000 and are non-modifiable from the GUI. V2 templates ship with Windows Server 2003 and are fully modifiable; they introduce the per-template DACL and the editable msPKI-Certificate-Name-Flag properties the catalog attacks. V3 templates ship with Windows Server 2008 and add Suite B cryptography support. The catalog mostly attacks V2 templates; ESC15 specifically attacks the residual V1 templates that ship pre-installed and cannot be removed.

Windows Server 2008 (general availability February 27, 2008 [@wikipedia-ws2008]) renamed the role to Active Directory Certificate Services and added new role services: Online Certificate Status Protocol Responder, Network Device Enrollment Service, Certificate Enrollment Web Service, and Certificate Enrollment Policy Web Service. These role services expanded the transport surface that ESC8 and ESC11 later attack. The Windows Server 2012 R2 documentation page hh831740 became the canonical reference SpecterOps later linked from the 2021 paper [@msl-adcs-2012r2].

Between 2008 and 2021 Microsoft published hardening guidance for AD CS in several places -- Test Lab Guides, PKI design pages, role-service deployment docs [@msl-pki-design]. The guidance covered template ACLs, manager approval, least-privilege enrollment, and the Enrollee-Supplies-Subject bit. It did not assign numbered identifiers to specific dangerous combinations. It did not appear in MSRC's vulnerability pipeline. It did not get a Common Vulnerabilities and Exposures registration. The configurations were documented but unnamed.

In 2019, two seeds for the named class appeared. Géraud de Drouas at the French ANSSI published a brief GitHub note that the Active Directory Public-Information property set includes altSecurityIdentities, which lets an attacker with that permission map their own certificate onto a privileged user [@dedrouas-altsec]. The note ends with a striking line: "This issue has been responsibly disclosed to MSRC and received a 'won't fix' response." The same year Microsoft began documenting the szOID_NTDS_CA_SECURITY_EXT extension in certificate-related KBs, though without making it default-on. The substrate for what would become ESC9, ESC10, and ESC14 was already in place; nobody had named it yet.

Twenty-one years from the role's ship date, then. Twenty-one years of admin-tunable knobs. No numbered identifiers, no patch cadence, no scanner enumeration, no MSRC pipeline. Microsoft documented every one of these settings individually, often well; what was missing was the catalog. Hardening guidance without numbered identifiers produces no defensive prioritization in real enterprises, because enterprise security programs prioritize against catalogs, not against documentation pages [@bollinger-ekuwu]. So what happened in June 2021 that turned a documentation pattern into a catalog?

flowchart LR A[2000
Microsoft Certificate Services
ships in Windows 2000 Server] --> B[2003
V2 templates
and autoenrollment] B --> C[2008
Role renamed
Active Directory
Certificate Services] C --> D[2019
de Drouas notes
altSecurityIdentities abuse] D --> E[June 2021
SpecterOps catalog
ESC1 through ESC8] E --> F[2021 to 2022
KB5005413
CVE-2022-26923
KB5014754] F --> G[2022 to 2023
ESC9 to ESC12
from Lyak Heiniger Knobloch] G --> H[2024
ESC13 to ESC15
Knudsen and Bollinger
CVE-2024-49019] H --> I[2025
ESC16
strong-mapping full enforcement]

3. Six Primitives Every ESC Abuses

Before opening the catalog, install the vocabulary. Every ESC -- without exception -- abuses one of six primitives: the template, the issuing authority, the enrollment transport, the certificate mapping, the authentication bridge, and the persistence substrate. Once you have these six names in your head, the sixteen ESCs compose into a small grid.

The Template

A certificate template is an Active Directory object stored in the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration partition that tells an Enterprise CA what kind of certificate to issue and to whom. Templates carry their own DACL controlling who can enroll, who can write, and who can autoenroll. They carry a msPKI-Certificate-Name-Flag attribute whose bits control how the Subject and Subject Alternative Name fields are populated. They carry an Extended Key Usage list that names what the certificate is permitted to do. And they carry a Manager Approval bit that gates whether issuance is automatic or whether a CA officer must approve each request [@msl-adcs-2012r2].

The Active Directory-stored object specifying who can request what kind of certificate from an Enterprise CA. Templates carry per-object DACLs (enrollment, autoenrollment, write), a `msPKI-Certificate-Name-Flag` controlling Subject and SAN behavior, an Extended Key Usage list, and a Manager Approval bit. V1 templates (Windows 2000) are non-modifiable; V2 templates (Windows Server 2003) are fully modifiable; V3 templates (Windows Server 2008) add Suite B cryptography.

ESC1, ESC2, ESC3, ESC4, and ESC15 all attack the template. They differ only in which template property is misconfigured. (ESC9 also begins on a template flag, CT_FLAG_NO_SECURITY_EXTENSION, but its effect lives in the mapping layer; we file it under mapping below, matching SpecterOps's own Certify taxonomy [@specterops-certify-docs-index].)

The Issuing Authority

An Enterprise CA is a Windows Server role service that signs certificate requests against published templates. To be trusted for authentication, the CA must be published into the forest's NTAuthCertificates container. That container is the single list of CA certificates the Key Distribution Center trusts for PKINIT. The CA carries its own security descriptor controlling who can enroll, who can manage certificates, and who can manage the CA itself. It carries two registry flags that change its issuance behavior: EDITF_ATTRIBUTESUBJECTALTNAME2, which permits requesters to specify arbitrary Subject Alternative Names, and IF_ENFORCEENCRYPTICERTREQUEST, which controls whether RPC enrollment requires packet privacy [@compass-esc11]. The 2022 KB5014754 patch introduced szOID_NTDS_CA_SECURITY_EXT, a Microsoft-specific extension carrying the requester's Security Identifier; that extension is the load-bearing artifact of the strong-mapping enforcement track [@kb5014754].

The AD-integrated certificate authority role in AD CS. Publishes certificate templates into Active Directory, processes certificate requests against those templates, and signs issued certificates with its private key. To be trusted for Windows authentication, the CA's certificate must be present in the forest-wide `NTAuthCertificates` container. The AD-published container `CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration` listing CA certificates trusted by the Key Distribution Center for client authentication. Any certificate signed by a CA in this container can, given a valid mapping, mint a Kerberos Ticket-Granting Ticket. Publishing a CA into NTAuth is the moment that CA's private key becomes a trust root parallel to krbtgt.

ESC5, ESC6, ESC7, and ESC16 attack the issuing authority itself -- its DACL, its registry flags, its extension policy. (ESC11's RPC packet-privacy gap is a CA-side configuration, but its abuse is an NTLM relay; we group it with ESC8 under transport, matching the §5 diagram.)

The Enrollment Transport

A certificate is requested over a network protocol. The default transport is DCOM/MS-WCCE -- the Windows Client Certificate Enrollment protocol, an RPC-based interface that ships enabled on every Enterprise CA [@ms-icpr-spec]. Additional transports ship as separate role services: HTTP Web Enrollment (IIS-based, with NTLM auth by default), the Certificate Enrollment Web Service (web service, supports basic and Kerberos), the Network Device Enrollment Service (the SCEP gateway), and the Certificate Enrollment Policy Web Service. Each transport is a network attack surface for relay primitives that route a coerced NTLM authentication into a certificate request.

ESC8 attacks the HTTP Web Enrollment transport. ESC11 attacks the RPC transport. Both are NTLM-relay attacks; they differ only in which transport the relayed authentication targets.

The CA's security model distinguishes two rights that look similar but differ in scope. Issue and Manage Certificates permits the holder to approve pending requests, revoke issued certificates, and read the request store. Manage CA permits the holder to edit the CA's own configuration -- including its registry-controlled extension policy and its DACL. ESC7 attacks the latter. The escalation chain that follows ESC7 typically pivots to ESC4 (edit a template) or to issuing a certificate directly via a CA officer's request-approval right.

The Certificate Mapping

When a CA issues an authentication certificate, the certificate identifies a principal -- a user or a computer. The Key Distribution Center has to decide which Active Directory principal that certificate represents. Two mappings exist. Implicit mapping reads the Subject Alternative Name (or the Subject, on older templates) and looks up the principal by User Principal Name. Explicit mapping reads the AD principal's own altSecurityIdentities attribute, which holds one or more X.509 issuer/serial expressions [@dedrouas-altsec]. The May 2022 KB5014754 patch redefined which mappings the KDC accepts: explicit mappings using X509IssuerSerialNumber, X509SKI, or X509SHA1PublicKey are strong; everything else is weak and will be rejected once Full Enforcement is active [@kb5014754].

OID 1.3.6.1.4.1.311.25.2. The Microsoft certificate extension introduced by KB5014754 that embeds the SID of the requesting Active Directory principal directly into the issued certificate. When present, the KDC matches the certificate against the principal whose SID is embedded, defeating SAN-supply attacks like ESC1. The extension is the load-bearing mechanism of strong mapping enforcement. Per KB5014754, explicit `altSecurityIdentities` entries using the `X509IssuerSerialNumber`, `X509SKI`, or `X509SHA1PublicKey` formats are *strong*. All other formats -- including implicit UPN and SAN matching -- are *weak* and rejected once Full Enforcement mode is active (February 11, 2025 default; legacy-mapping registry override removed September 9, 2025) [@kb5014754]. The strong-mapping track was the single largest Microsoft mitigation of the ESC era.

ESC9, ESC10, ESC13, and ESC14 all attack the mapping. They abuse the gap between what a certificate asserts and which AD principal the KDC binds it to.

The Authentication Step

This component is the part of Windows that turns a certificate into an authenticator. For Kerberos, the protocol is PKINIT (RFC 4556 [@rfc4556]): client presents a cert, KDC validates the cert and the mapping, KDC issues a TGT. For TLS-based services -- LDAPS, RDP with smart card, IIS with client cert -- the protocol is Schannel. For the legacy smart-card pipeline, the path is the combination of the Smart Card Resource Manager and PKINIT.

No ESC attacks this step directly. Every ESC must cross it to convert a misconfigured template, ACL, or mapping into a usable authenticator. The authentication step is the choke point; it is also the point Microsoft has reshaped most heavily with KB5014754.

The Persistence Substrate

An issued certificate is not a transient credential. It is a signed authenticator with a configurable validity period (one year is common, ten years is permitted). The certificate authenticates the embedded principal as long as the certificate is valid and not revoked. That property is what the SpecterOps paper's DPERSIST and THEFT classes attack [@cpo-blog]. UnPAC-the-Hash recovers the NTLM hash from a PKINIT-issued TGT, giving the attacker a password-equivalent credential they did not previously have. The Golden Certificate attack steals the CA's own private key, granting forever-issuance against the entire forest.

This article scopes those attacks to a sidebar; the body walks the ESC1 to ESC16 escalation catalog. But every ESC ends in the persistence substrate: the certificate the attacker walks out with is the receipt that survives password rotation.

Note: A primitive is a Microsoft-shipped knob, flag, ACL, or protocol that, when misconfigured, becomes part of an escalation. An exploitation chain is the specific sequence of operator actions that turns one or more misconfigured primitives into a Domain Admin authenticator. ESCs are exploitation chains, not primitives. ESC1, for example, abuses the template primitive's CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit, combined with the bridge primitive (PKINIT), to produce the authenticator. The catalog enumerates chains; the six categories above enumerate the substrate.

Now that the vocabulary is in place, sixteen named attacks compose neatly onto a 6 by 16 grid. Here is the moment they did.

flowchart TD T[Template
per-template DACL
Name-Flag bits
EKU list
Manager Approval] A[Issuing Authority
NTAuth membership
CA security descriptor
EDITF flags
extension policy] X[Enrollment Transport
RPC/MS-WCCE
HTTP Web Enrollment
CES/CEP
NDES/SCEP] M[Certificate Mapping
implicit UPN/SAN
explicit altSecurityIdentities
strong vs weak
SID extension] B[Authentication Bridge
PKINIT for Kerberos
Schannel for TLS
smart-card pipeline] P[Persistence Substrate
validity period
UnPAC-the-Hash
Golden Certificate
CRL bypass] T --> A A --> X X --> B A --> M M --> B B --> P

4. Certified Pre-Owned

Will Schroeder pushes the SpecterOps Medium post live on June 17, 2021. (A revision tagged [EDIT 06/22/21] follows the next week; the literature settles on "June 2021" as the canonical date [@cpo-blog].) The whitepaper PDF drops in the same window and is rehosted on the SpecterOps domain the following year [@cpo-whitepaper]. Seven weeks later, on August 5, Schroeder and Christensen present Certified Pre-Owned: Abusing Active Directory Certificate Services at Black Hat USA 2021. Three GhostPack tools ship to GitHub on schedule: PSPKIAudit for defense [@pspkiaudit-gh], Certify for offense [@certify-gh], and ForgeCert for Golden Certificate work.

The paper names eight escalation paths and three persistence and theft prefixes:

ESC1 through ESC8 -- escalation paths from a low-privilege foothold to Domain Admin
DPERSIST -- domain persistence via forged certificates after CA private-key compromise
THEFT -- certificate and credential theft primitives, including the UnPAC-the-Hash technique
DETECT -- defensive detection primitives the team mapped to each abuse

The contribution was not the discovery of new individual primitives. Most of the individual misconfigurations had appeared in Microsoft's hardening guidance or in scattered community posts well before the paper. ENROLLEE_SUPPLIES_SUBJECT had been a documented warning for a decade. NTLM relay to IIS had been a known attack class since at least 2008. The EDITF_ATTRIBUTESUBJECTALTNAME2 flag was a documented option in certutil since Windows Server 2008 R2. What the paper contributed was the unified catalog -- numbered identifiers, reproducible exploitation, a tool that enumerated each path, and a single document tying every abuse to its primitive and its mitigation.

While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous. -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* (June 2021) [@cpo-blog]

Microsoft's response was uncharacteristically fast. KB5005413 published in late July 2021 -- roughly six weeks after the blog -- recommending Extended Protection for Authentication and "Require SSL" on the AD CS Web Enrollment and Certificate Enrollment Web Service role services [@kb5005413]. The KB closes ESC8 over HTTPS when EPA is enabled. It does not close ESC1 through ESC7, and it does not close ESC11 (which had not yet been named).

The "ESC" prefix is an acronym for escalation. The catalog uses three sibling prefixes from the same paper: DPERSIST for domain persistence, THEFT for credential and certificate theft, and DETECT for defensive detection identifiers. ESC numbering is consecutive but not contiguous in time -- ESC12 (a hardware substrate attack) was disclosed by Knobloch in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive], four months before Knudsen disclosed ESC13 and ESC14 from SpecterOps. The numbering tracks the order of community disclosure, not a planned roadmap.

Here is the observation that this article will load-bear: the breakthrough was naming, not discovery. Until SpecterOps named the eight configurations, every one of them had been documented somewhere in Microsoft Learn or in a community blog. The hardening documentation had existed for years and had produced essentially no defensive prioritization in real enterprises. Microsoft Defender for Identity did not flag ESC1 templates. BloodHound did not graph ESC4-shaped DACLs. SIEMs did not ingest CA Event ID 4886. No commercial scanner shipped a rule for the Enrollee-Supplies-Subject bit. The reason was not that the information was inaccessible. The reason was that the configurations had no names -- and an enterprise security program cannot prioritize against an unnamed configuration.

Key idea: Naming is itself a defensive primitive. The 2021 SpecterOps catalog converted twenty-one years of unnamed admin-tunable knobs into a numbered backlog that scanners could enumerate, BloodHound could path-find, MSRC could patch, and operators could prioritize. Every subsequent mitigation generation -- KB5005413, CVE-2022-26923, KB5014754, CVE-2024-49019, BloodHound CE ADCS edges, Locksmith, Microsoft Defender for Identity's posture assessments -- builds on the catalog rather than on the underlying hardening documentation. The catalog is the security primitive; the patches are downstream of the catalog.

Eight ESCs in 2021. Within fifteen months, two researchers extended the catalog past the original boundary: Oliver Lyak at the Institute For Cyber Risk added ESC9 and ESC10 in August 2022 [@lyak-certipy-4-archive]; Sylvain Heiniger at Compass Security added ESC11 in November 2022 [@compass-esc11]. Hans-Joachim Knobloch added ESC12 in October 2023 [@knobloch-esc12]. SpecterOps's Jonas Bülow Knudsen added ESC13 in February 2024 [@knudsen-esc13] and ESC14 two weeks later [@knudsen-esc14]. Justin Bollinger at TrustedSec added ESC15 in October 2024 [@bollinger-ekuwu]. Lyak named ESC16 in 2025 against a workaround Schroeder himself had documented in 2022 [@specterops-esc16-docs]. Sixteen ESCs by the time you read this. Here is what each one does.

5. The Catalog: ESC-1 through ESC-16

Of the sixteen named ESCs, the original eight name the surface; ESC9 through ESC16 name the residual after every Microsoft mitigation shipped to date. We walk them in primitive-grouped order, following the same taxonomy the SpecterOps Certify documentation uses: template misconfigurations, access-control vulnerabilities, CA configuration issues, certificate mapping issues, and one hardware-substrate sidebar [@specterops-certify-docs-index].

Template misconfigurations: ESC1, ESC2, ESC3

ESC1 -- Misconfigured Certificate Template. A V2 template that lets a low-privilege principal enroll, has Client Authentication in its Extended Key Usage list, has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set, and does not require Manager Approval. The attacker requests a certificate naming the target principal in the Subject Alternative Name; the CA issues; the certificate maps via UPN to the target; PKINIT produces a TGT as the target. One operator chain: certipy req -u user -p pass -ca CA -template VulnTemplate -upn administrator@domain.local. First disclosed by SpecterOps in June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC1 [@bh-esc1-edge].

The `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit in `msPKI-Certificate-Name-Flag`. When set, the requester is allowed to supply the Subject or Subject Alternative Name in the CSR rather than having the CA build the Subject from the requester's own AD attributes. This is the load-bearing primitive of ESC1. ```powershell Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Filter * -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag | Where-Object { ($_.'msPKI-Certificate-Name-Flag' -band 0x1) -ne 0 -and ($_.'msPKI-Enrollment-Flag' -band 0x2) -eq 0 -and ($_.pKIExtendedKeyUsage -contains '1.3.6.1.5.5.7.3.2') } | Select-Object Name ``` The query lists templates with ESS set, no manager approval, and Client Authentication EKU. Locksmith, PSPKIAudit, and Certipy all run a logically equivalent check; this is the smallest reproducible form for an audit script that does not depend on a vendor tool.

ESC2 -- Any-Purpose or Subordinate CA EKU. A template that grants the Any-Purpose EKU (2.5.29.37.0) or the Subordinate CA EKU permits the certificate to be used for arbitrary purposes, including subordinate CA work. The attacker enrolls and then forges new certificates against the issued certificate's keypair. First disclosed by SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse pattern lives in Certify and Certipy [@certipy-wiki-priv].

ESC3 -- Enrollment Agent Template. A template with the Certificate Request Agent EKU lets the holder enroll certificates on behalf of other users. Combined with a second template flagged "Enrollment Agent" the attacker can request a certificate naming any principal. The chain is two requests rather than one. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC3.

Access-control vulnerabilities: ESC4, ESC5, ESC7

ESC4 -- Vulnerable Certificate Template ACL. Any principal with GenericAll, GenericWrite, WriteOwner, or WriteDacl on a template can modify the template into an ESC1-shaped configuration and then enroll. This converts a write right on a template object into Domain Admin. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC4.The ADCSESC4 edge composes with BloodHound's general DACL graph, so a Domain Users principal that holds WriteDacl on a sensitive template inherits the path automatically without a hand-written query. The edge composes naturally with the rest of BloodHound's principal-DACL graph -- a Domain Users principal with WriteDacl on the template inherits the path.

ESC5 -- Vulnerable PKI Object ACL. The same class of write rights on the CA computer object, the NTAuthCertificates container, or the AIA container. Compromising any of these gates the entire AD CS substrate. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge today; the surface is wide and the operator chain depends on the specific object compromised.

ESC7 -- Vulnerable CA ACL. A principal with the Manage CA right on the Enterprise CA can edit its registry-controlled configuration (including the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, which converts the CA into a global ESC6 condition). A principal with Issue and Manage Certificates can approve their own otherwise-blocked certificate requests. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse is a CA-side write rather than an AD principal-graph relationship.

CA configuration issues: ESC6, ESC8, ESC11

ESC6 -- EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA. When this CA-wide flag is set, every certificate request can specify an arbitrary Subject Alternative Name regardless of the template's Name-Flag bits. The CA becomes globally ESC1-shaped against any template the attacker can enroll into. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edges: ADCSESC6a and ADCSESC6b (the latter for cases where the CA also disables the SID extension).

ESC8 -- NTLM Relay to AD CS HTTP Web Enrollment. The AD CS Web Enrollment role service ships with NTLM authentication enabled and, by default, no Extended Protection for Authentication. An attacker who can coerce a target computer to authenticate (PetitPotam, PrinterBug, DFSCoerce) can relay that authentication to the CA's /certsrv/ endpoint, request a certificate naming the relayed principal, and walk away with a certificate impersonating the coerced computer -- including Domain Controllers. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE graphs this as the CoerceAndRelayNTLMToADCS edge [@bh-coerce-adcs-edge]: a Group-to-Computer edge whose source is Authenticated Users and whose destination is the coerced target computer, with the edge's evaluation conditioned on at least one ESC8-vulnerable Web Enrollment endpoint being reachable on the network.

Note: ESC8 needs no template misconfiguration. It needs a CA with HTTP Web Enrollment role service installed -- common in environments that ever provisioned smart cards or did web-based renewal -- and at least one computer account the attacker can coerce. Microsoft mitigated it with KB5005413 in July 2021 [@kb5005413], but the mitigation is configuration guidance (EPA on, "Require SSL" on, Web Enrollment disabled if unused), not a binary patch. Environments that never enabled EPA on /certsrv/ remain exploitable today. The "Domain Users to Domain Admin in eight minutes" demos that pepper conference talks are usually ESC8 demos.

ESC11 -- NTLM Relay to ICPR/RPC. The ICertPassage RPC interface (the default enrollment transport on every Enterprise CA) enforces packet privacy when the IF_ENFORCEENCRYPTICERTREQUEST flag is set; that flag has been on by default since Windows Server 2012. However, because the flag breaks certificate enrollment for legacy Windows XP clients, Compass Security observed real-world environments where administrators had explicitly removed the flag for compatibility, leaving the RPC enrollment surface unencrypted. When packet privacy is not enforced, an attacker can relay a coerced NTLM authentication into the CA's RPC interface and obtain a certificate impersonating the coerced principal. Disclosed by Sylvain Heiniger at Compass Security, November 2022 [@compass-esc11]. The SpecterOps Certify documentation describes the misconfiguration as "an insufficiently protected certificate authority RPC interface" [@specterops-esc11-docs]. No BloodHound CE edge; the RPC transport is below the principal-graph model.

Certificate mapping issues: ESC9, ESC10, ESC13, ESC14, ESC15, ESC16

ESC9 -- No Security Extension. A template flagged CT_FLAG_NO_SECURITY_EXTENSION instructs the CA to issue certificates without the szOID_NTDS_CA_SECURITY_EXT SID embedding. KB5014754's strong-mapping enforcement then falls back to weak UPN mapping, and the attacker can rename a controlled user account to match a privileged user's UPN, enroll, and authenticate as that privileged user. Disclosed by Oliver Lyak at IFCR on August 4, 2022, twelve weeks after KB5014754 [@lyak-certipy-4-archive]. BloodHound CE edges: ADCSESC9a and ADCSESC9b.

ESC10 -- Weak Certificate Mapping. The registry values StrongCertificateBindingEnforcement (on KDCs) and CertificateMappingMethods (on Schannel servers) control whether weak mappings are accepted. In Compatibility mode (the KB5014754 staged-rollout default through February 11, 2025), weak mappings still pass. An attacker who can write altSecurityIdentities on a target, or who can engineer a weak UPN match, authenticates as the target. Same disclosure: Lyak, August 4, 2022 [@lyak-certipy-4-archive]. BloodHound CE edges: ADCSESC10a and ADCSESC10b.

ESC13 -- Issuance Policy linked to AD Group via msDS-OIDToGroupLink. Active Directory issuance-policy OIDs can be linked to a security group via the msDS-OIDToGroupLink attribute. When a certificate carries that issuance-policy OID, the issued PAC includes the linked group. A template configured with such an issuance policy effectively grants its enrollees membership in the linked group at authentication time. Disclosed by Jonas Bülow Knudsen at SpecterOps on February 14, 2024; discovery credit goes to Adam Burford, who brought the technique to Knudsen and Stephen Hinck [@knudsen-esc13]. BloodHound CE edge: ADCSESC13.

ESC14 -- Explicit altSecurityIdentities Write. A principal with write access to a privileged user's altSecurityIdentities attribute can add their own certificate's X.509 expression to that attribute, then authenticate as the privileged user. The prior art goes back to Géraud de Drouas in 2019 [@dedrouas-altsec] and Jean Marsault at Wavestone in June 2021 [@marsault-wavestone]; Knudsen catalogued it as ESC14 in February 2024 [@knudsen-esc14]. No BloodHound CE edge today; the abuse traces through a write right on a single AD attribute and is in scope for future BloodHound coverage.

ESC15 -- V1 Template Application Policies Override (EKUwu). The pre-installed V1 WebServer template -- which ships on every CA, cannot be deleted, and is enrollable by Authenticated Users by default -- accepts Application Policies extensions in the request. Application Policies, a Microsoft extension parallel to standard EKU, are honored by the KDC. An attacker submits a CSR adding the Client Authentication Application Policy to a WebServer certificate, gets it signed, and authenticates as the requester. Disclosed by Justin Bollinger at TrustedSec on October 8, 2024 [@bollinger-ekuwu]. Microsoft assigned CVE-2024-49019 and patched it on November 12, 2024 [@cve-2024-49019-msrc]. No BloodHound CE edge.

ESC16 -- CA-wide SID Extension Disabled. The CA's DisableExtensionList registry value can list OIDs the CA will omit from issued certificates. If szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) is on that list, the CA stops embedding the SID extension globally, and the strong-mapping enforcement of KB5014754 collapses into weak mapping for every certificate the CA issues. The SpecterOps Certify documentation records the punchline: "The configuration was first described in 2022 by Will Schroeder in this blogpost as a temporary workaround for the interaction between ESC7 and ESC6, but was later tagged ESC16 by Oliver Lyak" [@specterops-esc16-docs]. No BloodHound CE edge.

ESC12 lives in a different primitive category from every other ESC: it attacks the CA's HSM, not its software configuration. Hans-Joachim Knobloch's October 2023 disclosure (earliest Wayback snapshot dated October 24, 2023) observes that the YubiHSM2 Key Storage Provider on AD CS stores the HSM authentication key in cleartext under `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` [@knobloch-esc12] [@knobloch-esc12-archive]. A non-administrative user with shell access to the CA and read on that registry key can recover the HSM password and forge certificates against the HSM-backed CA key. Out of body scope for this article; readers running YubiHSM-backed CAs should read Knobloch's primary source.

By the time you reach ESC10 here, a pattern is visible without anyone naming it: every Microsoft mitigation in this class is followed by a new ESC that side-steps it. KB5005413 closes ESC8 over HTTPS; ESC11 routes around it via RPC. KB5014754 closes ESC9 and ESC10 under Full Enforcement; ESC16 disables the underlying SID extension. CVE-2024-49019 closes ESC15 on V1 templates; the V1 templates themselves remain on every CA. The catalog grows faster than the patches.

Of the sixteen entries above, BloodHound CE ships eleven principal-graph edges covering eight distinct ESCs: ADCSESC1, ADCSESC3, ADCSESC4, ADCSESC6a/b, ADCSESC9a/b, ADCSESC10a/b, ADCSESC13, plus the CoerceAndRelayNTLMToADCS edge that graphs ESC8 [@bh-llms]. The remaining eight ESCs (ESC2, ESC5, ESC7, ESC11, ESC12, ESC14, ESC15, ESC16) are out of edge coverage today -- some because their primitive lives below the principal graph (ESC11's RPC transport), some because their abuse is a CA-side write rather than a domain principal relationship (ESC7, ESC5), and some because they are too new to have been edge-modeled (ESC14, ESC15, ESC16). The gap is structural and operationally significant; section eight explores why.

flowchart TD subgraph TEMPLATE[Template] E1[ESC1 ESS+ClientAuth+LowPriv
SpecterOps 2021] E2[ESC2 AnyPurpose/SubCA
SpecterOps 2021] E3[ESC3 Enrollment Agent
SpecterOps 2021] E15[ESC15 V1 AppPolicy
TrustedSec 2024] end subgraph ACL[Access Control] E4[ESC4 Template DACL
SpecterOps 2021] E5[ESC5 PKI Object DACL
SpecterOps 2021] E7[ESC7 CA DACL
SpecterOps 2021] end subgraph CA[CA Configuration] E6[ESC6 EDITF SAN2
SpecterOps 2021] E16[ESC16 Disable SID Ext
tagged Lyak 2025] end subgraph TRANSPORT[Transport] E8[ESC8 Relay to HTTP
SpecterOps 2021] E11[ESC11 Relay to RPC
Compass 2022] end subgraph MAP[Mapping] E9[ESC9 No SID Ext
IFCR 2022] E10[ESC10 Weak Mapping
IFCR 2022] E13[ESC13 OIDToGroupLink
SpecterOps 2024] E14[ESC14 altSecurityIdentities
SpecterOps 2024] end subgraph HW[Hardware] E12[ESC12 YubiHSM Substrate
Knobloch 2023] end

The static rules that Certipy, Certify, Locksmith, and PSPKIAudit all run to decide whether a template is ESC1-shaped are simpler than the catalog above might suggest. Three boolean inputs, three conjunctive conditions, one output label.

{` function classifyTemplate(t) { const ess = t.flags.includes('CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT'); const clientAuth = t.eku.includes('1.3.6.1.5.5.7.3.2'); const lowPriv = t.enroll.some(p => ['Authenticated Users', 'Domain Users'].includes(p)); const noApproval = !t.flags.includes('CT_FLAG_PEND_ALL_REQUESTS'); if (ess && clientAuth && lowPriv && noApproval) return 'ESC1'; return 'safe-for-now'; }

const wifi = { flags: ['CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT'], eku: ['1.3.6.1.5.5.7.3.2'], enroll:['Authenticated Users'] }; console.log(classifyTemplate(wifi)); `}

6. The 2026 Toolchain

Sixteen ESCs is too many for one tool. The 2026 state of the art is a stack: defenders run Locksmith, PSPKIAudit, BloodHound CE, and Microsoft Defender for Identity in parallel; offense runs Certipy and Certify. No single tool covers every ESC, prioritizes its findings, and produces forensic primitives for response. Coverage gaps are structural, not accidental.

Certify is the original offense-side tool from the SpecterOps team that wrote Certified Pre-Owned. A C# Windows binary that enumerates and abuses AD CS misconfigurations using the operator's in-process credentials [@certify-gh]. Released at Black Hat 2021, built against .NET 4.7.2. Certify covers the ESC1 through ESC16 enumeration surface via its documentation pages [@specterops-certify-docs-index]; abuse implementations exist for the catalog's most operator-friendly entries, with ESC11 documented as enumeration-only at the most recent docs revision [@specterops-esc11-docs].

Certipy is the Linux-side sibling, written in Python by Oliver Lyak at IFCR (now an independent project) [@certipy-gh]. The README carries the strongest coverage claim in the tool community: "full support for identifying and exploiting all known ESC1-ESC16 attack paths." Certipy ships its own NTLM relay (certipy relay), embedded BloodHound output, certificate forging, and PKINIT-to-TGT exchange. The Certipy wiki's privilege-escalation page is the best walking reference for the entire catalog [@certipy-wiki-priv].

BloodHound Community Edition is the only tool in the stack that integrates AD CS findings into the broader Active Directory attack graph. SharpHound CE collects AD CS objects -- CAs, templates, NTAuth membership, per-template DACLs -- and the BloodHound server computes ten ADCSESC*N* edges (ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, ESC13) plus the CoerceAndRelayNTLMToADCS edge that graphs ESC8 via coercion [@bh-llms]. BloodHound CE 7.x added Privilege Zones, which let defenders tag NTAuth CAs and their templates as Tier-Zero objects and surface paths to them in the analysis UI.

The principal-graph model treats each AD object as a node and each access right or trust as an edge. The graph then path-finds from a starting principal to a Tier-Zero target. This model works elegantly for template DACLs (ESC4) and CA DACLs (ESC7) and for issuance-policy group linkage (ESC13). It struggles with attacks where the abuse is a transport-level interaction rather than a principal-to-principal relationship.

ESC8 used to be considered uncatchable in this model. The CoerceAndRelayNTLMToADCS edge solved that: BloodHound CE now models the SMB-coercion-plus-NTLM-relay-to-ESC8 chain as a Group-to-Computer edge whose source is Authenticated Users and whose destination is the coerced target computer; the relay target CA and the template are encoded in the edge's metadata, not as graph nodes [@bh-coerce-adcs-edge]. The edge exists because coercion has a stable shape -- an unauthenticated principal class, a target computer, and an ESC8-vulnerable CA endpoint reachable on the network -- that the graph can express.

ESC11 remains harder. The RPC enrollment transport does not have a stable coercion model (the trigger is ICertPassage packet privacy not being enforced, not a coercion gadget like MS-EFSR), and the BloodHound graph today does not ship an ADCSESC11 edge. The model limit is partial, not total. The conventional "BloodHound cannot graph transport attacks" framing -- which was the prevailing folklore through 2024 -- is wrong; ESC8 is in the graph. ESC11 is the open structural case.

Locksmith is a PowerShell defender tool by Jake Hildreth (with Spencer Alessi) [@locksmith-gh]. It runs locally on a domain-joined host and reports template, CA, and NTAuth-container findings against the catalog. Modes 0 through 4: identify-and-report, auto-remediate where safe, produce a CSV, and so on. The lowest-friction defender tool in the stack -- a single Invoke-Locksmith cmdlet returns a triage list against the published ESC range.

PSPKIAudit is the SpecterOps team's own defender baseline, built on top of PKI Solutions' PSPKI module [@pspkiaudit-gh]. Its Invoke-PKIAudit and Get-CertRequest cmdlets cover ESC1 through ESC8 plus the "Explicit Mappings" surface for ESC14. The README is marked beta; PSPKIAudit predates Locksmith and ships fewer remediation primitives, but it is the canonical reference for what the original SpecterOps team thinks the defensive audit should do.

Microsoft Defender for Identity ships the ADCS posture assessment suite when the MDI sensor is installed on the CA itself [@mdi-certs]. The current product surface assesses nine ESCs by name: ESC1 (Preview), ESC2, ESC3, ESC4 (split across two separate assessments -- template owner and template ACL), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15. The product page is explicit: "This assessment is available only to customers who have installed a sensor on an AD CS server." MDI's coverage is broad and operationally integrated -- the same SOC console that surfaces Pass-the-Hash detections now surfaces the largest named-ESC posture-assessment suite of any non-Certipy tool in the stack, with the ESC1 and ESC6 assessments shipped in Preview state.

The KB5014754 strong-mapping track is Microsoft's runtime mitigation rather than a tool, but operationally it belongs in the stack discussion because it is the largest single thing Microsoft has shipped for this class [@kb5014754]. Strong mapping closes ESC9 and ESC10 (plus Certifried CVE-2022-26923) under Full Enforcement, defaults to Compatibility through February 11, 2025, and removes the legacy-mapping registry override on September 9, 2025. Operationally this is a deployment decision more than a "tool to run", but every defender stack has to plan for it; the Microsoft Tech Community Intune blog is the cross-reference for environments using SCEP or PKCS [@ms-tc-intune].

The Hacker Recipes AD CS chapter is a community reference catalog rather than a runnable tool; it serves as the canonical operator-facing summary of every ESC and is worth bookmarking. (Network reachability of the canonical URL has been inconsistent in late 2025 / 2026.)

Here is a single-table comparison of the practical stack. The right answer for a real enterprise is roughly "all of them in parallel"; the table makes the coverage gaps explicit.

Tool / track	Language	ESC enumeration coverage	Abuse capable	Graph capable	Best deployed for	Source
Certify	C# (Windows)	ESC1 to ESC16 (per docs)	Yes (most)	No	Operator chains, Windows offense	[@certify-gh]
Certipy	Python (Linux)	ESC1 to ESC16 (README claim)	Yes	Embedded	Operator chains, Linux offense	[@certipy-gh]
BloodHound CE ADCS edges	Cypher	8 of 16 ESCs (11 edges: ten ADCSESCN + CoerceAndRelayNTLMToADCS)	No	Yes	Prioritization, attack-path analysis	[@bh-llms]
Locksmith	PowerShell	Published ESC catalog	Identify and fix	No	Operational scans on each CA	[@locksmith-gh]
PSPKIAudit	PowerShell	ESC1 to ESC8 plus Explicit Mappings	No (read-only)	No	Defender baseline, audit	[@pspkiaudit-gh]
MDI ADCS posture	SaaS	ESC1 (Preview), ESC2, ESC3, ESC4, ESC6 (Preview), ESC7, ESC8, ESC11, ESC15	No	Inside MDI console	SOC integration, posture scoring	[@mdi-certs]
KB5014754 strong mapping	Windows runtime	ESC9, ESC10, Certifried (mitigation)	n/a	n/a	Domain Controllers (deploy)	[@kb5014754]

Note: For most enterprises the realistic configuration is: Locksmith scheduled monthly on every CA; BloodHound CE with the ADCS collector enabled in SharpHound CE; Microsoft Defender for Identity sensor on every AD CS server (for the nine-ESC SOC visibility surface that now includes ESC1 and ESC6 in Preview); PSPKIAudit run once a quarter as the SpecterOps-blessed baseline; Certipy in the red-team or purple-team kit; and the KB5014754 rollout staged to land at Full Enforcement before February 11, 2025 (legacy-mapping removal September 9, 2025). The remaining gap items -- ESC5, ESC12, ESC14, and ESC16 (neither in BloodHound's principal graph nor in MDI's posture-assessment surface) -- are caught by Locksmith plus PSPKIAudit plus Certipy plus careful template review.

If no single tool covers everything, what is Microsoft actually doing about it?

7. What Microsoft Has Actually Shipped

Of sixteen named ESCs, Microsoft has shipped three CVE-class patches. The rest are hardening guidance. The asymmetry is not accidental; it tracks the boundary Microsoft draws in its Windows Security Servicing Criteria between default-state vulnerabilities (which receive CVEs and binary patches) and admin-configurable misconfigurations (which receive documentation). Most ESCs sit on the configurable side of that boundary.

Four Microsoft mitigation tracks define the response, in order of when they shipped.

KB5005413 (late July 2021) -- NTLM Web Enrollment hardening. Published roughly six weeks after Certified Pre-Owned in response to PetitPotam plus the SpecterOps ESC8 disclosure [@kb5005413]. Recommends enabling Extended Protection for Authentication, requiring SSL on the /certsrv/ virtual directories of AD CS Web Enrollment and the Certificate Enrollment Web Service, and disabling NTLM where Kerberos is available. Crucially: KB5005413 is guidance, not a binary patch. Environments that never enabled EPA on /certsrv/ remain exploitable today. The KB closes ESC8 over HTTPS when fully applied; it does not affect ESC11 (RPC), ESC1 through ESC7, or anything in the ESC9-plus range.

CVE-2022-26923 (May 10, 2022) -- Certifried. The single MSRC-acknowledged CVE in the original ESC1 through ESC8 design space [@cve-2022-26923-nvd] [@cve-2022-26923-msrc]. Disclosed by Oliver Lyak at IFCR [@lyak-certifried], the vulnerability lets any Authenticated User (because the default ms-DS-MachineAccountQuota is 10 [@semperis-cve]) create a computer account, write its dNSHostName to match a Domain Controller, request a certificate from the default Machine template, and PKINIT as the DC. Microsoft patched it on the May 10, 2022 Patch Tuesday. Semperis's retrospective documents the chain in detail [@semperis-cve]. The patch closes that specific path -- the dNSHostName impersonation race -- and is part of the same Patch Tuesday that shipped KB5014754. It does not close any other ESC.

KB5014754 (May 10, 2022 -- present) -- the strong-mapping rollout. The largest single Microsoft mitigation in the entire class [@kb5014754]. SpecterOps's own analysis -- "Certificates and Pwnage and Patches, Oh My!" -- remains the canonical walkthrough of how the new behavior interacts with the existing catalog [@specterops-pwnage].

The mechanics: KB5014754 introduces the szOID_NTDS_CA_SECURITY_EXT extension (OID 1.3.6.1.4.1.311.25.2), embeds the requester's SID into every issued certificate by default, and redefines which altSecurityIdentities mappings the KDC will accept. Deployment is staged across three modes -- Disabled, Compatibility, and Full Enforcement -- with the Full Enforcement transition originally planned for November 2023, then repeatedly delayed in response to customer compatibility issues with SCEP, Intune PKCS, and non-Microsoft PKIs. The KB's current text states that Full Enforcement becomes the default on February 11, 2025, and the legacy compatibility-mode registry override is removed by the September 9, 2025 Windows security update [@kb5014754].

What it closes: ESC9 (because Full Enforcement rejects certificates lacking the SID extension), ESC10 (because weak mappings are rejected), and Certifried even on unpatched templates. It is bypassed by ESC16, which disables the SID extension at the CA level.

CVE-2024-49019 (EKUwu / ESC15) -- November 12, 2024. Patched thirty-five days after Bollinger's October 8, 2024 disclosure [@bollinger-ekuwu]. The November 12, 2024 Patch Tuesday addressed the V1 WebServer template Application-Policies override [@cve-2024-49019-nvd] [@cve-2024-49019-msrc]. The patch hardens the KDC's interpretation of Application Policies in V1 certificates; it does not close ESC16, ESC11, or anything in the template DACL space.

Note: Microsoft's Windows Security Servicing Criteria reserves CVEs for vulnerabilities in default product state [@msrc-servicing-criteria]. Misconfigurations that require administrator action to introduce are treated as hardening matters and receive documentation rather than CVEs. The 2019 ANSSI altSecurityIdentities report received a "won't fix" response on exactly these grounds [@dedrouas-altsec]. The boundary explains the catalog's CVE asymmetry: ESC1 (template flag) is configuration; Certifried (a default-template behavior on an account-creation-default-permission interaction) is a CVE. ESC15 sat on the boundary -- the affected template is shipped pre-installed and cannot be uninstalled, so its default-state could be argued either way -- and Microsoft chose to issue a CVE. The boundary is operational policy, not technical bound; it can move.

The single most useful table in this article is the cross-reference of which Microsoft mitigation closes which ESC. Read row by row to understand which ESCs are runtime-closed in a hardened environment and which remain dependent on the customer's administrative hardening discipline.

ESC	KB5005413 (2021)	CVE-2022-26923 (2022)	KB5014754 (2022-2025)	CVE-2024-49019 (2024)	Hardening only
ESC1	--	--	Partial (SID ext defeats SAN supply for cert-authn)	--	Primary mitigation
ESC2	--	--	--	--	Yes
ESC3	--	--	Partial (SID ext binds the cert to the agent)	--	Yes
ESC4	--	--	--	--	Yes
ESC5	--	--	--	--	Yes
ESC6	--	--	Partial (SID ext defeats requested SAN)	--	Primary
ESC7	--	--	--	--	Yes
ESC8 (HTTP)	Closed when EPA + SSL deployed	--	--	--	Continues if EPA off
ESC9	--	--	Closed at Full Enforcement	--	Until Feb 2025
ESC10	--	--	Closed at Full Enforcement	--	Until Feb 2025
ESC11 (RPC)	--	--	--	--	Primary (`IF_ENFORCEENCRYPTICERTREQUEST` flag)
ESC12	--	--	--	--	Primary (HSM hardening)
ESC13	--	--	--	--	Yes
ESC14	--	--	--	--	Yes
ESC15	--	--	--	Closed (Nov 12, 2024)	--
ESC16	--	--	Bypassed (this attack disables the extension)	--	Primary

Of sixteen ESCs, three have CVE-class binary patches (Certifried, EKUwu, and -- if you count it -- the KB5005413 NTLM-relay hardening track), two are runtime-closed under KB5014754 Full Enforcement, and the remaining eleven are administrative hardening matters. If only three of sixteen have CVEs, what stops the catalog from growing forever?

8. The Two-Trust-Roots Problem

What stops the catalog from growing forever is the architectural property the catalog enumerates around but cannot eliminate. The catalog grows because the property is structural, not because the engineering is sloppy. Four pieces of theory anchor the limit.

Two trust roots. Active Directory's Kerberos KDC will mint a Domain Admin Ticket-Granting Ticket on presentation of any valid certificate signed by a CA in the forest's NTAuthCertificates container, provided the certificate maps to the Administrator principal. The krbtgt key is the symmetric root of trust for password and TGS authentication; an NTAuth CA's private key is an asymmetric root of trust for PKINIT. There is no architectural relationship between the two. Rotating the krbtgt key does not invalidate any certificate. Revoking a CA does not invalidate krbtgt-issued tickets. They are independent authenticator-minting keys. For a forest with $n$ NTAuth-published CAs, the count of independent keys that can mint a Domain Admin authenticator is $n + 1$.

Key idea: For an Active Directory forest with $n$ Certificate Authorities published into NTAuthCertificates, there are exactly $n + 1$ independent keys that can mint a Domain Admin authenticator: the krbtgt account hash, and the private key of every published CA. Rotating krbtgt closes one root. Revoking one CA closes another. The other $n - 1$ remain. The ESC catalog enumerates how an attacker can make those keys issue a Domain Admin authenticator with low-privilege materials; the architectural property -- that there are $n + 1$ such keys at all -- is a design property of PKINIT and is not closable by any patch [@rfc4556] [@cpo-whitepaper].

PKINIT's binding gap. RFC 4556 specifies how a Kerberos client presents a certificate and receives a TGT [@rfc4556]. The RFC does not bind the certificate to a Microsoft SID; the mapping from certificate to AD principal is a Microsoft extension. The KB5014754 strong-mapping track closes the mapping ambiguity by embedding the requester's SID into the certificate and matching the SID on the KDC side [@kb5014754]. It does not close the underlying primitive: a certificate is an alternate identity assertion that the KDC honors as long as the signing CA is trusted. Different ESCs find different ways to get a useful certificate; the authentication step is identical across the catalog.

The transport-versus-principal split. The §6 BloodHound Aside develops this in full: BloodHound's principal-graph model now expresses ESC8 as the CoerceAndRelayNTLMToADCS edge, but ESC11 remains the open structural case because the RPC transport has no equivalent coercion gadget [@bh-coerce-adcs-edge]. The model limit is partial, not total -- it applies to RPC, not to all transport attacks.

The configuration-versus-CVE boundary. The §7 Callout develops this in full. The catalog has accumulated CVEs only when Microsoft judged the configuration was default-state -- Certifried's machine-account-quota path and ESC15's pre-installed V1 templates. The architectural property is policy-driven and movable.

Active Directory has two trust roots that can mint a Domain Admin authenticator: the krbtgt key, and any CA published into NTAuth. Rotating one does not touch the other.

The architectural property reshapes how operators should think about the catalog. The catalog is not an arms race that ends; the catalog is the community mapping the surface of a design property of PKINIT. Each new ESC narrows the description of what surface remains exposed; no plausible patch removes the underlying $n + 1$ key count. Until PKINIT itself is replaced -- until PKINIT is deprecated, until the KDC stops accepting certificate-based authentication, until NTAuth-published CAs lose their KDC trust -- every NTAuth-published CA in the forest is a key parallel to krbtgt.

If the architectural limit cannot be closed, what are the open questions in 2026?

flowchart LR K[krbtgt account hash
symmetric KDC key] CA1[CA #1 private key
published in NTAuth] CA2[CA #2 private key
published in NTAuth] CAN[CA #n private key
published in NTAuth] KDC[Kerberos KDC
and PKINIT] AUTH[Domain Admin
authenticator TGT] K --> KDC CA1 --> KDC CA2 --> KDC CAN --> KDC KDC --> AUTH

9. Open Problems and the Catalog's Closure

The catalog has no published closure principle. Here are the five open frontiers in 2026.

No closure principle. The catalog has grown every year since 2021: ESC1 through ESC8 in June 2021; ESC9 and ESC10 in August 2022; ESC11 in November 2022; ESC12 in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive]; ESC13 and ESC14 in February 2024; ESC15 in October 2024; ESC16 named in 2025 against a workaround from 2022 [@specterops-esc16-docs]. ESC15 revealed a twenty-four-year-old default behavior on V1 templates -- behavior that had been quietly present since the role's 2000 shipping date [@bollinger-ekuwu]. The Certify documentation conjectures an upper bound (the six primitive categories times the misconfigurable bits per primitive) but no formal upper bound is published. ESC15 is itself an existence proof that new categories still emerge: Application Policies as a parallel to standard EKU was not in the original 2021 catalog at all.

Detection asymmetry. Most ESCs leave artifacts on the CA -- specifically Event ID 4886 (certificate request submitted) and Event ID 4887 (certificate issued) -- and no artifact in the standard Active Directory event stream. Most SIEMs do not ingest CA logs, because CA logs were never on the standard Tier-Zero ingest checklist. The result is that the CA's own audit log carries the only reliable forensic primitive for the entire catalog, and that log is in a place the SOC does not look. Locksmith and PSPKIAudit can identify the misconfigurations but cannot tell you whether they have been exploited; that signal lives in the CA's audit log alone.

Strong-mapping migration risk. The KB5014754 staged rollout enters Full Enforcement on February 11, 2025 and removes the legacy compatibility-mode registry override on September 9, 2025 [@kb5014754]. Environments with legacy SCEP gateways, third-party PKI vendors, Intune PKCS profiles without strong mapping, or smart cards issued by non-Microsoft CAs face a real risk that legitimate authentication breaks at Full Enforcement. The Microsoft Tech Community Intune guidance is the operational reference for the SCEP/PKCS path [@ms-tc-intune]. The migration is a security upgrade and a deployment minefield in the same package; environments that defer the rollout past September 9, 2025 lose the legacy override and are forced into Full Enforcement by an OS update they did not opt into.

Note: Per the live KB5014754 text on Microsoft Support: "By February 2025, if the StrongCertificateBindingEnforcement registry key is not configured, domain controllers will move to Full Enforcement mode" and "the option to move back to Compatibility mode will remain until the September 9, 2025, Windows security update is installed" [@kb5014754]. Environments that have not finished the strong-mapping rollout by those dates -- particularly those with non-Microsoft PKI in the chain, including legacy SCEP / Intune PKCS / smart-card vendors -- should plan for breakage and have a rollback plan ready.

Cloud PKI. Entra-managed Cloud PKI changes the substrate: the issuing CA is Microsoft-operated, the template surface is partially exposed to administrators, and the trust relationship between Cloud PKI and on-premises Active Directory is itself a configurable bridge. The community has not yet published an ESC catalog for Cloud PKI; the on-premises catalog is on-prem-specific and does not transfer directly. The open question is whether the Cloud PKI substrate has its own equivalent primitives (a CA-side "this template is configured with ESS-equivalent behavior") that just have not yet been named.

The NTLM dependency in ESC8 and ESC11. Both ESC8 and ESC11 depend on NTLM authentication being available between the coerced computer and the CA host. Microsoft's stated direction is to disable NTLM by default in future Windows releases (the "NTLM disablement" track) [@ms-ntlm-evolution]. If that direction completes, ESC8 and ESC11's relay primitives lose their substrate -- not because the AD CS transport hardens, but because there is no NTLM authentication to relay. The rest of the catalog -- the template, ACL, mapping, and CA-configuration ESCs -- does not depend on NTLM and is unaffected by NTLM disablement.

Taken together, these results suggest the catalog's growth trajectory is structural. The reason ESC15 surfaced a twenty-four-year-old default is not that the SpecterOps team was lazy in 2021; it is that the surface is so large that systematic enumeration of every cross-product (six primitives multiplied by the configurable bits per primitive) is itself a research program. Knowing the architectural limits and the open problems, here is the operational playbook.

10. The Four-Lane Playbook

Here is what an enterprise security program actually does, in four lanes. Lane discipline matters because the catalog rewards parallel work: a single quarter spent only on Lane 1 leaves you detection-blind, and a single quarter spent only on Lane 2 leaves you remediation-paralyzed.

Lane 1: Preventive hygiene

Run Locksmith and PSPKIAudit on every Enterprise CA at least monthly [@locksmith-gh] [@pspkiaudit-gh]. Both tools enumerate the published catalog and produce a triage list. The defender baseline these tools encode is roughly:

Template ACL audit. Confirm that no non-Tier-Zero principal holds WriteDacl, WriteOwner, WriteProperty, or GenericAll on any V2 template.
CA security descriptor audit. Confirm that Manage CA and Issue and Manage Certificates are held only by Tier-Zero principals.
ESS audit. Confirm that no template enrollable by Authenticated Users or Domain Users has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set with Client Authentication EKU and no Manager Approval.
CA registry audit. Confirm that EDITF_ATTRIBUTESUBJECTALTNAME2 is not set, and IF_ENFORCEENCRYPTICERTREQUEST is set.
SID extension audit. Confirm that szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) is not present in any CA's DisableExtensionList registry value -- closing the ESC16 path.
Manager Approval on sensitive templates. Confirm that any template with privileged EKU sets has Manager Approval.
Least-privilege Enroll. Confirm that Domain Users-equivalent groups do not hold Enroll or Autoenroll on sensitive templates.

Lane 2: Detection deployment

Ingest the CA's own Security event log into the SIEM. The two load-bearing events are 4886 ("Certificate Services received a certificate request") and 4887 ("Certificate Services approved a certificate request and issued a certificate"). These events are what fire when an operator chain like the cold-open in section one executes. They are the only AD CS event stream the SOC needs to detect the entire issuance side of the catalog.

Enable Microsoft Defender for Identity sensors on every AD CS server. MDI now ships nine named ESC posture assessments -- ESC1 (Preview), ESC2, ESC3, ESC4 (template owner and template ACL as two separate assessments), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 -- and surfaces them in the same console the SOC uses for the rest of Active Directory [@mdi-certs]. The ADCS-resident sensor is the only MDI sensor that produces these particular assessments; environments running MDI on Domain Controllers only do not get the AD CS surface.

Run SharpHound CE with the AD CS collection options enabled and ingest the resulting graph into BloodHound CE. Tag NTAuth-published CAs and their pre-installed sensitive templates as Tier Zero in BloodHound's Privilege Zones. Run the analysis layer's Shortest Paths to Tier Zero query weekly; ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, and ESC13 will surface as edges, along with CoerceAndRelayNTLMToADCS paths for any ESC8-vulnerable HTTP enrollment endpoint [@bh-llms] [@bh-coerce-adcs-edge].

Schedule Locksmith on a recurring cadence with output to a triage queue. Locksmith is the lowest-friction defender tool; it identifies and (with mode 1) optionally fixes published-catalog findings with a single cmdlet.

Lane 3: Confirmed-compromise response

This lane carries the article's load-bearing operational claim. If a CA's private key is suspected compromised -- whether through ESC12 hardware-substrate compromise, through ntdsutil-equivalent CA export, or through a vendor compromise of the HSM -- the recovery path is not "rotate krbtgt" and not "revoke the affected certificates". The recovery path is multi-week:

Revoke the CA's published certificate chain.
Decommission the CA (remove the role service, delete the CA private key store, retire the host).
Build a replacement CA on new hardware with a new key.
Publish the new CA into NTAuthCertificates.
Distrust the old CA's certificates throughout the forest (CRL update, certificate revocation lists pushed via Group Policy, decommissioning all certificates issued by the compromised CA).
Re-issue every credential that depended on the compromised CA.

This operation is analogous in scale and duration to a forest rebuild for krbtgt compromise -- a multi-week IR project, not a one-day patch. The reason is the two-trust-roots property: revoking the CA closes only one of the $n + 1$ keys; if the operator already minted Golden Certificates against the CA's private key, those certificates outlive the revocation unless every issued serial is on the CRL and every relying party has a fresh CRL fetch policy.

Note: The Lane-3 CA rebuild operation is the single most important preparatory deliverable in this entire playbook. Run a tabletop exercise: "the CA private key is compromised; what are the steps to a clean state?" If the answer is unclear in the absence of an incident, the answer will be improvised during one -- typically poorly. Build the runbook, identify the operational owners, pre-stage the replacement CA's hardware, and document the certificate inventory you will need to re-issue. The two-week recovery becomes a one-week recovery if the prep is done; the two-week recovery becomes a four-week recovery if it is not.

Lane 4: What does not work

Five operator myths that the catalog refutes by construction:

"Rotating krbtgt closes AD CS." Wrong. Rotating krbtgt closes the symmetric KDC key; it does not touch the asymmetric CA private keys in NTAuthCertificates. An ESC1 certificate issued against the new krbtgt mints a Domain Admin TGT the same way it would have against the old one.
"Credential Guard protects against ESC." Wrong. Credential Guard's LSAISO isolates LSASS-resident credentials from the rest of the OS. AD CS abuse does not touch LSAISO; the certificate is issued by the CA against a request submitted over a network protocol. The credential never leaves the attacker's machine in a form Credential Guard could isolate.
"Disabling Web Enrollment closes AD CS." Partial. Disabling the AD CS Web Enrollment role service closes ESC8 (the HTTP relay primitive). It does not affect ESC1 through ESC7 (template, ACL, and CA-config attacks), ESC11 (RPC relay), or any of the mapping ESCs. The default RPC enrollment transport on every Enterprise CA is unaffected.
"If we patch CVE-2022-26923 we're done." Wrong. CVE-2022-26923 closes the specific dNSHostName machine-account-impersonation chain. It does not close ESC1, ESC4, or any of the configuration ESCs that the same operator chain could have taken.
"Reset krbtgt twice and we have evicted the attacker." Wrong. The double-krbtgt-reset playbook is well-suited for Golden Ticket eviction. It is not effective against an attacker who has issued a long-validity authentication certificate from a CA the attacker controls or has compromised. The issued certificate authenticates against the new krbtgt the same way it did against the old one, because PKINIT does not bind the certificate's authority to the symmetric krbtgt key.

Run Locksmith this week. Tag NTAuth CAs as Tier Zero in BloodHound. Schedule the Lane 3 rebuild playbook before you need it. The catalog grew faster than the patches; the defender's only working strategy is parallel work in all four lanes.

11. Frequently Asked Questions

The SID extension is on by default for any CA running an OS that has installed KB5014754 or later. The catch is what the *KDC* does with that extension. Switching the KDC to Full Enforcement breaks every certificate that lacks the SID extension, which is why Microsoft built the three-mode staged rollout: the §7 timeline anchors the compatibility window (mechanics and the Feb 11, 2025 / Sep 9, 2025 milestones), and the §9 Callout carries the verbatim KB5014754 dates and the customer compatibility-friction set (legacy SCEP, Intune PKCS, non-Microsoft PKI, third-party smart cards). ESC16 closes the loop in the other direction: an admin (or a compromised admin) can re-disable the extension at the CA level, recreating the weak-mapping condition KB5014754 was designed to close. Partially. The on-premises ESC catalog enumerates misconfigurations of the on-premises AD CS role. Entra Cloud PKI is a Microsoft-operated SaaS CA whose substrate is not the on-premises AD CS Windows role at all -- so ESCs that abuse on-premises CA registry flags (ESC6, ESC16), on-premises CA DACLs (ESC5, ESC7), or the on-premises transport (ESC8, ESC11) do not transfer directly. But Cloud PKI still issues authentication certificates, still has a template-equivalent administrative surface, and still maps certificates onto AD or Entra principals. The community has not yet published a Cloud PKI ESC catalog; the open question is whether the cross-product of Cloud PKI's primitive surface and its mapping behavior has its own equivalent class of named misconfigurations. No. A two-tier hierarchy improves protection of the *root* CA's private key (the root signs only the subordinate's certificate and stays offline) but does nothing for the subordinate. The ESC catalog attacks the issuing subordinate, not the root. The misconfigured Enrollee-Supplies-Subject template, the editable `EDITF_ATTRIBUTESUBJECTALTNAME2` registry flag, the per-template DACL, the NTLM-relayable Web Enrollment endpoint -- all live on the subordinate CA. A two-tier hierarchy is the right architecture and is essentially orthogonal to the ESC discussion. No. Smart cards are *consumers* of certificates issued by AD CS; the smart-card pipeline reads a certificate off the card, presents it to PKINIT, and receives a TGT. AD CS is the *issuing* substrate. Every ESC attacks the issuance side. A smart-card deployment depends on AD CS being correctly configured; it adds no defense against ESC1 through ESC16 and may add complexity in the strong-mapping migration (smart-card-issued certificates may use legacy mappings that break under Full Enforcement). No. BloodHound CE does not ship a numbered `ADCSESC8` edge. It ships `CoerceAndRelayNTLMToADCS`, an edge representing "a computer can be SMB-coerced to authenticate to an attacker host, and the attacker host can relay that authentication to an ESC8-vulnerable Web Enrollment endpoint on a CA" [@bh-coerce-adcs-edge]. Look for that edge, not for a numbered ESC8 edge. If `CoerceAndRelayNTLMToADCS` paths exist anywhere in the graph, your Web Enrollment endpoint is ESC8-exposed and the operator chain from any coercible computer to a Domain Admin authenticator runs in eight minutes. ESC12 is treated in the §5 Aside: Knobloch's October 2023 YubiHSM hardware-substrate disclosure (earliest Wayback snapshot dated October 24, 2023), scoped out of the body because the abuse depends on the specific HSM vendor and on shell access to the CA host [@knobloch-esc12] [@knobloch-esc12-archive]. ESC0 does not exist in the SpecterOps catalog; some operator blogs use "ESC0" informally to describe naive enumeration (no abuse, just "the CA is reachable and the template store is readable") but it is not a community-named technique.

KRBTGT: The Account That Owns Active Directory

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

Active Directory's `krbtgt` account is the one secret in any Windows domain whose disclosure forges valid Ticket-Granting Tickets for every principal -- including ones that do not exist. Twelve years of attacks (Golden, Diamond, Sapphire) and Microsoft's responses (the MS14-068 patch, KrbtgtFullPacSignature, the two-reset rotation procedure) converge on one fact: krbtgt rotation invalidates forged TGTs but does not recover the systemic compromise that produced them. That distinction is why confirmed krbtgt compromise is a forest-rebuild event in modern incident-response playbooks, not a key-rotation event.

1. Ninety Seconds to Domain Admin

A single mimikatz kerberos::golden command, with the krbtgt account's AES-256 long-term key in hand, walks the attacker onto any resource in the domain as Administrator. No Domain Admin password was reset. No Domain Admin account was created. No SACL on a sensitive object fired. No LSASS on any host was dumped. No signature-based IDS rule triggered. The attacker holds exactly one cryptographic key -- the long-term key of the RID-502 service account named krbtgt -- and the entire Kerberos trust hierarchy of the domain now accepts whatever they sign [@mitre-t1558001]. The section title's "ninety seconds" is an illustration of how fast the attack is on the wall clock, not a measured demonstration from a published primary.

The operator sequence is short enough to quote. Earlier in the engagement, the attacker ran lsadump::dcsync /user:contoso\krbtgt from a member-server foothold and walked off with the krbtgt long-term key material [@mimikatz]. Then they switched tools to forge a ticket from scratch:

mimikatz # kerberos::golden /domain:contoso.local
                            /sid:S-1-5-21-1004336348-1177238915-682003330
                            /aes256:<key>
                            /user:Administrator /id:500
                            /groups:512,513,518,519,520 /ptt

That single command, documented by Sean Metcalf for operators in 2015 [@adsec-1640], does the forgery in process memory, injects the ticket into the local Kerberos cache (/ptt = pass-the-ticket), and lets the next dir \\dc01\admin succeed.

Count the controls that did not fire while the forged ticket was being minted and presented. No Domain Admin password reset, because the attacker never used a Domain Admin password. No new privileged account, because the attacker impersonated an existing one (RID 500). No SACL on a sensitive object, because the ticket was already approved by the Kerberos trust root before any object was touched. No LSASS dump on a writeable DC, because DCSync is a replication API call, not a memory scrape [@mitre-t1003006]. No IDS hit on a known-malicious payload, because Mimikatz lives in attacker process memory and the wire traffic is, structurally, a TGS-REQ. No anomalous logon time, MFA prompt, or Conditional Access decision, because Kerberos pre-authentication is satisfied by holding a valid TGT and the TGT was minted offline.

The article's load-bearing thesis: within the Kerberos trust root of a single domain, the krbtgt key is the unique secret whose disclosure yields valid TGTs for every principal -- including ones that do not exist. The technical recovery (two-reset rotation) is well-documented [@ms-forest-recovery] and does cryptographically invalidate forged tickets. But the operational recovery from a confirmed krbtgt compromise is a forest-rebuild event for reasons that have nothing to do with the krbtgt key itself.

This produces an apparent contradiction. Microsoft documents a clean two-reset rotation procedure with a ten-hour interval [@ms-forest-recovery]; Mandiant- and SpecterOps-style incident-response playbooks treat confirmed krbtgt compromise as a forest-rebuild event [@specterops-dot2]. Both statements are simultaneously true. The job of the next ten thousand words is to explain why -- starting with what krbtgt actually is. Not the key. Not the protocol. The account itself: RID 502, disabled, indelible.

2. The Account: RID 502, Disabled, Indelible

Open Active Directory Users and Computers on a fresh Windows Server 2022 domain promoted ten seconds ago. In the Users container there is an account called krbtgt. It has no password visible to the admin. It is disabled. Try to enable it -- the checkbox accepts the click, but the next replication cycle puts the account right back into the disabled state. Try to rename it -- the operation appears to succeed, but the objectSID does not change. Try to delete it -- the operation fails outright. You cannot log in as it; the disabled-for-interactive-logon property is enforced inside the Security Accounts Manager. The account exists exactly because the domain exists; the lifetime of the account and the lifetime of the domain are the same lifetime [@ms-default-accounts].

Why does Active Directory ship with an account that no admin can use, no attacker can authenticate as interactively, and no operator can remove?

The Kerberos Ticket-Granting Ticket service account that exists, exactly once per Active Directory domain, to hold the long-term cryptographic key the domain controllers use to encrypt and sign every TGT issued in the domain. The account name itself is the Kerberos principal name (`krbtgt/DOMAIN@DOMAIN`) inherited from MIT's 1988 Kerberos v4 design.

Creation. The account is created automatically when the first writeable domain controller is promoted in a new domain. The Microsoft Learn default-accounts page lists it alongside Administrator and Guest as one of the three default local accounts in the Users container, with the verbatim note that "the KRBTGT account can't be enabled in Active Directory" [@ms-default-accounts]. The account's lifecycle is bound to the domain's lifecycle; there is no operator-controllable provisioning of a krbtgt account, and no de-provisioning short of demoting the domain.

RID 502. The relative identifier at the tail of the account's SID (S-1-5-21-<domain>-502) is fixed by the well-known SID specification [@ms-sids]. Sean Metcalf's operator primer confirms the RID-502 binding directly: "Each Active Directory domain has an associated KRBTGT account ... The SID for the KRBTGT account is S-1-5-<domain>-502" [@adsec-483].RIDs 500 through 1000 are reserved for built-in security principals; 500 is Administrator, 501 is Guest, 502 is krbtgt. Renaming the sAMAccountName cannot move the RID. The KDC service derives its key lookups from the principal name, which binds to the RID, not from the friendly name shown in ADUC. Renaming krbtgt as a defensive measure is a fallacy that the next section will sharpen further.

Each Read-Only Domain Controller has its own krbtgt_<rid> account whose key signs only that RODC's tickets. The full-domain krbtgt account is read-only from the RODC's perspective -- the design property that lets RODCs participate in Kerberos without holding the full-domain trust root [@adsec-483].

Container. CN=Users,DC=<domain>. The standard Users container, not a Tier-0 OU or a Protected Users group. The account is privileged by virtue of its RID, not by virtue of its containership. Moving it into a different container does not change its semantic role to the KDC.

Disabled for interactive logon. Documented verbatim on the Microsoft Learn default-accounts page: "The KRBTGT account can't be enabled in Active Directory" [@ms-default-accounts]. The account is reserved for the KDC service. There is no interactive logon surface attached, no LSA logon-rights grant, no Kerberos pre-authentication path that produces a TGT for the krbtgt account itself. The account exists to provide a key, not to authenticate.

Indelible and unrenamable. Also from the same Microsoft Learn page: "This account can't be deleted, and the account name can't be changed" [@ms-default-accounts]. ADUC will show a renamed display, but the underlying object identity (the RID, the principal name) is fixed by the directory schema and by LsaSrv enforcement on the writeable DCs.

Password. System-generated, unknown to operators by design. Resetting it via ADUC produces a value Active Directory immediately replaces with a fresh system-generated value. The mechanism that produces the current key is therefore not operator-controllable; rotation is the only primitive operators have over the key value [@ms-forest-recovery].

Password history equals 2. Documented verbatim on the AD Forest Recovery page: "The password history value for the krbtgt account is 2, meaning it includes the two most recent passwords" [@ms-forest-recovery]. This is the mechanical foundation for the two-reset procedure Section 7 will dissect. The KDC keeps both a current and a previous key in the krbtgt account; in-flight TGT validation tries both during the brief window after a rotation; one reset retires only the older of the two; a second reset, separated by at least the maximum ticket lifetime, evicts the key the attacker held.

Where the key lives. The KDC service (kdcsvc.dll) on every writeable DC reads the krbtgt long-term key from ntds.dit at startup and holds it in process memory for ticket signing and validation. Credential Guard's VBS trustlet -- LSAISO -- does not isolate this read on writeable DCs by design: a DC must read the key to issue tickets [@ms-credential-guard] (see also §10 Aside on why Credential Guard skips the DC). This is the structural asymmetry that makes the krbtgt key reachable to any attacker who can compromise a writeable DC (or invoke its replication API remotely), even on a system where Credential Guard is otherwise enforced everywhere else.

We know what the account is now: a non-interactive, indelible, RID-502 service principal with a system-generated, two-slot password history. But the account is just the container. The rest of the article cares about the long-term cryptographic key it holds.

3. The Key: What RFC 4120 and [MS-KILE] Specify

Hand a network capture of a Kerberos AS-REP to a Wireshark dissector. The dissector shows the TGT as a sequence of ASN.1 fields. One field is named enc-part and its content is opaque. The dissector knows the format of what is inside that opaque blob -- an EncTicketPart -- but it cannot show the field values because the blob is encrypted [@rfc4120]. Encrypted under what? Under one key: the long-term key of the principal named krbtgt/CONTOSO.LOCAL@CONTOSO.LOCAL.

The Microsoft specification puts it as plainly as is possible to put it. [MS-KILE] specifies that the KDC encrypts every ticket using the long-term cryptographic key of the krbtgt principal, citing RFC 4120 §5.2.2 [@mskile]. That sentence, more than any other in the Microsoft Open Specifications corpus, is the cryptographic foundation of Active Directory authentication. Every TGT issued by every writeable DC in the domain is encrypted under one key. There is no per-account key, no per-DC key, no rolling subkey. One key, one trust scope.

The credential the Kerberos Key Distribution Center issues at logon, encrypted under the KDC's own service key (in Windows, the krbtgt account's long-term key), that the client subsequently presents to request service tickets without re-authenticating with a password. RFC 4120 §5.3 defines its fields; [MS-KILE] specifies the Windows wire profile [@rfc4120][@mskile]. The Kerberos service that issues TGTs (the Authentication Service) and exchanges TGTs for service tickets (the Ticket-Granting Service). In Active Directory the KDC runs as `kdcsvc.dll` on every writeable domain controller; it holds the krbtgt long-term key in process memory for the lifetime of the service [@rfc4120].

Inside the encrypted blob

RFC 4120 §5.3 specifies the fields of the EncTicketPart: a session key the KDC generates for this TGT, the client's name, the cross-domain transit path, the timestamps (authtime, starttime, endtime, renew-till), the optional client-address list, and a final field of authorization-data that Windows uses to carry the Privilege Attribute Certificate [@rfc4120].

The Windows-specific data structure embedded inside the `authorization-data` field of every Kerberos ticket. The PAC carries the user's SID, the SIDs of every group the user belongs to, account restrictions, profile path, logon server, and a small set of cryptographic signatures the KDC computes to bind the structure to the ticket. Defined in [MS-PAC] [@mspac].

The PAC is where the load-bearing security claim of Windows Kerberos lives. RFC 4120 itself does not care about groups; it cares about whether the client can prove identity to a server. The PAC carries the authorization layer Windows needs on top of authentication: which security principal the ticket represents, which groups confer which permissions, which restrictions apply [@mspac]. The first thing a Windows file server does when it receives a service ticket is decode the PAC, read the SIDs, and run the access-check algorithm.

The three signatures inside every PAC

The PAC is integrity-protected by a small set of signatures the KDC computes when it issues the ticket. As of the [MS-PAC] revision 26.0 dated June 10, 2024 [@mspac], a TGT-resident PAC carries three of them:

The PAC server signature. A keyed HMAC computed under the service key. For a TGT the service is krbtgt/DOMAIN, so the server signature is computed under the krbtgt long-term key. For a service ticket the server signature is computed under the service account's long-term key (the file server's machine-account key, for example) [@mspac].
The PAC KDC signature. A keyed HMAC computed under the krbtgt long-term key, signing the bytes of the server signature. This is the pre-2022 anchor of PAC integrity: even if a service holding only its own key could verify the server signature, only the KDC (or anyone holding the krbtgt key) could compute the matching KDC signature. The "pre-2022" framing tracks the deployment of KB5020805's Full PAC Signature, documented in §5 Generation 6 [@kb5020805].
The Full PAC Signature. Added by Microsoft's response to CVE-2022-37967, deployed via KB5020805 starting November 8, 2022 and enforced by default since July 11, 2023 [@kb5020805][@cve-2022-37967]. Computed by the KDC over the entire PAC -- including the older two signatures -- and stored alongside them. Also computed under the krbtgt long-term key.

flowchart TD PAC[PAC contents: SIDs, groups, restrictions] --> SSig[Server Signature] PAC --> KSig[KDC Signature] PAC --> FSig[Full PAC Signature] SSig --> KEY["krbtgt long-term key (TGT)"] KSig --> KEY FSig --> KEY KEY --> TGT[EncTicketPart for TGT] TGT --> WIRE[AS-REP / TGS-REP on the wire]

This is the architectural fact the rest of the article will refer back to. The addition of the Full PAC Signature did not relocate the trust to a different key. All three PAC signatures on a TGT terminate at the krbtgt long-term key. An attacker who holds the krbtgt key computes all three correctly in the same step. This is the precise technical observation that motivates the Section 5 attack cascade and the Section 7 rotation analysis.

The enctype matrix

The krbtgt account does not hold a single key; it holds a set of keys, one per Kerberos encryption type advertised in msDS-SupportedEncryptionTypes on the account object. RFC 4120 §5.2.9 defines the enctype numbers; common Windows values are AES-256-CTS-HMAC-SHA1-96 (enctype 18), AES-128 (enctype 17), and the legacy RC4-HMAC (enctype 23) [@rfc4120]. AES-256 has been the recommended default for newly-provisioned krbtgt accounts since the Windows Server 2008 R2 / Windows Server 2012 functional levels, though early Windows Server 2008 deployments often required a krbtgt password reset to materialise the AES keys. The post-2017 AES-SHA2 family (enctypes 19 and 20) is defined by IETF but not deployed in mainline Windows production as of [MS-KILE] revision 47.0 dated April 27, 2026 [@mskile].

A numeric identifier for the cryptographic algorithm and key length used to encrypt a Kerberos message. RFC 4120 §5.2.9 enumerates them; common Windows values are 17 (AES-128), 18 (AES-256), and 23 (the legacy RC4-HMAC). Each principal's long-term key is derived per enctype, so the krbtgt account stores multiple key derivations side by side [@rfc4120].

Each derivation is stored in both current and previous slots; rotating the krbtgt password rederives the entire set for the new password and shifts the previous derivations into the previous slot.

FAST armoring sits next to, not above, the krbtgt key

RFC 6113 / [MS-KILE] Flexible Authentication Secure Tunneling adds a second key layer for the client-facing pre-authentication exchange, armoring the AS-REQ under a separate channel key derived from a TGT the client already holds. FAST hardens pre-authentication against offline brute-force. It does not change the fact that the TGT's enc-part is encrypted under the krbtgt key on its way back to the client [@mskile]. No Kerberos extension shipped through 2026 moves the TGT's trust anchor anywhere other than the krbtgt long-term key.

Within a Kerberos domain, every TGT reduces to the same key, and that key has a name: krbtgt.

That sentence is the load-bearing claim the rest of the article rests on. The next section explains how a 1988 academic design decision became the cryptographic foundation of every Windows domain alive today.

{` // Simplified model of the three PAC signatures on a TGT. // Each signature is a keyed HMAC computed under the krbtgt long-term key. const pacContents = "SIDs, groups, restrictions"; const krbtgtKey = "<32-byte AES-256 long-term key>";

function hmac(key, data) { return key === krbtgtKey ? "SIG(" + data + ")" // attacker-with-key computes valid sigs : "INVALID"; // attacker-without-key cannot forge them }

function buildPACBlock(attackerKey) { const serverSig = hmac(attackerKey, pacContents); const kdcSig = hmac(attackerKey, serverSig); const fullPAC = hmac(attackerKey, pacContents + serverSig + kdcSig); const validates = [serverSig, kdcSig, fullPAC].every(s => s !== "INVALID"); return { serverSig, kdcSig, fullPAC, validates }; }

console.log("with krbtgt key :", buildPACBlock(krbtgtKey).validates); console.log("without krbtgt key:", buildPACBlock("guess-key").validates); `}

4. Origins: 1988 Athena, RFC 4120, [MS-KILE]

Open the bibliography of RFC 4120 and find an entry tagged [Ste88]: "Steiner, J., Neuman, C., and J. Schiller, 'Kerberos: An Authentication Service for Open Network Systems,' USENIX Conference Proceedings, February 1988" [@rfc4120]. The principal name krbtgt is in that paper. It has been carried forward unchanged through RFC 1510 (1993) [@rfc1510], through Active Directory's February 2000 release, through RFC 4120 (2005) [@rfc4120], through the first [MS-KILE] revision (2007), and into the current [MS-KILE] revision 47.0 dated April 27, 2026 [@mskile]. Thirty-eight years.

What did the 1988 design decision look like, and what has changed about its security properties since?

MIT Project Athena, 1983-1991

Project Athena ran at MIT from 1983 to 1991 as a campus-scale distributed-computing experiment funded primarily by IBM and DEC [@project-athena]. The authentication problem Athena needed to solve was the one every multi-user network has needed to solve since: how do you let thousands of workstations talk to thousands of services without broadcasting cleartext passwords on every connection? Steiner, Neuman, and Schiller presented their answer at the Winter USENIX conference in Dallas in February 1988. Their design introduced the krbtgt principal name and the trust property that one key encrypts every TGT in the Kerberos domain [@athena1988].

The principal name krbtgt predates Active Directory by twelve years. MIT's 1988 USENIX paper used the name, RFC 1510 standardised it in 1993 [@rfc1510], and Windows 2000 inherited it unchanged. There is no Microsoft-specific Kerberos principal naming convention; the convention is IETF.

The design property that one key encrypts every TGT was not framed in 1988 as a security risk. It was framed as a simplification: by giving the TGS one stable identity that issues every TGT, the protocol does not need to negotiate per-session KDC identities or per-server validation paths. The protocol reduces, mathematically, to two questions: did the KDC issue this TGT, and did the TGT permit the subsequent TGS-REQ for this service? Both reduce to "does this signature validate under the krbtgt key?"

From RFC 1510 to [MS-KILE]

John Kohl and Clifford Neuman published RFC 1510 in September 1993, standardising Kerberos version 5 [@rfc1510]. The krbtgt/DOMAIN@DOMAIN principal-name convention carried forward unchanged from Athena. RFC 1510 is the document Microsoft engineers read when they chose Kerberos v5 as the Windows 2000 default authentication protocol; the krbtgt account became part of the AD schema at the Windows 2000 ship date (RTM December 15, 1999; general availability February 17, 2000) [@windows-2000]. The Microsoft Learn default-accounts page binds the two specifications to the same account: "KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120" [@ms-default-accounts].

RFC 4120, published in July 2005 by Neuman, Yu, Hartman, and Raeburn, obsoleted RFC 1510 [@rfc4120]. The principal name carried forward unchanged again. Section 5.3 defines the wire format of a ticket; §6.2 defines the principal-name convention. Microsoft Open Specifications then published the first [MS-KILE] revision in March 2007, documenting the Windows wire profile on top of RFC 4120. The current revision -- 47.0, dated April 27, 2026 -- still says the same thing: the krbtgt long-term key encrypts every TGT [@mskile]. The Microsoft overlay on top of the IETF specification is the AD-account-management surface: RID 502 fixed, password system-generated, password-history-of-2, disabled-for-interactive-logon, automatic provisioning at first-DC promotion [@ms-default-accounts][@ms-forest-recovery].

Every Kerberos domain on the public Internet today has a krbtgt principal in it. The name has not moved in thirty-eight years. Only the AD-specific overlay is what gives this article its Windows-specific subject; the protocol substrate is older than the attack surface by twenty-six years.

The principal name and the trust property are nearly forty years old. The exploit chain that targets them is twelve. The interesting question is what happened in the twelve years that turned an academic design decision into the most consequential single key in enterprise computing. That story has a beginning at Black Hat USA on August 7, 2014.

5. The Attack Cascade, 2014 to 2024

Six generations of attack span ten years. None of them found a way to forge a TGT without the krbtgt key; the search space is mathematically closed in that direction. What they did instead is get progressively better at hiding the forgery inside genuine-looking wire traffic. By 2022, the forgery and the legitimate TGT are wire-indistinguishable. Here is how that arc unfolded.

gantt title Attack and defence generations dateFormat YYYY-MM-DD axisFormat %Y section Attack Gen 0 Academic baseline :done, g0, 2000-02-01, 2014-08-05 Gen 1 MS14-068 PAC forgery :crit, g1, 2014-11-18, 90d Gen 2 Golden Ticket :crit, g2, 2014-08-07, 2920d Gen 3 Silver Ticket : g3, 2015-01-01, 4000d Gen 4 Diamond Ticket :crit, g4, 2022-06-21, 1700d Gen 5 Sapphire Ticket :crit, g5, 2022-10-15, 1300d section Defence MS14-068 patch :done, d1, 2014-11-18, 30d MDI alert family :done, d2, 2016-01-01, 800d Full PAC Signature audit :done, d3, 2022-12-13, 210d Full PAC Signature enforce :done, d4, 2023-07-11, 90d Compatibility removed :done, d5, 2023-10-10, 30d

Generation 0 (pre-November 2014): the academic baseline

Two assumptions held for fourteen years between Windows 2000 RTM and Black Hat USA 2014. First, the PAC's two signatures -- the Server Signature and the KDC Signature -- were treated as adequate; the [MS-PAC] specification required the KDC Signature to be a keyed HMAC under the krbtgt key, but Windows KDCs in practice accepted weaker non-keyed checksums on it (CRC32, RSA-MD5) [@mspac][@ms14068]. Second, the long-term krbtgt key was held only on writeable DCs and was considered unreachable to remote attackers because no remote primitive existed to extract it. Both assumptions failed within months of each other. The MS14-068 disclosure broke the first; the productionised DCSync primitive in Mimikatz broke the second.

Generation 1 (November 18, 2014): MS14-068 and CVE-2014-6324

On November 18, 2014, Microsoft published security bulletin MS14-068, "Vulnerability in Kerberos Could Allow Elevation of Privilege (3011780)" [@ms14068]. The disclosure: the KDC validated PACs using a checksum algorithm that did not actually depend on the krbtgt key. Any authenticated domain user could forge a PAC asserting Domain Admin group membership, attach it to an otherwise-valid AS-REQ exchange, and the KDC would accept the forgery. The NVD entry for CVE-2014-6324 records that the bug "allows remote authenticated domain users to obtain domain administrator privileges via a forged signature in a ticket, as exploited in the wild in November 2014, aka 'Kerberos Checksum Vulnerability'" [@cve-2014-6324]. CVSS 9.0. Critical for every supported Windows Server SKU. Exploited in the wild within hours of the bulletin.

Discovery credit for MS14-068 appears across Metasploit module authorship, AttackerKB, and several practitioner write-ups as Tom Maddock. The MSRC bulletin verbatim says only "privately reported" and does not name the reporter publicly [@ms14068]. The Maddock attribution is folk knowledge; the MSRC primary does not confirm it.

Microsoft's patch replaced the weak checksum with a real keyed HMAC under the krbtgt key, the same construction the [MS-PAC] document specifies today. The patch was correct: it restored PAC integrity to actual dependence on a real secret. It also, as a side-effect, elevated the krbtgt key from "an important secret in the directory" to "the load-bearing secret of every authentication decision in the domain." From November 18, 2014 onward, an attacker who held the krbtgt key did not just hold a useful credential; the attacker held the only credential the KDC could not check above.

Key idea: The MS14-068 patch was correct -- it restored PAC integrity to dependence on the krbtgt key. Its side-effect was to elevate the krbtgt key from "important" to "load-bearing for every authentication decision in the domain." From November 18, 2014 onward, the krbtgt key was the single secret worth attacking directly.

Generation 2 (August 7, 2014): Golden Ticket

Skip Duckwall and Benjamin Delpy presented "Abusing Microsoft Kerberos: Sorry you guys don't get it" at Black Hat USA on August 7, 2014 [@infocondb-bh2014]. The technique they demonstrated is what Sean Metcalf later popularised as the Golden Ticket: with the krbtgt key in hand, an attacker forges a TGT from scratch for any principal SID with any group memberships [@adsec-1640]. The KDC validates the TGT by decrypting enc-part with the krbtgt key. There is no upstream authority to check, because krbtgt is the authority. MITRE T1558.001 codifies the technique [@mitre-t1558001]; Benjamin Delpy's Mimikatz kerberos::golden command operationalises it [@mimikatz].

sequenceDiagram participant A as Attacker (holds krbtgt key) participant L as Local Kerberos cache participant K as KDC on a DC participant S as Target service A->>A: Choose target SID and groups A->>A: Build EncTicketPart locally A->>A: HMAC PAC signatures under krbtgt key A->>A: AES-encrypt enc-part under krbtgt key A->>L: kerberos::ptt -- inject ticket L->>K: TGS-REQ presenting forged TGT K->>K: Decrypt TGT with krbtgt key -- valid K->>L: TGS-REP for target service L->>S: Present service ticket -- access granted

The Golden Ticket works because of the single-key trust property the 1988 design chose. There is nothing in the protocol that asks "is this TGT in the KDC's issuance log?" The TGT is self-verifying. If it decrypts and its signatures validate under the key, it is, by definition, a TGT.

Why, then, does Golden Ticket sometimes get caught? Because the default Mimikatz invocation leaves four observable artefacts that Microsoft Defender for Identity ships dedicated alerts for, under the umbrella of the Suspected-Golden-Ticket alert family [@mdi-classic][@mdi-credential]. Mimikatz historically defaulted to RC4-HMAC encryption (enctype 23), which is anomalous on a modern AD where AES is standard. Mimikatz historically defaulted to a ten-year ticket lifetime, against the AD MaxTicketAge default of ten hours. The attacker frequently asserts groups the user does not actually hold, which produces a "forged authorization data" anomaly. And the attacker sometimes forges a ticket for an account that does not exist in the directory at all, which produces a "nonexistent account" anomaly. Microsoft's live MDI alerts page enumerates six External IDs in the family: 2009 (encryption downgrade), 2013 (forged authorization data), 2022 (time anomaly), 2027 (nonexistent account), 2032 (ticket anomaly), and 2040 (ticket anomaly using RBCD) [@mdi-classic].

The structural observation: every alert in this family detects symptoms of forging from scratch. None of them detects the primitive of holding the krbtgt key. That distinction is what makes Generation 4 (Diamond) and Generation 5 (Sapphire) interesting.

Generation 3 (parallel path): Silver Ticket

Silver Tickets forge a service ticket (TGS) under a captured service-account key. They sidestep the krbtgt key entirely; the KDC is never involved in the forgery, and the forgery validates only against the one service whose key was captured. MITRE T1558.002 catalogues the technique [@mitre-t1558002]. Mentioned here so the question stops being asked. Silver Tickets are a sibling technique that targets a different trust root (per-service account keys), not the krbtgt key.

Generation 4 (June 2022): Diamond Ticket

In June 2022, Andrew Schwartz at TrustedSec and Charlie Clark at Semperis co-published "A Diamond in the Ruff," documenting a refinement of Golden Ticket that defeats every PAC-content anomaly detection in one stroke [@trustedsec-diamond][@semperis-diamond]. The technique: instead of forging the TGT from scratch, the attacker requests a real TGT from the KDC, then decrypts its enc-part using the held krbtgt key, modifies the PAC contents, re-signs the PAC under the krbtgt key, re-encrypts the enc-part, and walks away with a ticket whose every wire property -- sname, cname, authtime skew matching the real KDC's clock, plausible endtime, AES-256 envelope -- looks like a legitimate KDC-issued artefact.

sequenceDiagram participant A as Attacker (low-priv user, holds krbtgt key) participant K as KDC on a DC participant L as Local Kerberos cache participant S as Target service A->>K: AS-REQ for low-priv user K->>A: Real TGT, encrypted under krbtgt key A->>A: Decrypt enc-part with held krbtgt key A->>A: Modify PAC SIDs to Domain Admins A->>A: Recompute PAC signatures under krbtgt key A->>A: Re-encrypt enc-part under krbtgt key A->>L: ptt -- inject modified TGT L->>K: TGS-REQ presenting Diamond TGT K->>K: Decrypt -- valid, signatures match K->>L: TGS-REP for target service L->>S: Access granted as Domain Admin

Every MDI Suspected-Golden-Ticket detection disappears, by construction. The encryption type is AES-256 because the KDC issued it that way. The lifetime matches the AD policy because the KDC set it that way. The cname matches a real account because the attacker requested the TGT as a real low-privilege account they own. The only thing the attacker changed is the group SIDs inside the PAC, and the PAC signatures revalidate because the attacker recomputed them under the same krbtgt key the KDC would have used.

TrustedSec verbatim: Diamond "would almost certainly require access to the AES256 key" [@trustedsec-diamond]. The KDC issued the real TGT in AES-256, so the attacker needs the AES-256 key to decrypt and re-encrypt -- not just the RC4 NTLM hash that the classic Golden Ticket can use.

The Diamond Ticket disclosure pointed at an architectural problem: with the krbtgt key in hand, every PAC-content anomaly detection is defeated. Microsoft's structural answer was the Full PAC Signature in November 2022. We come to that in Generation 6.

Generation 5 (October 2022): Sapphire Ticket

Charlie Bromberg, who publishes under the handle Shutdown (@_nwodtuhs) at Synacktiv and maintains The Hacker Recipes wiki, disclosed Sapphire Ticket in October 2022 [@hackrecipes-sapphire][@shutdownrepo-sapphire]. Where Diamond modifies the PAC, Sapphire splices the PAC. The procedure abuses two Kerberos extensions in combination -- Service-for-User-to-Self (S4U2self) and User-to-User (U2U) -- to coerce the KDC into issuing a service ticket whose embedded PAC describes a target user the attacker wishes to impersonate. The attacker then extracts that genuine PAC from the service ticket and embeds it, unchanged, in a freshly constructed TGT signed under the held krbtgt key.

A Kerberos extension that lets a service request a ticket *to itself*, on behalf of another user, without that user presenting credentials. Originally designed for protocol-transition scenarios (a web service accepting forms-based auth and translating it to Kerberos for downstream calls). Defined in [MS-SFU] (Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol); referenced from [MS-KILE] [@mssfu]. A Kerberos extension defined in RFC 4120 §3.7 that allows a ticket to be encrypted under the recipient's session key rather than its long-term key, enabling two clients to authenticate to each other without either being a KDC-registered service [@rfc4120]. sequenceDiagram participant A as Attacker (low-priv user, holds krbtgt key) participant K as KDC on a DC participant L as Local Kerberos cache participant S as Target service A->>K: AS-REQ for low-priv user K->>A: Real attacker TGT A->>K: S4U2self + U2U TGS-REQ for target user K->>A: TGS containing target user's genuine PAC A->>A: Extract genuine PAC from TGS A->>A: Build new TGT, embed genuine PAC A->>A: Sign three PAC signatures under krbtgt key A->>A: Encrypt enc-part under krbtgt key A->>L: ptt -- inject Sapphire TGT L->>K: TGS-REQ presenting Sapphire TGT K->>K: Decrypt -- valid, PAC is genuine K->>L: TGS-REP for target service L->>S: Access granted as target user

By construction, there is no PAC-content anomaly to detect: the PAC inside the resulting TGT is literally a PAC the KDC issued for the target user, because the KDC did issue it. The PAC's three signatures revalidate because the attacker held the krbtgt key to sign them; if Microsoft validates the Full PAC Signature on incoming tickets, that signature also validates because the attacker computed it under the same krbtgt key. Detection must move to traffic-flow analysis -- specifically, the anomalous S4U2self plus U2U TGS-REQ sequence on the wire -- and as of May 2026 no vendor has shipped a clean canonical default-enabled analytic for that signal [@unit42-gemstones].

The Sapphire Ticket disclosure is widely misattributed to Charlie Clark (Semperis). The primary tooling artefact -- the Impacket PR #1411 conversation thread -- addresses the author as @ShutdownRepo, who is Charlie Bromberg of Synacktiv [@impacket-1411]. The Hacker Recipes wiki and pgj11.com both confirm Bromberg as the author of record [@hackrecipes-sapphire][@pgj11]. The misattribution conflates Sapphire with Clark's separate "AS Requested Service Tickets" technique.

The empirical artefact is the Impacket pull request #1411, in which Bromberg added the -impersonate flag to ticketer.py to put the tool into "sapphire ticket mode" [@impacket-1411][@shutdownrepo-sapphire]. Palo Alto Unit 42's "Precious Gemstones" survey is the vendor-side state-of-the-art summary [@unit42-gemstones].

Generation 6 (November 2022 to October 2023): KrbtgtFullPacSignature

Microsoft's formal response to the post-2014 attack arc shipped as KB5020805 starting November 8, 2022, addressing CVE-2022-37967 [@kb5020805][@cve-2022-37967]. The fix adds a new PAC signature -- the Full PAC Signature -- computed by the KDC over the entire PAC including the older two signatures, validated on incoming tickets, and rolled out across five deployment phases:

Phase	Date	Mode	`KrbtgtFullPacSignature` value
Initial Deployment	November 8, 2022	Signatures added, validation disabled	1 (Compatibility)
Second Deployment	December 13, 2022	Audit mode default	2 (Audit)
Third Deployment	June 13, 2023	Cannot disable signature addition	(value 0 removed)
Default Enforcement	July 11, 2023	Enforcement default	3 (Enforcement)
Removal of Compatibility	October 10, 2023	Audit removed, Enforcement permanent	(registry key removed)

KB5020805 documents the final state verbatim: "Windows updates released on or after October 10, 2023 will do the following: Removes support for the registry subkey KrbtgtFullPacSignature. Removes support for Audit mode. All service tickets without the new PAC signatures will be denied authentication" [@kb5020805].

Note: The KB number for KrbtgtFullPacSignature is KB5020805, not KB5021131. KB5021131 is the paired but distinct KB for CVE-2022-37966 (encryption-type enforcement). The PAC-signature-specific KB is KB5020805. Secondary sources routinely confuse the two.

Here is the structural fact. The Full PAC Signature is also computed under the krbtgt key. So an attacker who holds the krbtgt key still mints fully-validating tickets, including:

Sapphire Tickets, which never modify the PAC at all; the existing signatures the KDC issued are valid by construction, the Full PAC Signature included.
Recomputed Diamond Tickets, in which the attacker simply computes the Full PAC Signature alongside the older KDC signature in the same step, because both depend on the same key the attacker holds.

KrbtgtFullPacSignature retired one specific class of attack (Diamond Tickets that did not recompute the Full PAC Signature). It did not retire the underlying primitive (TGT forgery from a known krbtgt key). The PAC signature surface in Section 3 -- all three signatures terminating at the same key -- is exactly why this is so.

Key idea: The Full PAC Signature was Microsoft's structural response to Diamond Ticket. It is itself computed under the krbtgt key. So an attacker who holds the krbtgt key recomputes it in the same step as the KDC signature -- and Sapphire Tickets, which never modify the PAC at all, are unaffected by construction. CVE-2022-37967 retired one class of attack (PAC-modifying Diamond variants); it did not retire the primitive.

Comparing the three forgery variants

Dimension	Golden	Diamond	Sapphire
Requires krbtgt key?	Yes	Yes (AES-256)	Yes (AES-256)
Calls the KDC?	No (forges from scratch)	Yes (real AS-REQ)	Yes (AS-REQ + S4U2self+U2U)
Modifies the PAC?	Builds it from scratch	Yes (group SIDs)	No (genuine PAC)
Defeats MDI encryption downgrade alert?	No (defaults RC4)	Yes (real AES)	Yes (real AES)
Defeats MDI time-anomaly alert?	No (defaults 10y)	Yes (KDC lifetime)	Yes (KDC lifetime)
Defeats MDI forged-auth-data alert?	No	Yes (still triggers if group mismatch detected via other means)	Yes (PAC is genuine)
Defeats Full PAC Signature (post-July 2023)?	Yes (recomputed under held key)	Yes (recomputed)	Yes (genuine PAC)
Known wire-residual?	Encryption type, lifetime, groups	Re-encryption-under-held-key timing	S4U2self+U2U conjunction

Six generations from MS14-068 to KrbtgtFullPacSignature, and the residual primitive is exactly what the 1988 paper described: hold the key, mint the ticket. So what does the detection topology in 2026 actually catch?

6. The Detection Stack in 2026

Detection of krbtgt-class attacks in 2026 is a four-layer stack. Each layer has a specific class of signal it reads, a specific class of attack it catches, and a specific gap that the next layer is supposed to close. Three of the four layers have a known gap above them. The fourth has nothing above it.

flowchart TD L4["Layer 4 -- S4U2self plus U2U residual (no vendor analytic shipped)"] L3["Layer 3 -- Network/SIEM (Sentinel, Splunk T1558.001)"] L2["Layer 2 -- Behavioural (MDI Suspected-Golden-Ticket family)"] L1["Layer 1 -- Posture (BloodHound DCSync edge)"] KEY["krbtgt long-term key (the attacker's objective)"] L1 --> L2 L2 --> L3 L3 --> L4 L4 --> KEY

Layer 1: posture (BloodHound DCSync edge)

The posture layer asks a question with no per-event component: "Who has rights that could extract the krbtgt key, regardless of whether they have used those rights?" In Active Directory terms, the answer is "anyone holding DS-Replication-Get-Changes plus DS-Replication-Get-Changes-All rights against a writeable DC, plus anyone who holds privileges that allow them to grant those rights to themselves." BloodHound encodes the answer as a DCSync edge in its graph; the canonical community Cypher query is MATCH (u)-[:DCSync]->(d:Domain) RETURN u, d. The current shipping release of BloodHound Community Edition is v9.1.0, dated 2026-05-06 per the release notes [@bloodhound-notes].

A replication primitive Mimikatz first productionised in August 2015. The attacker invokes the `DRSGetNCChanges` API call against a writeable domain controller, masquerading as a peer DC, and the target DC obligingly streams back the requested account secrets including the krbtgt long-term key. MITRE T1003.006 catalogues the technique [@mitre-t1003006]. Sean Metcalf's adsecurity.org write-up notes "DCSync was written by Benjamin Delpy and Vincent Le Toux" [@adsec-1729].

What this layer detects: any principal whose existing AD permissions create a path to the krbtgt key. What this layer misses: any attacker who already has the key. Posture is preventive, not detective. By the time the attacker is invoking kerberos::golden, the posture layer has already missed its window.

Layer 2: behavioural (Microsoft Defender for Identity)

Microsoft Defender for Identity ships an alert family covering classic Golden-Ticket-from-Mimikatz behaviour. The live MDI classic alerts page enumerates six Suspected-Golden-Ticket External IDs: 2009 (encryption downgrade), 2013 (forged authorization data), 2022 (time anomaly), 2027 (nonexistent account), 2032 (ticket anomaly), and 2040 (ticket anomaly using RBCD) [@mdi-classic]. The Credential access section adds External ID 2006 for "Suspected DCSync attack" on the extraction side [@mdi-classic].

What this layer detects: the Mimikatz Golden Ticket defaults plus the DCSync extraction primitive that produces the krbtgt key in the first place. What this layer misses: Diamond and Sapphire by construction. Diamond removes the PAC-content anomalies because every artefact except the modified group SIDs comes from the real KDC. Sapphire defeats PAC-content anomaly detection entirely by using a PAC the KDC genuinely issued via S4U2self plus U2U.

The MDI credential-access alerts page is the entry point to the family in the modern Microsoft Defender XDR console layout [@mdi-credential].

Layer 3: network and SIEM (Sentinel, Splunk)

Multi-vendor SIEM content packs ship analytic rules covering Kerberos behaviours flagged under MITRE T1558.001. Splunk's research catalogue contains the canonical example: "Kerberos Service Ticket Request Using RC4 Encryption" detects TGS-REQ traffic with encryption-type 0x17 (RC4-HMAC), leveraging Windows Event 4769 from the DCs [@splunk-7d9]. Microsoft Sentinel ships parallel rules under the Microsoft Defender XDR content connector. The pattern these analytics share is reliance on encryption-type anomalies, group-membership anomalies, or lifetime anomalies that appear in Windows event logs after the fact.

What this layer detects: signature-style indicators of Golden Ticket behaviour on the wire and in the DC event log. What this layer misses: the same encryption-downgrade dependency MDI's alert 2009 has. The Splunk analytic verbatim acknowledges its own limit: "This detection may be bypassed if attackers use the AES key instead of the NTLM hash" [@splunk-7d9]. Diamond and Sapphire both use the AES-256 key. Both walk through this layer untouched.

Note: Microsoft Sentinel ships rules called "Kerberoasting" that target MITRE T1558.003 (extracting service-account secrets by requesting SPN-bearing service tickets and brute-forcing the resulting RC4-encrypted blobs offline). Those rules target service accounts with SPNs registered against them. They are not a krbtgt detection asset. The krbtgt account does not have an SPN that any client can request a TGS for; the relevant Sentinel content for krbtgt-class attacks is the T1558.001 Golden-Ticket and Kerberos-anomaly analytic family.

Layer 4: the Sapphire residual

What would catch a Sapphire Ticket? The only wire-observable residual of the technique is the conjunction of (a) a TGS-REQ specifying the S4U2self flag, and (b) the same TGT being used to address a User-to-User request to the KDC. No other layer of the stack reads this signal because no other attack has historically produced it as a precondition.

What ships: nothing canonical. SpecterOps and the BloodHound content team have signalled graph-query work on the U2U TGS issuance pattern in 2026 trend reports [@bloodhound-notes], but no shipped default-enabled analytic. Palo Alto Unit 42's "Precious Gemstones" survey describes Cortex XDR detection-attempt heuristics but does not publish the rule [@unit42-gemstones]. The gap is engineering, not theoretical: the signal exists, the analytic to read it has simply not been packaged.

Note: No vendor analytic shipped for the S4U2self plus U2U conjunction as of May 2026. Sapphire is the current frontier and the article's "what 2026 still cannot do" gap. An attacker who holds the krbtgt key and uses the Sapphire technique walks past every shipping detection layer.

SpecterOps and the BloodHound content team have signalled graph-query work on the U2U TGS issuance pattern; Palo Alto Unit 42's "Precious Gemstones" survey describes Cortex XDR detection-attempt heuristics [@unit42-gemstones]. Neither has shipped a clean canonical default-enabled analytic. The gap is engineering, not theoretical, and it is the active research front for the 2026 to 2028 cycle.

Defensive method matrix

Method	Catches Golden?	Catches Diamond?	Catches Sapphire?	Layer
BloodHound DCSync edge	preventive only	preventive only	preventive only	1
MDI Suspected-Golden-Ticket (4 alerts)	yes	no	no	2
MDI Suspected DCSync (ID 2006)	extraction step only	extraction step only	extraction step only	2
Sentinel / Splunk T1558.001 RC4 rule	yes (if RC4)	no	no	3
Sentinel Kerberos-anomaly content pack	partial (lifetime/groups)	no	no	3
Full PAC Signature (post-July 2023)	n/a (already signed correctly)	retires non-recomputing variants	no	n/a (cryptographic enforcement, not detection)
S4U2self+U2U conjunction analytic	n/a	n/a	would catch	4 (not shipped)

Adjacent T1558 family techniques that are not krbtgt detections

Technique	What it targets	krbtgt detection?
T1558.002 Silver Ticket	service-account long-term keys	no
T1558.003 Kerberoasting	SPN-bearing service accounts via offline RC4 crack	no
T1558.004 AS-REP Roasting	accounts with pre-auth disabled	no
OverPass-the-Hash	user NTLM hashes via Kerberos PA-DATA	no

Detection in 2026 is a four-layer stack, and three of the layers leave gaps the next layer is supposed to close. The fourth gap -- the Sapphire residual -- has no layer above it. When the gaps close enough to confirm a krbtgt compromise, what does recovery actually look like?

7. Recovery: What the Two-Reset Procedure Actually Does

The Microsoft AD Forest Recovery page states the procedure verbatim:

"You should perform this operation twice. You must wait 10 hours between password resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value." -- and -- "The password history value for the krbtgt account is 2, meaning it includes the two most recent passwords. By resetting the password twice you effectively clear any old passwords from the history, so there's no way another DC replicates with this DC by using an old password." [@ms-forest-recovery]

What exactly do those two resets buy, and what do they not buy?

The mechanics of two-slot eviction

The krbtgt account, like every other AD account, stores both current and previous keys. A TGT issued at time $T = 0$ under key $K_0$ continues to validate after a rotation at $T = T_1$ (when $K_1$ becomes current and $K_0$ moves to the previous slot), because the KDC tries both keys during the in-flight validation window. One rotation fills the previous slot with the now-replaced $K_0$; the second rotation, separated by at least MaxTicketAge so that all $K_0$-signed TGTs have expired naturally, fills the previous slot with $K_1$ and evicts $K_0$ entirely. After the second rotation completes and replicates, no key in the krbtgt account matches the attacker's extracted $K_0$; forged TGTs from that key fail validation cleanly [@ms-forest-recovery].

The Kerberos policy value that bounds the lifetime of a Ticket-Granting Ticket from the moment of issuance. The Active Directory default is 10 hours, configured via the Default Domain Policy. The AD Forest Recovery procedure waits at least `MaxTicketAge` between krbtgt resets to ensure no in-flight TGT outlives the period between the two rotations [@ms-forest-recovery]. flowchart LR A0["T=0: K_0 current, K_prior previous"] --> A1["T=T_1: reset 1 -- K_1 current, K_0 previous"] A1 --> A2["T_1 + 10h: K_1 still current, K_0 still previous"] A2 --> A3["T=T_2 (≥ T_1 + 10h): reset 2 -- K_2 current, K_1 previous"] A3 --> A4["After replication: K_0 evicted from both slots"]

The 10-hour wait between resets is not a Microsoft convenience choice; it is a cryptographic requirement. If the second reset lands before all $K_0$-signed TGTs have expired naturally, some of those tickets will hit a DC whose previous slot now holds $K_1$ rather than $K_0$, and the KDC will reject them. This is what KB5020805's PAC-signature deployment phases also had to navigate during the November 2022 to October 2023 rollout: signature additions and validation transitions had to bracket the maximum in-flight ticket lifetime [@kb5020805].

{` // Model the krbtgt account as a two-slot store; simulate the two-reset procedure. function simulate(events) { const slots = { current: "K_prior", previous: null }; let stolen = null; for (const ev of events) { if (ev.kind === "compromise") { stolen = slots.current; } else if (ev.kind === "reset") { slots.previous = slots.current; slots.current = ev.newKey; } const validates = stolen && (stolen === slots.current || stolen === slots.previous); console.log( "[t=" + ev.t.toString().padStart(3) + "h]", ev.kind.padEnd(11), "current=" + slots.current, "prev=" + (slots.previous ?? "-"), "attacker_validates=" + validates ); } }

simulate([ { t: 0, kind: "issue" }, { t: 1, kind: "compromise" }, // attacker stores K_prior as stolen { t: 3, kind: "reset", newKey: "K_1" }, { t: 13, kind: "reset", newKey: "K_2" }, // ≥ MaxTicketAge later { t: 14, kind: "issue" }, ]); `}

`New-KrbtgtKeys.ps1`

Microsoft's reference automation for the procedure is New-KrbtgtKeys.ps1, originally distributed as an MSDN Gallery script and currently hosted in the microsoftarchive GitHub organisation. The repository banner reads, verbatim: "This repository was archived by the owner on Mar 8, 2024. It is now read-only" [@new-krbtgt-keys]. The script remains the canonical reference for the rotation procedure, including pre-reset and post-reset replication-health checks; it is simply no longer actively maintained. Operators in 2026 commonly fork it locally or wrap the same Set-ADAccountPassword plus replication-status pattern in their own runbooks.

What two-reset does

Cryptographically invalidates previously-forged TGTs after the second reset replicates fully across all writeable DCs. This is unambiguous and well-documented; the Microsoft Learn page is the primary [@ms-forest-recovery]. After step 3 (the second reset) has replicated, no TGT signed under the pre-compromise key validates anywhere in the domain.

What two-reset does not do

Any attacker who held the krbtgt key has typically already installed parallel persistence. SpecterOps's "Domain of Thrones Part II" by Nico Shyne and Josh Prager, published November 6, 2023, names the rotation list verbatim: "Machine accounts ... User accounts ... Service accounts -- Per domain KRBTGT account ... Trust keys and objects related to trust of all other domains; Group-managed service accounts; Key distribution service root keys" [@specterops-dot2]. The same playbook enumerates the persistence vectors an attacker with krbtgt access typically establishes: AdminSDHolder ACL edits, AD CS template alternates spanning the ESC1 through ESC8 abuse classes (canonically catalogued in Schroeder and Christensen's "Certified Pre-Owned," SpecterOps, June 2021) [@certified-pre-owned], SID History entries, machine-account secret retention, KDS root key exfiltration, trust-key compromise, and DSRM password exfiltration. Two-reset rotates the krbtgt key only; the rest of the trust-root set is untouched [@specterops-dot1][@specterops-dot2].

Key idea: Two-reset rotation cryptographically invalidates previously-forged TGTs. It does NOT rotate any of the other secrets an attacker who held the krbtgt key has typically already installed: AdminSDHolder edits, ADCS templates, SID History, machine-account secrets, KDS root keys, trust keys, DSRM passwords. This is why confirmed krbtgt compromise is a forest-rebuild event, not a key-rotation event.

Two-reset rotation is the cryptographic finish; the operational finish spans the rest of the Domain-of-Thrones surface, and the rotation alone cannot reach it. The single-sentence punchline of the article lands at the end of §11.

Why does Microsoft's AD Forest Recovery page treat krbtgt rotation as a recoverable rotation event while Mandiant-style and SpecterOps-style playbooks treat confirmed krbtgt compromise as a forest-rebuild event? Both statements are true at once. Microsoft documents the *cryptographic* recovery, which terminates at the krbtgt key. The IR playbooks document the *operational* recovery, which spans seven additional secret classes whose compromise the krbtgt holder typically also achieved. The cryptographic recovery is necessary and well-bounded; the operational recovery is necessary and not bounded by the same key.

Recovery has two pieces: a fast cryptographic part (two resets, well-documented) and a slow operational part (seven other secret classes, days to weeks). Both are necessary. Neither is sufficient. Even the combined procedure leaves three structural residuals, which the next section names.

8. Theoretical Limits and Open Problems

Even with the full Domain-of-Thrones rotation surface executed correctly, three structural residuals remain. Each has a current best-partial-result; none has a closed solution.

(a) The pre-second-reset TGT-lifetime window

Any TGT minted from the compromised krbtgt key between the moment of compromise and the moment the second reset replicates remains valid until naturally expired or until step 3 lands. Mimikatz's default 10-year lifetime makes this a years-long window if the attacker pre-minted tickets and a careless DC missed the time-anomaly signal. The MDI Suspected-Golden-Ticket family includes a time-anomaly alert (the External ID 2022 sibling) [@mdi-classic] that reads the difference between plausible and implausible ticket lifetimes. The window is bounded above by the AD MaxTicketAge floor: at minimum, the procedure must take 10 hours of wall-clock per Microsoft's own guidance [@ms-forest-recovery]. Below that floor the cryptographic invalidation does not finish.

The mitigation is procedural: between detection and the start of the rotation, the IR team treats every TGT in the domain as suspect. In practice that means rejecting cached tickets at high-value services, forcing a TGT renewal cycle, and watching the time-anomaly alert closely. The mitigation is not perfect; an attacker who minted tickets with realistic 10-hour lifetimes inside the typical AD policy survives this residual entirely.

(b) AD CS alternate persistence (the ESC class)

An attacker who held the krbtgt key long enough to also touch AD Certificate Services has often installed an ESC-class alternate-identity persistence: a backdoored certificate template allowing Domain Admin certificate issuance (ESC1), a misconfigured EnrolleeSuppliesSubject template (ESC4), an HTTP-bound CA endpoint vulnerable to NTLM relay (ESC8). The ESC class taxonomy is catalogued in Schroeder and Christensen's "Certified Pre-Owned" white paper (SpecterOps, June 2021) [@certified-pre-owned]. The compromised template or endpoint survives krbtgt rotation entirely. The CA private key is its own trust root, parallel to (not subordinate to) the krbtgt key. Domain-of-Thrones Part II names ADCS as a separate rotation workstream that must be addressed alongside the krbtgt reset [@specterops-dot2].

The structural fact: a domain with AD CS deployed has at least two cryptographic trust roots (krbtgt long-term key + CA private key) whose compromises are both recoverable only through different mechanisms. PKINIT, the Kerberos pre-authentication extension that validates certificate-bearing AS-REQs, accepts identities the CA chain attests to. Compromise of the CA chain yields valid Kerberos authentication as any principal, by a different mechanism than holding the krbtgt key, with the same end result.

(c) Cross-domain trust-key compromise

Within a multi-domain forest, the krbtgt of each domain is trusted by the others through inter-domain trust keys. A krbtgt compromise in a child domain can become a forest-level event if the trust topology is not hardened: SID Filtering misconfigurations, missing Selective Authentication on outbound trusts, or stale forest-trust artefacts from earlier domain migrations all extend the blast radius beyond the directly-compromised domain. Microsoft's "Recover from systemic identity compromise" guidance and the AD Forest Recovery procedure index together cover the cross-domain rotation requirements; Domain-of-Thrones Part II's "Trust keys and objects related to trust of all other domains" entry is the concise operational statement [@specterops-dot2].

The mitigation is architectural: domain-isolation discipline at the design phase plus Selective Authentication on all inbound trusts. After the fact, every domain whose krbtgt the compromised domain trusted (directly or transitively) becomes part of the rotation surface.

(d) The HSM-bound krbtgt aspiration

A theoretically clean solution exists in the literature: split the krbtgt key material such that no single party -- including the DC's own KDC service -- could read the full key in cleartext. The construction would be a hardware-security-module-bound krbtgt key (the HSM exposes only sign and verify operations on a key it never releases), or a threshold-cryptography scheme (the key is reconstructed across $n$ DCs, $t$ of which must cooperate per ticket-signing operation). Either construction would close the underlying primitive by making the krbtgt key unreadable in cleartext to anyone with code execution on a DC.

Neither construction is supported by any [MS-KILE] revision through 47.0 dated April 27, 2026 [@mskile]. Neither is on any published Microsoft roadmap as of May 2026. The closest analogues that have shipped -- LSAISO/Credential Guard's VBS trustlet for LSASS secrets on workstations and member servers -- explicitly omit the writeable-DC case by design, because a writeable DC must read the krbtgt key to issue tickets.

Even after two-reset and Domain of Thrones, three residuals remain: a window of time, an alternate trust root, and a topology problem. None of them are theoretical -- all three are operational realities documented in 2024-2026 incident-response practice. But they raise a different question: how does the krbtgt key compare to the other secrets in an AD trust-root set?

9. Where KRBTGT Sits in the AD Trust-Root Set

A correction to a framing that appears in many secondary write-ups: the krbtgt long-term key is one of a small set of "AD trust roots," not the only one. The framing matters because the rotation playbook in Section 7 lists seven secret classes for a reason: each is a candidate trust root that survives compromise of any other.

KRBTGT long-term key. Issues TGTs for all principals in the domain. Unique property within the Kerberos trust root: holding it forges TGTs for arbitrary principals, including ones that do not exist in the directory. Rotation: the two-reset, ten-hour-interval procedure on the AD Forest Recovery page [@ms-forest-recovery].

AD CS root CA private key. Issues certificates that PKINIT trusts for Kerberos pre-authentication. Compromise yields Kerberos auth as any principal via PKINIT -- a different mechanism with the same end result. Rotation: CA hierarchy rebuild, significantly more expensive than krbtgt rotation. SpecterOps "Certified Pre-Owned" (Schroeder + Christensen, June 2021) is the canonical primary on the ESC-class abuses of this trust root, cross-referenced in Domain of Thrones Part II [@certified-pre-owned][@specterops-dot2].

KDS root key. Group Managed Service Account passwords are derived deterministically from a KDS root key plus a per-account msDS-ManagedPasswordId. Compromise of the KDS root key reads every gMSA password in the forest. Different blast radius (service accounts only). Rotation: KDS root key rotation followed by gMSA cycling [@specterops-dot2].

Per-domain inter-domain trust keys. Bridge Kerberos trust between domains in a forest or across explicit external trusts. Compromise yields cross-domain TGT minting. Rotation: per-trust password rotation, with SID Filtering and Selective Authentication audits as the standard hardening procedure.

DSRM passwords on writeable DCs. Directory Services Restore Mode is a local-admin equivalent at the DC level; compromise yields a local logon to the DC, which then enables many other paths including direct read of the krbtgt key from ntds.dit. Rotation: per-DC DSRM password rotation [@specterops-dot2].

The precise framing

Within the Kerberos trust root of a single domain, the krbtgt key occupies a unique position: it is the issuer of every TGT, and forging a TGT requires exactly this key. At the forest-AD-trust-graph level, the krbtgt key is one of a handful of high-cost-to-rotate trust roots, not the only one. The framing matters because it explains why Domain of Thrones Part II lists seven rotation workstreams: each is a candidate path to the same end result (arbitrary identity in the forest) through a different cryptographic mechanism.

Five trust roots, one (krbtgt) with a unique forge-arbitrary-TGTs property, all five surfacing in the rotation list. With the trust-root topology mapped, the article's last technical job is the practical playbook: what does the reader actually do tomorrow morning?

10. Practical Guide: The Rotation and Detection Playbook

Four lanes. Each lane is a concrete action a reader can execute starting tomorrow morning.

Note: Lane 1: Preventive hygiene -- rotate krbtgt twice a year on a calendar schedule and audit who can DCSync. Lane 2: Detection deployment -- ship MDI Suspected-Golden-Ticket alerts plus SIEM T1558.001 content. Lane 3: Confirmed-compromise response -- two-reset rotation followed by the Domain-of-Thrones surface. Lane 4: What does NOT work -- four traps to avoid.

Lane 1: preventive hygiene

Rotate the krbtgt password twice a year on a calendar schedule, regardless of any specific incident. Use New-KrbtgtKeys.ps1 (or a fork of it) with pre-reset and post-reset replication-health checks [@new-krbtgt-keys]. Verify Active Directory replication health between the two rotations; if replication is lagging on any DC, the second reset can outpace the first in some replicas and break in-flight tickets.

Move every Tier-0 account into the Protected Users group. Enable Credential Guard on every workstation and member server. Credential Guard does NOT protect the DC itself by design -- DCs must read the krbtgt key unencrypted -- but it kills the worker-station memory-scrape that initially gets an attacker into a position to pivot to the DC.

Audit who can invoke DCSync. The BloodHound query MATCH (u)-[:DCSync]->(d:Domain) returns every principal whose existing AD permissions can extract the krbtgt key without a DC compromise [@bloodhound-notes][@mitre-t1003006]. Every match should map to a justified administrative role; any unexpected match is a finding.

LSAISO is a Virtualisation-Based Security trustlet that isolates long-term secrets from a SYSTEM-privileged kernel on workstations and member servers. On writeable DCs the design omits LSAISO because the KDC service must read the krbtgt key unencrypted to issue tickets. This is precisely the design property a DCSync-capable attacker exploits.

Note: Two krbtgt rotations per year as preventive hygiene -- not a response to a specific incident. Use New-KrbtgtKeys.ps1 with replication-health checks before, between, and after. The 10-hour wait between rotations is mandatory; do not shorten it [@ms-forest-recovery].

Lane 2: detection deployment

Ship the MDI Suspected-Golden-Ticket alert family plus the DCSync alert (External ID 2006) [@mdi-classic][@mdi-credential]. Confirm the Suspected-Golden-Ticket alerts (2009, 2013, 2022, 2027, 2032, 2040) are active for every domain controller MDI is deployed against. Configure Microsoft Sentinel content-pack rules covering T1558.001 Golden Ticket and Kerberos-anomaly patterns (not the T1558.003 Kerberoasting rules, which target service-account SPNs and are not a krbtgt detection asset). Configure Splunk T1558.001 detection [@splunk-7d9] and tune the encryption-type baseline against legacy systems that legitimately negotiate RC4 (or, better, retire those systems).

Ingest BloodHound for posture-graph visibility. Configure regular collections (the default is weekly) so the DCSync edge list stays current as ACLs change. Cross-reference the DCSync edge inventory against the actual administrative role assignments quarterly.

Lane 3: confirmed-compromise response

When MDI or Sentinel surfaces a confirmed krbtgt compromise -- DCSync extraction observed against a writeable DC, or a Suspected-Golden-Ticket alert with concrete supporting evidence -- the response runs in two parallel tracks. The cryptographic track executes the two-reset rotation: reset the krbtgt password (replicate, verify), wait at least 10 hours, reset again (replicate, verify) [@ms-forest-recovery]. The operational track executes the Domain-of-Thrones Part II rotation surface [@specterops-dot2]:

AD CS template review covering the ESC1 through ESC8 abuse classes [@certified-pre-owned]; replace or restrict templates with EnrolleeSuppliesSubject, broad Enroll permissions, or weak EKU restrictions.
SID History audit (Get-ADUser -Filter * -Properties SIDHistory); investigate every account whose SID History contains a Domain Admins or Enterprise Admins SID.
AdminSDHolder ACL audit; reset Protected Group inherited ACLs and verify the SDProp runs cleanly.
Machine-account secret rotation, especially for Tier-0 servers.
KDS root-key rotation followed by gMSA password cycling.
Trust-key rotation for every inbound and outbound trust.
DSRM password rotation on every writeable DC.

After both tracks complete, re-baseline detection: the post-incident DC event-log baseline will differ from the pre-incident baseline, and detection thresholds may need re-tuning to suppress the resulting alerts.

The reference automation runs against the krbtgt SID specifically, not the friendly name, to avoid any ambiguity with a renamed object. Conceptually: `Set-ADAccountPassword -Identity (Get-ADUser -Filter "objectSID -like '*-502'") -Reset -NewPassword (Convert-To-SecureString (New-RandomPassword) -AsPlainText -Force)`. The Microsoft Learn PowerShell reference for the `Set-ADAccountPassword` cmdlet documents the `-Reset` plus `-NewPassword` parameters used here [@ms-set-adaccountpassword]. The `New-KrbtgtKeys.ps1` script wraps this with replication checks and a confirmation prompt [@new-krbtgt-keys]. Production runbooks always include a pre-check that `Get-ADReplicationFailure` returns no failures before any reset is issued.

Lane 4: what does NOT work

Note: Renaming krbtgt. The RID 502 binding is what the KDC derives from, not the sAMAccountName. The KDC service does not care about the friendly name. Disabling krbtgt. The account is already disabled for interactive logon by design [@ms-default-accounts]. Toggling the field is semantically meaningless to the KDC service, which reads the long-term key directly from the directory. Single rotation. Password-history-of-2 means a single rotation only retires the older of the two keys, leaving the attacker-extracted key (which was current at compromise) still in the previous slot [@ms-forest-recovery]. The procedure must run twice. Treating MDI Suspected-Golden-Ticket alerts as sufficient. Those alerts do not cover Diamond and Sapphire by construction. Sapphire defeats every PAC-content anomaly detection because the PAC is genuine. Confirmed-compromise response must assume the worst even when MDI is silent.

Preventive hygiene, detection deployment, confirmed-compromise response, and four traps to avoid. The FAQ that follows addresses what remains.

11. FAQ

No. It retires Diamond Tickets that do not recompute the Full PAC Signature. It does nothing against tickets minted from a known krbtgt key, including Sapphire Tickets (no PAC modification) and recomputed Diamond Tickets (the attacker holds the key and can compute the new signature in the same step as the older KDC signature) [@kb5020805][@mspac]. No. See §10 Lane 4 trap #1: the RID 502 binding is what the KDC derives from, not the `sAMAccountName` [@ms-default-accounts][@ms-sids]. No. See §10 Lane 4 trap #3: password-history-of-2 keeps the previous key valid after a single rotation, so the procedure must run twice with at least `MaxTicketAge` between resets [@ms-forest-recovery][@new-krbtgt-keys]. No. See §10 Aside on why Credential Guard skips the DC: the KDC service on a writeable DC must read the krbtgt key unencrypted to issue tickets, and DCSync is a remote replication API call (DRSGetNCChanges), not a local LSASS memory scrape [@mitre-t1003006][@ms-credential-guard]. Mechanically, in-flight TGT validation requires the previous-key slot to retain validity for at least `MaxTicketAge` after each rotation. Operationally, the recommended cadence is calendar-driven preventive rotation twice a year, with incident-driven rotation as a separate workstream when confirmed compromise is detected [@ms-forest-recovery]. Indirectly. It forces all krbtgt-encrypted tickets to AES, raising the offline-crack bar against a captured ticket and reducing the surface for the Splunk RC4-Kerberos-anomaly detection family [@splunk-7d9]. It does not affect attacks against a captured krbtgt key; both AES-128 and AES-256 derivations are held in the same account and both validate forged TGTs cleanly. Yes. Each Read-Only Domain Controller has its own `krbtgt_` account whose key signs TGTs only for principals that the RODC can authenticate [@adsec-483]. The full-domain krbtgt is the only account whose key signs TGTs accepted by every DC in the domain; compromise of an RODC-specific `krbtgt_` is a contained event whose blast radius is bounded by the RODC's allowed-list policy. No. The IAKerb and Local KDC features shipping in recent Windows builds affect *where* KDCs run (allowing client-to-client Kerberos without a domain-joined intermediary), not the krbtgt-key trust root inside a domain. The post-RC4 enctype work affects *which* enctypes the krbtgt key derives, not the role of the key. As of [MS-KILE] revision 47.0 dated April 27, 2026, the krbtgt long-term key is still the sole trust anchor for every TGT in the domain [@mskile].

One sentence to take away

Krbtgt rotation invalidates forged TGTs; it does not recover the systemic compromise that produced the forged TGTs in the first place.

That is the precise sentence to keep from ten thousand words. The cryptographic question -- "is the ticket valid?" -- terminates at one key. The operational question -- "is the domain still ours?" -- never does. The 1988 design chose to make ticket validation a property of a single shared secret because that choice made the protocol simple and provably correct. The choice remains correct in 2026. What changed is the meaning of the word compromise: in 1988 the threat model was a passive eavesdropper on a campus LAN; in 2026 the threat model is a remote API call that streams the secret across a DRSGetNCChanges exchange. The key did not move. The attacker's reach did.

Who is allowed to log in where? The KDC-side answer to credential theft in Active Directory

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

Every NTLM and Kerberos credential-theft chain reduces to one operational question: which accounts will the directory authenticate, from which machines, with what credential materials? Active Directory's KDC-side answer arrived in a single October 2013 release -- the tier model (policy intent), the Protected Users security group (a non-configurable credential-restriction switch), and Authentication Policy Silos (KDC-enforced TGT-acceptance rules). It has since acquired residual closures (the November 2021 PAC hardening, the May 2022 PKINIT strong-mapping) and a cloud counterpart (Entra Conditional Access, a second independent enforcement plane). This article traces the 28-year arc from Paul Ashton's April 1997 pass-the-hash post to the 2026 reference deployment, names the four residuals the KDC cannot close by construction, and gives a six-phase playbook for putting the three controls into production this quarter.

1. Two accounts, one TGT, every domain controller

On a Tuesday morning in April 1997, an independent researcher named Paul Ashton posted to the NTBugtraq mailing list. His patched Samba smbclient did not accept a password. It accepted the hash, and the file server gave it everything [@exploit-db-19197]. The directory had no answer for the next sixteen years.

Skip forward to today. A domain admin's laptop is compromised by a phishing payload. The attacker runs Mimikatz against lsass.exe, recovers a Kerberos ticket-granting ticket for the admin account, and from that TGT every domain controller in the forest is reachable. The detection engineer who pulls the incident report knows exactly what happened. The architect on the other side of the table knows the answer was never going to come from the workstation, from the smartcard, or from the RDP client. It had to come from the directory.

This is what every credential-theft chain reduces to: a question about which accounts the directory will authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. Until October 2013, Active Directory had no place to answer that question. It had access-control lists, group memberships, and an AdminSDHolder template that re-stamped privileges every hour [@metcalf-p1906]. None of those mechanisms could refuse to issue a stolen credential, because on the wire a stolen credential is identical to a legitimate one.

Windows Server 2012 R2 changed that on October 18, 2013 [@save-date-blog]. In a single release, the directory acquired three controls that compose into one operational answer. The tier model names which accounts and machines belong to which control plane: T0 holds the domain controllers and the systems that manage them, T1 holds servers and business data, T2 holds workstations [@ms-eam]. The Protected Users security group (well-known RID 525) imposes a non-configurable credential-restriction set: no NTLM, no DES or RC4 in Kerberos, no delegation, no cached offline-sign-in verifier, and a four-hour non-renewable TGT cap [@ms-pu-current]. Authentication Policies and Authentication Policy Silos are directory objects that tell the Key Distribution Center (KDC) which source machines may authenticate which accounts, at AS-REQ time, before any TGT exists to be stolen [@ms-aps].

If you arrived here from the earlier posts in this series: this is the operational counterpart to the NTLM relay story, to the Kerberoasting story, and to the Credential Guard story. Silos are how the KDC says no; Credential Guard is how the host says no; Conditional Access is how the cloud says no. The three planes are independent and they compose.

Key idea: The on-prem AD KDC, keyed on directory state read at issuance time, is the operational answer to credential-theft attack chains. The directory decides which accounts may authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. The three controls -- tier model, Protected Users, Authentication Policy Silos -- compose into that decision.

The rest of this article pays off the question Ashton's 1997 post raises. Why did the directory have no answer for sixteen years? What changed in October 2013 that the pre-2013 controls could not deliver? What does a working 2026 deployment look like, and what does it still leave open?

2. Why the directory had no answer for a decade

Ashton's 1997 demonstration was not subtle. The NT hash is, on the wire, the credential. Windows NT 4's challenge-response authentication used the LanMan or NT one-way function output as the long-term key; anyone who could read that value from the SAM, from a network capture, or from lsadump could authenticate as the principal without ever knowing the password [@exploit-db-19197]. Wikipedia's secondary anchor attributes the first public demonstration to Ashton and dates it to 1997 [@wiki-pth]; the Exploit-DB mirror of the original patch preserves file modification timestamps that narrow the day to Tuesday, April 8, 1997 [@exploit-db-19197].

A credential-theft technique that uses an account's NT one-way function output (the NT hash) to authenticate, instead of the plaintext password. Because the Windows NTLM protocol uses the hash itself as the long-term key, an attacker who reads the hash from memory or from disk can authenticate as the account without ever cracking the password.

For more than a decade after Ashton's post, Microsoft's institutional position was that this was a protocol legacy, not a vulnerability. The reasoning was internally consistent: the hash IS the long-term key in the protocol's design; refusing to honour it would break every existing Windows client. The 2008 Pass-the-Hash Toolkit, written by Hernan Ochoa [@wiki-pth], turned the academic demonstration into a single-binary Windows-native tool that read NT hashes from lsass.exe and injected them into a running logon session [@wiki-pth]. Microsoft's Privileged access strategy page now records the 2008 release of the Pass-the-Hash Toolkit as the proximate cause of the escalation in attacker tooling [@ms-paw-strategy].

Pre-2012, Microsoft's public posture toward credential-extraction tooling was, in Benjamin Delpy's own retelling, "this is not a vulnerability." The Wired profile records the response he received when he disclosed Mimikatz to Microsoft in 2011 [@wired-mimikatz]. That posture is what made the 2012 white paper a turning point: Microsoft committed to treating the attack class as a vulnerability that had to be mitigated by a Microsoft control, not merely contained by operator discipline.

The escalation that finally broke the institutional posture was Benjamin Delpy's Mimikatz, released publicly in May 2011 (closed source) on his personal blog [@mimikatz-blog]. Wired's biographical piece records the date verbatim: "He released it publicly in May 2011, but as a closed source program" [@wired-mimikatz]. The GitHub repository at github.com/gentilkiwi/mimikatz opened in April 2014; the sekurlsa::logonpasswords command on a SYSTEM-level shell printed plaintext passwords, NT hashes, and Kerberos session keys directly from lsass.exe [@mimikatz-repo]. Within twenty-four months it was the default post-exploitation credential dumper in every public AD attack-and-defence talk [@metcalf-p1738][@wired-mimikatz].

Microsoft's first institutional acknowledgement arrived in December 2012 as Mitigating Pass-the-Hash, Version 1. The canonical Microsoft Download Center URL for that version has not survived the company's reorganisations and now returns HTTP 404; the document is preserved through references inside its successor, the 2014 Version 2 paper, which is still hosted [@pth-v2-pdf]. Version 2 introduces tiered administrative segmentation as a deployment shape and is unambiguous about why the previous decade of mitigations had not worked.

Pass-the-Hash and similar credential theft attacks are 100% successful when an attacker gains administrative privileges on a computer, because once a computer is compromised, the attacker can read any credential stored on that computer. -- Microsoft, *Mitigating Pass-the-Hash, Version 2* (2014) [@pth-v2-pdf]

That sentence is the institutional pivot. It moves the framing from "protocol feature, defend the host" to "credentials, once stolen, win." The defence cannot live in the host, because the host is where the attacker has already won. It also cannot live in the ACL, because the ACL evaluates the principal that is authenticating, and the stolen credential authenticates as the legitimate principal. If access-control lists cannot stop a stolen credential, what can?

3. Five generations of pre-2013 controls and why each one failed

Between 1997 and 2013, operators tried five distinct families of controls. Each targeted a different part of the stack. Each failed in the same structural way.

The first family was operational discipline: give every administrator two accounts, alice for daily work and alice.da for domain-administrative work, and trust her not to use the privileged identity from her daily workstation. NT 4 (RTM July 31, 1996) shipped with this as the operating model [@wiki-nt4]. As a control it is a procedure, not an enforcement: there is no directory mechanism that prevents alice.da from interactively logging on to a tier-2 workstation. The Microsoft 2014 paper named the failure mode plainly: once alice.da runs anywhere an attacker also runs, the credential material sits in that machine's LSASS and is replayable forest-wide [@pth-v2-pdf].

The second family was directory-ACL hardening. AdminSDHolder is an object under CN=System in the directory that stores a template security descriptor. A background task called SDProp runs every 60 minutes on the PDC emulator and re-stamps that ACL onto every account with adminCount=1 -- Domain Admins, Enterprise Admins, Schema Admins, and the rest of the protected groups [@metcalf-p1906]. The intent is to prevent ACL drift: a helpdesk operator's misconfigured permission cannot weaken Domain Admin protections for more than an hour. The mechanism survives in modern AD, but its original threat-model framing as a pass-the-hash mitigation is dead. ACLs evaluate the principal; a stolen credential authenticates as the legitimate principal. Worse, Sean Metcalf's Sneaky Active Directory Persistence #15 documents the inverse abuse: AdminSDHolder is not protected by AdminSDHolder, so an attacker who writes a Full-Control ACE into it once gets that ACE propagated across every protected member within sixty minutes [@metcalf-p1906].

`CN=AdminSDHolder,CN=System,DC=...` stores a template security descriptor. The SDProp (Security Descriptor propagator) task runs every 60 minutes on the PDC emulator and copies that ACL onto every member of the protected groups -- objects with `adminCount=1`. The mechanism prevents ACL drift on privileged accounts but does not stop credential theft.

The third family was smartcard-required admin accounts. Setting the SMARTCARD_REQUIRED flag (UAC bit 0x40000) on a privileged account causes the KDC to refuse any AS-REQ that is not a PKINIT request -- the user must present a certificate chain rooted in the domain, with the matching private key on a smartcard [@rfc-4556]. The phishing-credential-into-fake-portal vector is closed: the operator does not know a password to type. But the PKINIT exchange produces a derived long-term key that lives on the workstation as a normal NT hash. The 2014 Mitigating Pass-the-Hash paper is unambiguous in §6: "Smart cards do not protect against the Pass-the-Hash credential theft attack vector. When a smart card is used to log in to a system, the system computes a derived NT hash of the password and stores it on the system" [@pth-v2-pdf]. Mimikatz extracts the derived hash like any other.

The Public Key Cryptography for Initial Authentication in Kerberos extension, specified in RFC 4556. PKINIT lets a client present a certificate (typically held on a smartcard or a TPM) in its AS-REQ instead of a password-derived pre-authentication blob. The KDC validates the certificate against an account binding and issues a TGT. The resulting long-term key still lives in the host's LSASS process.

The fourth family was host-side credential protection: LSA Protection (RunAsPPL), WDigest plaintext disablement, and the TokenLeakDetectDelaySecs registry setting. LSA Protection runs lsass.exe as a Protected Process Light, refusing handles with PROCESS_VM_READ to anything not signed at PPL level [@ms-lsa-prot]. WDigest plaintext disablement (via UseLogonCredential=0, shipped in KB 2871997 in May 2014) stops the WDigest SSP from caching the user's plaintext password [@kb-2871997]. Both moved the bar; neither closed the attack. PPL is enforced by the kernel; on pre-VBS Windows an attacker with a signed kernel driver clears the protection bit, and Mimikatz ships mimidrv.sys for exactly this purpose [@mimikatz-repo] (on modern hardware-rooted HVCI/VBS, the VTL1 secure kernel closes the signed-driver bypass, but the discussion then moves to where the §6 Credential Guard primitive lives [@ms-cred-guard]). WDigest disablement removes plaintext from memory but does nothing to the NT hash or to Kerberos session keys, which are the actually-replayable material.

The fifth family was Restricted Admin Mode for RDP, shipped via the October 14, 2014 revision of KB 2871997 [@kb-2871997]. The intent was to interrupt lateral movement: mstsc /restrictedadmin causes the RDP client to send a CredSSP-wrapped network logon to the target. The target creates a network-logon token instead of an interactive one, and the user's NT hash or Kerberos session keys never land on the target [@ms-rcg][@kfalde-restricted-admin]. Within months, Benjamin Delpy demonstrated the inverse: because the RDP client authenticates with the user's existing credential material, an attacker on the client can pass a stolen NT hash directly into the RDP session with sekurlsa::pth /user:alice.da /domain:CORP /ntlm:<hash> /run:"mstsc /restrictedadmin" [@mimikatz-repo]. The defence became the lateral move. Microsoft updated KB 2871997 to acknowledge this, and Restricted Admin is off by default client-side on modern Windows [@kb-2871997].

Restricted Admin Mode for RDP is the cleanest case in the 28-year arc of a control whose deployment created the inverse of its intent. The mode that protects credentials on the RDP target also enables pass-the-hash into the RDP target from a compromised client. Microsoft's response -- disable it on the client side -- is the practical confirmation. This is the strongest argument in the historical record for moving the credential-restriction decision out of the host, the protocol, and the channel, and into the KDC.

flowchart TD Op["Operator discipline (two-account pattern, 1990s)"] --> Op_x["Procedure, not enforcement: one mistake compromises the forest"] ACL["AdminSDHolder + SDProp (NT 4 / 2000)"] --> ACL_x["ACLs evaluate the principal, and a stolen credential authenticates as the legitimate principal"] SC["Smartcard-required (Server 2003+)"] --> SC_x["PKINIT changes only the AS-REQ method, and the derived NT hash still lives in LSASS"] HS["LSA Protection / WDigest off (2013-14)"] --> HS_x["PPL bypassable by a signed kernel driver, with NT hash and Kerberos keys still in memory"] RA["Restricted Admin Mode for RDP (Oct 2014)"] --> RA_x["Inverse-of-intent: enables pass-the-hash via RDP from the compromised client"] Op_x --> Sink["All five enforce in a layer that does not see the directory's authoritative view of who-may-issue-credentials-from-where"] ACL_x --> Sink SC_x --> Sink HS_x --> Sink RA_x --> Sink

Note: A credential, once usable, is on the wire identical to the legitimate one. Every Generation 1-5 control fails because it enforces in a layer that cannot tell the two apart at the point where it tries to decide. The fix is to refuse to issue or to delegate the credential in the first place -- a decision that has to move one layer up, to the KDC, keyed on directory state.

If the operator cannot be trusted, the ACL cannot enforce, the smartcard-derived hash still lives in LSASS, the host-side protections can be bypassed by anyone with privilege to deploy them, and the RDP mode meant to interrupt lateral movement enables it -- where does the decision have to move?

4. October 18, 2013: the directory acquires a vocabulary

The Microsoft Server team's August 14, 2013 save-the-date blog post fixed the General Availability of Windows Server 2012 R2 for October 18, 2013 [@save-date-blog]. In that single release, three new directory-side primitives appeared: the Protected Users built-in security group with well-known RID 525, the msDS-AuthNPolicy AD object class for Authentication Policies, and the msDS-AuthNPolicySilo AD object class for Authentication Policy Silos [@ms-pu-legacy]. The legacy Windows Server 2012 R2 TechNet documentation, preserved on Microsoft Learn, states the introduction verbatim: "This group was introduced in Windows Server 2012 R2" [@ms-pu-legacy]. The architectural decision visible in the wire format: the KDC, not the application, now decides whether a TGT may be issued, what its lifetime will be, and what delegation operations on it will succeed.

The Kerberos authentication service, specified in RFC 4120. The KDC handles AS-REQ (issuing a Ticket-Granting Ticket from a long-term key) and TGS-REQ (issuing a service ticket from a TGT). On Windows domains, every domain controller runs a KDC; the KDC reads its policy state from the directory at request time, which is the property the Server 2012 R2 controls exploit [@rfc-4120]. A Microsoft authorisation-data overlay carried inside Kerberos TGTs and service tickets, specified in [MS-PAC]. The PAC's `PAC_LOGON_INFO` buffer contains the user's SID, primary-group SID, and a `GroupIds` array of well-known group memberships. Protected Users membership is encoded as RID 525 inside that array. There is no separate Protected Users flag bit [@ms-pac].

The detail that matters: there is no dedicated "Protected Users bit" in the PAC. The encoding is the well-known group SID S-1-5-21-<domain>-525 carried in PAC_LOGON_INFO.GroupIds ([MS-PAC] §2.5) [@ms-pac][@ms-pu-legacy]. The KDC reads that array at AS-REQ and TGS-REQ time the same way it reads it for every other group; what changes is the behaviour the KDC takes when it sees RID 525.

The down-level half of the shipment arrived seven months later. On May 13, 2014, Microsoft Security Advisory KB 2871997 backported the client-side honoring of Protected Users and Authentication Policies to Windows 7, Windows 8, Server 2008 R2, and Server 2012 [@kb-2871997]. KB 2871997 is not the introduction of Protected Users. It is the down-level backport that closed the long-tail Silo-bypass class an enterprise would hit if its 2014-era fleet could not honour the new restriction list. Five months later, the October 14, 2014 revision of the same KB shipped Restricted Admin Mode for RDP -- the mode §3 already taught the reader to treat as a cautionary tale.

The version-mismatch story matters for the operator who finds a 2014 KB cited as the "introduction" of Protected Users in older blog posts. It is not. The introduction is Server 2012 R2 GA on October 18, 2013; the backport is KB 2871997 on May 13, 2014. The legacy Microsoft Learn page records the introduction date plainly [@ms-pu-legacy].

Microsoft followed the primitive with a deployment shape. The Securing Privileged Access reference material, originally published on TechNet circa 2014-2015 and preserved on Microsoft Learn at the privileged-access-workstations root [@ms-paw-root], codified the clean-source principle: a higher-tier secret must never be exposed to a lower-tier host. T0 holds domain controllers, the PKI root, the identity-sync infrastructure, and the DC backup system. T1 holds servers and business data. T2 holds workstations [@ms-eam]. T0 credentials never authenticate to T1 or T2; T1 credentials never authenticate to T2. The Privileged Access Workstation (PAW) is the dedicated source machine for T0 administration. Server 2012 R2 gave operators the primitives; SPA gave them the shape.

flowchart LR A["Apr 8, 1997: Paul Ashton, NTBugtraq -- hash IS the credential"] --> B["2008: Hernan Ochoa, Pass-the-Hash Toolkit"] B --> C["May 2011: Benjamin Delpy, Mimikatz public release"] C --> D["Dec 2012: Microsoft, Mitigating Pass-the-Hash v1"] D --> E["Oct 18, 2013: Windows Server 2012 R2 GA -- Protected Users, Authentication Policies, Silos"] E --> F["May 13, 2014: KB 2871997 down-level backport"] F --> G["Oct 14, 2014: KB 2871997 adds Restricted Admin RDP"] G --> H["2014-2015: Securing Privileged Access reference material"] H --> I["Dec 15, 2020: ESAE retired, Enterprise Access Model begins"] I --> J["Nov 9, 2021: KB 5008380 PAC hardening"] J --> K["May 10, 2022: KB 5014754 PKINIT strong mapping"] K --> L["Feb 11, 2025: KB 5014754 Full Enforcement default"] L --> M["Sep 9, 2025: KB 5014754 Compatibility-mode revert removed"]

Key idea: The KDC, not the application, decides whether a TGT may be issued, what its lifetime is, and what delegation operations on it will succeed. The decision is made by reading directory state -- group SID 525 in PAC_LOGON_INFO.GroupIds for Protected Users, msDS-AssignedAuthNPolicySilo and msDS-AssignedAuthNPolicy for Silo and Policy bindings -- at request time. This is the architectural pivot. The credential-on-the-wire identity property no longer matters, because the credential never gets issued in the first place to be stolen.

Three controls, one ship. But how do they compose, exactly -- which decision does the KDC actually make at AS-REQ time, what does it read from the directory, and what does it refuse?

5. How the three controls compose: a mechanism walkthrough

If you have time to read only one section of this article, read this one. The Server 2012 R2 controls compose into a precise decision the KDC makes at AS-REQ and TGS-REQ time. The mechanism has four moving parts.

5.1 The tier model as policy intent

The tier model is policy intent, not enforcement. Tier 0 is the control plane: every domain controller, every certificate authority that issues domain-trust certificates, the Microsoft Entra Connect server that synchronises identity to the cloud, and the backup systems that can restore any of those. Tier 1 is the management and data plane: servers, business applications, and the database engines that hold the data the organisation actually cares about. Tier 2 is the user plane: workstations and the devices users carry [@ms-eam]. The rule that defines the model is the clean-source principle: a higher-tier credential must never authenticate to a lower-tier host, because once it lands in the lower-tier host's memory it is exfiltrable by anyone with privilege on that host [@ms-paw-strategy]. The tier model says nothing about how the rule is enforced. Protected Users and Authentication Policy Silos are how.

5.2 Protected Users: the credential-restriction switch

Protected Users is a global security group with well-known RID 525, present in every domain at Domain Functional Level 2012 R2 or later. Membership is encoded as the well-known SID S-1-5-21-<domain>-525 carried in the GroupIds array of the user's PAC_LOGON_INFO ([MS-PAC] §2.5) [@ms-pac][@ms-pu-current]. When the KDC reads RID 525 in that array, it applies a non-configurable restriction set documented on Microsoft Learn [@ms-pu-current]:

No NTLM authentication. The DC refuses any NTLM authentication attempt for a Protected Users member -- the NTLM SSP and NetLogon path on the DC enforce the rejection, and the Kerberos KDC enforces the corresponding refusal for AS-REQ flows that fall back to NTLM-style pre-authentication. NTLM relay against the account is structurally impossible because there is no NTLM session to relay.
No NTLM hash caching on the host. Even if the user has logged on interactively, the LSA never holds the account's NT one-way function output. Mimikatz sekurlsa::logonpasswords prints (null) for the NTLM tab.
No DES or RC4 in Kerberos pre-authentication. AES-128 or AES-256 only. Kerberoasting against the account becomes inapplicable, because the public roasting tooling requires RC4-HMAC ticket material that the KDC refuses to issue.
No constrained or unconstrained delegation, in either direction. The account cannot be the source of a constrained-delegation chain, and S4U2Self / S4U2Proxy against the account as a target is refused at TGS-REQ time.
No cached offline-sign-in verifier. The Windows Hello for Business PIN-based offline-logon path is unavailable for Protected Users members; this is the operational price of removing the cached verifier from disk.
TGT lifetime capped at 240 minutes, non-renewable. Microsoft Learn states the figure verbatim: "For Protected Users members, the group automatically sets these lifetime limits to 240 minutes" [@ms-pu-current]. The cap overrides the domain's "Maximum lifetime for user ticket" and "Maximum lifetime for user ticket renewal" policies.

The built-in domain Administrator (RID 500) is always exempt from Authentication Policy enforcement even when assigned to a Silo, which makes it a candidate break-glass identity [@ms-pu-current]. That exemption does not extend to the Protected Users restriction set itself: adding RID 500 to Protected Users on a domain whose Administrator account lacks AES keys will lock the account out. Service accounts cannot be enrolled in Protected Users without breaking workflows -- see §6's canonical Microsoft Learn PullQuote on this point.

5.3 Authentication Policies and Silos: the KDC-side policy objects

Two AD object classes, layered. The containment direction is the most common practitioner confusion, so be precise about it: the Silo references the Policy, not the other way.

The container object. A Silo enumerates the user, computer, and service accounts that share a set of restrictions and references one or more `msDS-AuthNPolicy` objects whose rules apply to its members. The Silo carries an `msDS-AuthNPolicySiloEnforced` Boolean that switches between audit-only and enforced modes. Accounts bind to it via `msDS-AssignedAuthNPolicySilo`, with `msDS-AuthNPolicySiloMembers` as the back-link [@ms-aps]. The rules object. A Policy carries the non-renewable TGT lifetime cap, the allowed-from SDDLs on source-machine identity (`UserAllowedToAuthenticateFrom`, `ServiceAllowedToAuthenticateFrom` -- computer accounts have no `-From` variant, only `-To`), the corresponding allowed-to SDDLs for delegation targets (`UserAllowedToAuthenticateTo`, `ServiceAllowedToAuthenticateTo`, `ComputerAllowedToAuthenticateTo`), claim-based authentication access-control conditions, and the option to require Kerberos armoring per RFC 6113 [@ms-aps][@rfc-6113].

The same Policy can be referenced by multiple Silos. Accounts can be bound to a Policy directly via msDS-AssignedAuthNPolicy without being placed in a Silo at all, though the more common pattern is Silo membership for the broader containment and Policy reuse for the rule definitions.

The containment direction is the single most-common practitioner confusion. The Silo names the Policy that applies to its members. The same Policy can apply to several Silos. The directory links are role-specific: the Silo carries msDS-UserAuthNPolicy, msDS-ComputerAuthNPolicy, and msDS-ServiceAuthNPolicy, each pointing outward to a Policy object [@ms-aps]. Older blog posts that describe "the Policy attached to the Silo" are using imprecise prose; the link in the schema is Silo to Policy, not the other way.

Note: Policy and Silo objects replicate via standard AD multi-master directory replication -- the DRS Remote Protocol, MS-DRSR / drsuapi [@ms-drsr]. They do NOT replicate via FRS or DFSR. FRS and DFSR replicate SYSVOL files (Group Policy content, scripts), not directory objects. Practitioners who chase "my Policy assignment is not replicating" through DFSR diagnostics are looking in the wrong primitive; the right one is repadmin /showrepl against the DRS partition.

5.4 The KDC's decision points

The KDC consults the directory at three precise moments, documented in [MS-KILE] §3.3.5 [@ms-kile]:

AS-REQ. The KDC reads the requester's msDS-AssignedAuthNPolicySilo and any msDS-AssignedAuthNPolicy. If the Policy specifies a UserAllowedToAuthenticateFrom SDDL, the KDC evaluates the source-machine identity (as presented in the pre-authentication exchange) against the SDDL. On denial, the KDC returns KDC_ERR_POLICY and no TGT is issued. The KDC also checks PAC_LOGON_INFO.GroupIds for RID 525; if present, it applies the Protected Users restriction set to the TGT it is about to issue (AES-only, 240-minute cap, delegation forbidden).
TGS-REQ for S4U2Self. The KDC reads the target account's group memberships and Silo bindings. If the target is a Protected Users member, S4U2Self is refused. If the target's Silo Policy specifies an allowed-to SDDL, the requesting service identity is evaluated against it [@ms-sfu].
TGS-REQ for S4U2Proxy. The KDC evaluates the requesting service's msDS-AllowedToDelegateTo and the target's msDS-AllowedToActOnBehalfOfOtherIdentity, then layers the Silo Policy's claim requirements on top. Protected Users membership on either side terminates the request [@ms-sfu].

sequenceDiagram participant PAW as PAW (source machine) participant KDC as KDC on DC participant DS as Directory (LDAP DSA) PAW->>KDC: AS-REQ for alice.da, pre-auth signed KDC->>DS: Read alice.da object (PAC_LOGON_INFO, msDS-AssignedAuthNPolicySilo) DS-->>KDC: GroupIds includes RID 525, Silo = "T0 Admins" KDC->>DS: Read referenced Policy (msDS-AuthNPolicy) DS-->>KDC: UserAllowedToAuthenticateFrom SDDL pinned to T0 PAWs KDC->>KDC: Evaluate source machine identity against SDDL alt Source is in the allowed-from set KDC->>KDC: Apply Protected Users restriction set (AES-only, no NTLM, no delegation) KDC->>KDC: Cap TGT lifetime at 240 minutes non-renewable KDC-->>PAW: TGT issued with restriction PAC else Source not in the allowed-from set KDC-->>PAW: KDC_ERR_POLICY, no TGT issued end flowchart LR A["User account alice.da (msDS-AssignedAuthNPolicySilo)"] --> S["Silo: T0 Admins (msDS-AuthNPolicySilo)"] C["Computer account paw01 (msDS-AssignedAuthNPolicySilo)"] --> S SV["Service account svc-bkp (msDS-AssignedAuthNPolicySilo)"] --> S S -- "references" --> P["Policy: T0 Source Restriction (msDS-AuthNPolicy)"] P --> Rule1["UserAllowedToAuthenticateFrom SDDL"] P --> Rule2["TGT lifetime cap"] P --> Rule3["Claim transformations"] P --> Rule4["FAST armoring requirement"] S -. "alt direct binding" .-> A2["Account can also bind via msDS-AssignedAuthNPolicy"]

The RunnableCode block below simulates the decision tree as a small JS function. It is pedagogical, not a real KDC, but the logic mirrors what [MS-KILE] specifies. Change the inputs -- move the source machine outside the allowed-from set, flip the Protected Users flag -- and the decision changes.

{` function kdcDecideAsReq(account, sourceMachine) { // account: { name, inProtectedUsers, siloPolicy: { allowedFrom: [], tgtMinutes, requireFast } } // sourceMachine: { name }

if (account.siloPolicy && account.siloPolicy.allowedFrom && !account.siloPolicy.allowedFrom.includes(sourceMachine.name)) { return { issued: false, error: "KDC_ERR_POLICY", reason: "source not in allowed-from set" }; }

const restrictions = []; let tgtMinutes = account.siloPolicy ? account.siloPolicy.tgtMinutes : 600; let renewable = true;

if (account.inProtectedUsers) { restrictions.push("no-NTLM", "AES-only", "no-delegation", "no-cached-verifier"); tgtMinutes = Math.min(tgtMinutes, 240); renewable = false; }

return { issued: true, tgtMinutes, renewable, restrictions, sourceMachine: sourceMachine.name }; }

const alice = { name: "alice.da", inProtectedUsers: true, siloPolicy: { allowedFrom: ["paw-t0-01", "paw-t0-02"], tgtMinutes: 480, requireFast: true } };

console.log("From PAW:", kdcDecideAsReq(alice, { name: "paw-t0-01" })); console.log("From workstation:", kdcDecideAsReq(alice, { name: "wks-finance-77" })); `}

The KDC now has a vocabulary it did not have in 1997. Well-known group SID 525 as a credential-restriction switch. msDS-AuthNPolicySilo and msDS-AuthNPolicy as policy objects. drsuapi as the replication primitive that carries policy changes to every DC. The decision is keyed on directory state, made at request time, before any TGT exists to be stolen. With the mechanism in hand, what does a current 2026 reference deployment look like?

6. The 2026 reference deployment

Microsoft has had thirteen years to settle the deployment shape. As of May 2026, a well-built environment looks like the layered stack below, in which Silos and Protected Users carry the on-prem enforcement and several complementary primitives close residuals the KDC plane cannot address by construction.

The control plane of an Active Directory environment. T0 contains the domain controllers and every system whose compromise grants forest-wide control: the AD CS certificate authorities, the Microsoft Entra Connect server, the privileged-access workstations used to manage them, and the backup systems that can restore any of those. The SpecterOps Tier Zero Table is the community-maintained canonical asset list and is the practical starting point for any T0 inventory [@tzt-pages][@tzt-github].

The reference deployment composes:

Tier model present as policy intent, with Authentication Policy Silos as the enforcement primitive that makes the tier boundary KDC-visible.
All human T0 administrators in Protected Users, in a "T0 Admins" Silo whose Policy's UserAllowedToAuthenticateFrom SDDL pins authentication to a defined set of T0 PAWs. The KDC will return KDC_ERR_POLICY for any AS-REQ from outside that set [@ms-aps][@ms-kile].
T0 service accounts in a "T0 Services" Silo with a more permissive Policy that still pins source machines. Service accounts cannot be in Protected Users; the Silo plane is the only KDC-side enforcement available to them [@ms-pu-current].
Domain-wide migration off RC4-HMAC for AS-REP, with msDS-SupportedEncryptionTypes audited per account. Protected Users enforces AES-only for free for human members; service accounts need explicit per-account configuration [@ms-config-pa].
Credential Guard default-on for non-DC Windows 11 22H2+ and Windows Server 2025+ devices that meet the hardware requirements [@ms-cred-guard]. Windows LAPS managing local-administrator password uniqueness on every workstation [@ms-laps].
Entra PIM for Entra ID privileged roles [@ms-pim], with Conditional Access keyed on the synced T0 Admins group requiring phishing-resistant MFA and a compliant device. The CA does not see the Silo; it sees the synced group. The two planes are independent (see §8).
Microsoft Defender for Identity assessments running, including "Identify privileged accounts that are not protected by Protected Users group" and adjacent recommendations [@ms-mdi]. This is the detection plane that tells the operator the reference deployment is the deployed posture.

For the service accounts that cannot be enrolled in Protected Users, the explicit AES enforcement story is direct: set msDS-SupportedEncryptionTypes to 0x18 (AES128 0x08 + AES256 0x10). To additionally signal Compound-Identity-Supported, use 0x20018 (0x18 | 0x20000) -- Compound-Identity-Supported is the G bit at position 17 of the [MS-KILE] §2.2.7 Supported Encryption Types Bit Flags diagram, value 0x20000, not 0x40. The full bit layout per [MS-KILE] §2.2.7 is: DES-CBC-CRC 0x01, DES-CBC-MD5 0x02, RC4-HMAC 0x04, AES128-CTS-HMAC-SHA1-96 0x08, AES256-CTS-HMAC-SHA1-96 0x10, FAST-Supported 0x10000, Compound-Identity-Supported 0x20000, Claims-Supported 0x40000, Resource-SID-Compression-Disabled 0x80000; 0x40 is bit 6 (AES128-CTS-HMAC-SHA256-128, an RFC 8009 enctype [@rfc-8009] older KDCs do not fully support and which is not Compound-Identity-Supported). The value 0x18 explicitly excludes RC4 (0x04) and the two DES flavours (0x01, 0x02). Note that 0x1C is not AES-only -- it is 0x10 | 0x08 | 0x04, which re-introduces RC4 on the very account you are trying to harden. Group Managed Service Accounts (gMSA) are the preferred new-service-account primitive: the Microsoft Key Distribution Service computes a long, automatically-rotated password keyed on a domain-wide root key, and the Microsoft Learn gMSA overview describes the mechanism in detail -- the resulting AES pre-auth tickets are not roastable in practical timeframes [@ms-gmsa-overview]. Microsoft's How to Configure Protected Accounts page lays out the per-account migration steps for non-gMSA legacy services [@ms-config-pa].

Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn't provide local protections because the password and certificate is always available on the host. -- Microsoft Learn, *Protected Users Security Group* [@ms-pu-current]

That quote is the operational reason the RBCD residual remains the punchline of §8. Before then, two further pieces of the reference deployment need to be named, because both have been mis-described in widely shared blog posts.

The first is the November 2021 PAC hardening in KB 5008380, which addressed CVE-2021-42287 and CVE-2021-42278 ("noPAC"). The fix added two new PAC buffer types to the Kerberos TGT: PAC_REQUESTOR (buffer type 18), which encodes the SID of the principal that requested the ticket, and PAC_ATTRIBUTES_INFO (buffer type 17), which carries PAC-generation attributes [@kb-5008380][@ms-pac]. The KDC at TGS-REQ time now verifies that the requestor SID in the PAC matches the principal currently presenting the TGT. Initial deployment was November 9, 2021; the Enforcement phase landed October 11, 2022 [@kb-5008380].

The second is the May 2022 PKINIT certificate-to-account strong-mapping fix in KB 5014754 [@kb-5014754]. Pre-fix, the KDC mapped a PKINIT certificate to an account by sAMAccountName or UPN -- the same comparison that Schroeder and Christensen's Certified Pre-Owned whitepaper showed could be spoofed via UPN conflicts or via the trailing dollar-sign convention on machine accounts [@cert-preowned-blog][@cert-preowned-pdf]. The fix added the SecurityIdentifier X.509 extension OID 1.3.6.1.4.1.311.25.2 to certificates issued by AD CS and requires the KDC to match the SID in the certificate against the SID of the account being authenticated. The Full Enforcement default landed February 11, 2025; the Compatibility-mode revert option was removed on September 9, 2025 [@kb-5014754].

The November 2021 PAC hardening is not the encoding of Protected Users membership. The Protected Users marker is RID 525 in `PAC_LOGON_INFO.GroupIds`, present in the PAC since Windows Server 2012 R2 GA in October 2013. The November 2021 buffers (`PAC_REQUESTOR`, `PAC_ATTRIBUTES_INFO`) are a separate, later KDC anti-spoofing primitive that closes the sAMAccountName-spoofing chain in CVE-2021-42278 plus CVE-2021-42287 [@kb-5008380][@ms-pac]. Conflating them produces wrong threat-model claims: it treats a 2021 anti-spoofing fix as if it were the 2013 credential-restriction marker, and leaves the operator unable to reason about either correctly.

Reference 2026 deployment: what runs where.

Account class	Protected Users?	Silo membership	Allowed-from SDDL anchor	TGT cap	Host-side	Cloud-side
Human T0 admin	Yes	T0 Admins	T0 PAWs only	240 min, non-renewable	Credential Guard on the PAW; LAPS irrelevant (PAW is unique)	Entra PIM + CA on synced group, phishing-resistant MFA, compliant device
T0 service account (gMSA)	No (breaks workflow)	T0 Services	T0 server set	Default; per-Policy cap	Credential Guard on every host the account runs on	n/a (on-prem only)
T1 admin	Optional	T1 Admins	T1 jump servers	Default; per-Policy cap	Credential Guard everywhere	CA on synced T1 group
T2 user	No	None	n/a	Default	Credential Guard default-on, LAPS for local admin	CA general policy

If this is the reference deployment, what about the alternative architectures customers actually have in production -- ESAE forests, MIM PAM bastion forests, the Enterprise Access Model?

7. Tiered Administration vs. bastion forest vs. Enterprise Access Model

Three operational doctrines coexist in 2026 production environments, with a fourth meta-architecture sitting above them. None are interchangeable; choosing the wrong one means over-building, under-building, or building the right thing in the wrong place.

Method A: Tier model + Authentication Policy Silos + Protected Users. The current Microsoft recommendation for the on-prem enforcement layer in connected and hybrid environments. The whole of §5 and §6 is the description. Cited references: [@ms-pu-current][@ms-aps][@ms-eam].

Method B: MIM Privileged Access Management with a bastion forest. Microsoft Identity Manager PAM with the Server 2016 bastion-forest functional level gives just-in-time activation of privileged group membership in a separate, hardened "bastion" forest with a one-way trust from production to bastion. Microsoft Learn's Raise the bastion forest functional level page is explicit on the feature pivot: "With Windows Server 2016, PAM features of time-limited group memberships and shadow principal groups are built into Windows Server Active Directory" [@ms-pam-bastion-ffl]. A user requests time-bound activation, MIM validates it, the user is briefly added to a bastion-forest privileged group (a shadow principal at WS 2016 FFL), and the resulting TGT carries the production SIDs via PAC SID History. When the activation expires, the SID History entry disappears from newly issued tickets. The Microsoft Learn page is explicit about scope:

The PAM approach provided by MIM PAM is not recommended for new deployments in Internet-connected environments. MIM PAM is intended to be used in a custom architecture for isolated AD environments where Internet access is not available, where this configuration is required by regulation, or in high impact isolated environments like offline research laboratories and disconnected operational technology or supervisory control and data acquisition environments. -- Microsoft Learn, *MIM PAM* [@ms-mim-pam]

Method C: Enhanced Security Admin Environment (ESAE) / Red Forest. A separate hardened forest used exclusively for administrative identities, with a one-way trust from production to the admin forest. Production-forest administration is performed by accounts that live exclusively in the admin forest. Microsoft retired ESAE as a mainstream recommendation on December 15, 2020 [@ms-esae-retire].

A dedicated Active Directory forest containing all administrative identities, with a one-way trust from the production forest to the admin forest. Retired as a mainstream Microsoft recommendation on December 15, 2020 [@ms-esae-retire]; preserved for air-gapped, OT, ICS, and SCADA scenarios where cloud-side privileged-access controls are unavailable. Microsoft's explicit guidance for existing ESAE deployments is "no urgency to retire" if the deployment is operating as designed.

Method D: Enterprise Access Model (EAM) / Rapid Modernization Plan (RaMP). Microsoft's current meta-architecture, announced concurrently with the ESAE retirement on December 15, 2020 [@ms-esae-retire][@ms-eam][@ms-ramp]. EAM widens the segmentation from forest boundaries to access levels: a privileged-access plane (the equivalent of T0, now explicitly including Entra ID admin roles), a management plane (formerly T1), a data/workload plane (where applications run), and a user/app plane (T2). EAM does not deprecate the directory-level controls -- it encloses them inside a larger model that adds the cloud control plane as a first-class object.

Microsoft's December 15, 2020 meta-architecture for privileged-access. Replaces forest-level isolation with access-level segmentation across four planes: privileged-access, management, data/workload, and user/app. EAM is the framework; Method A (Tier model + Silos + Protected Users) is the on-prem enforcement layer inside the privileged-access plane; Entra PIM and Conditional Access are the cloud-side enforcement [@ms-eam][@ms-ramp].

Four operational doctrines, side by side.

Dimension	A: Tier + Silos + Protected Users	B: MIM PAM bastion	C: ESAE / Red Forest	D: EAM + RaMP
Enforcement plane	KDC (AS-REQ, TGS-REQ, S4U)	Bastion KDC + MIM workflow	Admin-forest KDC + one-way trust	Meta: composes A + cloud + host
Primary restriction	Where a TGT may be issued and to whom delegated	Whether and for how long a privileged group is populated	Which forest privileged identities live in	Which planes are enforced and by what
AD schema footprint	4 attributes / 2 classes + RID 525	Server 2016 PAM FFL + Shadow Principal extensions	None new; uses standard trust + SID filtering	n/a (model)
Cloud / hybrid coverage	On-prem only	On-prem only (explicitly NOT for connected)	On-prem only	First-class hybrid by design
Deployment complexity	Moderate	High (forest pair + SQL + MIM)	Highest (forest pair + full DR)	Variable (sum of constituents)
Microsoft current status (May 2026)	Recommended for on-prem enforcement	OT / ICS / regulated air-gapped only	Legacy; supported for existing + OT only	Recommended as top-level architecture

Method D is the framework; Method A is the on-prem enforcement layer inside it; Methods B and C are the niche answers for environments Method A cannot reach. The four are not in competition for the same job. A connected hybrid enterprise in 2026 runs Method D + Method A on-prem, with B and C reserved for the air-gapped exception cases.

EAM is the framework. Method A is its on-prem enforcement layer. What does Method A's enforcement layer NOT close, by construction?

8. What the KDC cannot enforce

A well-deployed Method A architecture eliminates the credential-theft attack chain at the KDC. It does not close every gap. The remaining gaps are not implementation bugs; they are structural properties of where the KDC sits in the stack. Naming them is not optional.

The RBCD residual. Resource-based constrained delegation is configured by writing the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target object [@ms-sfu]. The write is governed by the target object's DACL, not by the Silo plane. The KDC never sees the write; it only sees the resulting TGS-REQ. If the target is a service account that is Silo'd but not in Protected Users -- which, per Microsoft Learn's explicit guidance, is the case for most service accounts -- the RBCD chain remains exploitable. The defence is layered: pin the source machine via the Silo Policy, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, prefer Group Managed Service Accounts for new services, and put Defender for Identity detection on the attribute-write event [@ms-mdi].

A constrained-delegation primitive introduced in Windows Server 2012. Unlike classic constrained delegation (configured by the privileged administrator on the *delegating* service via `msDS-AllowedToDelegateTo`), RBCD is configured on the *target* by writing `msDS-AllowedToActOnBehalfOfOtherIdentity`. The target object's owner controls which services may impersonate users to it. Governance is at the ACL plane, not the KDC plane, which is why RBCD writes are invisible to Authentication Policy Silo enforcement [@ms-sfu].

Note: Even after every tier-model, Silo, and Protected Users control is correctly deployed, RBCD remains exploitable against any tier-protected service account that is not also in Protected Users -- which, in practice, is most service accounts. Protected Users would close the gap but breaks delegation workflows. The KDC cannot prevent writes to msDS-AllowedToActOnBehalfOfOtherIdentity because the write is an ACL operation on a directory attribute, not a Kerberos operation. The defence is necessarily layered: ACL the attribute, Silo the target, gMSA the credential material, detect the write at the SIEM.

Physical extraction from a logged-on T0 host. The KDC cannot prevent the extraction of credential material from the memory of a machine on which the user is logged on. The credential has to exist somewhere in memory for the user to use it. Credential Guard raises the bar dramatically by placing the credential material in a VBS-protected VTL1 enclave that the VTL0 kernel cannot read, even with a signed driver [@ms-cred-guard]. Remote Credential Guard adds a parallel host-side control for RDP-initiated authentications that redirects Kerberos requests back to the originating client [@ms-rcg]. None of these is a KDC control. The KDC and the host are two layers; both are required.

The on-prem-to-cloud bridge. On-prem AD KDC enforcement (Silo membership) and Entra ID Conditional Access enforcement are two independent policy planes by construction. The Primary Refresh Token does not carry msDS-AssignedAuthNPolicySilo. Conditional Access does not consume the Silo binding. Operational alignment is achieved by synchronising the Silo'd group through Microsoft Entra Connect and writing a Conditional Access policy keyed on the synced group. The CA sees the synchronised group; it does not see the Silo. Two planes, both must hold.

The host-side limit ("Credential Guard moves the bar but cannot eliminate physical extraction") is the topic of the earlier Credential Guard post in this series; the on-prem-to-cloud limit is the topic of the Conditional Access post. The four-residual recognition in this section is the joint that connects all three.

Key idea: Closing the on-prem-to-cloud gap requires either a Microsoft product change that projects Silo membership into the Primary Refresh Token, or a third-party policy synthesiser. Neither exists as a product surface in May 2026 -- which is why the §10 Phase 4 workaround (sync the Silo'd group through Microsoft Entra Connect, key the Conditional Access policy on the synced group) is the current production answer. The workaround keeps both planes independent by construction; it does not close the gap, it routes around it.

Supply-chain compromise of T0 software. The KDC cannot enforce policy against an agent running as SYSTEM on every domain controller. By construction, the agent is outside the KDC's authorisation scope; it can rewrite the directory the KDC reads its policy from. The canonical instance is the SolarWinds Orion compromise disclosed in December 2020 (CISA Alert AA20-352A): the attackers used a backdoored Orion update to obtain SYSTEM-level access on management hosts and, per the CISA advisory's User Impersonation section, in several documented cases used that access to compromise "the SAML signing certificate using their escalated Active Directory privileges" -- the AD FS / Entra Connect token-signing certificate -- and then "create unauthorized but valid tokens" presented to services that trust SAML tokens from the environment, on T0 systems where the secret material has to exist in memory for the system to do its job [@cisa-aa20-352a]. The KDC saw legitimately-signed tickets and made legitimate policy decisions; the enforcement gap is one layer below, where the software running as the KDC's neighbour ships compromised code. The closure for this residual is not at the KDC; it is at the software-supply-chain layer (code signing, reproducible builds, attested deployment, and strict T0-software inventory).

Every Method A deployment requires two emergency-access break-glass accounts that are outside every Silo and outside Protected Users -- see §10 Phase 5 for the operational pattern (offline-stored passwords, monthly use-and-rotate, high-fidelity SIEM detection, RID 500 as the canonical first identity). Microsoft's RaMP guidance treats this as the *first* step of the privileged-access rollout, before any of the controls in §5 and §6 are deployed [@ms-ramp].

A maximally-correct Method A deployment closes the KDC-plane gaps it was designed to close. Four explicit residuals remain by construction. Three need additional controls (target-ACL hardening, Credential Guard, Conditional Access keyed on the synced group); the fourth is closed at the software-supply-chain layer. The architecture is correct. The world is bigger than the architecture.

What is the active research, and what does a practitioner do on Monday morning to deploy what is settled?

9. Active research lines as of mid-2026

The community is not standing still. Five lines of work are visible on the public radar.

Projecting Authentication Policy Silo membership into Entra Conditional Access as a first-class signal. The most-named open problem in both SpecterOps research and Microsoft's own post-NTLM roadmap discussion. Matthew Palko's October 2023 post Evolution of Windows Authentication is Microsoft's institutional acknowledgement that the post-NTLM future is Kerberos plus IAKerb plus Local KDC; the post does not commit to projecting Silo membership into the Primary Refresh Token, but it is the closest reading the community has of a hybrid identity direction [@palko-evol]. IAKerb plus Local KDC is plausibly the substrate that could eventually carry Silo state across the on-prem-to-cloud boundary, but no public Microsoft roadmap entry as of May 2026 announces that projection.

A community-maintained checklist of Active Directory and Microsoft Entra ID assets, annotated with whether each asset is "Tier Zero" (its compromise grants forest-wide or tenant-wide control), what platform it sits on, how to identify it (typically by SID or by role assignment), and what attack techniques apply by default versus by misconfiguration. The repository is `github.com/SpecterOps/TierZeroTable` with a rendered live view at `specterops.github.io/TierZeroTable` [@tzt-github][@tzt-pages].

Tier Zero scoping at hybrid-cloud scale. Defining the boundary of T0 in a hybrid environment is increasingly difficult. The on-prem T0 set (DCs, AD CS, Entra Connect, DC backup) is enumerable. The cloud-side T0 set (Entra ID Application Administrators with Graph permissions over AD-synced objects, Hybrid Identity Administrators, Global Administrators, Privileged Authentication Administrators) is large, dynamic, and contains roles whose tier-0 status is contested. The SpecterOps Tier Zero Table is the community's canonical operational answer; its GitHub README is explicit that "the table does not include all Tier Zero assets yet" [@tzt-github]. BloodHound Community Edition is the companion discovery primitive: feed it a directory snapshot, ask it for attack paths to T0, fix the paths [@bloodhound]. The introductory blog series at SpecterOps explains the "Defining the Undefined" definitional work behind the table [@tier-zero-part1].

If you have never used BloodHound against your own forest, that is the most leveraged single action you can take this month. The tool exposes the attack paths your tier model is supposed to be closing -- and the gaps are almost always somewhere you did not look. The Tier Zero Table is the human-readable companion; BloodHound is the machine-readable one [@bloodhound][@tzt-github].

Continued discovery of ADCS misconfiguration classes (ESC1-ESC8+). Schroeder and Christensen's June 17, 2021 Certified Pre-Owned whitepaper was the inflection [@cert-preowned-blog][@cert-preowned-pdf]. The original taxonomy catalogued ESC1 through ESC8; ESC9 and several subsequently-disclosed classes have been added since by the SpecterOps team and the wider AD CS research community, with the GhostPack Certify tool tracking the enumerable classes in its active branch [@ghostpack-certify], and adjacent variants continuing to land in the SpecterOps blog stream. Each class is a tier-bypass primitive that survives Method A's deployment if the AD CS configuration is itself misconfigured: the KDC sees a legitimately-signed certificate and a legitimate AS-REQ. KB 5014754's strong-mapping closes the specific CVE-2022-26923 ("Certifried") class; template hardening (manager-approval, no-CT, no-enrollee-supplies-subject) addresses several other classes [@kb-5014754].

Kerberos relay primitives. The KrbRelay family of attacks, anchored to James Forshaw's October 2021 Project Zero research on cross-protocol Kerberos relaying [@krb-relay-pz] and operationalised in the cube0x0/KrbRelay tool released shortly thereafter [@cube0x0-krbrelay], exploits the absence of channel binding in some pre-authentication flows. Silos enforce on the source-machine identity as presented in the AS-REQ; an attacker who can cause a different machine to issue an AS-REQ on the attacker's behalf and relay it can satisfy the Silo Policy. FAST (RFC 6113) provides the cryptographic primitive for channel binding [@rfc-6113]; Microsoft's Kerberos armoring uses FAST, and a Silo Policy can be configured to require FAST armoring. The open deployment question is whether FAST armoring becomes the universal default in legacy environments. The Palko post on the post-NTLM Windows authentication roadmap is the closest Microsoft has come to addressing the deployment direction publicly [@palko-evol].

Service-account placement: Protected Users vs. Silo-only. The unsolved sub-problem inside the RBCD residual. Service accounts have two failure modes: they cannot be placed in Protected Users without breaking their delegation workflows, and they cannot be left out without leaving an RBCD-attack primitive against tier-protected service accounts that have writable msDS-AllowedToActOnBehalfOfOtherIdentity. The current best partial result is composite: Group Managed Service Accounts plus a tight Silo Policy plus an ACL on the delegation attribute plus a SIEM rule on attribute writes. The architectural answer would be an extension to Protected Users that retains delegation-as-source but refuses NTLM, RC4, and DES. No such extension appears on Microsoft's public roadmap as of May 2026 [@ms-pu-current][@ms-mdi].

The settled controls are deployable. The open research is real and has not been closed. Five years from now, the Silo plane will likely still be the operational answer, with the residuals closed by different parts of the stack. What does that look like to a practitioner reading this on a Monday morning?

10. A six-phase playbook for deploying Method A this quarter

A staged playbook. The phases are ordered for safety: each phase reduces the blast radius of the next, and the first phase is the most important and the most often skipped.

Phase 0: Inventory Tier 0

Use the SpecterOps Tier Zero Table as the starting checklist [@tzt-github][@tzt-pages]. Pair it with BloodHound Community Edition to discover the attack paths your environment actually has into the T0 set [@bloodhound]. The Tier Zero Table is intentionally incomplete -- treat it as the floor, not the ceiling -- and add the assets specific to your environment: any service account whose compromise grants write access to a DC, any backup system that can restore a DC's NTDS.dit, any monitoring system that can run code on a DC. Sean Metcalf's body of work on secure workstation baselines is the canonical operator-grade reading for this phase [@metcalf-p3299][@metcalf-p1738].

Note: Do not start with Silo creation. Start with the T0 inventory. Every subsequent phase depends on a defensible list of what T0 contains. A T0 asset missed by the inventory is a T0 asset that is not Silo'd, not in Protected Users, and not behind a Conditional Access policy on the cloud side. Phase 0 is the single most-skipped step in failed Method A deployments and the single highest-value step in successful ones.

Phase 1: Create the T0 Admins Silo and Policy in audit mode

Create the msDS-AuthNPolicySilo named "T0 Admins" and its referenced msDS-AuthNPolicy named "T0 Source Restriction." Set msDS-AuthNPolicySiloEnforced=FALSE to start in audit mode [@ms-aps]. Place a single test admin account in Protected Users and assign it to the Silo. Set the Policy's UserAllowedToAuthenticateFrom SDDL to a SID set containing exactly one PAW. Confirm that authentication from the PAW succeeds, that authentication from a tier-2 workstation generates the expected audit event (Authentication Policy Silo audit failure in the Security log), and that nothing else in the environment breaks. Once the audit window is clean, flip the Silo to enforced mode. The KDC now returns KDC_ERR_POLICY for any AS-REQ from outside the allowed-from set [@ms-kile].

Phase 2: Catalogue every delegation relationship in the directory

Enumerate every account with msDS-AllowedToDelegateTo set, every object with msDS-AllowedToActOnBehalfOfOtherIdentity set, and every account with the legacy TrustedForDelegation UAC bit. For each T0-adjacent service account, decide whether the workflow can survive Protected Users membership. If yes, enrol the account and move on. If no -- which will be the common answer -- create a "T0 Services" Silo with a tight UserAllowedToAuthenticateFrom Policy, bind the account to the Silo, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, and audit Defender for Identity for the corresponding alerts [@ms-mdi]. The composite defence is the current best partial answer to the RBCD residual.

Group Managed Service Accounts (gMSA) are the preferred new-service-account primitive for the §6 reference deployment. The Microsoft Key Distribution Service (kdssvc.dll) on the domain controller derives the account's password from a domain-wide root key plus a per-account key identifier and rotates it on a configurable schedule; service hosts retrieve the current password through an ACL-controlled flow [@ms-gmsa-overview]. The cryptographic-rotation property -- not Silo membership -- is what closes the AS-REP roasting primitive in practical timeframes for a service-account workflow that the §6 PullQuote forbids from enrolling in Protected Users. Microsoft's How to Configure Protected Accounts page covers the wider per-account migration shape for legacy non-gMSA services [@ms-config-pa].

Phase 3: Roll the human T0 administrators into Protected Users in batches

Audit the longest-running tier-0 administrative task in your environment before you enrol anyone. Forest backups, replication health checks, schema upgrade dry-runs, DC promotions, and emergency operational procedures sometimes exceed four hours; the Protected Users 240-minute non-renewable TGT cap will silently re-authenticate or fail outright when they do [@ms-config-pa]. Enrol in batches of two or three administrators at a time; keep the previous batch in for at least two weeks before adding the next. Microsoft's How to Configure Protected Accounts page lays out the staged enrolment shape [@ms-config-pa].

Note: The 240-minute non-renewable TGT cap on Protected Users members is the single most common cause of failed pilot deployments. Tasks that ran fine for years quietly fail at the 4-hour mark, or worse, re-authenticate against a different identity that has lower privilege. Audit your longest-running T0 operations against the cap before enrolling humans; document workarounds (runas for long tasks; batch jobs running under gMSAs with a per-Policy lifetime configured deliberately) before the enrolment, not after.

Phase 4: Project the T0 group into Entra Conditional Access

Sync the T0 Admins group through Microsoft Entra Connect. Write a Conditional Access policy that requires phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based authentication) for that group, plus a compliant device, plus a known-good location if the threat model justifies it [@ms-pim]. Document explicitly that the CA is keyed on the synchronised group, not on the Silo binding; the two enforcement planes are independent by construction. The Entra side is the topic of the Conditional Access post in this series for the deeper treatment.

For the cloud-side treatment of Conditional Access policy shapes -- compliant device, phishing-resistant MFA grant control, location and risk conditions -- see the Conditional Access post in this series. The CA policy keyed on the synced T0 group is what holds the two-plane workaround together.

Phase 5: Break-glass

Two emergency-access accounts that are outside every Silo, outside Protected Users, with passwords stored offline in a tamper-evident envelope held by two separate people, with a documented monthly use-and-rotate procedure, and with high-fidelity SIEM detection on every authentication attempt. The cost of the break-glass pair is the deliberate, audited counter-balance to the rest of the architecture. Microsoft's RaMP guidance treats this as the first step of the privileged-access rollout [@ms-ramp]. The built-in domain Administrator (RID 500) is the natural canonical first break-glass identity because it is exempt from Authentication Policy enforcement even when assigned to a Silo [@ms-pu-current].

Microsoft's RaMP page lists "Emergency access accounts" as the first initiative of the entire Rapid Modernization Plan, ahead of Entra PIM and the on-prem controls [@ms-ramp]. The ordering is deliberate: a privileged-access deployment that locks itself out before it has secured the recovery path is worse than no deployment at all.

The Active Directory PowerShell module exposes the cmdlets directly. The skeleton below creates a Policy and a Silo in audit mode, then assigns one user. Adapt the SDDL to your PAW computer SIDs before running.

New-ADAuthenticationPolicy -Name "T0 Source Restriction" -UserTGTLifetimeMins 240 -UserAllowedToAuthenticateFrom 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "T0 Admins"))'

The @USER.ad://ext/AuthenticationSilo token in that SDDL is evaluated at AS-REQ time against the source machine's user-token claims, not against the requesting user's own Silo binding -- the Policy admits the requesting user only from devices whose computer accounts are themselves Silo members of "T0 Admins" (typically the T0 PAW set). The token's evaluation context is the source-device side of the request, which is the practical encoding of the source-machine pinning Method A relies on [@ms-aps].

New-ADAuthenticationPolicySilo -Name "T0 Admins" -Enforce:$false -UserAuthenticationPolicy "T0 Source Restriction"

Set-ADAccountAuthenticationPolicySilo -Identity alice.da -AuthenticationPolicySilo "T0 Admins"

Add-ADGroupMember -Identity "Protected Users" -Members alice.da

Run in audit mode (Enforce:false) for a full audit cycle, validate the Security log for Authentication Policy Silo events, then flip to enforced mode. The official PowerShell-cmdlet documentation is on the Microsoft Learn AD-cmdlet pages; the relevant deployment shape is described in How to Configure Protected Accounts [@ms-config-pa].

You have a playbook. You also have a set of questions readers are now going to ask. Here they are.

11. Frequently asked questions

No -- service accounts must not be (see §6's canonical Microsoft Learn PullQuote), and workstation users do not need to be (the Silo plane and Credential Guard handle their threat model). For human administrators, the answer is "yes, in batches, after testing" -- see §10 Phase 3's Callout on the 4-hour TGT cap, which is the single most common pilot break. Indirectly. Kerberoasting per se is defeated by AES-only enforcement and high-entropy passwords. Protected Users forbids RC4 and DES for its members, so a Silo'd and Protected human administrator cannot be roasted with the public RC4-dependent tooling. For service accounts that cannot be Protected, the defence is explicit AES enforcement via `msDS-SupportedEncryptionTypes` plus gMSA-managed high-entropy passwords [@ms-config-pa]. Defender for Identity surfaces accounts that still use RC4 [@ms-mdi]. No. Two independent planes. The PRT does not carry `msDS-AssignedAuthNPolicySilo`, and Conditional Access does not consume it. The standard alignment is to synchronise the Silo'd group through Microsoft Entra Connect and write a CA policy keyed on the synced group. The CA sees the synchronised group, not the Silo. Both planes must hold for a hybrid privileged identity to be safe [@ms-eam][@palko-evol]. Closing the gap requires either a Microsoft product change or a third-party policy synthesiser; neither exists as a product surface in May 2026. Subtly. ESAE -- the Red Forest pattern -- was retired as a mainstream recommendation on December 15, 2020 [@ms-esae-retire]. The tier model as an *idea* was folded into the Enterprise Access Model [@ms-eam]; the directory-level controls (Authentication Policy Silos, Protected Users) remain Microsoft's recommended on-prem enforcement layer. New ESAE deployments are not recommended outside air-gapped OT, ICS, and SCADA scenarios; existing ESAE deployments operating as designed have no urgency to retire. KB 2871997 is the May 13, 2014 down-level backport of Protected Users client-side honoring and Authentication Policy / Silo client-side support to Windows 7, Windows 8, Server 2008 R2, and Server 2012 [@kb-2871997]. It is NOT the introduction of those features -- the introduction is Windows Server 2012 R2 GA on October 18, 2013 [@save-date-blog][@ms-pu-legacy]. The October 14, 2014 revision additionally shipped Restricted Admin Mode for RDP, which has its own cautionary history as the canonical example of a defence that became its own inverse [@kfalde-restricted-admin][@ms-rcg]. The schema supports it -- a Silo's `msDS-ComputerAuthNPolicy` link carries a Computer Policy with its own Computer TGT Lifetime, and DCs are valid Silo members in principle [@ms-aps]. The operational pattern doesn't do that, for two reasons. First, DCs are themselves the authentication authority, and Microsoft Learn's Authentication Policies and Silos page explicitly warns against changing Computer TGT Lifetime on DC class accounts because shortened TGT lifetimes disrupt replication and other DC-to-DC operations ("It is not recommended to change this setting" [@ms-aps]). Second, the Silo plane is built for the accounts that authenticate *to* DCs -- T0 admins, the AD CS computer account, the Entra Connect server -- where source-machine pinning is the high-impact control. Silo the accounts that authenticate to your DCs; protect the DCs themselves with the orthogonal directory primitives (KDC service-account configuration, Defender for Identity sensor deployment, code-signing and update management, physical isolation). The Tier Zero Table and BloodHound surface the DC-adjacent accounts that need Silo membership [@tzt-github][@bloodhound].

The directory now has the answer it lacked for sixteen years. Three controls, one ship, plus thirteen years of operational discipline to compose them, plus an explicit acknowledgement of the four residuals the KDC cannot close by construction. On the Tuesday morning in April 1997 when Paul Ashton posted his patched smbclient to NTBugtraq, no one in the AD product group could have written this article. They can now -- and the KDC, keyed on directory state, is the layer they would write it from.

Two Checkmarks and the Keys to the Kingdom: How Active Directory's Replication Protocol Became the Longest-Lived Credential Attack on Windows

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

Active Directory's replication protocol (MS-DRSR) lets any domain controller pull every secret in the directory from any other domain controller, and the access check gates on an ACL, not on whether the caller is actually a DC. Mimikatz's `lsadump::dcsync` (August 11, 2015) and `lsadump::dcshadow` (January 2018) are the read and write sides of this loophole; both remain in active operational use eleven years later because the protocol cannot be amended without breaking AD replication. Credential Guard cannot help -- the secret moves from a remote DC's NTDS.dit over the network, never touching the attacker's LSASS. The 2026 defender response is four parallel detection layers (posture, behavioral, network, graph) because no single layer catches every case, and the architectural fifth layer that would close the class is not coming.

1. Two Checkmarks and the Keys to the Kingdom

A non-admin service account, created during a 2017 file-server migration and never cleaned up, holds exactly two access-control entries on the contoso.local domain object: Replicating Directory Changes and Replicating Directory Changes All. From a Windows 11 workstation -- not a domain controller, not a tier-zero admin host, just a desk -- the attacker opens a Mimikatz prompt and types:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Sixty seconds later they have the krbtgt NT hash and Kerberos AES keys, and they own the domain. Credential Guard, enabled on every workstation in the building, never saw the credential transit anywhere in its scope.

That last sentence is the punchline of the entire field. The secret never touches the attacker's LSASS, so Credential Guard's design has nothing to say. The keys move from a remote domain controller's on-disk database, over an RPC channel, into the attacker's process memory. Credential Guard isolates LSASS on the local machine. It has no jurisdiction over what a remote DC chooses to send when asked nicely.

Note: Credential Guard isolates LSASS-resident secrets in a separate virtual trust level. DCSync reads secrets from a remote DC's NTDS.dit over MS-DRSR -- a network protocol attack, not a local-memory attack. Microsoft's Credential Guard documentation does not claim protection against MS-DRSR-based credential extraction [@credential-guard-considerations].

The 60-second timeline is not a marketing number. One RPC round trip per principal is the protocol's per-principal cost, fixed by specification. For a single high-value target -- and krbtgt is the highest-value target in any Active Directory forest, because its long-term key signs every Kerberos ticket -- the attack is over before a typical SOC operator has finished pouring coffee.

The four people whose names recur in this story are worth meeting now. Benjamin Delpy (gentilkiwi) wrote Mimikatz and authored both the DCSync read primitive (2015) and, with Vincent Le Toux, the DCShadow write primitive (2018). Vincent Le Toux built the original DCShadow implementation and the PingCastle posture-assessment tool. Sean Metcalf (Trimarc / ADSecurity) translated DCSync into operator vocabulary in the weeks after its release. Microsoft's Defender for Identity team ships the canonical first-party detections that fire on this attack class today.

This story is what happens when a 23-year-old domain-controller-to-domain-controller protocol's access check turns out to gate on an ACL, not on whether the caller is a domain controller. Two ACEs on one object should not give an attacker the entire credential trove. The fact that they do is not a bug in the implementation. It is a 1999 design assumption -- that nobody who is not a DC would ever speak this protocol -- that survived twenty-five years as a social convention and was nowhere written down in the access-check code.

The next section explains why Microsoft built this protocol in the first place, and why its access check forgot to ask the one question that would have closed the loophole.

2. Why the Protocol Exists at All

Rewind to February 17, 2000. Microsoft ships Windows 2000 Server, and Active Directory replaces the old NT 4.0 PDC/BDC model [@microsoft-windows-2000-launch]. NT 4.0 was single-master: one Primary Domain Controller held the authoritative account database, every Backup Domain Controller held a read-only copy, and a password change on the PDC propagated to BDCs through a hub-and-spoke replication channel. AD inverts the model. Every domain controller in an AD domain holds a writable copy of the directory; a password change on any DC must propagate to every other DC within minutes; the replication topology is a mesh, not a star.

Multi-master replication is the design constraint that forces MS-DRSR's existence. If any DC can accept a write, then every DC must be able to pull every change -- including secret attributes like unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, and supplementalCredentials -- from every other DC. There is no second protocol. Replication of secrets is replication, and replication is MS-DRSR [@ms-drsr-spec].

The RPC protocol by which any Active Directory domain controller can replicate any object, including secret attributes, from any other DC in the same forest. Layered over DCE/RPC; the current public specification is revision 46.0 dated March 9, 2026 [@ms-drsr-spec]. MS-DRSR is the mechanism that makes AD's multi-master replication invariant work. The MS-DRSR method (opnum 3) that returns changed objects within a naming context. A calling DC supplies a target DN and a set of replication flags; the called DC returns the object's attribute values, with secret attributes encrypted under a session-derived key. This is the protocol method that DCSync invokes. flowchart LR subgraph Domain["contoso.local domain"] DCA[DC-A
NTDS.dit] DCB[DC-B
NTDS.dit] DCC[DC-C
NTDS.dit] end DCA -- IDL_DRSGetNCChanges
unicodePwd, ntPwdHistory --> DCB DCB -- IDL_DRSGetNCChanges
supplementalCredentials --> DCA DCB -- IDL_DRSGetNCChanges
dBCSPwd --> DCC DCC -- IDL_DRSGetNCChanges
unicodePwd --> DCB DCA -- IDL_DRSGetNCChanges
ntPwdHistory --> DCC DCC -- IDL_DRSGetNCChanges
krbtgt keys --> DCA

The access check that gates IDL_DRSGetNCChanges is defined in [MS-DRSR] §4.1.10. It asks one question: does the calling principal hold the appropriate extended rights on the naming-context root being replicated? Extended rights are AD's mechanism for control-access permissions that do not fit into the standard ACL bit set [@ms-drsr-spec].

A schema-defined access-control right identified by a GUID rather than by a standard ACL bit. Extended rights are granted via an access-control entry on a target object and checked at runtime by the operation that requires them. The three replication extended rights are the canonical example: each is identified only by GUID, and each is checked by `IDL_DRSGetNCChanges` against the caller's effective rights on the naming-context root. A top-level replication partition of the Active Directory database. Every AD forest has at least three NCs: the Schema NC, the Configuration NC, and one Domain NC per domain (plus optional Application NCs). DCSync operates against the Domain NC root.

Three extended rights together form what practitioners call the rights triad. The two-checkmark version from §1 is the most-common configuration; the third right unlocks a smaller set of attributes flagged confidential. Microsoft's own AD schema documentation enumerates each one [@ad-schema-get-changes][@ad-schema-get-changes-all][@ad-schema-get-changes-filtered-set]:

The combination of three replication extended rights on a naming-context root: `DS-Replication-Get-Changes` (the baseline read), `DS-Replication-Get-Changes-All` (unlocks secret attributes), and `DS-Replication-Get-Changes-In-Filtered-Set` (unlocks attributes with the confidential flag). The first two are what most operators mean when they say "DCSync rights"; the third is sometimes required for completeness.

Right	Display name	Rights-GUID	What it unlocks	Introduced
`DS-Replication-Get-Changes`	Replicating Directory Changes	`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`	Baseline replication read	Windows 2000 Server [@ad-schema-get-changes]
`DS-Replication-Get-Changes-All`	Replicating Directory Changes All	`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`	Secret attribute replication (`unicodePwd`, `ntPwdHistory`, etc.) [@ad-schema-get-changes-all]	Windows Server 2003
`DS-Replication-Get-Changes-In-Filtered-Set`	Replicating Directory Changes In Filtered Set	`89e95b76-444d-4c62-991a-0facbeda640c`	Confidential-flag attributes [@ad-schema-get-changes-filtered-set]	Windows Server 2008

In a freshly-installed AD domain, four principal sets hold the rights triad by default on the Domain NC root: the Domain Controllers group, the Domain Admins group, the Enterprise Admins group, and the built-in Administrators group [@sean-metcalf-dcsync-2015]. Every other ACE on that object is a deliberate delegation choice made by some operator at some point in the domain's history.

Now read the access check carefully. It asks whether the caller holds the rights. It does not ask anything about who the caller is. The protocol does not check whether the caller's Service Principal Name is GC/... or ldap/... or anything else. It does not check whether the caller's machine account is in the Domain Controllers group. It does not check whether the caller's Kerberos service ticket was issued for a DC service. The whole gate is the ACL on one object.

This is the most consequential design omission in any Microsoft network protocol. Every other replication-style protocol in Windows ships some form of caller-machine-identity assertion. MS-DRSR shipped without one because, in 1999, nobody on the design team imagined an unprivileged workstation would speak the DC-to-DC protocol.

The 1999 closed-population design assumption is the load-bearing fiction underneath this whole story. The protocol's designers assumed -- entirely reasonably for the deployment universe of that decade -- that the only software that would ever implement an MS-DRSR client was the DC role itself, which Microsoft shipped, signed, and audited. No defender in 1999 was thinking about a Python script speaking DRSUAPI from a desk. The assumption was a social convention dressed as a security model, and it survived for fifteen years.

If the protocol exists to replicate every secret in the directory, and the access check is the ACL on one object, what stopped anyone from abusing it for the protocol's first fifteen years? That accidental safety period is the subject of the next section.

3. The Fifteen-Year Accidental Safety Period

Between 2000 and 2015, attackers who wanted the entire credential trove of an Active Directory domain had exactly one road open to them: reach a domain controller and steal its database. The reasons are not subtle. The credentials lived in one file -- C:\Windows\NTDS\NTDS.dit, an Extensible Storage Engine database protected by a Password Encryption Key wrapped under the BootKey scattered across four registry values in the SYSTEM hive [@ntdsxtract-repo]. Without code execution on a DC, there was no obvious way to ask the directory for its secrets in bulk.

The on-disk Extensible Storage Engine ("Jet Blue") database that holds every Active Directory object, including secret attributes. Located at `C:\Windows\NTDS\NTDS.dit` on every domain controller. The file is locked while AD DS is running; offline copying requires either Volume Shadow Copy snapshots, `ntdsutil ifm` bundling, or DC downtime [@mitre-t1003-003].

Three sub-techniques bloomed inside this constraint, and MITRE catalogs them collectively as T1003.003 OS Credential Dumping: NTDS [@mitre-t1003-003]. Each is operationally distinct, and each requires the same precondition.

G1a -- Volume Shadow Copy plus offline parse. The attacker runs vssadmin create shadow /for=C: on a domain controller, creating an instant point-in-time snapshot. They copy NTDS.dit and SYSTEM out of the shadow path, exfiltrate both files, and parse them offline with Csaba Barta's ntdsxtract toolkit [@ntdsxtract-repo] or Impacket's secretsdump.py running in offline mode. The parse walks the datatable ESE table row by row, decrypts the PEK with the BootKey, and decrypts each principal's secret attributes with the PEK.

G1b -- ntdsutil Install From Media. The built-in command ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\IFM" packages NTDS.dit and the SYSTEM hive into a clean bundle, intended for legitimate seeding of a new replica DC. With local admin on any DC, an attacker invokes it without involving VSS.

G1c -- LSASS injection of the long-term DC secrets. Mimikatz's pre-DCSync technique reads cached long-term secret material (including the krbtgt key) directly out of lsass.exe memory on a domain controller via lsadump::lsa /inject /name:krbtgt. The variant that turned this surface into a persistence implant was Skeleton Key, disclosed by the Dell SecureWorks Counter Threat Unit on January 12, 2015 [@skeleton-key-wayback]. Skeleton Key patches the NTLM and Kerberos validation routines in LSASS on a DC so that a single master password works for any account.

Skeleton Key sits at the boundary between credential dumping and persistence. It does not produce usable NT hashes or Kerberos keys for offline forging; it gives the attacker a backdoor at the authentication step. The 2015 community debate over Skeleton Key versus the (then-imminent) DCSync technique was settled decisively by DCSync's August release: dumping the hashes is more useful than backdooring the auth path, because dumped hashes survive a DC reboot and are forge-ready material [@skeleton-key-wayback].

Sub-technique	Mechanism	Canonical tool	Emitted artifact	Host artifact on DC
G1a VSS + offline parse	Point-in-time snapshot, file copy, offline ESE parse	`vssadmin` + `secretsdump.py` / `ntdsxtract`	NT hashes, Kerberos keys, password history	VSS event in system log
G1b `ntdsutil` IFM	Built-in admin command produces clean bundle	`ntdsutil "ac i ntds" "ifm"`	Identical to G1a	IFM staging directory
G1c LSASS inject	Read long-term secrets from `lsass.exe` memory	`mimikatz lsadump::lsa /inject`	`krbtgt` key and other LSA-cached secrets	Process access of `lsass.exe`

The structural cost across all three is the same: code execution as SYSTEM on a domain controller. Read that requirement slowly. In a mature enterprise with even a basic tiered-administration model -- no interactive logon to DCs from workstations, restricted-admin RDP, Privileged Access Workstations for Domain Admin sessions, Protected Users group membership for Tier Zero principals -- DCs are the most defended boundary in the network. An attacker who has crossed that boundary has, in operational terms, already won. The credential dump is the trophy lap.

flowchart TD Start[Attacker foothold
on workstation] Start --> VSS[G1a: VSS snapshot
+ offline parse] Start --> IFM[G1b: ntdsutil IFM
create full] Start --> Inject[G1c: LSASS inject
on DC] VSS --> Gate[SYSTEM on DC] IFM --> Gate Inject --> Gate Gate --> Creds[All domain credentials
NT hashes, Kerberos keys, krbtgt]

This is what made the closed-population design assumption survive its first fifteen years. The protocol's design was open to abuse from any joined workstation that held the rights triad, but nobody noticed because the cheaper attack road -- compromise a DC, parse the database offline -- still passed through a defended chokepoint. The ACL on the Domain NC was nowhere on a defender's risk register, because no offensive tooling existed that treated the ACL as the gate.

There was a question waiting to be asked, though. What if you could ask the DC to send you the credentials, using a protocol the DC already speaks fluently with its peers? The protocol's wire format is published. Microsoft Learn hosts the IDL. The DCs trust each other's calls by ACL. The only missing piece was a client implementation that any attacker could run from any joined machine.

In August 2015 the missing piece arrived.

4. Generation by Generation

August 11, 2015, 01:27 Central European Time. Benjamin Delpy commits 47,132 insertions to the Mimikatz repository in a single push titled "DCSync in mimikatz & for XP/2003." The diff introduces four new modules -- kull_m_rpc_drsr.c/.h and kull_m_rpc_ms-drsr.h/_c.c -- generated from the [MS-DRSR] IDL. They are an MS-DRSR client surface, slotted into kuhl_m_lsadump.c as the new lsadump::dcsync command [@mimikatz-dcsync-commit][@mimikatz-repo]. Vincent Le Toux is credited as co-author.

Six weeks later Sean Metcalf writes the canonical operator post and presents the technique at DerbyCon V on Friday, September 25, 2015, in the Track 1 (Break Me) slot from 3:00 to 3:50 pm [@sean-metcalf-dcsync-2015][@sean-metcalf-derbycon-2015]. The closed-population assumption shatters in a weekend.

A commit hash widely cited in operator forums for the DCSync introduction -- `79b3577aed999baac0352cb1ba3a5f86b6d29f34`, dated 2015-07-20 -- does not exist in the Mimikatz repository. A `git --no-pager log --all` against a fresh clone returns `fatal: bad object` for that hash; the GitHub commit URL returns 404; the GitHub API returns 422. The actual introducing commit is `7717b7a7173fa6a6b6566bbbc3e7372b464d988f`, authored by Benjamin DELPY at 2015-08-11 01:27:13 +0200, with the subject line *"DCSync in mimikatz & for XP/2003"* [@mimikatz-dcsync-commit]. Sean Metcalf's contemporary writeup at ADSecurity confirms August 2015 as the release month [@sean-metcalf-dcsync-2015]. The lesson for verifying any third-party claim about a Mimikatz commit is the same lesson Stage 1 of this article's research pipeline applied: clone the repo, run `git show`.

What follows is the story of four generations of attacker approaches against this protocol, each motivated by the operational limit of the previous one.

Generation 2: DCSync (2015-08-11 onward)

Mimikatz becomes a DRSUAPI client. Operator invocation is one line:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Behind that line, six wire steps fire:

sequenceDiagram participant A as Attacker workstation participant DC as Target DC (DRSUAPI) A->>DC: 1. resolve target DC by domain A->>DC: 2. IDL_DRSBind (interface UUID DRSUAPI) DC-->>A: 3. bind reply (handle, session key) A->>DC: 4. IDL_DRSGetNCChanges (opnum 3, MTX_ADDR DN, EXOP_REPL_OBJ) DC-->>A: 5. DRS_MSG_GETCHGREPLY (encrypted secret attributes) A->>A: 6. decrypt with session key, emit NT hash and Kerberos keys

The wire format is one round trip per principal. To dump every account in the domain, Mimikatz's /all /csv mode iterates the request server-side via the same opnum with paginating up-to-date vectors. Per-call wire size is a few kilobytes for a single user; full-domain bulk dumps run to tens of megabytes. Wall-clock time is dominated by network latency to the target DC [@sean-metcalf-dcsync-2015][@trellix-silent-domain-hijack].

The Generation-1 precondition is gone. The attack runs from any joined workstation. The Generation-1 host artifacts -- VSS events, IFM staging directories, multi-megabyte file copies -- all disappear. The only on-the-wire signature is "an IDL_DRSGetNCChanges call from an IP that is not a domain controller" -- which has to be detected at the protocol layer, not the host layer.

Sean Metcalf's 2015 post named the detection recipe in the same breath as the attack: "Configure IDS to trigger if DsGetNCChange request originates an IP not on the 'Replication Allow List' ..." [@sean-metcalf-dcsync-2015]. Every network detection rule in this space, including Microsoft's own ATA "Unusual Protocol Implementation" category two years later, descends from that one sentence [@ata-v17-release-notes].

DCSync is read-only. The ACL pair the attack exploits does not include directory-write rights. An attacker who wants to plant SID-history backdoors, modify userAccountControl flags, or write to AdminSDHolder needs a different primitive. The same trust loophole that gave them read access turns out to support a symmetric write side.

Generation 3: DCShadow (2018-01-24)

January 23-24, 2018. Benjamin Delpy and Vincent Le Toux present at BlueHat IL in Tel Aviv. The talk is titled "Active Directory: What can make your million dollar SIEM go blind?" [@youtube-bluehat-2018-dcshadow]. Four days later, on January 27, 2018, Delpy pushes the mainline merge to Mimikatz with commit ab18bd1, subject "Pushing @vletoux DCShadow in current branch with some adaptations" [@mimikatz-dcshadow-commit].

Vincent Le Toux contributed the original implementation; the BlueHat IL talk shared joint Delpy/Le Toux billing; the Mimikatz mainline merge commit ab18bd103a5cd7e26fb8d475c5ea0157d6633ca9 is dated 2018-01-27 01:37:55 +0100, four days after the conference disclosure. Le Toux is the same author behind PingCastle's posture-assessment tooling and the canonical dcshadow.com reference site [@mimikatz-dcshadow-commit][@dcshadow-com].

DCShadow inverts DCSync. Where DCSync makes the attacker a DRSUAPI client, DCShadow makes the attacker a DRSUAPI server. The mechanism: temporarily register an nTDSDSA object plus the associated SPNs in the Configuration NC; signal to a legitimate DC that the new "DC" wants to push changes via IDL_DRSReplicaAdd followed by IDL_DRSReplicaSync; the legitimate DC pulls the attacker's pre-staged writes through the replication channel as if they were legitimate peer replication; deregister to clean up [@mitre-t1207][@dcshadow-com].

sequenceDiagram participant A as Attacker (rogue DC) participant Cfg as Configuration NC participant T as Target DC A->>Cfg: 1. create nTDSDSA + server object A->>Cfg: 2. add SPNs (GC, DRS UUID) to machine account A->>T: 3. IDL_DRSReplicaAdd (dsaSrc = attacker) T->>A: 4. IDL_DRSGetNCChanges callback (target pulls) A-->>T: 5. staged writes returned as replication payload A->>T: 6. IDL_DRSReplicaDel A->>Cfg: 7. delete nTDSDSA, remove SPNs A directory operation that does not generate the standard Event ID 4662 / 4738 / 5136 object-modification events that the Domain Services Auditing subsystem emits for normal writes. Legitimate DC-to-DC replication is SACL-silent by design -- the audit subsystem intentionally suppresses change events on the replication channel to avoid drowning every DC in audit traffic on every directory change. DCShadow writes are SACL-silent because they ride the same channel.

That last design fact is the entire point of the talk title. A SIEM watching object-modification events sees nothing when a DCShadow write lands, because the modifications arrive on the replication channel that the SIEM intentionally ignores as routine DC chatter. The original 2018 framing -- "your million-dollar SIEM goes blind" -- was correct for SIEMs that monitored only object-modification events. We will see in §6 how that framing has aged.

DCShadow is write capability. An attacker who reaches it can plant SID-history backdoors (write S-1-5-21-...-519 for Enterprise Admins into a low-privileged account's sIDHistory), modify userAccountControl to clear ACCOUNTDISABLE on dormant high-privilege accounts, add ACEs to AdminSDHolder (which then propagate via the SDProp process to every protected admin account every 60 minutes), or set msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer to enable resource-based constrained delegation chains.

Generation 4: Permission-graph attacks (2018-present)

By 2018 the attack-side question had shifted. Holding the rights triad directly was no longer the interesting precondition; the interesting question was how to reach it transitively, through whatever chain of ACL delegations a real-world domain happened to contain. The umbrella term that emerged is permission-graph attack. Its terminal edge is still DCSync; its novelty is the path that gets you to the terminal.

Three primitives anchor this generation. Elad Shamir's Wagging the Dog (January 28, 2019) showed how writing msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer object enables S4U2Self plus S4U2Proxy impersonation of any user to that computer [@shenaniganslabs-wagging-the-dog]. Shamir's Shadow Credentials (June 21, 2021) demonstrated that writing msDS-KeyCredentialLink on a target account adds an attacker-controlled certificate trust, enabling Kerberos PKINIT authentication as that account without resetting its password [@eladshamir-shadow-credentials]. And Sean Metcalf's earlier work on AdminSDHolder template abuse showed that writing the AdminSDHolder ACL causes SDProp to propagate the new ACL onto every protected admin account every 60 minutes -- self-healing persistence that survives defender cleanup [@sean-metcalf-adminsdholder].

The unifying observation: DCSync is a terminal in a permission graph. The graph's nodes are AD principals; its edges are individual access-control entries (WriteDACL, WriteOwner, GenericAll, WriteProperty, AddMember, ForceChangePassword). Whoever can traverse the graph to the rights triad on the domain root has DCSync transitively. The attacker's job is no longer to invoke IDL_DRSGetNCChanges; it is to find the shortest path through the graph from a foothold to the rights triad. The defender's mirror job is to enumerate all paths into the rights triad and either prune them or monitor them.

gantt title Domain replication attack class evolution dateFormat YYYY-MM-DD axisFormat %Y section Attack Gen 1 NTDS.dit theft :a1, 2000-02-17, 2015-08-11 Gen 2 DCSync :active, a2, 2015-08-11, 2026-12-31 Gen 3 DCShadow :active, a3, 2018-01-24, 2026-12-31 Gen 4 Permission-graph chains :active, a4, 2018-06-01, 2026-12-31 section Defense BloodHound 1.0 DEF CON 24 :d1, 2016-08-06, 30d ATA 1.7 release :d2, 2017-04-01, 30d Azure ATP DCShadow alerts :d3, 2018-07-24, 30d Azure ATP rebrand to MDI :d4, 2020-09-22, 30d BloodHound v6.0 :d5, 2024-09-30, 30d BloodHound v6.3 Butterfly :d6, 2024-12-09, 30d BloodHound v8.0 OpenGraph :d7, 2025-07-29, 30d Trellix NDR Silent Hijack :d8, 2025-12-08, 30d

To make the read-side access check decision concrete -- and to expose how thin it actually is -- here is the logic of the gate written as a runnable function. This is pseudocode for the decision, not the protocol bytes:

{` // Illustrative model of the MS-DRSR access check on IDL_DRSGetNCChanges. // Returns "secrets returned" or "ACCESS_DENIED" given a caller's effective // rights on the naming-context root. function dcsyncAccessCheck(callerRights, ncRootDn, requestedAttrs) { const GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c';

const SECRET_ATTRS = new Set(['unicodePwd', 'dBCSPwd', 'ntPwdHistory', 'lmPwdHistory', 'supplementalCredentials']); const wantsSecrets = requestedAttrs.some(a => SECRET_ATTRS.has(a));

// Baseline read requires GetChanges. if (!callerRights.has(GET_CHANGES)) return 'ACCESS_DENIED'; // Secret attributes require GetChangesAll. if (wantsSecrets && !callerRights.has(GET_CHANGES_ALL)) return 'ACCESS_DENIED';

// Notice what is NOT checked: caller's SPN, machine-group membership, // ticket service, source IP. The access gate is the ACL, full stop. return 'secrets returned'; }

const attacker = new Set([ '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2', ]); console.log(dcsyncAccessCheck(attacker, 'DC=contoso,DC=local', ['unicodePwd', 'ntPwdHistory'])); `}

Four generations, eleven years, no Generation 5 in sight. What is the single insight that lets all of this exist, and why has nobody patched it?

5. There Is No DC Check

The whole structural error of this protocol is one missing question. Specification [MS-DRSR] §4.1.10 defines the access check on IDL_DRSGetNCChanges as: does the calling principal hold the rights triad on the naming context being replicated? [@ms-drsr-spec] That is the whole gate. There is no second check that asks "is the caller's service principal name a domain-controller SPN?" or "is the caller's machine account in the Domain Controllers group?" or "was the caller's Kerberos service ticket issued for a DC service?" The spec is empirically and literally just an ACL check on the NC root.

The empirical proof that a non-DC client succeeds lives in Mimikatz's kuhl_m_lsadump.c and its DRSUAPI client surface in kull_m_rpc_drsr* [@mimikatz-repo]. Mimikatz is software running on a workstation. It binds to the DRSUAPI interface UUID, calls IDL_DRSGetNCChanges, and the call returns. The protocol's behavior is correct by specification. The security model is the bug.

A major feature added to Mimkatz in August 2015 is 'DCSync' which effectively 'impersonates' a Domain Controller and requests account password data from the targeted Domain Controller. DCSync was written by Benjamin Delpy and Vincent Le Toux. -- Sean Metcalf, ADSecurity, September 2015 [@sean-metcalf-dcsync-2015]

Read Metcalf's verb carefully: impersonates. The scare quotes are doing work. The Mimikatz client is not pretending to be a DC in any cryptographic sense. It is not forging a machine-account ticket. It is not spoofing an SPN. It is not bypassing any signature check.

It is honestly making an authenticated call as the principal it actually is -- some user or service account that happens to hold the rights triad -- and the protocol honestly responds because its gate is satisfied. The "impersonation" framing is operator vocabulary borrowed from the social model the protocol was written under.

The 1999 designers assumed only DCs would speak. By that social contract, anyone who speaks must be a DC. The spec encoded the social contract by way of not encoding it at all. The ACL was the whole gate because, in 1999, the ACL was always satisfied by something that was always a DC.

flowchart TD Start[IDL_DRSGetNCChanges request arrives] Start --> Q1{"Caller holds rights triad
on the NC root?"} Q1 -- yes --> Return[Return encrypted
secret attributes] Q1 -- no --> Deny[ERROR_DS_DRA_ACCESS_DENIED] Start -.-> Absent["What the check does NOT ask:
Is the caller a domain controller?
Is the SPN a DC SPN?
Is the machine in Domain Controllers?"] Absent -.-> Nothing[no second gate exists]

This is the article's intellectual fulcrum. The 1999 closed-population assumption -- only DCs speak this protocol -- survives in 2026 as an open-population reality (anyone with the rights speaks it), and the closed-population assumption is nowhere written down in the access-check code. The fix that would close the model would require a second gate. The spec did not write one. The implementation cannot synthesize one without breaking every legitimate consumer that already operates without one (more on this in §8).

Key idea: The protocol's design is correct. The security model is the bug. No patch can fix this without breaking Active Directory replication itself.

There is a temptation, on first encountering this, to assume the missing gate is an oversight that Microsoft will eventually fix. That intuition is wrong, and it is wrong for a deeper reason than "Microsoft has not gotten around to it." If the protocol is the bug and the protocol cannot be amended, what defenses can possibly work in 2026? That question carries us into the next section.

6. What 2026 Actually Ships Against This

If the protocol cannot be fixed, the defender's question is no longer "how do I prevent DCSync?" but "which layer catches which class of attempt?" Four production detection layers ship against this attack class in 2026. None of them is individually sufficient. A fifth layer -- the architectural one that would close the structural error -- does not exist and is not coming.

Posture: enumerate who holds the rights

The posture layer reads the static ACL on the Domain NC root and surfaces every principal that holds any of the three rights. Microsoft Defender for Identity ships this as an Accounts security posture assessment family, computed continuously from MDI's per-DC sensors [@mdi-security-posture-accounts]. Vincent Le Toux's PingCastle exposes it as the C-DCSync finding in its critical-risks section. Tenable Identity Exposure exposes it as an indicator of exposure. Christopher Keim's 2025 practitioner guide documents the PowerShell pattern that AD administrators without a posture-tool license can run on demand [@keim-dcsync-rights]:

Illustrative model of the posture-layer check. In production, replace SAMPLE_ACL with output from Get-Acl in PowerShell or python-ldap against the live Domain NC root.

GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c' TRIAD = {GET_CHANGES, GET_CHANGES_ALL, GET_CHANGES_FILTERED}

DEFAULTS = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES_ALL}, ]

residual = {} for ace in SAMPLE_ACL: if ace['right'] in TRIAD and ace['principal'] not in DEFAULTS: residual.setdefault(ace['principal'], set()).add(ace['right'])

for principal, rights in residual.items(): print(f"{principal}: {len(rights)} of 3 replication rights") `}

The residual set is the operational unit of work. In a freshly-installed domain it is empty. In a ten-year-old forest with a history of mergers and migrations it typically contains five to twenty entries -- a mix of legitimately delegated identity-sync products and forgotten service accounts from projects nobody on the current operations team remembers.

In Microsoft's Enhanced Security Administrative Environment and the BloodHound conventions, the set of principals and assets whose compromise yields domain-wide control. The `krbtgt` account, members of `Domain Admins` and `Enterprise Admins`, the Entra ID Connect MSOL_ sync account, and any non-default principal holding the rights triad on the domain root are all Tier Zero by construction. The Microsoft Entra ID (formerly Azure AD) Connect synchronization service account, created on-premises during Entra Connect installation. The account name uses an `MSOL_` prefix followed by a hex suffix. It legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to the cloud directory; treating it as Tier Zero is the standard hardening recommendation. Microsoft Defender for Identity's (and ATA's earlier) internal baseline of which computers in the domain legitimately speak DRSUAPI to which DCs. Incoming `IDL_DRSGetNCChanges` requests are matched against this baseline; a request from a source outside the list fires the External ID 2006 alert.

An earlier scope document for this article quoted an MDI assessment titled verbatim "Remove non-admin accounts with DCSync permissions." That exact title does not appear on the live MDI Accounts security-posture-assessment page in 2026 [@mdi-security-posture-accounts][@mdi-security-posture-hybrid]. The surface exists -- MDI's Accounts and Hybrid security posture-assessment families together cover non-default principals with replication rights -- but the verbatim title was not reproducible.

Behavioral: catch the act after it fires

The behavioral layer watches network traffic and event logs for the act of DCSync or DCShadow as it happens. Microsoft's first-party stack lives in Defender for Identity and ships three canonical alerts [@mdi-alerts-classic]:

External ID 2006 -- "Suspected DCSync attack (replication of directory services)." Credential Access (TA0006), Persistence (TA0003). Technique T1003.006. Severity High. Trigger: a replication request is initiated from a computer that is not a domain controller.
External ID 2028 -- "Suspected DCShadow attack (domain controller promotion)." Defense Evasion (TA0005). Technique T1207. Trigger: a machine in the network tries to register as a rogue domain controller.
External ID 2029 -- "Suspected DCShadow attack (domain controller replication request)." Defense Evasion (TA0005). Technique T1207. Trigger: a suspicious replication request is generated against a genuine domain controller, indicative of DCShadow.

The product lineage is Microsoft Advanced Threat Analytics 1.7 (April 2017, where DCSync was covered under the umbrella "Unusual Protocol Implementation enhancements" detection category [@ata-v17-release-notes]); Azure Advanced Threat Protection (2018, where Tali Ash's July 24, 2018 Microsoft Tech Community post announced the two named DCShadow detections that became 2028 and 2029 [@tali-ash-azure-atp-dcshadow]); and Defender for Identity (the Microsoft Ignite 2020 rebrand, week of September 22-24, 2020 [@rcpmag-defender-rebrand]). The detection content carries forward unchanged across product renamings; what changes is the portal it surfaces in [@mdi-whats-new].

Open-source SIEM equivalents implement the same detection via Event ID 4662 on the domain object. The Sigma rule Mimikatz DC Sync (id 611eab06-a145-4dfa-a295-3ccc5c20f59a) fires on Event ID 4662 where Properties contains any of the three rights GUIDs or the literal string Replicating Directory Changes All, with AccessMask=0x100 [@sigma-rule-dcsync]. Splunk's parallel detection Windows AD Replication Request Initiated by User Account (rule 51307514-1236-49f6-8686-d46d93cc2821) implements the equivalent SPL search with the same MITRE T1003.006 annotation and the same known-false-positive list (Azure AD Connect, dcdiag.exe /Test:Replications) [@splunk-research-dcsync].

The SACL-event detection layer (Sigma + Splunk + every other SIEM-side implementation) requires that the operator first enable Advanced Security Audit policy Audit Directory Services Access under DS Access, with SACLs on the domain root auditing the three rights against Everyone, Domain Computers, and Domain Controllers. A fresh-install AD does not have these SACLs by default [@splunk-research-dcsync]. The detection rule's documentation calls out the prerequisite explicitly; many operators discover it only after wondering why their Splunk dashboard is silent.

Network: NDR on the DRSUAPI interface

The network layer parses DCE/RPC traffic on the wire, identifies the DRSUAPI interface by its UUID, and fires when an IDL_DRSGetNCChanges call originates from a source outside the legitimate-DC baseline. The canonical 2025 reference is Trellix Advanced Research Center's "Silent Domain Hijack: Uncovering the DCSync Attack and Detecting with Trellix NDR", published in week 50 of 2025 [@trellix-silent-domain-hijack]. Equivalent capability ships in Microsoft Defender for Identity's network analytics layer (the same sensor that powers External ID 2006) [@mdi-alerts-classic].

The Trellix writeup is explicit about the architecture: "Trellix NDR detects replication protocol abuse by analyzing abnormal DCE/RPC and MS-DRSR traffic. It detects DCSync-like behavior when replication requests are sent from non-DC hosts or unusual users" [@trellix-silent-domain-hijack]. The detection is independent of host-side telemetry, so it survives EDR tampering and works in environments where a DC is un-sensored from MDI's perspective.

Graph: BloodHound traverses the permission graph

The graph layer was built specifically for Generation 4. BloodHound, originally released by Andy Robbins, Rohan Vazarkar, and Will Schroeder at DEF CON 24 on August 6, 2016, models "you have DCSync rights to the domain" as a directed edge from a principal to the domain node, computed by combining the separately-collected GetChanges and GetChangesAll ACEs through nested-group membership [@wald0-bloodhound-intro][@defcon24-bloodhound-pdf][@bloodhound-edge-dcsync]. An operator queries "shortest path from any compromised principal to the DCSync edge into a Domain node" and gets back every transitive route into the rights triad.

The 2024-2026 release cadence is dense and matters:

BloodHound v6.0 (September 30, 2024) improved logic for identifying and creating complex edges requiring multiple permissions, including DCSync, when Authenticated Users or Everyone groups are involved [@bloodhound-v6-0-release-notes]. This closed a long-standing blind spot in which rights granted to a wildcard principal (the worst kind of delegation drift, often dating from compatibility settings in pre-2003 forests) were not surfaced as DCSync edges.
BloodHound v6.3 (December 9, 2024) introduced the Butterfly algorithm -- bi-directional risk analysis. Where the historical query was "which principals can attack this target?", Butterfly adds "which targets can be attacked from this compromised principal?" SpecterOps describes the algorithm in their blog post Unwrapping BloodHound v6.3 with Impact Analysis: "This is a massive upgrade to BloodHound Enterprise's risk analysis capability with a new algorithm we call 'Butterfly'" [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].
BloodHound v8.0 (July 29, 2025) introduced OpenGraph, generalizing the graph engine to model attack paths across non-AD systems (GitHub, 1Password, NPM, Snowflake) using the same Cypher front-end. The DCSync edge remains AD-specific; OpenGraph's relevance is that hybrid-cloud principals can now be modeled end-to-end [@bloodhound-v8-0-release-notes].

The graph layer is the only one that catches multi-hop chains to the rights triad. A principal A with GenericAll on group B, where B has the DCSync triad, is invisible to MDI's posture assessment but stands out as a one-hop path in BloodHound.

flowchart TD subgraph Posture[Posture layer] P1[MDI Accounts assessments] P2[PingCastle C-DCSync] P3[Keim PowerShell pattern] end subgraph Behavioral[Behavioral layer] B1[MDI 2006 / 2028 / 2029] B2[Sigma 611eab06] B3[Splunk 51307514] end subgraph Network[Network layer NDR] N1[Trellix NDR] N2[MDI per-DC sensor] N3[CrowdStrike DCE/RPC IoA] end subgraph Graph[Graph layer] G1[BloodHound DCSync edge] G2[v6.3 Butterfly Impact] G3[v8.0 OpenGraph] end P1 --> SOC[SOC alert queue] P2 --> SOC P3 --> SOC B1 --> SOC B2 --> SOC B3 --> SOC N1 --> SOC N2 --> SOC N3 --> SOC G1 --> SOC G2 --> SOC G3 --> SOC

The full layer-by-layer comparison is the load-bearing matrix of the entire 2026 SOTA:

Layer	What it inputs	What it detects	What it misses	False-positive class	Detection latency	Cost
Posture	NC-root ACL	Direct grant of the rights triad to a non-default principal	Multi-hop transitive paths; legitimate-principal abuse	Identity-sync products (Entra Connect MSOL_, third-party HR-IDM); legitimately delegated backup agents	24h score recomputation; ACE changes near real time	Built in to MDI; PowerShell variant free
Behavioral	Event ID 4662 or sensor-captured DRSUAPI traffic	The act of DCSync, or the DCShadow registration / replication, after it happens	Pre-attack staging; compromised-DC speaker; un-sensored DC blind spot	Azure AD Connect syncs; `dcdiag.exe /Test:Replications`	Minutes (alert "after the fact")	MDI license; Sigma / Splunk free with SACL config
Network	DCE/RPC packet capture	Wire signature of `IDL_DRSGetNCChanges` from non-DC source	Encrypted RPC payloads (per-principal granularity); sub-DC replicas misclassified	Same as behavioral plus Samba-DC peers	Seconds (passive inspection)	Commercial NDR appliance
Graph	LDAP-collected ACEs and group nesting	Multi-hop graph paths that could reach the rights triad	Net-new ACEs created after the last collection	Stale data showing principals that no longer hold the right	Hours to weeks (collection cadence)	BloodHound CE free; BHE commercial
Architectural (un-shipped)	TPM-attested DC machine identity	Pre-empts non-DC speaker entirely	Compromised DC speaker; rogue `nTDSDSA` registration	N/A	N/A (preventive)	Requires Microsoft protocol amendment

Four layers, dozens of products, no shortage of detections. Why isn't the problem solved?

7. Which Gap Does Each Defense Close?

The matrix in §6 has one structural observation that earns its keep. Read down the What it misses column. Each detection layer has a class of cases it cannot see. The posture layer cannot see transitive paths. The behavioral layer cannot see pre-attack staging or compromised-DC speakers. The network layer cannot see encrypted RPC payloads. The graph layer cannot see net-new ACEs created after the last collection. That is the load-bearing reason a mature defender runs all four in parallel instead of picking one.

Run a thought experiment. Suppose you ship only the posture layer. Your MDI assessment is green: no non-default principals hold the rights triad. An attacker compromises a workstation belonging to an unrelated business unit, finds that the BU has GenericAll on a group LegacyApp_Operators that itself has WriteDACL on the BackupOperators group, and adds themselves to BackupOperators. BackupOperators inherits a forgotten 2014 delegation of the rights triad through three levels of nesting. Then DCSync runs.

The posture layer never saw this because the residual list at the NC root is the four defaults. The graph layer would have surfaced the path. The behavioral or network layer would have fired the moment the DCSync call hit the wire. Without those layers, your green dashboard is a single-layer fantasy.

Now consider the inverse. You ship only the behavioral layer. MDI fires External ID 2006 -- but only after the request hits the DC. Your SOC's mean response time is twelve minutes. The attacker's mean complete-the-extraction time is sixty seconds. The detection is real; the response window is not.

The same structural observation applies on the attack side. The four attack primitives have very different precondition costs:

Attack primitive	Pre-condition	Output	Default detection layer	Tier of damage
DCSync via Mimikatz	Rights triad on NC root	Every secret-attribute value for one or all principals	MDI 2006; Sigma 611eab06; Splunk 51307514; NDR	Domain takeover (via Golden Ticket from `krbtgt`)
DCSync via Impacket	Same as Mimikatz; no on-target binary footprint	Same as Mimikatz, plus PtH / PtT auth modes	Same as Mimikatz (wire signature is identical)	Domain takeover
DCShadow	Domain Admin, local administrator on a DC, or `KRBTGT` hash (for rogue-DC registration) [@mitre-t1207][@dcshadow-com]	Arbitrary directory write, SACL-silent	MDI 2028 + 2029	Domain persistence (SID-history, AdminSDHolder ACE re-grant)
Gen-4 chains	Any ACE that transitively leads to the triad	Reach DCSync, then DCSync's output	BloodHound DCSync edge inbound paths	Domain takeover (composite)

DCSync via Mimikatz and via Impacket [@impacket-secretsdump] share the output (domain takeover via credential theft) and the default detection (the wire signature is the same). Their pre-conditions are identical. The Hacker Recipes documents Impacket's invocation surface for both pass-the-hash and pass-the-ticket modes [@hacker-recipes-dcsync]. This is why Impacket's secretsdump.py -just-dc has become the universal red-team and IR tool, while Mimikatz remains the reference implementation that every blue-team detection still names.

The Generation-4 row is the interesting one. Its pre-condition is dramatically cheaper than the other three (any ACE that leads to the triad, rather than the triad in hand). Its detection is by graph traversal, not by wire signature. This is why the 2024-2026 frontier in this space has been the graph layer: the attack-side cost asymmetry favors the chain-finding problem, so the defense-side investment has landed there.

A reader who has internalized the "no DC check" observation will naturally ask: surely the obvious architectural fix is to add a caller-machine-identity check? CVE-2020-1472, popularly known as Zerologon, is the counterexample. Secura's September 2020 whitepaper, published approximately one month after Microsoft's August 11, 2020 patch, documented that the Netlogon protocol's `ComputeNetlogonCredential` AES-CFB8 implementation used an all-zero initialization vector. An attacker who sends an all-zero `ClientChallenge` exploits the IV bug to authenticate with roughly 1-in-256 probability per attempt, then calls `NetrServerPasswordSet2` to reset the DC's machine account password (commonly to all zeros) and becomes that DC for protocol purposes [@secura-zerologon-whitepaper]. After Zerologon-class compromise, the attacker *is* a DC. Any architectural caller-machine-identity check on `IDL_DRSGetNCChanges` would have been satisfied. Zerologon is the canonical worked proof that promoting the access-check from "rights" to "rights and DC identity" raises the bar but does not change the class.

Note: Every detection layer in this space has a class of cases it cannot see. Mature defenders run all four (posture, behavioral, network, graph) because each layer is the only answer for a specific class of inputs, and accept that the un-shipped fifth layer (architectural) would only narrow the gap, not close it. Single-layer deployments produce confident but incomplete coverage.

If even the hypothetical perfect architectural fix would not close the class, what are the actual theoretical limits of any possible defense?

8. Why the Protocol Cannot Be Fixed

Two structural ceilings bound any conceivable MS-DRSR amendment. Both are provable from the specification's own definition of what it must do; both have been corroborated by the post-2018 industry consensus that detection (not prevention) is the only viable defender posture.

Ceiling 1: replicated secret material is the data the protocol exists to carry. MS-DRSR is the mechanism by which Active Directory's multi-master replication invariant holds. If IDL_DRSGetNCChanges did not return secret attributes -- unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, supplementalCredentials -- then a password change on DC-A would not converge to DC-B within the replication interval. AD's "any DC accepts any write and the others catch up within minutes" property would collapse [@ms-drsr-spec]. The protocol cannot stop returning secrets without ceasing to be the protocol. This is why "disable MS-DRSR" appears on every list of options that look attractive in a slide deck and break replication in production within minutes of being applied.

Ceiling 2: a machine-identity check on the caller would shift the attack class, not close it. Suppose Microsoft amended the access check on IDL_DRSGetNCChanges to require, in addition to the rights triad, a cryptographic proof that the caller's machine account is in the Domain Controllers group -- for example, that the call was made under a Kerberos service ticket issued for a DC SPN. This would defeat the Mimikatz-from-workstation case. It would also defeat every legitimate integration that today holds the rights triad on a non-DC service account: the Entra ID Connect MSOL_ account, third-party HR identity-management connectors, every backup and disaster-recovery tool that integrates at the AD level.

Worse, the new check would shift the attack class to compromising a DC's machine account -- CVE-2020-1472 Zerologon being the canonical worked example (see the §7 Aside for the mechanism). After a Zerologon-class compromise the attacker is a DC, so promoting the speaker check from (rights) to (rights and DC-identity) raises the bar but does not change the class [@secura-zerologon-whitepaper].

flowchart TD Fix[Proposed MS-DRSR fix] Fix --> A[Stop returning secrets
in IDL_DRSGetNCChanges] Fix --> B[Add machine-identity check
on the caller] A --> A1[AD multi-master replication breaks
password changes do not propagate] B --> B1[Legitimate integrations break
MSOL_ account, HR IDM, backup tools] B --> B2[Attack shifts to compromised DC
machine accounts e.g. Zerologon
CVE-2020-1472]

The honest structural fix would require a different replication architecture: a TPM- or HSM-attested DC machine identity, bound to a sealed replication key, with secret attributes encrypted under that key on the wire. No caller without the sealed key (or its hardware-bound equivalent on a different DC) could ever decrypt the response.

Microsoft has not announced any such architecture. Its closest published precedent in the Windows security stack is the LSAIso trustlet that Credential Guard uses for LSASS isolation -- a per-host isolation primitive applied to a per-host secret store. Applying the same idea to a multi-party wire protocol that must interoperate with twenty-five years of installed identity-sync tooling is a different engineering problem at a different scale. Microsoft has not committed to it.

Key idea: The replication attack class is structurally permanent. The honest defender response is detection-and-response, not prevention.

This is the article's humility moment. The reader who arrived at §5 thinking "this is fixable" should now understand why eleven years of attack/defense iteration have produced detection layers, not protocol revisions. The four-layer detection architecture is not a placeholder while we wait for Microsoft to ship the real fix. It is the real fix, conditional on the constraint that the protocol's job description does not change.

If the protocol is structurally unfixable, what exactly does 2026 still not solve operationally?

9. What 2026 Still Cannot Do

Five problems sit on the open-questions register in 2026. Each is documented in the literature. None has a satisfying answer.

The DCShadow gap window. MDI's External ID 2029 alert fires on the rogue DC's replication request, which is structurally after the rogue nTDSDSA registration has been committed. The alert documentation describes the detection as firing after the fact [@mdi-alerts-classic]. An attacker who completes the register-replicate-deregister cycle inside the alert's batch interval commits the persistence write before any SOC responder sees the alert. External ID 2028 (rogue promotion) fires earlier in the kill chain and partially closes the gap, but the gap is structural to the alert-batch model. The directory write that DCShadow lands -- a SID-history injection, an AdminSDHolder ACE re-grant -- survives the alert.

Encrypted-channel DCSync. DRSUAPI clients that negotiate AUTH_LEVEL_PKT_PRIVACY on the RPC binding (the modern hardened-DC default) encrypt the request and response bodies on the wire. Passive NDR sensors that depend on parsing the IDL_DRSGetNCChanges request to determine which principal is being targeted lose per-principal granularity.

The interface-bind packet is still in clear, so the existence of a DRSUAPI call is still visible, but the payload is not. The Microsoft channel-binding rollout that began in late 2023 (targeting LDAP rather than DRSUAPI, but cementing the broader trend toward encrypted directory traffic) makes this gap permanent on the wire side [@microsoft-ldap-channel-binding-kb4520412]. Detection moves into the DC itself via the MDI sensor model.

The legitimate-principal-compromise non-detection. A hijacked Domain Admin session that uses its rightful DCSync ability triggers no layer. The posture layer sees a default principal. The behavioral layer sees a request from a DC or admin workstation that the Replication Allow List baseline accepts. The network layer sees the same. The graph layer sees the principal as a default Tier Zero member. The MDI alert is explicit: the trigger is "a computer that isn't a domain controller" -- a compromised legitimate principal acting from a legitimately-baselined workstation does not fire it [@mdi-alerts-classic].

This is the failure mode that catches mature SOCs. The attacker who already has Domain Admin does not need to attack DCSync detection because DCSync detection is not designed for legitimate principal abuse. UEBA-style per-principal anomaly detection ("this DA has not run DCSync in 90 days; this DA running DCSync at 03:00 from a workstation it has not used before is anomalous") is the partial answer. No production product currently delivers it with low enough false-positive rates to be operationally useful for already-Tier-Zero principals.

Cross-forest replication abuse is under-instrumented. The interaction of DS-Replication-Get-Changes-In-Filtered-Set with the SPN-suffix routing matrix in multi-forest environments is poorly covered in public detection guidance. Large enterprises with M&A history hold dozens of trusts; the cross-trust edges are the least-audited surface in their identity architecture. BloodHound's SharpHound collector can enumerate cross-trust data, and v6.0's wildcard-principal fix improves the picture, but no fully automated detection pattern exists [@bloodhound-v6-0-release-notes].

Delegation-drift residual long tail. Even with the MDI Accounts security posture assessment perfectly tuned, the long tail of forgotten ACE delegations across a twenty-five-year-old forest with mergers, acquisitions, decommissioned products, and migrations remains the canonical entry point. Christopher Keim frames it unambiguously [@keim-dcsync-rights]:

"The defaults aren't the problem. The problem is delegation drift, backup agents, identity sync products, and application service accounts accumulate these rights over time, often with no documentation and no review." -- Christopher Keim, *"DCSync Attack: Finding and Fixing Replication Rights in Active Directory"* (2025) [@keim-dcsync-rights]

The posture-layer detection is necessary but not sufficient; the human-process loop -- documented ownership, periodic review, removal of unjustified ACEs -- is what closes the residual. Most enterprise SOCs are not staffed to run this loop at the cadence the residual requires.

Open problem	Why it matters	Current best partial result
DCShadow gap window	Persistence write commits before SOC sees the alert	Configure MDI to surface External ID 2028 (rogue promotion) with automated investigation and response to block RPC traffic from the suspected source [@mdi-credential-access-alerts]
Encrypted-channel DCSync	Passive NDR loses per-principal granularity	Hybrid deployment: NDR for cross-DC visibility, MDI on-DC sensor for per-principal granularity [@trellix-silent-domain-hijack]
Legitimate-principal compromise non-detection	The Tier Zero principal who already has DCSync rights triggers nothing	Reduce the count of DCSync-capable principals to a number a human can monitor; surface their DCSync activity to a high-severity review queue
Cross-forest replication abuse	Cross-trust DCSync paths are not enumerated by default	SharpHound trust-collection methods; manual BloodHound inspection of foreign-domain principals
Delegation-drift residual long tail	Posture surfaces the principals; humans still have to decide which are legitimate	Quarterly posture review with documented justification per non-default principal

What can a defender actually do on Monday morning, given all of the above?

10. What a Defender Does on Monday Morning

Three action lanes, in priority order.

Lane 1: inventory the rights triad

Read the Domain NC root's ACL. Filter on the three rights GUIDs. Subtract the four default principal sets plus any legitimately delegated identity-sync product (Entra ID Connect's MSOL_ account is the canonical exclusion). Every entry that remains gets a documented owner and a documented justification, or the ACE gets removed.

Operator-facing inventory script. The browser-runnable demo uses a hardcoded SAMPLE_ACL; in production, replace the SAMPLE_ACL with output from one of: PowerShell: Get-Acl "AD:$( (Get-ADDomain).DistinguishedName )" python-ldap: ldap_search(ncroot_dn, attr='nTSecurityDescriptor')

DEFAULT_OK = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

MSOL_ accounts: legitimate Entra ID Connect sync principals. Exclude by prefix, never by exact name (the suffix is random).

def is_known_legitimate(principal): return principal in DEFAULT_OK or '\\MSOL_' in principal

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3d4', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\hr_idm_connector', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\fileserver_old$', 'right': GET_CHANGES_ALL}, ]

findings = [] for ace in SAMPLE_ACL: if ace['right'] not in TRIAD: continue if is_known_legitimate(ace['principal']): continue findings.append(ace['principal'])

print("Principals to investigate:") for p in sorted(set(findings)): print(f" - {p} -> document owner or remove ACE") `}

Anything in the Principals to investigate output is either a legitimately delegated service (document the owner and add to your exclusions; treat as Tier Zero) or a forgotten ACE from a project nobody remembers (remove it). Christopher Keim's framing is the operationally useful one: every common culprit is a backup tool, an identity-governance tool, or a service account from a long-dead migration [@keim-dcsync-rights].

The Microsoft Entra ID Connect synchronization service account, created on-premises during Entra Connect installation with an `MSOL_` prefix and a random hex suffix, legitimately holds the rights triad on the Domain NC root. It must -- it has to replicate password hashes to the cloud directory so that Entra ID can validate cloud logons against on-premises credentials. Removing its ACE breaks Entra ID password hash sync within a single replication interval, and your help desk will know about it.

The right answer is not to remove the ACE. It is to treat the MSOL_ account as Tier Zero. Dedicated host (the Entra Connect server itself, hardened as a DC-tier asset). No interactive logon. Multi-factor authentication on any privileged use. Conditional access policies that block sign-in from anything other than the Entra Connect service identity. The MDI Hybrid security posture-assessment family documents the surrounding controls [@mdi-security-posture-hybrid].

Lane 2: enable the canonical alerts and audit

Three configuration items.

First, ensure Microsoft Defender for Identity (or an equivalent identity-threat-detection product) is deployed with a sensor on every DC. The un-sensored-DC gap that the MDI alert documentation explicitly warns about creates a structural blind spot that an attacker will preferentially target [@mdi-alerts-classic].

Second, enable Advanced Security Audit policy Audit Directory Services Access under DS Access and apply SACLs on the Domain NC root that audit the three replication rights against Everyone, Domain Computers, and Domain Controllers. This is what makes Event ID 4662 fire on the request, which is what the Sigma 611eab06 and Splunk 51307514 rules consume [@sigma-rule-dcsync][@splunk-research-dcsync]. A fresh-install AD does not have these SACLs by default; the most common reason a SIEM dashboard for DCSync is silent is that the SACL never got applied.

Third, deploy or configure NDR coverage on the inter-DC subnet, with a rule that fires on DRSUAPI bind requests originating from source IPs outside the legitimate-DC baseline. Trellix NDR, Microsoft's MDI sensor, CrowdStrike Falcon, and community Zeek/Suricata rulesets all implement this [@trellix-silent-domain-hijack]. Where commercial NDR is out of budget, Sysmon with the SwiftOnSecurity or Olaf Hartong modular configuration surfaces Event ID 3 (NetworkConnect) and Event ID 22 (DnsQuery) outbound from non-DC hosts to DC RPC endpoints; a SIEM correlation rule can combine this endpoint-side signal with Event ID 4662 on the DC to approximate the network-plus-host signature without an appliance budget.

Lane 3: run BloodHound on the domain quarterly

Collect with SharpHound at minimum quarterly. Continuous collection if BloodHound Enterprise is available. Run the canonical query for the DCSync edge into the domain node. Trace inbound paths. Close the longest path first -- the longest paths are the ones a human operator is least likely to have noticed and most likely to have been delegated decades ago for a reason nobody remembers.

The v6.0 wildcard-principal fix is particularly worth a re-run on any forest that has been operated since before 2003: legacy Authenticated Users or Everyone ACEs on the domain root are exactly the kind of thing that survived a Server 2003 upgrade silently and never showed up in any subsequent audit [@bloodhound-v6-0-release-notes]. The v6.3 Butterfly algorithm lets you query the inverse view -- which targets fall if this principal is compromised? -- which is the right question to ask about any newly-discovered non-default DCSync holder [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].

What does not work

Four common misbeliefs are worth naming.

Note: See §1 -- Credential Guard does not stop DCSync. The secret transits remote-to-remote (a DC's NTDS.dit to the attacker's process), never local-to-LSASS, so the trustlet's isolation boundary has no jurisdiction over the call [@credential-guard-considerations]. Credential Guard is the right control for the local-memory attack surface and the wrong control for the network-protocol attack surface.

Note: After a confirmed DCSync of krbtgt, rotate the krbtgt account password twice, with at least ten hours between rotations. The first rotation invalidates the old key after the current Kerberos ticket lifetime expires. The second rotation invalidates the previous old key, which the directory stores alongside the current key for compatibility during replication convergence. Rotating only once leaves Golden Tickets forged from the dumped key valid for the duration of the second key. Rotating twice ten hours apart is what closes the window [@microsoft-new-krbtgtkeys]. (And neither rotation removes the ACE that allowed the dump in the first place: come back to Lane 1.)

Renaming krbtgt does nothing. The account's Relative Identifier (RID 502) is fixed by AD's design and is what the TGT signing key derives against, not the sAMAccountName [@microsoft-well-known-sids]. Renaming it to krbtgt-old-do-not-use confuses operators, not attackers.

Disabling MS-DRSR is not an option. The protocol is what makes AD replication work. Blocking opnum 3 at the RPC layer or refusing the DRSUAPI bind stops DCSync and stops every DC in the forest from talking to every other DC. Replication grinds. Password changes do not propagate. Domain joins fail. Within hours, the directory is split-brain across DCs, and within days, it is unrecoverable without DR-grade restore from backup: Microsoft's own AD-replication troubleshooting documentation walks the lingering-object pathology that produces exactly this split-brain when DCs stop replicating for longer than the tombstone lifetime [@microsoft-ad-lingering-objects].

On any DC, run `auditpol /get /subcategory:"Directory Service Access"` from an elevated prompt. If the output reads `No Auditing`, your Sigma / Splunk SACL-event detection will not fire because Event ID 4662 is not being generated. Enable with `auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable`, then apply the SACL on the domain root as described in the Splunk rule's implementation notes [@splunk-research-dcsync].

The six FAQ items in the next section cover the misconceptions that did not fit into any single lane.

11. Frequently Asked Questions

No. The access check on `IDL_DRSGetNCChanges` requires both the baseline `DS-Replication-Get-Changes` right *and* `DS-Replication-Get-Changes-All` to read secret attributes [@ad-schema-get-changes][@ad-schema-get-changes-all]. The *All* suffix unlocks the secret attribute set given the baseline right; it is not a self-sufficient gate. Christopher Keim's PowerShell pattern filters on both GUIDs together [@keim-dcsync-rights]. Confidential-flag attributes additionally require `DS-Replication-Get-Changes-In-Filtered-Set`. Some detection rules (Sigma 611eab06 included) accept either GUID in the SACL event because the operational cost of a false positive on the broader filter is lower than the risk of missing one of the two required ACEs being present without the other [@sigma-rule-dcsync]. No. Credential Guard isolates LSASS-resident secrets in a separate virtual trust level so that local-memory attacks (Mimikatz `sekurlsa::logonpasswords`, comsvcs.dll mini-dumps of `lsass.exe`, and similar) cannot read cached credentials. DCSync does not touch the attacker's LSASS at all. The secret transits from a remote DC's NTDS.dit, over an encrypted MS-DRSR session, into the attacker's process memory. Microsoft's Credential Guard documentation lists the scenarios Credential Guard does and does not cover; MS-DRSR-based network credential extraction is not in scope [@credential-guard-considerations]. This is one of the clearest examples in the Windows security model of a control that is right for one attack surface and orthogonal to another. Not anymore. The BlueHat IL 2018 "your million-dollar SIEM goes blind" framing was correct in 2018 against SIEMs that monitored only object-modification events: the replication writes are SACL-silent. By July 24, 2018, Tali Ash announced Azure ATP's two new preview detections, which fired on the rogue-DC promotion fingerprint (creating an `nTDSDSA` object in the Configuration NC) and the replication request from the rogue, respectively [@tali-ash-azure-atp-dcshadow]. Those detections carried forward as Microsoft Defender for Identity External IDs 2028 and 2029 [@mdi-alerts-classic]. The writes themselves remain SACL-silent; the *registration* fingerprint that has to precede them is not. The honest contemporary statement is "DCShadow's writes are silent, but the rogue-DC scaffolding is not, and a sensored DC catches the scaffolding." A skilled attacker who completes the register-replicate-deregister cycle inside the alert batch interval may still commit the persistence write before SOC response. No. The protocol's design is the issue. Microsoft has not announced any MS-DRSR amendment that would change the `IDL_DRSGetNCChanges` access check, because amending the access check breaks legitimate non-DC consumers (the Entra ID Connect MSOL_ account is the most prominent) and shifts the attack class to compromised DC machine accounts (Zerologon is the worked example [@secura-zerologon-whitepaper]). The "fixes" that have shipped since 2015 are all detection: ATA 1.7 (April 2017) [@ata-v17-release-notes], Azure ATP (2018) [@tali-ash-azure-atp-dcshadow], Microsoft Defender for Identity (post-Ignite 2020 rebrand) [@rcpmag-defender-rebrand][@mdi-whats-new], and the posture-assessment families that surface non-default rights triad holders [@mdi-security-posture-accounts]. The protocol itself is the same protocol it was in Windows 2000 Server. The MSOL_ sync account legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to Entra ID. Treat it as Tier Zero with the hardening profile listed in §10's MSOL_ Aside (dedicated hardened host, no interactive logon, MFA on privileged use, conditional access restricted to the Entra Connect service identity) [@mdi-security-posture-hybrid]. Critically, do *not* remove the ACE from the Domain NC root: doing so breaks Entra ID password hash sync within one replication interval, and your help desk will know about it within hours. No. DCSync is over DRSUAPI/MS-DRSR, not over LDAP. The directory's LDAP service refuses to return `unicodePwd` and related secret-attribute values regardless of caller privilege, because the attribute is marked confidential and the LDAP read path does not honor the replication extended rights. There is no "DCSync over LDAP" technique because LDAP simply does not return the data; MITRE T1003.006 names DRSUAPI explicitly as the protocol vector [@mitre-t1003-006]. Operators occasionally confuse this with LDAPS (LDAP over TLS) or with the November 2023 LDAP signing and channel-binding rollout, both of which are channel-protection concerns rather than credential-read concerns.

A final observation, since the closing should add something new. The protocol that this article calls structurally unfixable is not unusual. Most Microsoft security primitives that survive long enough enter the same regime -- the LSASS surface, the Kerberos delegation surface, the SMB authentication surface -- where the only honest answer is detection in depth because the protocol's job description and its abuse surface are the same surface viewed from different chairs.

The thing that makes MS-DRSR notable is the clarity with which the structural error is visible. Read §4.1.10 once and you are done. Everything from §6 onward is the industry's slow accumulation of detection layers around a gate that cannot be moved. Twenty-five years in, the gate is still where it was on February 17, 2000, and the four layers around it are still under active engineering.

Kerberos in Windows: The Other Half of NTLMless

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

**Kerberos was a 1988 protocol that solved one problem: mutual authentication on an untrusted network using a trusted third party.** Then it got piled on for thirty-three years. In 2026 NTLM is being switched off, the AS-REQ / AS-REP / TGS-REQ / TGS-REP skeleton is finally the single load-bearing authentication path for Windows, and the eleven attack primitives that exposed every joint of that skeleton between 2014 and 2022 are still mostly fixable by configuration, not by protocol. This is the companion to [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/): what happens to the protocol that takes over.

1. A Chain Without NTLM

Imagine a defender who has done every NTLM retrofit Microsoft has shipped. NTLM is disabled by default on the workstations. RestrictNTLMInDomain is on at the domain controller. SMB signing is enforced. Extended Protection for Authentication is set on every IIS endpoint. ESC8 has been patched. The defender has read the NTLMless post and ticked every box.

A low-privileged user on that network opens a PowerShell prompt. They run Powermad to create a fresh computer account. The default MachineAccountQuota is still 10, which means any authenticated domain user can create up to ten computer objects in Active Directory by design [@shenanigans-rbcd]. They then write a single LDAP attribute, msDS-AllowedToActOnBehalfOfOtherIdentity, on a target file server they have any write permission against. They ask the Key Distribution Center for a service ticket via Rubeus s4u, present that ticket to the target file server, and walk in as Administrator. Total elapsed time: less than this paragraph. Total NTLM in the chain: zero.

Note: The post-NTLM Resource-Based Constrained Delegation chain depends on three properties of Kerberos that are features, not bugs: (a) the default MachineAccountQuota = 10 setting on every fresh Active Directory forest, (b) the S4U2Proxy guarantee that always produces a forwardable TGS even when the input ticket was not forwardable, and (c) the absence of any KDC-side check on whether the requesting principal is a "trusted delegator". All three are documented behaviours of the protocol. None of them is a CVE [@shenanigans-rbcd].

The chain has a name and a primary disclosure: Elad Shamir's "Wagging the Dog" post on shenaniganslabs.io, January 28, 2019 [@shenanigans-rbcd]. The weaponised tooling is GhostPack's Rubeus, the C# Kerberos toolset that ships ready-made commands for s4u, asktgt, kerberoast, and diamond [@ghostpack-rubeus]. The single-line elevation wrapper that splices together Powermad, KrbRelay, Rubeus, and an SCM bypass is KrbRelayUp, published by Mor Davidovich ("Dec0ne") on April 24, 2022; its README scopes itself as a universal no-fix local privilege escalation in Windows domain environments where LDAP signing is not enforced (and that is the default) [@krbrelayup].

sequenceDiagram participant U as Low-priv user participant DC as Domain Controller / KDC participant T as Target file server U->>DC: Powermad: create machine account FAKE (machine account) U->>DC: LDAP write set RBCD attribute on T to allow FAKE U->>DC: AS-REQ for FAKE -> TGT U->>DC: S4U2Self as Administrator (non-forwardable TGS returned) U->>DC: S4U2Proxy with TGS returns forwardable TGS for cifs on T U->>T: AP-REQ presenting Administrator TGS T->>U: SYSTEM access on T

Read the chain twice. The first read shows that every step is a documented Kerberos exchange. The second read shows that removing NTLM did nothing to it. Restrict-NTLM, EPA, SMB signing, ESC8 -- the entire NTLM-retrofit catalogue has no edge against a Kerberos-only attack path that uses S4U2Self, S4U2Proxy, and the Resource-Based Constrained Delegation attribute exactly as Microsoft documented them in [@ms-kerberos-overview].

This is the article's load-bearing thesis. Removing NTLM did not remove the attack surface; it shifted the attack surface onto a protocol that is also thirty-three years old, also retrofitted, and now also the only load-bearing one. In October 2023, Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, wrote the post that committed Microsoft publicly to deprecating NTLM and named the Kerberos features that would replace it [@ms-palko-evolution]. The NTLMless companion article walked through the NTLM-side mechanics of that transition. This one walks through the Kerberos side.

The question that drives everything that follows is the question the chain above forces: how did Windows arrive at a state where the most catastrophic post-NTLM Active Directory attack chain depends on Kerberos working exactly as the 1989 designers intended?

2. Origins: Needham, Schroeder, Athena, and 1988

Kerberos is not new engineering. The story of Windows authentication in 2026 starts with two Xerox PARC researchers and a 1978 paper in Communications of the ACM.

In December 1978, Roger M. Needham and Michael D. Schroeder published "Using Encryption for Authentication in Large Networks of Computers" in CACM 21(12), pages 993 to 999 [@needham-schroeder]. The paper is paywalled on the ACM Digital Library, but RFC 4120's own Background section names it as the parent protocol [@rfc4120] and the Wikipedia article on the Needham-Schroeder protocol preserves the message structure verbatim [@wiki-needham-schroeder]. The symmetric-key version of that protocol is five messages long, and it is the structural blueprint of every "ticket from a trusted third party" design that followed.

$$A \to S:\ A, B, N_A$$ $$S \to A:\ {N_A, K_{AB}, B, {K_{AB}, A}{K{BS}}}{K{AS}}$$ $$A \to B:\ {K_{AB}, A}{K{BS}}$$ $$B \to A:\ {N_B}{K{AB}}$$ $$A \to B:\ {N_B - 1}{K{AB}}$$

A and B are the principals; S is the trusted third party; K_AS and K_BS are pre-shared long-term keys; K_AB is the session key that S mints for the conversation; N_A and N_B are nonces. The "ticket" is the part of the third message that A cannot decrypt and just forwards to B. That structure -- a server-issued cryptographic envelope intended for somebody else and opaque to the carrier -- is what becomes the Kerberos TGS thirty-eight years later.

Three years later, in August 1981, Dorothy Denning and Giovanni Maria Sacco published "Timestamps in Key Distribution Protocols" in CACM 24(8), 533-536. The paper is also paywalled on dl.acm.org, but the Wikipedia secondary preserves the finding: the Needham-Schroeder symmetric protocol is vulnerable to a replay attack if an attacker recovers an old session key [@wiki-needham-schroeder]. Denning and Sacco proposed timestamps as the fix. This is the structural reason every Kerberos ticket carries a timestamp and every Kerberos network requires a synchronised time service today.

A Kerberos administrative boundary, written in uppercase like `CONTOSO.COM`, that scopes a set of principals (users, services, computers) sharing a single Key Distribution Center. Every Kerberos ticket names the issuing domain in its `EncTicketPart.crealm` and `EncTicketPart.cname` fields. Active Directory binds one Kerberos domain to one AD forest root by default [@ms-kerberos-overview].

Between 1983 and 1991, MIT Project Athena -- the joint MIT, DEC, and IBM campus computing effort led by Jerome Saltzer -- needed a working authentication service for a distributed workstation network running over a hostile campus LAN. The Athena Technical Plan Section E.2.1, "Kerberos Authentication and Authorization System" [@mit-athena-plan], is the canonical internal design document. Steve Miller and Clifford Neuman did the protocol work; Jeffrey Schiller ran the network operations.

In February 1988, MIT published two complementary artefacts. Bill Bryant wrote "Designing an Authentication System: a Dialogue in Four Scenes" -- a pedagogical script in which an engineer named Athena designs her way step by step from "users type their password to every server" to "users obtain time-limited tickets from a trusted third party". Bryant's dialogue is the most cited pre-protocol document about why Kerberos exists in the shape it does [@mit-dialogue]. The same month, Jennifer Steiner, Clifford Neuman, and Jeffrey Schiller presented "Kerberos: An Authentication Service for Open Network Systems" at the USENIX Winter Conference in Dallas [@cerias-steiner1988]. The protocol that paper described -- later called Kerberos version 4 -- carried forward to v5 with ASN.1 encoding, extensibility hooks, and pre-authentication, but the AS / TGS / AP message-triple skeleton it specified is unchanged thirty-eight years later.

On January 24, 1989, MIT shipped the first public release of Kerberos v4 [@wiki-kerberos]. Five years later, in September 1993, the IETF adopted Kerberos v5 as RFC 1510 [@rfc1510]. RFC 1510 added ASN.1 encoding, cross-domain trust, and an extensibility hook called PA-DATA that every Kerberos extension since has used. In July 2005, RFC 4120 replaced RFC 1510 as the Kerberos v5 standard [@rfc4120].

sequenceDiagram participant C as Client participant AS as Authentication Service participant TGS as Ticket-Granting Service participant S as Application Server C->>AS: AS-REQ: identify yourself AS->>C: AS-REP TGT encrypted to TGS, session key wrapped under client long-term key C->>TGS: TGS-REQ: present TGT, ask for service ticket TGS->>C: TGS-REP service ticket encrypted to S, session key wrapped under TGT session key C->>S: AP-REQ: present service ticket S->>C: AP-REP: mutual auth confirmation

Kerberos in 2026 is the same protocol as Kerberos in 1988, with thirty-three years of extensions piled on top. The skeleton you draw on a whiteboard for a graduate seminar is exactly the skeleton a Windows 11 24H2 machine throws at a 2025 domain controller. The interesting question is what those thirty-three years of extensions did to the inside of every message.The default maximum clock skew between client and KDC in Windows Kerberos is five minutes (300 seconds), set by Group Policy "Maximum tolerance for computer clock synchronization" and documented in [@ms-kerberos-overview]. The five-minute window is the residue of Denning and Sacco's 1981 timestamp fix.

3. The Wire in 2026: Six Messages and an Encryption Matrix

Every Kerberos textbook draws the same six-message diagram you saw in Section 2. The diagram has been unchanged since 1988. What is different in 2026 is everything inside the messages.

Look first at the AS-REQ. In raw RFC 4120 the AS-REQ carries a req-body (client name, target name, requested lifetime, requested enctypes) and an optional padata field [@rfc4120]. That padata slot is the load-bearing extensibility hook of the entire protocol. Every Kerberos enhancement since 1993 has been a new PA-DATA type: PA-ENC-TIMESTAMP (the encrypted-timestamp pre-auth blob), PA-PK-AS-REQ (PKINIT [@rfc4556]), PA-FX-FAST-REQUEST (FAST armoring [@rfc6113]), PA-AS-FRESHNESS (PKINIT freshness [@rfc8070]). The skeleton survives only because the joints are extensible.

A `SEQUENCE OF { padata-type, padata-value }` field in the Kerberos AS-REQ and AS-REP messages, introduced in RFC 1510 (1993) and carried forward unchanged into RFC 4120 §5.2.7 (2005). PA-DATA is the only protocol-level hook by which a Kerberos client can prove possession of a credential before the KDC issues a Ticket-Granting Ticket, and the only hook by which an enhancement like FAST or PKINIT can attach new behaviour to the AS exchange without breaking compatibility with older clients [@rfc4120].

The AS-REP returns the TGT. The TGT itself is encrypted under the TGS's long-term key, so the client cannot inspect it. What the client can inspect is the EncTicketPart flag bitfield wrapped in the TGT envelope. RFC 4120 §2 enumerates the ticket-flag positions, including forwardable, proxiable, postdated, renewable, initial, pre-authent, hw-authent, transited-policy-checked, and ok-as-delegate [@rfc4120]. (may-postdate looks like a sibling but is a KDCOptions request bit per RFC 4120 §5.4.1, not a TicketFlags bit.) Pay attention to forwardable. In 2020, Jake Karnes of NetSPI demonstrated that an attacker who knew a service account's long-term key could decrypt the S4U2Self output ticket, set forwardable = 1, re-encrypt, and feed the ticket back to the KDC's S4U2Proxy step. The KDC accepted it. The bypass is CVE-2020-17049 and the attack is called Bronze Bit [@cve-2020-17049] [@netspi-bronze-bit].

Inside the ticket's AuthorizationData field is the Microsoft-specific construction that turns Kerberos into a Windows authorisation system. The Privilege Attribute Certificate, defined in [MS-PAC] revision 26.0 [@ms-pac-overview] [@ms-pac-deeplink], carries the user's SID, their group SIDs, their logon name, timestamps, and three cryptographic signatures: a Server signature, a KDC signature, and -- since CVE-2022-37967 in November 2022 -- a Full PAC Signature that covers the entire encoded PAC structure instead of just the existing signatures [@cve-2022-37967].

A Microsoft-specific authorization data element that the Kerberos KDC attaches to every ticket it issues for a Windows principal. The PAC carries the user's SID, group SIDs, logon name, and timestamps, and is signed by the KDC's `krbtgt` key and by the target service's key. The PAC, not the Kerberos ticket itself, is what gives a Windows file server the access-control information it needs to make a permission decision. Defined in [MS-PAC] [@ms-pac-overview]. The KB article URL ends in `cve-2022-37967` and the body text begins by referring to "CVE-2022-37966". This is not a typo in the citation -- it is a Microsoft filing artefact. November 2022 Patch Tuesday paired two Kerberos CVEs: CVE-2022-37967 (Full PAC Signature, KrbtgtFullPacSignature) and CVE-2022-37966 (default session-key encryption type). KB5021131 covers the deployment of the encryption-type bypass side. A sibling article, KB5020805, covers the Full PAC Signature side. When citing KB5021131 alongside the Full PAC Signature, both CVE numbers are relevant [@ms-kb-5021131] [@cve-2022-37967].

Then there is the encryption matrix. Kerberos abstracts ciphers behind the RFC 3961 framework [@rfc3961], which defines an enctype as a tuple of (encrypt, decrypt, checksum, string-to-key, key-derivation) functions. The history of Windows Kerberos is the history of which enctypes were the default at any given time.

Enctype	Number	Spec	Status in 2026
DES-CBC-CRC	1	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
DES-CBC-MD5	3	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
RC4-HMAC	23	RFC 4757 [@rfc4757]	Informational, not Standards Track; default-removed in mid-2026 per [@ms-beyond-rc4]
AES-128-CTS-HMAC-SHA1-96	17	RFC 3962 [@rfc3962]	Default since Server 2008; cross-version compatible
AES-256-CTS-HMAC-SHA1-96	18	RFC 3962 [@rfc3962]	Default since Server 2008; the mid-2026 destination
AES-128-CTS-HMAC-SHA256-128	19	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit K [@ms-kile-227]; no default-enable timeline
AES-256-CTS-HMAC-SHA384-192	20	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit L [@ms-kile-227]; no default-enable timeline

Enctype 23 is the row that built every Kerberoasting career. Kannan Jaganathan, Larry Zhu, and John Brezak of Microsoft published RFC 4757 in December 2006 [@rfc4757]. The IESG note on the RFC is unusually candid: the document is Informational, not Standards Track, because RC4-HMAC "do[es] not provide all the required operations in the Kerberos cryptography framework [RFC 3961]" and because of "security concerns with the use of RC4 and MD4". The choice that made enctype 23 dangerous, however, was upstream of the RFC. To make Windows 2000's Kerberos rollout backward-compatible with the existing SAM password database, Microsoft set the RC4-HMAC long-term Kerberos key equal to the NT hash of the user's password -- the same hash NTLM was already storing. As Microsoft's own October 2024 Kerberoasting guidance puts it verbatim: "RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key" [@ms-kerberoasting-guidance].

The function that converts a typed password into a Kerberos long-term symmetric key. For RC4-HMAC (enctype 23), `s2k(password) = MD4(UTF-16-LE(password))` -- the NT hash, no salt, no iteration. For AES-CTS-HMAC-SHA1-96 (enctypes 17 and 18), `s2k(password, salt) = PBKDF2-HMAC-SHA1(password, salt, 4096, dklen)` followed by RFC 3962 post-processing into a 128- or 256-bit AES key. The salt is the concatenation of the Kerberos domain name and the user principal name [@rfc3962].

The cryptography in that definition is short enough to read end-to-end. Here it is in JavaScript using the Web Crypto API:

{` async function kerberosStringToKey256(password, salt) { const enc = new TextEncoder(); const passKey = await crypto.subtle.importKey( "raw", enc.encode(password), { name: "PBKDF2" }, false, ["deriveBits"] ); const rawBits = await crypto.subtle.deriveBits( { name: "PBKDF2", salt: enc.encode(salt), iterations: 4096, hash: "SHA-1", }, passKey, 256 ); const hex = [...new Uint8Array(rawBits)] .map((b) => b.toString(16).padStart(2, "0")) .join(""); return hex; }

const password = "Summer2026!"; const salt = "CONTOSO.COMalice"; const keyHex = await kerberosStringToKey256(password, salt); console.log("PBKDF2-HMAC-SHA1 output (truncated AES-256 key):", keyHex); `}

That 32-byte output is the value LSA stores when an account is configured with msDS-SupportedEncryptionTypes bit E set. When a Kerberoasting attacker steals the TGS-REP, what they crack offline is which password produces that key. The RFC 3962 post-processing -- a single round of DK(key, "kerberos") -- shapes the output to AES key length but does not slow the dictionary attack down. The dispositive defence is not in the cryptography; it is in the password (or, more precisely, in not having one at all -- the move to gMSA and dMSA replaces typed passwords with KDC-generated random secrets [@ms-gmsa] [@ms-dmsa]). PBKDF2 at 4,096 iterations is well below modern PHC recommendations -- the 2023 OWASP guideline for PBKDF2-HMAC-SHA1 is 1.3 million iterations [@owasp-password-storage] -- but the 4,096 figure is wired into RFC 3962 and is the same on every supported Windows version. Service accounts using gMSA bypass this entirely: the gMSA's "password" is a 240-character random secret rotated every 30 days, derived by the Microsoft Key Distribution Service rather than entered by a human [@ms-gmsa].

The wire in 2026 is therefore six messages and a matrix of seven enctypes. The protocol skeleton is forty years old. In 2014 a SANS instructor named Tim Medin gave a forty-five-minute talk that turned every one of those enctypes into a problem.

4. The Attack Cascade: 2014 to 2022

September 26-28, 2014. Louisville, Kentucky. DerbyCon 4. Talk slot T120. Tim Medin -- then at Counter Hack Challenges, also a SANS instructor -- walks on stage with a forty-five-minute talk titled "Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades" [@irongeek-derbycon4]. The talk demonstrates that any authenticated domain user can request a TGS for any Service Principal Name in the directory, and that the service-portion of the returned ticket is encrypted under the SPN account's long-term key -- which, under RC4-HMAC enctype 23, is the NT hash of the password. Cracking the ciphertext is reduced to a dictionary attack against whatever password an admin set on the service account.

That talk is the moment Kerberos becomes interesting to attackers. The next eight years play out as a cascade. Five generations, each one named after the canonical primitive that defined it, each one exposing a different structural property of the protocol, each one earning its own engineered Microsoft response years later.

A unique identifier for a service instance in Active Directory, written in the form `service-class/host:port/service-name` (for example `HTTP/web01.contoso.com`). Kerberos uses the SPN to look up which account holds the long-term key that decrypts the service ticket. Any account that has an SPN -- a user account that has had `setspn -A` run against it, every machine account in the directory, every gMSA -- is a candidate for Kerberoasting [@adsecurity-kerberoast].

Generation 1, 2014: Kerberoasting

Tim Medin's primitive [@irongeek-derbycon4]. Will Schroeder's PowerShell weaponisation as Invoke-Kerberoast (later rolled into the C# Rubeus) [@ghostpack-rubeus]. Sean Metcalf's operational walkthrough on adsecurity.org [@adsecurity-kerberoast]. MITRE catalogued the technique in 2020 as ATT&CK T1558.003, which preserves the structural definition verbatim: "Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks" [@mitre-t1558-003].

The structural insight is the part that matters. The TGS-REP is encrypted with the service account's long-term password-derived key, so any domain user who can issue a TGS-REQ can mine ciphertext offline against any dictionary they care to assemble. The Kerberos protocol has no mechanism by which the KDC could tell whether the requesting user has any business asking for that SPN, because RFC 4120 has no concept of "this service is for these users". Anyone with a TGT gets the service ticket.

Microsoft's engineered response did not arrive until ten to twelve years later. Server 2012 introduced Group Managed Service Accounts: passwords randomised to 240 characters, derived by the Microsoft Key Distribution Service via kdssvc.dll, rotated every 30 days, retrievable from a domain controller by member hosts that are explicitly authorised in msDS-GroupMSAMembership [@ms-gmsa]. Server 2025 then introduced Delegated Managed Service Accounts (dMSA), which take the next structural step: the dMSA's secret is "derived from the machine account credential" held by the domain controller, and "the secret can't be retrieved or found anywhere other than on the DC" [@ms-dmsa]. The October 2024 Microsoft Security Blog formalised the Kerberoasting guidance in a single page that names RC4 as the load-bearing weakness and announces the deprecation [@ms-kerberoasting-guidance]. The December 2025 Beyond-RC4 announcement closed the cadence with a calendar date [@ms-beyond-rc4].

Generation 2, 2014-2017: Mimikatz Kerberos and AS-REP Roasting

Benjamin Delpy publishes mimikatz 2.0 on April 6, 2014; the v2 banner inside the repository README reads verbatim mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03) [@mimikatz]. The Kerberos module contains two commands that define the era: kerberos::golden (forge a TGT from the KRBTGT account's long-term key, granting Domain Admin equivalence indefinitely) and kerberos::silver (forge a TGS from any service account's long-term key, granting impersonation of any user against that service).

The structural insight: RFC 4120 has no online ticket validation [@rfc4120]. Once a ticket carries the right signatures, the service trusts it. Whoever holds a long-term key forges any ticket that key signs. Possession of a key collapses to ticket forgeability.

Around 2017, the same team behind Rubeus publicises AS-REP Roasting [@ghostpack-rubeus]: the same offline-cracking primitive as Kerberoasting, but against any account whose userAccountControl has UF_DONT_REQUIRE_PREAUTH (the DONT_REQ_PREAUTH flag) set. With pre-authentication disabled, the KDC will return an AS-REP encrypted under the user's password-derived key to anyone who asks for it, no proof of password possession required. The dispositive Microsoft response was already in place: pre-authentication has been required by default for all new Active Directory accounts since Windows 2000, and the flag has to be deliberately cleared by an administrator. The remaining vulnerability is operational hygiene -- finding the handful of legacy accounts an organisation has left with pre-auth disabled.

Generation 3, 2018-2020: Delegation Abuse

Three primitives in three years.

SpoolSample / PrinterBug. Lee Christensen (tifkin_, SpecterOps) published the PoC on GitHub on October 5, 2018 [@spoolsample]. The MS-RPRN remote-procedure-call interface includes a method, RpcRemoteFindFirstPrinterChangeNotificationEx, that any authenticated user can invoke against any host's spooler service to ask the spooler to please call back to an attacker-controlled address. The spooler obediently authenticates outbound using the machine account's credentials. Combined with unconstrained Kerberos delegation on the attacker-controlled host, the inbound authentication captures the target machine's TGT.

Wagging the Dog (RBCD). Elad Shamir's January 28, 2019 post on shenaniganslabs.io [@shenanigans-rbcd]. The TL;DR of the post is the load-bearing structural disclosure: "Resource-based constrained delegation does not require a forwardable TGS when invoking S4U2Proxy. S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute. S4U2Proxy always produces a forwardable TGS, even if the provided additional TGS in the request was not forwardable. By default, any domain user can abuse the MachineAccountQuota to create a computer account and set an SPN for it, which makes it even more trivial to abuse resource-based constrained delegation to mimic protocol transition" [@shenanigans-rbcd]. Every clause of that TL;DR points at a documented behaviour. The chain in this article's Hook is built directly on top.

Bronze Bit. Jake Karnes at NetSPI; CVE-2020-17049; disclosed November 10, 2020 [@netspi-bronze-bit] [@cve-2020-17049]. The NVD entry preserves Microsoft's verbatim description: "A security feature bypass vulnerability exists in the way Key Distribution Center (KDC) determines if a service ticket can be used for delegation via Kerberos Constrained Delegation (KCD). To exploit the vulnerability, a compromised service that is configured to use KCD could tamper with a service ticket that is not valid for delegation to force the KDC to accept it" [@cve-2020-17049]. The bypass: any service in possession of its own long-term key can decrypt the S4U2Self output ticket, flip the forwardable bit in EncTicketPart, and re-encrypt with the same key. Pre-2020 the KDC's S4U2Proxy validation accepted the resulting ticket because nothing on the ticket independently attested whether the forwardable flag had been set by the KDC or by the service itself. Microsoft's November 10, 2020 fix, per the NVD entry verbatim, "addresses this vulnerability by changing how the KDC validates service tickets used with KCD" so that the tampered flag is rejected [@cve-2020-17049]. The PAC signatures, contra a common framing, were never meant to cover the EncTicketPart flag bits in the first place.

Microsoft's engineered responses: the November 2020 Bronze Bit patch [@cve-2020-17049] tightened the KDC's S4U2Proxy ticket-validation step; KB5008383 (November 2021) [@ms-kb-5008383] issued the canonical "set ms-DS-MachineAccountQuota = 0 for non-administrator users" guidance; LDAP signing and channel binding work, ongoing since the NTLMless era, became the dispositive control against the relay variant of the chain.

Generation 4, 2021-2022: Certificate-Based Ticket Forgery and Kerberos Relay

Certifried. Oliver Lyak (ly4k) at IFCR disclosed CVE-2022-26923 to Microsoft, who patched on May 10, 2022 [@cve-2022-26923]. The attack exploited a quirk of how Active Directory Certificate Services (ADCS) bound a certificate's identity to an AD account when the certificate was used for PKINIT. Before the strong-mapping fix, AD's account-lookup at PKINIT time used the certificate's Subject Alternative Name (SAN) and matched the User Principal Name. If an attacker controlled a machine account, they could change the machine's dNSHostName to match a domain controller's, request a certificate via the (overly-permissive) default Machine template, and use the resulting certificate to PKINIT-authenticate to the KDC as that domain controller. Microsoft's response is documented end-to-end in KB5014754 [@ms-kb-5014754]: a new "strong certificate mapping" requirement that pins each issued certificate to a specific account SID via an X.509 extension (OID 1.3.6.1.4.1.311.25.2). The original release moved to Compatibility mode on May 10, 2022; full Enforcement mode took effect on February 11, 2025; Disabled-mode rollback was removed on April 11, 2023; the remaining Compatibility-mode fallback was removed on September 9, 2025 [@ms-kb-5014754].

KrbRelayUp. Mor Davidovich (Dec0ne), April 24, 2022 [@krbrelayup]. The README's universal-no-fix-LPE framing is preserved in the PullQuote below. The chain wraps Powermad (machine account creation), KrbRelay (Kerberos relay to LDAP), Rubeus (S4U2Self bypass of Protected Users, RBCD privilege addition), and SCMUACBypass (a wrapper that uses the resulting ticket to open the local Service Control Manager and create a service running as NT AUTHORITY\SYSTEM). The class of attack is "Kerberos relay" -- the post-NTLM cousin of NTLM-relay. The dispositive control is not a Kerberos patch; it is domain-wide LDAP signing plus channel binding plus Extended Protection for Authentication on ADCS Web Enrolment.

A universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings). -- Mor Davidovich, KrbRelayUp README, April 2022 [@krbrelayup]

Generation 5, 2022-2023: Forged-Ticket Sophistication

Diamond Ticket. Charlie Clark at Semperis co-authored a blog post in 2022 with Andrew Schwartz at TrustedSec disclosing the modern Diamond Ticket technique [@semperis-diamond] [@trustedsec-diamond]. The Semperis byline names the antecedent: a 2015 Black Hat EU presentation by Tal Be'ery and Michael Cherny ("Watching the Watchdog") that introduced the "Diamond PAC" idea. Verbatim from the Semperis post: "Golden Ticket attacks take advantage of the ability to forge a ticket granting ticket (TGT) from scratch, Diamond Ticket attacks take advantage of the ability to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC)" [@semperis-diamond]. The structural insight is that a Diamond Ticket has a legitimately issued, KDC-signed PAC at its base; only the privilege-claim fields inside the PAC are tampered. Before the November 2022 Full PAC Signature fix, the existing Server and KDC signatures only covered specific sub-structures, leaving room to modify the parts they did not sign.

Sapphire Ticket. Charlie Bromberg, also known online as "Shutdown", at Synacktiv [@pgj11-diamond-sapphire] [@thehacker-recipes-sapphire]. The community wiki The Hacker Recipes, which Bromberg maintains, documents the Sapphire Ticket technique end-to-end at thehacker.recipes/a-d/movement/kerberos/forged-tickets/sapphire [@thehacker-recipes-sapphire]. The verifiable third-party attribution lives at pgj11.com, which records verbatim: "One brand new technique is Sapphire Ticket. Created by Charlie Shutdown (twitter.com/_nwodtuhs) this approach is more stealthy. You can create a TGT impersonating any user assembling real TGT and real PAC combining S4U2Self + U2U ... He extended Ticketer from Impacket to add this attack" [@pgj11-diamond-sapphire]. The Sapphire Ticket bolts a legitimately KDC-issued PAC (obtained by chaining the S4U2Self and User-to-User Kerberos extensions to request a service ticket to oneself with the PAC of an arbitrary target user) onto a Diamond-style ticket. The result presents PAC signatures that the KDC itself produced. Unit 42's December 2022 "Next-Gen Kerberos Attacks" writeup is the secondary that joined Diamond and Sapphire into the same article and named them collectively the "Precious Gemstones" [@unit42-precious-gemstones]. Some secondary sources attribute Sapphire Ticket to Charlie Clark of Semperis. The misattribution probably stems from Clark's separate "AS Requested STs" post on the Semperis blog, which discusses a different technique exploiting unarmored machine-account AS-REQs and is not the Sapphire Ticket primary [@semperis-as-sts]. The verified Sapphire-Ticket originator is Charlie Bromberg (Shutdown, Synacktiv) per [@pgj11-diamond-sapphire]. The adsecurity.org URL ?p=2293 is Sean Metcalf's "Cracking Kerberos TGS Tickets Using Kerberoast -- Exploiting Kerberos to Compromise the Active Directory Domain" (not Metcalf's separate KRBTGT-account post, which lives at a different URL). The page is the operational walkthrough that pairs with Tim Medin's 2014 DerbyCon disclosure [@adsecurity-kerberoast].

Microsoft's engineered response to both Diamond and Sapphire was CVE-2022-37967, the KrbtgtFullPacSignature [@cve-2022-37967] [@ms-kb-5021131]. It is the first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, the KDC adds a Full PAC Signature that covers the entire encoded PAC, not just the existing sub-signatures. Diamond and Sapphire variants that modify any PAC field beyond what the Server and KDC sub-signatures already covered will fail validation.

The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly. -- Microsoft Security Blog, October 11, 2024 [@ms-kerberoasting-guidance]

The Spine Table

Generation	Year	Primitive	Structural Insight	Microsoft Response
1	2014	Kerberoasting [@irongeek-derbycon4]	TGS-REP is encrypted with the SPN account's long-term key; offline-crackable	gMSA (2012) [@ms-gmsa]; dMSA (2025) [@ms-dmsa]; Beyond-RC4 (2025-2026) [@ms-beyond-rc4]
2	2014-2017	Golden / Silver Ticket [@mimikatz]; AS-REP Roasting [@ghostpack-rubeus]	RFC 4120 has no online ticket validation [@rfc4120]; long-term key = forge equivalence	KrbtgtFullPacSignature (2022) [@cve-2022-37967]; preauth-required default since Windows 2000
3	2018-2020	SpoolSample [@spoolsample]; RBCD [@shenanigans-rbcd]; Bronze Bit [@cve-2020-17049]	MS-RPRN coercion; S4U2Proxy always returns forwardable; pre-2020 KDC did not independently validate the EncTicketPart flags	Bronze Bit patch (Nov 2020); KB5008383 MachineAccountQuota=0 (Nov 2021); LDAP signing
4	2022	Certifried [@cve-2022-26923]; KrbRelayUp [@krbrelayup]	ADCS template SAN-binding ambiguity; LDAP defaults unsigned	KB5014754 strong-mapping [@ms-kb-5014754]; LDAP signing + EPA on /certsrv/
5	2022	Diamond [@semperis-diamond]; Sapphire [@pgj11-diamond-sapphire] [@unit42-precious-gemstones]	PAC sub-signatures did not cover the encoded PAC structure	KrbtgtFullPacSignature (CVE-2022-37967, Nov 2022) [@cve-2022-37967]

timeline title Kerberos attack cascade section 2014 Sep 2014 : Kerberoasting (Tim Medin, DerbyCon 4) Apr 2014 : Mimikatz 2.0 (Golden / Silver Tickets) section 2017 2017 : AS-REP Roasting (Rubeus weaponisation) section 2018-2020 Oct 2018 : SpoolSample (PrinterBug, Lee Christensen) Jan 2019 : Wagging the Dog / RBCD (Elad Shamir) Nov 2020 : Bronze Bit (Jake Karnes, NetSPI) section 2022 Apr 2022 : KrbRelayUp (Mor Davidovich) May 2022 : Certifried (Oliver Lyak / ly4k) 2022 : Diamond Ticket (Clark / Schwartz) 2022 : Sapphire Ticket (Charlie Bromberg) Nov 2022 : KrbtgtFullPacSignature (Microsoft fix)

Eight years. Eleven structural primitives. One protocol. By 2022 the cascade slowed, not because the protocol got better, but because every primitive a thirty-three-year-old design could expose had been exposed. The 2022 Microsoft response, KrbtgtFullPacSignature, was the first one that targeted the structural properties (PAC coverage of its own structure) rather than the per-primitive patches that defined the 2014-2020 era. To see why that was a turning point, it helps to see exactly what the defensive cadence looked like before then.

5. The Defensive Cadence Before 2023

Each of the eleven primitives in Section 4 shipped with a fix. By 2022 every named primitive had a fix. And yet the cascade kept producing new primitives. Why?

The answer is in the shape of the defensive controls. Walk them in chronological order.

Protected Users (Server 2012 R2, October 2013) [@ms-server-2012-r2]. A new security group that triggers five non-configurable client-side protections and four non-configurable domain-controller-side protections [@ms-protected-users]. The client side: CredSSP "doesn't cache the user's plain text credentials"; Windows Digest "doesn't cache the user's plaintext credentials"; "NTLM stops caching the user's plaintext credentials or NT one-way function (NTOWF)"; "Kerberos stops creating Data Encryption Standard (DES) or RC4 keys ... or long-term keys after acquiring the initial Ticket Granting Ticket (TGT)"; "The system doesn't create a cached verifier at user sign-in or unlock" [@ms-protected-users]. The domain-controller side, also verbatim: members "cannot authenticate with NTLM authentication ... use DES or RC4 encryption types in Kerberos preauthentication ... delegate with unconstrained or constrained delegation ... renew Kerberos TGTs beyond their initial four-hour lifetime" [@ms-protected-users]. The limit is the obvious one: Protected Users breaks every workflow that relied on delegation, RC4, or NTLM, and there are many such workflows still in production.

Authentication Policy Silos (Server 2012 R2). A scope construct that lets administrators apply Protected-Users-equivalent constraints (no RC4, no unconstrained delegation, mandatory FAST) to tiered subsets of an organisation rather than per-account. The standard tier-zero / tier-one / tier-two split fits neatly under three silos [@ms-privileged-access].

A container of users, computers, and managed service accounts in Active Directory that scopes a single authentication policy. Members can be required to authenticate only from designated hosts, must use AES enctypes, may be excluded from delegation, and (when paired with FAST armoring) sign their AS-REQ inside a machine-account or anonymous-PKINIT armor. Available since Server 2012 R2; the operational granularity that Protected Users does not provide on its own [@ms-protected-users].

Restricted Admin (2014) and Remote Credential Guard (2016) [@ms-remote-credential-guard]. The RDP-side companions that block credential exposure on the target host. Both work by changing what gets sent on the wire during a remote sign-in: Restricted Admin (Windows 8.1 / Server 2012 R2 era) uses the user's TGT to authenticate via Kerberos network logon, so no credentials reach the target; Remote Credential Guard (Windows 10 1607, August 2016) performs the same trick but for interactive sessions, redirecting CredSSP back to the originating workstation [@ms-remote-credential-guard].

Credential Guard (Windows 10 RTM, 2015) [@ms-credential-guard]. Virtualization-Based-Security-isolated LSASS: secrets that LSASS would otherwise hold in user-mode memory are moved into the LSAISO trustlet running in Virtual Trust Level 1. SYSTEM on the box cannot read VTL1 memory. Credential Guard is the ceiling against memory-side ticket and key theft, and is one of the cross-link points to the NTLMless companion article.

FAST armoring (RFC 6113, April 2011). Sam Hartman and Larry Zhu's "A Generalized Framework for Kerberos Pre-Authentication" defines the FAST (Flexible Authentication Secure Tunneling) channel [@rfc6113]. The AS-REQ is wrapped in an outer armor envelope, keyed under the machine account's TGT (for a domain-joined client), an anonymous PKINIT TGT (for a non-domain-joined client), or a compound identity. The armor envelope encrypts the PA-ENC-TIMESTAMP blob and authenticates the entire request, closing the offline-cracking path that targets the encrypted-timestamp pre-auth. The limit: FAST is client opt-in, not on by default, and Server 2012 R2 domain functional level is the floor for compound identity. Many production environments still do not require FAST on their tier-zero accounts.

gMSA (Server 2012). The dispositive Kerberoasting defence for service accounts [@ms-gmsa]. The Microsoft Key Distribution Service (kdssvc.dll) computes a 240-character random password, rotated every 30 days, and member hosts authorised in msDS-GroupMSAMembership can retrieve it from a domain controller. The decisive property that gMSA closes is the human-typed-password assumption: there is no password to remember, write down, or share.

LDAP signing and channel binding. The dispositive KrbRelayUp defence. Set LDAPServerIntegrity = 2 to require signing on every LDAP bind, and LdapEnforceChannelBinding = 2 to require channel binding on TLS-bound LDAP connections. Both are off by default in older domain functional levels, which is exactly the default the [@krbrelayup] README is targeting when it calls itself "no-fix".

KrbtgtFullPacSignature (November 2022). The first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, every PAC carries an additional Full PAC Signature covering the entire encoded structure, not just sub-pieces; Diamond and Sapphire variants that previously evaded validation by tampering with un-covered fields now fail [@cve-2022-37967] [@ms-kb-5021131].

MachineAccountQuota = 0 guidance (KB5008383, November 2021) [@ms-kb-5008383]. The dispositive RBCD defence as a configuration: setting the directory-wide ms-DS-MachineAccountQuota attribute on the domain root to zero prevents non-administrative users from creating computer accounts at all, which kills the first step of the chain in Section 1's Hook.

Key idea: Each defensive control patches a primitive. No control patches the structural property of the protocol -- that any long-term symmetric key is forge-equivalent for every ticket type that key signs, and that the protocol's offline-validation guarantee makes online ticket revocation incompatible with the design.

Defence	Target Primitive	Structural Limit
Protected Users [@ms-protected-users]	Pass-the-Hash, Pass-the-Ticket, RC4 pre-auth	Breaks delegation, RC4, and NTLM; four-hour TGT cap may break legacy apps
Authentication Policy Silo [@ms-protected-users]	Per-tier scope of Protected-Users behaviour	Requires Server 2012 R2 DFL; FAST armoring requires Server 2012 R2 too
Credential Guard	LSASS memory theft (Mimikatz `sekurlsa::`)	Does not prevent ticket theft via legitimate Kerberos APIs
FAST (RFC 6113) [@rfc6113]	PA-ENC-TIMESTAMP offline cracking	Client opt-in; not on by default
gMSA [@ms-gmsa]	Kerberoasting on service accounts	Human-managed service accounts unaffected
LDAP signing + channel binding	KrbRelayUp [@krbrelayup]	Off by default in older domains
KrbtgtFullPacSignature [@cve-2022-37967]	Diamond and most Sapphire variants	Does not stop Sapphire variants whose tampered PAC was issued legitimately
MachineAccountQuota = 0	RBCD chain [@shenanigans-rbcd]	Default value is `10`; setting requires admin action

Read the table the way an attacker reads it. Each row is necessary; no row is sufficient. The "structural limit" column is the next-attack catalogue. Protected Users does not stop a Diamond Ticket forged from a stolen KRBTGT key. Credential Guard does not stop the operator who has SYSTEM on a domain controller. FAST does not stop AS-REP Roasting (because AS-REP Roasting only happens on accounts with pre-auth disabled, where FAST is moot). gMSA does not protect a service account someone still manages manually with a Notes-saved password.

The pattern is the answer to the section's opening question. Every control attacks one primitive -- a key, a flag, a coercion path, a ticket lifetime -- and none of them closes the protocol-level structural property that any long-term symmetric key in the domain is forge-equivalent for any ticket type that key signs. By 2022 the engineering catalogue was complete. The 2023 announcement was the first plan that targeted the structure.

What would a structural fix even look like, given that any "online revocation" change would also give up Kerberos's O(1) service-side validation, and given that any "deprecate the long-term key" change has to back-compat to clients that have not been touched since Server 2008? The October 2023 Palko post had answers.

6. The Breakthrough: Closing the Domainless Gap

October 11, 2023. Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, publishes "The evolution of Windows authentication" on the Windows IT Pro Blog. The article's <meta property="article:modified_time"> reads 2023-11-11T01:30:49.108-08:00 in the raw HTML; the description metadata reads "Discover how we're securing authentication and reducing NTLM usage in Windows" [@ms-palko-evolution]. It is the first time Microsoft commits publicly to deprecating NTLM, and the first time Microsoft names the three load-bearing engineering features that move Kerberos from "domain-only" to "load-bearing-for-everything".

The plan has four moving parts. Each one closes a specific reason that NTLM survived for thirty years.

IAKerb: Kerberos without KDC line-of-sight

The structural reason NTLM lived through Server 2003, Server 2008, Server 2012, and Server 2019 is that Windows had no Kerberos-equivalent path for the case where a client cannot reach a KDC. A laptop on a hotel network, a hybrid Azure-joined workstation that can reach the application server but not the AD DC, a workgroup machine attempting to access a domain file share -- all of those flowed back to NTLM by default, because Kerberos required a working AS-REQ to the domain controller before it could mint a TGT.

IAKerb (Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API) closes that gap. The draft IETF specification, draft-ietf-kitten-iakerb, is by Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman [@iakerb-draft]. The mechanism is GSS-API encapsulation: the client wraps each AS-REQ, AS-REP, TGS-REQ, and TGS-REP message inside a GSS-API token addressed to the application server, and the application server proxies the token to the KDC the server can reach. From the client's perspective, it is talking to the application server; from the KDC's perspective, the AS exchange came from the application server. The protocol's verbatim problem statement reads: "encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server" [@iakerb-draft].

Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. An extension to GSS-API Kerberos (RFC 4121) that encapsulates Kerberos AS / TGS exchanges inside GSS-API tokens between client and application server, so the application server can proxy them to a KDC the server can reach but the client cannot. Documented in the IETF draft `draft-ietf-kitten-iakerb` by Kaduk, Schaad, Zhu, and Altman [@iakerb-draft]. A Kerberos Key Distribution Center implemented as an in-process service inside the local Windows Security Authority (LSASS) on a workgroup or Azure-joined machine. The Local KDC issues tickets backed by the local SAM password database, exposing no Kerberos port to the network; clients reach it only through IAKerb encapsulation tunnelled through the application protocol. Closes the "local account auth has no KDC" gap that has kept NTLM alive for workgroups since Windows NT 3.1 [@ms-palko-evolution] [@fosdem-localkdc].

MIT krb5 added IAKERB support fifteen years ago. The README for krb5-1.9, released December 22, 2010, says verbatim: "Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services" [@mit-krb5-19-readme] [@mit-krb5-19-page]. The capability sat in MIT's mainline Kerberos for over a decade. Windows did not ship the equivalent because, until NTLM was on a deprecation path, Windows did not need it -- NTLM filled the line-of-sight gap. Once NTLM was on the road to removal, IAKerb stopped being optional. The sixteen-year gap between MIT krb5-1.9 IAKERB (December 22, 2010) and Microsoft's planned H2 2026 broad enable is the cleanest evidence that Microsoft's NTLM deprecation is the forcing function for the Kerberos refit, not a side effect. The specification was waiting for the customer demand to catch up.

Local KDC: Kerberos for the workgroup

The second structural reason NTLM survived was that Windows local accounts had no concept of "domain". Without an AD domain, there was no KDC. Without a KDC, there were no Kerberos tickets. Local-account authentication therefore flowed through NT challenge-response (NTLMv2) by default.

Local KDC closes this. The Local KDC, shipping in Windows 11 24H2 and Server 2025 with broad enablement targeted for H2 2026 [@ms-palko-evolution], is a Kerberos KDC built directly on top of the local SAM database. LSA derives an AES-256 long-term key from the local account's password rather than persisting the legacy RC4 NT hash. The Local KDC exposes no listening Kerberos port; clients reach it only through IAKerb encapsulation inside the application protocol (SMB, RDP, HTTP).

The parallel open-source path was demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025, where they presented "localkdc: A General Local Authentication Hub" [@fosdem-localkdc]. The abstract reads verbatim: "A local Kerberos Key Distribution Center (KDC) is not a new invention. It is a useful tool in combination with the Kerberos IAKerb extension but also allows to map SSO from a web authentication to local authentication or in a network environment isolated from the rest of the enterprise environment ... how use of NTLM in SMB protocol will be replaced by a localkdc in combination with IAKerb" [@fosdem-localkdc]. Samba 4.21 carries the prototype implementation.

The Bokovoy / Schneider talk is the cleanest external evidence that Local KDC is a *protocol-level* architecture, not a Microsoft-proprietary one. Samba, Heimdal, MIT krb5, and Microsoft are converging on the same design: an in-process KDC, GSS-API-tunnelled Kerberos exchanges, AES-keyed local accounts. The IETF draft-ietf-kitten-iakerb specification [@iakerb-draft] is the shared standardisation layer. Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services. -- MIT krb5-1.9 release notes, December 22, 2010 [@mit-krb5-19-readme]

PKINIT and the freshness extension

The third gap NTLM filled was non-password credentials. Windows Hello for Business, smart cards, and Federal Information Processing Standard token logon all need to translate "I hold this private key" into "I hold this Kerberos TGT". PKINIT (Public Key Cryptography for Initial Authentication in Kerberos), RFC 4556, by Larry Zhu (Microsoft) and Brian Tung (Aerospace Corporation), is the protocol for that [@rfc4556]. The AS-REQ carries a PA-PK-AS-REQ PA-DATA element wrapping an AuthPack CMS structure signed by the client's private key; the AS-REP carries the TGT keyed for the client to decrypt with either RSA key transport or Diffie-Hellman key exchange.

The 2006 RFC 4556 PKINIT had a replay window: an attacker who recorded a signedAuthPack could replay it indefinitely until the client's certificate expired. RFC 8070, "PKINIT Freshness Extension," by Michiko Short, Seth Moore, and Peter Miller of Microsoft (February 2017) closed it [@rfc8070]. The AS-REP issues an opaque PA-AS-FRESHNESS blob in a preliminary KDC-error round-trip; the client must echo the blob in its next signed AS-REQ; replays after the freshness window fail. Verbatim from RFC 8070 abstract: "exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange" [@rfc8070].

Together, RFC 4556 plus RFC 8070 anchor every modern non-password Windows credential: Windows Hello for Business, smart-card logon, FIDO2 keys mediated by Windows Hello, and the upcoming Entra-issued cloud TGTs. The 2022 Certifried CVE [@cve-2022-26923] forced the strong-mapping layer on top of all of this: every certificate used for PKINIT must carry an X.509 extension binding it to a specific AD account SID. KB5014754 [@ms-kb-5014754] tracks the rollout; see §4 for the full Compatibility / Enforcement / rollback-removal date sequence.

FAST armoring as default

The fourth gap was the trust assumption at the start of an AS-REQ: the encrypted-timestamp pre-auth blob, PA-ENC-TIMESTAMP, is keyed under the client's password-derived key, which is offline-crackable on observation. FAST (RFC 6113) wraps the AS-REQ inside an armor envelope keyed under a separate key the attacker does not see [@rfc6113]. In a domain-joined client the armor key is derived from the machine account's TGT; in a non-domain-joined client it is derived from an anonymous PKINIT TGT; in a compound-identity scenario it is the combination of both.

What changes in the 2023 plan is the default-on posture: Authentication Policy Silos can now require FAST for every AS-REQ from a silo member, and Local KDC clients use anonymous PKINIT armoring out of the box because the SAM-derived long-term key is the only credential available and offline-crackability would be catastrophic.

sequenceDiagram participant C as Client (no KDC reach) participant S as Application Server participant KDC as KDC (reachable from S) C->>S: GSS-API token: IAKerb (AS-REQ wrapper) S->>KDC: AS-REQ (forwarded) KDC->>S: AS-REP (forwarded) S->>C: GSS-API token: IAKerb (AS-REP wrapper) C->>S: GSS-API token: IAKerb (TGS-REQ wrapper) S->>KDC: TGS-REQ (forwarded) KDC->>S: TGS-REP (forwarded) S->>C: GSS-API token: IAKerb (TGS-REP wrapper) C->>S: AP-REQ presenting service ticket S->>C: AP-REP -- session established

The Gap-to-Closure Mapping

NTLM-fallback gap	Engineered closure	Primary source	Ship target
Client has no KDC line-of-sight	IAKerb GSS-API encapsulation	[@iakerb-draft]	Windows 11 24H2 / Server 2025; broad enable H2 2026 [@ms-palko-evolution]
Local accounts have no domain KDC	Local KDC on SAM + AES-256 derivation	[@ms-palko-evolution] [@fosdem-localkdc]	Windows 11 24H2 / Server 2025
Non-password credentials need an AS path	PKINIT (RFC 4556) + Freshness (RFC 8070) + strong mapping (KB5014754)	[@rfc4556] [@rfc8070] [@ms-kb-5014754]	Enforcement February 11, 2025; Disabled mode removed April 2023; Compatibility mode removed Sept 9, 2025
AS-REQ pre-auth is offline-crackable	FAST armoring (RFC 6113) default-on in silos	[@rfc6113]	Available since Server 2012 R2; default-on with new silos

After thirty-three years of layered extensions, Kerberos in 2026 is finally a single-protocol authentication path for every Windows scenario. Domain-joined, workgroup, Azure-joined without AD line-of-sight, local-account to local-account. The mechanism that closes the last gap -- IAKerb -- is a sixteen-year-old MIT protocol coming to Windows for the first time. What's left for Kerberos to fix is encryption-type hygiene, and a December 2025 Microsoft post named the calendar dates for that too.

7. The Beyond-RC4 Cadence

December 3, 2025. The Microsoft Windows Server Blog publishes "Beyond RC4 for Windows authentication" [@ms-beyond-rc4]. The post is short and specific. Verbatim: "By mid-2026, we will be updating the domain controller default assumed supported encryption types. The assumed supported encryption types is applied to service accounts that do not have an explicit configuration defined. Secure Windows authentication does not require RC4; AES-SHA1 can be used across all supported Windows versions since it was introduced in Windows Server 2008" [@ms-beyond-rc4]. For the first time in twenty years, RC4-HMAC is on a removal cadence with a calendar date and an enforcement CVE.

The rollout has three phases.

Phase 1, January 2026, audit only. Domain controllers gain new fields in Event ID 4768 (TGT issued) and Event ID 4769 (TGS issued): msDS-SupportedEncryptionTypes, Available Keys, and Session Encryption Type. The fields tell an administrator, for each ticket issued, which enctypes the requesting account had configured and which one the KDC actually chose. Two new PowerShell auditing scripts ship in the microsoft/Kerberos-Crypto GitHub repository: List-AccountKeys.ps1 enumerates every account and the enctype configuration on each; Get-KerbEncryptionUsage.ps1 parses the 4768 / 4769 log stream and prints accounts still requesting or being issued RC4 tickets [@ms-beyond-rc4]. Verbatim from the post: "we have enhanced existing information within the Security Event Log and developed new PowerShell auditing scripts. These enhancements are available in Windows Server versions 2019, 2022, and 2025" [@ms-beyond-rc4].

Phase 2, April 2026, default flip. The "assumed" msDS-SupportedEncryptionTypes on accounts that have no explicit setting changes from "anything the client asks for, including RC4" to "AES-SHA1 only". AES-SHA1 (RFC 3962 enctypes 17 and 18) has shipped on every supported Windows version since Server 2008 [@rfc3962], so the flip is theoretically backward-compatible with every domain-joined client; in practice the casualties are third-party Kerberos clients (legacy Linux MIT krb5 with RC4-only keytabs, network-attached-storage appliances stuck on older krb5 libraries, SQL Server linked servers with manually-configured service-principal RC4 entries).

Phase 3, mid-2026, enforcement. RC4 tickets require explicit per-account opt-in. The enforcement boundary is CVE-2026-20833, called out by name in the Microsoft post [@ms-beyond-rc4]. After that date, an account that has not had msDS-SupportedEncryptionTypes explicitly written to include 0x4 (RC4) will not be issued RC4 tickets, and DCs will reject any TGS-REQ that asks for one against an account configured AES-only.

Note: The mid-2026 RC4-default removal is gated on CVE-2026-20833, named in the December 2025 "Beyond RC4" post as the enforcement boundary [@ms-beyond-rc4]. The audit window closes when this date lands. Production environments that have not migrated their service accounts to gMSA or explicitly set msDS-SupportedEncryptionTypes will find Kerberos authentication failing for those accounts the day Phase 3 ships.

The interesting question is why the migration destination is AES-SHA1 (enctypes 17 and 18) and not AES-SHA2 (enctypes 19 and 20). RFC 8009 specifies AES-SHA2 [@rfc8009]; Microsoft's [MS-KILE] §2.2.7 supported-encryption-types bit table includes bits K (AES128-CTS-HMAC-SHA256-128) and L (AES256-CTS-HMAC-SHA384-192) [@ms-kile-227]. Linux MIT krb5 has shipped RFC 8009 since version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain interoperability between AES-SHA2 Windows and AES-SHA2 MIT works. The remaining work is purely Microsoft-side default enablement and the auditing infrastructure analogous to the RC4 cadence.

The Beyond-RC4 post does not name an AES-SHA1 -> AES-SHA2 timeline at all. The audit-default-enforce cadence Microsoft has now demonstrated for RC4 -- audit instrumentation in event logs, default flip with backward-compatible enctypes, enforcement gated by a named CVE -- has no announced analogue for AES-SHA1 yet.

Key idea: The cadence Microsoft has is audit, default, enforce. The RC4 to AES-SHA1 transition has all three: audit instrumentation in Phase 1, the default flip in Phase 2, and named enforcement via CVE-2026-20833 in Phase 3. The AES-SHA1 to AES-SHA2 transition has none. The [MS-KILE] bits exist; the cross-domain interoperability works; the Microsoft-side rollout is the missing piece. The microsoft/Kerberos-Crypto GitHub repository ships the two PowerShell auditing scripts (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1) that the December 2025 post names as the Phase 1 instrumentation. They are the right tools for an administrator who wants to find their RC4-dependent service accounts before the audit window closes mid-2026 [@ms-beyond-rc4].

Mid-2026 is the audit-window-closes date. The question for every AD operator is which of their service accounts will still be requesting RC4 tickets when the default flips, and whether their detection tooling sees them in the window. Two quarters from now, the answer "we'll just turn RC4 off and see what breaks" stops being a defensible operating posture.

timeline title Beyond-RC4 rollout section Phase 1 -- Audit Jan 2026 : Event 4768 / 4769 fields msDS-SupportedEncryptionTypes Available Keys Session Encryption Type Jan 2026 : Kerberos-Crypto GitHub repo with List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1 section Phase 2 -- Default flip Apr 2026 : Assumed msDS-SupportedEncryptionTypes flips to AES-SHA1-only for accounts without explicit configuration section Phase 3 -- Enforcement Mid 2026 : CVE-2026-20833 enforcement boundary -- RC4 tickets require explicit per-account opt-in

8. What Removing NTLM Cannot Buy You

After everything in Section 6 and Section 7 ships, Kerberos in 2026 is still vulnerable to four classes of attack. None of them are protocol bugs; all of them are protocol structure.

Kerberos has its own relay class. The KrbRelayUp README explicitly scopes itself to Windows domain environments where LDAP signing is not enforced -- the post-NTLM cousin of NTLM-relay [@krbrelayup]. The relay primitive survives the move from NTLM to Kerberos because the attack does not target the authentication protocol -- it targets the LDAP protocol's lack of mandatory integrity, and any authenticated bind (Kerberos or NTLM) is fair game once the channel is unsigned. The dispositive control is LDAP signing plus channel binding domain-wide, plus Extended Protection for Authentication on every AD CS Web Enrolment endpoint. It is a configuration, not a protocol fix. The NTLMless companion article walks through the LDAP-side work in detail.

The long-term-key problem is intrinsic to symmetric Kerberos. Whoever holds the krbtgt account's long-term key forges any TGT (the Golden Ticket primitive). Whoever holds an SPN account's long-term key forges any TGS for that service (the Silver Ticket primitive). RFC 4120's offline-validation property [@rfc4120] requires that the service trust the key alone -- the AP-REQ contains no callback to the KDC; the service decrypts the ticket, validates the signatures, and decides. Any change that adds an online "is this ticket still valid?" check also gives up Kerberos's O(1) service-side scaling and the offline-validation guarantee that makes the protocol cheap. Authentication Policy Silos, Protected Users, TPM-backed credentials, and Credential Guard all raise the cost of obtaining the key; they do not close the forge-equivalence property. Mathematically, if you have the key, you are the principal.

The PAC is a signed vouching token, not a verified live query. KrbtgtFullPacSignature [@cve-2022-37967] closes the modification side of Diamond and Sapphire. It does not close the staleness side. A user removed from Domain Admins at 09:00 still presents service tickets attesting Domain Admin membership until the ticket expires (default 10 hours user TGT, 7 days renewable; Protected Users members are capped at 4 hours [@ms-protected-users]). The PAC vouching window is the residual stale-authorization gap. The defender's option is shorter ticket lifetimes or out-of-band ACL flips at the service tier; the protocol itself has no callback by which a service learns about a group-membership change before the ticket expires.

Domainless does not mean keyless. Local KDC binds the SAM password to an AES-256 long-term key. The wire form of pass-the-hash is gone: there is no NT hash on the line, no LMv2 challenge response, no DES-CBC-MD5 keytab. But a NT AUTHORITY\SYSTEM-level attacker on the box still recovers the AES key, because LSA must materialise that key in user-mode memory to hand it to Kerberos. The chip- and VBS-based countermeasures (TPM-backed credentials, Microsoft Pluton, Credential Guard) remain orthogonal and necessary; none of them is replaced by Local KDC.

Key idea: H2 2026 ships Kerberos as the load-bearing single authentication protocol; it does not ship a Kerberos in which (1) the Kerberos-relay class is closed, (2) long-term-key forge-equivalence is closed, (3) PAC staleness is closed, or (4) local-key recovery from a SYSTEM-level attacker on the box is closed. The arc is a transition between tradeoffs, not out of them.

The Phase-3-as-transition-between-tradeoffs framing is mirrored in the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article's Section 8 -- the symmetric framing is deliberate. Read the two articles together as a paired diagnosis: NTLMless is the eulogy and the migration story; this article is the inheritance and the to-do list.

9. Open Problems and the 2026-2027 Edge

Five problems sit on the May-2026 research agenda. None has a shipping Microsoft answer.

The AES-SHA1 to AES-SHA2 Windows-default timeline. RFC 8009 [@rfc8009] is nine years old. The [MS-KILE] §2.2.7 supported-encryption-types bit table already includes the AES-SHA2 bits K and L [@ms-kile-227]. Linux MIT krb5 shipped RFC 8009 in version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain Kerberos interop between MIT clients and Windows DCs over AES-SHA2 works in the laboratory. What is missing is a Microsoft-side equivalent of the audit / default / enforce cadence already in place for the RC4 transition, especially because the hard part is not the cryptography but the long tail of third-party Kerberos clients and pre-2017 keytabs that an AES-SHA2 audit would have to enumerate before the default can flip. The 8009 cadence is the largest Windows-side cryptographic gap that has no announcement.

Quantum risk. Kerberos symmetric primitives (AES-128 and AES-256) retain a Grover-bound effective security margin of 64 and 128 bits respectively, which is durable against the near-term cryptographically-relevant quantum computer. PKINIT is the exposed half: the CMS signature chains in AuthPack are RSA or ECDSA per RFC 4556 §3.2 [@rfc4556], and both are broken by Shor's algorithm. Anonymous PKINIT, used for FAST armoring on non-domain-joined clients, has the same exposure. Microsoft has not announced a PKINIT-specific post-quantum cryptography plan; the Kerberos team's standardisation tracking sits on the IETF kitten working group's queue rather than on a shipping Windows roadmap. Cross-link to the post-quantum cryptography sibling article in this series.

dMSA field-deployment maturity. Server 2025 introduced Delegated Managed Service Accounts as the successor to gMSA [@ms-dmsa]. The protocol-level differences -- "Authentication for dMSA is linked to the device identity ... dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets" -- close several gMSA gaps, including the multi-tenant-key problem. But the 14-day account-migration window, the four-ticket-lifetime startup state during which both the legacy account and the dMSA can authenticate, and the cross-domain plus cross-forest behaviours are still being shaken out in field deployments. As of the May 2026 reading, dMSA is shipping but not yet the default for new service accounts.

Cross-cloud Kerberos. Kerberos Cloud Trust for Windows Hello for Business is the architectural piece that lets an Azure-joined laptop obtain TGTs from Entra ID rather than from an on-premises DC, with the on-premises DC trusting Entra's signatures via federation. Per [@ms-palko-evolution] the architecture is planned but unproven in the field at scale. The role of Local KDC in pure-Entra (no AD on-prem) deployments is still being defined. The trust graph for "Local KDC + Entra ID + on-premises AD" is one of the open architectural problems the Palko post mentions but does not yet detail.

Open-source IAKerb and Local KDC. Samba's localkdc work, demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025 [@fosdem-localkdc], is the most public open-source mirror of Microsoft's Local KDC plan. Heimdal has a partial implementation. MIT krb5 IAKERB has been shipping since krb5-1.9 on December 22, 2010 [@mit-krb5-19-readme] and is mature. The Local-KDC-on-the-SAM pattern is new to the Windows world specifically; in the open-source world the equivalent (a Kerberos KDC fed from a local user database) has existed in textbooks since Kerberos v4.

Each of the five problems is a residual. Each is the next decade's research. None of them invalidates the Phase 3 shipping commitment. The article's load-bearing closing claim is honest about that: H2 2026 is a transition, and what comes next will be its own multi-year cadence.

10. What an AD Engineer Should Do This Quarter

If you read nothing else from this article, read this. Seven controls; each one is tied to one primary Microsoft Learn or MSRC URL; each one closes one of the attack primitives in Section 4. Cross-link to the parallel practical-guide section in the NTLMless companion article.

Note: Run the two PowerShell scripts in microsoft/Kerberos-Crypto: List-AccountKeys.ps1 enumerates every account's configured enctypes; Get-KerbEncryptionUsage.ps1 parses your Event 4768 / 4769 stream and lists accounts still requesting or being issued RC4 tickets. The audit window closes mid-2026 when Phase 2 flips the default [@ms-beyond-rc4]. Every account on the list above is a Phase-3 production incident if you do nothing.

Note: Do not rely on the mid-2026 default flip. Explicitly write msDS-SupportedEncryptionTypes with the value 0x18 (AES-128 + AES-256, no RC4) on every service account that does not have a documented RC4 dependency. For service accounts that do, write 0x1C (AES-128 + AES-256 + RC4) and put a calendar reminder against the RC4 dependency so it gets remediated before Phase 3 [@ms-beyond-rc4].

Note: Manually-managed service-account passwords are the Kerberoasting attack surface per [@ms-kerberoasting-guidance]. gMSA gives you 240-character KDS-derived passwords rotated every 30 days [@ms-gmsa]. dMSA on Server 2025 binds the account secret to the device identity and stores it only on the domain controller, where it can be further protected by Credential Guard [@ms-dmsa]. There is no service-account workflow gMSA or dMSA does not cover; the migration is operational, not architectural.

Note: Setting ms-DS-MachineAccountQuota on the domain root to zero kills the first step of the RBCD chain in Section 1 [@shenanigans-rbcd] and the KrbRelayUp chain [@krbrelayup]. The default value of 10 has been the de facto attack-surface enabler since Windows 2000. The control is one PowerShell line: Set-ADDomain -Identity (Get-ADDomain) -Replace @{'ms-DS-MachineAccountQuota'=0}. The breakage surface is small: only legitimate computer-account bootstrap workflows that today rely on user-driven djoin.exe.

Note: Protected Users gives every member the five non-configurable client protections plus the 4-hour TGT cap [@ms-protected-users]. Wrap an Authentication Policy Silo around the same population to add mandatory FAST armoring [@rfc6113] and per-silo logon-from constraints. Both controls have been available since Server 2012 R2; the operational reason most environments still have not adopted them is the breakage in legacy delegation workflows. Audit and remediate those workflows; do not skip Protected Users.

Note: Set LDAPServerIntegrity = 2 (require signing) and LdapEnforceChannelBinding = 2 (require channel binding on TLS-bound connections) via Group Policy. This is the dispositive KrbRelayUp defence [@krbrelayup] and the dispositive defence against any Kerberos-relay-class attack that targets the LDAP control plane. Pair with Extended Protection for Authentication on every AD CS Web Enrolment endpoint to close the Certifried-style certificate-issuance variant [@ms-kb-5014754].

Note: Flight the RC4DefaultDisablementPhase Group Policy setting in your Insider channel; pilot non-production AES-only configurations on a representative subset of service accounts; identify legacy NAS appliances, Linux MIT krb5 clients with keytabs older than 2017, and SQL Server linked-server SPNs before Phase 2 closes the audit window [@ms-beyond-rc4]. Phase 3 ships with CVE-2026-20833; production environments that have not run the audit will discover the dependency list the day enforcement lands.

Three quarters from now (mid-2026), every default in this list will have changed. Do the work in the audit window or do it in the post-flip ticket queue. The cost of an audit-window migration is a quarter of engineering time; the cost of a post-flip remediation is a sixty-minute outage on every undocumented RC4 dependency the directory holds. Cross-link to the Pluton, TPM, and Credential Guard sibling articles for the hardware-backing layer that protects the long-term keys these controls assume.

11. Frequently Asked Questions

AES-SHA1 (RFC 3962 enctypes 17 and 18) is enough against the 2026 attack picture: there is no known cryptographic attack against AES-256-CTS-HMAC-SHA1-96 within Kerberos's threat model, and AES eliminates the salt-less / iteration-less Kerberoasting weakness of RC4-HMAC [@rfc3962] [@ms-kerberoasting-guidance]. AES-SHA2 (RFC 8009 enctypes 19 and 20) is the obvious next step and is supported by [MS-KILE] bits K and L [@ms-kile-227]. Quantum threats are not the immediate worry for symmetric Kerberos; the exposed surface is PKINIT, not the ticket cipher.The Grover speedup applied to AES-256 leaves an effective 128-bit security margin, which is durable for the lifetime of any current cryptographic system [@nist-pqc]. Yes, for delegation, and that is the point. Per [@ms-protected-users], members cannot use unconstrained or constrained delegation, cannot use DES or RC4 in Kerberos pre-auth, and have their TGT capped at four hours. Workflows that today rely on a domain admin's TGT being forwardable to a downstream service must be reworked. Use Authentication Policy Silos for the per-account scope where some delegation must remain. Yes, with risk. The mid-2026 enforcement boundary CVE-2026-20833 [@ms-beyond-rc4] is the formal cutover. Disabling RC4 today by setting `msDS-SupportedEncryptionTypes` to `0x18` (AES-only) on accounts will work, but expect breakage from Linux clients with MIT krb5 keytabs older than 2017, network-attached-storage appliances with hard-coded RC4 entries, and SQL Server linked-server SPNs that have not been updated. The audit-then-migrate cadence in Section 10 is the operationally honest path. No. It kills *unsigned-PAC* Golden Tickets and most Diamond and Sapphire variants that tampered with PAC fields outside the original sub-signatures [@cve-2022-37967]. If an attacker has the actual `krbtgt` long-term key, they still mint correctly-signed tickets -- the Full PAC Signature is computed with that same key. The defence is rapid `krbtgt` rotation (the dual-password scheme means you must rotate twice with an interval) plus Credential Guard to keep the key out of LSASS user-mode memory. PKINIT [@rfc4556] exists, Active Directory Certificate Services exists, Windows Hello for Business is built on top of PKINIT. The reason "everywhere" was hard is Certifried (CVE-2022-26923) [@cve-2022-26923] and the strong-mapping retrofit [@ms-kb-5014754]: the original ADCS templates allowed a certificate's Subject Alternative Name to be set independently of the AD account that requested the certificate, which let an attacker mint a certificate claiming to be a domain controller. Strong mapping (the SID-binding X.509 extension) closed that, but the rollout took years to land in Enforcement mode (see §4 for the full date sequence). It eliminates the *wire* form. There is no NT hash on the LSA-to-Local-KDC path; the long-term key is an AES-256 derivation. A SYSTEM-level attacker on the box still recovers that AES key, because LSA must hold it in user-mode memory to hand to the Kerberos SSP. The chip-side defences (TPM, Microsoft Pluton, Credential Guard) remain orthogonal and necessary per [@fosdem-localkdc]. Local KDC closes the relay-from-the-wire class, not the SYSTEM-on-the-box class. Kerberos Cloud Trust for Windows Hello for Business issues TGTs from Entra ID and federates trust back to on-premises AD, so an Entra-joined laptop can present a domain-trusted Kerberos ticket to a file server it has never directly authenticated to. The on-premises KDC role is partially federated; the on-prem AD signs nothing for the Entra-issued TGT but trusts Entra's signature via Cloud Trust. Per [@ms-palko-evolution] the architecture is shipping in stages. The full story is its own article in this series. Not in this decade. The architectural trajectory is "Kerberos + PKINIT + FAST + Local KDC + IAKerb + Authentication Policy Silos + TPM-backed long-term keys" -- not a replacement protocol. The closest thing to a replacement on the horizon is post-quantum PKINIT, which is more of a re-cipher than a re-protocol. The Kerberos message triple (AS-REQ, TGS-REQ, AP-REQ) is genuinely durable.Compared with the 28-year deprecation cycle NTLM took, replacing Kerberos would be a thirty-year project on the same precedent. Microsoft's stated direction is to harden the joints, not to throw out the skeleton. The commands below assume Server 2019 or later with the `microsoft/Kerberos-Crypto` repo cloned locally. Run on a domain controller; output names every account whose configured `msDS-SupportedEncryptionTypes` allows RC4 or has no explicit setting (in which case it inherits the pre-Phase-2 default of "anything goes"). Cross-reference with the 4768 / 4769 audit stream from `Get-KerbEncryptionUsage.ps1` to identify which of those accounts is actually being issued RC4 tickets in practice.

# Enumerate accounts and configured enctypes
Import-Module ActiveDirectory
.\List-AccountKeys.ps1 -OutputCsv accounts.csv

# Parse 4768 / 4769 events for issued ticket enctypes
.\Get-KerbEncryptionUsage.ps1 -LookbackDays 30 -OutputCsv tickets.csv

# Join the two on account name -- the accounts that
# both have RC4-allowed AND were issued RC4 tickets
# are your Phase 3 incident list.

NTLMless: The Death of NTLM in Windows

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

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

1. Eight Minutes

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

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

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

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

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

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

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

2. Origins: Why NTLM Existed at All

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. The Wire: Three Messages and One Hash

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

NEGOTIATE, CHALLENGE, AUTHENTICATE

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

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

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

The NTLMv2 response, verbatim

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

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

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

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

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

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

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

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

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

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

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

Run it

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

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

const crypto = require("crypto");

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

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

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

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

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

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

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

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

4. The Three-Decade Attack Cascade

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. The Retrofit Strategy and Its Funeral

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

Family A -- Per-protocol message authentication

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

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

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

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

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

Family C -- Credential isolation

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

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

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

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

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

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

6. The Breakthrough: Closing the Fallback

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

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

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

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

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

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

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

Local KDC -- closing "no domain at all"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. The Three-Phase Roadmap

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

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

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

Phase 1 (now) -- Audit

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

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

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

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

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

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

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

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

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

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

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

8. What Disabling NTLM Cannot Buy You

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

Disabled is not removed

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

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

Kerberos has its own relay class

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

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

Local SAM hashes remain password-equivalent

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

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

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

9. Open Problems and the 2026-2027 Edge

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

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

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

10. What an AD Engineer Should Do This Quarter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. Frequently Asked Questions

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

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

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