NTLM Relay

Also calledSMB relay, LDAP relay, Relay attack

Passes a victim's NTLM sign-in to another server and keeps the session it opens.

Needs
Incoming Sign-In
Gives
Account Access

How the Attack Works

An NTLM response proves the client knows the NT hash for one challenge, but nothing stops a machine in the middle passing it to a different server, unless that server checks the name or channel it was made for, or the session is signed. The relaying machine passes the victim's messages to a server of its choosing, hands the victim that server's own challenge, and keeps the session that opens. It never learns the hash, because the server has the DC check the response and the DC approves it as it would any other. A message integrity code over all three messages stops it removing the client's request for signing, and where signing is then in force, the session it keeps is useless.

Read first Certificate Sign-In (PKINIT), NTLM Challenge, NTLM Authenticate and Validation, LM, NTLMv1 and NTLMv2

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

ws-017 signs in to an unknown device, which passes every message to srv-fin-01 and keeps the session it opens.Step through it

ws-017 Client

  • dana's key

192.0.2.66 Unknown device

srv-fin-01 File server

  • srv-fin-01 key
  • Netlogon key
  1. Step 1 of 6, Negotiate, ws-017 to 192.0.2.66
  2. Step 2 of 6, Negotiate, Passed On, 192.0.2.66 to srv-fin-01
  3. Step 3 of 6, Server's Challenge, 192.0.2.66 to ws-017
  4. Step 4 of 6, Authenticate, ws-017 to 192.0.2.66
  5. Step 5 of 6, Answer, Passed On, 192.0.2.66 to srv-fin-01
  6. Step 6 of 6, Access as dana, srv-fin-01 to 192.0.2.66

  1. Step 1 of 6: Negotiate

    ws-017 Client to 192.0.2.66 Unknown device

    Offer to sign in with NTLM NEGOTIATE_MESSAGE SMB, port 445

    ws-017, sent to the wrong machine by a poisoned answer or a forced callback, starts NTLM with the unknown device.

    What Defenders See

    No machine in the domain records this step in its Security log. Where NTLM auditing is on, look for event 8001 or 4020 in the Microsoft-Windows-NTLM/Operational log on ws-017, naming a target no server holds.

    Hooks into NTLM negotiate

  2. Step 2 of 6: Negotiate, Passed On

    192.0.2.66 Unknown device to srv-fin-01 File server

    The same offer, passed on NEGOTIATE_MESSAGE SMB, port 445

    The device opens its own SMB session to srv-fin-01 and passes the victim's negotiate message on.

    What Defenders See

    Endpoint or network data shows an SMB session to srv-fin-01 from 192.0.2.66, an address with no DHCP lease.

    Hooks into NTLM negotiate

  3. Step 3 of 6: Server's Challenge

    192.0.2.66 Unknown device to ws-017 Client

    The real server's challenge, passed on CHALLENGE_MESSAGE SMB, port 445

    The device hands ws-017 srv-fin-01's own challenge, so the answer it gets back will be valid at srv-fin-01.

    What Defenders See

    The challenge travels in the clear, and no log on ws-017 or any other machine records it.

    Hooks into NTLM challenge

  4. Step 4 of 6: Authenticate

    ws-017 Client to 192.0.2.66 Unknown device

    Answer to the challenge AUTHENTICATE_MESSAGE SMB, port 445

    ws-017 answers with dana's name and an NTLMv2 response computed over srv-fin-01's challenge.

    What Defenders See

    No log on any machine in the domain records this step, because ws-017's answer goes to the unknown device.

    Hooks into NTLM authenticate

  5. Step 5 of 6: Answer, Passed On

    192.0.2.66 Unknown device to srv-fin-01 File server

    The answer, passed on AUTHENTICATE_MESSAGE SMB, port 445

    The device forwards dana's answer unchanged, and srv-fin-01 has dc-01 check it as it would any sign-in.

    What Defenders See

    The Security log on dc-01 shows event 4776 for dana with Source Workstation WS-017, the same as for any sign-in of hers.

    Hooks into NTLM authenticate

  6. Step 6 of 6: Access as dana

    srv-fin-01 File server to 192.0.2.66 Unknown device

    Session accepted as dana SMB2 SESSION_SETUP response SMB, port 445

    srv-fin-01 accepts the session as dana and the device keeps it. Unless signing is required, it now acts as her there.

    What Defenders See

    The Security log on srv-fin-01 shows event 4624 with Workstation Name WS-017 but Source Network Address 192.0.2.66. Where enhanced NTLM logging runs, its Microsoft-Windows-NTLM/Operational log shows event 4022 with the same mismatch.

    Hooks into NTLM access

Needs First

