Ariovis

Active Directory attack path · NTLM · Relay · MITRE ATT&CK T1557.001

NTLM Relay: When Legitimate Authentication Is Used Against the Wrong Service

NTLM relies on a challenge-response exchange: the password itself is never sent to the remote service, which only verifies a response computed from the identity's secret. That property protects the secret, but it does not prevent relay attacks.

If an attacker manages to sit in the path of an authentication, or to trigger that authentication, some configurations allow the exchange to be passed on to another service without ever knowing the victim's password. The receiving service then authenticates an identity that never intended to connect to it.

The risk therefore does not come from NTLM alone. It comes from the combination of an exploitable authentication source, a target insufficiently protected against relay, and the real privileges of the relayed identity.

The real question

Which identities can be made to authenticate, towards which destinations, and which services still accept that authentication without checking the context in which it was produced?

Understand Active Directory attack paths
MITRE ATT&CK
T1557.001 — Name Resolution Poisoning and SMB Relay
Parent technique
T1557 — Adversary-in-the-Middle
Protocol
NTLM, deprecated yet still supported in Windows
Triggers analysed
Legacy name resolution and authentication coercion
Targets analysed
SMB, LDAP, LDAPS, AD CS HTTP enrollment endpoints
Related protections
SMB signing, LDAP signing, channel binding, EPA
Windows signals
4776, 4624, 2886-2889, 3039-3041, 4886, 4887
Level
Tier 0 where the relayed identity allows it

Stealing an NTLM response and relaying an authentication are two different scenarios

NTLM authenticates an identity without sending its secret to the remote service: the server issues a challenge, the client computes a response from its secret, and that response is validated by the server or by a domain controller. The exchange is a proof of possession, valid for that session and that service.

Two very different scenarios can start from that exchange, and confusing them leads to wrong analysis, misdirected remediation and unsuitable detection. The first goes after the secret; the second uses an authentication while it is happening.

How the exchange works

  1. 01The client wants to authenticate to a service.
  2. 02The service issues a challenge.
  3. 03The client computes a response from its secret.
  4. 04The service, or a domain controller, validates that response.

  • Scenario A — Capture

    The attacker collects NTLM authentication material that may later be attacked offline, with success depending entirely on how strong the secret is and how much time is available. This scenario targets the identity's secret, not the live session.

  • Scenario B — Relay

    The attacker does not necessarily try to recover the secret: the authentication exchange is passed on in real time to another service, which accepts it and then treats subsequent actions as coming from the relayed identity. The secret stays unknown, yet the identity is used.

Relay is neither capture followed by offline cracking nor Pass-the-Hash, which already assumes possession of a password hash. In a relay, the attacker only needs an authentication in progress and a target that accepts it.

The attack path, step by step

Every arrow depends on the real configuration: an authentication trigger only creates a path if some target accepts the relay, and the final impact stays bounded by what the relayed identity can actually do.

  1. 01

    Legitimate identity or machine

  2. 02

    NTLM authentication triggered or diverted

    • Legacy name resolution
    • Authentication coercion
  3. 03

    Attacker in a relay position

  4. 04

    NTLM exchange passed to another target

    • SMB
    • LDAP or LDAPS
    • HTTP enrollment endpoint
  5. 05

    The target accepts the authentication without sufficient relay protection

  6. 06

    The attacker acts with the rights of the relayed identity

  7. 07

    A further step becomes possible in the attack path

Nothing about this sequence is automatic: successful coercion with no exploitable target leads nowhere, and a weakly protected target is only reachable if an exploitable authentication can be presented to it.

NTLM Relay grants no extra privilege by magic. It lets an attacker use elsewhere the privileges the relayed identity already holds.

The first problem is making the victim speak

