Detecting NTLM Relay Attacks

NTLM relay remains the most reliable path from a foothold to Domain Admin, and 2025 proved it: CVE-2025-24054, an NTLM hash-disclosure flaw, was exploited in the wild within eight days of its March 2025 patch and added to CISA’s KEV catalog. Detecting it means watching two things: the coercion that forces a machine to authenticate, and the relay landing at a domain controller or AD CS. This guide ships the detection and the layered signing controls that actually close the relay surface.

NTLM relay maps to MITRE ATT&CK T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay, usually reached via T1187 — Forced Authentication. It builds on the credential-harvesting theme of LSASS dumping and the AD focus of Kerberoasting.

What is an NTLM relay attack?

In an NTLM relay, the attacker does not crack a password — they pass the authentication along. They coerce a victim machine into authenticating to a host they control, then relay that authentication to a different service (LDAP on a domain controller, HTTP on AD CS web enrollment) to act as the victim. Because NTLM lacks the channel binding that would tie the auth to its destination, the relayed handshake is accepted.

The relay is only as good as the coercion that feeds it. Primitives like PetitPotam (MS-EFSRPC), PrinterBug (Print Spooler), DFSCoerce, and ShadowCoerce force a machine — often a domain controller — to authenticate on demand, most needing no authentication on default server configs. That combination is why relay is a top red-team path year after year.

What does the NTLM relay kill chain look like?

The throughline: relay is noisy if you collect the right events, and invisible if you don’t — most SOCs simply aren’t logging AD CS certificate requests.

How to detect NTLM relay attacks

The relay lands as an NTLM network logon to a domain controller or AD CS from a source that should not be initiating it. Collect the AD CS audit events and DC logons, then alert on the anomaly.

title: NTLM Network Logon to AD CS or Domain Controller
id: 7c3e9a14-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'NTLM'
  scope:
    TargetServerName|contains: ['CERTSRV','LDAP','ADCS']
  filter_machine_self:
    SubjectUserName|endswith: '$'
  condition: selection and scope and filter_machine_self
falsepositives:
  - Legacy apps using NTLM to these services (inventory and allowlist them)
level: high

The coercion-to-relay chain in SPL and KQL

index=windows (EventCode=4624 Logon_Type=3 Authentication_Package=NTLM)
             OR EventCode IN (4886, 4887) OR (EventCode=5145 Relative_Target_Name IN ("efsrpc","lsarpc","spoolss","netdfs"))
| bin _time span=10m
| stats values(EventCode) AS events, values(Account_Name) AS accounts,
        values(Relative_Target_Name) AS pipes, dc(ComputerName) AS hosts,
        min(_time) AS first by _time, src_ip
| eval coercion  = if(mvcount(mvfilter(match(events,"^5145$"))) > 0, 1, 0)
| eval ntlm_logon= if(mvcount(mvfilter(match(events,"^4624$"))) > 0, 1, 0)
| eval cert_req  = if(mvcount(mvfilter(match(events,"^(4886|4887)$"))) > 0, 1, 0)
| where (coercion=1 AND ntlm_logon=1) OR (ntlm_logon=1 AND cert_req=1)
| eval severity = if(cert_req=1, "critical", "high")
| table first, src_ip, accounts, pipes, events, severity, hosts

SecurityEvent
| where EventID in (4886, 4887)
| extend Requester = tostring(Requester), Template = tostring(CertificateTemplate)
| where Requester endswith "$"          // machine accounts rarely enroll interactively
| join kind=leftouter (
    SecurityEvent
    | where EventID == 4624 and LogonType == 3
          and AuthenticationPackageName == "NTLM"
    | project NtlmTime = TimeGenerated, Account = TargetUserName, SrcIp = IpAddress
) on $left.Requester == $right.Account
| where isnotempty(NtlmTime) and NtlmTime between (ago(10m) .. now())
| project TimeGenerated, Requester, Template, SrcIp, NtlmTime
| order by TimeGenerated desc

The second query encodes the highest-fidelity single signal in this attack class: a machine account requesting a certificate. Computers rarely enroll for certificates interactively, and when one does so moments after an NTLM network logon, you are watching the coercion-to-ESC8 chain in progress rather than inferring it.

What telemetry do you need to detect NTLM relay?

Enable AD CS auditing first. Events 4886 and 4887 are off by default on most certificate authorities, and without them the ESC8 relay — the step that converts a coerced authentication into a domain-admin-capable certificate — leaves no trace at all. It is a policy change measured in minutes and it is the difference between detecting this chain and not.

