LLMNR, NBT-NS and mDNS Poisoning

Also calledLLMNR poisoning, NBT-NS poisoning, Name resolution poisoning

Answers the local network's name queries so victims sign in to the wrong machine.

Needs
Local Network
Gives
Incoming Sign-InandPassword

How the Attack Works

When DNS has no answer for a name, Windows asks the local network over LLMNR, NBT-NS and mDNS, and accepts an answer from any device. The client then connects to that device as if it were the server it wanted, and signs in with NTLM using the user's own credentials. The NTLMv2 response it sends can be guessed offline, or the live exchange passed on to another server (NTLM relay).

Read first NTLM Negotiate, 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.

dana mistypes a server name on ws-017, and an unknown device on the same network answers for it.Step through it

ws-017 Client

  • dana's key

192.0.2.66 Unknown device

  1. Step 1 of 5, Name Query, on ws-017
  2. Step 2 of 5, Poisoned Answer, 192.0.2.66 to ws-017
  3. Step 3 of 5, Negotiate, ws-017 to 192.0.2.66
  4. Step 4 of 5, Challenge, 192.0.2.66 to ws-017
  5. Step 5 of 5, Authenticate, ws-017 to 192.0.2.66

  1. Step 1 of 5: Name Query

    On ws-017 Client

    DNS has no record for the mistyped name, so ws-017 asks every device on its segment, over LLMNR, NBT-NS and mDNS.

    What Defenders See

    Network sensors see the multicast and broadcast queries from ws-017. Windows writes no event for them to the Security log on ws-017 or any other machine.

  2. Step 2 of 5: Poisoned Answer

    192.0.2.66 Unknown device to ws-017 Client

    Fake answer to a name query LLMNR response LLMNR, UDP port 5355

    The unknown device answers that the name is its own address, 192.0.2.66, and ws-017 accepts it.

    What Defenders See

    Network data shows an answer to ws-017's name query from 192.0.2.66, a device that should never answer one.

  3. Step 3 of 5: Negotiate

    ws-017 Client to 192.0.2.66 Unknown device

    Offer to sign in with NTLM NEGOTIATE_MESSAGE SMB, port 445

    ws-017 connects to 192.0.2.66 over SMB as if it were the real server, and starts an NTLM sign-in.

    What Defenders See

    Endpoint network data from ws-017 shows an SMB connection to 192.0.2.66, an address with no DHCP lease.

    Hooks into NTLM negotiate

  4. Step 4 of 5: Challenge

    192.0.2.66 Unknown device to ws-017 Client

    The fake server's challenge CHALLENGE_MESSAGE SMB, port 445

    The unknown device sends a challenge of its own, as any server would.

    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

  5. Step 5 of 5: 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 from her NT hash and that challenge.

    What Defenders See

    No machine in the domain writes a logon event to 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 authenticate

Needs First

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

  • A Place on the Local NetworkA device on the same network segment as its victims, where their name queries are heard.

Gives the Attacker

What running it hands the attacker to use next.

  • An Incoming Sign-InVictims' NTLM sign-ins arriving live, to be passed on (relay) or weakened (downgrade).
  • A PasswordA password, where a captured NTLMv2 response is guessed offline.

Leads To

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
8001 NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked (opens in a new tab) Microsoft-Windows-NTLM/Operational logThe client that sends the NTLM sign-inOn the client, an outgoing NTLM sign-in whose Target server is a name no server holds.Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, set to Audit all
4020 and 4021 This machine attempted to authenticate to a remote resource via NTLM (opens in a new tab) Microsoft-Windows-NTLM/Operational logThe client that sends the NTLM sign-in (4021 flags a weaker one, such as NTLMv1)On the client, an NTLM sign-in whose Target Machine is a name no server holds. This logging is on by default in Windows 11 24H2.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
4769 A Kerberos service ticket was requested (opens in a new tab) Security logDomain controllersA failure with Failure Code 0x7 for a service name no account holds, which means a client looked for a server that does not exist.TGS Reply: The Service Ticket explains how to read it.Audit Kerberos Service Ticket Operations

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.

8001 NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked

In the Microsoft-Windows-NTLM/Operational log on ws-017,

ws-017 signs in with NTLM to a name no server holds.

  • The service and name ws-017 meant to reach. No server is called fileserv, so the name was mistyped, and something answered for it.

    As Windows writes it: Target server cifs/fileserv

  • No credentials were typed. Windows sent dana's own sign-in, as it does for a share.

    As Windows writes it: Supplied user (NULL)

  • The System process, where the SMB client runs, so a share was opened, not a program signing in on its own.

    As Windows writes it: PID of client process 4

  • Whose NTLMv2 response went to the device. It was dana's, computed from her NT hash.

    As Windows writes it: User identity of client process dana

Blind Spots

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

  • No domain host logs the poisoned answer or the captured response. Only network sensors and the victim's own NTLM audit events see it.
  • A strong password defeats offline guessing of a captured response, but not a live relay of the same exchange.

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 Related ActivityDeviceNetworkEvents (documentation, opens in a new tab)

Needs Defender for Endpoint on the workstations, with KnownServers and the workstation name pattern set to your own. It sees the connection after a poisoned answer, not the answer, and most hits are servers missing from the list, so an address no DHCP lease explains is the lead.

KQLDefender XDR, Advanced hunting
// SMB and web connections from workstations to internal addresses that are not known serverslet KnownServers = dynamic(["192.0.2.10", "192.0.2.11", "192.0.2.15", "192.0.2.20", "192.0.2.25"]);DeviceNetworkEvents| where Timestamp > ago(30d)| where DeviceName startswith "ws-"| where ActionType == "ConnectionSuccess" and RemotePort in (445, 80)| where RemoteIPType !in ("Public", "Loopback") and RemoteIP !in (KnownServers)| summarize Connections = count(), Devices = dcount(DeviceName), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by RemoteIP, RemotePort| order by Devices 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.

Sources