A relay requires an authentication to relay. Two very different families of mechanisms can produce one, and they are not fixed the same way: one concerns name resolution on the network, the other concerns Windows interfaces able to trigger an outbound connection.

  • Legacy name resolution

    When a workstation fails to resolve a resource through normal mechanisms, some local resolution protocols may lead it to contact a machine other than the expected one, including a machine controlled by an attacker, which then receives an authentication attempt.

    • LLMNR;
    • NBT-NS;
    • mDNS where the network context makes it relevant.

    These mechanisms are not vulnerabilities in themselves: they become a problem when they stay enabled without a real need, on segments where an unmanaged machine can answer.

  • Authentication coercion

    Some Windows interfaces have historically allowed a machine to be pushed into initiating an authentication towards a system chosen by the caller. The most documented cases involve interfaces related to file encryption and to the print spooler service, commonly referenced under the research names PetitPotam and PrinterBug.

    • MS-EFSRPC — PetitPotam;
    • MS-RPRN — PrinterBug.

    Coercion is not yet compromise: it provides an authentication that still has to be relayed to an exploitable target, using an identity whose privileges make the operation worthwhile.

Addressing only the trigger therefore closes one door among several. An organisation that blocks one specific coercion interface, while leaving its critical services able to accept a relayed authentication, keeps the whole class of paths in its environment.

There is no universal protection called “NTLM Relay”

Relay protections are specific to each protocol: they bind the authentication to the session in which it was produced, or require a signature the attacker cannot produce. Assessing an environment therefore means checking, service by service, what is actually required.

  • SMB

    SMB signing

    An SMB service that does not properly require signing can be a relay target depending on context, especially where legacy servers keep settings more permissive than recent defaults.

  • LDAP

    LDAP signing

    Insufficiently protected binds can enable certain relay scenarios towards the directory, with an impact that depends on the relayed identity's permissions over the targeted objects.

  • LDAPS

    LDAP channel binding

    TLS encryption alone does not protect against every relay scenario: channel binding ties the authentication to the TLS session in which it is presented, which breaks reuse of the exchange elsewhere.

  • HTTP / IIS / AD CS

    Extended Protection for Authentication and HTTPS

    AD CS enrollment endpoints accepting NTLM without EPA are the documented ESC8 scenario, with a specific consequence: the target does not merely grant access, it can issue a credential.

The problem is not only that NTLM exists. The problem is that a service accepts a relayed authentication without sufficiently verifying the context in which it was created.

SMB Relay: the identity's rights determine the impact

When an NTLM authentication can be relayed to an SMB server that does not block the scenario, the attacker acts with the rights granted to the relayed identity on that specific target. There is no generic power over the domain, only the exact scope of that identity on that server.

If the relayed identity holds local administrative privileges on the targeted machine, the impact can extend to remote administration operations and open a further step in the attack path. If it only holds limited rights, the same technique produces a result matching those rights.

This is why mapping accounts with broad local administrative privileges across many machines matters as much, in the analysis, as the protocol configuration itself: it determines what a successful relay makes possible.

An SMB relay can enable privileged actions where the relayed identity itself holds those privileges on the reached target.

LDAP turns a relay into a change in the rights graph

Active Directory does not only authenticate. LDAP also allows objects, attributes and authorisation relationships to be read and modified where the identity in use holds the necessary permissions on the objects involved.

In some scenarios, an NTLM relay towards LDAP or LDAPS can therefore be used to change the rights graph rather than to perform an immediately visible action: the consequence is not a one-off access but a persistent relationship written into the directory. Delegations are the clearest example of that category, in particular Resource-Based Constrained Delegation.

Depending on the relayed identity and the ACLs present in the directory, a path may allow the creation or modification of a delegation relationship such as RBCD. That possibility is not an automatic consequence of relaying to LDAP: it depends entirely on the effective permissions of the identity used over the targeted object.

A relay towards the directory should be analysed with the same lens as a delegation: the protocol grants no power, the ACLs the relayed identity already holds over the objects do.

ESC8: when the PKI accepts the relayed identity

Active Directory Certificate Services can expose enrollment services through IIS, notably Certificate Authority Web Enrollment and the Certificate Enrollment Web Service. These interfaces serve legitimate enrollment needs, yet they are reachable over HTTP and accept Windows authentication.