What the attacker must already hold for this attack to be possible.

  • An Incoming Sign-InA victim signing in to the relaying machine, after poisoning or coercion.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

  • Access as Another AccountA session on the target server as the victim, without ever learning the victim's hash.

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and LogWritten OnLook ForSwitch It On
4624 An account was successfully logged on (opens in a new tab) Security logThe computer that was logged on toWorkstation Name of the victim's machine but a Source Network Address that is not its own, with Authentication Package NTLM.Reading Logon Events explains how to read it.Audit Logon
4022 and 4023 A remote client is using NTLM to authenticate to this workstation (opens in a new tab) Microsoft-Windows-NTLM/Operational logThe server the NTLM sign-in reaches (4023 flags a weaker one, such as NTLMv1)On the server, a Client Machine whose Client IP does not match it. Channel Binding and MIC Status show what the client sent.On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The NTLM Enhanced Logging policy (System > NTLM) controls it
4776 The computer attempted to validate the credentials for an account (opens in a new tab) Security logThe computer that holds the account, a domain controller for a domain account or the computer itself for a local oneOn the DC, an ordinary success for the victim, where Source Workstation is the name the message claimed, not where it came from.NTLM Authenticate and Validation explains how to read it.Audit Credential Validation
5168 SPN check for SMB/SMB2 failed (opens in a new tab) Security logThe server that holds the shareWhere the server checks SPNs, a sign-in refused because the client meant to reach a different name.Audit File Share
2889 The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification) (opens in a new tab) Directory Service logDomain controllersClients and accounts trying unsigned LDAP binds, the kind a relay to LDAP depends on while DCs still accept them.The 16 LDAP Interface Events diagnostic setting at 2 (Basic) on each domain controller
3039 The following client performed an LDAP bind over SSL/TLS and failed the LDAP channel binding token validation (opens in a new tab) Directory Service logDomain controllersA bind over TLS that failed channel binding, a sign-in arriving over a connection it was not made on.The 16 LDAP Interface Events diagnostic setting at 2, with the LDAP channel binding policy at When Supported or Always

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4624 An account was successfully logged on

In the Security log on srv-fin-01,

dana's sign-in, relayed, with her workstation's name but another machine's address.

  • The victim the session runs as. dana did sign in, but to the unknown device, not to srv-fin-01.

    As Windows writes it: Account Name dana

  • A network logon, as an SMB session is.

    As Windows writes it: Logon Type 3

  • The name inside the NTLM message, the victim's machine, which the relaying device passed on unchanged.

    As Windows writes it: Workstation Name WS-017

  • The address that actually connected, which is not ws-017's 192.0.2.17 and has no DHCP lease. A mismatch like this is what a relay leaves.

    As Windows writes it: Source Network Address 192.0.2.66

  • NTLM, where a domain client reaching srv-fin-01 by its name would normally use Kerberos.

    As Windows writes it: Authentication Package NTLM

  • NTLMv2 alone does not stop a relay. Signing, channel binding or a name check on the server does.

    As Windows writes it: Package Name (NTLM only) NTLM V2

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

  • The victim's machine writes at most its own outgoing NTLM events, and the DC's 4776 looks like any sign-in, so the mismatch on the target is the main sign.
  • Required SMB signing makes the session useless, but the logon has already succeeded, so a 4624 can appear with no access following it.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyDeviceLogonEvents and DeviceNetworkInfo (documentation, opens in a new tab)

Needs Defender for Endpoint on the servers and the workstations. Printers and other unmanaged devices also sign in with NTLM, so a hit is an address to explain. A relayed logon names the victim's workstation in RemoteDeviceName but comes from the relaying machine's address.

KQLDefender XDR, Advanced hunting
// NTLM network logons from addresses that belong to none of your onboarded deviceslet Known = DeviceNetworkInfo    | where Timestamp > ago(30d)    | mv-expand Entry = parse_json(IPAddresses)    | project Address = tostring(Entry.IPAddress)    | distinct Address;DeviceLogonEvents| where Timestamp > ago(30d)| where ActionType == "LogonSuccess" and LogonType == "Network" and Protocol =~ "NTLM"| where isnotempty(RemoteIP) and RemoteIPType != "Loopback" and RemoteIP !in (Known)| project Timestamp, DeviceName, AccountDomain, AccountName, RemoteDeviceName, RemoteIP| order by Timestamp desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

  • Certificate Services Abuse

    Relayed to certificate web enrolment (ESC8), a forced DC sign-in becomes a certificate for the DC.

  • NTLMv1 Downgrade

    The other use of the same incoming sign-in, weakened to an NTLMv1 answer that gives up the NT hash.

Sources