Event ID 8004 deserves a mention as a planning tool rather than a detection. Enabling NTLM auditing tells you exactly which applications and hosts still depend on NTLM, which is the inventory you need before you can safely tighten signing requirements.

Which false positives will you actually see?

The auto-enrollment row is the one to handle by correlation rather than suppression. Machine certificate renewal is scheduled and predictable; a machine-account certificate request that does not match the renewal window is exactly the ESC8 signal, and blanket-suppressing machine enrollments deletes it.

How do you triage an NTLM relay alert?

1. Check whether a certificate was issued. Event 4887 means the attacker holds a credential that survives password resets — that changes everything about the response.
2. Identify which identity was relayed. A relayed domain controller machine account is a domain-compromise-level event; a workstation account is serious but bounded.
3. Revoke any certificate issued to a relayed identity, and confirm revocation is actually being checked. An unrevoked certificate is durable access.
4. Find the coercion source. The host that received the coerced authentication is the attacker’s position; the named-pipe events tell you which primitive was used.
5. Check what the relayed identity did next — LDAP writes, especially changes to msDS-AllowedToActOnBehalfOfOtherIdentity (delegation), which is a common follow-on.
6. Reset the machine account password twice where a machine account was relayed, to clear the password history that certificate-based persistence can otherwise exploit.
7. Verify signing and EPA configuration on the targeted services — the alert has just told you a relay path is open.
8. Hunt for other coerced hosts. Coercion is cheap and usually attempted broadly.

Step 1 is what determines whether this is an incident or a near miss. The whole point of the ESC8 chain is that it converts a transient relayed authentication into a certificate — a long-lived credential that a password reset does not invalidate.

How to test your NTLM relay detection

In an isolated AD lab you own:

1. Trigger a coercion primitive (e.g. a lab PetitPotam) against a test host and confirm the RPC/coercion signal appears.
2. Relay to a test AD CS and confirm Events 4886/4887 fire and your rule correlates.
3. Confirm SMB signing on the target blocks the SMB relay path.
4. Confirm LDAP signing + channel binding blocks the LDAP relay path.

How to defend against NTLM relay

• Disable LLMNR and NBT-NS to remove passive coercion/poisoning paths.
• Patch NTLM CVEs immediately (CVE-2025-24054, CVE-2025-33073) — KEV-listed and fast to weaponize.
• Move off NTLM toward Kerberos and phishing-resistant auth where applications allow.

Which control closes which relay path?

The reason partial deployment fails is that each control closes exactly one protocol. An attacker relays over whichever one you left open.

Start with the top two rows. AD CS auditing costs minutes and turns an invisible attack chain into a detectable one; EPA on web enrollment closes the highest-value relay target. If nobody is actually using AD CS web enrollment — and in many estates nobody is — disabling it outright is the cleanest fix available, because a feature that does not exist cannot be relayed to.

Roll the signing controls out in audit mode first. Each one logs what would have been rejected, which gives you the inventory of legacy clients to fix before enforcement turns a security improvement into an outage.

Common NTLM relay detection mistakes

• No AD CS audit logging. ESC8 relay is invisible without Events 4886/4887.
• Partial signing. SMB signing alone leaves the LDAP path open.
• Ignoring coercion RPC. The relay starts with a forced authentication.
• Treating NTLM as legacy. NTLMv2 relay works on current default configs.
• Suppressing machine-account certificate requests. That exclusion deletes the ESC8 signal; correlate against the renewal schedule instead.
• Resetting a relayed machine account only once. Password history can still be leveraged; reset twice.
• Forgetting certificate revocation. A certificate issued to a relayed identity survives every password reset you perform.
• Enforcing signing without an audit pass. You discover the legacy inventory as an outage.

NTLM relay detection checklist

1. Enable AD CS audit Events 4886 and 4887 on every certificate authority.
2. Alert on NTLM network logons (4624 type 3) to DCs/AD CS from unexpected sources.
3. Alert on coercion RPC (MS-EFSRPC, MS-RPRN) to non-DC hosts.
4. Enforce SMB signing on all machines.
5. Enforce LDAP signing and LDAP channel binding (EPA) on DCs.
6. Enable EPA on AD CS web enrollment.
7. Disable LLMNR/NBT-NS; patch NTLM CVEs (CVE-2025-24054, CVE-2025-33073).
8. Test coercion, relay, and each signing control in an AD lab.