If those endpoints accept NTLM without suitable relay protections, notably HTTPS and Extended Protection for Authentication, Microsoft considers them exposed to the ESC8 scenario. This target differs from all the others: it does not grant an access, it can issue a credential usable independently afterwards.

The documented sequence

  1. 01Domain controller or another machine
  2. 02Coerced NTLM authentication
  3. 03Relay to the AD CS endpoint
  4. 04AD CS authenticates the relayed principal
  5. 05A certificate is issued for that principal, according to available rights and templates
  6. 06The certificate becomes a usable credential for that identity

Where the relayed principal is a domain controller

  1. 01Certificate for the domain controller's machine account
  2. 02Authentication with that account's identity
  3. 03Critical capabilities attached to that account
  4. 04Depending on the path: access to domain secrets, for example through DCSync
  5. 05Tier 0
DCSync: abusing replication rights
The certificate obtained represents the principal actually relayed, for example a domain controller's machine account. Later compromise of domain secrets is a possible step, conditioned by that account's capabilities, not an automatic consequence of issuance.

ESC1 and ESC8 attack the same PKI through two different paths

Both scenarios concern Active Directory Certificate Services, but they do not target the same object or the same weakness, and they are therefore not fixed by the same measures.

Presenting the two scenarios as one vulnerability leads to fixing the wrong object: hardening templates does not protect an exposed endpoint, and protecting an endpoint does not correct an over-permissive template.

Relay must be assessed against a real Windows estate, not a 2020 lab

NTLM is now deprecated by Microsoft, yet it remains supported in Windows for compatibility reasons, and Kerberos remains the preferred authentication mechanism inside an Active Directory domain. Deprecation therefore means neither absence of the protocol nor absence of a path.

Recent Windows versions have also hardened their defaults, which changes the exposure of a modern estate compared with analyses published a few years ago. That hardening applies to new installations and default configurations, not to the effective state of an information system built up layer by layer.

What changed and what still has to be verified

  • Windows 11 24H2 significantly strengthened SMB signing requirements;
  • Windows Server 2025 further hardens SMB and introduces new NTLM blocking mechanisms for SMB;
  • new Active Directory deployments on Windows Server 2025 require LDAP signing by default;
  • legacy environments, systems not upgraded, exceptions and third-party products still have to be analysed one by one.

The operating system version therefore does not prove that a path is closed: a recent estate can still carry documented exceptions, older servers or third-party applications that restore the conditions for relay. Only an audit of the effective configuration, on clients as well as servers, can settle the question.

Detecting NTLM Relay means correlating several layers

No single event characterises a relay: each signal, taken alone, describes an operation that may be perfectly normal. Detection therefore means rebuilding a coherent sequence across protocol usage, the authentication observed on the target, network behaviour and the specific service involved.

  1. Level 1

    Observe NTLM usage

    The credential validation event on the domain controller documents NTLM authentications and shows which accounts still use the protocol, from which machines and how often. It forms the basis of the inventory, not an alert.

    • which account uses NTLM;
    • from which machines;
    • how often and in which time windows.
    Event ID 4776
    The domain controller attempted to validate the credentials for an account. This event does not mean “NTLM Relay”.
  2. Level 2

    Observe authentication on the target

    On the targeted system, the logon event documents the logon type, the authentication package, the network source and the identity. A successful network NTLM logon can be entirely normal: value comes from correlating it with an unexpected source, target and behaviour.

    • Logon Type;
    • Authentication Package and NtLmSsp;
    • source address;
    • authenticated identity.
    Event ID 4624
    An account was successfully logged on to the targeted system.
  3. Level 3

    Observe coercion and the network

    The network layer carries signals that authentication logs do not, following the detection logic associated with the matching MITRE technique: abnormal responses to legacy resolution mechanisms, traffic from an unauthorised host, unusual SMB authentications between systems with no reason to talk to each other, changes re-enabling certain resolution mechanisms, and service creation following a compromise.

  4. Level 4

    Observe the specific target

    Each targeted service brings its own telemetry. On the directory side, diagnostic events identify clients that do not meet signing or channel binding requirements. On the PKI side, Certification Services events allow a certificate request to be matched with the network context in which it was presented, using IIS logs as well.

    • LDAP: clients not honouring signing, events 2886 to 2889;
    • LDAP channel binding: events 3039 to 3041 where available;
    • AD CS: correlation with IIS logs and the request context.
    Event ID 4886
    Certificate Services received a certificate request.
    Event ID 4887
    Certificate Services approved a request and issued a certificate.
