LLMNR poisoning to SMB relay: a login with no password cracked

The question nobody should have asked

A Windows host resolves a name in a fixed order. It checks its hosts file and cache, then it asks DNS. When DNS answers, that is the end of it. When DNS returns nothing, older defaults do not stop there: the host shouts the name onto the local segment and asks whoever is listening. Two protocols carry that shout. Link-Local Multicast Name Resolution, LLMNR, uses UDP 5355. NetBIOS Name Service, NBT-NS, uses UDP 137. Neither one authenticates the reply.

That last sentence is the whole problem. When a machine broadcasts "who is fileserver01", it trusts the first host that says "I am". Nothing binds the answer to the real owner of the name, so an attacker on the segment can claim to be any host that DNS failed to resolve. The weakness is an authentication decision made on a spoofable signal, which is the shape of CWE-290, authentication bypass by spoofing. What makes it worth an attacker's time is that the failed lookups are constant: a mistyped share, a decommissioned server still in a login script, a Web Proxy Auto-Discovery request for wpad. The names arrive on their own.

For a tester standing on the internal network with no credentials, this is often the opening move, and it is exactly the position an internal infrastructure test is scoped to occupy. No phishing, no exploit against a service, no password guessed. Just a listener that answers a question the network should never have broadcast in the first place.

Answering as the target

The listener is Responder. Started on the network interface, it watches for LLMNR, NBT-NS and multicast DNS queries and answers each one by claiming the queried name resolves to the attacker's address. The client, having asked the segment and received an answer, now connects to the attacker believing it has found the file server. Over SMB it offers to authenticate, and the NetNTLMv2 exchange runs: the attacker sends a challenge, the client returns a response computed from the user's password hash. The attacker never sees the password and never sees the hash, only a response bound to a challenge it chose. This is MITRE ATT&CK T1557.001, LLMNR and NBT-NS poisoning and relay.

A capture looks like this. The username and domain are in clear, and the long trailing value is the NetNTLMv2 response, salted by the server challenge and the client's own nonce.

The response is a keyed hash, not a reusable secret. It cannot be replayed as-is against another service, which is the point of CWE-294, capture-replay, and it is why the attacker now has a decision to make rather than a finished attack.

$ sudo responder -I eth0 -wv
[+] Listening for events...

[*] [LLMNR]  Poisoned answer sent to 10.10.14.52 for name fileserver01
[SMB] NTLMv2-SSP Client   : 10.10.14.52
[SMB] NTLMv2-SSP Username : CORP\j.reed
[SMB] NTLMv2-SSP Hash     : j.reed::CORP:1122334455667788:A1B2C3...:0101000000000000...

Crack it, or do not

The first option is offline cracking. The NetNTLMv2 response is a hash format hashcat understands as mode 5600, so the attacker feeds it a wordlist and waits. If the password is weak or reused, it falls, and the reward is the plaintext, which works everywhere that account is valid. This is the same offline economics that makes a Kerberoast worth cracking: the attacker is off the network, unthrottled, limited only by the password and the hardware. A strong passphrase survives it.

The second option needs no password at all. Instead of taking the captured response home to crack, the attacker forwards it, live, to a different host as proof of identity. The client authenticated to the attacker; the attacker re-presents that same authentication to a third machine before the exchange expires. Whether that works has nothing to do with password strength. It depends entirely on whether the destination host insists that its SMB messages be signed.

The two paths answer different questions, and a tester usually tries both.

$ hashcat -m 5600 hashes.txt rockyou.txt
J.REED::CORP:1122334455667788:a1b2...:Autumn2025!

Status...........: Cracked
Hash.Mode........: 5600 (NetNTLMv2)

The relay lands where signing is off

SMB signing puts a cryptographic signature on each message, keyed to the session. A relayed authentication produces a session the attacker cannot sign for, because it never held the material the signature is derived from, so a host that requires signing rejects the relayed connection. A host that does not require it accepts the session and does whatever that account is entitled to do. On a default member server, signing is enabled but not required, which is the setting a relay is looking for. It is worth checking a target before pointing a relay at it.

The relay itself is ntlmrelayx from the Impacket suite. Responder is turned to capture-and-forward rather than answer-and-log, and ntlmrelayx takes the incoming authentication and drives it at a list of targets. Against a host without required signing and an account that is a local administrator there, the default action dumps the local SAM. Reusing NTLM material to authenticate to another system this way is MITRE ATT&CK T1550.002, pass the hash, though here the hash is never even cracked to a password first.

From a SAM dump the operator has local administrator hashes, and the chain keeps going: those hashes open other machines that share the password, and a foothold like this is the assumed starting point for a deeper assumed breach exercise. Where a certificate service is in reach, the same relayed authentication can be pointed at it rather than at a file share, which is the road into AD CS ESC1 and a domain admin certificate.

$ nmap --script smb2-security-mode -p445 10.10.14.60

445/tcp open  microsoft-ds
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required

$ ntlmrelayx.py -tf targets.txt -smb2support
[*] Servers started, waiting for connections
[*] Authenticating against smb://10.10.14.60 as CORP/J.REED SUCCEED
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c0ffee...:::

What breaks the chain

The chain has two hinges, and each one has a clean fix. The capture end depends on Windows falling back to LLMNR and NBT-NS. Turn that fallback off. LLMNR is disabled by group policy under the DNS client settings, and NBT-NS is disabled per interface or pushed through DHCP option 001 with a startup script. With both off, a failed DNS lookup simply fails, and Responder hears nothing to answer. A network test should confirm the policy is applied on the wire, not merely set, because the two protocols are configured in different places and it is common to disable one and leave the other broadcasting.

The reuse end depends on hosts accepting unsigned SMB sessions. Require SMB signing on servers and clients, and a relayed session cannot be signed, so it is refused. These two controls together are the standard technical mitigation NIST SP 800-115 frames as verifying configuration against policy, and they cost nothing but the change window. The residual risk after them is a weak password on an account that still authenticates somewhere, which is why account hygiene, and hunting for accounts that skip protections like AS-REP roasting does, stays on the list.

None of this is exotic, and that is the point. The findings that carry an internal red team engagement are usually defaults left in place rather than a novel exploit, and this chain is three defaults lined up: a name-resolution fallback, an unsigned SMB session, and a reused local password.

What this means for networks in Dubai and Abu Dhabi

This chain is a property of internal Windows networks, which is where most work in the UAE sits: a corporate domain, file servers, and default protocols nobody revisited after the estate was built. An internal test that starts with no credentials, the position this attack assumes, is what shows whether those defaults are still broadcasting. For a bank or a payment firm supervised by the Central Bank of the UAE, and for a Dubai government entity or its suppliers under the Dubai Electronic Security Centre, internal network testing is the part of an assessment that reaches this class of finding, because an external scan never sees the broadcast segment where it lives.

The controls that break it, disabling LLMNR and NBT-NS and requiring SMB signing, are configuration baselines rather than products, and both Dubai and Abu Dhabi procurement will expect them evidenced against the applicable regime: the NESA-published Information Assurance Standards federally, and ADHICS for a healthcare provider in Abu Dhabi. A free-zone entity carries the same exposure as a mainland one; the broadcast domain does not care about the licence. The practical ask is the same in either emirate: prove the fallback is off on the wire, prove signing is required, and have an internal test confirm both from the position an attacker would take.

Frequently asked questions