Why does this attack survive so long in real environments?

NTLM relay has been well understood for over a decade and remains reliably effective, which is worth explaining because it tells you where to spend effort.

The protocol is doing what it was designed to do. There is no memory-corruption bug to patch. NTLM authenticates a user to a server without binding that authentication to the specific service being contacted, so an attacker who sits in the middle can present it somewhere else entirely. Patching cannot fix a design property; only configuration can.

Coerced authentication is abundant. The attacker does not need to wait for a victim to connect — a range of ordinary Windows features can be induced to authenticate outbound on demand. Each new coercion method revives the technique against environments that considered it handled.

The mitigations are individually incomplete. Signing prevents relay to the signed protocol; channel binding covers another path; disabling NTLM entirely is the real fix and is frequently blocked by one legacy application that nobody will let you retire. Partial mitigation leaves a partial attack surface, and attackers enumerate exactly the unsigned remainder.

The practical conclusion is uncomfortable and worth stating plainly: most environments cannot fully eliminate this, so detection is not a fallback here — it is a primary control. Budget for it accordingly rather than treating it as a gap that hardening will eventually close.

What does the successful case look like versus the noisy one?

The detection challenge is that the individual events are common. Machine accounts authenticate constantly, and an authentication arriving from an unexpected host is frequently a misconfiguration rather than an attack.

The signal that separates them is the mismatch between where an identity should be and where it just authenticated from, combined with the timing. Specifically:

• A computer account authenticating from an address that is not its own is the single strongest indicator, because a machine account has exactly one legitimate home.
• Authentication arriving within seconds of a coercion-capable request to that same host ties the two halves of the attack together, and neither half alone is convincing.
• A privileged account authenticating to a service it has never touched, from a host it has never used — the same first-time-seen logic that works for lateral movement.

The triage question that resolves most alerts quickly: could this identity plausibly be at this source address? For a user account the answer is often yes, and the alert needs more context. For a machine account it is almost always no, and that is why the machine-account variant is where to start building — highest signal, lowest tuning burden, and it catches the most damaging version of the attack.

What can you disable this quarter?

Full NTLM removal is a multi-year programme in most environments, which is why it never starts. A more useful framing is to ask what can be narrowed now, because each step removes a concrete relay path rather than waiting for a total fix.

Ordered by ratio of protection to disruption:

Require signing on the protocols that support it. This closes relay to those services outright. It is a configuration change, it is measurable, and the compatibility risk is confined to genuinely ancient clients you can enumerate in advance.

Turn off the coercion surfaces you do not use. Several Windows features exist purely to make one machine authenticate to another; where a service is not needed, disabling it removes the attacker’s ability to trigger authentication on demand — which is the half of the attack that does not depend on your protocol choices at all.

Restrict which accounts can authenticate where. A relayed credential is only useful against services that identity can reach. Tiering administrative accounts so that a workstation credential cannot authenticate to a domain controller collapses the value of a successful relay even when the relay itself succeeds.

Inventory what actually still needs NTLM. This is the step that unblocks everything else, and it is almost always smaller than assumed. Audit-mode logging will name the holdouts within a week, and the list is usually a handful of appliances rather than the sprawling dependency everyone fears.

The point of sequencing it this way: each item is independently valuable and independently shippable. An organisation that does the first two has meaningfully reduced its exposure without finishing the programme — which is a far better outcome than a full migration that stays permanently at the planning stage.

One measurement worth taking before any of this: count how much NTLM you are actually doing. Audit-mode logging answers it within a week, and the number is almost always lower than the organisation assumes. Teams that skip this step plan a multi-year migration around a dependency that turns out to be three appliances and a scheduled task — and teams that take it frequently discover the programme is a quarter’s work, not a decade’s.

Run it before you scope the work, not after — the audit is a week and the plan it produces is an order of magnitude more accurate than the one built on assumptions.

One more reason to measure first: the audit output doubles as your detection baseline. The same logs that tell you which systems still negotiate NTLM tell you what normal looks like, which is the prerequisite for every rule above.

The takeaway

Detecting NTLM relay means watching the coercion and the relay landing — anomalous NTLM logons and AD CS Events 4886/4887 — while closing the surface with SMB signing, LDAP signing, and EPA together. Patch the NTLM CVEs fast; they weaponize in days. Continue with LSASS credential dumping detection, Kerberoasting and the relay-to-CA chain in detecting AD CS abuse (ESC1–ESC8), or browse the full Detection Engineering pillar.