A certificate request, an NTLM authentication or an SMB connection are not, on their own, proof of a relay. Detection has to rebuild the sequence: who authenticated, to what, from where, and what happened next.

The right strategy removes several links at once

A relay path is made of a trigger, a target and an identity. Every link removed reduces the corresponding class of paths, and the progressive approach below avoids the trap of an abrupt shutdown that would break business usage still depending on the protocol.

  1. 01 — Map NTLM

    Before any global disablement, inventory the systems still using NTLM, identify legacy dependencies, separate business usage, technical usage and historical exceptions, then prepare a migration towards Kerberos or more modern mechanisms.

  2. 02 — Reduce NTLM

    Prefer Kerberos and restrict NTLM once dependencies are known. On the most privileged systems, domain controllers in particular, prioritise outbound NTLM authentication capability, which directly feeds coercion scenarios.

    Blind disablement across the whole estate, with no audit phase and no handling of exceptions, causes service breakage without guaranteeing that the paths are closed.

  3. 03 — SMB

    Require SMB signing wherever the configuration does not already do so, verifying the real configuration of clients as well as servers, then take advantage of recent NTLM blocking mechanisms for SMB where the context allows.

  4. 04 — LDAP

    Require LDAP signing after identifying incompatible clients, and address channel binding for LDAPS and the authentications concerned, using audit modes before enforcement where the estate requires it.

  5. 05 — AD CS and IIS

    For AD CS enrollment services, enforce HTTPS, enable Extended Protection for Authentication with the Required mode where compatible, and reduce or remove NTLM on those endpoints where possible.

    HTTPS alone does not address ESC8: it is the combination of encryption and Extended Protection for Authentication that binds the authentication to the session presented.

  6. 06 — Name resolution and coercion

    Reduce legacy resolution mechanisms that are no longer needed and monitor outbound authentication from critical systems, without relying solely on blocking one specific coercion tool.

Blocking a known coercion interface only addresses a trigger. Preventing a Tier 0 identity from emitting exploitable NTLM authentication, and preventing critical services from accepting a relayed authentication, breaks an entire class of paths regardless of the tooling used.

The vulnerability is not NTLM alone: it is the chain that remains exploitable

A configuration inventory may show that NTLM is still active, that SMB signing is not enforced everywhere, that LDAP signing remains incomplete, that an AD CS endpoint runs without EPA and that a domain controller can initiate authentication towards an insufficiently controlled perimeter. Taken individually, those observations produce a list of findings handled according to team availability.

Linked together, the same observations describe a practicable path towards Tier 0, and the order of fixes stops being arbitrary: some measures close one configuration point, others remove a link shared by many paths. That difference in effect is what the analysis must make visible.

The question the assessment must answer

In this environment, can an authentication obtained under coercion still be presented to a service that accepts it, and how far does it lead?

The assessment therefore looks for

  • which identities can be forced to authenticate;
  • towards which destinations those authentications can travel;
  • which services still accept a relayed authentication;
  • which protections are effectively applied, on clients and on servers;
  • what the relayed identity can genuinely do once authenticated;
  • which fixes break the largest number of paths.
Assess my Active Directory securityExplore the Identity and Active Directory Security service

Related techniques

The other pages in this collection. They are not mandatory successive steps: each fits into an attack path according to what the environment allows.

Technical sources

First-tier references used to support this page.

Continue the analysis

The pages that extend this one, from the attack path to the assessment approach.